Detecting masquerading (T1036)

What is masquerading (T1036)?

Masquerading (T1036) is a MITRE ATT&CK® defense evasion technique where adversaries disguise the nature, origin, or purpose of malicious files and processes so they blend in with expected system activity. The goal is simple: make a malicious binary look like a Windows system process, or make a persistence mechanism look like a scheduled maintenance task. When a security team scans for threats by name or signature, masqueraded items slip past unchallenged.

Masquerading is not a single action, it is a category of deception that includes renaming executable files, placing them in trusted directories, abusing signed Windows utilities to proxy execution, and mimicking system process behavior. Log360 maps 30+ pre-built correlation rules to T1036, targeting the behavioral signatures that remain consistent regardless of which binary name an attacker chooses to copy.

How attackers use masquerading

Masquerading works because security monitoring often relies on process name and path trust. If a process is named svchost.exe and resides in System32, basic monitoring tools assume it is legitimate. Attackers exploit this assumption through several consistent techniques:

1. Binary renaming: The attacker copies a malicious executable and renames it to match a legitimate Windows process (svchost.exe, explorer.exe, lsass.exe). When placed in a writable user directory and executed, signature-based tools may not flag the renamed file if the actual binary hash is clean or the AV signature does not match the executable content.
2. Wrong-path execution: Legitimate Windows binaries always run from specific system directories. Svchost.exe runs from System32, not from AppData or a network share. An attacker who places a malicious binary named svchost.exe in C:\Users\Public or a temp folder betrays the masquerade through its execution path alone, if the detection rule checks path as well as name.
3. Parent process spoofing: Windows allows processes to create child processes that report a different parent than the true creator. Attackers use this to make malicious code appear to be spawned by trusted system processes like explorer.exe or services.exe, defeating investigation tools that rely on parent-child relationships.
4. LOLBAS (Living-Off-the-Land Binary) abuse: Rather than renaming malware to look like a legitimate tool, the attacker uses the legitimate tool itself to do the malicious work. Windows utilities like wsmprovhost.exe, mshta.exe, and certutil.exe can download, decode, and execute payloads without any detected malware binary. The binary is real and signed, only its behavior is malicious.

Sub-techniques and variants

MITRE ATT&CK documents several sub-techniques under T1036, each requiring slightly different detection logic:

• T1036.001 — Invalid code signature: Signing malicious code with an expired, revoked, or self-signed certificate to pass shallow signature checks.
• T1036.003 — Rename system utilities: Copying and renaming legitimate binaries (or renaming malware to look like them) to bypass name-based controls.
• T1036.004 — Masquerade task or service: Creating scheduled tasks or Windows services with names that match legitimate system components to hide persistence.
• T1036.005 — Match legitimate name or location: Placing malicious files in directories that match where legitimate binaries live, or using filenames that match expected system files.
• T1036.006 — Space after filename: Adding trailing spaces or special characters to a filename to make it appear as a different extension in GUI-based file views.

Detection indicators for T1036

Masquerading detection is most reliable when it combines path analysis, behavioral baseline comparison, and parent-child chain inspection. Relying on binary name alone fails immediately when the attacker copies the correct name to a wrong path. Effective indicator categories:

Path anomalies

Every core Windows binary has a canonical execution path. Detection rules that cross-reference the process image name against its expected path can surface masquerading instantly. Svchost.exe running from anything other than C:\Windows\System32\ or C:\Windows\SysWOW64\ is anomalous, regardless of any other characteristic. Log360's Suspicious Process Start Locations rule targets this pattern across a comprehensive list of system-critical binaries.

Process parent-child anomalies

Legitimate system processes have consistent parent relationships. Explorer.exe is typically a child of userinit.exe. Svchost.exe is always a child of services.exe. When Log360's Windows Masquerading Explorer As Child Process rule fires, it means a process named explorer.exe was spawned by something other than its expected parent — a reliable signal of masquerade or parent process spoofing.

LOLBAS execution context

LOLBins are flagged not by their name but by context: what arguments were passed, what they spawned, and what they accessed. Wsmprovhost.exe spawning a command interpreter, or mshta.exe loading content from a remote URL, are behavioral signals Log360's LOLBAS rules detect regardless of whether any file rename occurred.

Log360 detection rules for T1036

Log360 ships with 30+ pre-built correlation rules directly mapped to Masquerading (T1036). The rules span binary rename detection, LOLBAS abuse detection, and suspicious execution location monitoring, providing coverage even when no known malware signature is involved:

Investigation steps

When Log360 fires a Masquerading (T1036) alert, follow this sequence to confirm the masquerade, identify the attacker's objective, and scope any damage:

1. Confirm the path anomaly: Verify the full image path of the flagged process. A process named svchost.exe running from C:\Windows\System32\ is legitimate; the same name running from C:\Users\Public\ is not. Extract the binary and check its hash against known-good values using Log360's integrated threat intelligence.
2. Trace the parent-child chain: Use Log360's process lineage view to trace the full ancestry of the suspicious process. Identify where in the chain the anomaly originated — whether a web application, a document, or a remote PowerShell session spawned the masqueraded binary.
3. Check for lateral movement: Masquerading is often a tool to enable sustained access. Check whether the flagged process initiated any outbound network connections, accessed non-local file shares, or spawned additional processes that moved laterally to other hosts.
4. Review the timeline: Look at what other events occurred on this host in the 30 minutes before and after the alert. Correlate masquerading activity with credential access events (Event ID 4624, 4648), privilege escalation indicators, or security tool disabling events that may indicate the broader attack sequence.
5. Check task and service persistence: If the masqueraded binary was loaded as a service (Event ID 7045) or scheduled task (Event ID 4698), the attacker may have established persistence. Enumerate all recently created services and scheduled tasks on the affected host.

Response playbook

• Isolate the affected host: If active masquerading activity is confirmed, remove the host from the network via EDR quarantine or VLAN isolation. A masqueraded process with an active session can be used for lateral movement until the session is terminated.
• Terminate the masqueraded process: Kill the suspicious process and remove the binary from disk. Hash the file first for forensic evidence before deletion. If the process is running as SYSTEM, prioritize host isolation before process termination to prevent anti-forensic cleanup scripts from triggering on termination.
• Remove persistence mechanisms: If the masquerade was backed by a scheduled task or service, remove both the task/service definition and the binary it referenced. Check the registry for run keys that reference the same path.
• Audit execution locations: After responding to the immediate threat, run a host scan to enumerate all processes running from non-standard paths. Masquerading attacks sometimes involve multiple renamed binaries placed at once for redundancy.
• Review and harden application allowlisting: If the environment uses AppLocker or Windows Defender Application Control, tighten rules to enforce that specific system binaries can only execute from their canonical paths. This prevents future masquerading attempts from the same execution locations.
• Apply detection tuning: After the incident, review any T1036 rule false positives generated during normal operations. Legitimate software installers sometimes exhibit masquerade-like behavior. Document these exclusions with justification to prevent them from becoming blind spots.

Frequently asked questions