Skip to navigation Skip to main content Skip to footer

Microsoft announces the WMIC command is being retired, Long Live PowerShell

10 March 2022

By Michael Gough

Research Detection and Threat Hunting Digital Forensics and Incident Response (DFIR)

Category:  Detection and Threat Hunting

What is WMIC?

The Windows Management Instrumentation (WMI) Command-Line Utility (WMIC) is a command-line utility that allows users to perform WMI operations from a command prompt. WMI is an interface providing a variety of Windows management functions. Applications and WMI scripts can be deployed to automate administrative tasks on remote computers or interface with other Windows tools like System Center Operations Manager (SCCM) or Windows Remote Management (WinRM).

Unfortunately for defenders, default WMIC logging is minimal and primarily runs directly in memory without writing any files to disk. Due to WMI’s built-in capabilities and small forensic surface area, attackers often weaponize WMI for all facets of the post-exploit attack chain.

Malicious WMIC Usage

  • cmd.exe /c “wmic /node:”10.123.34.123″ /user:”WorkGroupBob-admin” /password:”Summer2022″ PROCESS CALL CREATE “cmd.exe /c C:ProgramDataregit.bat” >> C:WINDOWSTEMPcb66E3.tmp

In the example above, an attacker has already gained Administrator privileges to execute a WMIC command. Here, the actor launches a malicious payload against a remote host and saves the results to a temp file. Fortunately for defenders, if command line audit logging is enabled, the Windows Security log would capture this execution under event ID 4688. However, these actions would not have been captured if the attacker simply called “wmic” and conducted their operations within the WMI console. There is no recorded logging by leveraging the console, making it a good tool for attackers to live off the land with little fear of detection.

Goodbye WMIC, Hello PowerShell

Microsoft is reportedly no longer developing the WMIC command-line tool and will be removed from Windows 11, 10, and Server builds going forward. However, WMI functionality will still be available via PowerShell. So now is a great time to consider how attackers will adjust to these developments and start tuning your detections accordingly.

Preparation

The default settings of Windows logging rarely will catch advanced attacks.  Therefore, Windows Advanced Audit Logging and PowerShell Audit Logging must be optimally configured to collect and allow detection and able to threat hunt for malicious WMI and similar attacks.

Organizations should have a standard procedure to configure the Windows Advanced Audit Policies as a part of a complete security program and have each Windows system collect locally significant events.  NCC Group recommends using the following resource to configure Windows Advanced Audit Policies:

  • Malware Archaeology Windows Logging Cheat Sheets
  • Malware Archaeology Windows PowerShell Logging Cheat Sheet

Log rotation can be another major issue with Windows default log settings.  By leveraging Group Policy, organizations should increase the default log size to support detection engineering and threat hunting, as outlined below.

Ideally, organizations should forward event logs to a log management or SIEM solution to operationalize detection alerts and provide a central console where threat hunting can be performed.  Alternatively, with optimally configured log sizes, teams can run tools such as PowerShell or LOG-MD to hunt for malicious activity against the local log data as well.  Properly configured logging will save time during incident response activities, allowing an organization to recover faster and spend less money on investigative and recovery efforts.

Detection and Threat Hunting Malicious WMI in PowerShell logging

WMI will generate log events that can be used to detect and hunt for indications of execution.  To collect Event ID 4104, the Windows PowerShell Audit Policy will need to have the following policy enabled:

  • PowerShell version 5 or later must be installed
    • Requires .Net 4.5 or later
  • Minimum Log size – 1,024,000kb or larger
  • There are two PowerShell logs
    • Windows PowerShell (legacy)
    • Applications and Services Logs – Microsoft-Windows-PowerShell/Operational
  • The following Group Policy must be set
    • ModuleLogging Reg_DWord =1 or ENABLED
    • ModuleNames Reg_Sz – Value = * and Data = *
    • ScriptBlockLogging Reg_DWord =1 or ENABLED

The following query logic can be used:

  • Event Log = PowerShell/Operational
  • Event IDs = 4100, 4103, 4104
  • User = Any user, especially administrative accounts
  • Path = Look for odd paths or PowerShell scripts
  • ScriptBlock = What was actually executed on the system that will contain the cmdlets listed below

WMI PowerShell cmdlets

The following PowerShell cmdlets should be monitored for suspicious/malicious activity:

  • Cmdlet          Get-WmiObject
  • Cmdlet          Invoke-WmiMethod
  • Cmdlet          Register-WmiEvent
  • Cmdlet          Remove-WmiObject
  • Cmdlet          Set-WmiInstance

Also, the following PowerShell CIM (Common Information Model) cmdlets should also be monitored as a replacement to older WMI cmdlets:

  • Cmdlet          Export-BinaryMiLog
  • Cmdlet          Get-CimAssociatedInstance
  • Cmdlet          Get-CimClass
  • Cmdlet          Get-CimInstance
  • Cmdlet          Get-CimSession
  • Cmdlet          Import-BinaryMiLog
  • Cmdlet          Invoke-CimMethod
  • Cmdlet          New-CimInstance
  • Cmdlet          New-CimSession
  • Cmdlet          New-CimSessionOption
  • Cmdlet          Register-CimIndicationEvent
  • Cmdlet          Remove-CimInstance
  • Cmdlet          Remove-CimSession
  • Cmdlet          Set-CimInstance        

Sample Log Management Query

The following query is based on Elastic’s WinLogBeat version 7 agent.

event.provider="Microsoft-Windows-PowerShell" AND event.code=4104 // PowerShell WMI commandlets (winlog.event_data.ScriptBlockText="*Get-WmiObject*") or (winlog.event_data.ScriptBlockText="*Invoke-WmiMethod*") or (winlog.event_data.ScriptBlockText="*Register-WmiEvent*") or (winlog.event_data.ScriptBlockText="*Remove-WmiObject*") or (winlog.event_data.ScriptBlockText="*Set-WmiInstance*")  | UserName:=winlog.user.name | Domain:=winlog.user.domain | ScriptBlock:=winlog.event_data.ScriptBlockText | User_Type:=winlog.user.type | PID:=winlog.process.pid | Task:=winlog.task | Path:=winlog.event_data.Path | OpCode:=winlog.opcode | table([@timestamp, host.name, UserName, Domain, User_Type, Path, Task, OpCode, ScriptBlock])

Detection Engineering – Filtering Known Good

Once an output of all WMI PowerShell cmdlets is produced, you can start filtering known good activity to narrow the results to suspicious activity. Take the following example:

The following is a typical result that might be seen in the logs, and in this case excluded as a false positive or known good to reduce results.  The path of the PowerShell script or the actual PowerShell executed (ScriptBlock) is what to focus on.

In this example, our focus is on the highlighted PowerShell executed (ScriptBlock). Here the command is just checking the disk for an install routine which is typical on a Windows system.  From here, you can begin building out your detection logic to better find suspicious WMI PowerShell activity and support threat hunting efforts.  Play close attention to the names of the scripts, location of where the script executes, the context of the user executing the script, the quantity of systems the script runs on, and the calls being used in order to filter out the known good items.  Generally, directories that users have read-write access should be closely reviewed such as; C:Users.

Conclusion

WMI and WMIC have been consistent attack vectors since their introduction. With the deprecation of WMIC, malicious usage WMI functionality with PowerShell will likely increase. We hope this information can assist your detection and threat hunting efforts to detect this and similar types of attacks. Happy Detection and Hunting!

Additional Reading and Resources

Michael Gough

Michael Gough