Home/ATT&CK Technique/Match Legitimate Resource Name or Location
ATT&CK Technique

Match Legitimate Resource Name or Location

T1036.005 · stealth

Adversaries may match or approximate the name or location of legitimate files, Registry keys, or other resources when naming/placing them. This is done for the sake of evading defenses and observation. This may be done by placing an executable in a commonly trusted directory (ex: under System32) or giving it the name of a legitimate, trusted program (ex: svchost.exe).

Alternatively, a Windows Registry key may be given a close approximation to a key used by a legitimate program. In containerized environments, a threat actor may create a resource in a trusted namespace or one that matches the naming convention of a container pod or cluster.

ContainersESXiLinuxmacOSWindows
◆

Actors Using This

14
iranAgrius
russia_speaking_cybercrimeAkira
russia_speaking_cybercrimeALPHV / BlackCat
latin_america_brazilian_organized_cybercrimeAmavaldo
north_koreaAndariel
franceAnimal Farm
chinaAoqin Dragon
chinaAPT10
chinaAPT17
chinaAPT1
russiaAPT28
russiaAPT29
chinaAPT31
iranAPT33
▸

Atomic Tests

3
Executable Atomic Red Team test cases for exercising this technique in a lab. Copy a command, run it on the listed platform, confirm your detections fire.
shmacos, linuxExecute a process from a directory masquerading as the current parent directory
Create and execute a process from a directory masquerading as the current parent directory (`...` instead of normal `..`) 
mkdir $HOME/...
cp $(which sh) $HOME/...
$HOME/.../sh -c "echo #{test_message}"
powershellwindowsMasquerade as a built-in system executable
Launch an executable that attempts to masquerade as a legitimate executable. 
Add-Type -TypeDefinition @'
public class Test {
    public static void Main(string[] args) {
        System.Console.WriteLine("tweet, tweet");
    }
}
'@ -OutputAssembly "#{executable_filepath}"

