In today’s edition, we’ll cover two techniques: suspicious parent-child process relationships and impersonation with the RunAs command.

Today’s content

• Suspicious parent-child process relationships
• Impersonation using ‘RunAs’

Suspicious parent-child relationships for operating system processes

As referenced in an article earlier this year by the cool folks from Elastic, current solutions for malware detection (AV & machine learning) have been more and more successful in detecting file-based attacks. This caused threat actors and red team operators alike to shift to “living off the land” techniques to bypass these solutions. For example, by involving trusted system tools or pretending to be one of these processes, attackers can simply spoof processes and blend in with the ‘noise’ the process creates.

Blue: Similar to the attackers hiding in plain sight (using common process names; a technique discussed in FalconFriday 0xFF06), exploiting parent-child relationships also allows adversaries to remain hidden. As a defender it’s easy to get lost here.

First, you might want to understand how some important parent-child relationships work. This can provide a base for spotting what is suspicious and what is not. A great resource for this information is for instance the SANS DFIR Find Evil poster, even though it has not been completely updated to Windows 10 in terms of the parent-child relationships. The paths and user account the process will be spawned under remain to be the same.

These parent-child relationships have been broadly documented and provide a solid base for a low false-positive detection. Besides the relationship, it obviously is a great idea to also look at the original file name of the process, its launch folder, and the user name it is running under as separate detections. Below you can find an example.

 

 

Keep in mind that some of these parent processes launch their child process(es) and immediately terminate, which in some cases might cause the parent field to remain empty. This is caused by the speed of it terminating, where the system wasn’t quick enough to pick this up.

Second, you want to be looking at some follow-up items for these suspicious processes. Examples are:

• Is the processes signed and is this a valid, trusted cert?
• Is the process running under the expected System/User context?
• Is the process running from the expected path ?

Red: From a red teaming perspective, you can either mimic these chains with care or you can try to bypass this detection by for instance injecting into one of these processes and spawn believable child processes.

Get your copy of this query on our GitHub page.

Impersonation using ‘RunAs’

In this query we explore the use of RunAs, a command-line tool built into Windows that allows you to run applications on behalf of another user. MITRE classified this as privilege escalation, although it feels more like impersonation / lateral movement.

From an attacker’s perspective, we use this RunAs mostly for performing SSO against an application on behalf of a specific user whose machine we can’t or don’t want to compromise. So if you have DA access but the SQL Server you’re trying to breach only allows person X to login, you can run SQL Studio Management Server as user X to log in.

Blue: To spot suspicious behavior potentially misusing RunAs, we recommend taking the following approach:

First, you start by de-obfuscating the command line usage. This is to prevent any kind of obfuscation on the command line. The parse_command_line function ensures that the command line is the same as the receiving program would see it.

The next step is to start filtering the noise. There are several considerations here:

• You want to filter on user-specific use of their admin account. This results in excluding legitimate examples, such as Bob running a terminal through his personal admin account adm.Bob.
• You also want to exclude local admin account activities (e.g. lapsadmin) by generic teams like the service desk. Abuse of the generic local admin account should be detected in another query.
• Finally, we join the results of the RunAs with the logon events to get some more data for the analyst on the account used to log in with.

Depending on your environment, you might need to filter out some more stuff which is known good behavior.

Also, note that this query cuts some corners regarding parsing the command line options. Parsing command line options is hard and not in scope for FalconFriday. However, if you want to use this in a production environment, make sure to parse the command line parameters properly to prevent bypasses.

Red: The most reliable way to bypass this, is to build your own .exe which implements the same functionality, but has a different name and signature. This is a foolproof way to bypass this tool. It’s almost as simple as implementing a call to CreateProcessWithLogonW.

A simpler bypass — if someone has just copy-pasted this rule without improvement — is to bypass the shortcuts taken in this specific implementation. The arguments are not fully parsed and interpreted, rather we use strings to match for various parts. For example, any result that has “:lapsadmin” in the command line, will be whitelisted. So if you run

runas /user:LAB\EvilUser “cmd.exe && :lapsadmin”

you will bypass this query. For a production environment, we recommend a more find-tuned query.

Finally, you can just rename the runas.exe to something else, but any decent blue team will find you for “masquerading”. But it might work for some immature environments.

Get your copy of this query on this GitHub page.

Knowledge center

Other articles

FalconForce realizes ambitions by working closely with its customers in a methodical manner, improving their security in the digital domain.

KVK 76682307
BTW NL860745314B01