Match Legitimate Resource Name or Location is ATT&CK T1036.005. It is a Stealth technique and the platform list is wide: Containers, ESXi, Linux, macOS and Windows. The behavior is simple to state. An attacker names or places a resource so that it matches or approximates something legitimate.
How attackers use it
MITRE gives several forms of the same idea:
- Placing an executable in a commonly trusted directory, for example under System32.
- Giving a file the name of a legitimate, trusted program, for example svchost.exe.
- Giving a Windows Registry key a close approximation of a key used by a legitimate program.
- In containerized environments, creating a resource in a trusted namespace or one that matches the naming convention of a container pod or cluster.
The procedure examples include an executable installed as C:\Temp\TrustedInstaller.exe to mimic the Windows installer service, DLLs and EXEs named after common electric power sector protocols during an attack on a power grid, and firewall rules created to mimic the name of an institution already present in a network device configuration. One actor ran a rename command to give a tool the benign name audiodg.exe.
What these share is that a reviewer who checks names will think the item belongs.
Click through it at your own pace, or open it full screen.
How to detect it
The MITRE detection strategy compares the claimed identity of a resource with its other properties, by platform:
- Windows: processes or binaries run from trusted directories or under trusted names where the metadata, hash or parent process does not match legitimate activity.
- Linux: renamed binaries or scripts placed into trusted paths such as /usr/bin or /lib, with mismatched metadata or unexpected creation and modification times.
- macOS: binaries or launch daemons in /System/Library or /Applications with mismatched bundle names, unexpected metadata or an improper installation origin.
- Containers: malicious containers or pods that use names, labels or namespaces that mimic legitimate workloads. The same analytic also checks for image layer mismatches and unauthorized resource deployments.
- ESXi: VIBs, scripts or binaries placed in directories such as /bin or /etc/vmware with names that mimic standard ESXi components, plus unauthorized creation of services.
Useful data to keep for all of these: file creation events with path and timestamp, process creation with hash and signer, package manager records on Linux so you can ask which package owns a file, and the Kubernetes audit log for object creation in sensitive namespaces.
How to reduce the risk
MITRE lists three mitigations:
- Restrict file and directory permissions. Protect folders such as C:\Windows\System32 with file system access controls, so a file cannot be dropped there by an ordinary account.
- Execution prevention. Use application control that decides by attributes other than file name for the common operating system utilities your environment needs.
- Code signing. Require signed binaries and images. For containers, that means signed images and a policy that only admits images from sources you trust.
For clusters, the natural complement is to limit who can create workloads in system namespaces and to review new workloads whose names resemble existing ones.
Check your own environment
Linux, ask the package manager which package owns a binary in a trusted path. A file owned by no package is worth a look.
dpkg -S /usr/bin/example 2>&1 # Debian and Ubuntu
rpm -qf /usr/bin/example # RHEL family
Linux, find recently modified files under /usr/bin and /usr/sbin:
find /usr/bin /usr/sbin -type f -mtime -7 -ls
Windows PowerShell, check the signature of everything in a folder you expect to hold only signed files:
Get-ChildItem C:\Windows\System32 -Filter *.exe | Get-AuthenticodeSignature | Where-Object { $_.Status -ne 'Valid' }
Kubernetes, list pods across namespaces with their images, and read the list for names that look like system components but run unfamiliar images:
kubectl get pods -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,IMAGE:.spec.containers[*].image
If your containers pull dependencies at build time, it is also worth scanning those. The free in-browser dependency scan at gold.safeguard.sh/scan needs no login, the file never leaves your machine, and it covers up to 100 dependencies.
Quick check
Why is a file named svchost.exe in the wrong folder suspicious even if its name is right?
The name matches a trusted program, but the location, signer, hash or parent process may not. Detection compares those properties with what the legitimate program would show.
What does masquerading look like in a Kubernetes cluster?
Per MITRE, an attacker may create a resource in a trusted namespace or one that matches the naming convention of a pod or cluster, so that it blends in with legitimate workloads.
