At the Troopers 16 Casey Smith has given a talk about the gap in Application Whitelisting.
Application Whitelisting is a technique that should prevent malware and unauthorized applications from running. Broadly speaking this is implemented by deciding if an application is trusted or not before executing it. Casey’s talk gave an understanding where this whitelisiting fails down.
In his introduction about the architecture he reminded us: There is no perfect defense. It is important to understand how the defenses work and where they fail. In the difference to exploits, which can be patched, there is no possibility to patch architecture flaws.
He focused on the AppLocker Feature of the Microsoft Windows platform. Windows implements whitelisting with a Kernel Mode Minifilter Driver. The Minifilter/Event Monitor provides a user space interface for decision support/approval which communicates with the kernel interface:
There a three different types how trust decisions can be made:
– by the path of the application executable
– by checking the publisher with the certificate of the application
– by the hash of the executable
In the main part of the talk, he showed three attacks that could allow an attacker to bypass the Application whitelisting:
I. Attacking Weak Path Rules
The default rule allow executing every binary in C:\Windows and C:\Windows\System32\. The attacker only needs a writable directory and place his malicious executable there. On a default Windows system this is possible for C:\Windows\Temp, C:\Windows\Tasks and Spool\Drivers\Color in System32. (To prevent this click no for “Create the default rules now” when installing AppLocker.)
II. .NET Utilities & Tactics
An attacker is more intreseted what application is made to do: If an attacker can utilized a .NET utility to load a .NET assembly, he can avoid filtering mechanism. The filtering mechanism intercepts a paticular request and pulls it off the queue if it’s voliates the rules: When executing binaries the event PAGE_EXECUTE is fired. But this event never occures when a .NET assembly is loaded by an .NET application.
There a two .NET utilities installed by default and signed by Microsoft, that can be misused for that. They need no administrator rights to execute.
One of the untitilies is InstallUtil.exe. To utilize it, the attacker must create a special class that inherit from class Installer and override Uninstall() which calls the payload. Casey showed in his demo, how he bypassed the protection by invoking “installUtil.exe /U katz.exe”. katz.exe is an .NET assembly which executes the latest version of Mimikatz and can be found on his GitHub account. There is also a Metasploit module for generating a custom bypass.
In Casey’s second demo he used .NET utility is RegAsm.exe. It typical needs admin rights, but only for register not for unregister. For this untilize this, you need a class that inherit from ServicedComponent and call the payload with RegisterClass().
III. Scripting Languages
Whitelisiting does NOT prevent exploitation of trusted applications. It is not preventing something that persist in memory. Upon that based the last attack: It’s using scripting language capabilities of applications.
The first demo is using the VBA Tools of Excel to execute Windows API calls. The demo PoC should launch the typical Windows Calc application but this fails, because of the Enhanced Mitigation Experience Toolkit (EMET).
The second demo is using MSHTA.EXE, which is a preinstalled and signed Microsoft executable. It can launch HTML Application, which are fully trusted web application. The PoC shows that MSHTA.EXE spawn an Excel instance that runs a shellcode macro which launches a Reverse TCP shellcode. In his demo he showed how a victim cloud be attack by sending him a link to such a file. If he clicks on open, the attacker gets a reserve shell. The EMET protection fails.
The Export Address Table (EAT) Access Filtering feature of EMET should prevent shellcode to scan EAT to look for alocated adresses as example LoadLibraryA, GetProcAddress. So Casey just moved these lookups from the shellcode assembler into trusted VBA and passes the adresses into the shellcode.
In conclusion Application Whitelisting doesn’t stop everything but it increases the visiblity, noise tracks of attacks gernates. It also removes an entrie class of attacks: download & execute and forces adversaries to re-tool its attacks. The gas still exists in scripting languages, when living off the land: misuages of trusted application like Office, .NET, WMI and powershell and by using memory injection.
To the common arguments against this technique Casey says:
– it is difficult: take it in step
– it does not stop evering: there is no perfect defense and logging has been very effective to us
His TR16 slides are available here: Mind The Gap – Exploit Free Whitelisting Evasion Tactics
His GitHub Account here: https://github.com/subTee/Troopers2016
See you at TROOPERS17!
Sven