Start-Process -FilePath "#{executable_filepath}"
powershellelevatedwindowsMasquerading cmd.exe as VEDetector.exe
This test simulates an adversary renaming cmd.exe to VEDetector.exe to masquerade as a legitimate application. The test copies cmd.exe, renames it to VEDetector.exe, adds a registry run key for persistence, and executes the renamed binary. This technique may be used to evade detection by mimicking legitimate software names or locations. **Expected Output:** - A new process named VEDetector.exe appears in the process list, but its behavior matches cmd.exe. - SIEM/EDR systems may detect this as suspicious process activity (e.g., Sysmon Event ID 1 for process creation, or Event ID 13 for registry modifications). - Registry modification in HKLM:\Software\Microsoft\Windows\CurrentVersion\Run may trigger persistence alerts in XDR platforms. **References:** - [MITRE ATT&CK T1036.005](https://attack.mitre.org/techniques/T1036/005/) - [Sysmon Process Creation](https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon) 
# Copy and rename cmd.exe to VEDetector.exe
Copy-Item -Path "#{source_file}" -Destination "#{ved_path}\VEDetector.exe" -Force

# Create registry run key for persistence
New-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Run" -Name "VEDetector" -Value "#{ved_path}\VEDetector.exe" -PropertyType String -Force

# Start the renamed process
Start-Process -FilePath "#{ved_path}\VEDetector.exe"

Start-Sleep -Seconds 5
▣

Mitigations

3
MITRE ATT&CK mitigations - vendor-agnostic guidance for reducing exposure to this technique.
M1022Restrict File and Directory Permissions

Restricting file and directory permissions involves setting access controls at the file system level to limit which users, groups, or processes can read, write, or execute files. By configuring permissions appropriately, organizations can reduce the attack surface for adversaries seeking to access sensitive data, plant malicious code, or tamper with system files.

Enforce Least Privilege Permissions
  • Remove unnecessary write permissions on sensitive files and directories.
  • Use file ownership and groups to control access for specific roles. Example (Windows): Right-click the shared folder.
  • Properties.
  • Security tab.
  • Adjust permissions for NTFS ACLs.
Harden File Shares
  • Disable anonymous access to shared folders.
  • Enforce NTFS permissions for shared folders on Windows. Example: Set permissions to restrict write access to critical files, such as system executables (e.g., /bin or /sbin on Linux). Use tools like chown and chmod to assign file ownership and limit access. On Linux, apply: chmod 750 /etc/sensitive.conf `chown root:admin /etc/sensitive.
conf` File Integrity Monitoring (FIM)
  • Use tools like Tripwire, Wazuh, or OSSEC to monitor changes to critical file permissions.
Audit File System Access
  • Enable auditing to track permission changes or unauthorized access attempts.
  • Use auditd (Linux) or Event Viewer (Windows) to log activities.
Restrict Startup Directories
  • Configure permissions to prevent unauthorized writes to directories like C:\ProgramData\Microsoft\Windows\Start Menu. Example: Restrict write access to critical directories like /etc/, /usr/local/, and Windows directories such as C:\Windows\System32.
  • On Windows, use icacls to modify permissions: icacls "C:\Windows\System32" /inheritance:r /grant:r SYSTEM:(OI)(CI)F.
  • On Linux, monitor permissions using tools like lsattr or auditd.
M1038Execution Prevention

Prevent the execution of unauthorized or malicious code on systems by implementing application control, script blocking, and other execution prevention mechanisms. This ensures that only trusted and authorized code is executed, reducing the risk of malware and unauthorized actions.

Application Control
  • Use Case: Use tools like AppLocker or Windows Defender Application Control (WDAC) to create whitelists of authorized applications and block unauthorized ones. On Linux, use tools like SELinux or AppArmor to define mandatory access control policies for application execution.
  • Implementation: Allow only digitally signed or pre-approved applications to execute on servers and endpoints. (e.g., `New-AppLockerPolicy -PolicyType Enforced -FilePath "C:\Policies\AppLocker.
xml"`) Script Blocking
  • Use Case: Use script control mechanisms to block unauthorized execution of scripts, such as PowerShell or JavaScript. Web Browsers: Use browser extensions or settings to block JavaScript execution from untrusted sources.
  • Implementation: Configure PowerShell to enforce Constrained Language Mode for non-administrator users. (e.g.
, Set-ExecutionPolicy AllSigned) Executable Blocking
  • Use Case: Prevent execution of binaries from suspicious locations, such as %TEMP% or %APPDATA% directories.
  • Implementation: Block execution of .exe, .bat, or .ps1 files from user-writable directories.
Dynamic Analysis Prevention
  • Use Case: Use behavior-based execution prevention tools to identify and block malicious activity in real time.
  • Implemenation: Employ EDR solutions that analyze runtime behavior and block suspicious code execution.
M1045Code Signing

Code Signing is a security process that ensures the authenticity and integrity of software by digitally signing executables, scripts, and other code artifacts. It prevents untrusted or malicious code from executing by verifying the digital signatures against trusted sources. Code signing protects against tampering, impersonation, and distribution of unauthorized or malicious software, forming a critical defense against supply chain and software exploitation attacks.

Enforce Signed Code Execution
  • Implementation: Configure operating systems (e.g., Windows with AppLocker or Linux with Secure Boot) to allow only signed code to execute.
  • Use Case: Prevent the execution of malicious PowerShell scripts by requiring all scripts to be signed with a trusted certificate.
Vendor-Signed Driver Enforcement
  • Implementation: Enable kernel-mode code signing to ensure that only drivers signed by trusted vendors can be loaded.
  • Use Case: A malicious driver attempting to modify system memory fails to load because it lacks a valid signature.
Certificate Revocation Management
  • Implementation: Use Online Certificate Status Protocol (OCSP) or Certificate Revocation Lists (CRLs) to block certificates associated with compromised or deprecated code.
  • Use Case: A compromised certificate used to sign a malicious update is revoked, preventing further execution of the software.
Third-Party Software Verification
  • Implementation: Require software from external vendors to be signed with valid certificates before deployment.
  • Use Case: An organization only deploys signed and verified third-party software to prevent supply chain attacks.
Script Integrity in CI/CD Pipelines
  • Implementation: Integrate code signing into CI/CD pipelines to sign and verify code artifacts before production release.
  • Use Case: A software company ensures that all production builds are signed, preventing tampered builds from reaching customers. Key Components of Code Signing.
  • Digital Signature Verification: Verifies the authenticity of code by ensuring it was signed by a trusted entity.
  • Certificate Management: Uses Public Key Infrastructure (PKI) to manage signing certificates and revocation lists.
  • Enforced Policy for Unsigned Code: Prevents the execution of unsigned or untrusted binaries and scripts.
  • Hash Integrity Check: Confirms that code has not been altered since signing by comparing cryptographic hashes.
◈

Detection Coverage

2/6 layers
Coverage across standard detection surfaces. Rows marked none have no rule of that type mapped. Some are real blind spots worth closing; others are simply not applicable to this technique (e.g. YARA matches malware files, not network behaviour).
Behavioral / log (Sigma) 14
Analytics (MITRE CAR) 1
Runtime / container (Falco) none
File / malware (YARA) none
Network (Suricata/Snort) none
Vuln scan (Nuclei) none
◈

CAR Analytics

1
MITRE Cyber Analytics Repository - field-tested detection logic for this technique, written as pseudocode/queries you adapt to your own SIEM (Splunk, Sentinel, EQL). Each is a ready starting point for a detection rule, not just a description.
CAR-2021-04-001Moderate coverageCommon Windows Process Masquerading

Masquerading (T1036) is defined by ATT&CK as follows: "Masquerading occurs when the name or location of an object, legitimate or malicious, is manipulated or abused for the sake of evading defenses and observation. This may include manipulating file metadata, tricking users into misidentifying the file type, and giving legitimate task or service names." Malware authors often use this technique to hide malicious executables behind legitimate Windows executable names (e.g. lsass.exe, svchost.exe, etc). There are several sub-techniques, but this analytic focuses on Match Legitimate Name or Location only. Analytic Methodology With process monitoring, hunt for processes matching these criteria: process name is svchost.exe, smss.exe, wininit.exe, taskhost.exe, etc. process path is not C:\Windows\System32\ or C:\Windows\SysWow64\ Examples (true positive): C:\Users\administrator\svchost.exe To make sure the rule doesn't miss cases where the executable would be started from a sub-folder of these locations, the entire path is checked for the process path.

The below example should be considered as suspicious: C:\Windows\System32\srv\svchost.exe.

Pseudocode - Pseudocode - Common Windows Process Masquerading
processes = search Process:*
suspicious_processes = filter processes where (
  (exe=svchost.exe AND (image_path!="C:\\Windows\\System32\\svchost.exe" OR process_path!="C:\\Windows\\SysWow64\\svchost.exe"))
  OR (exe=smss.exe AND image_path!="C:\\Windows\\System32\\smss.exe")
  OR (exe=wininit.exe AND image_path!="C:\\Windows\\System32\\wininit.exe")
  OR (exe=taskhost.exe AND image_path!="C:\\Windows\\System32\\taskhost.exe")
  OR (exe=lasass.exe AND image_path!="C:\\Windows\\System32\\lsass.exe")
  OR (exe=winlogon.exe AND image_path!="C:\\Windows\\System32\\winlogon.exe")
  OR (exe=csrss.exe AND image_path!="C:\\Windows\\System32\\csrss.exe")
  OR (exe=services.exe AND image_path!="C:\\Windows\\System32\\services.exe")
  OR (exe=lsm.exe AND image_path!="C:\\Windows\\System32\\lsm.exe")
  OR (exe=explorer.exe AND image_path!="C:\\Windows\\explorer.exe")
  )
output suspicious_processes
Splunk - Splunk Search - Common Windows Process Masquerading
index=__your_sysmon_index__ source="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" AND (
(process_name=svchost.exe AND NOT (process_path="C:\\Windows\\System32\\svchost.exe" OR process_path="C:\\Windows\\SysWow64\\svchost.exe"))
OR (process_name=smss.exe AND NOT process_path="C:\\Windows\\System32\\smss.exe")
OR (process_name=wininit.exe AND NOT process_path="C:\\Windows\\System32\\wininit.exe")
OR (process_name=taskhost.exe AND NOT process_path="C:\\Windows\\System32\\taskhost.exe")
OR (process_name=lasass.exe AND NOT process_path="C:\\Windows\\System32\\lsass.exe")
OR (process_name=winlogon.exe AND NOT process_path="C:\\Windows\\System32\\winlogon.exe")
OR (process_name=csrss.exe AND NOT process_path="C:\\Windows\\System32\\csrss.exe")
OR (process_name=services.exe AND NOT process_path="C:\\Windows\\System32\\services.exe")
OR (process_name=lsm.exe AND NOT process_path="C:\\Windows\\System32\\lsm.exe")
OR (process_name=explorer.exe AND NOT process_path="C:\\Windows\\explorer.exe")
)
▣

Comply & Defend

NIST 800-53AC-02, AC-03, AC-06, CA-07, CM-02, CM-06, CM-07, IA-09, SI-03, SI-04, SI-07, SI-10
D3FEND12 defensive techniques
Intelligence Graph · click any node to traverse
CVETechnique ActorTool Family
drag to reposition · click any node to traverse · button top-right enlarges
External lookups - second-class, for what we don’t hold ourselves
MITRE ATT&CKAtomic Red Teamcar (MITRE)
Vulnerabilities
CISA KEV catalog
CWE weaknesses
CAPEC attack patterns
Package vulnerabilities
Threat intelligence
Threat actors
Tools & malware
ATT&CK techniques
IOCs
Detection & defense
Sigma rules
YARA rules
Atomic Red Team tests
D3FEND countermeasures
Compliance
NIST 800-53
ISO 27001:2022
SOC 2 TSC
PCI-DSS v4.0
CIS Controls v8.1
About
All capabilities
Live statistics
Data sources
Privacy policy
Terms of service
threatengine.sh  ·  Open-source threat intelligence platform  ·  100+ authoritative sources  ·  Every fact traces to its origin