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.
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
/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.
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
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.
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.