Overview

Match Legitimate Resource Name or Location (T1036.005) is a masquerading technique where adversaries rename malicious executables, scripts, or other resources to mimic trusted system files, or place them in directories where legitimate tools are expected to live. The goal is simple: make malicious activity look routine so that defenders, monitoring tools, and even end users ignore it.

This technique is pervasive across nearly every intrusion type — from commodity malware to nation-state APTs — because it costs attackers almost nothing and dramatically raises the bar for detection. Every security team needs coverage here because a missed masquerading binary can persist undetected for months, blending silently into normal operations while the attacker exfiltrates data, moves laterally, or establishes long-term access.

Attacker Perspective

Attackers use this technique to reduce friction at every stage of the kill chain — from initial access through persistence — by hiding malicious files in plain sight among trusted system resources.

• Fake system binaries on Windows: Dropping a Cobalt Strike beacon named svchost.exe or lsass.exe into C:\ProgramData\Microsoft\ or C:\Users\Public\ rather than the legitimate C:\Windows\System32\, exploiting the fact that many defenders filter on file name alone rather than path and signature together.
• Greenbug-style masquerade: Nation-state actors (e.g., Greenbug/APT34) staging tools as C:\ProgramData\adobe\Adobe.exe or C:\ProgramData\oracle\local.exe — paths that look plausible at a glance but sit outside any legitimate vendor installation directory.
• Malicious .node file injection (DripLoader): Loading unsigned native Node add-ons (.node files) into trusted Electron applications like Slack or Discord, hijacking the trusted process context to execute arbitrary native code while evading application allowlisting.
• Kubernetes namespace spoofing: Creating a malicious pod or service account in the kube-system namespace or naming a rogue container coredns or metrics-server to blend with legitimate cluster infrastructure and avoid scrutiny during routine kubectl get pods checks.

This technique is attractive precisely because it exploits human and tool bias toward trusting familiar names — a single renamed binary can defeat signature-based AV, bypass application allowlisting rules anchored to file name, and survive casual analyst triage for months.

Detection Strategy

Required Telemetry

• Windows Process Creation (Event ID 4688): Enable via GPO — Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation. Also enable command-line logging: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1. This generates Event ID 4688 with full CommandLine and ParentProcessName fields. Alternatively, deploy Sysmon (Event ID 1) which provides richer fields including Hashes, OriginalFileName, and ParentImage — critical for this technique.
• Windows Image Load Events (Sysmon Event ID 7): Required to detect unsigned .node files or DLLs loaded into trusted processes. Enable via Sysmon config by including ImageLoad event logging. Key fields: ImageLoaded, Signed, SignatureStatus, Image.
• Windows File System Events (Sysmon Event ID 11 — FileCreate): Captures file writes including path and creating process. Essential for detecting executables dropped in suspicious locations like C:\ProgramData\, C:\Users\Public\, or fake system directories.
• Windows Security Event ID 4663 (File Object Access): Enable via Advanced Audit Policy → Object Access → Audit File System. Useful for detecting access to sensitive paths. Must configure SACLs on monitored directories.
• Windows PE Metadata (Sysmon Event ID 1 — OriginalFileName field): This single field is one of the most powerful signals for this technique. Sysmon extracts the OriginalFileName from the PE header, which adversaries often forget to spoof. A binary named svchost.exe on disk with an OriginalFileName of nc.exe or beacon.exe is an immediate red flag.
• Web Proxy / DNS Logs: Required for detecting fake Flash updates or lookalike domains delivering masqueraded payloads. Fields needed: cs-host, c-uri, cs-referer, c-ip. Enable full URL logging on your proxy; DNS logs should capture query name and response IP.
• Linux — Auditd Process Execution: Add the following audit rule to capture all executions: -a always,exit -F arch=b64 -S execve -k exec_monitor. Key fields: exe, comm, ppid, uid. Ship via auditbeat or syslog to your SIEM.
• Linux — File Integrity Monitoring: Use auditd watch rules on sensitive directories: -w /usr/bin/ -p wa -k bin_watch and -w /tmp/ -p wxa -k tmp_exec. Alternatively, deploy a FIM solution (OSSEC, Wazuh, or Auditbeat) monitoring /bin, /usr/bin, /sbin, /usr/sbin.
• Kubernetes Audit Logs: Enable API server audit logging with a policy that captures create and patch verbs on pods, serviceaccounts, and clusterrolebindings. Key fields: requestObject.metadata.namespace, requestObject.metadata.name, user.username, verb.
• EDR Telemetry (CrowdStrike, Microsoft Defender for Endpoint, SentinelOne): Most modern EDR platforms capture process metadata including code signing status, parent-child relationships, and hash — supplement SIEM-based detection with EDR hunt queries, especially for the OriginalFileName mismatch signal.

