FalconFriday — DLL hijacking & suspicious unsigned files 0xFF06

In today’s edition, we’ll cover two techniques: privilege escalation through DLL hijacking and masquerading files as unsigned processes.

Today’s content

Privilege escalation through DLL hijacking.
Execution of unsigned files that are supposed to be signed.

Privilege escalation through DLL hijacking

Blue: Privilege escalation through DLL hijacking is a stealthy technique, if a system is vulnerable. In DLL hijacking, an attacker creates or overwrites a DLL with “normal” privileges which is then loaded and executed by a process with high privileges.

So to identify a potential exploitation of DLL hijacking, we need to identify all DLLs loaded by “high integrity” processes and cross-check the DLL paths against FileCreate/FileModify events of the same DLL by a medium integrity process. That’s in a nutshell today’s hunt.

Of course, we need to do some magic to filter out false positives as much as possible. So any FileCreate/FileModify done by “NT Authority\System” and the “RID 500″ users aren’t interesting. Also, we only want to see the FileCreate/FileModify actions which are performed with a default or limited token elevation. If done with a full-elevated token, the user is apparently admin already. Details on token elevation levels can be found here.

The results of this query are very accurate, although not every hit is necessarily malicious. This query also triggers a result when a hijackable DLL has been created or modified by a benign process. Nevertheless, each result is a legit concern and should be addressed, if privilege escalation is a relevant risk for you.

Get your copy of this query on our GitHub page.

Red: At this point, the only reasonable way to bypass this detection is by leaving a gap between the moment the the FileCreate/FileModify event happens and the moment the process is started, which is big enough to bridge the lookback period.

Execution of unsigned files that are supposed to be signed

Blue: One trick used by attackers to “hide in plain sight” is to use process names which are very common in Windows. This is obviously very rudimentary, but nonetheless used fairly often in less sophisticated attacks.

This rule is aimed at detecting files that are normally supposed to be signed, but are executed unsigned.

Approach 1: List all (system32) binaries that are normally signed. Cross-check against process executions which have the same filename, but are unsigned.

Approach 2: Make a list of the top 100 executed (system) processes. Obtain all unique hashes for those processes and filter all unique processes with a low prevalence and check if they’re signed. This is based on the assumption that most commonly used files are usually signed. This assumption doesn’t always hold true unfortunately, but the query does help in identifying suspicious unsigned files on your system.

Obviously, there are ways to improve both approaches. One of the most significant improvements required is to validate if the certificate is signed by the Issuer you would expect.

Both approaches to detect unsigned files are on our GitHub page.

Red: This shouldn’t really be a big challenge for red teams. If you’re doing a red team and are not emulating any particular adversary, avoid naming your implants svchost.exe 🙂