Detecting and Mitigating Masquerading (T1036)

Masquerading is the practice of making something malicious look ordinary. MITRE ATT&CK describes it as manipulating the name or location of an object, legitimate or malicious, so that users and security tools wave it through. It sits under the Stealth tactic and applies to Containers, ESXi, Linux, macOS and Windows.

The idea is old and cheap, which is why it shows up everywhere. It also has twelve sub-techniques, from a trailing space on a filename to a spoofed browser fingerprint. This post covers the parent technique and how the pieces fit together. If you need the detail on one variant, the sub-technique posts go deeper.

How attackers use it

MITRE groups the behavior into a few families. The common thread is that the attacker changes what a defender sees without changing what the thing does.

• Names and metadata. Giving a file, task or service a name that matches something legitimate, or tampering with file metadata such as icons, so a quick glance looks fine.
• File type tricks. Making a file appear to be a different type, for example through a misleading extension, so a person opens it believing it is a document.
• Renaming system utilities. Renaming an abusable built-in tool so that rules keyed on the tool's name no longer fire. MITRE calls this out as a form of masquerading in its own right.
• Location. Placing a file where trusted files normally live, or in an unusual folder with a trusted name.
• Accounts. Creating accounts with generic or service-like names so they blend into a user list.

The MITRE page lists many real procedure examples. A few illustrate the range: one group renamed the Plink tunneling tool to systems.exe, another renamed the WinRAR utility, and a third disguised a Cobalt Strike beacon as a Flash installer. None of these needed anything clever. They relied on the fact that most review is a glance at a name.

How to detect it

The MITRE detection strategy for this technique is about discrepancy. You are looking for a thing whose claimed identity does not match its behavior or its properties.

Per platform, the analytics on the page describe:

• Windows: renamed living-off-the-land binaries or binaries with spoofed file names, internal PE metadata or misleading icons, followed by execution or service registration that does not fit known usage.
• Linux: renamed binaries dropped in uncommon directories such as /tmp and /dev/shm, special characters in names such as a trailing space or a Unicode right-to-left override, and execution or a cron job soon after the drop.
• macOS: launch daemons or apps with misleading names and bundle metadata, where the Info.plist values do not agree with the binary path or icon.
• Containers: renamed images, or files with misleading names or metadata injected into a container and executed at startup or by scheduled jobs.
• ESXi: scripts or binaries with misleading names in locations such as /etc/rc.local.d or /var/spool/cron, and services with legitimate-sounding names that are not in a default ESXi build.

In practice that means collecting process creation events with the full image path, the original file name from the PE header, the signer and the hash, then alerting when the on-disk name disagrees with the embedded name or when a known system name runs from the wrong folder. Add file creation events for the same paths and you can see the drop that came before the run.

How to reduce the risk

MITRE lists these mitigations for the parent technique:

1. Audit accounts. Make sure every account has a defined purpose. An account nobody can explain is a finding.
2. Enforce an account naming convention. If your accounts follow a pattern, generic names that do not fit the pattern stand out.
3. Train users. Do not open unexpected attachments or click unknown links. Many masquerading cases depend on a person double clicking something.
4. Require signed binaries. Code signing gives you a property that a rename cannot fake.
5. Use endpoint behavior prevention. A host intrusion prevention system can block execution of files whose content does not match their claimed type, such as mismatched file signatures.

The pattern behind all five is the same: stop trusting names and start trusting properties you can verify, such as the signer, the path, the hash and the account's documented owner.

Check your own environment

A few read-only starting points. Adjust paths to your estate.

Windows (PowerShell), list running processes with their paths and compare them with what you expect:

Get-CimInstance Win32_Process | Select-Object ProcessId, Name, ExecutablePath | Sort-Object Name

Windows (PowerShell), check a suspicious binary's signature:

Get-AuthenticodeSignature "C:\path\to\file.exe" | Format-List Status, SignerCertificate

Linux, list files with execute permission in two folders attackers commonly use:

find /tmp /dev/shm -type f -perm /111 -ls 2>/dev/null

macOS, verify a binary's code signature:

codesign --verify --deep --strict --verbose=2 /path/to/App.app

Also review your account list against your naming convention, and ask who owns each account that does not match.

Quick check

Sources

• MITRE ATT&CK T1036: Masquerading