Below the OS: UEFI Scanning in Defender

Nic Fillingham: Hello, and welcome to Security Unlocked, a new podcast from Microsoft where we unlock insights from the latest in news and research from across Microsoft's security, engineering, and operations teams. I'm Nic Fillingham-

Natalia Godyla: And I'm Natalia Godyla. In each episode we'll discuss the latest stories from Microsoft Security, deep dive into the newest threat intel, research and data science.

Nic Fillingham: And profile some of the fascinating people working on artificial intelligence in Microsoft Security.

Natalia Godyla: And now, let's unlock the pod.

Natalia Godyla: Hello Nic. Welcome to Episode 24. How's it going with you today?

Nic Fillingham: Going well, thank you, Natalia. Yes, uh, welcome to you and welcome to listeners to Episode 24 of Security Unlocked. On today's podcast, we speak with Shweta Jha and Gowtham Reddy from the Microsoft Defender for Endpoint engineering team about capabilities in MDE to scan down into the UEFI layer. Now this is the third of three conversations we have that started back in Episode 11 with Nazmus Sakib where we talked about secure core PCs and, and firmware integrity. Then in Episode 14 we spoke with Peter Waxman about the Pluton processor and some of the new work that's happening there to imbed more security tech into sorta silicon onto the actual CPU die itself. And today we're sort of rounding that conversation out with Shweta and Gowtham to talk about how Microsoft Defender for Endpoint can now scan down or can scan down into the UEFI layer. You're gonna hear a bunch jargon, a bunch of technical terms like, I guess, UEFI. That's, we, we could start there.

Natalia Godyla: Yes. And UEFI is the Unified Extensible Firmware Interface, so it is the software interface that lies between an operating system and firmware, and is an evolution of BIOS. And we'll also talk about MosaicRegressor which, for those of you that don't know, is the second ever UEFI rootkit which was discovered in 2020, but was used in an attack against NGOs in 2019. And, and for me, the timeline is shocking, second ever in the past year. Normally we hear about the continuous increase of a certain type of attack over the years, and here we're just at the second ever.

Nic Fillingham: Yeah. It's a real interesting part of the conversation where we talk about the history of BIOS attacks, firmware attacks, UEFI attacks, and to learn that this has been sort of traditionally a pretty challenging area for attackers to, to breech and compromise. But, you know, Shweta and Gowtham have been, you know, very much ahead of the curve and, and being ahead of, of attackers in, in being able to develop these new capabilities to, from the operating system, scan down to the UEFI layer and look for malware, look for compromise. And it's a, it's a fascinating conversation. Again, it's sort of a completion of three episodes starting with Episode 11 and 14. So if you haven't listened to those, I recommend you add them to the queue. But I guess on with the pod.

Natalia Godyla: On with the pod.

Nic Fillingham: Welcome to the Security Unlocked podcast. Shweta Jha and Gowtham Reddy, welcome both of you. Thanks for being here.

Gowtham Reddy: Thank you.

Shweta Jha: Thank you so much for having us. We're so very excited.

Nic Fillingham: I'm very excited, too. Now this is gonna be the third conversation in a sort of a mini series that we're running here on the podcast. We started with Nazmus Sakib who introduced us to the idea of secure core PCs and we talked about some of the challenges of firmware integrity and keeping firmware safe. Then we spoke Peter Waxman in another episode to learn about Pluton, the history of, of that technology and sort of what's coming for the Pluton processor. And today we're actually gonna talk about some new capabilities, or newish as of 2020, in Defender to scan down into the UEFI layer. Before we jump into to all that, let's just do some introductions for the audience. Shweta if we could start with you. Who are you? What is your role? What do you do day-to-day at Microsoft? Tell us, what you like the audience to know about you?

Shweta Jha: Absolutely. Thank you, Nic. My name Shweta Jha. I am a program manager with Microsoft Defender for Endpoints, and I've been building security solutions features and products, and I'm super excited about it because security is the need today for our, uh, customers. And a few of the features that I built with my team were part of anti-tampering. Investment that we did, EDR block as part of be able to blocking and containment. And then we are gonna talk a lot about UEFI scanner. So pretty much around building security solution and features in this team and helping our customers.

