WMI Persistence

By Anders Kursar –

Within windows there are three main ways to persist payloads, two being easy and considered “go to” and the last one being more advanced and not nearly as common. The First two are creating scheduled tasks and persisting to the registry.

Having a payload persist from registry is as easy as setting a registry key in HKCU:SOFTWARE\Microsoft\Windows\CurrentVersion\Run or HKLM:SOFTWARE\Microsoft\Windows\CurrentVersion\Run[a] to trigger your payload whenever the user logs back into the system. The problem with this is that it is very easy to detect and very easy to remove and can pop open windows which isn’t very stealthy.


Here I have created a registry key to run a malicious piece of code at the start up of the system, this can also easily be done with one line in powershell for example


This is easy to run but also very easy to find one on of the first places an Administrator would go to look for a persistent program.

Having a payload persist from a scheduled task is also easy to implement as well as does not trigger any windows to pop open. A payload could be set to execute as specific amount of time after a user has been idle or at a specific date and time but this method easy to detect and to remove.


Here I have created a task clearly called evil that will launch a program at system startup. This can be done using as simple a powershell script below to create a scheduled task and run it at a specific time.


The last method of persistence is using WMI to persist on a system. Using WMI to persist is very beneficial due to being difficult to detect as well as difficult to remove, due to the knowledge needed to know how to fully remove payloads.[b]

WMI stands for Windows Management Instrumentation, and was introduced in Windows 95 and is currently present on all windows systems and can be used both locally and remotely.  WMI has recently gained popularity due to its wide variety of use including code persistence, system reconnaissance, anti-virus and virtual machine detection, code execution, lateral movement and data theft.

WMI Objects are broken down into classes and those classes can easily queried using the WMI query language, WQL for short. WQL can be used to search for specific instances of WMI Objects, look for alerts on events of specific WMI object instances, and search for information about WMI namespaces and class schemes. [c]

Using Powershell these queries can be leveraged to do things previously stated such as gain some information on a system and be used to gain code persistence on a system. PowerSploit, a very strong powershell post-exploitation framework, features all three types of persistence as well as a handful of other modules used for privesc, recon, code execution, and more.

Setting up a script to utilize WMI persistence can be broken down into 7 parts. $filterName, $consumerName, $exePath, $Query, $WMIEventFilter, $WMIEventConsumer and finally the WMI Query to set and bind the filter and consumer to create the instance. [d]


Here the filter and consumer names are set, and the path of the malicious executable.




The meat of the code is the Query, WMIEventFilter, and WMIEventConsumer. The Query is setup to trigger the set executable between 200 and 300 seconds after the system startup.


The WMIEventFilter is creating the WMI instance and setting the query to the filterName.


The WMIEventConsumer is creating the WMI instance and executes the given executable with system privileges.


Lastly the both the filter and consumer are registered and bound together with a __FilterToConsumerBinding instance.


After running a script to create a WMI instance on a target machine there is no easy way to go about finding that instance. You can go about using windows own program wbemtest.exe which is not very easy to use and would require you to learn and understand some WQL.


Or another GUI you could use is WMI Explorer as seen below. This makes it easier to try and search for specific WMI instances but you still need to know what you’re looking for.


The code for creating a new WMI instance is not as simple as with creating a new scheduled task or a new registry key, and trying to find a new WMI instance is much harder than looking at scheduled task GUI or looking through the registry keys. Both of these combined make it much harder to use WMI as a form of persistence but also make it hard to find once executed on a victim’s system.




[c]Probably not needed



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s