{
	"id": "e8d0012e-eaad-46ef-a33f-474992d10200",
	"created_at": "2026-04-06T00:12:05.284886Z",
	"updated_at": "2026-04-10T13:12:07.056515Z",
	"deleted_at": null,
	"sha1_hash": "2726df4adadcb2b116aa1c894e5404b432cc4c7e",
	"title": "Compromised Microsoft Key: More Impactful Than We Thought",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1185484,
	"plain_text": "Compromised Microsoft Key: More Impactful Than We Thought\r\nBy Shir Tamari\r\nPublished: 2023-07-21 · Archived: 2026-04-05 17:35:00 UTC\r\nMicrosoft and CISA recently disclosed a security incident impacting multiple customers of Exchange Online and\r\nOutlook.com. According to Microsoft, this incident stemmed from a threat actor attributed to China, Storm-0558,\r\nacquiring a private encryption key (MSA key) and using it to forge access tokens for Outlook Web Access (OWA)\r\nand Outlook.com. Additionally, the threat actor reportedly exploited two security issues in Microsoft’s token\r\nverification process.\r\nMicrosoft have said that Outlook.com and Exchange Online were the only applications known to have been\r\naffected via the token forging technique, but Wiz Research has found that the compromised signing key was more\r\npowerful than it may have seemed, and was not limited to just those two services. Our researchers concluded that\r\nthe compromised MSA key could have allowed the threat actor to forge access tokens for multiple types of Azure\r\nActive Directory applications, including every application that supports personal account authentication, such as\r\nSharePoint, Teams, OneDrive, customers’ applications that support the “login with Microsoft” functionality, and\r\nmulti-tenant applications in certain conditions.\r\nIn addition, while Microsoft mitigated this risk by revoking the impacted encryption key and publishing attacker\r\nIOCs, we discovered that it may be difficult for customers to detect the use of forged tokens against their\r\napplications due to lack of logs on crucial fields related to the token verification process.\r\nWhy is it so impactful?  Identity provider’s signing keys are probably the most powerful secrets in the modern\r\nworld.  For example, they are much more powerful than TLS keys. Even if an attacker got access to the\r\ngoogle.com TLS key, they would still need to somehow impersonate a google.com server to gain significant\r\nimpact. With identity provider keys, one can gain immediate single hop access to everything, any email box, file\r\nservice or cloud account. This isn’t a Microsoft specific issue, if a signing key for Google, Facebook, Okta or any\r\nother major identity provider leaks, the implications are hard to comprehend. Our industry – and especially cloud\r\nservice providers – must commit to a greater level of security and transparency concerning how they protect\r\ncritical keys such as this one, to prevent future incidents and limit their potential impact. \r\nIn this post, we will share how we were able to confirm which private key was acquired by the threat actor and\r\nhow we determined its permissions. We will also unpack some of the technical aspects of this incident and help\r\ndetect potential use of this compromised key within your environments.\r\nCompromised consumer signing key – who are you? \r\nOn July 11th, 2023, Microsoft revealed that a malicious actor had obtained an MSA consumer signing key,\r\nallowing them to forge access tokens for Exchange Online and Outlook.com accounts.\r\nDetermined to learn more about the incident, we launched an investigation.\r\nhttps://www.wiz.io/blog/storm-0558-compromised-microsoft-key-enables-authentication-of-countless-micr\r\nPage 1 of 7\n\nFirst, we checked which keys could sign OpenID tokens for Microsoft accounts and Azure Active Directory\r\napplications. We therefore examined Microsoft’s official documentation for OpenID token verification.\r\nInterestingly, we discovered that all Azure personal account v2.0 applications depend on a list of 8 public keys,\r\nand all Azure multi-tenant v2.0 applications with Microsoft account enabled depend on a list of 7 public keys (at\r\nthe time of writing).\r\nUsing the Internet Archive’s Wayback Machine, we noticed that one of the listed public keys that had been present\r\nsince at least 2016 was replaced sometime between June 27th and July 5th, 2023, matching the time frame in\r\nwhich Microsoft replaced the acquired key according to their blog post.\r\nMetadata of the public key replaced between June 27th and July 5th \r\nThe old public key’s certificate revealed it was issued on April 5th, 2016, and expired on April 4th, 2021, and its\r\nthumbprint matched the thumbprint of the key Microsoft listed in their latest blog post, named “Thumbprint of\r\nacquired signing key”:\r\nThe decoded certificate of the old key (1LTMzakihiRla_8z2BEJVXeWMqo). Obtained from the list\r\nintended June 27th, 2023 version of the certificate list for Azure common (mixed audience)\r\napplications.\r\nThis led us to believe that although the compromised key acquired by Storm-0558 was a private key designed for\r\nMicrosoft's MSA tenant in Azure, it was also able to sign OpenID v2.0 tokens for multiple types of Azure Active\r\nDirectory applications.\r\nWhat is the significance of a compromised OpenID signing key? \r\nThe Azure identity platform publishes multiple lists of trusted keys scoped to different application types. These\r\nserve to validate the integrity of tokens which are issued by Azure Active Directory (AAD). During the\r\nauthentication process for an AAD application, the application must confirm the token's authenticity by verifying\r\nits signature against the correct trusted public key list. This verification determines whether the token should be\r\ntrusted.\r\n# Azure Active Directory multi-tenant applications: \r\nAzure Active Directory public certificates’ lists \r\nIf any of the keys from one of these lists are compromised, there is a significant risk for applications using that list\r\nfor validation. Such a compromise could enable unauthorized parties to forge valid access tokens for consumption\r\nby any application that depends on the Azure identity platform under certain conditions (see below).\r\nThe risks of compromised OpenID signing key\r\nBased on what we can deduce from Microsoft’s blog post, Storm-0558 seemingly managed to obtain access to one\r\nof several keys that were intended for signing and verifying AAD access tokens. The compromised key was\r\ntrusted to sign any OpenID v2.0 access token for personal accounts and mixed-audience (multi-tenant or personal\r\naccount) AAD applications.\r\nhttps://www.wiz.io/blog/storm-0558-compromised-microsoft-key-enables-authentication-of-countless-micr\r\nPage 2 of 7\n\nThe types of applications that could trust the key acquired by Storm-0558\r\nIn other words, Storm-0558 could have theoretically used the private key it acquired to forge tokens to\r\nauthenticate as any user to any affected application that trusts Microsoft OpenID v2.0 mixed audience and\r\npersonal-accounts certificates.\r\nWhich applications are affected? \r\nBased on our analysis, only Azure Active Directory applications that work with Microsoft’s OpenID v2.0 were\r\naffected. Version 1.0 applications were not using the compromised key for token validation and therefore were not\r\naffected.\r\nApplications supporting Personal Microsoft accounts only\r\nAny Azure Active Directory application that supports “Personal Microsoft accounts only” and works against\r\nMicrosoft’s v2.0 protocol was affected. This includes managed Microsoft applications, such as Outlook,\r\nSharePoint, OneDrive, and Teams, as well as customers’ applications that support Microsoft Account\r\nauthentication, including those who allow the “Login with Microsoft” functionality.\r\nApplications supporting accounts in any organizational directory (Any Azure AD directory –\r\nMulti-tenant) and personal Microsoft accounts (e.g. Skype, Xbox)\r\nAny Azure Active Directory application that supported “mixed audience” and works against Microsoft’s v2.0\r\nprotocol was affected as well. The threat actor could forge valid access tokens and impersonate application users\r\nwho signed in with their Personal Microsoft account.\r\nTo restrict the power of MSA keys in impersonating organizational accounts, Microsoft introduced an extension to\r\nthe OpenID protocol. This extension advises developers to validate the issuer claim by comparing it with the\r\nissuer field in the list of the OpenID public keys. By doing this, it aims to prevent an MSA key from signing\r\naccess tokens with an issuer different than the MSA tenant (9188040d-6c67-4c5b-b112-36a304b66dad). This\r\nextension is specific to Microsoft and the responsibility of its implementation rests with the application owner.\r\nTherefore, there is a concern that many applications lack this procedure and as a result, the threat actor could\r\npotentially impersonate organizational accounts as well (according to Microsoft’s blogpost, OWA was affected by\r\na similar issue).\r\nTo assist Azure developers with adopting this validation functionality, Microsoft added it to their official Azure\r\nSDK on July 12.\r\nApplications supporting accounts in any organizational directory (Any Azure AD directory –\r\nMulti-tenant)\r\nIIf the multi-tenant application is configured to rely on the “common” v2.0 keys endpoint (instead of\r\n“Organizations”), then it is affected but also should be considered misconfigured. The official Microsoft\r\ndocumentation is not clear on when the “common” endpoint should be used, and therefore, some multi-tenant\r\napplications could be affected as well.\r\nhttps://www.wiz.io/blog/storm-0558-compromised-microsoft-key-enables-authentication-of-countless-micr\r\nPage 3 of 7\n\nApplications supporting accounts in this organizational directory only (Singletenant)\r\nSingle tenant applications were not affected. \r\nHow different types of users may have been affected depending on the application type and whether\r\nit was properly validating access tokens\r\nHow does key forging work? \r\nOpenID keys are fundamentally JWTs signed by an authorized private key. As part of the Azure Active Directory\r\ntoken validation procedure, the app developer must confirm that the key is indeed signed by the relevant authority\r\nfor the intended scope, and that the token's aud field matches the targeted application’s scope.\r\nTo confirm whether the token was truly signed by a trusted Azure authority, the application developer queries a\r\nmetadata endpoint (named jwks_uri ) to pull the permitted certificates for signature verification and verify the\r\ntoken against it.\r\nTo forge a valid access token, the threat actor could have crafted a JWT token, populated it with a victim’s data\r\n(e.g. email address), and finally signed it with the trusted compromised key that is listed under the Azure Active\r\nDirectory public certificates’ endpoint. By submitting the signed token to a targeted application, the malicious\r\nactor could have then impersonated the victim.\r\nHere is a fictitious example of such a forged OpenID token signed by the compromised encryption key,\r\n1LTMzakihiRla_8z2BEJVXeWMqo :\r\nAccording to Microsoft's guidelines, in order for the token to be considered valid, the issuer claim ( iss ) must be\r\nset to https: //sts.windows.net/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0 since it was specified in the issuer\r\nfield within the jwks_uri endpoint. As for the tenant ID claim ( tid ), it must accordingly be set to 9188040d-6c67-4c5b-b112-36a304b66dad , the MSA tenant’s ID.\r\nFor AAD mixed-audience applications (multi-tenant and personal-account), any token signed by the MSA tenant\r\nfor an Azure AD account could be deemed valid, as long as it impersonates a personal account.\r\nFor additional details, check out Microsoft's official guidelines on how to verify ID Tokens.\r\nAre Azure customers still at risk? \r\nDue to Microsoft's revocation of the compromised key, Azure Active Directory applications will no longer accept\r\nforged tokens as valid tokens. Tokens with extended expiration dates will also be rejected by these applications.\r\nHowever, during previously established sessions with customer applications prior to the revocation, the malicious\r\nactor could have leveraged its access to establish persistence. This could have occurred by leveraging the obtained\r\napplication permissions to issue application-specific access keys or setting up application-specific backdoors. A\r\nnotable example of this is how, prior to Microsoft’s mitigation, Storm-0558 issued valid Exchange Online access\r\ntokens by forging access tokens for Outlook Web Access (OWA).\r\nhttps://www.wiz.io/blog/storm-0558-compromised-microsoft-key-enables-authentication-of-countless-micr\r\nPage 4 of 7\n\nThere is another potential risk to applications that retained copies of the AAD public keys prior to Microsoft's\r\ncertificate revocation. Applications that rely on local certificate stores or cached keys and still trust the\r\ncompromised key remain susceptible to token forgery. It is imperative for these applications to immediately\r\nrefresh the list of trusted certificates. Microsoft advises refreshing the cache of local stores and certificates at least\r\nonce a day.\r\nRecommendations for Azure users \r\nTo identify whether a compromised key was used in your environment, identify all potentially affected\r\napplications in your environment, search for forged tokens usage (as explained in the next section) and leverage\r\nthe Indicators of Compromise (IoCs) published by Microsoft on their blog to look for any activity that originates\r\nfrom the IP addresses provided by Microsoft.\r\nIn addition, make sure that none of the applications use a cached version of the Microsoft OpenID public\r\ncertificates, and if so, refresh the cache.\r\nMicrosoft has added additional verifications to the official Azure SDK, which are designed to prevent the use of\r\nMSA keys to authenticate to organization accounts. Users of the package are advised to update it to the latest\r\nversion.\r\nHow to detect the compromised key in your environment \r\nSince the threat actor can forge access tokens offline, there is no trail in the Azure portal for token issuance. The\r\nonly way for cloud customers to identify whether the key was used to target their apps or users is by reviewing\r\napplication-specific logs for potentially affected AAD apps. Therefore, application owners who want to protect\r\ntheir systems will have to check whether a forged token has been used against their applications.\r\nTo the best of our knowledge, the only affected applications were those that utilized Microsoft v2.0 access token\r\nverification using the endpoints ”https://login.microsoftonline.com/common/discovery/v2.0/keyscommon“ and\r\n“https://login.microsoftonline.com/consumers/discovery/v2.0/keys“. These parameters make it feasible to filter\r\nout applications that were not exposed to this issue. \r\nFirst, to identify which AAD applications in your environment might be affected, you can run the following Azure\r\nCLI command: \r\nAdditionally, your AAD applications might also be associated with Azure WebApps. To identify which AAD apps\r\nare redirecting to any of your WebApps, you can run the following CLI command: \r\nNext, to identify potentially malicious activities in applications, it is necessary to examine suspicious\r\nauthentication attempts via OpenID tokens signed by the compromised key. This can be done by unpacking the\r\naccess tokens used against the application and searching for the string 1LTMzakihiRla_8z2BEJVXeWMqo within the\r\nkid field of the JOSE Header. \r\nAccording to Microsoft, the compromised key was inactive and therefore any access token signed by this key\r\nmust be considered suspicious.\r\nhttps://www.wiz.io/blog/storm-0558-compromised-microsoft-key-enables-authentication-of-countless-micr\r\nPage 5 of 7\n\nUnfortunately, there is a lack of standardized practices when it comes to application-specific logging. Therefore,\r\nin most cases, application owners do not have detailed logs containing the raw access token or its signing key. As\r\na result, identifying and investigating such events can prove exceedingly challenging for app owners.\r\nWhen examining an AAD application configured solely for multi-tenant authentication (without support for\r\nMicrosoft personal accounts), it is possible to detect forged tokens by filtering for `iss` and `tid` claims within the\r\naccess token. Applications commonly use these fields and they are more likely to be present in application logs.\r\nMoreover, any attempt to connect with an access token signed by the MSA tenant ID 9188040d-6c67-4c5b-b112-\r\n36a304b66dad may indicate the use of a compromised key.\r\nFinally, if you’ve enabled HTTP Logs in your WebApp, you might be able to see which IP addresses have\r\naccessed your application. Based on Microsoft’s blogpost, the following IP addresses are associated with the threat\r\nactor, so you should validate if your WebApp might have been impacted by running the following query in Log\r\nAnalytics for each of your potentially affected Web Apps: \r\nFor additional guidance on searching for signs of persistence in your environment, see our “CircleCI Incident Sign\r\nof Persistence” blog. \r\nKey Takeaways \r\nThe full impact of this incident is much larger than we Initially understood it to be. We believe this event will have\r\nlong lasting implications on our trust of the cloud and the core components that support it, above all, the identity\r\nlayer which is the basic fabric of everything we do in cloud. We must learn from it and improve.\r\nAt this stage, it is hard to determine the full extent of the incident as there were millions of applications that were\r\npotentially vulnerable, both Microsoft apps and customer apps, and the majority of them lack the sufficient logs to\r\ndetermine if they were compromised or not. However there are some critical actions items that application owners\r\nshould perform. The first and foremost is to update their Azure SDK to the latest version and ensure their\r\napplication cache is updated, otherwise their apps may still be vulnerable to a threat actor using the compromised\r\nkey.\r\nWe will continue to closely monitor this incident and provide updates; this is still an ongoing investigation and\r\nthere are many unanswered questions (how did the threat actor acquire the key? When exactly did it happen? Were\r\nother keys compromised as well?). Finally, we want to thank the Microsoft team for working closely with us on\r\nthis blog and helping us ensure it is technically accurate.\r\nSee for yourself...\r\nLearn what makes Wiz the platform to enable your cloud security operation\r\nhttps://www.wiz.io/blog/storm-0558-compromised-microsoft-key-enables-authentication-of-countless-micr\r\nPage 6 of 7\n\nReferences \r\nhttps://msrc.microsoft.com/blog/2023/07/microsoft-mitigates-china-based-threat-actor-storm-0558-\r\ntargeting-of-customer-email/ \r\nhttps://www.cisa.gov/news-events/cybersecurity-advisories/aa23-193a \r\nhttps://blogs.microsoft.com/on-the-issues/2023/07/11/mitigation-china-based-threat-actor/ \r\nhttps://www.microsoft.com/en-us/security/blog/2023/07/14/analysis-of-storm-0558-techniques-for-unauthorized-email-access/ \r\nhttps://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/pull/2136/files \r\nhttps://github.com/MicrosoftDocs/azure-docs/commit/f17445bb9202a89964ea7311c4374806adfcb28c \r\nSource: https://www.wiz.io/blog/storm-0558-compromised-microsoft-key-enables-authentication-of-countless-micr\r\nhttps://www.wiz.io/blog/storm-0558-compromised-microsoft-key-enables-authentication-of-countless-micr\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MISPGALAXY",
		"ETDA",
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.wiz.io/blog/storm-0558-compromised-microsoft-key-enables-authentication-of-countless-micr"
	],
	"report_names": [
		"storm-0558-compromised-microsoft-key-enables-authentication-of-countless-micr"
	],
	"threat_actors": [
		{
			"id": "86fb4ddd-989e-4613-8db8-ca646c553aae",
			"created_at": "2023-11-01T02:00:07.404201Z",
			"updated_at": "2026-04-10T02:00:03.381034Z",
			"deleted_at": null,
			"main_name": "Storm-0558",
			"aliases": [],
			"source_name": "MISPGALAXY:Storm-0558",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "1c762729-56f7-48d5-8fb0-b64a43716319",
			"created_at": "2023-09-07T02:02:47.944899Z",
			"updated_at": "2026-04-10T02:00:04.907587Z",
			"deleted_at": null,
			"main_name": "Storm-0558",
			"aliases": [
				"Antique Typhoon"
			],
			"source_name": "ETDA:Storm-0558",
			"tools": [
				"CHINACHOPPER",
				"China Chopper",
				"SinoChopper"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434325,
	"ts_updated_at": 1775826727,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/2726df4adadcb2b116aa1c894e5404b432cc4c7e.pdf",
		"text": "https://archive.orkl.eu/2726df4adadcb2b116aa1c894e5404b432cc4c7e.txt",
		"img": "https://archive.orkl.eu/2726df4adadcb2b116aa1c894e5404b432cc4c7e.jpg"
	}
}