Persistence: “the continued or prolonged existence of something”: Part 3 — WMI Event Subscription
In my previous two posts I covered persistence using both Microsoft Office and COM hijacking, in this post I’ll discuss my third favourite technique for persistence; WMI event subscription. Unlike the previous two techniques, this technique requires administrator rights but has the benefit of being fileless, meaning that no artefacts need to touch disk. This technique is also fairly well known and documented; I would highly recommend this excellent post by FuzzySec on the topic.
In short, the WMI event subscription technique allows you to permanently bind a specific action (in our case popping a shell) to a Windows event. To achieve this, there are two things that we need; a __EventFilter query which creates a filter that selects the trigger for our specific event and the Event Consumer Class which sets the action to be performed when the event is triggered.
The event filter determines the conditions on which the trigger will execute, this is done using a SQL like query language named WQL.
A very simple WQL event query may look like this:
Select * From __InstanceCreationEvent
Where TargetInstance Isa “Win32_Process”
This event will trigger every time a win32 process is created; for testing purposes you can install the trigger using the Register-WMIEvent cmdlet:
Starting a new process will cause the PowerShell block to execute:
Turning this in to something more useful, we can create an event that triggers when a specific process is created; for example outlook.exe. This trigger can be installed using C# similar to the following:
The next thing we need as part of our malicious event is the Event Consumer Class, there are two classes of interest:
- ActiveScriptEventConsumer which allows the execution of arbitrary script (either JScript or VBScript engines supported)
- CommandLineEventConsumer which allows the execution of an arbitrary command
The CommandLineEventConsumer is well covered in FuzzySec’s blog post so let’s look at how the ActiveScriptEventConsumer class can be used to load an implant.
As previously mentioned, the ActiveScriptEventConsumer class can be used to run arbitrary VBScript; we can create a VBS script that executes shellcode using SharpShooter as follows:
python SharpShooter.py — stageless — dotnetver 2 — payload vbs — output implantvbs — rawscfile payload64.bin
Next, I’ll base64 encode it so it’s easy to embed inside my WMI code:
base64 -i output/implantvbs.vbs
The ActiveScriptEventConsumer can now be deployed using the following C#:
The CommandLineEventConsumer class supports execution of an arbitrary command when the event occurs, there are numerous ways this could be used to install an implant (PowerShell, wmic, mshta, rundll32 etc) and is left as an exercise for the reader.
Putting all this together, we’ve now got a DotNet tool that’s executable through execute-assembly that we can use to create a permanent WMI event that loads a VBS script that stages an implant, let’s take a look at it in action:
What’s interesting to note is the that the implant is executing inside the scrcons.exe process, as opposed to wscript.exe et al; defenders may want to monitor this process closely if they’re not doing so already.
The C# code for the WMIPersistence tool can be downloaded from the ActiveBreach GitHub.
This blog post was written by Dominic Chell.