Using aspnet_compiler.exe for AWL Bypassing

A few days ago I was working on AWL (Application Whitelisting) bypassing techniques, looking through LOLBAS, and researching some that I had yet to use or learn- enter aspnet_compiler. This is a native Windows utility for compiling ASP.NET web application, naturally. The researcher who initially wrote about using this tool for AWL bypassing is cplsec on ijustwannared.team where you can find their write up on the subject. I will leave all references down below or in hyperlinks.

The purpose of this post is for people like myself who admittedly have zero knowledge of .NET and may struggle a bit in reading between the lines on cplsec’s post on the topic, and how you can play around with AWL bypassing (for fun and profit). I will also touch on setting up AppLocker, Windows native AWL tool, for proper testing of this technique.

First, I recommend reading through the original work by cplsec before reading on to this write up as all my work is based on theirs. With that said let’s go over how to prepare our attack. As a reminder, this will cover more of the how rather than the why on this attack. Additionally, I would recommend getting relevant files on the target machine before enabling security controls simply for the sake of your sanity. Obviously there are ways to bypass security controls to get these files on the target machine, but that is a write up for another day.

Building the Project

We’re are first going to pull down cpl3h’s “BringYourOwnBuilder” github repo and open the project in Visual Studio. This is as simple as opening Visual Studio -> File -> Open -> Project/Solution and selecting the BringYourOwnBuilder.csproj file.

The important file of note here is the Class1.cs file which will hold our payload. Here cplsec has simply used a MessageBox.Show() WinAPI method for proof of concept. We will keep with the MessageBox.Show() to keep things easy, but this is where you could place your malware (shellcode injection, DLL injection, etc.).

Once the project has been built the two files that will be of the most interest to us later will be the BringYourOwnbuilder.dll file, and the Class1.cs file.

Additionally, we need the web.config file which will look like this:

<?xml version="1.0"?>
<configuration>
    <appSettings/>
    <connectionStrings/>
    <system.web>
			<compilation debug="true">
				<buildProviders>
					<add extension=".cs" 
						type="BringYourOwnBuilder.GoHaveFun, BringYourOwnBuilder"/>
				</buildProviders>
			</compilation>        
    </system.web>
</configuration>

The important line to note here is the <add extension=".cs" line which we have changed from xml.

Project File Structure Setup

Next, we need to setup the appropriate file structure. For simplicity sake I will be nearly recreating the same file structure that cplsec uses.

I would also recommend using croc for file transfers. Probably the easiest way to install it would be via the Chocolatey package manager for Powershell.

For the lazy:

Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

choco install croc

This is what we want to see:

Now croc over the previously mentioned files into the appropriate folders. It should like this:

C:\Users\%USER%\Desktop\asptest\Web.config

C:\Users\%USER%\Desktop\asptest\App_Code\Class1.cs

C:\Users\%USER%\Desktop\asptest\bin\BringYourOwnBuilder.dll

Setting up AppLocker

Now that the project is ready for execution we need to setup our defenses for proper bypassing. Let’s get started with the AppLocker setup. This requires either an Enterprise, Education, or Professional version of Windows. For this test I will be using Windows 10 Education 21H2 (build 19044.2486).

First, start the Application Identity service which is required for AppLocker to enforce policies. In an elevated Powershell run the following to start the service:

sc.exe config appidsvc start= auto

Open the Group Policy Editor and locate AppLocker:

Computer Configuration -> Windows Settings -> Security Settings -> Application Control Policies

The only category of applications we need to set policies for is Executable Rules as that is what we are testing.

Right-click Executable Rules and Create New Rule…
For Permissions- Deny Everyone.
Select Path for Conditions, Browse Folders, and select the C: drive (%OSDRIVE%*).
For Exceptions we are going to go with any Microsoft signed executable. Otherwise this rule would make the workstation near unusable. Select Publisher, Add a Reference File, and I just selected ConfigSecurityPolicy within the Windows Defender Folder. Next, widen the rule scope to the Publisher (Microsoft), select Open, and Create the rule.
A warning box will pop up asking to create default rules. Select yes.

Your Executable Rules Policy should look like this:

Now, lets test our policy enforcement and attempt to execute an application. Here I have a simple C# application/executable called messageBox_test.exe that simply pops a message box. We can see when I attempt to execute it AppLocker blocks it from running. Perfect.

Execution

Finally, the fun part. We’ve set up the proper file structure, gotten the required files and payload on the machine, and setup our defenses. Now to execute the bypass, and pop our message box.

The aspnet_compiler can be found within the Windows .NET Framework directory located at:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\

Note: Your Framework version may differ slightly so best to go to the Framework64 directory and cd into the appropriate directory for your machine.

We’re going to pretty much lift the exact syntax used by cplsec and only changing the project/application name from none to NWG as well as the User directory from which the project code resides.

cd C:\Windows\Microsoft.NET\Framework64\v4.0.30319\

aspnet_compiler.exe -v NWG -p C:\Users\Taylor\Desktop\asptest\ -f C:\Users\Taylor\Desktop\asptest\NWG -u

Success!

I hope this helped others like myself who read cplsec’s write up and struggled to understand the mechanism of the bypass. Please let me know if you believe I have made any sort of technical error in this write up, or have any further questions for me regarding this subject. This will be a companion post to one I will be submitting for NetWorksGroup in the coming days so stay tuned for that and I will add it to the below references when posted. Thanks again to cplsec for the work they did on this topic, and thanks to everyone else for checking mine out.