In a detailed, technical blog post, Wiz researcher Shir Tamari wrote that while Microsoft had said that Outlook.com and Exchange Online were the only applications to be affected, "Wiz Research has found that the compromised signing key was more powerful than it may have seemed, and was not limited to just those two services".

"Our researchers concluded that the compromised MSA key could have allowed the threat actor to forge access tokens for multiple types of Azure Active Directory applications, including every application that supports personal account authentication, such as SharePoint, Teams, OneDrive, customers’ applications that support the 'login with Microsoft' functionality, and multi-tenant applications in certain conditions," he said.

The breach came to light on 13 July, with the email account of US Commerce Secretary Gina Raimondo cited as one of the more prominent accounts to have been breached.

The attackers gained access through a vulnerability in Microsoft's Azure cloud platform which was said to have been discovered last month by the State Department, according to anonymous officials who spoke to the Washington Post.

On Friday, the Wall Street Journal reported that the attackers, who are claimed to have been from China, also breached the email account of American envoy to Beijing, Nicholas Burns, and assistant secretary of state for East Asia, Daniel Kritenbrink.

Tamari said while Microsoft had mitigated the risk by revoking the impacted encryption key and provided indicators of compromise of the attackers, "we discovered that it may be difficult for customers to detect the use of forged tokens against their applications due to lack of logs on crucial fields related to the token verification process".

Microsoft came under fire after the incident was disclosed for not providing logs to its basic subscriptions. Steven Adair, a security expert at Volexity, told Reuters on 13 July that he could not find out details about a client's breached email account because of a lack of logs.

The news agency said Adair's client had not forked out what Microsoft demands for its premium security suite, and hence detailed forensic data was unavailable.

Adair thus could not discern what had happened. "We basically became a spectator at that point," he said.

On 19 July, Microsoft yielded to the pressure to some extent, but still held back on providing full logging access, saying: "Additional Audit Premium features [which] include longer default retention periods and automation support for importing log data into other tools for analysis" would have to be bought.

Vasu Jakkal, corporate vice-president for Security, Compliance, Identity and Management, said in a blog post that cloud logging accessibility and flexibility would be expanded.

"Over the coming months, we will include access to wider cloud security logs for our worldwide customers at no additional cost," she said. "As these changes take effect, customers can use Microsoft Purview Audit to centrally visualise more types of cloud log data generated across their enterprise."

Tamari explained why the attack was so serious, saying: "Identity provider’s signing keys are probably the most powerful secrets in the modern world. For example, they are much more powerful than TLS keys.

"Even if an attacker got access to the google.com TLS key, they would still need to somehow impersonate a google.com server to gain significant impact. With identity provider keys, one can gain immediate single hop access to everything, any email box, file service or cloud account.

"This isn’t a Microsoft-specific issue, if a signing key for Google, Facebook, Okta or any other major identity provider leaks, the implications are hard to comprehend. Our industry — and especially cloud service providers — must commit to a greater level of security and transparency concerning how they protect critical keys such as this one, to prevent future incidents and limit their potential impact."

Tamari said while Microsoft had ensured that Azure Active Directory applications would not longer accept forged tokens as valid, by revoking the compromised keys, the danger from the breach still remained..

"...during previously established sessions with customer applications prior to the revocation, the malicious actor could have leveraged its access to establish persistence," he explained.

"This could have occurred by leveraging the obtained application permissions to issue application-specific access keys or setting up application-specific backdoors. A notable example of this is how, prior to Microsoft’s mitigation, Storm-0558 [the name given by Microsoft to the alleged Chinese attackers] issued valid Exchange Online access tokens by forging access tokens for Outlook Web Access.

"There is another potential risk to applications that retained copies of the AAD public keys prior to Microsoft's certificate revocation. Applications that rely on local certificate stores or cached keys and still trust the compromised key remain susceptible to token forgery.

"It is imperative for these applications to immediately refresh the list of trusted certificates. Microsoft advises refreshing the cache of local stores and certificates at least once a day."

The Wiz researcher said Azure users should act to safeguard against future attacks. "To identify whether a compromised key was used in your environment, identify all potentially affected applications in your environment, search for forged tokens usage... and leverage the IoCs published by Microsoft on their blog to look for any activity that originates from the IP addresses provided by Microsoft," he advised.

"In addition, make sure that none of the applications use a cached version of the Microsoft OpenID public certificates, and if so, refresh the cache."

Tamari also provided steps for Azure users to detect compromised keys in their environments.

"The full impact of this incident is much larger than we Initially understood it to be. We believe this event will have long lasting implications on our trust of the cloud and the core components that support it, above all, the identity layer which is the basic fabric of everything we do in cloud. We must learn from it and improve," he concluded.

"At this stage, it is hard to determine the full extent of the incident as there were millions of applications that were potentially vulnerable, both Microsoft apps and customer apps, and the majority of them lack the sufficient logs to determine if they were compromised or not.

"However there are some critical actions items that application owners should perform. The first and foremost is to update their Azure SDK to the latest version and ensure their application cache is updated, otherwise their apps may still be vulnerable to a threat actor using the compromised key."

Microsoft has not issued any further posts about the incident after its 14 July blog post.