 here. Before we jump into the content here, I want to start with a personal observation. Working as a consultant that gets to see thousands, hundreds of thousands of compromised systems. One thing, a remarkable shift we've seen has been away from malware that's a discrete file that exists in the file system that's basically really easy to find as an analyst. Two attacks that are much more difficult to find because maybe they don't use malware or their payloads are stored in very unusual places. So some things we've seen recently are, you know, attackers that may compromise say, you know, the VPN, come in, use RDP and don't use any malware whatsoever to compromise an environment and steal the recipe to Coca-Cola for instance, not speaking officially there. Another thing you may have heard of is Powerlix for instance, that backdoor that stores this whole payload in the registry. It doesn't exist in the file system. And so what we're here to talk about today is yet another variant of this, yet another technique that we can use as offense people, you know, pen testers getting into environments and also from a defensive perspective, how we go about investigating these types of attacks. So as Matt mentioned, and as I hope you're aware, we are here to talk about WMI, Windows Management Instrumentation. We're going to talk about practical attacks here, but we're not just talking about the theoretical. In our experience at Mandiant and FireEye, we have seen attackers use these techniques that we're going to talk about here and use even more advanced techniques to compromise environments and maintain persistence and further their goals. And what we've also found is as investigators going around, there's not much out there in terms of doing the investigation. It's actually very difficult. We've gotten lucky in many cases, but looking to the future, we can't expect to be lucky in the future. So we've done research to ensure that we can advance the state of the art there. So that's what we'll be covering today. In order to motivate this presentation, so you understand very practically what this means and how powerful these techniques are, Matt's going to introduce a demo here that we'll use throughout the presentation to kind of show how these techniques work. Would you take it from there, Matt? All right. So I wrote a very crude, basic credit card track data scraper. So what you're going to see here is from this red attacker machine, I'm going to persist on the blue victim machine, a track data stealing payload using pure WMI. So I will use WMI both to install the payload persistently. The WMI payload itself is asynchronous in that upon firing of a very specific event that I target, it's going to start scraping the track data from the executable that I'm targeting. Finally, I'm also going to use WMI as a pure C2 channel and exfiltrate the data back to the attacker system. So I'm going to provide the credentials to the victim machine. And all in the background over DECOM, the WMI port that I'll get into briefly, it's going to install the payload. All right, we're targeting payment processor.exe. So as soon as this process on the victim machine fires up, it's going to execute the payload, the one that will scrape memory for valid credit card track data. And this is our fictitious payment processor.exe, just PowerShell where I paste in some fake but valid track data consisting of both track 1 and track 2 data. So I'll let that run for a second, close it out. And then if everything worked properly, what I can do is over WMI, using it as a pure C2 channel, I can pull back that fully parsed data. And because I love PowerShell so much, I love the fact that everything is an object. I'm not dumping text here. I dumped the fully parsed track data in the form of a properly like parsed out PowerShell object. All right. So the attack that you just saw, I'm sorry, I'm not going to be releasing the source code for it, but we're going to use this to drive a mock investigation. So William and Claudia have developed some pretty amazing tools to be able to parse out the WMI or the SIM repository. You'll hear us use those terms interchangeably. And what they'll be able to do is parse out all the forensic artifacts that that attack left behind. All right. So prior to this week in Vegas, such a forensic capability didn't exist. But they're going to release these tools and I think you'll be pretty impressed. All right. Willie? My name is Willie Ballantyne. I'm a reverse engineer on FireEyes Flare team. We're a group of 20 reverse engineers working on the malware queue there. What I like most about this position is that I get to do a ton of research, investigate these new technologies that are coming out or in the case of WMI, something that's been around for 20 years that attackers may just be starting to use. And then turn that into something usable for you defenders out there. I won't ask you guys if you're on the blue team out there to raise your hand for fear of embarrassment there. But I love helping you guys out there. And I look forward to kind of developing additional techniques with you in the future. I don't fear embarrassment. So who here is on the blue team? Who might have to defend against this sort of thing? Okay. There's a lot of you in here. Okay. That's awesome. Blue team rocks. All right. I'm Matt Graber. You find me on Twitter. I'm also a reverse engineer on the FireEye Labs advanced reverse engineering team. Been a speaker at various conferences. Black Hat trainer. As you may or may not know, I'm a huge PowerShell fanboy. Probably to a fault. I personally subscribe to what myself and my good friend Chris Campbell referred to as like the living off the land mindset where as an attacker, you should have the minimum footprint possible, right? So, you know, we're advocates of, you know, using these like, powerless infections where say you're running like PowerShell payloads purely in memory or using some of the WMI techniques that we'll be discussing here shortly. You know, traditionally security products, you know, perform all kinds of introspection on things on disk. Well, there's, I mean, we really don't have to drop too many payloads to disk. WMI is extremely powerful for attackers. And as you'll see, it's also very powerful for defenders. But there's not a single payload aside from a single file that AV can't touch that can be really introspected by a traditional security product. All right? And I'm a noob. I don't really claim to know what I'm talking about, but here I am. Hello, everybody. I'm Claude Ute Odarescu. I didn't don't recognize my middle name though. It seems it's a translation of my last name in English. That's what I heard. So, I'm a reverse engineer for Flare Team. I've been doing forensic research, writing forensic parcel for, in case for the past ten years. So my background is forensics and a lot of forensics. I'm a crypto enthusiast as well. And I wish I could have been a soccer player, but my parents had a different idea about that. Since we have to cover a lot of information in this presentation, the outline is two-page long, so bear with me, please. So first we start with the background, motivation and attack examples. We go into the WMI architecture and the WQL query language. We follow up with eventing and remote WMI and a bridge history of WMI attacks from malware perspective. Then WMI providers. Then we go into forensic data, like file format, investigation, real-time defense and mitigations. And then forensics on the formats of the files, the team, the same repository consists of. And we finish with the mock investigation and WMI attack detection. Let's cover the basics first. So many of you already know what WMI is, but just real quickly, WMI stands for Windows Management Instrumentation. This is Microsoft's implementation of a series of open standards that strive to automate just management of resources and devices in an enterprise. It's extremely powerful both locally and remotely. Attackers have realized that this WMI service has been listening on every Windows system since Windows 98 and NT4 seriously. So from a Windows 10 attacker machine on a network, like you could easily compromise Windows 98 system given that you have the proper credentials. So WMI can be used to do a lot of things, as we'll see, but just some of the quick highlights are you can work with a registry, you can enumerate files, directories. So when I say you can work with a registry, you can read from it, write to it. You can subscribe to events. This is like one of the killer features that I'll explain in PowerShell. And you can also execute commands. There's a bunch of WMI classes that have these built in methods, one of which is used very heavily, the Win32 process create method which is used for both code execution and lateral movement. And I'll have some examples of those. And I'll probably say this fairly often, any technology that's useful for administrators obviously will be very useful for attackers too. Admins have known about WMI for a very long time. If you just go out and Google various articles on say like WMI permanent event subscriptions, you'll see these great articles going back to like the late 90s, early 2000s. It really hasn't been until I'd say probably 2010 that we start to see this uptick in attackers starting to realize just how powerful this technology is. All right, so here's kind of the overlying architecture of WMI. Over on the left side you see all these client utilities. So WMI you can think of as kind of like a client server model where we have all these clients say you want to use a client like Wimic.exe to enumerate processes remotely or read registry values. These are all going to fall under the clients and there's a bunch of tools to allow you to do that. Ultimately I would call the server process and all of this the WMI service itself. So wind management. This is probably running on every one of your Windows systems whether you realize it or not. Listening on port 135 or in the case where you have WinRM enabled port 1589 by default. So these clients you can either like just straight up like execute methods directly enumerate all instances of a certain class. You can also get pretty specific with like what events you want to subscribe to or objects you want to enumerate by using kind of a like domain specific language called WQL. It's a very like SQL like syntax that allows you to like easily manipulate objects and what not. Okay, there's two basic protocols that WMI will use. The classic one is Decom and then more of the recent one is WinRM, Winner's remote management. I'll kind of use like WinRM and like PowerShell Remoting kind of interchangeably like they're two different specs like PowerShell Remoting is built on WinRM. But just be aware of these two protocols where you can use WMI remotely. WMI wouldn't be very useful without a bunch of providers. So say you wanted to enumerate all the running processes, right? So you would get all the instances of the Win32 underscore process class instance, right? Well, there's a DLL that's on disk that actually provides the WMI service with the information that you're requesting. So there's a bunch of these WMI providers and these are what really give the functionality and allow you as a defender or an attacker to potentially extend the functionality of WMI. Then everything in WMI is backed by this one particular file called, we call it the WMI or SIM repository. And William and Claudio are going to get into this in a lot of depth. But the point is there's a lot of valuable forensic artifacts in there. And until this week there has been no way of parsing these out in an offline forensically sound fashion. All right. So I'm going to cover some of the more popular WMI clients out there. My favorite, of course, being PowerShell. And I don't just say this because I'm a huge PowerShell fanboy. I say this because right out of the box you have all of these commandlets here listed. So you have a set of WMI commandlets and SIM commandlets. And what we can do with these is enumerate class instances, execute WMI methods, register WMI events in the local PowerShell process context. But we can also do so in a permanent fashion as well. And we can remove class instances as well. There's also, as a PowerShell 3 and above, there's a bunch of these SIM commandlets. And they're more or less the same as the WMI commandlets only. They provide it just a little bit more functionality. For example, you can call like getSIM class to parse out like the schema of a bunch of like WMI objects. If you're doing research, like trying to find like really valuable objects, that might be useful to an attack or a defender. Also, these SIM commandlets can talk over both DCOM and WinRM. So something to be mindful of when you're working in more modern environments where the Windows Remote Management Service is listening. These are the kind of the SIM commandlets, are the kinds of commandlets that you'll find the most value out of. Okay? There's a bunch of other utilities as well. Who here has used WMIK.exe? Cool. Yeah. A lot of you. So this is like the tried and true WMI utility. It's been out forever. Probably since WMI has been out like going back to like Windows 98. It's really powerful. It gets the job done. So I've seen this used pretty heavily. For example, for lateral movement where like the Win32 process create method is called and WinMIC.exe for lateral movement. I haven't seen it used a lot for persistence. But I've also seen it used by a lot of malware samples actually where they'll use WMIK and query certain WMI object instances like the Win32 underscore BIOS class for example where they'll do some pretty crude like VM detection and then like exit out of the malware process or do something that's or like go into like an infinite sleep loop if it detects that it's in a virtualized environment. Another really cool utility that you may not be aware of is WBEM test. This is like it's a really crappy GUI utility like the UI is terrible. But it's extremely powerful. So I've actually used this on assessments a long time ago like when I didn't have access to WMIK.exe or PowerShell.exe. I was able to use this to get around like their application whitelisting because this utility was whitelisted. So just keep that in the back of your mind if on assessments you're blocked by using some of these utilities that one may be available. Also there's WinRM.exe. This isn't really too well known but you can use WinRM assuming the WinRM service is listening on your local or remote system. This can be used to enumerate class instances, execute methods. You can also use it to set WinRM settings. You can also use VBScript, JScript. People have been doing this forever. Like if you were to go and Google like how to install a permanent WMI event consumer or subscription you would see a lot of like old school articles or VBScript is used. And actually attackers and well some defenders kind of have to resort sometimes to unfortunately writing VBScript because one of like the built-in payloads that you can do when like persisting with WMI is you can embed like a VBScript or JScript payload in there. There's a bunch of other utilities. There's some good Linux ones. WMIC which is very similar to WMIC.exe. WMIS is kind of like just a wrapper for the Win32 process create method. So it basically enables you to from a Linux system do lateral movement given credentials or in the case of the past the hash variant you can just provide a hash to do your lateral movement and code execution. There's some pretty cool research utilities as well. So if you're interested in digging around in these WMI repository looking for objects, methods or events of interest then I recommend you check out SimStudio or WMI Explorer which is a commercial utility. Finally if you're going to incorporate some of these techniques into your own code say it be C++ or .NET you have various APIs to work with. Now aside from the client utilities if you want to be able to do some slightly more advanced operations with WMI then it would behoove you to learn WQL. So WMI query language it's very SQL like syntax. It basically allows you to do three things. So there's three classes of queries. There's instance queries so we're just interested in particular object instances. Say like if you want to enumerate processes, right? Event queries. So if you want to subscribe to an event of value then you'll want to use an event query and then meta queries are just kind of like high level queries where you can use these to determine like what classes may or may not exist in the WMI repository. So here's what an instance query might look like. So let's just look at the example. Select star from Win32 process. So I'm interested in having all Win32 process instances return to me and all properties. So that's a star right there. You can specify just a single property name but usually you'll just give it a star because you may be interested in all of the properties. And then you can provide an additional constraint. So instead of providing all Win32 process objects give me the ones that just have the word chrome in them. Okay? The event queries are a little more complex and so there's a little bit of a learning curve but I hope to prove to you eventually that like these things are really, really powerful. So there's two classes of event queries. There's queries for intrinsic and extrinsic events. I'll get into those briefly. But let's look at these examples here. All right. The first example, at a high level, we want to target all interactive logons. And so the way you describe that in a WMI query is you want to target all instance creation events. Okay? So this event will fire upon the creation of any WMI class instance. And what we're interested in is all instances that are of type Win32 logon session. Within 15. So with these types of queries you have to specify a polling interval because these queries or these events trigger all the time. So you have to specify this polling interval just to make sure the query is a little more performant. All right? And we're interested in any Win32 logon session where logon type equals two. So if you look this up in MSDN you would see that logon type two refers to interactive logons. Okay? Now the next one. Select star from Win32 volume change event where event type equals two. This is an example of an extrinsic event. So this would fire immediately upon this event firing. What does this event do? Well, again, if you look up in MSDN you would see that event type two refers to removable media. So you have something that would trigger and then you could do something interesting based off that trigger whenever someone inserts a USB stick. All right? And then the last example should be pretty self-explanatory. This trigger will fire upon the registry key, the run key changing in HKLM. All right? Let's dig into eventing a little bit more. All right? So you saw some examples of how these WQL event queries could be used to subscribe to these events. What's really cool about WMI is that if you were to just enumerate like every single class definition, like on this Windows 7 that I'm driving these slides, this Windows 7 machine that the slides are being driven from, there's just under 8,000 WMI classes. So there's some really interesting classes in there that have some extremely valuable information to both defenders and attackers. So we can craft these queries based upon some of the examples that you saw previously. And you'll see some more pretty valuable examples coming up later. Now, attackers seem to really enjoy using WMI's persistence mechanism. I would say largely because to date perhaps defenders just aren't that great at detecting it. And I don't know of anyone to date who is able to recognize WMI used as a persistence mechanism in real time. Okay? So it's really easy let's say like using auto runs to detect it used after the fact, but in real time it's a little bit more of a challenge. So in order to use WMI for persistence, you need three things. A filter, which is a WQL query. So this describes the event that you want to trigger off of. A consumer. This is what you want to do upon firing that event. And then a binding. So this is the registration mechanism that takes the filter and the consumer and actually like installs them. All right? So these can either run for the lifetime of the host process in the case where say you ran a registered WMI event or you can register permanent WMI events and these are persistent. Okay? And the evidence is only located in a single file that AV will never touch and it runs as system. All right. So there's two event types. Intrinsic and extrinsic. Once you start digging into like WMI classes, you'll see that there's a ton of classes that are organized like hierarchically into namespaces, not unlike any typical object oriented language. So within each of these namespaces, you have the following system classes defined. And when I say system class, I refer to any class that begins with these two underscores here. So within each namespace, you have all these intrinsic events. So there's some really like valuable queries that you could subscribe to. For example, I used the instance creation event earlier to trigger off of whenever an object is created of the type that I'm targeting, then I can go do something with that accordingly. There's some malware that APT-29 was using that created dynamically its own custom WMI classes and was using it like they were stuffing data into there. So you could create a query that would trigger on the class creation event, for example. There's another tool out there that uses WMI as a C2 channel by creating and modifying namespaces. Well, you have intrinsic events that could fire off of those malicious events as well. All right. Extrinsic events are a little more specialized. These things are not going to be present within all the namespaces. These are very highly performant events. They fire immediately, so you don't have to specify that like that polling interval. So, for example, we have something like the Win32 process start trace event. All right. This will fire immediately upon any process starting. All right. So you could use this as a defender for, you know, pretty decent process and command line auditing. You could also use it as an attacker, which is exactly what I did in the attack scenario that I showed at the beginning of the talk with that credit card scraper. All right. You have like module load trace. So every single executable DLL device driver, this event will fire. So if you subscribe to that, you can get some really interesting information. You have the volume change event, which has to do with, you know, like physical volume, say like removable media. And registry key change event and value change event. It should be pretty self-explanatory. These are extremely powerful. So as a defender and attacker, like, start thinking about the creative ways that you might be able to leverage these events. All right. So once we've registered our event, the thing that we're interested in triggering off of, we want to do something interesting. Okay? So Microsoft provides five standard event consumers. So these are the things that effectively execute our payload upon triggering this event. Log file event consumer. This just appends whatever data we specify to a log file. Active script event consumer. Attackers really enjoy this one because it allows you to embed in line VB script or J script that will execute immediately upon your event triggering. Anti event log consumer. So think, I mean, there's already a lot of rich information within the event log and hopefully you're constantly inspecting those event logs. But WMI can be used to cover all the gaps where, say there's some event that you're interested in where there's no respective event log entry, you can use this event consumer to supplement the existing event log entries. There's SMTP event consumer. So fire off an email upon an event. And then command line event consumer. Again, very popular with attackers, hopefully for obvious reasons. All right. So again, for permanent WMI events, we need those three things. We need a filter, which takes the form of an instance of an event filter class. An event consumer class, so the consumer, one of those five standard consumers that perform the action upon triggering that event and the binding, which takes the form of this filter to consumer binding object, which performs the registration and does the installation of these events, either locally or remotely. All right. A little bit about the protocols used by WMI. So the one that's been around forever is DECOM. So the WMI service will listen on TCP port 135 to establish an initial connection. All subsequent connections, like where data is being passed back and forth, will be established on a separate TCP port dictated by this following registry key. So I believe by default, there's like a somewhat like large range of ports here, but you can use the DECOM config.exe to specify a single port making DECOM a little more firewall friendly in your enterprise. All right. Here's an example of me just enumerating processes on a remote system using DECOM. And the DECOM protocol is implied here because I'm using the WMI commandlets, not to be mistaken with the SIM commandlets that talk both DECOM and WinRM. So WinRM or PowerShell Remoting. So it's a SOAP based protocol. So, you know, SOAP inherently contains all this like very rich type information that can transmit and receive PowerShell objects and WMI information. So it's encrypted by default. Just out of the box, it'll be listening on port 5985. If you configure it to use certificates over HTTPS, then it'll be listening on port 5986. All right. This really is like the official remote management protocol that Microsoft is pushing really hard. If you were to take like a server 2012 R2 machine in like server core mode, you would find that the only port listening on this machine is 5985. So Microsoft is really pushing this hard. All right. Here's an example of me using the SIM commandlets where rather instead, let's see, I'm using the WinRM protocol using the SIM commandlets to do the same thing that I did using DECOM previously. So here I'm just using the SIM commandlets to enumerate processes. So it's just a different set of commandlets and a different protocol that's being used to ultimately obtain the same exact information. All right. So we've got a somewhat rich history of WMI attacks. All right. As far as I can tell, the first WMI attack that came to my attention was with StuxNet. So what StuxNet did, well, one of the many things that it did was it exploited the Windows printer spooler vulnerability. I believe this was MS10.061 where effectively they got an arbitrary file write vulnerability. All right. So imagine, if as an attacker you could write a file anywhere on the Windows system to gain code execution, what file would that be and where would you write it to? Well, the developers of StuxNet were really intelligent and what they did was they created a moth file which is basically a specification for these certain objects. So they had this moth file that allowed them to gain persistence and when you do WMI persistence you run in the system context. So they dropped this file into this specific directory and then previously before Microsoft fixed this there was like a watchdog process that would look for new moth files in this directory and consume them and process them accordingly if it's all a new one. All right. So all they did here was they installed this event that I believe was like shortly after a system start up it would execute some other executable that they dropped in the system context. So they used this vulnerability as a privilege escalation attack. All right. Then in the same year there was the ghost malware. This is a commodity sample that targeted users documents. So what it did was there's a really useful WMI class for file based operations. It's a sim underscore data file. It detected like whenever there was any new or modified files within the recent folder it would upload all of those. And so like the payload that it used was like an active script event consumer that just used the Internet Explorer COM object to simply upload those new documents that it discovered. And then moving forward in 2014 there's a Romanian researcher who developed WMI shell. And this was the first time that I had ever seen WMI use as a pure C2 channel. So what he did was he created and modified namespaces and just stuffed his payload in there. So say you created some namespace and placed in it an encoded PowerShell command. And then you used the Win32 process create method to take that namespace on the victim system, basic C4 decode it and then go ahead and execute it. And then conceivably you could also take the output of that PowerShell command, save it to another WMI namespace and then you could read that remotely. And so that's effectively what this tool did. And then this year we revealed APT29. So fire I believe it was like a week or two ago released a report on the HammerToss malware. So this was largely like Python and .NET malware that used like Twitter as a C2 channel. What that paper didn't describe though were the WMI TTPs that this threat group was using. So what they were doing was they were creating and modifying WMI classes and class properties, stuffing their payload in there. Basically doing the same thing as WMI shell only using custom WMI classes instead of namespaces. So there's a lot of things that as an attacker you can do with WMI. So from a post exploitation perspective really like you can cover pretty much the entire like attack life cycle here. Whether it be reconnaissance, I already mentioned some malware does like VM and sandbox detection. We have code execution, lateral movement, persistence as we already know, data storage. So like using those namespaces and custom classes to stuff our payloads or the result of our payloads in there. And C2 communication. So basically tying together the data storage with code execution and getting a pure C2 channel out of WMI. Now so if you were to go about doing reconnaissance with WMI, these are just some of the classes that you might be interested in. So this is very typical of a lot of malware. So the first thing you might do is collect some host information, upload it to a C2 server. You have some convenient objects there. If you want to perform file of directory listings, delete files, move files, you have SIM underscore data file. Any volume operations, registry operations. You can list processes, stop processes, start services, create services all remotely using WMI. Okay. Now we can also get code execution and lateral movement. So I've already described the static create method in the Win32 underscore process class. So here's an example of me using PowerShell to invoke that method and in this case just call notepad.exe. From an attack perspective just imagine replacing notepad.exe with say PowerShell.exe dash encoded command and then you have like a little like one liner command stager that just goes out to the internet, downloads your subsequent PowerShell payload and executes that. So this is really simple to do. All right. So a reminder for WMI persistence, we have those three requirements, the filter, which takes the form of a WQL event query, a consumer, the thing that you want to execute, and you have those five standard event consumers and a binding. What's up? Hey. All right. So we have a little tradition here at DEF CON. What is it? Shot the noob. Welcome to DEF CON. Cheers. So we have our three requirements. So let's get going with persistence. Feeling so much better now. All right. So here's an example of what SeaDaddy was doing. So SeaDaddy is the internal Mandiant name that we were using for, I believe the public family name for this was SeaDuke. So this was a Python back door that used PowerShell as a WMI persistence mechanism. So I just pulled that out of the Python back door, changed it up a little bit, but effectively what it does is, so you take the event filter, which is this long query here in the query variable, effectively all it's doing is it's going to trigger some event shortly after system start up, specifically anywhere within 232 seconds after system start up. In fact, this attacker just ripped this query right out of PowerSpoil. Kind of lame. And then, so we have what we want to trigger off of, and then what are we going to do upon triggering that? So all we do here is there's a command line event consumer. So shortly after system start up, we're going to execute something at the command line. What is that going to be? It's just going to be, in this case, evil.exe. So the attacker had previously dropped their Python executable and shortly after system start up, it would just be executed again. Nothing too complex here. So WMI can also be used as a storage mechanism. This is a short little snippet of, in essence, what APT29 was doing. Only they were doing this remotely, not locally. This is just a simple example where I was doing this locally. So here I'm creating a custom Win32 underscore evil class, which is going to be contained within the root Symbi2 namespace. And then I'm going to attach evil property to it, and my payload will be the string this is not the malware you're looking for. And then the put method is what actually installs it permanently into the sim repository. So just imagine this being like some base 64 encoded PowerShell command that would get executed later on. All right. Providers, take it away with it. Sure, just take a minute here. So one of the things that kind of impressed me when I started looking at WMI was that it's not this one huge monolithic service that I expected coming from Microsoft and existed for 20 years. I expected this really complicated beast, and that's not quite what it is. Instead you should really be thinking of WMI as a framework for querying and configuring a system. All right. And the core part of WMI is very small. And what gives WMI its power are all these providers. And a provider is essentially a calm DLL that declares that it knows how to provide some type of data. And it says, hey, this is the data that I know how to process and give to people. So for instance, when you use WMI to go about and say query the list of processes on an operating system or not host, there's a provider on the back end that basically is able to perform the operating system queries, the system calls to get those processes, and then format them in a way that the query is able to process. So it's actually a really neat system. There are of course ways that as a defender you can go ahead and enumerate those things. And that's going to be something I suggest that you do. Because with your attacker hat on, you should be thinking, wait a minute, this is kind of a plug in based system with calm objects that provide arbitrary data to a framework. You know, what can we do with that? Is there a way that we can use that maliciously? And sure enough there is. We can think very easily now of how you might create a malicious WMI provider that can do customized activity on the remote systems. So I think Matt was able to come up with some examples of this. And they really show the state of the art here. Really neat stuff. So I didn't really come up with the examples here. I had the requirements which I provided out to the Twitter sphere. And what resulted in that was my good friends Casey Smith and Jared Atkinson. Like that very night went and implemented their own like custom or proof of concept malicious WMI provider, which is awesome. Because like when Willie and Claudia mentioned this for the first time, this was just like a theoretical attack factor. We had never actually seen this used in the wild. So we thought it would be really cool. And these guys banged it out really quickly. So what Casey did was he created a malicious WMI provider in the form of just a shell code runner. So what you would do is you would take his .NET DLL, install it with install utility .exe. It would do all of its like com registration and what not. And what that would allow you to do is either locally or remotely execute a shell code payload in the system context. Pretty cool. Then Jared, what he wanted to do was create a WMI provider that would simply list out active network connections. Because prior to Windows 8 there was no respective WMI object for doing that. So you know, there was this large gap in WMI for like older systems where you wouldn't have that information to say like trigger off of if you saw a connection going out to like a known blacklisted C2 address. Another thing that he just slipped in there was a PowerShell runner. So once you got this installed, then you would just provide an arbitrary PowerShell command via this argument list argument and then it would go execute that PowerShell payload either locally or remotely in the system context. Cool. So that kind of concludes our introduction to WMI. And if you weren't kind of familiar with WMI, you now have a good basis for understanding of what you can do with it and so forth. Matt gave a great introduction. I'd like to spend a few minutes now talking a little bit about our motivation of why we even started doing this in the first case. So this is definitely started within at least our company about six months ago or so, working some large investigations, companies that had say 10,000, 100,000 hosts on their network, where we saw a particular threat group come in and use WMI to further their attack. We call this of course as Matt mentioned earlier, APT29. They used actually a lot of really neat techniques and one of the things that made the most interesting to me at least as a defender was that they were particularly aware of how a forensic investigator goes about their investigation and made it really difficult for us. So they did kind of those things that we always talk about but never really do, almost like using long passwords, which is like using secure delete to delete their files, clearing event logs everywhere. And so when we got in there and we started doing the investigation, even though we weren't trying to remediate, they very quickly knew that we were doing an investigation. And so that put us at an interesting situation because they knew it, so they started upping their game and then we knew that they were upping their game, so we upped our game and used newer and newer techniques and kind of cool ideas. And we kind of got into this little, I don't know, like a little bit of a war there, kind of trying to do better and better things. And it was really interesting because we were very lucky because we had great network coverage and great host-based coverage. And so ultimately we were successful on our remediation and we believe we exhausted the attackers' new techniques. Along the way, what we saw was them deploy many of these new WMI techniques. And so some of the things we saw them do right off the bat at the very beginning was use this filter to consumer binding persistence technique to start up their back doors. But as we started pushing them along, you know, they deployed C Daddy and then they kind of reverted and stopped using C Daddy to an extent and they started pushing all of their payloads into this sim repository. And now why did they want to do that? Because as investigators, when we go to look at a system, I mean hopefully it's online, at least when we get to it and maybe we can do some inspection. But if we get a forensic image, there are no dropped files on disk. There are no new registry entries. There's very little to look at. There's this one binary blob, this database thing that sits there and houses data, but at that point we had no way to parse it. So we were a little bit out of luck. Some things we could have done and we tried along the way was that we could have used WMI to go in and inspect the WMI system itself to find out what was there. We can use those meta queries to actually fetch that data. Now that's a fair technique and it's actually a fairly powerful technique because WMI is networked. So we can do it remotely. We can reach out to systems and say, hey, what WMI classes do you have installed? But, you know, being familiar with, you know, sophisticated attackers, I don't really trust asking the system to report its own safety and health to me back. I imagine how a very short amount of time it would take to deploy a root kit, for instance, that might shim into that WMI service and decide not to return a couple of the most interesting results. So that doesn't make me feel very good. Another reason that this didn't work particularly well is that occasionally maybe the system that had the most interesting data on it was compromised and so we had to pull the system offline as soon as possible. Or we just got a forensic image from the client. On a dead box environment, on a dead box image, we couldn't use WMI to query that dead box. That doesn't even make sense, right? So we were left just inspecting the file system and registry. And so what we found was, you know, we found some really interesting string hits and objects.data. Has anyone done that before? Maybe seen malware binaries, their file names showing up in objects.data? Well, that's what we found. We found really interesting strings, but this was a huge file, like 100 megabytes. And we really had no way to go about inspecting it further. So running strings on a binary file and calling that forensics also doesn't make me feel good. That's not forensics, all right? The final technique that we explored with limited success was to kind of build a Frankenstein system. And that's where we have a live running system that's clean and we copy out the SIM database from a compromised system onto the live system and hope that everything kind of works. And sometimes it does. But again, coming from a forensic perspective, I don't know why the system works that way. I'm wondering, hey, is it performing any kind of checksum and maybe cleaning up unusual data or data that shouldn't be there? Is there other things that are being cleaned up along the way when that live system imports the data? I don't know that. And so I'm wondering if I'm losing data, if I'm stomping on timestamps, I just don't know. And so that made me really uncomfortable. So we got together and we spent a little bit of time investigating what these files were and if they allowed us to fully reconstruct all of this WMI data. And I can report to you with confidence that, sure enough, there's a lot of really interesting stuff in there. So we're going to dig into that. Taking a look on disk, what makes up this WMI service and the data that backs it, here are some of the most major files. Object south data is the most obvious one. And this is a file we had been inspecting for actually the past couple of years looking for interesting entries in there. But really all we were able to do is basically run strings on it and interpret the output. And again, that's not forensics. There are a couple of other files in there as well as index.btr file. Ultimately, it ends up being a B tree that allows us to very quickly seek to data within the object's file. And these mapping files, here at the bottom, mapping.ver and mapping 1, 2, and 3, these allows us to correctly reconstruct the data in kind of a logical address space. And unfortunately, one of the findings that we identified along the way, but fortunately we're able to share here, is that simply grabbing objects.data is not sufficient for forensic analysis. All right? So over time, we had basically acquired a huge corpus of these object.data files and we were excited to parse through them and find all the malware. That file by itself is not sufficient. So make sure when you go out and do forensics, grab that whole directory. So we dug into these files. Maybe from a single system, we were looking at maybe 50, 100 megabytes of data, most of it in that object.data file with a few supporting the B tree index, for instance, on the side. We're not going to dig into this a lot, but how do we go about this? We actually did not do any static analysis on the WMI service binaries at all. We didn't debug the system. We simply generated a lot of big heck stumps and spent most of our weekends and full weeks just staring at those heck stumps. But it ends up not being as difficult as it may sound on first pass because there's a lot of human readable strings and that's a great place to start when you're reversing a file format. Identifying known data. So those strings stand out really obviously. Alongside strings, oftentimes you find, you know, the size of the string. So very quickly you're identifying those fields. And then offsets within, you know, sized buffers also become very obvious. You have a known piece of data that's written. Now you look for offsets to that string that show you how the data is organized internally. The thing that was probably most difficult for us to understand and to reverse engineer, we're kind of bit flags along the way. So, you know, the read writeable flag, that might have been one of those bit flags. Or does this thing have a default value? That's a single bit that's flipped in each record. Glancing at the file is a little bit difficult to do, but through differential analysis where we have one known good thing, we have a similar repository. And then we apply one change to that same repository and see what the difference was on disk. That allows us to trace down very quickly what a lot of those flags were. So ultimately it was a little bit of a tedious piece of work. But I can report now that after a few months of research, I think we have four bytes across the entire database that were unsure what they mean. So everything else, we know what it means and we know how to parse it. And that's really exciting. Because what that means is that we can use the SQL or any of these other query languages on a dead box system. And we can say, okay, what is there? What did the attacker store there? And what other artifacts might there be that aren't exposed to WMI? There are additional artifacts. There's all new sets, brand new sets of time stamps along the way that we can pull out and use to figure out when this database was modified last, when entries were inserted and things like that. So anyone familiar with digital data can build up a timeline of attacker activity and identify new periods of compromise. So this is definitely really, really neat stuff. So Claudia and I are going to spend a little bit of time digging into this nitty gritty detail to kind of give you a sense of what it looks like. Thank you, Willy. So the next diagram shows the files that the same repository consists of and their relationship. So we have the index BTR, which is a page file. The page size is 8192 or 2,000 hexa. It's a B3 on disk index. Pointers to the next pages are represented as logical page numbers. And to get the physical page number of a certain artifact, you have to use the currently active mapping file and find the logic to physical page number mapping for the index that BTR. And the logical page number is used on an index in the mapping. What the value of that index represents the physical page number. In this example, in the physical page 10, we have the internal representation of evil consumer. As you can see, the first identifier prefixed by NS underscore represents the name space where the instance lives in. The second identifier prefixed by CI underscore is the class name of that instance. And the last one is the IL underscore is the actual instance name. At the end of the representation, there are three integers. The first integer is a logical page number. The second one is a record identifier. And the last one is the size of the record. Objects that data is also a page file. The same page size as the index which is 2,000 hex. So getting from the logical page number found in the index, we are using the corresponding mapping in the active mapping file. From that logical offset, we are getting the physical offset in the objects that data. The actual physical page number, sorry, actually the physical offset is computed by multiplying the page number by the page size. And after reading the page, we identify the record header for the instance data using the record identifier from the search result. From the record header, we get the offset in page of the record and its size. We get the actual physical offset of the record data by doing the following computation. Physical page number multiplied by the page size plus the page in page offset. The size is also present in the header. Also CRC32 checksum is present there too. So we can do a data integrity check on the record data and validate that nothing weird happen. So to do an artifact recovery methodology, first we have to construct the search thing, taking into consideration the artifact namespace, class and name. Stay tuned for the white paper that will describe this in detail and then perform a search BTR doing a prefix match on the key that is return. From the key you get the logical page number, the artifact record ID and the record size. Based on the logical page number, you determine the physical number using the corresponding mapping in the mapping active mapping that map file. Then in the objects that data page you find the record header using the record identifier from the result search and then we validate the size in the record header matches the size in the index that BTR founds a search and then the record offset in the header represents the offset in the current page of the artifact and then the integrity check is performed. So this is a page structure with object data. It starts with a list of record headers. Each record header consists of a record identifier an in-page record offset a record size and the CRC32. The CRC32 is only present under Windows XP since the integrity check is done at the record level for optimization purposes in Windows Vista and up the CRC was moved in the mapping so the integrity check will be done at the page level this time. Next, this is the keys, keys in a root page in the index that BTR they represent class definitions instance declarations hierarchy representations and also references. Next, it's a very pretty picture and when I talk about pretty I'm saying pretty complicated so I won't spend any time on this all the details and examples are in the white paper they are very self-explanatory and whoever wants to follow and read the white paper I'm pretty sure they'll understand. We've demonstrated I hope that maybe you don't quite fully understand the file format we do understand it so the natural thing for us to do was to build some tools that would make it easy for you all to take advantage of this knowledge so that's precisely what we did. I wrote a tool developed in Python which is a fully oriented library and makes it easy to interact with a forensic image that contains a sim repository. Claudio developed a tool that is written in C++ and it is extremely fast and codifies a lot of our knowledge for investigating these sim repositories. We're going to spend a few minutes walking through these tools for you so you understand what you now have at your disposal to investigate these types of attacks. I'm going to call it pure Python parser for the sim repository. Now the sim repository is these files that contain anything that's been persisted to disk by WMI. So this includes many of the instances of classes that attackers may have created or other assist admins as well as all the data that's supported by the system that you can query and configure. It is a very interesting place to look. This tool provides access to any field that we're able to parse out and it parses everything that we're able to describe at this point all except those last four bytes and it gives you access to say all those time stamps if you want to do time lining. It makes it very easy for you to use. I did develop a little GUI to kind of demonstrate its functionality so that's what I'll show you here but I will describe that anything that you see in the GUI here is very easy to use programmatically and that's kind of the intent of this script because it's very easy to use. So this tool is really good for data exploration. So let me see if I can figure out this. All right. So written PyQT works on both Windows Linux systems. You're able to go in and explore any of the pieces of data, the forensic artifacts that we can parse out. If you don't understand the physical representation then you can also explore the logical representation of the sim repository. So here we are looking at the various namespaces that we're able to parse out. Root sim v2 is a default namespace and down here under root subscription is where we find those filters to consumer bindings that maintain persistence. So as we explore that namespace we see all of the classes that are resident under that namespace. These are all the types of data that you can query for and an attacker may have modified. This filter to consumer binding I'm sorry everyone. It's amazing that you can have a demo fail when you're not even doing it live. I'll just have to avoid pausing it. All right. So we can explore these classes here and this filter to consumer binding that looks like we're pretty good. I'm just going to hit start and we're just going to go for it. Here we are. Filter to consumer binding that's what we use for persistence using WMI. What this report shows is all those nitty gritty details that we're able to parse out. But the most interesting one there is this layout section here which describes in detail each of the properties that is exposed by this particular class. So as expected we see a filter and consumer. Those are the two parts of the persistence there. Additionally we can see things like default values or any other things that we're able to parse out of the artifact. Now one of the neat things about this tool here is that in addition to parsing data for you it also gives you a way to validate the parsing. So what we see here is a pretty standard hex editor view that you can kind of go in and take a look at the various fields. But it's more than that, alright? In addition to parsing out and just showing you the hex dumps it shows you how each individual field is parsed out. So if you're not quite sure why was that time stamp parsed in 2009 in July? Well let's go in and see where that data is. We can mark up that data and confirm offline that sure enough so that's really powerful easy way to validate our tools. So anything that we're able to parse out is visible here in this hex dump. That's really neat I think. So we've kind of parsed through this class definition that describes what data is available. Now let's take a look at some of the instances, the specific concrete data that is stored using the schema. So that's also displayed under this tree view here under that sub branch and we have three instances of this persistence mechanism. So we can take this first one for instance and explore that concrete data that's installed on the system. Notably there are two time stamps there within each instance that we conjecture is probably the creation and modification date for those instances. We're looking at the specific values, those concrete values and these give us the names of those WMI classes that define both the filter which is a thing that would be triggering and the consumer, the thing that would be run. And so we're able to go out and fetch that data as well and see what those two payloads might be. And just to kind of confirm, sure enough we can go in and validate manually using that hex view. What is this data? How is it being parsed? So from my perspective I think this is an interesting tool. It's really intuitive, at least from my perspective you can kind of click around and explore the data. But at this point I don't necessarily expect you to know quite where you want to look. So this is a great tool for getting familiar with WMI, especially from a forensic perspective. But we'll leave it to Claudio now who's able to take a lot of the knowledge that we've developed along the way. Methodology is finding persistence and things like that. And he's codified it into his own tool that makes it almost like a wizard to find evil. So you'll have both of these things finding bad guys in your environment. So we'll give Claudio a chance here. So the demo parser it's a C++ forensic parser and it works only in Windows. And he's using commands dash dash namespace instance, dash dash consumer instance dash dash class definition and so on. Extracts persistence and pull out data and it's a guided wizard to find evil consumers and event triggers and it was built following the IR workflow. The source code is available at the following GitHub. Let's go into the demo. Yeah, it doesn't. Is it working the demo? So we start the WMI parser and we saw that the persistence in WMI is using consumers. So what we're doing here is we're parsing all the consumers that are in the root subscription namespace and sure enough we found a command line event consumer which is called test consumer and execute a power shell using the IEX which is invoke expression and it's taking from the Windows 32 payload class the payload value the payload property value. The next one is an NT event log called SEM event log consumer and another command line event consumer which is called BVT consumer and it's executing a VBS script which is located in C tools can rate. So the first one looks suspicious. The second tool you can find those in any system. So but still you have to check them to make sure that they're valid and not overwritten. Next we take a closer look to the suspicious event consumer. Again we see that what it's doing is executing a payload stored in a custom class and also we are finding the binding that binds the triggering event to the consumer. So the triggering event in this case is the payment card processor launched and let's take a look what the query to find out the triggering event looks like so we get a filter instance and then we see that select start from win32 process start trace where process name is equal with payment processor.exe so whenever this process is started it triggers automatically and execs the consumer. So since we know that the payload is located in the win32 payload class under the payload property then we can do the class definition parsing of the win32 payload and we have here the name of the class and then we see the property and as a default value there is a base 64 encoded payload which is actually after decoding and analyzing is a memory scraper for credit card information data so we decoded we look at it and the most important thing is okay where are you hiding the data that you're scraping so a class win32 underscore X fill in the root CIMV2 namespace under track data it's a good indication so let's go back to the WMI parser and then do a class definition parsing on the win32 X fill under root CIMV2 and what we have here under the track data property there is another base 64 encoded value which after decoding it we have a serialized object which contains the information that was scraped so with the track type the CVV the name, Fred Smith and the credit card number so I don't know Fred Smith but I have his credit card so we're heading to Vegas so join me next cool so I'd say at this point we're in a lot better shape now because we're able to go out and investigate these types of attacks now we don't have to hope that we have good network coverage and host space coverage in order to investigate these things we can do it offline and be sure of our results we have tools that do that now we're going to continue to update with all of our methodologies along the way that we're able to discover to identify WMI attacks so what are some of the other generic ways that we can go about finding these WMI attacks how do you know if this affects you Matt already said there might be something like 7, 8,000 of these WMI classes on a single host how do you even kind of dig through the weeds there to find the bad stuff we're still working on that but I also want to maybe some kind of call for action because essentially what we're presenting at this point is like a file system parser like an NTFS parser that gives you a new file system but we're not quite sure of all those new pieces of data that are stored there so let me talk to you about the few things that we do know about and encourage you to kind of dig around in some of those files to find interesting pieces of information so the obvious one that we've covered in our bindings this is the most obvious and well known and commonly used way to maintain persistence through WMI and it's also a way that you can encode and store your payloads within this sim repository so AV may not find those files on disk, those payloads but they'd be in the sim repository and this is a way that you can find them we've also seen attackers that go in and install their own custom class definitions we're proposing at this point to kind of do a complete enumeration of what we expect to see in client environments and that's no longer something that we can't do this is something that we can do which is build baselines to understand what should be on systems and to look for things that shouldn't be there in my experience seeing attackers use even the most advanced techniques that we've talked about the new classes that they create do not look like legitimate classes that we've gone on or back door or I think there was one that was almost like bad or something like that so even if you're scanning this thing it's like that's so obvious so at least we can say for this next week next two days still pretty easy to find but we need to be thinking about in the future how do we identify things that shouldn't be there now moving beyond just what has been installed persistently or what are the class definitions is that under Microsoft software metering a lot of the trace data that it stores like the processes that are executed when they were last executed and how often they're used is actually stored for some reason via WMI and so when it persists that data which programs the operating system is executing it stores it in the same repository so now we have a very easy to use parser that can actually extract all those recently used executables and who is running them and what directory they were in and how many times it was executing and when the last time it was executing this is really juicy and interesting stuff so one of those classes that I recommend you take a look at into is CCM recently used apps additionally some of those other software metering artifacts are really interesting and we can talk about that offline I have used successfully kind of time lining everything that's happened in a similar repository some really interesting things to me I was able to use the time lining of the background I guess is that I saw an attacker install a persistence mechanism he used the filter to consumer binding so I saw the modification date there in line in the same repository so I looked at the other events that were happening about that same time and I saw artifacts that led me directly to the user account that the attacker had compromised in order to compromise the system and so that's something we didn't know at that point and was able to add to the report so that was really valuable and finally of course we were able to finally decode this stuff with full confidence because let's say two or three months ago when we were trying to do this the first time we would run strings on the same repository objects.data and we'd get things that looked like base 64 encoded commands in there and like hey man we got it this is good we got everything and then we throw it into our base 64 decoder and it was truncated in the wrong order so we had to do the work and ultimately that's due to the way that the file is paged and because we didn't know the mapping of all those pages we couldn't reconstruct it correctly now we can reconstruct it with full confidence so I definitely think we're in a pretty good situation now in regards to investigating these attacks but is there anything more that we can do to kind of prevent these attacks in the future and know that this is something that is actually maybe affecting our organization or our client's organization alright so I want you to consider the following an attacker can do a lot of things so I'm going to give a few examples of some attacks and the respective effects that they'll have in WMI that you might be able to form a creative WQL query off of to potentially detect these sorts of things as they're happening in real time so an attacker will persist via a WMI permanent event subscription so what ends up happening from a WMI perspective is instances of event filters event consumers and filter to consumer bindings are created and a respective event that would be triggered upon creation of those class instances would be an instance creation event an attacker uses WMI as a C2 channel WMI shell tool that creates and modifies WMI name spaces and uses that to stuff payloads and store the result of executed payloads well instances of the name space creation event would trigger in this case okay an attacker uses WMI as a payload storage mechanism very similar to WMI shell but let's say we're talking about APT-29 their TTP was to create WMI classes and properties dynamically and stuff the payload in there as well as executed payload take the result of that payload and store it into another class property in this case for the TTP used by APT-29 you would see the class creation event be fired going further an attacker persists via a really valuable WMI class called win32 startup command that would capture that very action whether it be the all user startup user startup directory HKLM or one of the user HKCU hives this single WMI object will capture that and the way that you would capture that event is because an instance creation event of type win32 startup command all right so an attacker modifies any additional known registry persistence locations one that comes to the top of my mind is say you have a malicious LSA plugin that's installed there's a very particular registry key used where those are installed to well in a more generic sense you could just use a registry key or registry value change event to trigger upon the modification of any key or value that you are specifically targeting service creation this is easy an instance creation event is going to fire of type win32 service are you starting to see this pattern here so all of these attack effects can effectively be described in the form of a WQL query okay so what's a WQL query that's that event filter that's requirement number one for an instance of permanent WMI event subscriptions the only other two things you need now is you want to do something upon triggering this event so you have one of your standard event consumers and then you bind those together using a filter to consumer binding all right so I thought this really kind of this exhibit mean here so let's take the case of an attacker using WMI as a persistence technique well what if we just had a permanent WMI event subscription that detected the creation of permanent WMI event subscriptions it's totally doable all right so we could potentially detect any persistence any like WMI persistence registry persistence say like using the registry key change event service creation easy schedule job and task creation and then like you can just get so creative with these so just think of any attacker action and the respective artifacts that it might leave behind and there's going to be almost guaranteed there's going to be a WQL query that can represent that attacker effect the only notable exception to that would be as I mentioned before below Windows 8 you don't have WMI classes that represent network connections so there's a known gap right there all right so perhaps we can use WMI as say an agent list host IDS we register our own permanent WMI event subscriptions for all kinds of attacker activity and the benefit is it's persistent the service is already running and there's no agent we don't have to push our own executable like EXE or MSI package onto a system Microsoft already gives us this mechanism to do this without dropping a single file and we can install it remotely so I wrote a proof of concept tool called WMI host IDS it's effectively an agent list host based IDS it's a single PowerShell module file so all you do is you call import module and then the name of the file and so the only system that requires PowerShell is the one that you're installing it from so all this is doing on the back end is just creating either locally or remotely those permanent WMI event subscriptions on the machine that you want to register these alerts on okay so let's see this in action so here's our attacker slash defender machine and I'm going to import the IDS module and then you can view all the commands exported in this module by calling get command list the module and currently there's four functions new alert action trigger register alert okay these are the three requirements for permanent for WMI persistence and so let's look at the help so what does new alert trigger do well this is what you want to trigger off of so we can trigger currently off of event consumer creation modification or deletion so like the creation of say command line event consumer we could trigger off the startup command that win32 startup command object or the or a change to a registry right there's much to be expanded in this but right now this is just a perfect concept to show that this is possible now new alert action this is the payload that we want to execute as a defender so we can either send that event information to a URI or we can create an event log entry so we would be supplementing the event log with whatever event is that we're interested in as a defender and then we register the respective trigger an action together using register alert so let's see this in action now I'm interested in detecting in real time the attack that you saw at the beginning of the talk so I'm going to provide the credentials to the remote system register my trigger so what do I want to fire off of creation of a command line event consumer which is what the attack use so trigger type creation optionally you can provide a name of this trigger when it's registered persistently in the sim repo and then you just take that pipe it to new alert action so this is what we want to do upon the creation of say a malicious command line event consumer alright so in this case I want to create an event log entry which hopefully as a defender you would be forwarding all your event logs to some centralized logging server and then you simply register it together with the register alert function and as proof we now have our created instances of the event filter event consumer and filter to consumer binding on the remote system now I said this was the attacker machine so we're going to execute the track data scraper again but before we do that as proof to show you that this hasn't fired yet I want to be able to pull back remotely the event log entry that I would be looking for upon a malicious command line event consumer being created so just to show you that the payload hasn't been executed yet there is no respective event log entry at this point now when we install remotely and persistently the credit card track data scraper it's going to do its thing this is the same exact payload that you saw installed previously and now I'm going to look at the event log to see if that respective event log entry was created upon creation of the command line event consumer which indeed it was created so this was real time detection of this inaction and so like what Claudio did earlier I can simply parse out this payload and see that what it's doing is it's stuffed the payload in the root sim v2 win32 process class I believe and then in the payload property and so I can even pull that back remotely using the sim command line so here I'm just calling get sim class payload which we see here so I'm pulling this remotely and I'm interested in dumping out the data in the payload property and I get the base 64 encoded payload so we have two options we have now the capability to perform dead box forensics and also the ability to perform detection in real time using WMI alright so as a defender I showed you a few instances of how you could use this to detect activity in real time there's a bunch of other things that you could trigger off of for example event log creation or say you might want to trigger off of the clearing of an event log and do something interesting as a defender do process auditing monitor files or directories and then in Windows 8 and above classes these you can you can both query and trigger off the creation and removal of new network connections okay we can use PowerShell to detect WMI persistence after the fact so I just showed you how to detect it in real time but say you want to sweep your whole enterprise you just have a few lines that can accomplish this here there are some additional existing utilities that can also help you detect WMI persistence again after the fact the latest version of auto runs has a WMI tab that will print out all of these event filters and event consumers and then you can just right click and delete them Kansa is a really cool like pure incident response framework for PowerShell that also has some WMI detection lastly one other thing I'd like to mention you can actually set the namespace ACLs for each respective namespace so say you wanted to remove the ability to execute the Win32 process create method you could go into the root Symbi2 namespace which is where the process class is contained and remove the ability of anyone to execute those methods remotely now Sean Metcalf you probably saw his awesome talk earlier mentioned to me that this is kind of a great idea from an attacker's perspective so what I'm saying here is like as a defender you can set ACLs as an attacker you can also set ACLs as well so imagine compromising a DC and then downgrading all of the ACLs so that any authenticated user without any privilege on the domain can go back at any time and re-compromise the domain controller so that was a really cool idea so here's just the those respective ACLs being set alright so that's it just want to give a shout out to Will Schroeder and Justin Warner for giving me some great ideas on like the various like creative event filters that you could come up with as both a defender and an attacker and Willie take it away during this presentation we kind of brought you through an emotional roller coaster because we started off by talking about how awesome WMI was and like all these really cool things that we can use it for during an attack all the different phases of the attack life cycle and I think it was also kind of neat how after the fact we're able to come in and say well here's the things you can also do to defend from that using the same techniques and some also forensic techniques so I think it's probably fair that we acknowledge our employer for this for allowing us to do this research and also to share it with you is on GitHub at this point just before this talk we finalized and asked to be published this white paper that goes into deep detail about everything we just talked about it's currently about 100 pages long talks in depth about everything there and so this is all information that I hope you can take away from this talk and implement in your environment or use in another person's environment but anyways a couple references here we'll also share more again in those around challenge if you haven't given it a shot yet great way to practice reverse engineering starts off pretty easy gets pretty complex and we love to chat with you after this whole talk so I think at this point we have almost a half an hour for questions or maybe half an hour that we can get over to that hacking cars talk and see the end of it. Sure references. There's a microphone coming sorry I have a question first as far as the trying to downgrade how many classes there are to go through is there any possible in terms of forming master hash libraries to go through that or is that modify create time stamps just going to mess everything up or can you exclude those and do the rest of the values yeah so I think it's totally feasible and not difficult to do to build up say like a hash list of all the known classes and all the properties you expect to find there across an environment and then go from your gold image to anything that's actually installed on our workstation to maybe 5, 10 classes much more reasonable. Would that be primarily location specific or is it possible to start developing one for multiple systems just contribution based? I think we have a lot of flexibility there and the way we attack it and we'll chat after. Is kind of a follow up to that are there any techniques you can share for doing this at scale for identifying malicious providers across an entire environment? Is this persistence mechanism that we talk filter to consumer bindings this is the only one we've seen so far and is most heavily used and on top of that on a default windows installation there's at most one or two persistent WMI consumers those are used by the operating system to do its own thing so you only expect to find one or two per system so it's very easy to go and look at scale well how many do I have do I have 5, do I have 10 that's weird. That's a good place to start. Were you also asking specifically about WMI providers? Not specifically. More in the methodology to detect this across an environment. Sure. It might be worth noting whenever any new WMI provider is created you could say trigger off instance creation event of type underscore win32 provider and then like you can take the definition of that provider there's a GUID that you can look up in the registry and then that would show you the DLL that is for that actual provider. On the ACLs with WMI are there any situations where you might put an ACL on that might actually cause something else not to work properly? Yes. If in your organization you're doing completely legitimate things with WMI remotely then you would want to be mindful of that say you could create like a remote WMI administrator's group and then limit the ACLs to that group and then block everything else for every other group. Is there anything specific within Windows itself that uses that or is it just if you were using remote WMI yourself? Is there anything like standard Windows services that would actually need that in order to function properly? That's a good question. I had considered but I never really looked into like what maybe some of the unintended side effects would be of just like outright disabling that service. I mean Windows is like increasingly reliant upon this service like especially in OSs where you have this new technology called desired state configuration that relies very, very heavily upon WMI under the hood. I would just be wary of that. Hi. First of all, excellent presentation and thank you for that. For opening up a new class of defense which is not available using the existing tool chain which we have. Thank you for that. I have a few questions. First is I write my own custom moff files to do different stuff. So most of your differential analysis is comparing it with a clean machine with the one so how does my moff file play into that? You're going to trip my moff file for sure. Okay. So backing up a little bit, we didn't really cover a moff very much because from an attacker's perspective and like an investigator perspective what we're starting to see more and more is attackers doing everything dynamically without requiring a moff file. So you could use a moff file to carry out the same exact attacks that the attackers are doing. Only a moff introduces another forensic artifact that as a defender you would be able to detect pretty easily. From an attacker's perspective like in my view the only thing that a moff file gets you is persistence beyond WMI repository corruption. So not sure if you want to ask your question again to see how maybe moff might play into all this. My second question is for Willie with that Python tool. So how do you handle standard if you're managing Citrix environments and your Citrix installations get corrupt. So WMI recompilation and backup and restore of WMI repositories which is pretty standard stuff to do for system and so on. My question is what happens to your date time signatures which you are relying on and let's say if I drop a payload and immediately after that I can take the whole moff and recompile the repository right so we're exploring how the timelines are affected by inserting new data into the repository and taking it out. Our understanding right now is as you insert dynamically or via moff files new classes not all the time stamps change within the repository typically they are restricted to the new objects that are being created or modified so I would expect those time stamps to stand out like a sore thumb when I'm doing my timeline analysis. Does that answer your question? It's a good start. So another thing is you used CCM recently used apps so how do you track an environment which doesn't use SCCM? I simply pointed to that forensic artifact as something that would be useful. I think in probably approximately 50% of the environments that we investigate they're using Microsoft SCCM and so this is a useful artifact for us to look for as a consulting company but if you're not using your organization you may not find it as useful for sure. Question for Claudio about the objects dot data. Did you try taking objects dot data and dumping it into something like a MongoDB which can actually nest it as JSON objects or something? No. Because you did a very static analysis of the whole thing which is very forensically accurate. Can you dump it in there? Can you do a diff on different instances which can go into that? Just a thought, I'm asking. Usually you don't take only the objects that data, as Willy was explaining you have to have all the files in order to get to all the data and how the data is constructed in objects that data you need a mapping file because if you have a record that is bigger than the page size the different offset is not sequential. That's one of the things but no we didn't go and put it in and doing a diff. You can go. The next big thing that we want to invest some time in is recovering deleted artifacts because the mapping, the active mapping file has a list of free pages which whenever you insert something new into the database and there is no space in any of the allocated pages they will be used. So, but whenever something goes out of the scope the data still resides in the object that data and you can go and parse every file that is in the free every page that is in the free pages array and look for artifacts and you can do per for both index.btr and for objects that data. So, imagine the attacker is trying to be really stealthy, right, where after they install their permanent WMI event subscription they only want to execute the payload once so they do whatever it is they want to do and then as a cleanup step remove the event filter, event consumer and filter to consumer binding those artifacts are actually going to persist in those free pages which we don't have the ability to parse at the moment but the tools like once the research is done will certainly be extended to pull those artifacts out. After the next question we'll start charging. Yeah. Depends on how much you charge. So, a lot of the forensic analysis is focused on finding out what exactly is your filter to consumer binding but you do not have any trace of what events did fire. Well, wouldn't you through the so from the filter to consumer binding you would have the event filter property and then when you look at that instance you would see the event of interest. No, my question is this you are coming into exploited system after point X after the something has happened or unless you are looking at it with your development ideas and you already have those files pre-installed if you do not have that there is no way to keep track of what previous events is already fired in the system because unless you have a consumer there is no persistence. You know what I'm saying? I think you're right basically we see the persistence mechanism installed but we don't quite know if it was fired and the payload was executed. I mean that's kind of equivalent to finding a run key in the registry that points to a payload. You don't quite know if the system was rebooted and like the run key executed and caused the payload to execute but that's usually enough to kick off your investigation and say there's malware here it's been installed for persistence typically I say this box is compromised and we should assume that the malware has run even though we haven't quite seen the specific trigger yet I mean I understand what you're saying so I mean we are in agreement cool more questions sure the B3 file which you're analyzing I know that there are certain stuff which stands out you know meaning the name a lot of this analysis is very name based I would say let's say if you're hiding yes I'm trying to say that how can you get beyond detecting things based just on name or a base 64 dump or something which is very stealthy what's the link with the index BTR because that's the part of it my point is there's B3s where your repository is stored so is there any differential analysis which you can the B3 stores some representation of different artifacts so the keys in the B3s are a concatenation of sim entities for example if you want to specify a class definition you have to provide the interpretation of the namespace full path and the class name that represents a key into the index BTR and this is how you are able to query the objects that data through this representation by finding location information of the data in objects that data that's the purpose of the index BTR there is no other information in store it's just for searching quick and finding where the data resides in object that data question for Matt development class without auto recover development class defined without the auto recover meaning I drop it it fires off once and goes away like if you had a moth out that still did like WMI persistence it would still persist even without pragma auto recover just pragma auto recover will just recover everything and recompile that moth after the rebuilding of the sim database but we'll take any further questions offline and we can talk about this for hours so we'll just be right outside so thanks again for staying so long and missing out on the car hacking talk really appreciate it