FalconFriday — Masquerading; LOLBin file renaming— 0xFF0C

February 12, 2021

Olaf Hartong

In today’s edition, we’ll cover a technique and a new feature in Microsoft Defender for Endpoint: PE header information.

LOLBins, why you still should care

There has been an abundance of blogs detailing all kinds of uses for these tools. Not only APTs and red teams are utilizing them, also a lot of malware authors are. Let’s briefly recap what constitutes a LOLBin/Lib/Script. It must:

Be a Microsoft-signed file, either native to the OS or downloaded from Microsoft.
Have functionality that is useful to an APT or red team, or other malicious person.

The image below shows an overview of the most prevalent LOLBins used by unique malware samples recently (mid December 2020 — early February 2021). The graph is based on behavioral malware sample analysis in a sandbox. This was recorded, parsed and shipped to Azure Sentinel for further investigation.

Obviously, the use of some of these processes is rare — if run from certain parent processes — and detections can be built based on that. Therefore, attackers are also often seen copying these processes to another folder or mimic the process name to evade detection — like in the example below, where svchost.exe is being executed from several locations, most of them suspicious.

svchost.exe executed from a lot of uncommon locations.

Besides copying binaries to other locations and executing them from there, it is also relatively common practice to copy and rename the binaries to something else. Below is an overview of malware samples doing exactly that to LOLBins.

LOLBins being copied and renamed before execution.

This last technique poses some challenges for detection since file copy/rename and write events are a lot more difficult to track at scale due to the sheer volume of events occurring. One of the ways to get visibility on these events was given to us by Sysmon a while ago. This approach takes the information from the PE header of the file on execution and adds it to the event.

MDE: new fields in events

Recently Microsoft also added this functionality to Microsoft Defender for Endpoint (MDE). They extended the schema for all device events by adding the following fields:

New field names added to all device generated events.

This means there are a lot of new and more efficient behavioral detection opportunities to detect renamed binaries being executed, but also where they are making network connections, downloading files or loading a .dll.

Blue: keep in mind an attacker still has the ability to change the PE header and alter the original filename to bypass detection. Make sure to also have rules that look for the specific behavior of these binaries.

Some software vendors ship products with ‘their own’ copy of these files. This is a risk by itself because it will not be patched and maintained by Microsoft, plus it exposes an additional attack surface.

Detection notes

The detection uses two arrays. The first contains all the filenames of the most common LOLBins. The second contains well-known original filenames of other interesting Microsoft-signed files. E.g. the first array contains common LOLBins like “regasm.exe”, and the second array contains, for example, “psexec.c”.

The next step is to concatenate these two arrays and use that as a base to match all executed processes against – to detect renamed processes.

Once you start whitelisting certain uses of these binaries which are legitimate in your environment, make sure it as specific as possible by including the FolderPath, FileName and OriginalFileName and maybe event the parent process and the command line. You’d want to leave as little room as possible for evasion.

You can grab our detection for renamed processes from our repository.