Introduction
After establishing a foothold inside a corporate Windows environment, there’s a considerable chance for an adversary to encounter several defenses in place.
This blog post aims on showcasing a technique for bypassing application control policies that can be employed through AppLocker.
Application Control and Whitelisting
Another mechanism commonly employed for further enhancing security on Windows servers and workstations is software monitoring solutions such as AppLocker or Windows Defender Application Control (WDAC). Such controls work by blocking the execution of binaries, scripts, and even DLLs that are outside of a predefined whitelist.
AppLocker, as an example, provides a group of default rules that can be applied with a single click, which can also be automated with the help of a Group Policy Object (GPO).
These settings can be applied through the Local Group Policy Editor (gpedit.msc), which is divided by AppLocker into three categories.
Each category has a set of default rules provided by AppLocker, which can be easily applied with a single click.
With this set of default rules applied, a non-administrative user won’t be able to run any binaries outside of C:\Windows, C:\Program Files and C:\Program Files (x86).
However, by the same token, such default rules allow for bypass, as binaries can be placed and executed inside a trusted folder. The Windows folder has directories that are writable by default:
If no custom rules were enforced to manually block execution from such directories, the bypass would consist of simply dropping instrumentation there and executing it.
Let’s explore another alternative for when execution is blocked from everywhere.
Living Off The Land
The concept of LOLBAS – Living Off the Land Binaries and Scripts consists of making use of native and trusted Windows binaries to run your malware or instrumentation. A great resource and reference is the LOLBAS Project.
An example of this would be InstallUtil:
The Installer tool is a command-line utility that allows you to install and uninstall server resources by executing the installer components in specified assemblies. This tool works in conjunction with classes in the System.Configuration.Install namespace.
The idea is then to write a tool that will leverage the utility’s functionality to execute arbitrary code.
The Installer Class provides the foundation for custom installations, it has methods for performing both Install and Uninstall processes.
The Install method, as is to be expected, requires administrative privileges. Let’s then check how the Uninstall method can be implemented.
The documentation states that a few steps have to be done:
- Inherit the Installer class
- Override the desired methods, in this case only Uninstall is required
- Add the RunInstallerAttribute to the derived class, setting it to
true
Inheriting the class would look like the following.
public virtual void Install (System.Collections.IDictionary stateSaver);
Then overriding the Uninstall method inside the inherited class.
public override void Uninstall (System.Collections.IDictionary savedState);
Lastly, add the attribute.
[RunInstallerAttribute(true)]
The full code would look like as follows.
using System;
using System.ComponentModel;
namespace applocker_uninstall {
internal class Program {
static void Main(string[] args) {
// Decoy procedure
Console.WriteLine("\n[i] Random decoy content");
}
}
}
[RunInstallerAttribute(true)]
public class AppLockerUninstall : System.Configuration.Install.Installer {
public override void Uninstall(System.Collections.IDictionary savedState) {
// Arbitrary code
}
}
The tool should then be invoked with InstallUtil, passing the respective arguments to avoid logging information and the Uninstall method.
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\installutil.exe /logfile= /LogToConsole=false /U <binary.exe>
As a simple demonstration, the tool will just fetch the current username and print it out.
It can, of course, be expanded upon your necessities and intentions. The next blog post will expand the instrumentation to act upon PowerShell CLM as well.
References and Further Reading
0 Comments