Nic Fillingham: Fantastic. And, and Gowtham, welcome to the podcast. If you could also introduce yourself. Uh, tell us about your role. What does your day-to-day look like?

Gowtham Reddy: Hi. This is Gowtham Reddy. I'm an engineering manager in Microsoft Defender, uh, Endpoint. So before engineering manager, so I was working as an engineer in the same team for last six years. So I work on, uh, many of the rootkit technologies, the Defender, uh, has and, uh, the remediation technologies to remediate many of the malwares that are present on the system. I have been where I working on this fantastic team, developing like durable protection features that were, and compliment the ever changing malware fields.

Nic Fillingham: That's great. So, again, welcome to both of you. Thanks for your time. One of the things we do on the, uh, Security Unlocked podcast here is we, we don't necessarily cover the latest announcements. We, we sort of look back over the last sort of three to six months for interesting sort of technology, interesting advancements in, in security technology, and we bring experts on to, to talk about these new features and capabilities after them sort of being in the wild. Today we're talking about the UEFI scanning capabilities that are in Microsoft Defender, and there's a blog post that, that both of you helped author back in, in June of 2020, which feels like a decade ago, but I guess it's more like six or seven months. So I wondered if one of you might be able to just walk us through. What was that announcement made in that blog post? What was sort of the news? And then I think maybe if the other one or maybe just following, I'll, I'll leave it to how we, how we split this up. But what was announced back in June? And sort of what's happened since then? How have those new capabilities sort of rolled out and what are we seeing with customers actually using them?

Shweta Jha: So I, I guess I can get us started, and then I'll hand it over to Gowtham definitely to talk more on the technical details and the, the attacks that we see in the wild, and that's why we kind of built this UEFI scanner. So as you understand, this is a journey, right? We built a layered defense in that security solutions. And when we build any security solution, we need to make sure that we take a holistic approach. So if you look at the operating level of security solutions, we've been getting pretty great at operating level security solutions. And it's not only Microsoft. If you see other security providers as well, they have been doing great, too.

Shweta Jha: So what does that mean? It means that because the operating system level security solution is really great, it does making difficult for attackers to not get detected at that level. It's a constant battle, so they have been looking into other means where they can go into the system undetected, and that's where if you look at the data, you would find that in recent past the attacks across hardware and firmware level has been on the rise. So we built UEFI scanner keeping in mind that we should be able to detect those type of attacks, because those type of attacks are not only very dangerous, but often time they are not detected. They persist even if you reboot the system. So the nature of these type of attacks is very dangerous, and keeping that in mind, we decided to build UEFI scanner.

Gowtham Reddy: So I can add like why we did, uh, build the UEFI scanner. So because of the operating system security features that Microsoft is constantly working on, the bad guys are trying to go in, down and down in the layered architecture. And so some of the traits of the ia64 went onto the BIOS, tampering the BIOS and, uh, tampering the MBR, the master board required and, uh, VBR based bootkits. So Defender has evolved into that space of counting the MBR and, uh, detecting the bootkits and the boot time.

Gowtham Reddy: So as a logical evolution the bad guys are, uh, from the stage of Colonel to the MBR, MBR to the UEFI. So we were anticipating that this kind of evolution is quite possible and the UEFI implants were not very far. So that's the time we found the first UEFI implant called LoJax. So that was a triggering point when we completely committed to ourselves to expand our root kit technology, to detect any kind of rotates presence in the UV. So that was our core idea of expanding or rotating to the layer much below the operating system. So there were some challenges

Natalia Godyla: If you don't mind me jumping in, I had a question around that. So...

Gowtham Reddy: Mm-hmm (affirmative)

Natalia Godyla: ... the way you're framing it is that when we started to notice the threat landscape moved to this layer, we decided to invest in this type of technology. What about the technology itself? Had there always been this opportunity to tackle UEFI scanning, or is there something new that we're leveraging in order to solve this problem Now that might not have been around beforehand?

Gowtham Reddy: That's a good question. So there was always a chance to exploit the UEFI, but it's about the timing of the attackers to get at target this space because the rest of the platform and ecosystem is getting more and more secure. So the UEFI is not new. So it was there a decade ago, but the implants are new because of the advances in the operating system.

Nic Fillingham: So Gowtham, tell us about the LoJax attack that happened. Was it the first or it was one of the first detected compromises of the UEFI firmware? Can you tell us some more about, about that? If folks aren't familiar with it like me?

