sub-technique T1036.005
Match Legitimate Name or Location
Adversaries often name their malicious payloads after system binaries to evade detection strategies that rely on filenames. T1036.005 is the only sub-technique making its debut appearance in the report this year.
Pairs with this song Threat Sounds
*cue CSI theme song* Who who? Who who?
Editors’ note: While the analysis and detection opportunities remain applicable, this page has not been updated since 2022.
Analysis
Why do adversaries match legitimate names or locations?
Adversaries often take non-native binaries and rename them so that their name or location matches that of a legitimate system binary to evade detection. The hope is that by giving an arbitrary binary a legitimate or expected filename, malicious activity will seem benign and blend in with the system—and, by extension, that a security analyst would not flag the activity for further investigation. While our analysis focuses mostly on endpoint concepts like processes and files, this technique also applies to user identities or container namespaces.
How do adversaries match legitimate names or locations?
Adversaries will often leverage system utilities or common commands—such as the Unix’s mv command (or PowerShell’s similar Move-Item cmdlet, which can be shortened to mv)—to move third-party tools to locations that commonly contain system binaries. They may also use built-in functionality in tools, such as the -OutFile flag in PowerShell, to save tools with a name matching an existing binary, which makes it appear legitimate unless a full path is available to analyze.
We often observe adversaries using this technique to mimic less well known system binaries. Two of the most common masqueraded binaries we saw in 2021 were the Windows Console Host (conhost.exe) and the Windows Service Host (svchost.exe). Both processes have fairly consistent legitimate behavior, with only a handful of legitimate locations and command-line parameters. They are also unlikely to be brought onto the system by legitimate third-party software, so anomalous binaries attempting to masquerade as them stand out.
Adversaries may also extend their time in an environment by creating an account or hostname mimicking a legitimate entity, or by running a malicious container in a namespace consistent with the pattern used by a container orchestration system.
Visibility
Note: The visibility sections in this report are mapped to MITRE ATT&CK data sources and components.
Relevant telemetry for this technique will vary depending on what exactly an adversary is attempting to match. Our detection analytics focus on tools and binaries, so we primarily collect process and file modification telemetry to understand both what is legitimate and what is masquerading as legitimate on an endpoint. Adversaries attempting to hide as something else, such as an IAM role in the cloud, could be identified by collecting data relevant to the entity—the cloud service’s API in this case—and analyzing it for anomalies.
Process and process metadata monitoring
Third-party tooling or native logging features that offer access to process metadata (e.g., process names, internal names, known paths, etc.) are among the most effective data sources for observing or identifying matched legitimate names or locations. As is the case for renamed system utilities, the most effective method for finding malware that’s masquerading as a legitimate system binary is to compare the name embedded directly into the binary file (i.e., its internal name) with its externally presented name and generate alerts whenever those two names are different or deviate from what is expected.
You can also compare expected process paths to the actual process paths—basing expected paths on what is normal for the binary given its internal name—to detect relocated system binaries that have not been renamed.
Last but not least, if you maintain a store of System32 binaries and their known hashes, you can generate alerts whenever process names deviate from expected hash values.
File monitoring
Much like process monitoring, filesystem events can be used to identify binaries with names or binary metadata we’d only expect to find in specific folders. For Windows, this is most often achieved by comparing binaries with known ones found in System32. On Linux and macOS, system binaries should mostly run from predefined paths like /bin/, /usr/local/bin, etc. Depending on how the system is used, other directories may be considered normal too, such as a developer executing Python from a .pyenv folder in their home directory. This is where knowing normal for your organization becomes a necessity.
Command monitoring
Most endpoint sensors provide command lines as part of their process telemetry, so this data source should be ubiquitous. Many binaries take a wide variety of command-line parameters, so detecting masquerading in this way can be challenging. Start by focusing on a few processes with limited command-line parameters, such as conhost.exe or svchost.exe on Windows. On Linux, init processes like systemd can be a good target—there are typically only one or two running at once, and their parameters don’t change much.
Network monitoring
The presence of network connections in processes that don’t typically initiate them can be a reliable indicator of masquerading. Additionally, profiling processes known to initiate network connections to a specific domain can help identify processes that are not what they say they are.
Collection
Note: The collection sections of this report showcase specific log sources from Windows events, Sysmon, and elsewhere that you can use to collect relevant security information.
Windows Event ID 4688: Process Creation
Process Creation (4688) events are an invaluable resource for detecting masquerading on Windows. They contain the running process path and, if available, command-line parameters that can be compared to legitimate system binaries.
Process auditing on Linux
Audit
Linux endpoints have a few native options for auditing processes. The audit framework has been around a long time, so if you have older systems, this may be the best route to take. You can create audit rules to monitor specific files or system call events. To monitor processes, consider creating rules surrounding the exec family of system calls.
Linux kernel modules (LKM)
LKMs are the most flexible way to collect data, as a developer can create any logic they want to manipulate kernel objects. Unfortunately, this flexibility is also dangerous, and it can lead to system instability if not handled properly.
Extended Berkeley Packet Filters (eBPF)
eBPF offers a newer method of collecting security-related data in the kernel. We have covered this in more detail in the eBPF for security article on our blog, but generally, eBPF will empower you to monitor specific system calls, such as the exec family, and collect process telemetry without risking system instability.
Process and file auditing with the macOS Endpoint Security Framework
Apple recently released the Endpoint Security Framework for macOS. This framework provides many ways to generate security telemetry natively on a system. Events cover everything from process execution to file creation and more. These excellent blog posts by the folks at Objective See detail how to instrument this framework for interesting events.
Sysmon Event ID 1: Process creation
Sysmon process creation events are another rich source of telemetry for detecting masquerading since they allow you to analyze process metadata and compare if internal binary names match presented filenames.
Detection
All detection opportunities for masquerading techniques rely on a solid baseline. Otherwise, how would a detection engineer differentiate between a legitimate name or location and an illegitimate one? If possible, start with a statistical analysis of running processes, pinpointing those processes with very low command-line prevalence, and using online resources to understand which command-line parameters are unexpected. Online man-pages for Linux/BSD systems should contain expected parameters, and Microsoft’s documentation for Windows Server should have most common Windows commands listed.
Presented filename doesn’t match internal name
We have covered profiling Windows binaries in System32 for detection opportunities on the Red Canary blog. This continues to be a highly effective and durable method for catching malicious activity, and any organization that has a significant set of Windows systems should consider this strategy. In essence, whenever an internal name deviates from a filename, consider investigating or alerting. The following pseudo-analytic is a good starting point for developing detection coverage:
process_name == notepad.exe
&&
internal_name == 'rclone'**Note: This is an arbitrary example. In reality, you might want to alert on any internal name other than “Notepad” here.
System processes executing outside normal directories
On Linux, we don’t have the luxury of comparing a process name with the corresponding executable’s internal name due to lack of signing and version information in ELF files. Even still, we can apply a similar logic from Windows: targeting specific system binaries located outside of normal location. For example, we have observed a coinminer renamed to systemd and executed from the /dev/shm directory. We knew a process with this name should never execute from world-writable directories, and that knowledge helped us identify additional behaviors in surrounding activity that have improved our detection coverage since. This same technique applies equally well to macOS binaries as it does to Linux and Windows.
Command-line parameters don’t match normal execution parameters
One tell-tale sign of process masquerading is when binaries claim to be part of the running system but don’t have the functionality normally associated with them. This often presents itself in the form of different command-line parameters than what the legitimate system binary uses. The svchost.exe binary has a limited set of parameters that can be easily identified as missing. Our blog post on process masquerading focuses on the known behavior of svchost.exe, including the importance of the -k flag. As an example, consider iterating on the following detection analytic:
process == svchost.exe
&&
command_line_does_not_include ('-k')Processes with unexpected names making network connections or creating files
We have found a handful of service-oriented network domains used both maliciously and in a business’s normal operations. These types of domains typically fall under the development umbrella, such as Ngrok, or unwanted software, such as Tor and P2P software like BitTorrent. We’ve found that when adversaries use these services, they will often rename their binaries to disguise their intent, such as renaming ngrok.exe to the less conspicuous sysmon.exe. In this case, we expect the Ngrok service to only be contacted by the former, and we can identify outliers by simply looking at all processes contacting ngrok.io and excluding ngrok.exe and web browsers (generally, it’s a good idea to exclude browsers from all similar detection analytics that rely primarily on network connections). A similar concept can be applied to network connections to the Tor network.
Weeding out false positives
Many of the false positives we’ve encountered result from poor assumptions during the baselining process. For example, it’s not unusual for web browsers to initiate connections to ngrok.io and its subdomains, especially in organizations with many developers. Additionally, we have observed many software packages executing their own Windows system binaries from non-standard locations, or legitimate binaries with generic names matching system binaries, such as services.exe. Understanding “normal” requires extensive analysis of your environment, and you’ll absolutely want to get there before deploying a new detection analytic or you risk a flood of alerts into your SOC.
Testing
Start testing your defenses against masquerading using Atomic Red Team—an open source testing framework of small, highly portable detection tests mapped to MITRE ATT&CK.
Getting started
View Atomic tests for T1036.005: Match Legitimate Name or Location. In most environments, these should be sufficient to generate a useful signal for defenders.
The following Atomic Red Team test demonstrates compiling a custom executable and naming it as svchost.exe in an attempt to blend in:
Run this test on a Windows system using Command Prompt:
Add-Type -TypeDefinition @'
public class Test {
public static void Main(string[] args) {
System.Console.WriteLine("tweet, tweet");
}
}
'@ -OutputAssembly $Env:windir\Temp\svchost.exe
. $Env:windir\Temp\svchost.exeUseful telemetry will include:
| Visibility | Collection | |
|---|---|---|
| Visibility : Process metadata | : Process name and metadata don’t match. | Collection : EDR, Sysmon Event ID 1, and Windows Event ID 4688 should collect relevant telemetry. |
Review and repeat
Now that you have executed one or several common tests and checked for the expected results, it’s useful to answer some immediate questions:
- Were any of your actions detected?
- Were any of your actions blocked or prevented?
- Were your actions visible in logs or other defensive telemetry?
Repeat this process, performing additional tests related to this technique. You can also create and contribute tests of your own.