Key Indicators

• OriginalFileName mismatch (Sysmon Event ID 1): Field OriginalFileName does not match Image filename. Example: Image = C:\Windows\System32\svchost.exe but OriginalFileName = mimikatz.exe. This is the highest-fidelity signal for this technique.
• Trusted binary name in untrusted path (Sysmon Event ID 1 or Windows Event 4688): Image contains a known system binary name (e.g., svchost.exe, lsass.exe, explorer.exe) but CurrentDirectory or the full Image path is NOT in C:\Windows\System32\, C:\Windows\SysWOW64\, or another known-good path.
• Known masquerade paths (Sysmon Event ID 1): Image path contains any of: C:\ProgramData\adobe\, C:\ProgramData\oracle\, C:\ProgramData\comms\, C:\Users\Public\, C:\Temp\. Combined with an executable that shares a name with a Microsoft or vendor binary.
• Unsigned .node file loaded into Electron app (Sysmon Event ID 7): ImageLoaded ends with .node AND (Signed = false OR SignatureStatus = Unavailable) AND Image contains a trusted Electron app path (e.g., slack.exe, discord.exe, teams.exe).
• Suspicious Flash installer download from non-Adobe host (Proxy logs): c-uri ends with /install_flash_player.exe OR contains /flash_install.php AND cs-host does NOT end with .adobe.com.
• Greenbug masquerade command lines (Windows Event 4688 / Sysmon Event ID 1): CommandLine contains -ExecutionPolicy Bypass -File AND \msf.ps1; OR CommandLine contains infopagesbackup AND \ncat AND -e cmd.exe.
• Executable in temp or data directory with system binary name (File Creation — Sysmon Event ID 11): TargetFilename ends with svchost.exe, lsass.exe, explorer.exe, csrss.exe, winlogon.exe AND path does NOT begin with C:\Windows\.
• Kubernetes pod created in kube-system with unexpected name (K8s Audit Logs): verb = create AND resource = pods AND requestObject.metadata.namespace = kube-system AND user.username is NOT a known cluster admin or service account.
• Process without valid code signature running from system path (Sysmon Event ID 1 + 7): Image path is under C:\Windows\System32\ AND Signed = false — legitimate Microsoft binaries in System32 are always signed.

Detection Logic