Gowtham Reddy: Mm-hmm (affirmative).So that definitely some theoretical researcher driven, before the LoJax, but the LoJax is a fast known exploitation instance where we know we found it in the wild. It is quite possible even before that a UEFI implant demonstrated in many of the black hat conferences, but those are theoretical in nature. So the research had access to the device and they demonstrated it. But LoJax's is the one where from operating system level. So a particular malware, I would say it as a root kit, which has tried to intrude from kernel mode to the UEFI, and they have installed a UEFI driver. So if we consider the operating system as a drivers, even the firmware itself had some drivers. So they were able to install a driver which actually in turn drops the another kernel mode driver, advanced operating system boots up. it's about the boot sequence.

Gowtham Reddy: So first the firmware starts running and it initializes all the system, and then it invokes operating system. So in the LoJax's case, after the firmware is completed, it has already dropped the kernel driver on the operating system, if it is not present. So that means by the end of the firmware sequence, so we have a presence of a kernel driver. And when that kernel driver starts, that is a user mode, malware starts, kicks in. So this keeps repeating even after you were re-install the wares, even if you change the hard disc, the same pattern will be fought. So that's how the LoJax's type work.

Nic Fillingham: And I wonder, do we know, what was the breakthrough that made LoJax possible? UEFI has been around for a while. UEFI for probably predates LoJax. And obviously before UEFI, there was sort of the more standard sort of BIOS that probably most folks are familiar with. Can we talk a little bit more about how LoJax came about and sort of what maybe changed or what the breakthrough was on the attacker side?

Gowtham Reddy: I would say that there were a couple of open source read-write drivers, which has a capability to access the firmware, using a special interface called SPI. SPI is a something called serial peripheral interest. So using the serial peripheral interface, any kernel driver can instruct the platform hardware layer to read and write any content in the flash. So I think like many of the security industry knows a driver called a read drive, everything, they call it as RWE. So this is the driver using which anybody can read any offset, any device memory, and write. I think this is, the prevalence of this kind of open source tools might be help attackers to develop this kind of ecosystem of all the sequence of the malware, the root kits.

Shweta Jha: In addition to what Gowtham said, definitely the work that researchers were doing in this space, it always starts with researcher trying to do something and then attackers trying to find other means. So here are the things. Attackers usually do exploit things that are not done in a right way. So in this case, for example, if there are certain configuration that you need to, or your partner needs to make sure that those are in place, for example, rewrite where you are not providing writing access, just the reading access, and so on.

Shweta Jha: So typically in all these type of attacks would see that misconfigured devices are exploited the most, and that misconfiguration happens at the time when the devices are getting built. So that is another factor why these attacks are very successful, because there are misconfigured devices, because while building the devices, somebody messed to configure it and right way. And if you look at the journey, that's where you have a secure core PC, which is designed be secured, making sure that the things that are needed to protect the computer against these types of attacks that are there out from the first day.

Natalia Godyla: So my question is about the application of this new technology. So I really appreciate you walking through that attacker workflow. So what type of signals is UEFI scanning, looking for? What is it using to enrich the context of the existing end point data?

Gowtham Reddy: That's a very good question. So basically the level of details that UEFI scanner can get is enormous. So this is the area where like the defender has a content scanning. So, uh, we have, uh, extended our content scanning to every file that is present inside the firmware. So this help the defender research to write any kind of content scanning signatures to detect any bad content. So that means in this case, if research knows any implant, so we have a capability to scan the 600 million devices to know if any of our customers have impacted with the specified malicious file.

Gowtham Reddy: And this is just one part of our UEFI scanner. And the other part of it is detecting any anomalous behavior inside the firmware. For example, in many of the supply chain attacks like Solarigate, it's quite possible that some of the OEMs channels were compromised and the deliver the firmware updates with the malicious modules in it.

Gowtham Reddy: So in this case, our UEFI scanner collects all the metadata about the new for- firmware update and we run heavy amount models in our cloud. And that will tell us if there is an unknown anomaly that exists in this particular firmware update. Instead of a known malware implant so that the UEFI scanner has the two capabilities. One is detecting a known malicious implant, and the other one is anomalous from where presence of a fax. So in this case, we act both ways.

