The PATH to PWNAGE.
Background
In our previous article we detailed how we might go about blocking unwanted programs from accessing the IMDS API. We heavily referenced LOLBAS in that article and will be doing so again here. During this research a couple of interesting binaries, or more so the location of these binaries, caught our eye and we briefly wanted to address this.
When locking down user workstations one of the most common setups includes the use of AppLocker. Microsoft have even created a recommended block list to accompany both this and WDAC and we highly recommend that you check out their article if you haven’t already done so!
AppLocker Rules
We all know that PATH based rules can potentially be dangerous, but in reality, some of these conditions will likely be used in an environment.
An example program that both LOLBAS and Microsoft flag is MSBuild.exe. This program can be used to compile code on a host, is shipped on a default Windows build and should obviously be restricted from non-developers.
The locations of this binary (LOLBAS does detail a few more, so do check them out) are:
- C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe (32-bit)
- C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe (64-bit)
I think it’s fair to say that these locations are quite well known, at least in the development and offensive security fields.
During our testing we noted however that MSBuild.exe was also accessible from the following locations:
- C:\Windows\Microsoft.NET\assembly\GAC_32\MSBuild\v4.0_4.0.0.0__b03f5f7f11d50a3a\MSBuild.exe
- C:\Windows\Microsoft.NET\assembly\GAC_64\MSBuild\v4.0_4.0.0.0__b03f5f7f11d50a3a\MSBuild.exe
Depending on the contents of your WinSxS directory you might potentially find a copy there as well!
Now this might not seem like a ‘sky is falling’ issue, and it isn’t. What it is, however, is something to be very mindful of as if for example, we had an AppLocker PATH based block condition on the default known MSBuild locations (quite a common scenario), then we’d be under the impression that this potential risk may be somewhat mitigated, when in reality we’re still exposed.
It’s worthwhile audit builds to see what’s available and confirm that application rules are configured correctly.
Application Review
To help you along the path, pun fully intended, we’ve slightly adjusted the PowerShell script from our IMDS hardening article.
The code will query the LOLBAS API for a list of documented programs and scripts and will then perform a local check to see if the program exists on the endpoint. Assuming a match is found, the full path of the identified item will be written to a text file for later review.
$response = Invoke-WebRequest -Uri 'https://lolbas-project.github.io/api/lolbas.json' -UseBasicParsing
$binaries = $response | ConvertFrom-Json
foreach ($exe in $binaries.Name)
{
Get-ChildItem C:\ -Filter $exe -Recurse | ForEach-Object {$_.FullName} | tee C:\tmp\binaries.txt -Append
}
If you’re looking to reduce the internal attack surface of your organisation, check out our Build Review and Internal Penetration Testing services, or contact us for more information.