Search results for:
Written by: Asaf Perlman, Almog Shotland, Amit Martsiano
Recent years have seen the the implementation of LOLbins in threat actors’ kill chain with the goal of faster and more efficient endpoint breaches that could go undetected. LOLBins (short for “Living Off The Land Binaries”) are legitimated Microsoft-signed binaries that threat actors are fond of due to their ability to bypass security defenses and deploy attacks without having to import tools to victim endpoints through C2 servers.
Using these built-in binaries offers several benefits to attackers including remote code execution, transferring files, disabling defenses, and much more. One of the most commonly exploited LOLbins by attackers is Windows Management Instrumentation (WMI).
WMI is an infrastructure for the standardized management of data and information used as a subsystem of PowerShell which allows us to configure computer settings, run applications, monitor the computer’s applications status, and more.
WMI has been implemented by Microsoft into the Windows operating system and has become part of the Windows system since windows 2000.
WMI is an implementation of Web-Based Enterprise Management (WBEM). WBEM is a set of standards that an enterprise can use to manage its information operations in the distributed computing environment of the internet.
WBEM uses the Common Information Model (CIM) as the schema for defining information about objects which allows integration between individual processes to exchange information which can lead to faster, less error-prone manufacturing.
WMI uses this schema for storing information in the WMI repository. The purpose of this structure is to gain the ability to see interrelated systems which are composed of discrete elements.
WMI enables tasks to be performed locally and remotely to manage the system’s environment more conveniently. However, this tool can be used as an elusive method to perform malicious activities such as code execution, lateral movement, persistence, and as a command & control server.
The fact that WMI exists in almost all Windows operating systems allows malicious actors to perform complex attacks and stay off the radar.
In this article, we will discuss several different methods attackers are using WMI to achieve their goals during the attack chain.
WMI techniques & tactics represented by MITRE ATT&CK®
In the examples below, you will watch several short GIFs of attack scenario simulations that causes alerts to be triggered. The attacks were not stopped, even though an alert was generated. It’s important to acknowledge that Cynet’s prevention capabilities have been disabled for the purpose of this article. If the prevention mechanisms were enabled, none of the attacks would have been succeeded.
Windows Management Instrumentation (WMI) was built to allow remote access to Windows components via the WMI service. The purpose of this service is to perform tasks locally and remotely to manage the system’s environment more conveniently. The WMI service communicates by using Remote Procedure Calls (RPCs) over port 135. This service is often abused by attackers to move laterally in the network and deploy malicious commands by using the WMI cmdlet (WMIC) or executing files remotely.
We will demonstrate three different commands attackers can perform on remote machines using WMI:
wmic /node:”5.0.0.20” /user:”dfir\John” /password:ABC123! process call create ‘cmd.exe /c “net user /add user QWE123! & net localgroup administrators /add user |
2. An adversary can verify which operating system updates are missing by checking the installed ones. This way they can identify vulnerable components in the operating system.
wmic /node:”5.0.0.20” /user:”dfir\user” /password:QWE123! qfe list |
3. The threat actor can execute a ransomware payload that was dropped beforehand to the remote machine’s shared folder.
wmic /node:”5.0.0.20” /user:”dfir\user” /password:QWE123! process call create “\\5.0.0.20\admin$\sodinokibi.exe” |
WMI can be abused to evade security products such as XDR that base their detections on a “parent-child” process relationship.
By using the “Win32_Process” and “Win32_ProcessStartup” WMI classes, attackers can proxy the execution of their malware by spawning it as a child process of WmiPrvSe.exe
The parent process ID (PPID) of the malware will be the PID of WmiPrvSe.exe instead of the actual process that executes it.
WmiprvSE.exe is a DCOM server and is spawned under the DCOM service host svchost.exe, which is executed with the following parameters:
C:\WINDOWS\system32\svchost.exe -k DcomLaunch
We created a VBA script loaded into Word that uses the WMI classes “Win32_Process” and “Win32_ProcessStartup” to execute a PowerShell command:
In the example presented below, you can observe the spoofed process tree in which PowerShell is executed under WmiPrvse.exe:
This technique allows the breaking of the process tree so malicious actions won’t be correlated by security products or incident responders to their original parent process,
WINWORD.EXE, which doesn’t spawn any child-process:
The creation of PowerShell.exe was made via WmiPrvse.exe:
Before drilling down into this technique, it’s important to know that WMI events run as a system authority, persist reboots and require administrator privileges to run this technique.
WMI uses Managed Object Format (MOF), the language used to describe Common Information Model (CIM) classes. An MOF file typically contains classes, statements, and class instances which are added to the WMI repository (Objects.Data) when the file is compiled. Such files can be compiled by mofcomp.exe, which is part of Windows.
Since Windows has the utility to interact with WMIC (WMI cmdlet) and leverage PowerShell, this technique doesn’t require any toolkit. The Get-WmiObject cmdlet allows access to most of the WMI parameters.
However, this technique can be automated by various frameworks such as PowerSploit, Metasploit, C tools, and PowerShell scripts to provide different triggers and options for code execution.
Persistence via WMI requires the creation of the following three classes:
The PowerShell script below will download and execute Mimikatz five minutes after the system log on.
After executing the PowerShell script, we can see the WMI entry on Autoruns:
When a Windows Management Instrumentation (WMI) event is triggered it provides the attacker with System privileges.
The image below describes the process tree of the execution and PowerShell is shown running as System:
The first way to delete WMI persistence is using the application Autoruns, which lists all the system entries
Deleting WMI persistence via Autoruns will delete only the class ‘EventConsumer’ which stores the action.
The other way to clean the WMI classes and remove the persistence from the system is using PowerShell commands.
First, we will query the three mentioned classes to get the name of the persist classes. Besides the name of the classes that will be deleted, the output contains all the information of the class including the trigger and action.
Get-WMIObject -Namespace root\subscription -ClassName __EventFilter |
Get-WMIObject -Namespace root\subscription –ClassName CommandLineEventConsumer |
Get-WMIObject -Namespace root\subscription -ClassName __FilterToConsumerBinding |
Once we have the name of the classes, we will run the following commands to delete them:
|
WMI offers seamless integration with Windows objects using C#, C/C++, Jscript, VBScript, and PowerShell which are very popular among malware authors. WMI can be abused to detect virtual environments and evade getting caught by security products.
Malware authors can query for these details at the very beginninng of their malware’s execution and decide to terminate it to avoid any attempted analysis.
In general, AV products will register themselves to the AntiVirusProduct WMI class contained within the root\SecurityCenter or root\SecuirtyCenter2 namespaces depending on the operating system version.
Get-WmiObject -Namespace root\SecurityCenter2 -Class AntiVirusProduct |
For illustration, if physical memory is lower than 2GB or if there is only a single processor core, you’re probably running in a VM.
Example:
There are many indicators on the operation system, running services, processes, etc., which can tell us we are running in a virtual machine of the manufacturer “VMware”.
Example:
Windows Remote Management (WinRM) is a service that was implemented as the Web Services Management protocol (WS-Management) standard used to manage remote hardware and software. WinRM service communicates over HTTP (5985) and HTTPS (5986) and includes a command-line tool, scripting objects and Windows Remote Shell command line tool (WinRS) that may be used to obtain management data from local and remote computers that have Baseboard Management Controllers (BMCs). On Windows-based systems the management data is supplied by Windows Management Instrumentation (WMI).
Adversaries may perform lateral movement in a compromised network using the winrm command or by other programs such as CMD or PowerShell. On a Windows-based systems, using this method remotely interacts with Windows Management Instrumentation (WMI).
In the following example, we used winrm command to disable the User Account Control (UAC). The “Win32_Process” WMI class has a “Create” method which allows the attacker to execute a process via WMI using WinRM:
Winrm invoke create wmicimv2/win32_process @{CommandLine=“reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f”} -r:DESKTOP-JNG5REF |
This use case will present a life-like simulation of an actual event that was handled by CyOps. We will walk you through the artifacts that were extracted from the endpoint, the initial WMI event subscription script, and all the evidence we gathered from the infiltrated endpoint and the victim endpoint – which the attacker aimed to eventually compromise the domain controller by remote execution of a malicious payload (The famous ransomware Sodinokibi, which was implanted in the shared folder).
The initial script that triggered the remote execution can be seen below:
This script adds a WMI event named “WinUpdate”. The event will check every 60 seconds for the creation of the process “svchost.exe” by using the class “Win32_Process”. When a new instance of “svchost.exe” is created, the value of the “CommandLineTemplate” will be executed. The value is using WMIC to execute “Sodinokibi.exe” located at the shared folder.
Disclaimer – the time difference between the system logs and the parsed files is due to timezone differences between our lab and the investigated endpoint.
Observing the data from the source endpoint, we can identify the execution of Update.ps1 on the target DC using WMI
Investigating the domain controller, we gathered several artifacts that revealed the whole process from the target side:
The ransomware binary, “Sodinokibi.exe”, dropped in ADMIN$ (the shared folder) 
Windows event id 4624 is generated when there is a successful authentication for an account. Logon type 3 indicates the authentication occurred remotely, via the network. Examples for such activities could be shared folders, remote desktop connections, etc.
The Update.ps1 (the script that registers the WMI event) is dropped in ADMIN$ (the shared folder)
Parent entry number 503 represents the ADMIN$ directory which is hidden and located in “C:\Windows” 
Update.ps1 is executed remotely using WMI (Event 1)
The content of “Update.ps1” observed from PowerShell script block (event 4104) 
WMIC command execution from WMI event upon svchost.exe creation (Event 1)
The ransomware has been executed with WmiPrvSE.exe as the parent and with SYSTEM privileges (Event 1) 
Creation of Sodinokibi.exe prefetch file which tells us the time the binary was executed. Afterward – we can observe the files being encrypted:
Persistence in the WMI events can be identified by querying the three WMI classes:
__EventFilter
CommandLineEventConsumer
__FilterToConsumerBinding
As evidenced above, there is still much to work to be done by the EDR field. The ways LOLbins can be exploited are vast and remain largely uncovered. Moreover, it’s a constant game of cat and mouse between attackers and researchers. Once a new exploit technique is revealed, new detection rules are written and SOC teams are placed on high alert to protect their organizations.
The techniques we showcased are a pinnacle of the possibilities and variations that are available using WMI, and each threat actor will tailor it to fit his style and kill chain.
Here at Cynet360, the SOC and research teams are constantly investigating, hunting, and developing new detection and monitoring capabilities to cover WMI exploitation in practicular, and LOLbins exploitation in general methods to keep our customers safe and secure.
Let’s get started
Ready to extend visibility, threat detection and response?
Prefer a one-on-one demo? Click here
By clicking next I consent to the use of my personal data by Cynet in accordance with Cynet's Privacy Policy and by its partners
