Just over one year ago (November 2015), I released [WMIOps](), a PowerShell script that enables a user to carry out different actions via Windows Management Instrumentation (WMI) on the local machine or a remote machine. WMIOps can: * Start or stop a process. * Return a list of all running processes. * Power off, reboot, or log users off the targeted system. * Get a listing of all files within a directory. * Read a file’s contents. * …and more. As I continued to develop WMIOps and use it during [Mandiant Red Team Operations](), I realized that it has some of the same capabilities that are in Remote Access Tools (RATs). WMIOps’s capabilities were in a state of disparate functions, but if I wove what existed along with new functionality, I could create a RAT. After months of development and internal testing, I’m happy to publicly release [WMImplant](). WMImplant leverages WMI for the command and control channel, the means for executing actions (gathering data, issuing commands, etc.) on the targeted system, and data storage. It is designed to run both interactively and non-interactively. When using WMImplant interactively, it’s designed to have a menu of commands reminiscent of Meterpreter, as shown in Figure 1. ![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/WMImplant/Fig1.png) Figure 1: WMImplant main menu #### Data Storage and Device Guard After spending some time developing WMImplant, I ran into issues storing data on systems that used [Device Guard](), a Microsoft security feature added in Windows 10 and Server 2016. Even though this feature and these operating systems are not widely deployed today, I wanted WMImplant to support these systems since I expect Device Guard protected systems to become more common, especially at security-conscious organizations. Device Guard helps protect systems by employing (among other capabilities not detailed here): 1. Code Integrity Policies – When deploying Device Guard, administrators will create a code integrity policy (CIP) that explicitly defines what is allowed to run on the protected system. This granularity can range from file hash, file name, publisher, both file name and publisher, and much more. Administrators can create the CIP from a gold-imaged computer. Administrators can further enhance their CIP by preventing applications that provide attackers the ability to bypass Device Guard’s protections from running. Finally, administrators can use Group Policy Objects (GPO) to enable Device Guard, preventing executables or select scripts from running unless explicitly allowed, per the CIP. 2. PowerShell Constrained Language Mode – Device Guard auto-enrolls PowerShell into [ConstrainedLanguage]() mode. Constrained Language mode restricts the cmdlets and data types that are allowed to run in PowerShell. In this mode, .NET methods are completely blocked unless they are an allowed data type. On a Device Guard protected system, attackers cannot run custom executables, and the available PowerShell cmdlets are severely restricted. For example, simple functionality such as base64 encoding a string is not permitted within Constrained Language mode, as shown in Figure 2. ![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/WMImplant/Fig2.png) Figure 2: PowerShell Constrained Language mode blocking base64 encoding At first, I designed WMImplant to use the Windows Registry for data storage, as described in [Matt Graeber’s WMI research](). However, after discussing using the Windows Registry for data storage with Matt Dunwoody (a Mandiant coworker), he suggested, “Why not also use WMI itself for storage?” This conversation led me to research using WMI for data storage. I found a proof-of-concept for creating custom WMI properties (Figure 3) in FireEye’s report on [WMI Offense, Defense, and Forensics](). ![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/WMImplant/Fig3.png) Figure 3: Sample code from FireEye report on WMI Offense, Defense, and Forensics However, after testing this code on a Device Guard protected system, I discovered that this wasn’t permitted within Constrained Language mode, as shown in Figure 4. ![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/WMImplant/Fig4.png) Figure 4: Constrained Language mode blocking WMI property creation After some additional research, I found that within Constrained Language mode, users are able to create custom WMI classes. But, as evidenced by Figure 4, WMI property creation is not allowed, so this wouldn’t work for data storage. Therefore, my next thought was to store data in an existing WMI property. In order to leverage an existing WMI property, a few conditions would need to be present: 1. The property needs to be of type string. 2. The property needs to be writable. 3. The property needs to accept an arbitrary length of data. 4. Modifications to the property need to not blue screen or degrade use of the targeted system. 5. Most importantly, the property needs to be writable within Constrained Language mode. I modified an existing PowerShell script to enumerate all WMI classes, find the properties of each class, check if each property is a string type, and determine if it is writable (the script is [available here]()). The script identified a list of candidate WMI properties, but for one reason or another, modifications to those that I initially tested resulted in “general failures”. Then, I came across a class I have not previously used: [Win32_OSRecoveryConfiguration](). This class has a property named “DebugFilePath”, which is the file path where Windows will place a memory dump after a computer failure, as shown in Figure 5. ![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/WMImplant/Fig5.png) Figure 5: Win32_OSRecoveryConfiguration’s DebugFilePath property The DebugFilePath appears to only accept a file path, and the property should be limited to the length of a valid Windows paths (260 characters by default or 32k with LongPathsEnabled). In testing, however, I discovered that I could write an arbitrary string to the DebugFilePath property within Constrained Language mode without adversely affecting the targeted system. The final test was to determine how much data could be placed in the DebugFilePath property. ![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/WMImplant/Fig6.png) Figure 6: Data storage test within DebugFilePath Figure 6 shows that the DebugFilePath property can store over 57 megabytes of data. This satisfied the data storage requirement for WMImplant, and future testing showed that the DebugFilePath property could store more than 250 megabytes of data. Additionally, using the DebugFilePath WMI property for data storage provides the side-benefits that it is easily retrievable and modifiable remotely. This discovery shaped WMImplant’s command and control communications methodology. For commands issued by WMImplant that require data storage, the communication process is as follows: 1. Remotely query and obtain the original value for Win32_OSRecoveryConfiguration’s DebugFilePath property. 2. Use WMImplant to execute a command on the targeted system (such as ifconfig), encode the output, and store the encoded results in the DebugFilePath property. 3. Remotely query the targeted system’s DebugFilePath over WMI to receive the encoded results. 4. Decode the results and display them to the console. 5. Set the DebugFilePath property on the targeted system back to its original value. This methodology for command and control communications minimizes the amount of time that the WMI property is modified from its original state. #### WMImplant Usage I’ve developed WMImplant for both interactive and non-interactive use. Users also have the ability to change the user account that is authenticating to the targeted machine. As shown in Figure 7, users can issue the “change_user” command, provide the username and password to use, and then all future commands through WMImplant will authenticate with the provided credentials. ![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/WMImplant/Fig7.png) Figure 7: Changing the current user context within WMImplant The easiest way to use WMImplant is interactively; however, that isn’t always possible. RATs such as Meterpreter or Cobalt Strike’s Beacon allow users to load and execute PowerShell scripts, but both of those tools require non-interactive use. That is, the tools accept a command to run, execute it, and return the results. They do not allow the user to interact with the command while running, however. WMImplant includes a built-in command-line generating feature specifically for this use case. To generate a command-line, start WMImplant and specify the “gen_cli” command. After issuing the “gen_cli” command, the user will be presented with the normal WMImplant menu and asked for the command to be run. WMImplant will then ask for any required information for the command specified. Once the user has provided everything that’s required, WMImplant will display the command-line command to run in a non-interactive manner, as shown in Figure 8. ![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/WMImplant/Fig8.png) Figure 8: “gen_cli” output At this point, the user can load WMImplant within the RAT of choice, and copy and paste the command to run WMImplant non-interactively. Another of WMImplant’s capabilities is the ability to run a PowerShell script on a remote machine and receive script output. This is performed through a multi-step process: 1. The attacking system queries the targeted system’s DebugFilePath property to obtain its original value. 2. The attacking system reads in the specified PowerShell script, encodes it, and stores it in the targeted system’s DebugFilePath property. 3. WMI spawns a PowerShell process on the targeted system that reads the DebugFilePath property, and decodes the PowerShell script. 4. The PowerShell process runs the user-specified function and stores the function output in a variable. 5. The data in the variable is encoded and stored in the DebugFilePath property, and the PowerShell process exits. 6. The attacking system makes an additional WMI query for the DebugFilePath value (currently storing the encoded data), decodes the data, and displays its contents to the console. 7. The attacking system replaces the encoded data with the original DebugFilePath property contents on the targeted system over WMI. This multi-step process is demonstrated in Figure 9. ![](https://www.fireeye.com/content/dam/fireeye-www/blog/images/WMImplant/remoteposh.gif) Figure 9: Remote PowerShell execution While I’ve only talked about a limited number of WMImplant’s features, others include: * Setting/removing the “UseLogonCredential” Windows Registry value to enable credential caching. * Uploading/downloading files. * Enabling/disabling Windows Remote Management (WinRM) to remotely connect to and issue commands on a system using PowerShell. * Identifying users who have logged in to the targeted system. * Listing files by directory. * Reading file contents. * …and more. I hope that WMImplant can help others as it has helped us on multiple assessments. If you notice any bugs, please let me know and I’ll be happy to get a fix pushed! WMImplant can be downloaded [here](). #### Thanks I want to state that I wouldn’t have been inspired to work on this without the [previous work]() of Matt Graeber, Willi Ballenthin, and Claudiu Teodorescu. Their work gave me a lot of great ideas that I was able to build upon when developing WMImplant.

WMImplant – A WMI Based Agentless Post-Exploitation RAT Developed in PowerShell