Technique T1036

Masquerading

There is no specific threat that explains the prominence of masquerading across our customers. However, the technique is versatile, broad, and effective, so it makes sense as a staple among a variety of adversaries.

#6

Overall rank

34%

Organizations affected

1042

Confirmed threats

Analysis

The number of customers that received a threat detection associated with Masquerading was far higher in 2019 than in 2018, while total threat volume was mostly constant.

 

 

Why do adversaries use Masquerading?

Like many of the techniques on this list, Masquerading is a broad one that encompasses many common and effective adversary behaviors. This includes everything from manipulating binary metadata to subverting expected execution paths to changing process names and much more. In fact, several other ATT&CK techniques—such as Process Injection (T1055), Process Hollowing (T1093), or even Timestomping (T1099)—could be considered forms of Masquerading. It will be interesting to see if MITRE reorganizes these as sub-techniques in the coming months.

Masquerading allows adversaries to manipulate expected names and file paths to circumvent security controls, especially when they are reliant on filenames and process paths to observe, detect, or otherwise prevent threats. For example, it’s trivial to detect an adversary executing a binary named “mimikatz.exe.” As such, when adversaries want to dump credentials with Mimikatz, renaming the tool is essentially a prerequisite for successful credential theft.

While Masquerading is an important technique for deceiving tools and controls, it is also used to prey on analytical bias by renaming malicious files so they seem to be benign. Casual observers of Masquerading processes may quickly dismiss these as normal behaviors on Windows, macOS, or Linux-based systems.

How do adversaries use Masquerading?

Masquerading can manifest on an endpoint in a wide variety of ways. Adversaries commonly:

  • Modify binary metadata by renaming files and adding seemingly legitimate information, such as software descriptions and copyright information
  • Manipulate file locations or paths
  • Rename legitimate processes or move them to different directories
  • Imitating Windows system processes such as “lsass.exe,” “userinit.exe,” and “svchost.exe”
  • Masquerading executables as documents by replacing application icons with document icons or by appending executables with multiple extensions (e.g., “malware.txt.exe”)

Emerging tactics

Lately we’ve started to observe some novel examples of masquerading on Linux systems. Adversaries have deployed kernel thread Masquerading using process names such as “kworkerds,” “kauditd,” and others that make defenders think twice about removing components of malware.

Sighted with

Many of the techniques we commonly spot alongside Masquerading are associated with otherwise prevalent threats that happen to occur in conjunction with Masquerading. The most prominent example of this is TrickBot, which explains why Masquerading occurs in tandem with the following:

  • Process Injection (T1055)
  • Windows Admin Shares (T1077)
  • Remote File Copy (T1105)
  • Domain Trust Discovery (T1482)

Definition

Detection

MITRE’s data sources

  • File monitoring
  • Process monitoring
  • Binary file metadata

Collection requirements

Command-line parameters

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

Detection suggestions

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.

File monitoring

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.

Testing

Getting Started With Atomic Red Team

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: Masquerading. In most environments, these should be sufficient to generate a useful signal for defenders.

Run this test on a Windows system using Command Prompt:
copy %SystemRoot%\System32\cscript.exe %APPDATA%\notepad.exe /Y
cmd.exe /c %APPDATA%\notepad.exe /B
Useful telemetry will include:
Data sourceTelemetry
Data source:

Binary file metadata

Telemetry:

does notepad.exe have the correct signature and internal name?

Data source:

Process monitoring

Telemetry:

cmd.exe renamed to notepad.exe

Data source:

File monitoring

Telemetry:

“%APPDATA%\notepad.exe”

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.

Justin Schoenfeld
Detection engineer
The detection strategies in this section were brought to you by Justin Schoenfeld! Justin is experienced in threat hunting, incident response, and researching industry-wide threat intelligence. He earned his B.A. in Computing Security from the Rochester Institute of Technology, where he had the opportunity to co-op for a large corporation and a startup company. His love for endpoint telemetry came from his experience as an advanced threat engineer for a large global hospitality company.
The detection strategies in this section were brought to you by Justin Schoenfeld! Justin is experienced in threat hunting, incident response, and researching industry-wide threat intelligence. He earned his B.A. in Computing Security from the Rochester Institute of Technology, where he had the opportunity to co-op for a large corporation and a startup company. His love for endpoint telemetry came from his experience as an advanced threat engineer for a large global hospitality company.