Security Unlocked

Share

Below the OS: UEFI Scanning in Defender

Ep. 24

All of us have seen – or at least, are familiar with – the antics of Tom and Jerry or Road Runner and Wile E. Coyote. In each one the coyote or the cat set up these elaborate plans to sabotage their foe, but time and time again, the nimble mouse and the speedy bird are able to outsmart their attackers.  


In our third episode discussing Ensuring Firmware Security, hosts Nic Fillingham and Natalia Godyla speak with Shweta Jha and Gowtham Reddy about developing the tools that allow for them to stay one step ahead of cybercriminals in the cat & mouse game that is cyber security.  

  

In this Episode You Will Learn: 

The new capabilities within Microsoft Defender to scan the Unified Extensible Firmware Interface (UEFI)

How the LoJax attack compromised UEFI firmware

How UEFI scanning emerged as a capability  


Some Questions that We Ask: 

Has UEFI scanning always been possible? 

What types of signals is UEFI scanning searching for? 

What are the ways bad actors may adjust to avoid UEFI scanning? 


Resources:  

Shweta Jha’s LinkedIn: 

https://www.linkedin.com/in/jhashweta/ 


Gowtham Reddy’s LinkedIn: 

https://www.linkedin.com/in/gowtham-animi/ 


Defender Blog Post: 

https://www.microsoft.com/security/blog/2020/06/17/uefi-scanner-brings-microsoft-defender-atp-protection-to-a-new-level/ 


Nic Fillingham’s LinkedIn: 

https://www.linkedin.com/in/nicfill/ 


Natalia Godyla’s LinkedIn: 

https://www.linkedin.com/in/nataliagodyla/ 


Related:

Security Unlocked: CISO Series with Bret Arsenault

https://SecurityUnlockedCISOSeries.com


Transcript

