Abusing WMI Providers For Persistence - Philip Tsukerman

hi I'm Philip I do research at cyber reason and this is abusing WMI providers for persistence now what every attacker wants after doing all the cool stuff like code execution and privilege escalation is persistence or to be able to run to run your calculators after the machine which starts of course you can stop set your calculator with stuff with some useful payload but still you want to run after the machine restored one such common technique at least nowadays for persistent is comm hijacking now--come or the component object model is just another way to interact with external code you basically say I want to interact use this external piece of code identifiable by a class ID which is just

a good like identifier and you say and you tell the OS oh I want that object and the OS knows how to retrieve it load it and then you can interact with this outside code now behind the scenes this is implemented by the registry each such class ID has its own separate registry key which contains a couple of sub keys that have the implementation of that com object so if it's a DLL it just gets loaded into your process if it's an executable it gets loaded as a separate process and then you can communicate with it but all in all you just ask the us course for a specific class ID it close it and you can interact with it

now abusing this is pretty straightforward like pretty much every kind of persistence it's a combination of registration and demand if you try to find which comm objects are requested at boot by Windows and you just become that object you can simply modify the registry the class ID entry whatever object you want to hijack instead of original object itself original implementation executable you just write whatever you want basically whether it's your dll or it or it's some kind of command etc now this is pretty popular in recent times but there are a couple of problems with this technique first of all not every comma object is requested at boot so we have a limited number of objects you can hijack and

also to do this you need to modify existing comm objects' which is a thing that doesn't really happen legitimately so it's a pretty rare occasion and registry could be monitored pretty easily now you could of course create a newcomer object but there's nothing to demand it so you just basically have a registry entry that does nothing unless you write some other piece of code that demanded at booth but then this kind of this kind of defeats the purpose because now you have to persist this new piece of code so the question I asked myself which was also the basis of this research is is there any feature of Windows I could just coerced into loading any arbitrary calm object and it

turns out such a feature is WMI now WMI is the feature of Windows that provides an object-oriented representation of lots of unrelated elements on a machine this means there W my class representations of processes services but also hardware components such as monitors and network adapters and I can just ask Windows to enumerate some W my class such as win32 process which represents the process that we might enumerate whatever this object represents and gives me that all of the instances of this class here we can see it just gives you something pretty similar to a task list now behind-the-scenes WMI providers are what are pieces of code that provide this kind of magic there are a couple of

common objects exist and dll's which implement the actual enumeration methods into instances and classes that comprise WMI now these WMI providers are only loaded when something requests are relevant w my class so if I have a provider that implements win32 process it isn't loaded until I ask for every due process now all of these providers and the classes themselves are are defined in what's called the WMI repository which is just a couple of files on disk the providers themselves are also defined as W my classes specifically as the double underscore went really do provider now this is a pretty big object but we actually have only two interesting fields for for our purposes first there's a name because we

need to refer to it somehow and second as a class ID now the class ID is exactly the same class ID as an comb each WMI provider could be implemented as a comm object and we could just if we were an admin and I'm assuming I'm an admin because I play in easy mode I can just create my own W my provider and provide it with an arbitrary class ID now this means each time the provider loads my comm object loads but again nothing demands this W my provider nothing there are no classes that are requested at boot so let's look at what W my providers actually exist when the machine boots so actually there's quite

a few such providers one of which is double my proof inst the other the others sometimes change between machines between laptops and desktops cetera but double my proof inst is one such provider now when something demands a W my provider it actually demands a W my class and it in turn demands the comm object this means we have two new levels of indirection with which we could play until we somehow achieve execution boot now let's look at how the association between W my class and a WMI provider works it turns out that if we look class that's implemented by this when per year by this double my birth into provider we can see that the provider is denoted as

part of the class itself and it's identified by name only this means it's just a string so the way we could have used this is pretty simple we find an instance provider that's loaded at boot here it's WI perf inst we just delete it and we can register our own W my provider with an arbitrary comma object as an implementation and give it the same name so if a class is requested at boot W might looks for the provider with the name which corresponds to the implementation and loads that so this means we've achieved something that looks like comm hijacking but we didn't really hijack any comma X and if you're not looking at W mi at specific W my

event you're gonna miss what's happening now it's pretty easy to implement and if you have a contact ready it's about six lines of PowerShell you simply delete an existing WMI provider create your own and that's it but still hijacking is invasive and when you hijack some kind of object that is used by the operating system you need to somehow proxy to the original object or we implement some of its functionality or just hope really hard that nobody notices that something's not working well in fact comm hijacking really sometimes depends on people not noticing stuff isn't working because there's oh there's a lot of common objects loaded boot which do pretty much nothing important but still

can we avoid hijacking because that would be much much easier and it turns out that we might still have the answer and it's in W my event providers now WMI provides an invasion eventing functionality this means there are special W my classes which act as events you can subscribe to a type of event and each time this event happens you could have some kind of callback consume this event and run your own code now there is an infamous persistent technique which use which uses the consumption of WMA events this is something a bit different and we're gonna use the event providers themselves now it turns out the association between event classes and event providers is done a tiny bit

differently which works in our favor instead of having a specific W my class that that tells you here's my implementation of the provider there's a separate class called double underscore event provider registration the way it looks is it creates an association between a WMI provider and some kind of W my query which describes the scope of events this provider could provide so let's say I wanna get all MSFT SDM event event I could this means the SDM event provider is gonna be low now the nice thing about that is W my event providers also allow for redundancy so multiple providers could allow you could provide the same events this means I can register an additional

provider to provide an event that's already provided to W my now of course we need to check is there any demand for any W my events at boot because again no demand no execution and it turns out that on every machine I've checked at least one of the events demanded is the MSF tsdm event or SDM event log event which is provided by the SDM event provider so now we have a pretty simple way to piggyback on that same demand what we need to do is create again our own WMI provider provided with our own comm object again unrelated to any other common objects on the machine this means it will probably be overlooked because

cob jects are created pretty much constantly because lots of installers and stuff like that create their own comm object-- so this really isn't uncommon and we could register it to provide MSFT SDM event and what happens next is at boot the Machine tries to consume SCM event it close the original provider it looks is there any provider that provides these is there any additional providers to provide this event the answer is yes our malicious provider and that's how we persist it and this is also really easy the only thing we need to do is create a new provider create this event revise registration we'd not delete anything we'd not override anything and we achieve persist persistence with an

arbitrary comma object and if you're not looking at W my event and WI providers in there there's pretty much nothing you can do to detect unless you detect the payload itself and that's about it

so one minute is enough for questions but you could ask me outside or something thank you