Good afternoon DEFCON. Excited to be here. Before we jump into the content I want to start with a personal observation. Working as a consultant that gets to see hundreds of thousand of compromised systems, a remarkable shift we've seen is away from malware that is a discreet file in the file system that is easy to find as an analyst, to attacks that are more difficult because they don't use malware or the payload is stored in unusual places. Attackers that compromise the VPN and use RDP and don't compromise the environment and steal the recipe for coke. The storing of the whole payload in the registry. This is yet another variant of this. Another technique to use as offense. Pentesters getting into environments and from a defense perspective. How do we investigate these attacks. We are here to talk about WMI, Windows management. We're going to talk about practical attaches. Not just the theoretical. We have seen attackers use these techniques and even more advanced techniques to compromise environments and further their goals. As investigators going around, there is not much out there in terms of doing the investigation. It's difficult. We have gotten lucky in many cases and looking into the future we can't expect to be lucky. We'll be covering that today. In order to motivate this presentation, so you understand practically what this means and how powerful these techniques are. Matt is going to introduce a demo that we'll use throughout the presentation to show how these techniques work. Will you take it from there, Matt? >> I wrote a very crude basic credit card track data scraper. 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 WMI. I 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 going to use WMI as a pure C2 channel and exfiltrate data back to the attacker system. I'm going to provide the credentials to the victim machine and all in the back ground over the WMI port. It's going to install the payload. 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. This is our fictitious payment process. I paste in some fake but valid track data. Track one and track two data. (audio blipped). If everything worked properly, over WMI using it as a pure C2 channel, I can pull back that fully parsed data and because I love PowerShell so much, I love the fact that everything is an object. I'm not dumping text. I dumped the track data in a form of a properly parsed out PowerShell object. So the attack that you just saw -- I'm sorry I'm not going to release the source code for it. We're going to use this to drive a mock investigation. We developed amazing tools to parse out the WMI or the SIM repository, you'll hear us use these terms interchangeably. They parse out all the forensic artifacts that attack left behind. 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 impressed? >> I'm Willi Ballenthin. A group of 20 reverse engineers working on the mall IQ there. What I like most is I get to do a ton of research, investigate new technologies that are coming out. Or WMI something that has been around for 20 years and turn it into something usable for you. I don't want ask you if you're on the blue team. I love helping you guys out and I look forward to 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? Great. I'm Matt Graeber. A reverse engineer. Been a speaker at various conferences. BlackHat trainer. As you may or may not know, I'm a (audio blipped) fan boy, probably to a fault. I personally subscribe to what myself and my friend Chris Campbell referred to as the living off the land mind set. As an attacker you should have the minimum footprint possible. We are advocates of using the -- infections. Say you're running PowerShell payloads purely in memory or the WMI techniques that we'll discuss here shortly. Traditionally security products perform all kinds of introspection on things on disk. We really don't have to drop too many payloads to disk. It's very powerful for defenders. There is not a single payload that AV can't touch that can be really introspected by a traditional security product. And I'm a new -- I don't really claim to know what I'm talking about, but here I am. >> Hello, everybody. I'm Claudiu Teodorescu. My middle name is a translation of my last name in English. That is what I heard. I'm a reverse engineer for the team. I do forensic research writing forensic parsing for the past ten years. So my background is forensics. I'm a crypto enthusiast. [indiscernible]. My parents had a different idea about that. We have to cover a lot of information in this presentation. The outline is two page long so bear with me. First the background, motivation, and attack examples. We go into the WMI architecture and WPL core language. Follow up with eventing and remote WMI and a brief history of WMI attacks from malware perspective. And WMI providers. And then we go into forensic data, file formatting, investigation, realtime, defense and mitigations. And forensics on the formats of the files. The SIM repository. And we finish with a mock investigation and WMI attack detection. >> Let's cover the basics first. Many of you know what WMI is. But just real quickly, WMI stands for Windows management instrumentation. This is Microsofts open standards that strive to automate just management of resources and devices in an enterprise. It's extremely powerful locally and remotely. Attackers have realized that this WMI service has been listening on every Window's system since Windows 98 and MP4. From a Window's ten attacker may sheen, you can easily compromise a Windows 98 system given that you have the proper credentials. WMI can be used to do a lot of things but some highlights are, you can enumerate files and directories. When I say you can work with the registry, you can read from it, write to it, you can subscribe to events. This is one of the killer features that I'll explain in PowerShell. And you can execute commands. There is a bunch of my classes that have these built-methods. One of which is used heavily, the win 32 which is used for (audio blipped) and lateral movement and I'll have examples of those. I'll probably say this often. Any technology that is useful for administrators is useful for attackers, too. Admins have known about WMI for a long time. If you Google various articles on WMI event subscriptions you'll see these great articles going back to the late 90s and early 2000s. It hasn't been until 2010 that we saw an up tick in attackers starting to realize just how powerful this technology is. All right. So here is the overlying architecture of WMI. Over-on the left side you see all these client utilities. WMI you can think of as like a client-server model where we have all these clients, say you want to use a client like win dot XE2 and use processes remotely or read registry value. These fall under the clients and there are tools to allow you to do that. Ultimately I would call it a server process, the WMI service itself. So win management. This is running on every one of your Window's systems whether you realize it or not. On part 185 or part 1589 by default. These clients you can either straight up execute methods directly, enumerate all instances of a certain class. You can get pretty specific with what events you want to subscribe to or objects you want to enumerate by using the main specific language called WQL. It's SQL like syntax that allows you to manipulate objects and whatnot. There are two basic protocols that WMI uses. The classic is D con and the more recent is Windows remote management. I will use win RM and PowerShell interchangeably. Just be aware of these two protocols where you can use WMI remotely. WMI wouldn't be useful without a bunch of providers. Say you want to enumerate all the running processes. (audio blipped) there is a DLL on disk that provides the WMI service with the information you're requesting. There is a bunch of WMI providers and these give you the functionality and allow as the defender or attacker to potentially extent the functionality of WMI. And then everything in WMI is backed by this one particular file called, the WMI or SIM repository and Willi and Claudiu are going to get into this. There is valuable -- in there but there is no way to parse these offline in a forensically sound fashion. I'm going to cover a few of these, my favorite including PowerShell. I say this because right out of the box you have all of these commands listed. You have a set of WMI command lets and SIM command lets. We can enumerate class instances, WMI -- events in the local shell power context but also do some on a permanent fashion as well. Remove class instances as well. There is also as a PowerShell three and above there are a bunch of SIM command lets and they're more or less the same as the WMI command lets but they provide more functionality. You can call get SIM class to parse out the schema of a bunch of WMI objects (audio blipped) valuable objects. That might be useful to an attacker or a defender. Also these SIM command lets can talk over Dcom and win RM. That something to think of when you're working in more modern environments. These are the command lets that you'll get the most value out of. There are a bunch of other utilities. Who used WIMIC.EXE? A lot of you. It's been out forever. Since WMI has been out, going back to Windows 98. It's powerful. It gets the job done. I've seen this used pretty heavily for example for lateral movement where the win 32 process is used or lateral movement. Haven't seen it used a lot for persistence. But I've seen it used for a lot of malware samples where they use certain WMI object instances like the win 32 bios class where they do something crude like VM detection and exit out of the malware process or do something -- like a sleep loop. [indiscernible] Another really cool utility that you may not be aware of is WBEM test. This is like -- it's a crappy GUI utility, the UI is terrible but it's powerful. I have used this on assessments a long time ago when I didn't have access to win dot EXE, I was able to use this to get around their application. Because this utility was white listed. If on assessments you're blocked by using some utilities that might be available. This one isn't too well known, you can use win RM assuming the service is listening on your local or remote system. This can be used to enumerate class instances. You can use it to set win RM settings. You can also use VD script, J scripts. People have been doing this for. If you go and Google how to install a permanent WMI subscription you would see a lot of old-school articles where VD script is used. Attackers and some defenders have to resort sometimes to writing VD script. One of the built-in payloads you can do with this thing with WMI is you can embed a VD script in there. There are good Linux ones. WMIC, WMIS is a wrapper for the win 32 process create method. It enables you to promote a Linux system, do lateral movement given credentials or in the case of the pass the hash variant, you can provide a hash to do your lateral movement and code execution. There is cool research utilities as well. If you're interested in dicking around in these WMI repository looking for objects, methods or events of interest, check out SIM studio or WMI explorer. Finally if you're going to incorporate some techniques into your own code, plus plus or -- use various APIs to work with. Aside from the client utilities, if you want to be able to do some slightly more advanced options with WMI, then it would behoove you to learn WQL. It's very -- syntax. Allows you to do three things. There is three classes of queries, instance queries where you're interested in logic instance. Say like if you want to enumerated. And meta queries are high level queries where you can use these to determine like what classes may or may not exist in the WMI repository. What is what an instance query might look like. Look at the example. Select star from win 32 process. I'm interested in having all win 32 process instances returned to me in all properties. That's a star. You can specify just a single property name but usually you give it a star because you may be interested in all of the properties. You can provide an additional constraint. Instead of providing all win 32 process objects give me the ones that just have the word "chrome" in them. The event queries are more complex. There is a little bit of a learning curve. I hope to prove to you eventually these things are really, really powerful. There's two classes of event queries. There is queries for intrinsic and extrinsic events. But look at these examples here. The first example at a high level, we want to target all interactive log ons. So the way you describe that in a WMI query is you want to target all instance creation events. So this event will fire upon (audio blipped) WMI class instance. What we're interested in is all instances that are of type win 32 log on session, within 15. With these queries you have to specify a polling interval because they trigger all the time. You have to specify a polling interval. We're interested in any win 32 log on where time equals 2. You see that log on type 2 refers to interactive log ons. Now the next one. Select star from win 32 volume change where event type equals 2. This is an extrinsic event. This fires immediately upon this event firing. What does this event do? If you look up, you see event type 2 refers to removable (audio blipped) you have something that triggers and can do something interesting when someone inserts a USB stick. The last example is self-explanatory. This trigger will fire upon the registry key, the run key changing in HKLM. Let's dig into eventing. You saw some examples of how the WQL event queries can be used. What is cool about WMI if you enumerate every class definition, on this Windows 7, the slides are being driven from, there is just under 8,000WMI classes. There are really interesting classes with valuable information to defenders and attackers. We can craft these queries based upon some of the examples that you saw previously. You'll see more valuable examples coming up later. Attackers seem to enjoy using WMI system 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 realtime. It's easy say like using autoruns to detect it used after the fact but in realtime it's a challenge. So in order to use WMI for persistence you need a filter which is a WQL query. This describes the event you want to trigger off of. A consumer. This is what you want to do upon firing that event. And then a binding. This is the registration mechanism that takes the filter and the consumer and actually like installs them. So these can run for the lifetime of the host process (audio blipped) or you can register permanent and these are persistent and the evidence is only located in a single file that AV will never touch and runs a system. So there's two event types, intrinsic and extrinsic. Once you start digging into WMI classes you will see there are a ton of classes that are organized into name spaces. Not unlike any typical object oriented language. So within each of these name spaces you have the following system classes defined. When I say system class I refer to any class that begins with these two underscores here. Within each space you have all these intrinsic eventers. There is really valuable queries that you can subscribe to. I use the instance creation event to trigger off of. Whenever an object is create offed the type that I'm targeting, then I can go and do something with that accordingly. There are some malware that -- was using that created dynamically it's own custom WMI classes and using it like they were stuffing data into there. You can create a query that would trigger on the class creation event for example. There is another tool with a WMI as a C2 channel by identifying and changing name spaces. You have intrinsic events that could fire off the malicious events as well. Extrinsic are more specialized. These are highly performance events. They fire immediately. You don't specify the polling interval. We have the win 32 process start trace event. This fires immediately upon any process starting. So you can use this as a defender for pretty decent processing command line auditing. You can 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 module load trace. Every single executable DLL device driver, this event will fire. If you subscribe to that you can get interesting information. You have the volume change event that has to do with physical volume. Removable media. And registry key change event and value change event. These are self-explanatory. These are extremely powerful. As a defender and attacker think of the creative ways you might be able to leverage these events. So once we registered our eventer, the thing that we're interested in triggering off of, we want to do something interesting. Microsoft provides five standard event consumers. These things effectively execute the payload upon triggering the event. Log file then consumer. Active script event consumer. Attackers enjoy this one. It allows you to embed (audio blipped) J script that executes immediately upon the event triggers. Anti-event log consumer. There's already a lot [indiscernible] information within the event log and hopefully you constantly inspect those event logs. WMI can be used to cover all the gaps. Say there is some event that you're interested in where there is no event log entry. You can use this event consumer to supplement the existing antilog entries. There is SMTM event consumers. Fire off an email. And [indiscernible] very popular with attackers for obvious reasons. So again, for permanent WMI events we need a filter, an event consumer class. The consumer one of the 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 that performs the registration and does the insulation of these events local or remotely. A little about the protocols used by WMI. The one that's been around forever is DCOM. WMI service will listen on port 135 to establish an initial connection. All subsequent connections will be established on a separate port dictated by this registry key. I believe by default there is like a large range of ports here. You can use the DCOM.EXE making it more firewall friendly in your enterprise. (audio blipped) on a remote system using DCOM. The DCOM protocol is -- WMI command list. Not to be mistaken with the SIM command list. So WINRM. A soap based protocol. Soap inherently contains all this rich type information that can transmit and receive PowerShell objects and WMI information. It's encrypted by default. Out of the box it is listening on port 5985. If you configure it to use certificates it will listen on port 5986. This is like the official remote management protocol that Microsoft is pushing hard. If you take a server 2012 machine, you would find the only port listening on this machine is 5985. Microsoft is pushing this hard. Here is an example of me using the SIM commandlets rather, I'm using the win RM protocol to do the same thing that I did with DCOM previously. Here the SIM commandlets to enumerate processes. (audio blipped) attacks. As far as I can tell the first WMI attack that came to my attention was with [indiscernible]. What stucks net did is exploited the Windows printer spooler vulnerability. Effectively they got an arbitrary -- right vulnerability. Imagine, if as an attacker you could write a file anywhere on the Windows system to gain code execution, what file would it be and where would you write it do? The developers of stuck net are intelligent and they created a specification for these certain objects. They had this moth file that allowed them to gain persistence and when you do WMI persistence -- they dropped the file into this directory. And there was a watchdog process that looked for new moth files and consumes them if it saw a new one. All they did was installed this anti, I believe shortly after systems start up. It executes another executable they dropped in the system context. (audio blipped) then in the same year there was a ghost -- this is a commodity sample that targeted user's documents. There was a really useful WMI class for file based operations. SIM under score data file. When ever there was new or modified files within the recent folder, it would up load all of those. The payload that it used was event consumer that just used the internet explorer comma object to up load the new documents that it discovered. And then moving forward in 2014, there's a Romanian researcher who developed WMI shell. This was the first time that I had ever seen WMI used as a pure C2 channel. So what he did was he created a modified name space and just stuffed his payload in there. So say you created some name space and placed in it an encoded PowerShell command. And then used the win 32 process create method to take that name space on the victim's system, base 64 code it and execute it. And then you can also take the output of the PowerShell command and save it to another WMI name space and read that remotely. That is effectively what this tool did. And then this year we revealed ATP29. It was like a week or two ago, released a report on the hammer toss malware. This is python and -- what that paper didn't describe were the WMITTPs that this group was using. They were creating and modifying WMI classes and class properties, stuffing their payload in there, basically doing the same as WMI shell using custom WMI classes instead of name spaces. There's a lot of things that as an attacker you can do with WMI. From a post exploitation perspective, really you can cover pretty much the entire attack life cycle here whether it's reconnaissance, I mentioned malware does VM and sandbox detection. Code execution and lateral movement. Persistence as we know. Data storage. Using the name spaces and custom classes to stuff the payloads or the result of payloads in there. And C2 communication. Basically tieing together the data storage with code execution and getting a pure C2 channel out of WMI. Now, if you were to go about doing reconnaissance with WMI, these are just some of the classes that you might be interested in. This is typical of a lot of malware. The first thing is collect host information, up load to a server, you have convenient objects there. If you want to perform file or directly listings, delete files, move files, you have SIM underscore data file. The volume operations, registry operations. You can list processes, stop processes, start processes, create services all remotely using WMI. Now, we can also get code -- lateral movement. I described the static create method. Here is an example of me using PowerShell to evoke that method and -- well in this case call it [indiscernible] from an attack perspective replacing no paddocks EXE and you have one liner commands that goes out to the internet and downloads the PowerShell and executes that. This is simple to do. A reminder for WMI persistence. We have the filter that take it is form of a WQL event query. The consumer, the thing you want to execute and the five standard event consumers and a binding. What's up? Hey. >> So we have a little tradition here at DEFCON. What it is? Shot the newb. Welcome to DEFCON. Cheers. >> That's good. All right. So we have our three requirements. So let's get going with persistence. I feel so much better now. Here is an example of what C daddy was doing. C daddy was the internal name that we were using for the public family name for this was CDUKE. This was a python back door that used PowerShell as an WMI persistence mechanism. I pulled that out of the python back door and changed it a bit. So you take the event filter which is this long query here in the query variable, effectively all it's doing is going to trigger some event shortly after system start up. Specifically anywhere within 232 seconds after system start up. In fact, this attacker just ripped this query right out of [indiscernible] kind of lame. And then we have what we want to trigger off of and what are we going to do upon triggering that? All we do here is there is a command line event consumer. After system start up we execute thing in the command line. The attacker had previously dropped their python executable and shortly after system start up it would be executed again. Nothing too complex here. So WMI can be used as a storage mechanism. This is a short little snippet of what ATP29 was doing. They were doing it remotely not locally. This is local, here I create a custom win 32 underscore evil class within the root space and attach evil property to it and the payload is the string. The put method installs it permanently into the SIM repository. Just imagine this being like some base 64 encoded PowerShell command that gets executed later on. Providers. Take it away? >> One of the things that kind of impressed me when I started looking at WMI is that it's not this one huge monolithic service that I expected coming from Microsoft and existed for 20 years. I expected this complicated beast. And that's not what it is. Instead you should be thinking of WMI as a framework for querying and configuring a system. The core part of WMI is very small. What gives WMI the power is those providers. And a provider is a [indiscernible] that declares that it knows some type of data. This is the data that I know how to process and give to people. For instance when you use WMI to go query the list of processes on an operating system or on a host, there is a provider on the backend that is able to perform the operating system queries that the system calls to get those processes and format them in a way that the querier is able to process. It's a really neat system. There are of course ways that as a defender you can enumerate those things. With your attacker hat on you should be thinking, wait a minute, this is a plug in based system that provides ark tear data to a framework. Can we use that maliciously? Yes. We can think easily of how to create a malicious WMI provider that can do customized activity on the remote systems. Matt was able to come up with some examples of this and it's really state of the art? >> Didn't come up with examples here, I had the requirements which I provided out to the twit toe sphere and what resulted in that is my good friends Casey and Jared, that very night went and implemented their own custom or proof of concept malicious WMI provider which is awesome. When Willi and Claudiu mentioned this, this was just theoretical. We thought it was cool and these guys banged it out quickly. What Casey did is created a malicious WMI provider in the form of a shell code runner. You take his dot net DLL and install with install U till dot EXE and do the COM registration and locally or remotely you can execute a shell load payload in the system context. Pretty cool. And then Jared what he wanted to do was create a WMI provider that would list out active network connections. Prior to Windows 8 there -- 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 trigger off of if you saw a connection going out to a known blacklisted C2 address. Another thing he slipped in there was a PowerShell runner. So once you got this installed, then you just provide an arbitrary PowerShell command via this argument list argument and it executes the PowerShell payload local or remotely in the system context. That concludes the introduction to WMI. If you weren't familiar with WM, you now have a good basis for understanding what you can do with it and so forth. Matt gave a great introduction. I would like to spend a few minutes talking about our motivation. Why we started this in the first place. This started within our company about 6 months ago or so. Working on large investigation. Companies with 10,000, 100,000 host ons the network. We saw a threat group and use WMI to attack. We called this APT29. They used neat techniques. And one of the most interesting to me as a defender is they were particularly aware of how a forensic investigator goes about their investigation and made it really difficult for us. They did what we always talk about like using passwords., clearing event logs. When we did the investigation, we aren't trying to remediate they knew we were doing an investigation. They knew it and started upping their game and we knew they were upping their game so we upped our game. And we got into this little, I don't know like a war there kind of trying to do better and better things and it was interesting. We were very lucky because we had great network coverage and host base coverage. We were successful in the remediation and exhausted the attackers new technique. Along the way what we saw is deployment of the WMI techniques. Some of the things they did right away was this consumer to binding persistence technique at the backdoors. As we started pushing them along, they deployed C daddy and I started pushing all of their payloads into the SIM repository. And why did they want to do that? Because as investigators when we look at a system, hopefully it's online when we get to it and maybe we can do inspection. When we get a forensic image, there are no dropped files on disk. Very little to look at. There is one binary blob that sits there and houses data. At that point we had no way to parse it. We were out of luck. Some things that we could have done and tried is we could have used up WMI to inspect the WMI system itself to find out what was there. We can use those meta queries to fetch that data. That's a fair technique and a powerful technique because WMI is networks. We can do it remotely and say what WMI classes do you have installed. But being familiar with 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 that might shim into the WMI service and decides not to return the most interesting results. That doesn't make me feel good. Another reason this didn't work well is occasionally, maybe the system that had the most interesting data on it was compromised and we had to pull the system offline as soon as possible or 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 box. So we were left inspecting the file system and registry. We found some interesting string hits and object hits data. Have you seen that before, malware showing (audio blipped) strings. This was a huge file. 100-megabytes and we had no way to inspect it further. Strings on a binary file and calling that forensics doesn't make me feel good. That is not forensics. The final technique that we explored with limited success was to build a Frankenstein and that's where we have a live running system that is clean and copy out the SIM database from a compromised system onto a live system and hope everything works and sometimes it does. Coming from a forensic perspective I don't know why the system works that way. I'm wondering -- check some and cleaning up unusual data that shouldn't be there. Is there other (audio blipped) along the way when that live system imports the data? I don't know that. I'm wondering if I'm losing data, stomping on time stamps, I don't know. That makes me uncomfortable. So we got together and spent time investigating what these files were and if they allowed us to reconstruct the WMI data. I can report to you with confidence that sure enough there is a lot of really interesting stuff in there. So we're going to dig into that. Taking a look on disk, what makes up my service and the data that backs it. Here are some of the major files. Objects of data is the most obvious. This is a file that we had been inspecting for years looking for interesting entries in there. All we were able to do is run strings and interpret the output. That is not forensics. This index dot BTR file. This allows us to seek the data within the object files. These bottom files, mapping one, two, three, allows us to reconstruct the data in a logical address space. Unfortunately one of the findings that we identified along the way is simply grabbing objects for data is not sufficient forensic analysis. Over time we had basically acquired a huge -- of the data files and we were excited to parse through them and find the malware. That file itself is not sufficient. When you go out and do forensics, grab the whole directory. So we dug into these files, maybe from a single system we were looking at 50, 100-megabytes of data. Mostly within that data file that we can use -- supporting the B tree index on the side. We're not going to dig into this a lot. How do we go about this (audio blipped) we didn't debug the system. Generates head stumps and meant weeks staring at the stumps. It ends up not being as difficult as it sounds. There is a lot of human readable strings and it's a great place to start when reversing a file format. Identifying known data. Those strings stand out obviously. The long side strings, the size of the string. You identify those. And sets within sized buffers that become obvious. A known piece of data that is interesting, a string. And now offsets to the string that show how the data is organized internally. (audio blipped) reverse engineer, bit flags along the way. The read write able flag. A bit flag. Does this thing have a default value, a single thing flipped in each record. Glancing at the file is difficult. Differential analysis. One good known SIM repository and one changed one and see what the dins was on disk. Ultimately it was tedious 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 it means. Everything else we know what it means and how to parse it. What that allows us to do is reimplement WQL or any of the other query languages on a dead box system. What is there. What did the attacker store there and what other artifacts that aren't exposed to WMI. There are additional artifacts. Brand new sets of time stamps that we can pull out and figure out when this database was modified last, when enters were inserted and things like that. Anyone familiar with digital forensics (audio blipped) we can build up a time line of attacker activity and identify new period of compromise. This is really neat stuff. Claudiu now is going to dig into the nitty-gritty detail? >> The next diagram shows the files that the SIM repository consist of and their relationship. The index -- a beat file, the page size is 8,192. It's a B tree on disk index. Pointers to the next pages are represented as logical page numbers. And to get the physical page number of a certain artifact you have to use the currently active mapping file and find the logic to physical page number mapping for the index [indiscernible] and the logical number page number is used as an index in the mapping. What the value of that index represents, the physical page number. In this example, in the physical page ten, we have the internal representation of evil consumer. As you can see the first identifier prefixed by MS under score represents the name space where the instance lives in. The second identifier is prefixed by CI under score is the class name of the instance. And the last one is prefixed by the [indiscernible] the instance name. At the end of the representation there are three integers. The first integer is of 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 paged file. This is the same page size as the index -- 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're getting the physical offset in the object set data. The actual physical -- the physical page numbers, sorry. 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 offsetting page of the record and its size and then the physical offset of the record data by doing the following computation. Physical page number multiplied by the page size plus the end page offset. The size is also present in the header. Also CRC32 checks them, is present there, too. We can do a data integrity check on the record data to validate that nothing weird happened. To do an artifact recovery methodology, first we have to construct the search thing, taking into consideration the artifact name space plus a name. Stay tuned for the white paper that will describe this in detail. And then perform a search into the index -- 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 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 of the record header matches the size in the index -- search and record offsetting the header offsetting the current page of the artifacts. And the integrity check is performed. This is a page structure of page and object data. It starts with a list of record headers. Each record header consists of a record identifier. A record offset and size and CR32. The CRC32 is only present under Windows XP since the integrity check is done on the record level for optimization purposes in Windows vista and up, the CRC was moved into mapping. So the integrity check will be done at the page level this time. Next this is the keys in route page in the index dot ETR (ph.). They respect class definitions instance, decorations, hierarchy representations and also references and next it's a pretty picture. When I talk about pretty, I'm saying pretty complicated. I won't spend any time on this. All the details and examples are in the white paper and they're very self-explanatory and whoever wants to follow and read the white paper, I'm pretty sure they'll understand? >> So we've demonstrated I hope that maybe you don't quite fully understand the file format, we demonstrated that we do understand it. The natural thing for us to do is build tools that make it easy for you all to take advantage of this knowledge. Precisely what we did. I wrote a tool developed in python which is a nice object oriented library and it's easy to interact with a forensic image with a SIM repository. We're going to spend a few minutes walking through the tools so you understand what you have at your disposal. So python SIM is what I call it. Pure python parser for the SIM repository. The SIM repository are files that have been persisted to disk. Many of the instance of classes that attackers have created as well as all the data supported by the system that you can query and configure. It's an 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 except for the last four bytes and access to say time stamps, time lining. It's easy to use. I did develop a GUI to demonstrate the functionality. That's what I'll show you. I will describe that anything you see in the GUI here is easy to use programmatically. Build investigative scripts to triage data. This is good for data exploration. Let me see if I can figure out this. Written IQT works on Windows and Linux systems. You can go in and explore the pieces of data, the forensic artifacts that we can parse out. If you don't understand the physical representation, you can explore the logical representation of the repository. SIM V2 is the default space. And root subscription is the consumer bindings that maintain persistence. As we explore that name space we see all the classes that are resident. These are the types of data you can query for and an attacker may have modified. Consumer binding. I'm sorry, everyone. It's amazing you can have a demo fail when you're not even doing it live. So we can explore these classes here. And this filter to consumer binding is ... Now it looks like we're good. We're going to hit start and go for it. Filter to consumer binding. That is for persistence using WMI. What this report shows is all those nitty-gritty details that we're able to parse out. The most interesting one is the layout section here. In detail each of the properties exposed by this particular class. A filter and consumer. Those are the two parts of the persistence there. Additionally the default values or other things we're able to parse out of the artifact. One of the neat things about this tool is in addition to parsing data for you, it gives you a way to validate the parsing. What we see here is a standard hex editor view where you can look at the various fields. It's more than that. In addition to parsing out, it shows you how each individual field is parsed out. If you're not quite sure why was that time stamp parsed as 2009 in July? We can see where that data is and confirm that (audio blipped) correctly. Anything that we're able to parse out is visible here in this hex stump. That is really neat. We parsed through the class definition that describes what data is available. Now let's look at the instances, the specific concrete data that is stored using the schema. That's also displayed under this -- sub branch. We have three instances. We can take this first one and explore the concrete data installed on the system. There are two time stamps there within each instance, it's probably the creation and modification date for those instances. We're looking at the special values, the concrete values and these give us the names of the WMI classes that define the filter which is a thing that will be triggering and the consumer, the thing that will be run. We can fetch that data as well and see who those two payloads will be. And sure enough we can go in and validate manually what is this data. From my perspective I think it's an interesting tool. It's intuitive from my perspective. You can click around and explore the data. I don't necessarily expect you to know where you want to look. This is a great tool for getting familiar with WMI especially from a forensic perspective. We'll leave it to Claudiu who is able to take the knowledge that we gained along the way and codified it into almost like a wizard to find evil. Both of these things you'll have at your disposal for finding bad guys in your environment. We'll give Claudiu a chance here. >> The daemon parser, a C++ parser and works only in Windows. It's using commands, dash, dash, name space 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 triggers and it was built following the IRR (ph.) workload. The source code is available at the following [indiscernible]. And let's go into the demo. Is it working now? We start the parser and we saw that the persistence in WMI is using consumers. What we're doing here is parsing all the consumers in the root subscription event space and found a [indiscernible] called -- consumer and execute the PowerShell using IEX. And it's taking form the Window 32 payload the class, the payload value, the payload property value. The next one is an -- log. [indiscernible]. And another command line event consumer called BVD consumer and executing a script which is located in [indiscernible] The first one looks suspicious, the second tool, 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. We see what it's doing is executing a payload toting a custom class. And also finding the binding that binds the triggering event to the consumer. The triggering event in this case is the payment card processor. And let's look at the query to find what the triggering event looks like. We get a filter instance and select star from win 32, where process name is [indiscernible]. Whenever a process is started, it triggers automatically. Since we know that the payload is located in the win 32 payload class and payload property, then we can do the class definition parsing of the win 32 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 -- encoded payload. Which is actually after decoding and done analyzing the memory [indiscernible] for credit card information data. We decode it and look at it and the most important thing is what are you hiding the data that you're scraping. A class -- route event space under track data it's a good indication. Let's go back to the WMI parser and do a parsing on the win 32X field and what we have here under the track data property, there is another base 64 encoded value which after decoding it ... (audio blipped) which contains the formation that was created. Track type, the CDV, the name, Fred Smith. And the credit card number. I don't know Fred Smith, but I have his credit card and we're in Vegas, so join me? >> At this point we're in a lot better shape now. We can go out and investigate these types of attacks now. We don't have to hope that we have good network coverage and host space coverage. We can do it offline and be sure of the results. We have tools that do that now. That python tool is really good. And Claudiu's tool we're going to continue to update with all of the methodologies along the way to identify WMI attacks. What are the other ways that we can go about finding these WMI attacks. Matt said there might be something like 7, 8,000 of these on a single host. How do you dig through the weeds to find the bad stuff. We're working on that. I want to jump into a few things but I want to maybe do some kind of call for action. Essentially what we're presenting is like a file system parser, an NTFS parser that gives you a new file system. We're not sure of the new pieces of data stored there. Let me talk about the things that we do know about and encourage you to dig around in those files to find new information. The obvious one that we covered a new times ago is [indiscernible]. This is the most obvious and well known commonly used way to maintain persistence in WMI. It's a way to encode and store the payloads within SIM repository. AV may not find those on the list but it's in the repository. We have seen attackers that go in and install their own custom class definitions and use them remotely to store payloads or pull data out. We're proposing to do a complete enumerate of client environments and it's no longer something that we can't do (audio blipped) and look for things that shouldn't be there. In my experience seeing attackers use the most advanced techniques, the new classes they create do not look like legitimate classes. It's something like recon or back door or I think there was one that was bad or something like that. If you're scanning this thing, it's like that is so obvious. At least for the next two days we can say, easy to find, we need to think about in the future, how to identify things that shouldn't be there. Moving beyond what has been installed persistently, another piece of interesting forensic artifact that shows up in these object up data files is under Microsoft metering, the processes that are executed and when last executed and how often their used is stored for some reason via WMI. When it persists, that data, which operating system is executing it, it stores it in the SIM repository. We have an easy to use parser that can extract the recently used executable and who was running it and how many times and when was the last time. This is juicy and interesting stuff. One of the classes that I recommend you looking at is CCM recently used apps. Some of the other software metering artifacts is interesting and we can talk about that offline. I have you successfully time lining everything that is happening in the SIM repository to find attacker inventory. And that is interesting. I was able to use the time lining of -- the background I guess is I saw an attacker install the [indiscernible]. I looked at the other events that were happening about that same time and saw artifacts that lead to the user account ha the attacker compromised to compromise the system and get that persistence there. That is something we didn't know at the point and was able to add to the report. And finally decode this stuff with full confidence. Say two or three months ago when we were trying to do this the first time, we would run strings on the SIM repository and get things that looked like base 64 commands in there and think we got everything and then we threw it into the decoder and it was truncated and didn't work. It's due to the way the file is paged. Because we didn't know the mapping of all those, we couldn't reconstruct. Now we can with full confidence. I think we're in a good situation now in regards to investigating these attacks. Anything more we can do to prevent these attacks in the future? Something that is effecting our client's organization. That is what Matt is going to talk about next. >> So I want you to consider the following. An attacker can do a lot of things. I'm going to give a few examples of attacks and the effects that they'll have in WMI that you might be able to form a creative WQL query off of to potentially detect these sort of things as they're happening in realtime. An attacker persists an -- subscription. What ends up happening from a WMI perspective is instance of event filters, event consumers and filter to consumer bindings are created and a respective event that is triggered upon creation of the class instances is an instance creation event. An attacker uses WMI as a C2 channel. Let's take that WMI shell tool that creates and modifies WMI name spaces and uses it to stuff payloads and store the results of executed payloads. The name space creation event will trigger in this case. An attacker uses WMI as a payload storage mechanism. Similar to WMI shell but say we're talking about APT29 -- create WMI classes and properties dynamically and stuff the payload in there as well as execute a payload, take the result of that payload and store it into another class property. In this case for the TTPs by 29, you see the class creation event be fired. Going further, an attacker persists via the start menu or the registry. There is a valuable WMI class called win 32 start up command that captures that very action. Whether it's the all user start up, user start up directly, HKLM or one of the KCU 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 win 32 start up command. An attacker modifies any additional known persistence locations. One that comes to the top of my mind is say you have a malicious LSA plug in installed. The registry key used where those are installed to. Well, in a more generic sense you can use the registry key change event (audio blipped) to trigger -- modification of any key or value that you're specifically targeting. Service creation. This is easy. Instance creation. Is going to fire of win 32 type service. Are you seeing a pattern here? All of these attack effects can effectively be described in the form of a WQL query. What's the WQL query? That event filter. Requirement No. 1 for an instance of permanent WMI event subscriptions. You want to do something upon triggering this event. You have a standard event consumer and bind those together using a filter to consumer binding. I thought this really kind of begged for this exhibit mean here. (audio blipped) using WMI as a persistence technique. What if we had a permanent WMI event subscription that detected the [indiscernible] it's do able. All right. So we could potentially detect persistence, any WMI persistence, registry per SYS sans using the registry key change event. Service creation. Easy. Schedule job and task creation. You can get creative. Think of any attacker action and the respective artifacts that it might leave behind and there is going to be almost guaranteed there is going to be a WQL query that can respect that attacker effect. The only exception to that as I mentioned before, below Windows 8 you don't have WMI classes that represent network actions. There is a known gap there. All right. So perhaps we can use WMI as say an agent list host IBS. We register or own permanent WMI event subscriptions that detect all kinds of attacker activity and the benefit is it's persistent, the service is running and there is no agent. We don't have to push our own executable package onto a system. Microsoft gives us this mechanism without dropping a single file. And we can install it remotely. I wrote a proof of concept tool called WMI post IDS. It's effectively an agent list host-based IDS. A single PowerShell module file. All you do is 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. What you're doing on the backend is just creating locally or remotely those event subscriptions on the machine that you want to register these alerts on. Let's see this in action. The attacker machine. Then you import. List the module and currently there are four functions. Trigger, register alert with the requirements for permanent (audio blipped) WMI persistence. Let's look at the help. What does new alert trigger do? This is what you want to trigger off of. We can trigger off event consumer, creation, modification or deletion. We can trigger off the start up command object or the - a change to a registry key. There is much to be expanded in this but right now this is just a proof of concept to show it's possible. New alert action. This is the payload that we want to execute as a defender. We can either send that event information to a URI or we can create an event log entry. 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 realtime 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. 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. Optimally you can provide a name of this trigger when it's registered persistently in the SIM repo. And then you just take that, type 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. Hopefully as a defender you would be forwarding your event logs to some centralized logging server. And 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. I said this was the attacker machine as well. We're going to execute the track data scraper again. 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 eventer consumer being created. Just to show the payload hasn't been executed. There is no event log at this point. Installed remotely and persistently, the - data scraper is going to do its thing. This is the same exact payload that you saw installed previously. Now, I'm going to look at the event log to see if that event was created. Which indeed it was created. So this was realtime detection of this in action. And so like what Claudiu did earlier, I can parse out this payload and see that what it's doing is it's stumped the payload in the win 32 process class I believe and then -- or in the payload property. And I can even pull that back remotely using the SIM command. I say get SIM class on win 32 payload which we see here. I'm pulling this remotely and I'm interested in dumping out the data in the payload property. And I get the base 64 included payload. So we have two options. We have now the capability to perform dead box forensics and the ability to perform detection in realtime using WMI. So as a defender, I just showed you a few instances of how you can use this to detect activity in realtime. There are a bunch of other things you can 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, check out the MSFT net classes. These you can query and trigger off the creation and removal of new network connections. Okay. We can use PowerShell to detect WMI persistence after the fact. I showed you how to do it in realtime. Say you want the sweep the whole enterprise, there are a few lines that can accomplish that. Existing utilities out there that can help detect WMI persistence after the fact. The latest autorun has a WMI tab that will present out the event filters and consumers and you can right click and delete them. [indiscernible] pure incident response framework for PowerShell has WMI detection. Lastly one other thing I would like to mention is you can actually set the name space, for each respective name space. Say you wanted to remove the ability to execute the win 32 process create method. You can go into the root SIM 2 name space where the process is and remove the ability of anyone to execute those methods remotely. Shawn Metcalf, mentioned to me, this was a great idea from an attacker's perspective. What I'm saying here as a defender you can set Ackles (ph). Imagine compromising a DC and downgrading the Ackles (ph) so any authenticated user without any privilege on the domain can go back and recompromise the domain controller. All right. So that's it. Just want to give a shout out to Will Schroder and Justin Warner for giving me great ideas on the event filters that you can come up as a defender and attacker. And Willi take it away? >> I hope through this presentation we brought you through an emotional roller coaster. We started about talk about how awesome WMI was and I think it's neat how after the fact we can come in and say here are the things you can do to defend from that using the same techniques and forensic techniques. I think it's fair that we acknowledge our employer for this. And share it with you. All this code is on GitHub at this point. Just before this talk we finalized and asked to be published a white paper that goes into great detail. It's about 100 pages long and talks in depth about everything here. This is information that I hope you can take away from the talk and implement in your environment or use on another person's environment. Couple references here. We'll share that white paper. The flare challenge. Great way to practice reverse engineering. Starts off easy and gets pretty complex and we'd love to chat after this talk. We have almost a half hour for questions or a half hour to get over to the parse talk. The microphone is coming around. >> As far as the trying to downgrade how many classes there are to go through is there master hash libraries, does that mess everything up or can you exclude those and do the rest of the values. >> Totally feasible and not difficult to do, a hash list of the known classes and the properties you expect to find there across an environment and go from the gold image to anything installed on a workstation. That would limit it to 5, 10 classes. >> Would that be primarily location specific or is it possible to develop one for multiple systems just contribution based. >> I think we have a lot of flexibility there in the way we attack it. We'll try it after. >> As a follow up, any techniques you can share for doing this at scale for identifying providers across an entire environment? >> I think the most obvious one is this persistence mechanism that we talked about to consumer bindings. This is the only one we've seen so far. And on top of that on a default Windows insulation, there is one or two persistent WMI consumers used by the operating system to do its own thing. You only expect to find one or two per system. It's easy to look at scale how many do I have. Five, ten? That is something to look at and say that's weird. That's a good place to start. >> Were you also asking specifically about WMI providers? >> Not specifically. More as the - in methodology to detect across an environment. >> It might be worth noting when a new WMI provider is created you can say trigger off instance creation event of type under score under score win 32 provider. You can take the definition of that - there is a GUI that you can look up in the registry and that shows the DLL that is for that provider. >> Are there any situations where you might put an Acklet (ph) on and cause something else not to work properly. >> If you're doing things with WMI remotely you want to be mindful of that. Say you can create like a remote WMI administrators group and limit the Ackles (ph) to that group and block everything else for every other group. >> Anything specific within Windows for using that or just if you're using remote WMI for yourself? It's like any standard Windows services that would need that in order to function properly. >> That is a good question. I never looked into what some of the unintended side effects would be of just disabling that service. Windows is increasingly relying on this service -- like desired state configuration that relies heavily on WMI under the hood. I would be wary of that. >> 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 that we have. Thank you for that. I have a few questions. First is I write my own custom files to do different stuff. Most of your defense analysis is coming with a clean machine [indiscernible] you're going to trip my more file for sure? >> So backing up. We didn't really cover moth very much. Only because from an attackers perspective and investigator's perspective, what we see more and more is attackers doing everything dynamically without a moth file. You can use a moth file to carry out the same exact attacks that the attackers are doing. Only a moth introduces another forensic artifact that has a defender you would be able to detect pretty easily. From an attacker's perspective, in my view the only thing that a moth file gets you is persistence beyond WM, repository corruption. Not sure if you want to ask your question again. Say how moth might play into all this? >> The second question is for Willie with that tool. How do you handle WMI recompile in a Citrix environment [indiscernible]. Compilation and back up and restore the repositories. What happens to you daytime signatures that you're relying on and say if I drop a payload, and immediately after that I can take the whole moth and recompile the repository, and I mean on my time line there should be a line. >> Sure. We're explaining how the time lines are effected now by inserting new data into the repository and taking it out. As you insert dynamically new classes not all the -- change. Typically they're restricted to the new objected created or modified. I suspect they stand out like a sore thumb when doing the time line analysis. Does that answer the question? >> It's a good start. Another thing is [indiscernible] how do you track that in environments which doesn't use ACCM. >> I pointed to that forensic artifact as something useful. In 50 percent of the environments that we investigate they're using MS8067 SCM. This is a huge -- to look for as a consulting company. But if you're not using that in your organization, you may not find it useful. >> Did you try taking objects dot update data and dumping into it a -- which can nest it [indiscernible] >> No. >> You did a static analysis of the whole thing which is forensically. >> Usually you don't take only the objects -- (audio blipped) you have to have all the files. In order to get all the data and how the data is constructed, you need the mapping file. If you have a record that is bigger than the page size, there will be different chance of different offset. It's not sequential. That is one of the things. But no, we didn't go and [indiscernible] that's correct. You can go -- the next big thing we want to invest some time in is recovering deleted artifacts. Because the mapping that -- the active mapping file has a list of three pages which whenever you insert something new in the data base, [indiscernible] they will be used. Whenever something goes outs of the scope, the data still resides in the object set data. You can go and parse every file in the -- every page that is in the three page array and look for artifacts there. You can do [indiscernible] both for BPR and object set data? >> Imagine the attacker is trying to be stealthy. After they install, they only want to execute the payload once. They do what they do and as a clean up remove the event filter and consumer and filter to consumer binding. Those artifacts are going to persist in these three pages which we don't have the ability to parse at the moment. But they're the tools like once the research is done, extended to pull those artifacts out. >> The next question, we start charging. >> Depends how much you charge. So a lot of the forensic analysis is focused on finding out what exactly -- consumer binding. But you do not have any trace of what events did fire. >> Wouldn't you through -- from the filter to consumer binding you would have the event filter property and when you look at that instance you would see the event of interest. >> The question is you're coming into exploited system after point X after something has happened. Or unless you're looking at it with your WMI and you have the moth files pre-installed, if you don't have that there is no way to keep track of what already fired in the system. Unless you have a consumer there is no persistence, right. You know what I'm saying. >> I think you're right. You're saying we see the persistence mechanism installs but we don't know if it fired and the payload. That is equivalent to finding a run key in the registry, you don't know if the system rebooted and the run key executed but it's enough to kick off the investigation and say there is malware here. It's been installed. Typically I say this box is compromised and assume the malware has run even though we didn't see the specific trigger that caused the consumer to execute. >> I understand what you're saying. We're in agreement. >> Cool. >> More questions. >> Sure. >> The B tree file which you're 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 if you're hiding, I'm trying to say how can you get beyond detecting things based just on name or base 64 dump or something which is stealthy? >> [indiscernible] >> My point is B tree is where the deposit is stored is there a differential am SYS. >> No the B tree stores different representation of different artifacts. The keys in the B tree is concatenation of -- 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. And this is how you are able to query the objects, by finding the location information of the data and objects. That's the purpose of the index BTR. There is no other information. It's just for searching quick and finding where the data resides. >> Question for Matt. Development class without autorecover. [indiscernible] meaning I drop it, it fires off once. And goes away. >> Well, like if you had a moth file that still did (audio blipped) even without autorecover. Just autorecover will recover everything and recompile the moth after the rebuilding of the database. We'll take any further questions offline and we can talk about this for hours. We'll just be right outside. Thanks again for staying so long and missing out on the car hacking talk. We really appreciate it.