[Full transcript can be found at https://aka.ms/SecurityUnlockedEp24]


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.

More Episodes

6/2/2021

Pearls of Wisdom in the Security Signals Report

Ep. 30
It’s our 30thepisode! And in keeping with the traditional anniversary gift guide, the 30thanniversary means a gift of pearls.Sofrom us to you, dear listener, we’ve got an episode with somepearlsofwisdom!On today’s episode, hostsNic FillinghamandNataliaGodylabringback returning champion,Nazmus Sakib, to take us through the newSecurity Signals Report. Sakib walks us through why the reportwasdoneand then helps us understand the findings and what they mean for security.In This Episode You Will Learn:How pervasive firmware is in our everyday livesWhy many people were vulnerable to firmware attacksHow companies are spending the money they allocate towards digitalprotectionSome Questions We Ask:What was the hypothesis going into the Security Signals Report?How do we protect ourselves from vulnerabilities that don’t exist yet?Wereany of the findings from the report unexpected?ResourcesNazmusSakib’sLinkedIn:https://www.linkedin.com/in/nazmus-sakib-5aa8a6123/Security Signals Report:https://www.microsoft.com/security/blog/2021/03/30/new-security-signals-study-shows-firmware-attacks-on-the-rise-heres-how-microsoft-is-working-to-help-eliminate-this-entire-class-of-threats/Nic Fillingham’sLinkedIn:https://www.linkedin.com/in/nicfill/NataliaGodyla’sLinkedIn:https://www.linkedin.com/in/nataliagodyla/Microsoft Security Blog:https://www.microsoft.com/security/blog/Related:Security Unlocked: CISO Series with Bret Arsenaulthttps://SecurityUnlockedCISOSeries.com
5/26/2021

Securing Hybrid Work: Venki Krishnababu, lululemon

Ep. 29
On this week’s Security Unlocked we’re featuring for the second and finaltime,a special crossover episode of our sister-podcast, Security Unlocked: CISO Series with Bret Arsenault.Lululemon has been on the forefront of athleisure wear since its founding in 1998,but while many of its customers look atitexclusively as a fashionbrand,ata deeper level thisfashion empire is bolstered by a well thought out and maintained digital infrastructure that relies on ahard workingteam to run it.On today’s episode, Microsoft CISO Bret Arsenault sits down with VenkiKrishnababu, SVP of Global Technology Services at Lululemon.Theydiscuss the waysin whichtechnology plays into the brand, how Venkileada seamless transition into the remote work caused by the pandemic, and how he’s using the experiences of the past year to influence future growth in the company.In This Episode You Will Learn:Why Venkifeels sopassionatelyabout leading withempathyWhy Venki saw moving to remote work as only the tip of the iceberg; and how he handled whatlaidbelow.Specific tools and practices that haveleadto Venki’ssuccessSome Questions We Ask:What is the biggest lesson learned during the pandemic?How doesone facilitate effective management during this time?Howdoes Lululemonviewthe future of in-person versus remote work?Resources:VenkiKrishnababu’sLinkedIn:https://www.linkedin.com/in/vkrishnababu/Brett Arsenault’s LinkedIn:https://www.linkedin.com/in/bret-arsenault-97593b60/Nic Fillingham’sLinkedIn:https://www.linkedin.com/in/nicfill/NataliaGodyla’sLinkedIn:https://www.linkedin.com/in/nataliagodyla/Microsoft Security Blog:https://www.microsoft.com/security/blog/Related:Security Unlocked: CISO Series with Bret Arsenaulthttps://SecurityUnlockedCISOSeries.com
5/19/2021

Contact Us; Phish You!

Ep. 28
Threat actors arepeskyand, once again,they’reup to no good.A newmethodologyhas schemers compromising onlineformswhere userssubmittheir information like their names, email addresses,and, depending on the type of site, some queries relating totheir life.This new methodindicatesthat the attackers have figured out away around the CAPTCHA’s that have been making us all provewe’renot robotsbyidentifyingfire hydrantssince 1997.Andwhat’smore,we’renot quite surehowthey’vedone it.In this episode, hosts NataliaGodylaand Nic Fillingham sit down with Microsoftthreat analyst, Emily Hacker, to discuss what’s going on behind the scenes as Microsoft begins todigintothis new threat and sort through how best to stop it.In This Episode You Will Learn:Why this attack seems to be more effective against specificprofessionals.Why this new method of attack has a high rate ofsuccess.How to better prepare yourself for this method of attackSome Questions We Ask:What is the endgame for these attacks?What are we doing to protect againstIceIDin these attacks?Are we in need of a more advanced replacementforCAPTCHA?Resources:Emily Hacker:https://www.linkedin.com/in/emilydhacker/Investigating a Unique ‘Form’ of Email Delivery forIcedIDMalwarehttps://www.microsoft.com/security/blog/2021/04/09/investigating-a-unique-form-of-email-delivery-for-icedid-malware/Nic Fillingham’sLinkedIn:https://www.linkedin.com/in/nicfill/NataliaGodyla’sLinkedIn:https://www.linkedin.com/in/nataliagodyla/Microsoft Security Blog:https://www.microsoft.com/security/blog/Related:Security Unlocked: CISO Series with Bret Arsenaulthttps://SecurityUnlockedCISOSeries.comTranscript[Full transcript can be found athttps://aka.ms/SecurityUnlockedEp26]Nic Fillingham: (00:08)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 security, engineering and operations teams. I'm Nick Fillingham.Natalia Godyla: (00:20)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: (00:30)And profile some of the fascinating people working on artificial intelligence in Microsoft Security.Natalia Godyla: (00:36)And now, let's unlock the pod.Nic Fillingham: (00:40)Hello, the internet. Hello, listeners. Welcome to episode 28 of Security Unlocked. Nic and Natalia back with you once again for a, a regular, uh, episode of the podcast. Natalia, how are you?Natalia Godyla: (00:50)Hi, Nic. I'm doing well. I'm stoked to have Emily Hacker, a threat analyst at Microsoft back on the show today.Nic Fillingham: (00:58)Yes, Emily is back on the podcast discussing a blog that she co-authored with Justin Carroll, another return champ here on the podcast, called Investigating a Unique Form of Email Delivery for IcedID Malware, the emphasis is on form was, uh, due to the sort of word play there. That's from April 9th. Natalia, TLDR, here. What's, what's Emily talking about in this blog?Natalia Godyla: (01:19)In this blog she's talking about how attackers are delivering IcedID malware through websites contact submission forms by impersonating artists who claim that the companies use their artwork illegally. It's a new take targeting the person managing the submission form.Nic Fillingham: (01:34)Yeah, it's fascinating. The attackers here don't need to go and, you know, buy or steal email lists. They don't need to spin up, uh, you know, any e- email infrastructure or get access to botnets. They're, they're really just finding websites that have a contact as form. Many do, and they are evading CAPTCHA here, and we talk about that with, with, with, uh, Emily about they're somehow getting around the, the CAPTCHA technology to try and weed out automation. But they are getting around that which sort of an interesting part of the conversation.Nic Fillingham: (02:03)Before we get into that conversation, though, a reminder to Security Unlock listeners that we have a new podcast. We just launched a new podcast in partnership with the CyberWire. It is Security Unlocked: CISO Series with Bret Arsenault. Bret Arsenault is the chief information security officer, the CISO, for Microsoft, and we've partnered with him and his team, uh, as well as the CyberWire, to create a brand new podcast series where Bret gets to chat with security and technology leaders at Microsoft as well as some of his CISO peers across the industry. Fantastic conversations into some of the biggest challenges in cyber security today, some of the strategies that these big, big organizations are, are undertaking, including Microsoft, and some practical guidance that really is gonna mirror the things that are being done by security teams here at Microsoft and are some of Microsoft's biggest customers.Nic Fillingham: (02:52)So, I urge you all to, uh, go check that one out. You can find it at the CyberWire. You can also go to www.securityunlockedcisoseries.com, and that's CISO as in C-I-S-O. CISO or CISO, if you're across the pond, securityunlockedcisoseries.com, but for now, on with the pod.Natalia Godyla: (03:12)On with the pod.Nic Fillingham: (03:18)Welcome back to the Security Unlocked Podcast. Emily Hacker, thanks for joining us.Emily Hacker: (03:22)Thank you for having me again.Nic Fillingham: (03:24)Emily, you are, uh, coming back to the podcast. You're a returning champion. Uh, this is, I think your, your second appearance and you're here-Emily Hacker: (03:30)Yes, it is.Nic Fillingham: (03:30)... on behalf of your colleague, uh, Justin Carroll, who has, has also been on multiple times. The two of you collaborated on a blog post from April the 9th, 2021, called Investigating a Unique Form-Emily Hacker: (03:43)(laughs)Nic Fillingham: (03:43)... in, uh, "Form", of email delivery for IcedID malware. The form bit is a pun, is a play on words.Emily Hacker: (03:51)Mm-hmm (affirmative).Nic Fillingham: (03:51)I- is it not?Emily Hacker: (03:53)Oh, it definitely is. Yeah.Nic Fillingham: (03:54)(laughs) I'm glad I picked up on that, which is a, you know, fascinating, uh, campaign that you've uncovered, the two of you uncovered and you wrote about it on the blog post. Before we jump into that, quick recap, please, if you could just reintroduce yourself to the audience. Uh, what, what do you do? What's your day-to-day look like? Who do you work with?Emily Hacker: (04:09)Yeah, definitely. So, I am a threat intelligence analyst, and I'm on the Threat Intelligence Global Engagement and Response team here at Microsoft. And, I am specifically focused on mostly email-based threats, and, as you mentioned on this blog I collaborate with my coworker, Justin Carroll, who is more specifically focused on end-point threats, which is why we collaborated on this particular blog and the particular investigation, because it has both aspects. So, I spend a lot of my time investigating both credential phishing, but also malicious emails that are delivering malware, such as the ones in this case. And also business email, compromise type scam emails.Nic Fillingham: (04:48)Got it. And so readers of the Microsoft Security Blog, listeners of Security Unlocked Podcast will know that on a regular basis, your team, and then other, uh, threat intelligence teams from across Microsoft, will publish their findings of, of new campaigns and new techniques on the blog. And then we, we try and bring those authors onto the podcast to tell us about what they found that's what's happened in this blog. Um, the two of you uncovered a new, a unique way of attackers to deliver the IcedID malware. Can you walk us through this, this campaign and this technique that you, you both uncovered?Emily Hacker: (05:21)Yeah, definitely. So this one was really fun because as I mentioned, it evolved both email and endpoint. So this one was, as you mentioned, it was delivering IcedID. So we initially found the IcedID on the endpoint and looking at how this was getting onto various endpoints. We identified that it was coming from Outlook, which means it's coming from email. So we can't see too much in terms of the email itself from the endpoint, we can just see that it came from Outlook, but given the network connections that the affected machines were making directly after accessing Outlook, I was able to find the emails in our system that contains emails that have been submitted by user 'cause either reported to junk or reported as phish or reported as a false positive, if they think it's not a phish. And so that's where I was actually able to see the email itself and determined that there was some nefarious activity going on here.Emily Hacker: (06:20)So the emails in this case were really interesting in that they're not actually the attacker sending an email to a victim, which is what we normally see. So normally the attacker will either, you know, compromise a bunch of senders and send out emails that way, which is what we've seen a lot in a lot of other malware or they'll create their own attacker infrastructure and send emails directly that way. In this case, the attackers were abusing the contact forms on the websites. So if you are visiting a company's website and you're trying to contact them a lot of times, they're not going to just have a page where they offer up their emails or their phone numbers. And you have to fill in that form, which feels like it goes into the void sometimes. And you don't actually know who it went to in this case, the, the attackers were abusing hundreds of these contact forms, not just targeting any specific company.Emily Hacker: (07:08)And another thing that was unique about this is that for some of the affected companies that we had observed, I went and looked at their websites and their contact form does require a CAPTCHA. So it does appear that the attackers in this case have automated the filling out of these contact forms. And that they've automated a way around these CAPTCHAs, just given the, the sheer volume of these emails I'm seeing. This is a good way of doing this because for the attacker, this is a much more high fidelity method of contacting these companies because they don't have to worry about having an incorrect email address if they have gotten a list off of like Pastebin or a list, you know, they purchased a list perhaps from another criminal. Emily Hacker: (07:52)A lot of times in those cases, if they're emailing directly, there's gonna be some, some false emails in those lists that just don't get delivered. With the contact form, they're designed to be delivered. So it's gonna give the attacker a higher chance of success in terms of being delivered to a real inbox.Natalia Godyla: (08:11)And so when we, we talk about the progression of the attack, they're automating this process of submitting to these contact forms. What are they submitting in the form? What is the, and what is the end goal? So there's malware somewhere in their-Emily Hacker: (08:27)Mh-mm-hmm (affirmative).Natalia Godyla: (08:27)... response. What next?Emily Hacker: (08:29)Yeah. It's a really good question. So the emails or rather the contact form submissions themselves, they're all containing a, a lore. So the contents themselves are lore that the attacker is pretending to be a, um, artist, a photographer, and illustrator, something along those lines. There's a handful of different jobs that they're pretending to be. And they are claiming that the company that they are contacting has used an image that belongs to the artist, illustrator, photographer on their website without permission. And so the attacker is saying, "You used my art without permission. I'm going to sue you if you don't take this down, if you wanna know what aren't talking about, click on this link and it'll show you the exact art that I'm talking about or the exact photo." What have you, all of the emails were virtually identical in terms of the content and the lore.Emily Hacker: (09:21)The attacker was using a bunch of different fake emails. So when you fill out a contact form, you have to put your email so the, the company can contact you, I guess, in reply, if they need to. And the attackers, almost every single email that I looked at had a different fake attacker email, but they did all follow a really consistent pattern in terms of the, the name, Mel and variations on that name. So they had like Melanie, I saw like Molina, like I said, there was hundreds of them. So the email would be Mel and then something relating to photography or illustration or art, just to add a little bit more credence, I think to their, to their lore. It made it look like the email address was actually associated with a real photographer. The, the attacker had no need to actually register or create any of those emails because they weren't sending from those emails. They were sending from the contact form. So it made it a lot easier for the attacker to appear legitimate without having to go through the trouble of creating legitimate emails. Emily Hacker: (10:16)And then the, um, the email itself from the recipients view would appear other than the fact that it felt fishy, at least to me, but, you know, I literally do this for a living. So maybe just everything feels fishy to me. Other than that, the email itself is going to appear totally legitimate because since it's coming through the contact form, it's not going to be from an email address. They don't recognize because a lot of times these contact forms are set up in a way where it'll send from the recipient's domain. So for example, a contact form, I don't know if this is how this works, but just as an example at Microsoft might actually send from Microsoft.com or the other large percentage of these that I saw were sent from the contact form hosting provider. So there are a lot of providers that host is kind of content for companies. And so the emails would be coming from those known email addresses and the emails themselves are gonna contain all of the expected fields, all in all. It's basically a legitimate email other than the fact that it's malicious.Nic Fillingham: (11:17)And, and just reading through the sample email that you, that you have in the blog post here, like sort of grammatically speaking it's, it reads very legitimately like, the-Emily Hacker: (11:26)Mh-mm-hmm (affirmative).Nic Fillingham: (11:27)... you know, the s- the, the grammar and the spelling is, it's colloquial, but it's, but it seems, you know, pretty legitimate. The idea of a photographer, a freelance photographer, stumbling upon their images being used without permission. You know, you hear stories of that happening. That seems to be somewhat plausible, not knowing how to contact the, the infringing organization. And then therefore going to the generic contact us form like this all, this all seems quite plausible. Emily Hacker: (11:52)And, definitely. And it's als one of those situations where even though, like I said, I do this for a living, so I read this and I was like, there's no way that's legit. But if my job was to be responsible for that email inbox, where stuff like this came in, it would be hard for me to weigh the consequences of like, is it more likely that this is like a malicious email? Or is it yeah. Is it possible that this is legit? And if I ignore it, my company is gonna get sued. Like, I feel like that kind of would give the recipient that, that weird spot of being like, "I don't want to infect the company with malware, or, you know, I don't wanna click on a phishing link if that's what this is, but also if I don't and then we get sued, is it my fault?"Emily Hacker: (12:33)I just, I, I feel for the recipient. So I, I understand why people would be clicking on this one and infecting themselves. And speaking of clicking on that is the other thing that's included in this email. So that was the last bit of this email that turns us from just being weird/legitimate, to totally malicious. All of the emails contain a link. And, um, the links themselves are also abusing legitimate infrastructure. So that's, uh, the next bit of abused, legitimate infrastructure that just adds that next bit of like believability if that's a word to this campaign.Nic Fillingham: (13:05)It is a word.Emily Hacker: (13:06)Okay, good believability. Is that the, the links, you know, we're, if you don't work insecurity, and even if you do work in security, we're all kind of trained like, "Oh, check the links, hover over the links and make sure it's going somewhere that you expect and make sure it's not going to like bad site dot bad, dot bad or something," you know, but these don't do that. All of the emails contained a sites.google.comm link. And I've looked at literally hundreds of these, and they all contain, um, a different URL, but the same sites.google.com domain. If you click on the link, when you receive the email, it'll take you actually to a legitimate Google authentication page that'll ask you to log in with your Google credentials, which again, every step along the way of this, of the email portion of this, of this attack, the attacker just took extra steps to make it seem as real as possible, or to almost like every piece of security advice. Emily Hacker: (14:01)I feel like they did that thing. So it seemed more legitimate because it's not a phishing page. It's not like a fake Google page that's stealing your credentials. It's a real where you would log in with your real Google credentials. Another thing that this does outside of just adding an air of legitimacy to the emails, it also can make it difficult for some security automation products. So a product that would be looking at emails and detonating the link to see if they're malicious and this case, it would detonate the link and it would land on, you know, a real Google authentication page. And in some cases it may not be able to authenticate. And then it would just mark these as good, because it would see what it expected to see. So, outside of just seeming legit, it also makes, you know, security products make this think it's more legit as well. But from there, the, uh, user would be redirected through a series of attacker own domains and would eventually download a zip file, which if they unzipped, they would find the IcedID payload.Emily Hacker: (15:06)So in this case, it's delivering IcedID, although this technique could be used to deliver other stuff as well, but it's not necessarily surprising that it's delivering IcedID right now, because pretty much everything I feel like I'm seeing lately as I study. And I don't think I'm alone in that there's murmurings that IcedID might be replacing Emotets now that you Emotet has been taken down in terms of being, you know, the annoyingly present malware. (laughs) So this is just one of many delivery methods that we've seen for IcedID malware lately. It's certainly in my opinion, one of the more interesting ones, because in the past, we've seen IcedID delivered a lot via email, but, um, just delivered via, you know, the normal type of malicious email if you will, with a compromised email sending with a, a zip attachment, this is much more interesting.Emily Hacker: (15:56)But in this case, if the user downloaded the payload, the payload would actually do many things. So in this case, it was looking for machine information. It was looking to see what kind of security tools were in place to see what kind of antivirus the machine was running. It was getting IP and system information. It was getting, you know, domain information and also looking to access credentials that might be stored in your browser. And on top of that, it was also dropping Cobalt Strike, which is another fun tool that we see used in every single incident lately. It feels like, um, which means that this can give attacker full control of a compromised device.Natalia Godyla: (16:38)So, what are we doing to help protect customers against IcedID? In the blog you stated that we are partnering with a couple of organizations, as well as working with Google.Emily Hacker: (16:52)Yes. So we have notified Google of this activity because it is obviously abusing some of their infrastructure in terms of the sites at Google.com. And they seem to be doing a pretty good job in terms of finding these and taking them down pretty quickly. A lot of times that I'll see new emails come in, I'll go to, you know, click on the link and see what it's doing. And the site will already be taken down, which is good. However, the thing about security is that a lot of times we were playing Catch Up or like, Whack-A-Mole, where they're always just gonna be a step ahead of us because we can't pre block everything that they're going to do. So this is still, um, something that we're also trying to keep an eye on from, from the delivery side as well. Emily Hacker: (17:34)Um, one thing to note is that since these are coming from legitimate emails that are expected is that I have seen a fair bit like, uh, a few of these, uh, actually, um, where the, the customers have their environment configured in a way where even if we mark it as phish, it still ends up delivered. So they have a, what is like a mail flow rule that might be like allow anything from our contact form, which makes sense, because they wouldn't wanna be blocking legitimate requests from co- from customers in their contact form. So with that in mind, we also wanna be looking at this from the endpoint. And so we have also written a few rules to identify the behaviors associated with the particular IcedID campaign. Emily Hacker: (18:16)And it will notify users if the, the behaviors are seen on their machine, just in case, you know, they have a mail flow rule that has allowed the email through, or just in case the attackers change their tactics in the email, and it didn't hit on our rule anymore or something, and a couple slipped through. Then we would still identify this on the endpoint and not to mention those behaviors that the rules are hitting on are before the actual IcedID payload is delivered. So if everything went wrong in the email got delivered and Google hadn't taken the site down yet, and the behavioral rule missed, then the payload itself is detected as I study by our antivirus. So there's a lot in the way of protections going in place for this campaign.Nic Fillingham: (18:55)Emily, I, I wanna be sort of pretty clear here with, with folks listening to the podcast. So, you know, you've, you've mentioned the, the sites.google.com a, a couple of times, and really, you're not, you're not saying that Google has been compromised or the infrastructure is compromised simply that these attackers have, uh, have come up with a, a, you know, pretty potentially clever way of evading some of the detections that Google, uh, undoubtedly runs to abuse their, their hosting services, but they could just evasively has been targeting OneDrive or-Emily Hacker: (19:25)Mh-mm-hmm (affirmative).Nic Fillingham: (19:25)... some other cloud storage.Emily Hacker: (19:25)That's correct. And we do see, you know, attackers abusing our own infrastructure. We've seen them abusing OneDrive, we've seen them abusing SharePoint. And at Microsoft, we have teams, including my team devoted to finding when that's occurring and remediating it. And I'm sure that Google does too. And like I said, they're doing a pretty done a good job of it. By the time I get to a lot of these sites, they're already down. But as I mentioned, security is, is a game of Whack-A-Mole. And so for, from Google point of view, I don't envy the position they're in because I've seen, like I mentioned hundreds upon hundreds of these emails and each one is a using a unique link. So they can't just outright block this from occurring because the attacker will just go and create another one.Natalia Godyla: (20:05)So I have a question that's related to our earlier discussion. You, you mentioned that they're evading the CAPTCHA. I thought that the CAPTCHA was one of the mechanisms in place to reduce spam. Emily Hacker: (20:19)Mh-mm-hmm (affirmative).Natalia Godyla: (20:19)So how is it doing that? Does this also indicate that we're coming to a point where we need to have to evolve the mechanisms on the forms to be a little bit more sophisticated than CAPTCHA?Emily Hacker: (20:33)I'm not entirely sure how the attackers are doing this because I don't know what automation they're using. So I can't see from their end, how they're evading the CAPTCHA. I can just see that some of the websites that I know that they have abused have a CAPTCHA in place. I'm not entirely sure.Nic Fillingham: (20:52)Emily is that possible do you think that one of the reasons why CAPTCHA is being invaded. And we talked earlier about how the, sort of the grammar of these mails is actually quite sophisticated. Is it possible? This is, this is a hands on keyboard manual attack? That there's actually not a lot of automation or maybe any automation. And so this is actually humans or a human going through, and they're evading CAPTCHA because they're actually humans and not an automated script?Emily Hacker: (21:17)There was another blog that was released about a similar campaign that was using the abusing of the contact forms and actually using a very similar lore with the illustrators and the, the legal Gotcha type thing and using sites.google.com. That was actually, it was very well written and it was released by Cisco Talos at the end of last year, um, at the end of 2020. So I focused a lot on the email side of this and what the emails themselves looked like and how we could stop these emails from happening. And then also what was happening upon clicks over that, like I said, we could see what was happening on the endpoint and get these to stop. Emily Hacker: (21:55)This blog actually focused a lot more on the technical aspect of what was being delivered, but also how it was being delivered. And one thing that they noted here was that they were able to see that the submissions were performed in an automated mechanism. So Cisco Talos was able to see that these are indeed automated. I suspected that they were automated based on the sheer volume, but I Talos is very good. They're very good intelligence organization. And I felt confident upon reading their blog that this was indeed automated, how it's being captured though, I still don't know.Natalia Godyla: (22:35)What's next for your research on IcedID? Does this round out your team's efforts in understanding this particular threat, or are, are you now continuing to review the emails, understand more of the attack?Emily Hacker: (22:52)So this is certainly not the end for IcedID. Through their Microsoft Security Intelligence, Twitter account. I put out my team and I put out a tweet just a couple of weeks ago, about four different IcedID campaigns that we were seeing all at the same time. I do believe this was one of them. They don't even seem related. There was one that was emails that contained, um, zip files. There was one that contained emails that contained password protected zip files that was targeting specifically Italian companies. There was this one, and then there was one that was, um, pretending to be Zoom actually. And that was even a couple of weeks ago. So there's gonna be more since then. So it's something that, like I mentioned briefly earlier, IcedID almost feels to be kind of, it feels a little bit like people are calling it like a, the next wave of replacement after Emotech are taken down. Emily Hacker: (23:43)And I don't know necessarily that that's true. I don't know that this will be the new Emotech so to speak, Emotech was Emotech And IcedID is IcedID but it does certainly feel like I've been seeing it a lot more lately. A lot of different attackers seem to be using it and therefore it's being delivered in different ways. So I think that it's gonna be one that my team is tracking for awhile, just by nature of different attackers using it, different delivery mechanisms. And it'll be, it'll be fun to see where this goes.Nic Fillingham: (24:13)What is it about this campaign or about this particular technique that makes it your Moby Dick-Emily Hacker: (24:17)(laughs) Nic Fillingham: (24:17)... if I may use the analogy.Emily Hacker: (24:20)I don't know. I've been thinking about that. And I think it has to do with the fact that it is so, like, it just feels like a low blow. I don't know. I think that's literally it like they're abusing the company's infrastructure. They're sending it to like people whose job is to make sure that their companies are okay. They're sending a fake legal threat. They're using legit Google sites. They're using a legit Google authentication, and then they're downloading IcedID. Like, can you at least have the decency, descend to crappy like unprotected zip attachment so that-Nic Fillingham: (24:49)(laughs)Emily Hacker: (24:49)... we at least know you're malicious, like, come on. It's just for some reason it, I don't know if it's just 'cause it's different or if it's because I'm thinking back to like my day before security. And I, if I saw this email as this one that I would fall for, like maybe. And so I think that there's just something about that and about the, the fact that it's making it harder to, to fully scope and to really block, because we don't want to block legitimate contact emails from being delivered to these companies. And obviously they don't want that either. So I think that's it.Nic Fillingham: (25:22)What is your guidance to customers? You know, I'm a security person working at my company and I wanna go run this query. If I run this, I feel like I'm gonna get a ton of results. What do I do from there?Emily Hacker: (25:33)That's a good question. So this is an advanced hunting query, which can be used in the Microsoft Security portal. And it's written in advanced hunting query language. So if a customer has access to that portal, they can just copy and paste and search, but you're right. It is written fairly generically to a point where if you don't have, you know, advanced hunting, you can still read this and search and whatever methodology, whatever, you know, searching capabilities you do have, you would just have to probably rewrite it. But what this one is doing the top one, 'cause I, I have two of them written here. The first one is looking specifically at the email itself. So that rejects that's written there is the, um, site.google.com.Emily Hacker: (26:16)All of the emails that we have seen associated with this have matched on that rejects. There was this morning, like I said, I was talking to a different team that was also looking into this and I'm trying to identify if she found, um, a third pattern, if she did, I will update the, um, AHQ and we have, we can post AHQ publicly on the Microsoft advanced hunting query, get hub repo, which means that customers can find them if we, if we change them later and I'll be doing that if that's the case, but point being this rejects, basically it takes the very long, full URL of this site.google.com and matches on the parts that are fairly specific to this email.Emily Hacker: (27:02)So they all contain, you know, some of them contain ID, some of them don't, but they all contain that like nine characters, they all contain view. It's just certain parts of the URL that we're seeing consistently. And that's definitely not by itself going to bubble up just the right emails, which is why have it joined on the email events there. And from there, the, I have instructed the users to replace the following query with the subject line generated by their own contacts, their own websites contact submission form. What I have in there are just a few sample subject lines. So if your website contact form generates the subject line of contact us or new submission or contact form, then those will work. But if the website con-, you know, contact form, I've seen a bunch of different subject lines. Then what this does is that it'll join the two. So that it's only gonna bubble up emails that have that sites.google.com with that specific pattern and a subject line relating to the contact form. Emily Hacker: (28:02)And given the searching that I've done, that should really narrow it down. I don't think there's going to be a ton in the way of other contact emails that are using sites.google.com that are showing up for these people. I wouldn't be surprised if this did return one email and it turned out to be a malicious email related to this campaign. But if the contact form generates its own subject line per what the user inputs on the website, then, you know, the screenshots that are in the blog may help with that, but it might be more difficult to find in that case. There's a second advanced hunting query there, which we'll find on the endpoint.Natalia Godyla: (28:37)And I know we're just about at time here, but one quick question on endpoint security. So if a customer is using Microsoft Defender for endpoint, will it identify and stop IcedID?Emily Hacker: (28:49)Yes, it will. The IcedID payload in this case, we're seeing Defender detecting it and blocking it. And that was what, one of the things I was talking about earlier is that Defender is actually doing such a good job. That it's a little bit difficult for me to see what's, uh, gonna happen next because I'm limited to, um, seeing kind of what is happening on customer boxes. And so, because our products are doing such a good job of blocking this, it means that I don't have a great view of what the attacker was going to do next because they can't, 'cause we're blocking it. So it's of mostly a win, but it's stopping me from seeing if they are planning on doing, you know, ransomware or whatever, but I'd rather not know if it means that our customers are protected from this.Nic Fillingham: (29:32)Well, Emily Hacker, thank you so much for your time. Thanks to you and Justin for, for working on this. Um, we'd love to have you back again on Security Unlocked to learn more about some of the great work you're doing.Emily Hacker: (29:41)Definitely, thank you so much for having me.Natalia Godyla: (29:47)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: (29:54)And don't forget to tweet us @msftsecurity or email us at securityunlockedatmicrosoft.com, with topics you'd like to hear on a future episode. Until then, stay safe.Natalia Godyla: (30:05)Stay secure.