WMImplant can be used to compromise Windows systems within a domain in an agent-less manner. However, every tool that exists also provides opportunities to detect their use. WMImplant is no different. I’d like to provide an under-the-hood look at how WMImplant works and give opportunities for detection (similar to others who have looked into this same topic).
WMImplant largely operates in two modes. If possible, WMImplant will directly interact with WMI on a remote system to pull information such as running processes, pulling active network cards, searching for files, etc. However, in it’s other “mode”, WMImplant will spawn a process (powershell.exe) and run various commands on the system pertaining to what you are trying to accomplish. When in this second mode, WMImplant does the following:
- WMImplant queries the targeted system to get the original value of the Win32_OSRecoveryConfiguration DebugFilePath property
- WMImplant then overwrites the value of the DebugFilePath property with the encoded command that will be executed on the targeted system
- WMImplant spawns powershell.exe on the targeted system, decodes the command stored in the DebugFilePath property, and runs the command
- After receiving the results, WMImplant encodes the results and writes back to the DebugFilePath property
- WMImplant queries the targeted system’s DebugFilePath property, decodes the results, and displays the results to the console
- WMImplant replaces the modified DebugFilePath property with its original value
- 5 character environmental variables (only letters and/or numbers)
- wmiprsve spawns powershell.exe
- Obfuscated use of the following commands
- Anonymous pipes
This is exactly spot-on with regards to how a non-modified instance of WMImplant works. Let’s take a look at the code below:
In the first red box, you can see that WMImplant is randomly generating 5 characters which is used for the environmental variable name. The second box is randomly selecting one of each of the pre-obfuscated commands that will be used by WMImplant to execute code on the targeted system. These pre-obfuscated commands are static, and not randomly generated on the fly. If you are detecting 5 character length environmental variables being created on systems and any of the above PowerShell, it may be indicative of WMImplant behavior.
WMImplant also includes a “debug” mode which displays the exact commands that WMImplant is running and the environmental variables that are being created (and deleted). To enable this mode, change the $ShowFunFactsForPOV variable to $True (shown in line 173 below).
Once you enable this mode, anytime you execute a command which spawns powershell.exe on the targeted system, you’ll get all of the debug details.
You can use the debug information from WMImplant to live test detections with on test systems to ensure coverage for WMImplant. It contains the environmental variable name, commands embedded within it, and the PowerShell command line launcher.
Additionally, Matt Graeber tweeted a PowerShell one-liner that’s can be used to see WMImplant’s host artifacts.
When you run this command, you can see the mappings between the different properties:
Any data that is saved to the DebugFilePath property is backed by the registry key located at HKLM\SYSTEM\CurrentControlSet\Control\CrashControl and the DumpFile.
The information stored within this registry key should remain relatively static, therefore any modifications to this should be suspicious.