Microsoft has published a more technical analysis[1] which was submitted in two of those HN stories mentioned above (which received no interest). Microsoft hav

Microsoft has published a more technical analysis[1] which was submitted in two of those HN stories mentioned above (which received no interest). Microsoft have two identity services being MSA and AAD. MSA is used for consumer Microsoft accounts for use with products like Xbox. AAD is Azure AD that businesses use. When a client wants to authenticate to a Microsoft service, it asks MSA to sign a token for services accepting MSA tokens, or asks AAD to sign a token for services accepting AAD tokens. Someone has gained access to an "inactive" (but not "invalidated"/revoked) MSA signing key. It's not stated in the analysis whether Microsoft services such as Xbox would have accepted a token signed with an "inactive" MSA signing key, but it sounds like this may have been the case. It's just consumer privacy and security at stake and the attackers apparently weren't interested in that, so the analysis is rather ¯\_(ツ)_/¯ on consumer impact. The problem for Microsoft is that they had incorrectly configured OWA API to accept tokens signed by the MSA identity services even when accessing mailboxes that should require an AAD signed token. So now the attacker could access mailboxes for all business and government users around the world (excluding GCC High, DoD, etc which Microsoft state are not exposed to public networks). Microsoft only found out after one of their diligent customers queried Microsoft on why they were seeing logs for user mailboxes being accessed in unexpected ways. Speculatively (not in the analysis) this may have been noticed as a random IP address outside of allowed subnets accessing mailboxes at odd hours, and the customer checked their AAD configuration to ensure IP subnet restrictions were configured correctly and verified the user was not overseas. The attacker looks to have been quite careless by accessing OWA API from very obvious red flag locations for legitimate users. For example, the attacker could have used a residential ISP subnet in Washington DC to access a GCC hosted mailbox of a government agency with a presence in Washington DC, and only done so in hours that an employee may be working from home in Washington DC. Or the attacker could have gone after soft targets like small to medium businesses that contract to the government, hoping these soft targets wouldn't be monitoring nor have the ear of Microsoft for prompt incident response. Instead, the attacker has used random dedicated hosting providers in places as far as Europe and accessed mailboxes during hours coinciding with business hours half way between the US and Europe. It's possible the attackers thought this attack would be detected quickly, and therefore were always just going for a hit-and-run approach knowing they'd get their data prior to the attack being noticed and blocked. But it does make the attacker look brazen at best, and unsophisticated and careless at worst. [1] https://www.microsoft.com/en-us/security/blog/2023/07/14/analysis-of-storm-0558-techniques-for-unauthorized-email-access/ https://www.microsoft.com/en-us/security/blog/2023/07/14/ana... [2] https://learn.microsoft.com/en-us/office365/servicedescriptions/office-365-platform-service-description/office-365-us-government/gcc https://learn.microsoft.com/en-us/office365/servicedescripti...