Rule 1 — Broad: Executable with System Binary Name Running from Non-Standard Path
IF process_name IN ['svchost.exe','lsass.exe','explorer.exe','csrss.exe','winlogon.exe','services.exe','smss.exe','taskhost.exe','rundll32.exe'] AND process_path NOT IN ['C:\Windows\System32\','C:\Windows\SysWOW64\','C:\Windows\'] THEN alert HIGH

This catches any masqueraded binary that reuses a critical Windows process name but runs from an unexpected location. Expect moderate alert volume — tune aggressively using the paths listed in Tuning Guidance below. This should be one of your baseline rules on every Windows endpoint.

Rule 2 — Medium: OriginalFileName Mismatch in PE Header
IF event_id = 1 (Sysmon Process Create) AND OriginalFileName != NULL AND OriginalFileName != filename(Image) AND Image NOT IN [known_legitimate_renamed_binaries_allowlist] THEN alert HIGH

Requires Sysmon. This is your highest-precision rule because attackers frequently forget to modify the PE OriginalFileName field. False positive volume is low — most legitimate software does not rename binaries in ways that mismatch their PE metadata. Build an allowlist of known exceptions (e.g., some vendor tools rename their binaries during updates).

Rule 3 — Targeted: Unsigned .node File Loaded into Electron Application
IF event_id = 7 (Sysmon Image Load) AND ImageLoaded ENDSWITH '.node' AND (Signed = 'false' OR SignatureStatus = 'Unavailable') AND Image ENDSWITH IN ['slack.exe','discord.exe','teams.exe','code.exe','atom.exe'] AND NOT (Image ENDSWITH 'Code.exe' AND ImageLoaded CONTAINS '.vscode\extensions\ms-toolsai.jupyter-') THEN alert MEDIUM

Targets DripLoader-style abuse of Electron apps. The false positive rate for truly unsigned .node files in production apps is low, but VSCode extensions are a known benign source — the filter handles the most common exception. Investigate each hit individually before adding further allowlist entries.

Rule 4 — High Precision: Known Masquerade Path Execution (Greenbug / APT Patterns)
IF process_path CONTAINS IN ['C:\ProgramData\adobe\Adobe.exe','C:\ProgramData\oracle\local.exe','C:\ProgramData\comms\comms.exe'] OR (CommandLine CONTAINS 'infopagesbackup' AND CommandLine CONTAINS '\ncat' AND CommandLine CONTAINS '-e cmd.exe') OR (CommandLine CONTAINS '-ExecutionPolicy Bypass -File' AND CommandLine CONTAINS '\msf.ps1') THEN alert CRITICAL

This is IOC-level detection based on confirmed APT tooling paths and command-line patterns. Expected volume is near-zero in a clean environment — any hit should be treated as a confirmed incident until proven otherwise. Update this list as new threat intelligence identifies masquerade paths used by tracked threat groups.

Tuning Guidance

• Legitimate vendor software with confusing install paths: Some third-party tools (e.g., Oracle DB client, Adobe Creative Cloud components) do legitimately install in C:\ProgramData\ subdirectories. Before alerting, enumerate your environment’s actual vendor install paths using an asset inventory or software management tool, and add specific path+hash combinations to an exclusion list rather than excluding entire directories.
• Software update mechanisms renaming binaries: Automated updaters (e.g., Google Chrome, Firefox, Zoom) sometimes create new binaries with temporary names then rename them. Exclude known updater parent processes: parent_process IN ['GoogleUpdate.exe','MozillaUpdate.exe','ZoomUpdater.exe'] when the child process path is within the expected install directory.
• Security and IT tooling: SCCM, Tanium, CrowdStrike, and other security agents may run from paths like C:\ProgramData\ with names that could superficially match the rule. Add exclusions anchored to both path AND signing certificate (not just path): path CONTAINS 'CrowdStrike' AND Signed = true AND SignerName = 'CrowdStrike, Inc.'
• Development environments for Rule 3 (.node files): Developers running local builds of Electron apps or Node.js projects will generate unsigned .node files frequently. Suppress by user or workstation OU — exclude machines in a known developer workstation group or suppress alerts where user IN [dev_team_accounts] and process_path CONTAINS '\node_modules\'.
• Sysinternals and legitimate admin tools: Tools like PsExec, Process Explorer, and TCPView are often not code-signed in the traditional sense and may trigger OriginalFileName mismatch rules. Build a hash-based allowlist from your IT team’s approved toolset and exclude those specific hashes rather than the tool names.
• Kubernetes false positives: In active cluster environments, legitimate CI/CD pipelines may create pods in kube-system during upgrades. Exclude known service account names tied to your cluster management tooling (e.g., user.username IN ['helm','flux','argocd-server']) and alert only on unexpected usernames.

When the Alert Fires: Investigation Steps

1. Verify the alert is real. Pull the raw event from your SIEM or EDR and confirm the process execution or file creation actually occurred — check that the event timestamp, host, and user match the alert context. For Sysmon-based alerts, retrieve Event ID 1 or 7 directly from the endpoint’s event log to rule out SIEM parsing errors.
2. Identify the affected host and user account. Determine whether the account is a standard user, local admin, domain admin, or service account — note this in your case. Flag immediately if the account has elevated privileges or if the host is a server, domain controller, or jump box, as this significantly raises severity.
3. Pull the full process execution chain. Using Sysmon Event ID 1 or your EDR’s process tree, trace the parent-grandparent-child chain for the suspicious process. Ask: does the parent make sense? A fake svchost.exe spawned by cmd.exe or powershell.exe instead of services.exe is a strong confirmation of malicious activity.
4. Check the binary’s PE metadata and signature. If Sysmon is available, compare Image (file name on disk) against OriginalFileName from Event ID 1. Submit the file hash to VirusTotal and your EDR’s threat intelligence feed. Verify the code signing status — a binary claiming to be svchost.exe that is unsigned or signed by an unknown certificate is confirmed malicious.
5. Enumerate network connections and files written to disk. Use Sysmon Event ID 3 (Network Connection) and Event ID 11 (FileCreate) filtered to the malicious process’s PID and timeframe. Look for outbound connections on non-standard ports, connections to newly registered domains, and any additional executables, scripts, or configuration files dropped by the process.
6. Search for persistence mechanisms added by this process. Query for scheduled tasks (Sysmon Event ID 1 with schtasks.exe in the command line), registry run key modifications (Sysmon Event ID 13), new services (Windows Event ID 7045), and WMI subscriptions (Sysmon Event ID 19/20/21) created within 30 minutes before and after the masquerade binary execution timestamp.
7. Assess lateral movement and make the escalation decision. Search for authentication events (Windows Event ID 4624/4648) and remote execution evidence (Event ID 4688 with network logon type) originating from the affected host in the same timeframe. If you find the binary is signed and from a known vendor path with a plausible parent, downgrade to low and document; if you find a PE mismatch, unsigned binary, or C2 connection, escalate to incident immediately and move to containment.

Response Playbook

Containment

• Network isolate the affected host immediately — keep it powered on. Use your EDR console (CrowdStrike Network Containment, MDE Isolate Device, SentinelOne Network Quarantine) to cut network access while preserving volatile memory and process state for forensics. Do not power off — you will lose in-memory indicators and active connections.
• Disable the affected user account. In Active Directory, use Disable-ADAccount -Identity [username] or the ADUC console. If the account is an Azure AD or hybrid account, also disable in the Azure portal and revoke all active refresh tokens using Revoke-AzureADUserAllRefreshToken.
• Block identified C2 IPs, domains, and URLs. Push blocking rules to your perimeter firewall, web proxy, and DNS resolver immediately. If the proxy logs show a specific C2 domain, add it to your DNS sinkhole as well. For Kubernetes incidents, apply a NetworkPolicy to isolate the rogue pod: kubectl apply -f deny-all-policy.yaml targeting the pod’s labels.
• Kill the malicious process. Use your EDR’s remote process kill capability, or for a hands-on approach use taskkill /F /PID [pid] on Windows. Document the PID, hash, and command line before killing. For Kubernetes, delete the rogue pod: kubectl delete pod [pod-name] -n [namespace].
• Revoke active sessions and service account tokens. If the masquerade binary ran under a service account, rotate that account’s password and invalidate Kerberos tickets with a double password reset. For cloud environments, rotate any IAM access keys or OAuth tokens associated with the compromised identity.

Eradication

• Delete the masquerade binary and any dropped files. Locate and remove the malicious executable and any scripts, configuration files, or secondary payloads identified during investigation. Use the file paths captured from Sysmon Event ID 11 as your file manifest. Quarantine to your EDR or malware vault before deleting for evidence preservation.
• Remove all identified persistence mechanisms. Delete rogue scheduled tasks (schtasks /delete /tn [taskname] /f), remove malicious registry run keys (reg delete HKLM\...\Run /v [valuename] /f), disable and delete any rogue services (sc stop [service] && sc delete [service]), and remove WMI subscriptions if found. Verify each removal with a follow-up query.
• Search lateral movement targets for the same IOCs. Run a threat hunt across all hosts that received network connections from the compromised machine during the incident window. Search for the same file hashes, binary names, and masquerade paths on those endpoints using your EDR’s search capability or SIEM correlation.
• Reset credentials for all accounts touched by the malicious process. This includes the directly compromised account and any accounts whose credentials may have been cached on the host (check for lsass.exe memory access via Sysmon Event ID 10). Force password resets and MFA re-registration for all affected accounts.
• Rotate secrets and API keys exposed on the host. Identify any plaintext credentials, certificates, or API keys stored on the compromised host (check %APPDATA%, %USERPROFILE%\.ssh, credential manager, and browser stored passwords). Rotate every secret that could have been read by the malicious process.

Recovery

• Re-image the host if confidence in full eradication is low. If the attacker had persistent access for more than a few hours, or if you found evidence of rootkit-level activity, do not attempt cleanup — re-image from a known-good baseline and restore data from a pre-compromise backup. Only reconnect the host to the network after re-imaging and verifying a clean EDR baseline scan.
• Re-enable the user account only after confirming no persistence remains. Run a final check for scheduled tasks, registry run keys, new local accounts, and WMI subscriptions before restoring access. Brief the user on what happened and require a password reset and MFA re-enrollment at first login.
• Monitor the previously affected host and user for 72 hours post-remediation. Create a temporary high-sensitivity watchlist rule in your SIEM for the host’s IP/hostname and the user’s UPN. Alert on any process execution from C:\ProgramData\, C:\Temp\, or C:\Users\Public\ during this window, and review all authentication events for the account daily.
• Update detection rules with newly discovered IOCs. Add any new masquerade paths, binary names, hashes, and C2 domains discovered during the investigation to your detection rules and threat intelligence platform. Share indicators with your ISAC or threat intelligence community if appropriate.
• Conduct a post-incident review and close the ticket with a documented timeline. Document the full attack timeline from initial execution to containment, including how the binary gained initial access, how long it was present, and what data or systems it touched. Use this to identify detection gaps and prioritize any telemetry that was missing (e.g., Sysmon not deployed on the affected host).