It is nice when random things come together to give you a novel attack during an engagement, especially when it starts to feel like the environment is completely sterile.

Recently we had set ourselves the goal of elevating privileges on a laptop not too far removed from its original imaging. We did have some credentials for a low privilege domain account so there are some evergreen approaches that can be considered... but that's not what this post is about.

The endpoint was also running Airlock, an application whitelisting solution, which was configured to whitelist DLLs in addition to executables (from our experience this is fairly rare in production environments as it breaks too many things without careful configuration).

Now, this is a real pain as it rules out quite a few options from what was already a situation pretty deprived of the common issues.

Patches? Up to date (as they normally are on workstations these days). Scheduled tasks? Nothing. Service bugs? Nope. Problems with installed applications? Nothing. And so on and so forth.

This got us looking at the event logs.

Unless you're going into eventvwr.exe with a specific problem in mind, to troubleshoot some broken software or something, like a normal and healthy individual, it's pretty easy to drown. But a bit of scrolling around did reveal something that caught our eye.

Event Viewer showing failing scheduled task.

A failed scheduled task! This was strange as we didn't notice anything in the task scheduler. Turns out that some of these procedures were executed by Group Policies Tasks and hidden to low privileged users on the client.

This may be because these scheduled tasks are immediate run group policy tasks, which don't appear as permanent items in the scheduler - if this isn't exactly correct, let us know!

After investigating the group policy files in SYSVOL, we found a few other immediate run scheduled tasks from the same policy too, all run as SYSTEM.

One, in particular, drew our attention which ran a bat file off a share (the bat file's permissions were secure - why is nothing ever easy?).

This bat file copied everything from the directory in which it resided to a directory created on the local system. Among these files, there was an executable responsible for uninstalling a different security product, which the bat script ran from the newly-created directory.

Getting ahead of ourselves, we pulled these files off the laptop to hunt for potential DLL side-load issues affecting the uninstaller (maybe we can just drop a DLL in that dir), and yes, there were a few. We compiled up a user adding DLL, uploaded it to the endpoint, and ran gpupdate.exe /force and...

Airlock denies the loading of the bad DLL (again, why is nothing ever easy?).

Airlock, preventing the loading of our malicious DLL.

So much for that.

SYSTEM processes copying things to writable locations however reminded us of James Forshaw's iconic class of vectors involving junctions.

A little secret between us here - understanding and retaining all of the theory behind junctions, hardlinks, symlinks, mountpoints and other insanity, and then all the different ways they can be exploited, is only really possible for about 3 minutes after binge-watching James' talks for the 15th time, but can be tested for quickly and easily by just... trying some attacks and seeing what happens.

We took this experimental approach on a test machine (sans whitelisting) and learned that by using the 'bait and switch' approach we could indeed trick the task into copying the uninstaller executable pretty much anywhere we please.

Well, we can write a legitimate and harmless executable anywhere we like, what now?

We set our sights on "Airlock.sys", one of the drivers responsible for the whitelisting, and overwrote it.

Clobbered whitelisting driver.

Rebooting the endpoint lead to... no more whitelisting! Airlock didn't seem to complain or attempt self-repair, it just didn't work.

Of course, with no more whitelisting, we could attempt the DLL side-load that previously failed, and sure enough, we got our elevation.

There isn't really a moral to this story, other than reminding offensive security people to spend time trawling event logs, and that junction bugs can absolutely be useful in real-world time-sensitive testing conditions.

Note: The exploits described above are not taking advantage of any kind of weakness or 0-day in Airlock, but purely an environment-specific configuration issue!

MITRE Tactics