MITRE’s data sources
- File monitoring
- Process monitoring
- Binary file metadata
While ATT&CK doesn’t list it as a related data source, security teams should consider monitoring process command-line parameters, which are often useful for comparing legitimate command lines to suspicious ones. For example, observing the
-accepteula command-line parameter can be an indicator that a Microsoft Sysinternals tool has been renamed to masquerade as something else. However, you can also expect to see the
-accepteula command-line parameter anytime a user runs a new tool, when a tool runs in a new user context, or for many of the other reasons that a user might be expect to accept a license agreement.
Binary file metadata
That said, binary file metadata is probably the most useful data source for observing threats that leverage Masquerading. Certain elements of a binary’s metadata—internal names and signature information are good examples—are reliable indicators of Masquerading.
Binary file metadata
Security teams should consider taking a close look at code signatures. Many operating systems sign binaries in a consistent manner, and we can use EDR platforms and other tools to consistently identify signature discrepancies.
Building on that, it’s possible to create an inventory of known system binaries, which you can then query for anomalies. For example, you can build a query that looks for unsigned versions of legitimate processes—such as svchost.exe. While this would fail to uncover signed malware, you can solve that problem by running a similar query that looks for legitimate Windows processes that are signed by an authority other than Microsoft.
While a process can be readily renamed, its binary metadata contains a field for “internal name” that is often a good indicator of a process’s true identity. It might make sense to compile a list of the internal names for system processes. You can then cross-reference that list with the internal names for processes executing in your environment, identifying cases where a process’s internal name deviates from what’s expected for that process.
As we noted in the analysis section above, adversaries frequently rename legitimate processes to circumvent security controls that ignore metadata and focus primarily on process names. In this way, it also makes sense to search for instances where a known internal name is associated with an unexpected process. For example, one variant of the common “Sticky Keys” attack involves replacing the file sethc.exe—an Accessibility Feature native to Windows—with a renamed copy of cmd.exe, the Windows Command Prompt. The masquerading binary is still named “sethc.exe,” however, the internal name will now indicate the true identity of the file.
Look for whitelisted processes that execute from unexpected paths; this is particularly useful for organizations that deploy standardized operating system images to their employees’ computers. Again, you can compile lists of the paths that legitimate processes typically execute from and alert on processes that execute from unexpected file paths.
Weeding out false positives
While file paths can be useful for detection, they can also be prone to false positives in certain cases. For example, different versions of operating systems may store the same processes in different file paths. If this is an issue in your organization, you may be able to decrease false positives by excluding some of these commonly observed paths from your detection queries over time.
If you don’t have in-depth access to binary metadata at scale, you can improvise slightly with a working knowledge of operating system internals. If you understand the roles and process ancestry of common Windows processes (shown in the SANS Hunt Evil Poster), you can perform quick checks to see if there are abnormalities in a single executing process. This is slightly more difficult on macOS and Linux systems but still workable with some time in a test lab.