Nic Fillingham: What does an anomaly look like in this context?

Gowtham Reddy: Anomalies look like, for example, if you have a firmware is a, firmware is a file system, like a typical drive. A presence of an driver file, probably a hedge P driver file or an unsigned driver file. On a Dell OEM is constrained to the anomaly. Because we have trained the model of all the known Dell firmwares with them, a ML model. So any new image with the unexpected file, it will be immediately flagged.

Nic Fillingham: And why is ML the sort of approach you've taken here versus sort of heuristics? I would have thought that there's a pretty limited set of content. They could make up sort of firmware and firmware instructions. Obviously, I don't know anything about this space, so I'll caveat that there, but, um, could you talk about why ML versus heuristics versus something else?

Gowtham Reddy: In the days of, uh, BIOS, so you are a expectation was right. The bast consists of a series of micro code,

Gowtham Reddy: ... which is, uh, very limited. And, uh, in the context of UEFI, you have a full file system, uh, which has, like, uh, thousands of files; individual files. And, uh, this causes... Uh, creates, uh, basically a huge amount of, uh, the vectors space, which to scan or to collect the metadata.

Gowtham Reddy: So it's not just simple collection of mecra- microcodes. It contains the drivers, it contains the services, it contains a lot of other things. It's a file system like NTFS.

Nic Fillingham: Got it. So because UEFI is, as you say, a file system as opposed to... What was BIOS? BIOS was not a file system? BIOS was, uh, sort of a discreet, sort of, low level executable?

Gowtham Reddy: Yeah, i- i- it is just a sequence of, uh, microcode instructions that will be run on the firmware. So basically, i- it has a s- uh, fi- se- set of microcodes.

Nic Fillingham: So the machine learning models that you reference, w- where are they running? Are some of them running locally? Are they all running in the Cloud? Is it a mixture of the two?

Gowtham Reddy: They're all running in the Cloud for now. So we have MDATP Cloud services where we run all this clo- uh, demo models. So our models are really very effective. So recently, we got in, uh, so- so, uh, the UEFI alert by, uh, mal- model. Apparently, it's a kind of, um, true positive because, um, there was a Microsoft engineer who was working on a hardware space.

Gowtham Reddy: So he take, uh, firmware. And he kept a developer driver and he flashed on his own device. And, uh, our UEFI scanner immediately caught it and we... the security administrator got an alert and there was an investigation happen. So we are pretty ready to catch any kind of such things now.

Natalia Godyla: So we all know it's a cat and mouse game with the threat actors. So what is the team anticipating in terms of how the actors will adjust their processes to evade this new UEFI scanning technology?

Gowtham Reddy: That's a good question. We're trying to validate something in a- a lower level of trust, the lower level of ring other than the kernel. So definitely, there is a chance that attacker can modify the firmware presence. Uh, he can spoof the content when defender tries to scan. So this is quite, uh, possible. But we are already working on mitigating that kind of an attacks.

Nic Fillingham: So now that this feature, these capabilities, have been live in the product for, uh, I guess over six months at this point, w- what have you learnt? What have you seen in the telemetry? What have you seen in the types of attacks and, I guess, even sort of false positives that have- have come through from- from this new, uh, capability?

Gowtham Reddy: Uh, that's a very good question. So we learnt a lot of things. The UEFI file system has never scanned before. So we got some false positives on the content that we scan but we immediately fine-tuned our signatures.

Gowtham Reddy: Back in... Six months before, when we published a blog, we only know the first UEFI known implant called LoJax but often we share... There was a second implant called Public. That's called MosaicRegressor and our UEFI scanner has well detected the MosaicRegressor implant. Uh, the- the telemetry count was small. So we did, uh, able to detect the mi- MosaicRegressor.

Nic Fillingham: So in this first six months, as well as the LoJax campaign, uh, what's the taxonomy here? How do we f- refer to it?

Gowtham Reddy: Uh, we can consider... W- we are, uh, tracking them as an UEFI implant malware or UEFI rootkit. So this is the category we are looking at. So right now, we have, uh, LoJax and we have a MosaicRegressor as, uh, two big families in this space.

Nic Fillingham: Big families. Got it.

