WhyMI so Sexy? WMI Attacks, Real-Time Defense, and Advanced Forensics Analysis
Ballenthin, Willi
Graeber, Matt
Teodorescu, Claudiu
Windows Management Instrumentation (WMI) is a remote management framework that enables the collection of host information, execution of code, and provides an eventing system that can respond to operating system events in real time. FireEye has recently seen a surge in attacker use of WMI to carry out objectives such as system reconnaissance, remote code execution, persistence, lateral movement, covert data storage, and VM detection. Defenders and forensic analysts have largely remained unaware of the value of WMI due to its relative obscurity and completely undocumented file format. After extensive reverse engineering, our team has documented the WMI repository file format in detail, developed libraries to parse it, and formed a methodology for finding evil in the repository. In this talk, we will take a deep dive into the architecture of WMI, reveal a case study in attacker use of WMI in the wild, describe WMI attack mitigation strategies, show how to mine its repository for forensic artifacts, and demonstrate how to detect attacker activity in real-time by tapping into the WMI eventing system. By the end of this talk, we will have convinced the audience that WMI is a valuable asset not just for system administrators and attackers, but equally so for defenders and forensic analysts. Speaker Bios: Matt Graeber is a reverse engineer in the FireEye Labs Advanced Reverse Engineering (FLARE) team with a varied background in reverse engineering, red teaming, and offensive tool development. Since joining FireEye, Matt has reversed a vast quantity of targeted and commodity malware samples and served as an instructor of Mandiant's Advanced Malware Analysis course. Matt is the author of various PowerShell modules used for pentesting and reverse engineering including PowerSploit and PowerShellArsenal. He has also been designated a Microsoft "Most Valuable Professional" in PowerShell. Twitter: @mattifestation Willi Ballenthin is a reverse engineer in the FLARE team who specializes in incident response and computer forensics. He can typically be found investigating intrusions at Fortune 500 companies and enjoys reverse engineering malware, developing forensic techniques, and exploring the cutting edge. Willi is the author of a number of cross-platform Python libraries including python-registry, python-evtx, and INDXParse.py. Twitter: @williballenthin Claudiu Teodorescu is a reverse engineer in the FLARE team. Prior to joining FireEye, Claudiu worked for Guidance Software, writing forensic parsers for different file formats to support the EnCase forensic tool. Also, as the Cryptographic Officer of the company, he supported EnCase integration with different disk/volume/file based encryption products including Bitlocker, McAfee EEPC, Checkpoint FDE, Symantec EEPC, etc.
 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 attackers that may compromise say 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 back door 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. So 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. All right. 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 in objects. I'm not dumping text here. I dumped the fully parsed track data in the form of a properly 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. 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 FireEyes 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, malware-less 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 this. 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 Oderescu. I 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 NKs for the past 10 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 WKL 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 the WMI attack detection. All right. 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 management of resources and devices in an enterprise. All right. 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. All right. 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 the registry, you can enumerate files, directories. So when I say you can work with the 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. All right. Admins have known about WMI for a very long time. Like 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. Only 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 WMIX.XE2, enumerate processes remotely or read registry values. Okay. 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 this the WMI service itself. So wind management. Okay. 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. All right. 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 there are 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 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 get SIM 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 DECOM 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 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 Wimic.exe? Cool. Yeah, a lot of you. So this is like to try it in 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 Wimic.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 Wimic 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 like going to 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 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 Wimic.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 is not 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 old school articles or VBScript is used. And actually attackers and some defenders kind of have to resort sometimes to unfortunately writing VBScript because one of 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. WMI.exe which is very similar to WMI.exe. WMI. S is kind of like just a wrapper for the Win32 process create method. So it basically enables you from a Linux system do lateral movement given credentials or in the case of the pass 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 logic 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 to 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 2. So if you look this up in MSDN you would see that logon type 2 refers to interactive logons. Okay. Now the next one. Select star from Win32 volume change event where event type equals 2. 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 2 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. 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. So these can either run for the lifetime of the host process in the case where say you ran registered WMI event or you can register permanent WMI events and these are persistent. And the evidence is only located in a single file that AV will never touch and it runs as system. So there's two event types, intrinsic and extrinsic. Once you start digging into 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 a malware that APT29 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 this 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. 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. This will fire immediately upon any process starting. So you could use this as a defender for pretty decent processing 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. 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 physical volumes say like removable media and registry key change event and value change event. These are extremely powerful so as a defender or an attacker start thinking about the creative ways that you might be able to leverage these events. So once we registered our event, the thing that we're interested in triggering off of, we want to do something interesting. 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. And this, 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 that, I believe by default there's like, some of 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 about DECOM and WinRM. So WinRM or PowerShell Remoting. So this is 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 will be listening on port 5985. If you configure it to use certificates over HTTPS then it will 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 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, yeah, 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 Moff file which is basically a specification for these certain objects. So they had this Moff 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 Moff 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 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 Mauer. 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 used 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 W32 process create method to take that namespace on the victim system, base 64 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 like 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 FireEye 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. All right. 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. All right. 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. All right. If you want to perform file or directory listings, delete files, move files, you have some underscore data file. All right. 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, well, in this case, just call notepad.exe. From an attack perspective, just imagine replacing notepad.exe with say PowerShell.exe-coded 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. So we have a little tradition here at DEF CON. What is it? Shot the noob. Welcome to DEF CON. Cheers. That's good. All right. 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 C Daddy was doing. So C Daddy is the internal Mandiant name that we were using for, I believe the public family name for this was C Duke. So this was a Python backdoor that used PowerShell as a WMI persistence mechanism. So I just pulled that out of the Python backdoor, 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 a system start-up. In fact, this attacker just ripped this query right out of PowerSpoiler. 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 A to T29 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 sim v2 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. 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. 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 com 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 com objects that provide arbitrary data to a framework. 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 kind of 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. That very night went and implemented their own proof of concept malicious WMI provider. Which is awesome. Because 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 installutil.exe. It would do all of its like com registration and whatnot. 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 there was this large gap in WMI for 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 would 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, APT 29. 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 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 deploying 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 that we could have done and that 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 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 and on 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 we 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. Objects update 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, the bottom mapping dot 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 head stumps and spent most of our weekends and full weeks just staring at those head 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 the sizes of the strings. 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 interesting, a string. 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 they're differential analysis where we have one known good sim repository and then we apply one change to that sim 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 we're 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 allows us to do is basically reimplement WQL 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 timestamps 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 forensics immediately know why that's interesting. We 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, Willie. 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 logical to physical page number mapping for the index that BTR. And the logical number, 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 prefix by NS underscore represents the name space where the instance lives in. The second identifier prefix by CI underscore is the class name of that instance. And the last one is prefix by the I 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 BTR, which is 2000 hex. So getting from the logical page number found in the index, we are using the corresponding mapping in the map, 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 identified 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. And then 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, the 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 to validate that nothing weird happened. So to do an artifact recovery methodology, first we have to construct the search thing, taking into consideration the artifact name space, class and name. Stay tuned for the white paper that will describe this in detail. And then perform a search into the index BTR doing a prefix match on the key that is returned. From the key, you get the logical page number, the artifact records ID and the record size. Based on the logical page number, you determine the physical number, page number using the corresponding mapping in the mapping active mapping that map file. Then in the object 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 found in the 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 of a page in 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 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. And they are very self-explanatory. And whoever wants to follow and read the white paper, I'm pretty sure they'll understand. All right. So we've demonstrated, I hope that maybe you don't quite fully understand the file format that we've done. I hope that we do understand it. So the natural thing for us to do was to kind of build some tools that would make it easy for you all to take advantage of this knowledge. And so that's precisely what we did. All right. I wrote a tool developed in Python, which is a fully nice library object oriented library. Makes it very easy to interact with a forensic image that contains a sim repository. All right. Claudio developed a tool that is written in C++ and is extremely fast and codifies a lot of our knowledge for investigating these sim repositories. So we're going to spend a few minutes now kind of walking through these tools for you so you understand what you now have at your disposal to investigate these types of attacks. So Python sim is simply what I 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. All right. 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. So it is a very interesting place to look. This tool provides access to any field that we're able to parse out and know about. 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, like, all those time stamps if you want to do time lining. 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 to give you power to go ahead and build investigative scripts that can quickly triage data. All right. So this tool is really good for data exploration. So let me see if I can figure out this. All right. So written in 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. Route Sim V2 is a default namespace. And down here under route 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. Oh, 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 is that ‑‑ all right. 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 kind of 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, all right? 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 timestamp parsed as 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 that was parsed correctly. 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 timestamps there. Within each instance that we conjecture is probably the creation of modification data 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, all right? 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, 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 to, both of these things at your disposal are 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. And let's go into the demo. Yeah, it doesn't. Okay. Is it working the demo? Okay. So we started WMI parser, and we saw that the persistence in WMI is using consumers. So what we're doing here, 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 window 32 payload class the payload value, the payload property value. The next one is an anti event log called SEM event log consumer, and another command line event consumer, which is called BVT consumer, and is 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, 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 basic foreign coded payload. Which is actually after decoding and then analyzing is a memory scraper for credit card information data. So we decoded and we look at it and the most important thing is okay, where are you hiding the data that you are scraping? So a class win32 underscore X fill in the root CIMV2 name space, under track data, it's a good indication. So let's go back to the WIParser 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 basic foreign coded value, which after decoding it, we have a serialized object, which contains the information that was scraped. So it's 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 are in Vegas. So join me. Next. Cool. So I'd say at this point, we are in a lot better shape now because we are 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 based 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. So that Python tool again was really good if you want to programmatic access or kind of explore the data. And we're going to continue to update with all of our methodologies along the way that we are able to discover to identify WMI attacks. So what are some of the other kind of generic ways 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. So I want to jump into a few things. But I also want to maybe kind of do 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 additional interesting pieces of information. So the obvious one that we've covered a few times already is to look for those filtered to consumer 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 and use those remotely to store payloads or pull data out. 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. It's something like recon or back door or I think there was one that was like almost like bad or something like that. So even if you're like scanning this thing, it's like that's so obvious. So at least we can save 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 is in that, you know, what has been installed persistently or what are the class definitions, another piece of interesting forensic artifact that shows up in these object data files 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 to find attacker activity and that's identified 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 and so I saw the modification date there in line in the similar repository. So I looked at kind of 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 get that persistence there. 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 are able to finally decode this stuff with full confidence because let's say two three months ago when we were trying to do this the first time we would run strings on the similar repository, objects.data and we get things that look 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, it just didn't 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? That's something that Matt is going to talk about next. All right, so I want you to consider the following. Okay. 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 persists via a WMI permanent event subscription. Okay. 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. Okay. An attacker uses WMI as a C2 channel. Let's take that WMI shell tool that creates and modifies WMI namespaces and uses that to like stuff payloads and store the result of executed payloads. Well, instances of well, sorry, not instances, but the namespace creation event would trigger in this case. Okay. An attacker uses WMI as a payload storage mechanism. Very similar to like WMI shell, but let's say we're talking about APT29. 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 APT29, you would see the class creation event be fired. All right. Going further, an attacker persists via say the start menu or the registry. There's a really valuable WMI class called Win32 startup command that would capture that very action. So 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 would fire of type Win32 startup command. All right. So an attacker modifies any additional known like registry persistence locations. One that comes to the top of my mind is like say you have like a malicious like LSA plug in 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 change event or registry value change event to trigger upon the modification of any key or value that you're specifically targeting. All right. Service creation. This is easy. All right. And instance creation event is going to fire of type Win32 service. Are you starting to see this pattern here? Okay. 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 begged for 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 attack or 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, in 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 let's say an agent list host IDS. We register our own permanent WMI event subscriptions that detect all kinds of attack or 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. All right. So I wrote a proof of concept tool called WMI host IDS. All right. It's effectively an agent list host-based IDS. It's a single PowerShell module file. So all you do is you call it 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 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 went 32 startup command object or a change to a registry key. There's much to be expanded in this but right now this is just a proof of 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 it is that we're interested in as a defender. And then we register the respective trigger and 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? The creation of a command line event consumer which is what the attack used. 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. 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 as well. 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 in action. 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 Symbi2 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 on Win32 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 then 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. All right. So as a defender, I just 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, look at, check out the MSFT net classes. These 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 out there 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 is you can actually set the namespace ACLs, like 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 Symbi to 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, then 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, like without any privilege on the domain, can go back at any time and recompromise the domain controller. So that was a really cool idea. So here's just the respective ACLs being set. All right. So that's it. Just want to give a shout out to Wilshire Oder 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. I hope 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 also some 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 because all this code 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 of references here. We'll also share more again in that white paper. Better mention the flaring out challenge if you haven't given it a shot yet. Great way to practice reverse engineering. It 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. There's a microphone coming around. All right. Sure. References. There's a microphone coming. Sorry. I had a question first. As far as the trying to downgrade how many classes there are to go through, is there any possibility in terms of forming master hash libraries to go through that? Or is that modified, create timestamps, 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. And that would be probably limit it down 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. We'll try it after. As kind of a follow up to that, are there any techniques that you can share for doing this at scale for identifying malicious providers across an entire environment? I think the most obvious one at this point 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 of all the techniques we've seen. 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 something that you should give a look at and say, okay, 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. But yeah, just it might be worth noting, whenever any new WMI provider is created, you could say trigger off of instance creation event of type underscore underscore win32 provider. And then 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. Yep. 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. Okay. Yeah, I mean if in your organization you're doing completely legitimate things with WMI remotely, then yeah, you would want to be mindful of that. Say you could create like, you know, 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? It's like any 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 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 like modern OS's where you have some like this new technology called desired state configuration that like relies very, very heavily upon WMI under the hood. So yeah, I would just be aware of that. Yeah. Okay, 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. So thank you for that. I have a few questions. First is I write my own custom more files to do different stuff. So most of your differential analysis is comparing with a clean machine with the one so how does my more file play into that? You're going to trip my more file for sure. Okay, well, so backing up a little bit. We didn't really cover a moth very much only 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 moth file. So you could use a moth file to carry out the same exact attacks that the attackers are doing. Only a moth 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 moth file gets you is persistence beyond WMI repository corruption. So not sure if you want to ask your question again to see how maybe moth might play into all this. My second question is for Willie with that Python tool. So how do you handle WMI recompile which is pretty 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 moth and recompile the repository and I mean all my timelines would be aligned right after that. Sure. Right. So we're exploring how the timelines are affected right now by inserting new data into the same repository and taking it out. Our understanding right now is as you insert dynamically or via moth files new classes not all the time stamps change within the same 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? I mean it's a good start. So another thing is you used CCM recently used apps. So how do you track that in environments which doesn't use CCM? 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 SCM and so this is a useful artifact for us to look for as a consulting company but if you're not using that in your organization you may not find it as useful for sure. Question for Claudia about the objects.data. Did you try taking objects.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. Exactly. But my point is this if you dump it in there can you do a diff on different instances which can go into that? I mean just a thought. I'm asking. Usually you don't take only the objects that data. As Willie was explaining you have to have all the files. In order to get to all the data and how the data is constructed in object that data you need a mapping file. Because if you have a record that is bigger than the page size there will be different chunks of the different offsets. It's not sequential. So that's one of the things but no we didn't go and put it in and doing a diff. Yeah, that's correct. Yeah, you can go. But the next big thing that we want to invest some time in is recovering deleted artifacts. Because the mapping that 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 page that is in the free pages array and look for artifacts there. And you can do both for both index.btr and for objects that data. Yeah, so imagine the attackers 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 clean up 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. Depends on how much you charge. So a lot of the forensic analysis is focused on finding out what exactly is the 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. My question is this you are coming into an exploited system after point X after something has happened or unless you are looking at it with your WMI IDS 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 and if you have a consumer there is no persistence. You know what I'm saying? I think you are right. We see the persistence mechanism installed but we don't quite know if it fired and the payload is executed. 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 the run key executed and caused the payload to execute but that's usually enough to kick off your investigation and say there is 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 that caused the consumer to execute. Would you agree with that? I understand what you are saying. We are in agreement. Cool. More questions? Sure. The B3 file which you are analyzing. I know that there are certain stuff which stands out. Meaning the name. A lot of this analysis is very name based. I would say let's say if you are 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 because that's the part of it. My point is there are B3s where your repository is stored. Is there any differential analysis which you can? No. The B3 stores some representation of different artifacts. 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 name space full path and the class name. That represents a key into the index BTR. This is how you are able to query the objects that data through this representation by finding the 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 objects that data. Question for Matt. Development class without auto recover. Development class defined without auto recover meaning I drop it, it fires off once and goes away. If you had a mall file that still did WMI persistence, it would still persist even without Pracma auto recover. We will recover everything and recompile that mall after the rebuilding of the SIM database. We will take any further questions offline and we can talk about this for hours. We will be right outside. Thanks again for staying so long and missing out on the car hacking talk. I really appreciate it.
 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 attackers that  may compromise say 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 back door 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. So 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. All right. 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 in  objects. I'm not dumping text here. I dumped the fully parsed  track data in the form of a properly 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. 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 FireEyes 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, malware-less 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 this. 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 Oderescu.  I 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 NKs for the  past 10 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 WKL  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 the WMI attack detection. All right. 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 management  of resources and devices in an enterprise. All right. 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. All right. 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 the registry, you can enumerate files,  directories. So when I say you can work with the 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.  All right. Admins have known about WMI for a very long time.  Like 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.  Only 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  WMIX.XE2, enumerate processes remotely or read registry  values. Okay. 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 this the  WMI service itself. So wind management. Okay. 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. All right.  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 there are 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  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 get SIM 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 DECOM 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 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 Wimic.exe? Cool. Yeah, a lot of you. So this is like to  try it in 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 Wimic.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 Wimic 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 like going to 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  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 Wimic.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 is  not 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 old school articles or VBScript is used. And actually  attackers and some defenders kind of have to resort sometimes  to unfortunately writing VBScript because one of 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. WMI.exe which is very similar to WMI.exe. WMI.  S is kind of like just a wrapper for the Win32 process  create method. So it basically enables you from a Linux system  do lateral movement given credentials or in the case of  the pass 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 logic 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  to 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 2. So if you look this  up in MSDN you would see that logon type 2 refers to  interactive logons. Okay. Now the next one. Select star from  Win32 volume change event where event type equals 2. 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 2  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. 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. So these can either run for the  lifetime of the host process in the case where say you ran  registered WMI event or you can register permanent WMI events  and these are persistent. And the evidence is only located in  a single file that AV will never touch and it runs as  system. So there's two event types, intrinsic and  extrinsic. Once you start digging into 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 a malware  that APT29 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 this 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. 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. This will fire immediately upon any process  starting. So you could use this as a defender for pretty  decent processing 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. 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 physical volumes  say like removable media and registry key change event and  value change event. These are extremely powerful so as a  defender or an attacker start thinking about the creative  ways that you might be able to leverage these events. So once  we registered our event, the thing that we're interested  in triggering off of, we want to do something interesting.  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. And this, 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  that, I believe by default there's like, some of 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 about  DECOM and WinRM. So WinRM or PowerShell Remoting. So  this is 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 will be listening on port 5985. If  you configure it to use certificates over HTTPS then  it will 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 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, yeah, 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  Moff file which is basically a specification for these  certain objects. So they had this Moff 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 Moff 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 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 Mauer. 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  used 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 W32 process  create method to take that namespace on the victim system,  base 64 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 like 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 FireEye  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. All right. 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. All right. 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. All right. If you  want to perform file or directory listings, delete  files, move files, you have some underscore data file. All  right. 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, well, in this case, just call  notepad.exe. From an attack perspective, just imagine  replacing notepad.exe with say PowerShell.exe-coded  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. So we have a little  tradition here at DEF CON. What is it? Shot the noob. Welcome to  DEF CON. Cheers.  That's good. All right. 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 C Daddy was doing. So  C Daddy is the internal Mandiant name that we were using for,  I believe the public family name for this was C Duke. So this  was a Python backdoor that used PowerShell as a WMI  persistence mechanism. So I just pulled that out of the Python  backdoor, 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 a  system start-up. In fact, this attacker just ripped this query  right out of PowerSpoiler. 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 A to T29 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 sim v2 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.  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.  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 com 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 com objects that provide arbitrary data to a  framework. 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 kind of 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. That very night went and  implemented their own proof of concept malicious WMI provider.  Which is awesome. Because 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 installutil.exe. It would do all of its  like com registration and whatnot. 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 there was this large gap in WMI for 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 would 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, APT 29. 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 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 deploying 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 that we could have done and that  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 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 and on 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 we 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. Objects update 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, the bottom mapping  dot 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 head stumps and spent most of our  weekends and full weeks just staring at those head 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  the sizes of the strings. 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  interesting, a string. 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 they're differential  analysis where we have one known good sim repository and then  we apply one change to that sim 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 we're 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 allows  us to do is basically reimplement WQL 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 timestamps 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 forensics immediately  know why that's interesting. We 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, Willie. 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 logical to  physical page number mapping for the index that BTR. And the  logical number, 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 prefix by NS underscore represents the name  space where the instance lives in. The second identifier  prefix by CI underscore is the class name of that instance. And  the last one is prefix by the I 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 BTR, which is 2000  hex. So getting from the logical page number found in the  index, we are using the corresponding mapping in the  map, 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 identified 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. And then 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, the 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 to  validate that nothing weird happened. So to do an artifact  recovery methodology, first we have to construct the search  thing, taking into consideration the artifact name  space, class and name. Stay tuned for the white paper that  will describe this in detail. And then perform a search into  the index BTR doing a prefix match on the key that is  returned. From the key, you get the logical page number, the  artifact records ID and the record size. Based on the  logical page number, you determine the physical number,  page number using the corresponding mapping in the  mapping active mapping that map file. Then in the object 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 found  in the 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 of a page in 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 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. And they are very self-explanatory. And whoever  wants to follow and read the white paper, I'm pretty sure  they'll understand. All right. So we've demonstrated, I hope  that maybe you don't quite fully understand the file format  that we've done. I hope that we do understand it. So the natural  thing for us to do was to kind of build some tools that would  make it easy for you all to take advantage of this knowledge.  And so that's precisely what we did. All right. I wrote a tool  developed in Python, which is a fully nice library object  oriented library. Makes it very easy to interact with a  forensic image that contains a sim repository. All right.  Claudio developed a tool that is written in C++ and is  extremely fast and codifies a lot of our knowledge for  investigating these sim repositories. So we're going to  spend a few minutes now kind of walking through these tools for  you so you understand what you now have at your disposal to  investigate these types of attacks. So Python sim is  simply what I 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. All  right. 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. So it is a very interesting place to look. This  tool provides access to any field that we're able to parse  out and know about. 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, like, all those time stamps if  you want to do time lining. 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 to give you power to go ahead and build  investigative scripts that can quickly triage data. All right.  So this tool is really good for data exploration. So let me see  if I can figure out this. All right. So written in 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. Route Sim V2 is a default namespace. And down here  under route 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. Oh, 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 is  that ‑‑ all right. 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 kind of 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, all  right? 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 timestamp  parsed as 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 that was parsed correctly. 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 timestamps  there. Within each instance that we conjecture is probably the  creation of modification data 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, all right?  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, 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 to, both of these things at your disposal are  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. And let's go into the demo.  Yeah, it doesn't. Okay. Is it working the demo? Okay. So we  started WMI parser, and we saw that the persistence in WMI is  using consumers. So what we're doing here, 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 window 32 payload class the payload value, the payload  property value. The next one is an anti event log called  SEM event log consumer, and another command line event  consumer, which is called BVT consumer, and is 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, 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 basic foreign coded payload.  Which is actually after decoding and then analyzing is a  memory scraper for credit card information data. So we decoded  and we look at it and the most important thing is okay, where  are you hiding the data that you are scraping? So a class  win32 underscore X fill in the root CIMV2 name space,  under track data, it's a good indication. So let's go back to  the WIParser 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 basic foreign coded  value, which after decoding it, we have a serialized object,  which contains the information that was scraped. So it's 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 are in Vegas. So join me. Next.  Cool. So I'd say at this point, we are in a lot better shape  now because we are 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 based 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. So that Python tool  again was really good if you want to programmatic access or  kind of explore the data. And we're going to continue to  update with all of our methodologies along the way that  we are able to discover to identify WMI attacks. So what are  some of the other kind of generic ways 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. So I want to jump into a few things. But I  also want to maybe kind of do 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 additional  interesting pieces of information. So the obvious one  that we've covered a few times already is to look for those  filtered to consumer 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 and use those remotely to store payloads or  pull data out. 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. It's something like recon or back door or I think there  was one that was like almost like bad or something like that. So  even if you're like scanning this thing, it's like that's so  obvious. So at least we can save 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 is in that, you know, what  has been installed persistently or what are the class  definitions, another piece of interesting forensic artifact that  shows up in these object data files 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  to find attacker activity and that's identified 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  and so I saw the modification date there in line in the  similar repository. So I looked at kind of 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 get  that persistence there. 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 are able to finally  decode this stuff with full confidence because let's say two  three months ago when we were trying to do this the first time  we would run strings on the similar repository, objects.data  and we get things that look 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, it just didn't 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? That's something that Matt is  going to talk about next.  All right, so I want you to consider the following. Okay.  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  persists via a WMI permanent event subscription. Okay. 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. Okay. An attacker uses WMI as a C2  channel. Let's take that WMI shell tool that creates and  modifies WMI namespaces and uses that to like stuff payloads  and store the result of executed payloads. Well, instances of  well, sorry, not instances, but the namespace creation event  would trigger in this case. Okay. An attacker uses WMI as a  payload storage mechanism. Very similar to like WMI shell,  but let's say we're talking about APT29. 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 APT29, you would see  the class creation event be fired. All right. Going further,  an attacker persists via say the start menu or the registry.  There's a really valuable WMI class called Win32 startup  command that would capture that very action. So 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 would fire of type Win32  startup command. All right. So an attacker modifies any  additional known like registry persistence locations. One that  comes to the top of my mind is like say you have like a  malicious like LSA plug in 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 change event or registry value change event to trigger  upon the modification of any key or value that you're  specifically targeting. All right. Service creation. This is  easy. All right. And instance creation event is going to fire  of type Win32 service. Are you starting to see this pattern  here? Okay. 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  begged for 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 attack or 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, in 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  let's say an agent list host IDS. We register our own  permanent WMI event subscriptions that detect all kinds of  attack or 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. All right. So I wrote a proof of concept tool  called WMI host IDS. All right. It's effectively an agent  list host-based IDS. It's a single PowerShell module file. So  all you do is you call it 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 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 went 32 startup command  object or a change to a registry key. There's much to be  expanded in this but right now this is just a proof of 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 it is that we're interested in as a  defender. And then we register the respective trigger and 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? The creation of a command line  event consumer which is what the attack used. 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. 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 as well. 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 in action. 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 Symbi2 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 on Win32  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  then 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. All right. So as a defender, I just 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,  look at, check out the MSFT net classes. These 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 out there  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 is you can actually set the namespace  ACLs, like 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 Symbi to 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,  then 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, like without any  privilege on the domain, can go back at any time and  recompromise the domain controller. So that was a  really cool idea. So here's just the respective ACLs being  set. All right. So that's it. Just want to give a shout out to  Wilshire Oder 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. I hope 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 also some  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 because all this code 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 of references here. We'll also share more again in  that white paper. Better mention the flaring out challenge if  you haven't given it a shot yet. Great way to practice reverse  engineering. It 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.  There's a microphone coming around.  All right. Sure. References.  There's a microphone coming. Sorry.  I had a question first. As far as the  trying to downgrade how many classes there are to go through,  is there any possibility in terms of forming master hash  libraries to go through that? Or is that modified, create  timestamps, 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. And that would be  probably limit it down 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. We'll try it after.  As kind of a follow up to that, are there any techniques that  you can share for doing this at scale for identifying  malicious providers across an entire environment?  I think the most obvious one at this point 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 of all the  techniques we've seen. 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 something that you should  give a look at and say, okay, 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.  But yeah, just it might be worth noting, whenever any new WMI  provider is created, you could say trigger off of instance  creation event of type underscore underscore win32  provider. And then 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. Yep.  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.  Okay.  Yeah, I mean if in your organization you're doing  completely legitimate things with WMI remotely, then yeah, you  would want to be mindful of that. Say you could create like,  you know, 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?  It's like any 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 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 like modern OS's where you have some like this new  technology called desired state configuration that like relies  very, very heavily upon WMI under the hood. So yeah, I would  just be aware of that. Yeah.  Okay, 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. So thank  you for that. I have a few questions. First is I write my  own custom more files to do different stuff. So most of your  differential analysis is comparing with a clean machine  with the one so how does my more file play into that? You're  going to trip my more file for sure. Okay, well, so backing up  a little bit. We didn't really cover a moth very much only  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 moth file. So you could use a moth file to carry  out the same exact attacks that the attackers are doing.  Only a moth 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  moth file gets you is persistence beyond WMI  repository corruption. So not sure if you want to ask your  question again to see how maybe moth might play into all  this. My second question is for Willie with that Python tool.  So how do you handle WMI recompile which is pretty  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 moth and recompile the  repository and I mean all my timelines would be aligned right  after that. Sure. Right. So we're exploring how the  timelines are affected right now by inserting new data into  the same repository and taking it out. Our understanding right  now is as you insert dynamically or via moth files new  classes not all the time stamps change within the same  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? I mean  it's a good start. So another thing is you used CCM recently  used apps. So how do you track that in environments which  doesn't use CCM? 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 SCM and so this is a useful artifact for  us to look for as a consulting company but if you're not using  that in your organization you may not find it as useful for  sure. Question for Claudia about the objects.data. Did you try  taking objects.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. Exactly.  But my point is this if you dump it in there can you do a  diff on different instances which can go into that? I mean  just a thought. I'm asking. Usually you don't take only the  objects that data. As Willie was explaining you have to have  all the files. In order to get to all the data and how the data  is constructed in object that data you need a mapping file.  Because if you have a record that is bigger than the page size  there will be different chunks of the different offsets. It's  not sequential. So that's one of the things but no we didn't go  and put it in and doing a diff. Yeah, that's correct. Yeah, you  can go. But the next big thing that we want to invest some  time in is recovering deleted artifacts. Because the mapping  that 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 page that is in the free pages  array and look for artifacts there. And you can do both for  both index.btr and for objects that data. Yeah, so imagine the  attackers 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 clean up 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. Depends on how much you charge. So a lot of the  forensic analysis is focused on finding out what exactly is  the 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. My question is this you are coming  into an exploited system after point X after something has  happened or unless you are looking at it with your WMI  IDS 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 and if you  have a consumer there is no persistence. You know what I'm  saying? I think you are right. We see the persistence  mechanism installed but we don't quite know if it fired and  the payload is executed. 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 the run key  executed and caused the payload to execute but that's usually  enough to kick off your investigation and say there is  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 that caused the consumer to execute. Would you  agree with that?  I understand what you are saying. We are in agreement.  Cool.  More questions?  Sure.  The B3 file which you are analyzing. I know that there are  certain stuff which stands out. Meaning the name. A lot of  this analysis is very name based. I would say let's say if  you are 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 because that's the part of it.  My point is there are B3s where your repository is stored. Is  there any differential analysis which you can?  No. The B3 stores some representation of different  artifacts. 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  name space full path and the class name. That represents a  key into the index BTR. This is how you are able to query the  objects that data through this representation by finding the  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 objects that data.  Question for Matt. Development class without auto  recover. Development class defined without auto recover  meaning I drop it, it fires off once and goes away.  If you had a mall file that still did WMI persistence, it  would still persist even without Pracma auto recover.  We will recover everything and recompile that mall after the  rebuilding of the SIM database. We will take any further  questions offline and we can talk about this for hours.  We will be right outside. Thanks again for staying so long  and missing out on the car hacking talk. I really appreciate it.
DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_0_1739.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_1740_3251.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_3252_4547.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_4548_4595.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_4596_5195.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_5196_5243.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_5244_5699.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_5700_6143.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_6144_6275.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_6276_6335.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_6336_6551.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_6552_6695.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_6696_6959.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_6960_7079.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_7080_7283.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_7284_7331.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_7332_8399.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_8400_10751.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_10752_12755.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_12756_13403.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_13404_13487.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_13488_16727.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_16728_20771.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_20772_22931.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_22932_28019.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_28020_28379.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_28380_33215.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_33216_33263.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_33264_36275.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_36276_38339.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_38340_40091.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_40092_42011.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_42012_42695.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_42696_42767.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_42768_43883.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_43884_45623.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_45624_46307.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_46308_46355.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_46356_52007.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_52008_53111.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_53112_54179.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_54180_55187.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_55188_56267.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_56268_56531.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_56532_59903.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_59904_60083.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_60084_62927.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_62928_65651.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_65652_66035.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_66036_73703.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_73704_75431.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_75432_79139.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_79140_84707.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_84708_86699.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_86700_87779.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_87780_88379.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_88380_89099.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_89100_89543.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_89544_90467.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_90468_92027.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_92028_92219.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_92220_92279.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_92280_93299.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_93300_93347.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_93348_93479.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_93480_93875.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_93876_93923.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_93924_93995.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_93996_94835.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_94836_96047.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_96048_97763.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_97764_98831.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_98832_99791.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_99792_99959.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_99960_100007.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_100008_100055.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_100056_100547.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_100548_100607.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_100608_101027.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_101028_101123.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_101124_101207.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_101208_101423.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_101424_101507.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_101508_101747.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_101748_101795.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_101796_102071.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_102072_102683.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_102684_102731.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_102732_103247.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_103248_103307.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_103308_103355.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_103356_103451.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_103452_103499.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_103500_103643.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_103644_103727.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_103728_103775.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_103776_103823.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_103824_103871.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_103872_104195.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_104196_104663.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_104664_104831.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_104832_105047.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_105048_105335.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_105336_105875.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_105876_105935.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_105936_113627.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_113628_113735.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_113736_116387.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_116388_119195.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_119196_119831.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_119832_121127.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_121128_121895.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_121896_122975.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_122976_123743.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_123744_124859.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_124860_125135.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_125136_125507.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_125508_125627.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_125628_127115.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_127116_128663.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_128664_128711.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_128712_129263.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_129264_130019.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_130020_130127.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_130128_131519.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_131520_131915.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_131916_132575.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_132576_134159.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_134160_134303.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_134304_136199.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_136200_136295.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_136296_136439.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_136440_136979.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_136980_137243.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_137244_138695.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_138696_139883.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_139884_140903.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_140904_143723.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_143724_143771.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_143772_145043.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_145044_145247.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_145248_147695.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_147696_149219.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_149220_150515.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_150516_150599.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_150600_151187.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_151188_151439.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_151440_151871.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_151872_152195.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_152196_152243.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_152244_156887.png DEF_CON_23_-_Panel_-_WhyMI_so_Sexy__WMI_Attacks_-_Real_Time_Defense_and_Advanced_Forensics_xBd6p-Lz3_156888_158150.png
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 attackers that may compromise say 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 back door 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. So 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. All right. 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 in objects. I'm not dumping text here. I dumped the fully parsed track data in the form of a properly 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. 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 FireEyes 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, malware-less 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 this. 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 Oderescu. I 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 NKs for the past 10 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 WKL 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 the WMI attack detection. All right. 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 management of resources and devices in an enterprise. All right. 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. All right. 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 the registry, you can enumerate files, directories. So when I say you can work with the 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. All right. Admins have known about WMI for a very long time. Like 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. Only 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 WMIX.XE2, enumerate processes remotely or read registry values. Okay. 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 this the WMI service itself. So wind management. Okay. 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. All right. 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 there are 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 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 get SIM 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 DECOM 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 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 Wimic.exe? Cool. Yeah, a lot of you. So this is like to try it in 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 Wimic.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 Wimic 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 like going to 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 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 Wimic.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 is not 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 old school articles or VBScript is used. And actually attackers and some defenders kind of have to resort sometimes to unfortunately writing VBScript because one of 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. WMI.exe which is very similar to WMI.exe. WMI. S is kind of like just a wrapper for the Win32 process create method. So it basically enables you from a Linux system do lateral movement given credentials or in the case of the pass 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 logic 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 to 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 2. So if you look this up in MSDN you would see that logon type 2 refers to interactive logons. Okay. Now the next one. Select star from Win32 volume change event where event type equals 2. 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 2 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. 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. So these can either run for the lifetime of the host process in the case where say you ran registered WMI event or you can register permanent WMI events and these are persistent. And the evidence is only located in a single file that AV will never touch and it runs as system. So there's two event types, intrinsic and extrinsic. Once you start digging into 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 a malware that APT29 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 this 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. 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. This will fire immediately upon any process starting. So you could use this as a defender for pretty decent processing 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. 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 physical volumes say like removable media and registry key change event and value change event. These are extremely powerful so as a defender or an attacker start thinking about the creative ways that you might be able to leverage these events. So once we registered our event, the thing that we're interested in triggering off of, we want to do something interesting. 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. And this, 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 that, I believe by default there's like, some of 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 about DECOM and WinRM. So WinRM or PowerShell Remoting. So this is 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 will be listening on port 5985. If you configure it to use certificates over HTTPS then it will 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 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, yeah, 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 Moff file which is basically a specification for these certain objects. So they had this Moff 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 Moff 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 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 Mauer. 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 used 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 W32 process create method to take that namespace on the victim system, base 64 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 like 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 FireEye 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. All right. 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. All right. 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. All right. If you want to perform file or directory listings, delete files, move files, you have some underscore data file. All right. 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, well, in this case, just call notepad.exe. From an attack perspective, just imagine replacing notepad.exe with say PowerShell.exe-coded 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. So we have a little tradition here at DEF CON. What is it? Shot the noob. Welcome to DEF CON. Cheers. That's good. All right. 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 C Daddy was doing. So C Daddy is the internal Mandiant name that we were using for, I believe the public family name for this was C Duke. So this was a Python backdoor that used PowerShell as a WMI persistence mechanism. So I just pulled that out of the Python backdoor, 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 a system start-up. In fact, this attacker just ripped this query right out of PowerSpoiler. 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 A to T29 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 sim v2 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. 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. 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 com 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 com objects that provide arbitrary data to a framework. 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 kind of 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. That very night went and implemented their own proof of concept malicious WMI provider. Which is awesome. Because 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 installutil.exe. It would do all of its like com registration and whatnot. 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 there was this large gap in WMI for 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 would 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, APT 29. 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 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 deploying 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 that we could have done and that 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 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 and on 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 we 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. Objects update 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, the bottom mapping dot 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 head stumps and spent most of our weekends and full weeks just staring at those head 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 the sizes of the strings. 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 interesting, a string. 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 they're differential analysis where we have one known good sim repository and then we apply one change to that sim 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 we're 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 allows us to do is basically reimplement WQL 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 timestamps 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 forensics immediately know why that's interesting. We 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, Willie. 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 logical to physical page number mapping for the index that BTR. And the logical number, 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 prefix by NS underscore represents the name space where the instance lives in. The second identifier prefix by CI underscore is the class name of that instance. And the last one is prefix by the I 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 BTR, which is 2000 hex. So getting from the logical page number found in the index, we are using the corresponding mapping in the map, 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 identified 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. And then 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, the 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 to validate that nothing weird happened. So to do an artifact recovery methodology, first we have to construct the search thing, taking into consideration the artifact name space, class and name. Stay tuned for the white paper that will describe this in detail. And then perform a search into the index BTR doing a prefix match on the key that is returned. From the key, you get the logical page number, the artifact records ID and the record size. Based on the logical page number, you determine the physical number, page number using the corresponding mapping in the mapping active mapping that map file. Then in the object 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 found in the 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 of a page in 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 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. And they are very self-explanatory. And whoever wants to follow and read the white paper, I'm pretty sure they'll understand. All right. So we've demonstrated, I hope that maybe you don't quite fully understand the file format that we've done. I hope that we do understand it. So the natural thing for us to do was to kind of build some tools that would make it easy for you all to take advantage of this knowledge. And so that's precisely what we did. All right. I wrote a tool developed in Python, which is a fully nice library object oriented library. Makes it very easy to interact with a forensic image that contains a sim repository. All right. Claudio developed a tool that is written in C++ and is extremely fast and codifies a lot of our knowledge for investigating these sim repositories. So we're going to spend a few minutes now kind of walking through these tools for you so you understand what you now have at your disposal to investigate these types of attacks. So Python sim is simply what I 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. All right. 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. So it is a very interesting place to look. This tool provides access to any field that we're able to parse out and know about. 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, like, all those time stamps if you want to do time lining. 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 to give you power to go ahead and build investigative scripts that can quickly triage data. All right. So this tool is really good for data exploration. So let me see if I can figure out this. All right. So written in 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. Route Sim V2 is a default namespace. And down here under route 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. Oh, 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 is that ‑‑ all right. 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 kind of 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, all right? 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 timestamp parsed as 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 that was parsed correctly. 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 timestamps there. Within each instance that we conjecture is probably the creation of modification data 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, all right? 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, 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 to, both of these things at your disposal are 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. And let's go into the demo. Yeah, it doesn't. Okay. Is it working the demo? Okay. So we started WMI parser, and we saw that the persistence in WMI is using consumers. So what we're doing here, 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 window 32 payload class the payload value, the payload property value. The next one is an anti event log called SEM event log consumer, and another command line event consumer, which is called BVT consumer, and is 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, 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 basic foreign coded payload. Which is actually after decoding and then analyzing is a memory scraper for credit card information data. So we decoded and we look at it and the most important thing is okay, where are you hiding the data that you are scraping? So a class win32 underscore X fill in the root CIMV2 name space, under track data, it's a good indication. So let's go back to the WIParser 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 basic foreign coded value, which after decoding it, we have a serialized object, which contains the information that was scraped. So it's 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 are in Vegas. So join me. Next. Cool. So I'd say at this point, we are in a lot better shape now because we are 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 based 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. So that Python tool again was really good if you want to programmatic access or kind of explore the data. And we're going to continue to update with all of our methodologies along the way that we are able to discover to identify WMI attacks. So what are some of the other kind of generic ways 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. So I want to jump into a few things. But I also want to maybe kind of do 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 additional interesting pieces of information. So the obvious one that we've covered a few times already is to look for those filtered to consumer 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 and use those remotely to store payloads or pull data out. 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. It's something like recon or back door or I think there was one that was like almost like bad or something like that. So even if you're like scanning this thing, it's like that's so obvious. So at least we can save 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 is in that, you know, what has been installed persistently or what are the class definitions, another piece of interesting forensic artifact that shows up in these object data files 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 to find attacker activity and that's identified 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 and so I saw the modification date there in line in the similar repository. So I looked at kind of 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 get that persistence there. 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 are able to finally decode this stuff with full confidence because let's say two three months ago when we were trying to do this the first time we would run strings on the similar repository, objects.data and we get things that look 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, it just didn't 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? That's something that Matt is going to talk about next. All right, so I want you to consider the following. Okay. 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 persists via a WMI permanent event subscription. Okay. 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. Okay. An attacker uses WMI as a C2 channel. Let's take that WMI shell tool that creates and modifies WMI namespaces and uses that to like stuff payloads and store the result of executed payloads. Well, instances of well, sorry, not instances, but the namespace creation event would trigger in this case. Okay. An attacker uses WMI as a payload storage mechanism. Very similar to like WMI shell, but let's say we're talking about APT29. 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 APT29, you would see the class creation event be fired. All right. Going further, an attacker persists via say the start menu or the registry. There's a really valuable WMI class called Win32 startup command that would capture that very action. So 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 would fire of type Win32 startup command. All right. So an attacker modifies any additional known like registry persistence locations. One that comes to the top of my mind is like say you have like a malicious like LSA plug in 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 change event or registry value change event to trigger upon the modification of any key or value that you're specifically targeting. All right. Service creation. This is easy. All right. And instance creation event is going to fire of type Win32 service. Are you starting to see this pattern here? Okay. 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 begged for 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 attack or 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, in 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 let's say an agent list host IDS. We register our own permanent WMI event subscriptions that detect all kinds of attack or 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. All right. So I wrote a proof of concept tool called WMI host IDS. All right. It's effectively an agent list host-based IDS. It's a single PowerShell module file. So all you do is you call it 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 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 went 32 startup command object or a change to a registry key. There's much to be expanded in this but right now this is just a proof of 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 it is that we're interested in as a defender. And then we register the respective trigger and 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? The creation of a command line event consumer which is what the attack used. 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. 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 as well. 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 in action. 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 Symbi2 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 on Win32 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 then 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. All right. So as a defender, I just 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, look at, check out the MSFT net classes. These 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 out there 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 is you can actually set the namespace ACLs, like 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 Symbi to 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, then 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, like without any privilege on the domain, can go back at any time and recompromise the domain controller. So that was a really cool idea. So here's just the respective ACLs being set. All right. So that's it. Just want to give a shout out to Wilshire Oder 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. I hope 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 also some 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 because all this code 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 of references here. We'll also share more again in that white paper. Better mention the flaring out challenge if you haven't given it a shot yet. Great way to practice reverse engineering. It 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. There's a microphone coming around. All right. Sure. References. There's a microphone coming. Sorry. I had a question first. As far as the trying to downgrade how many classes there are to go through, is there any possibility in terms of forming master hash libraries to go through that? Or is that modified, create timestamps, 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. And that would be probably limit it down 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. We'll try it after. As kind of a follow up to that, are there any techniques that you can share for doing this at scale for identifying malicious providers across an entire environment? I think the most obvious one at this point 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 of all the techniques we've seen. 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 something that you should give a look at and say, okay, 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. But yeah, just it might be worth noting, whenever any new WMI provider is created, you could say trigger off of instance creation event of type underscore underscore win32 provider. And then 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. Yep. 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. Okay. Yeah, I mean if in your organization you're doing completely legitimate things with WMI remotely, then yeah, you would want to be mindful of that. Say you could create like, you know, 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? It's like any 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 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 like modern OS's where you have some like this new technology called desired state configuration that like relies very, very heavily upon WMI under the hood. So yeah, I would just be aware of that. Yeah. Okay, 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. So thank you for that. I have a few questions. First is I write my own custom more files to do different stuff. So most of your differential analysis is comparing with a clean machine with the one so how does my more file play into that? You're going to trip my more file for sure. Okay, well, so backing up a little bit. We didn't really cover a moth very much only 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 moth file. So you could use a moth file to carry out the same exact attacks that the attackers are doing. Only a moth 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 moth file gets you is persistence beyond WMI repository corruption. So not sure if you want to ask your question again to see how maybe moth might play into all this. My second question is for Willie with that Python tool. So how do you handle WMI recompile which is pretty 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 moth and recompile the repository and I mean all my timelines would be aligned right after that. Sure. Right. So we're exploring how the timelines are affected right now by inserting new data into the same repository and taking it out. Our understanding right now is as you insert dynamically or via moth files new classes not all the time stamps change within the same 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? I mean it's a good start. So another thing is you used CCM recently used apps. So how do you track that in environments which doesn't use CCM? 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 SCM and so this is a useful artifact for us to look for as a consulting company but if you're not using that in your organization you may not find it as useful for sure. Question for Claudia about the objects.data. Did you try taking objects.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. Exactly. But my point is this if you dump it in there can you do a diff on different instances which can go into that? I mean just a thought. I'm asking. Usually you don't take only the objects that data. As Willie was explaining you have to have all the files. In order to get to all the data and how the data is constructed in object that data you need a mapping file. Because if you have a record that is bigger than the page size there will be different chunks of the different offsets. It's not sequential. So that's one of the things but no we didn't go and put it in and doing a diff. Yeah, that's correct. Yeah, you can go. But the next big thing that we want to invest some time in is recovering deleted artifacts. Because the mapping that 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 page that is in the free pages array and look for artifacts there. And you can do both for both index.btr and for objects that data. Yeah, so imagine the attackers 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 clean up 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. Depends on how much you charge. So a lot of the forensic analysis is focused on finding out what exactly is the 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. My question is this you are coming into an exploited system after point X after something has happened or unless you are looking at it with your WMI IDS 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 and if you have a consumer there is no persistence. You know what I'm saying? I think you are right. We see the persistence mechanism installed but we don't quite know if it fired and the payload is executed. 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 the run key executed and caused the payload to execute but that's usually enough to kick off your investigation and say there is 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 that caused the consumer to execute. Would you agree with that? I understand what you are saying. We are in agreement. Cool. More questions? Sure. The B3 file which you are analyzing. I know that there are certain stuff which stands out. Meaning the name. A lot of this analysis is very name based. I would say let's say if you are 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 because that's the part of it. My point is there are B3s where your repository is stored. Is there any differential analysis which you can? No. The B3 stores some representation of different artifacts. 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 name space full path and the class name. That represents a key into the index BTR. This is how you are able to query the objects that data through this representation by finding the 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 objects that data. Question for Matt. Development class without auto recover. Development class defined without auto recover meaning I drop it, it fires off once and goes away. If you had a mall file that still did WMI persistence, it would still persist even without Pracma auto recover. We will recover everything and recompile that mall after the rebuilding of the SIM database. We will take any further questions offline and we can talk about this for hours. We will be right outside. Thanks again for staying so long and missing out on the car hacking talk. I really appreciate it.
are here to talk about WMI, Windows Management Instrumentation. We're going to talk about at Mandiant and FireEye, we have seen attackers throughout the presentation to kind of show how you're going to see here is from this red forensic artifacts that that attack left behind. kind of developing additional techniques with you me on Twitter. I'm also a reverse engineer on the FireEyes Labs Advanced Reverse Engineering team. research, writing forensic parcel for NKs for the Since we have to cover a lot of information in go into forensic data, like file format, mitigations. And then forensics on the formats of here's kind of the overlying architecture of WMI. provides the WMI service with the information seen it used by a lot of malware samples actually crude like VM detection and then like exit out of enables you from a Linux system do lateral in these WMI repository looking for objects, these events. What's really cool about WMI is defenders and attackers. So we can craft these events. So there's some really like valuable like the official remote management protocol that processes. So it's just a different set of there's a Romanian researcher who developed WMI that as an attacker you can do with WMI. So from lateral movement, persistence as we already know, data storage with code execution and getting a to go about doing reconnaissance with WMI, these processes on an operating system or not host, used in the wild. So we thought it would be can do with it and so forth. Matt gave a great know how to parse it. And that's really exciting. page number of a certain artifact, you have to the value of that index represents the physical page number. In this example, in the physical found in the index, we are using the for the white paper that will describe this in detail. And then perform a search into the index knowledge for investigating these sim that's supported by the system that you can query repository. So here we are looking at the various the way, methodology, finding persistence, and be in the sim repository and this is a way that repository to find attacker activity and that's due to the way that the file is paged and because So let's take the case of an attacker using WMI there's going to be a WQL query that can So let's see this in action. So here's our detection of this in action. And so like what this to detect activity in real time. There's a can use PowerShell to detect WMI persistence cool, like, pure incident response framework for PowerShell that also has some WMI detection. techniques and also some forensic techniques. So before this talk, we finalized and asked to be hacking cars talk and see the end of it. There's forming master hash libraries to go through that? moth file to carry out the same exact attacks Python tool. So how do you handle WMI recompile don't have the ability to parse at the moment but