Root Causes 323: Update on Microsoft Key Compromise

Hosted by

Tim Callan

Chief Compliance Officer

Jason Soroko

Fellow

Original broadcast date

August 3, 2023

In this follow up to our episode 320, we describe Microsoft's actions to mitigate this attack and explain new understanding that shows its impact to be broader than originally thought. Anyone using the Microsoft stack needs to understand this new threat.

Podcast Transcript

Lightly edited for flow and brevity.

Tim CallanThis is an update on the Microsoft key compromise story. We originally covered this in our episode 320. We're not going to repeat what was in that episode so if you want to learn the basics, I recommend you go back to our Episode 320. We're going to pick that up where we left off and I guess we'll repeat a tiny bit of it. On July 11, 2023, there was a bulletin I believe, from Microsoft, where they announced that basically root kit software, root malware was being signed using a Microsoft certificate in China. Correct?

Jason SorokoThat is correct. That was the original announcement.

Tim CallanAll right. So there's two updates. Number one is that same day, July 11, Microsoft announced that they had basically solved the problem, mitigated the problem, which I think means they revoked the certificate, which will pretty much kill that. And Microsoft has said Microsoft has completely mitigated this attack, and no consumer action is required. So there you go. That's number one.

Jason SorokoCorrect. Tim, what we're calling out here on this podcast is a follow up. Which is Wiz, if you go to wiz.io, we'll call them right out, Shir Tamari, author, July 21, talks about the fact that the compromise goes further than just the firmware signing, unfortunately.

Tim CallanThat article real quick, Jay, before you jump into it, if you want to do a search, the title is Compromised Microsoft Key More Impactful Than We Thought. It is from wiz.io, as you said, Shir Tamari, is the writer and with that, go ahead, Jay. So what does Shir have to say?

Jason SorokoSure. I'll keep it real basic. I invite everybody, everybody, to actually look at this article because it will affect everyone who has a Microsoft stack of technology. Basically, Tim, that part of the original compromise, they did mention compromise of Outlook. That's one of the clues, but for any of you who run Outlook, Office365, SharePoint, MS Teams, or application, specific kinds of applications that are utilizing Azure, and I won't go into it because I'll easily botch it and get something wrong, you should go right to the source of this article. Anytime you're logging into those tools, Tim, that you're logging in with a token, because once you identify yourself, once you've logged in to Microsoft, you then will be allowed into these different services by having a signed token. The problem is that it looks like these signing keys that were stolen were enabling the attacker to forge their own signed JWT tokens for Open ID. That's bad. That's really, really bad because that essentially allows the attacker to then authenticate just about any kind of account into those affected applications. So imagine this Tim, the concept, obviously, of the public/private key pair. That's well understood. But we're talking about essentially a form of single sign on through OpenID and OpenID uses the mechanism of tokens, which are not necessarily, they're not certificates. It's essentially a real snazzy passcode if you will. That’s people who were in the industry will throw a book at me for saying such a stupid thing, but I'm trying to oversimplify this for everybody else.

These tokens, they're not really valid. You can't just make them up. They have to be signed by this Microsoft signing key, which unfortunately was compromised. So think about this. Let's say that you have a lock on your front door and this door uses like a pin pad and you have to enter in a complicated in order to open the door. It’s not like a key, like the way we traditionally think of a key. Think of the key in this case as being the thing that bestows the pin pad, the actual number on the pin pad to be the something that is known to be valid by the pin pad reader. It's kind of a complicated way of saying it. What I'm really trying to say here is that the actual login mechanism of OpenID depends on trust to be bestowed on it, if you will, by a signing key. That's what I'm trying to get across here.

Tim CallanCorrect. And it circumvents those other protections. You and I have talked at great length on many, many episodes, about the reason that it's better. PKI is better. But we should probably slightly modify that to say, properly functioning PKI is better. In the case that your key is compromised and is usable, then it’s not better. It's a whole lot worse. It's worlds worse. That's what we're looking at here.

Jason SorokoYou got it. It’s worlds worse. Because of the fact that these tokens can now be generated tokens that essentially get you into that pin pad, if you will. They get you into the door even though you don't have the original signing key, the thing that bestows the trust. If the bad guy has that, then they can start to make their own essentially pin pad codes to get through the door. so that's really bad. So the idea that the signing keys, Tim, have been revoked, and they're no longer valid, that's all really good. Microsoft, as far as I understand, I haven't personally seen it yet, at this point, just haven't had the time to look, but it looks like they published indicators of compromise and they give you ways to search for those forged token usages.

The problem is this. this is the reason why we wanted to call out this on the podcast, is because a lot of you probably don't have certain logs turned on in order to look for this forged token usage and the indicators of compromise. It's very specific of the forged token usage that the logs might not be turned on. So without getting into a lot of that application specific logging stuff and how that would all work, this is not an IT course we're putting on here on this podcast, this is something where if you're a Risk Officer, if you're a CIO, please ask your security staff and your IT staff that are responsible for turning on or off these logs to determine whether or not you do have those logs on and look for that indicator of forged token usage and all those other indicators of compromise, IOCs, make sure that you're the what's necessary to look for those forge token usages is available to you. That's the most plain English I can put it.

Tim CallanJason, if my memory serves, Shir’s article is not a bad place to start. If I want to look at and figure out what do I need to do to look for these. Like that's where the trail of breadcrumbs begins is right there. Now let me ask you another question. And I'm pulling this out of the Microsoft bulletin. Here's the headline it's on MSRC. It reads Microsoft Mitigates China Based Threat Actor Storm O558 Targeting of Customer Email. This is the problem we're talking about. Go down to, partway down in the article. Here's what it says. These are steps Microsoft have taken. Three bullets. I'm just gonna read them verbatim.

Microsoft blocked the usage of tokens signed by the acquired MSA key in OWA, preventing further threat actor and apprised mail activity. So we get that.

Second one. Microsoft completed the replacement of the key to prevent the threat actor from using it to forge tokens. In other words, we replaced it. We revoked the cert. This is what you and I were talking about.

Here's the third one. Microsoft blocked usage of tokens issued with the key for all impacted consumer customers. So what's the significance of that third one? And is that solving the problem for us?

Jason SorokoI think the article that we are quoting here from Wiz basically says I believe that the context of that was for Microsoft Outlook and OWA. And so what Wiz is saying is they found that Microsoft had actually changed out keys for other applications, which include Office 365, SharePoint, Teams, and certain kinds of Azure customer applications.

They were paying very close attention to things and realized, oh, this goes beyond the scope of Outlook and OWA. This goes into other things as well. Therefore, what Wiz is suggesting is, has Microsoft turned off token usage for those apps? Well, maybe what you should really be doing right now is looking for indicators of that. Looking for usage of those forged tokens and other IOCs that you can look up another logs. That's what they’re saying.

Tim CallanOkay. Fair enough. So obviously, this is a bit unusual story, and an important story, and we just wanted to share that update. I think if there are more meaningful updates to the story, we'll return to it again. And we're definitely going to keep our eye on it.

Jason SorokoYou got it, Tim. Hey, just final word, just because it's worth emphasizing is, folks, your OpenID usage with respect to JWT tokens, which is just the single sign on in general that's using signed JWT tokens, don't let the keys that are signing those JWT tokens ever get compromised because that's just bad news.

Stay informed with expert insights

Subscribe to Root Causes for engaging discussions on PKI, digital security, and best practices for protecting your organization's critical assets. Don’t miss an episode!