Shweta Jha: Yeah, about MosaicRegressor, I wanted to add a little bit more just to complement what, uh, Gowtham mentioned, how powerful this tool is. And how powerful this particular feature is. So if you read through the MosaicRegressor, uh, breach, it was a nationwide targeted attack.

Shweta Jha: This was targeted for diplomats. And this attack, as Gowtham described, first they would insert one module. Uh, that one module would get undetected and then that module would try to do other stuff, like try to, uh, get in touch with command and control and get another, uh, module and so on.

Shweta Jha: So the entire c- chain is so very interesting. And I'm glad that we built this feature and we were able to detect it because it's so powerful. Most of the security solution, they're not able to detect because they don't have this, uh, such great capabilities.

Shweta Jha: But look at the way this attack was carried. It was pretty much targeted, pretty much nationwide for a few countries, originated from one country. So the sophistication level in the nature itself speaks for it and I'm glad that we, as in our product, we have this capability which can even, you know, unknown, first seen, it can detect those type of attacks as well.

Natalia Godyla: In the process of developing this new technology, where were there false starts? What techniques did you try but didn't work to solve this problem?

Shweta Jha: Little bit on the journey, right? We have been working on it. Um, so Gowtham explained about how we have rootkit, bootkit level and then we went to the UEFI site and we had to be extremely careful because it's, like, uh, it has a high integrity and high severity of going wrong.

Shweta Jha: So we had to be very careful making sure that the running system is not damaged and at this point, I'll hand it over to Gowtham because he can explain, in detail, each and every pieces that we took into consideration to making sure that our customers' device remain intact. So go ahead Gowtham.

Gowtham Reddy: Yeah. Thanks Shweta. So, uh, we have indeed explored, uh, many mechanisms like accessing the PCI space from the operating system itself, which we didn't continue to proceed because of some of the pushback from the kernel team to update the haul.

Gowtham Reddy: So actually, uh, to accessing any peripheral device from the PCI bus, there are a couple of complications because the peripherals have, uh, specific implementation of Reads and Writes, the bus Reads and Writes. So, uh, the approach we took was, uh, using the SBI interface, which is pretty much, kind of, an, uh, universal interface which is developed by Motorola by a long time ago.

Gowtham Reddy: So luckily, what worked in our favor was most of the Intel p- s- uh, chipsets, they support the SBI based access. So they support the SBI, uh, using which we can use the memory map mechanisms to access the PCI space.

Gowtham Reddy: So basically, here, what happened was instead of directly using the hardware primitives, we used, uh, software primitives because the chipsets are well supporting the SBI interface. So that's how we landed in our approach.

Nic Fillingham: I wanted to circle back to the use of machine learning here in- in solving this problem. How big are the signal sets that you're getting to train the model? How big is the model?

Nic Fillingham: Is the model that you use here, to detect anomalies in the firmware layer, is it as sophisticated and large as something as, like, looking for malware on endpoints? Or are we talking, like, a much sort of smaller more, sort of, n- nuance. No, that's not the right word. Sort of a smaller bespoke model?

Gowtham Reddy: Uh, I can take that question. So u- usually, uh, in the endpoint when- when applying the malware, um, in machine learning models, we heavily focus on the individual file properties, like file headers, file footers and some file p- properties and so on.

Gowtham Reddy: But UEFI case, we built a brand new machine learning model based on the properties of the UEFI image itself. So thanks to David, from our MDATP team. So he come up with a model where... which takes input signals as specific to the UEFI firmware image.

Gowtham Reddy: To give some examples, each firmware drive has a lot of GUIDs, called firmware GUIDs. And then they have some properties called, uh, file types and properties. Every property that we took was specific to the firmware. So they are not generic to the specific malware files that we see regular malware detections. So these are highly tailored to the signals from the UEFI firmware image.

Nic Fillingham: And were you able to reuse some of the anomaly detection

Nic Fillingham: Algorithms are purchased from other parts of the defender engineering org, or did you have to sort of build a brand new model and a brand new way to detect anomalies?

Shweta Jha: Yeah. So, we definitely used our existing infrastructure. So, as you know? Uh, we have a massive backend system where we get tons of signals and we run tons and tons of AI and ML model to detect the anomalies and to detect the new trends and so on. So, as Gordon was talking, for this particular UV, AI and ML model, even though where we had to tweak it to make sure that we capture the inputs that are UV specific, the models were used, the pipeline to collect the data that were used and the channel where we surface it to our customers. So, if you look at the end to end story, the way we do things are we detect, we remediate, and we also notify to our SecOps that, "Hey, these are the things that happened in your environment." And that goes in the form of alerts or incidents and so on. So, we used exactly same infrastructure, same pipeline, but specific to UV.

