Microsoft has admitted that a “validation error in Microsoft code” helped Chinese hackers to breach the Exchange Online and Azure Active Directory accounts of government agencies and other organisations – after the mystery theft of a key that let the attacker forge access tokens.
Microsoft Threat Intelligence hinted that the incident first reported on July 11 may also have involved the breach of Microsoft systems to steal a Microsoft account (MSA) consumer signing key – although “the method by which the actor acquired the key is a matter of ongoing investigation.”
This key allowed it to forge Azure AD tokens, as a result of this “validation error” in how Microsoft was handling identity management, then go on to attack some two dozen organisations internationally including diplomatic, economic and telecommunications organisations, a July 14 post said.
Keys, tokens, forgery, what?
Microsoft explained the use of authentication tokens as follows.
"Authentication tokens are used to validate the identity of entities requesting access to resources – in this case, email. These tokens are issued to the requesting entity (such as a user’s browser) by identity providers like Azure AD. To prove authenticity, the identity provider signs the token using a private signing key. The relying party validates the token presented by the requesting entity by using a public validation key. Any request whose signature is correctly validated by the published public validation key will be trusted by the relying party. An actor that can acquire a private signing key can then create falsified tokens with valid signatures that will be accepted by relying parties. This is called token forgery."
The stolen MSA key should only really have allowed the atttacked to create falsified tokens that let it access target consumer accounts, but due to this "validation error in Microsoft code", let it do the same thing for Azure AD enterprise accounts.
Microsoft’s rivals have leaped on the incident, with CrowdStrike saying the incident “amplifies the systemic risk of Microsoft’s technology… federal leaders have been making a public push to pressure software makers to build products that are secure by design. Unfortunately, that message seems to continue to fall on deaf ears in Redmond."
But Microsoft said the attacker had “a high degree of technical tradecraft and operational security” and was “keenly aware of the target’s environment, logging policies, authentication requirements, policies, and procedures… technically adept, well resourced, and has an in-depth understanding of many authentication techniques and applications.”
See also: This Azure bug is a perfect CVSS 10, gives you control over K8s clusters
“Since identification of this malicious campaign on June 16, 2023, Microsoft has identified the root cause, established durable tracking of the campaign, disrupted malicious activities, hardened the environment, notified every impacted customer, and coordinated with multiple government entities. We continue to investigate and monitor the situation and will take additional steps to protect customers” it added.
The group’s acquisition of an “MSA consumer signing key” that it then used to forge authentication tokens for Azure AD enterprise and MSA consumer remains something of a key mystery (apologies for the pun.)
Microsoft key storage hardened
But Microsoft suggested that it was thinking long and hard about its systems’ in the wake of the key’s loss, saying it has “substantially hardened key issuance systems since the acquired MSA key was initially issued. This includes increased isolation of the systems, refined monitoring of system activity, and moving to the hardened key store used for our enterprise systems” – that latter line suggesting consumer keys were now being stored in Hardware Security Modules (HSMs) which industry observers say had not previously been the case for such keys.
“We have revoked all previously active keys and issued new keys using these updated systems. Our active investigation indicates these hardening and isolation improvements disrupt the mechanisms we believe the actor could have used to acquire MSA signing keys. No key-related actor activity has been observed since Microsoft invalidated the actor-acquired MSA signing key. Further, we have seen Storm-0558 transition to other techniques, which indicates that the actor is not able to utilize or access any signing keys. We continue to explore other ways the key may have been acquired and add additional defense in depth measures."
According to a joint advisory by the CISA and FBI, the incident was flagged after one federal agency that got breached observed unexpected events in Microsoft 365 audit logs in June 2023. Troublingly for many, the specific logging that caught the incident, CISA notes, requires licensing at the expensive G5/E5 level and “CISA and FBI are not aware of other audit logs or events [other than of E5-available MailItemsAccessed events] that would have detected this activity.”)
Steven Adair, founder of Volexity, a security firm providing incident response, said said his firm had been called out to one affected organisation.
“Initially the incident was a real head scratcher for us. Investigating incidents and suspect activity in Microsoft 365 and AzureAD is something we do frequently. However, despite a notification from Microsoft regarding unauthorized access, we could not find any corroborating evidence. It turns out our investigation turned up nothing because there was nothing for us to find. The incident was invisible to us with the data at our disposal and this was due to the customer's M365 license level: E3... [CISA’s] first recommendation is ‘Enable Purview Audit (Premium) logging. This logging requires licensing at the G5/E5 level.’ That is a tough pill to swallow for most organizations due to the cost. IMHO, this log data should be available at all M365 license levels” he added in a social media post.
Follow The Stack on LinkedIn
.