Natalia Godyla: So, I know a little earlier in this episode, we talked about the learnings after being in market. What about the impact to SecOps teams? Do we have any early numbers to talk through about what this has raised for our customers?

Shweta Jha: That's a great question. We do see here and there, though the number is not pretty high on the implant, but we do see in numbers there, like, as Gordon mentioned about a mosaic regression. We did find that and there are few others also. But I think the most important aspect of this unique feature is that, just a little bit forget about this feature and see that today's world, today, there is no UV scanner, the security admins or SecOps, they, they don't know what is happening at this level. They have tons of device in their organization. And these devices are at this level is completely black box for them, because they don't know whether it is configured well. They don't know if there are implants there. They don't know if there are vulnerabilities that could be exploited.

Shweta Jha: So, there's the power of this UV scanner. One is, you know, so we, we built a solution keeping in mind that we will not only detect, we will bring these, these things where they don't have visibility today to understand what is going on. So, the focus area, and then the objective that we have is to detect the implant, either using the heuristic detection or the AI, ML but also read through each and every configuration that are happening at this level and the vulnerabilities that exist at this level and bring that to the, SecOps attention, so that when they look at it, they can take appropriate action to remediate it. So, that's the next step. And that is the work right now, we are currently doing. We do not have, in the form of report, we do see it in our data and we want to make sure that these are available to our SecOps. But just to tell you, there are tons and tons of misconfigured device out there. And it's, it's a little tricky.

Gowtham Reddy: To add more about the misconfiguration. So, it's about like the PC settings, like a UV, the BIOS read-write or whatever the settings we'll use to see in when we go to the BIOS in the past. So, the UV must be configured well to support the secure boot, to use the TPM and to use any of the hardware provided features, it must be configured well. If it is misconfigured, you won't get any protection. So, if you have a helmet in your backseat, when you are driving, it won't help you. So, you had to keep it on your head.

Shweta Jha: (laughs). That's a great analogy.

Nic Fillingham: That leads us to, what is the guidance here for Sec admins and security teams out there? How do they enable this functionality? Is it on by default in, in certain places? What do we need to do to make sure that, that customers are getting the full protection from this capability?

Shweta Jha: So, uh, this, this feature is enabled by default on all the devices. Um, we made sure that this is available. And the great news is that it is not only, you know, Windows 10, it is available for servers, download as well. So, that's the power that we have in our solution. Ultimately, if you look at what is the future that are gonna look like, secure core PC is the future we should be heading towards. But because enterprises and customers are not there yet, uh, we have UV scanner to compliment it. The other thing, if we have to talk about the futuristic roadmap, right now, we built the scanner for UV, but there are other network devices like network adapter and things like that. There is a scope to extend these types of capability to those devices as well, because those, there is a possibility to get those devices exploited too. So, that's something we are considering to work through.

Nic Fillingham: Got it. So, just to confirm there, so, this new capability is on by default in any device that is being protected by the defender service. Is, is it, is it as simple as that or is there sort of more to it?

Shweta Jha: Yes. Any device which is having defender antivirus running.

Natalia Godyla: Thank you for that. That was super helpful. And thank you both for joining us on the show today.

Shweta Jha: Thank you, Natalia. It was pleasure to be here and talking with our customers. Thank you so much for hosting us.

Gowtham Reddy: Thank you Natalia and Nick for hosting us. So, it's been wonderful time talking to you about UV scanner. Thank you so much.

Nic Fillingham: Thank you both for your time. Thanks for bringing great innovation to the security space.

Shweta Jha: Absolutely. It's a constant journey and we're on it.

Natalia Godyla: Well, we had a great time unlocking insights into security from research to artificial intelligence. Keep an eye out for our next episode.

Nic Fillingham: And don't forget to tweet us @msftsecurity or email us @securityunlocked@microsoft.com with topics you'd like to hear on a future episode. Until then, stay safe.

Natalia Godyla: Stay secure.