Why T1036 masquerading is hard to spot in your own estate
Masquerading makes hostile activity look like routine administration, and that is why a SOC lead cannot rely on a process name or a file path to decide whether something is safe. T1036 Masquerading is a technique in which an adversary manipulates the name, location or metadata of a file or process so that it resembles legitimate software. In MITRE ATT&CK Enterprise version 20.0, it sits under the Stealth tactic (TA0005), whose stated purpose is to hide and conceal actions by appearing as normal behavior. The technique spans 12 sub-techniques that cover containers, ESXi, Linux, macOS and other platforms, so the problem is not confined to Windows endpoints. ATT&CK v19 split the former Defense Evasion tactic into Stealth, which keeps the ID TA0005, and Defense Impairment, so the identifier you map to has not changed.
In practice, the difficulty is that your own estate is full of names that look benign: service binaries in unusual but plausible directories, container images with familiar tags, and scheduled jobs created by configuration management. A masqueraded process can pass a casual review of the process list because its name matches an expected tool. Before you tune alerts, confirm which of these sources your environment can actually see. Ask your platform team whether process creation events include the full executable path, the parent process and a hash, and whether container runtime and ESXi host logs reach the same store as endpoint telemetry. Without those fields, a name match is the only evidence an analyst has.
The decision to make now is which baseline defines normal for each platform. Write down the expected executable locations, owners and signing details for critical services on Linux, macOS, ESXi hosts and container images, and treat any deviation as a finding to investigate rather than an automatic alert. Confirm with your vendors and internal change records which binaries should ever change in place. This baseline is the reference that your detection logic, and your cyber range rehearsals, will be measured against.
Which telemetry reveals masquerading and which open-source tool collects it
This table maps each telemetry source used for T1036 Masquerading to the signal it carries and the open-source collector that gathers it. Read each row as a question: what does this data show when a binary, path or file name is disguised, and which tool gives you that field. Confirm data component IDs against the ATT&CK version your detections target before building rules.
| Telemetry | Signal for masquerading | Open-source collector | Fields to normalize |
|---|---|---|---|
| Process Creation (DC0032) | Image path that does not match the expected location of a system utility, or a parent-child pair that looks unusual for that binary name | Wazuh, Velociraptor, Security Onion | Image path, original file name, parent image, command line, user, hash |
| Command Execution (DC0064) | Command line that uses a trusted system binary name while the arguments or context suggest a different purpose | Wazuh, Velociraptor, Security Onion | Command line, process name, working directory, host, timestamp |
| File Creation (DC0039) | Executable or script written to a user-writable or temporary directory under a name resembling a system component | Wazuh (file integrity and syscheck), Velociraptor | File path, file name, creating process, hash, creation time |
| File Modification | Changes to the name, path or metadata of an existing binary that conceal its true origin | Wazuh (file integrity monitoring), Velociraptor | Path, previous and new name, modifying process, hash history |
| Network Connection Creation (DC0082) | Process with a system-utility name making outbound connections it does not normally make, used to correlate with a disguised binary | Zeek, Security Onion, Suricata | Source process, destination, port, protocol, host, timestamp |
| Process Access (DC0035) | Access to or from a process whose name suggests a benign service, useful for pivoting from a masqueraded process | Velociraptor, Wazuh (where supported) | Source and target process, access rights, host, timestamp |
Detection logic for masquerading that a SOC can tune
Masquerading works because a renamed or relocated binary looks ordinary at a glance, so detection depends on comparing what a process claims to be with where it runs and who started it. The cards below describe logic in words that a SOC can express in Sigma or in its SIEM, along with the thresholds to tune and the benign activity that will trigger alerts first.
Process name and parent mismatch
Flag processes whose image name matches a well-known system binary but whose parent process, signer or original file name does not match what that binary normally has. A name that matches but a parent that does not is the core signal. Start by baselining parent-child pairs per host group over a few weeks, then alert only on pairs never seen in that baseline. Expect package managers, configuration management agents and backup agents to spawn shells and utilities under unusual parents, so exclude them by signed path and service account rather than by name alone.
Binaries running from unexpected directories
Alert when a process carrying a system binary name runs from a path outside the directories where the operating system or vendor installs it, such as a user profile, temporary folder or an application data directory. The threshold is usually zero for system binary names on servers, with a short allowlist for documented vendor paths. Container build steps, developer tooling and self-updating applications create legitimate hits, so review the first week of alerts per host class before enabling response actions.
System names in user-writable paths
Focus on files written to user-writable locations and then executed under names that imitate operating system components, which is the typical pattern for dropped payloads. Combine a File Creation event with a later Process Creation event for the same file hash or path within a short window that you set after testing. Software installers, browser downloads and IDE plugins create similar sequences, so use code signing status and publisher allowlists to separate them from unsigned or newly seen binaries.
Container images started outside baseline
On container hosts, compare the image digests and entrypoint processes of running containers against the approved image inventory for each workload. Alert when a container starts a process name that is not in its image manifest, or when an image is pulled and launched from a registry outside the approved list. Scheduled jobs, sidecar injections and debugging sessions are the common false positive sources, so record maintenance windows and label approved debug workflows in the inventory.
ESXi host processes outside baseline
On ESXi hosts, treat any process or service that is not part of the vendor base image or an approved agent list as a masquerading candidate, especially one using a name close to a native management service. Baseline the process list after patching and after each approved agent deployment. Backup appliances, monitoring agents and configuration management tools will change this list, so tie baseline updates to change tickets so that each new process has an owner and a reason.
Sigma rule format for tuning
Write each detection as a Sigma rule with explicit fields for image path, original file name, parent image and command line, then keep the exclusions in a separate, reviewed filter section. Version the rules against the ATT&CK release you target, and record which data components each rule uses, such as Process Creation and File Creation, so that a change in ATT&CK mappings does not silently break coverage. Test every rule against logs from your own environment before promotion, because detection quality depends on your fleet, not on the rule text.
How to build masquerading detections from ATT&CK analytics
Start with the ATT&CK v20.0 technique page for T1036 Masquerading and its sub-techniques, then read the detection strategy and analytics for each platform your estate runs, such as Linux, macOS, containers and ESXi. Do not copy the analytic logic into a rule unchanged. Map each analytic to the telemetry you actually collect, usually Process Creation (DC0032) and File Creation (DC0039) for this technique, and record which analytic fields your Wazuh decoders or Sigma pipeline can populate. Where a platform's analytic depends on telemetry you do not collect, treat that gap as a finding and decide whether to add a collector or accept a documented blind spot. Store each rule with the ATT&CK version it targets, for example v20.0, so that a later rename or deprecation is traceable to a specific change.
Masquerading rules depend on a baseline of known-good process paths per host group. Build that baseline separately for workstations, application servers, build hosts and management nodes, because a binary that is legitimate in one group can be anomalous in another. Collect the executable path, parent process and signing or hash data over a representative period, then review the list with the system owners before you turn it into an allowlist. Keep exceptions narrow and time-limited, and review them when packages are upgraded. Expect the baseline to behave differently in containers and on ESXi: container images often run from unusual paths by design, and ESXi hosts have a small, vendor-defined process set. Ask your platform team to confirm which paths are expected in each image and host build before you alert on them.
Test each rule against the sub-technique variants that your ATT&CK version lists, using a private cyber range and benign test binaries so that results are reproducible. Record the expected alert, the false positive rate observed on production-like data, and the owner who signs off on each exception. When MITRE publishes a new ATT&CK version, compare the new analytics with your rule set, retire rules that no longer match a current technique ID, and re-run the test set. Confirm with your SIEM or detection team how often the upstream ATT&CK updates page is reviewed and who owns the change.
How to validate that masquerading detections fire
This sequence proves that masquerading detections for T1036 fire as designed on each in-scope platform, and it records how quickly they fire, which fields they carry and where they produce false positives. The output is a validation record that the detection owner can re-run after tuning or after an ATT&CK version change.
Define the sub-techniques in scope
The detection owner and the platform leads list which T1036 sub-techniques apply to the estate, grouped by platform such as Containers, ESXi, Linux, macOS and Windows. They record the ATT&CK version the mapping targets, because technique and sub-technique content can change between releases. The step is done when each in-scope sub-technique has a named owner, a platform and a target ATT&CK version in a single scope document.
Write an approved test plan
The security engineering lead drafts a written test plan that describes the emulated behavior in words, the lab or cyber range where it runs, the hosts and accounts involved, the expected detection and the rollback steps. Change or risk owners approve the plan before any activity starts. The step is done when the approved plan is stored with the scope document and every emulation has a documented owner and stop condition.
Stage isolated test hosts
The platform team builds test hosts that mirror production logging configuration, including the same agents, log forwarding and Sigma or Wazuh rule versions. Hosts stay inside a private range with no route to production. The check is that a benign marker event sent from each host arrives in the SIEM with the expected source, host name and timestamp, which confirms the telemetry path before any emulation runs.
Confirm expected alerts per platform
For each sub-technique and platform, the detection engineer records the expected alert, the data components it depends on, such as Process Creation, Command Execution or File Modification, and the severity it should carry. The reviewer compares these expectations against the rule text so that the expectation is written before the test is run. The step closes when every in-scope pair has a written expected outcome.
Run the emulation and measure results
The red or purple team runs the approved emulation while a second engineer watches the SIEM. For each run, the team records whether the alert fired, the time between the action and the alert, which fields were present in the event and any unrelated alerts that appeared. Where an alert does not fire, the team records the gap rather than adjusting the test. The output is a results log tied to the test plan identifier.
Log false positives and field gaps
The detection engineer reviews benign activity from the same hosts during the same window to find alerts triggered by normal administration, build tooling or backup jobs. Each false positive is classified with its cause and the field that caused the match. Missing fields are logged against the normalization source. The step is done when each false positive and field gap has an owner and a decision recorded in the validation record.
Tune rules and re-run validation
The detection owner changes rules or exclusions based on the findings, and each change is reviewed and versioned. The team then repeats the approved emulations for the affected sub-techniques and platforms to confirm the detection still fires and that the false positive rate has moved in the expected direction. The check is a fresh results log that matches the original expectations for every changed rule.
Re-validate after ATT&CK version changes
When MITRE releases a new ATT&CK version, the team compares the sub-technique list, detection strategy references and data component mappings against the previous scope document. Any renamed, deprecated or revoked item triggers a re-run of the affected validations. The team should confirm the current release notes and the STIX bundle for the target version before closing the review, and record the outcome against the scope document.
Preventive controls that reduce masquerading
Masquerading succeeds when a renamed or relocated binary looks like something an operator expects to see, so the strongest preventive controls make that disguise harder to keep. The cards below cover the two primary ATT&CK mitigations, Audit and Behavior Prevention on Endpoint, along with two adjacent controls that narrow where a masqueraded file can run and who can change it.
Audit process execution
The ATT&CK mitigation Audit (M1047) asks you to review how the environment is configured to log and assess activity, so that process creation records are complete enough to show what actually ran. For T1036, this means confirming that the executable path, hash, parent process and command line are all captured, not only the process name. Check that logging is enabled on every platform in scope, including Linux, macOS and container hosts, and that a sample of renamed binaries from a test run appears in your store with those fields intact.
Enforce behavior rules on endpoints
The mitigation Behavior Prevention on Endpoint (M1040) covers endpoint controls that block or flag execution based on what a process does rather than on its name. Masquerading defeats name-based allow lists, so behavior rules matter more, for example flagging a process whose file path or signed origin does not match the name it presents. Confirm with your endpoint vendor which behaviors can be blocked and which can only be alerted on, and test each rule in a staging group before it moves to enforcement.
Restrict execution to approved paths
The adjacent mitigation Execution Prevention (M1038) limits what is allowed to run, which can stop a disguised binary before its first instruction. For T1036, the practical question is whether temporary directories, user profile folders and container writable layers are blocked from launching executables, since these are common places for a renamed copy to appear. Ask your vendor or platform team to confirm how path-based and code-signing rules are supported on each operating system in your estate.
Restrict who can change binaries
The adjacent mitigation Restrict File and Directory Permissions (M1022) reduces the ability of an attacker or an unprivileged account to copy, replace or rename system binaries. Review write permissions on system binary directories, service definitions and container base images, because a masqueraded file must first be placed somewhere it can be executed. Pair this with file creation and file modification telemetry so that any unexpected write to these locations generates an alert for review.
What to do in the first hour after a masquerading alert
The first decision is whether the alert describes a real masquerade or a benign naming collision, and the fastest way to settle that is to compare the binary against what this host should be running. Pull the file hash, install path, and code signing details for the flagged process and check them against the known-good baseline for that host role, package manager records, or the golden image. A legitimate system binary that lives in an unexpected directory, carries a missing or different signer, or does not match its baseline hash is a strong indicator of T1036 Masquerading. Next, review the parent process chain and any file modifications on the host over the preceding hours, since a masquerading binary usually arrived through a dropper, a package change, or a deployment that someone can name. Record every check in the case ticket with the time and the analyst's name, because those notes become the basis for later review.
Preserve volatile evidence before anything is stopped or rebooted. Use Velociraptor or a comparable collection tool that your team has already tested to capture the running process list, open network connections, loaded modules, and a copy of the suspect file with its hash recorded at collection time. Confirm that the collection itself is logged and that the collector account is authorized for that host. Then decide on containment with the system owner present. Isolating the host at the network layer is usually preferable to killing the process, because a kill can destroy the in-memory state you need. Scope containment to what the evidence supports, and write down which options were considered and why each was accepted or rejected.
Container and ESXi cases need a different path. If the flagged process runs inside a container, or the alert concerns a hypervisor host, escalate to the platform owner for that cluster or virtualization estate within the first hour rather than working the case alone, because the platform owner controls the image, the registry, the hypervisor management plane, and the rollback procedure. Ask them to confirm which image digest or host build the workload should run, and whether any recent deployment, patch, or configuration change touched it. Document each containment decision, who approved it, and the evidence it relied on. Those records are what incident review will test, so write them as if the reviewer had no access to the chat history.
How to rehearse masquerading detection in a private cyber range
Build the range as a small set of Linux and macOS endpoints enrolled in Wazuh agents, with Zeek and Suricata sensors on a monitored segment and Security Onion providing the analyst console. Keep a clean baseline image for each operating system so every exercise starts from a known state. The injects should represent masquerading in general terms: a process that presents itself under the name of a common system utility, a binary run from an unexpected user-writable location, or a file whose name suggests a trusted package but whose path does not match. Teams confirm the expected detections in Wazuh alerts built on process creation and file creation telemetry, then check whether the same events appear in Security Onion. Illustrative scenario: a red team operator places a renamed tool in a temporary directory on a test host, and the exercise succeeds only if the process lineage and path are visible to the analyst.
- Range topology: Separate the endpoint, sensor and analyst networks, and document which segment each host sits on so exposure is traceable.
- Baseline capture: Record normal process names, paths and parent processes for each image before any inject runs.
- Inject design: Define each inject as a behavior and expected evidence, not as a command, and keep the operator's notes in a controlled log.
- Expected detections: Note which alert should fire, which fields must be present, and which benign admin tasks could trigger a false positive.
- Rule tuning: Track every noisy rule and the reason it was adjusted, so later exercises measure the same logic.
Check that each expected detection fires within the window your team agreed on and that the analyst can explain the process path without guessing.
Containers and ESXi hosts need different telemetry than general endpoints, so this tab uses a separate part of the range. Enroll the container host and the ESXi management interface into the log pipeline, and forward container runtime events, host process events and hypervisor audit logs to Wazuh. Zeek can contribute network metadata for traffic between workloads and the management plane. The illustrative injects here cover an image whose name imitates a known base image but whose registry source differs, a container process that reports a system process name from an unexpected working directory, and a hypervisor shell or agent that reports a name matching a vendor component. The aim is to confirm that teams can compare image provenance, process paths and host audit records side by side.
- Container telemetry: Collect runtime and orchestration events so that image name, digest and launching context are all available to analysts.
- ESXi audit coverage: Confirm which host and management logs your ESXi version writes and forwards, and verify that the forwarding survives a host reboot.
- Cross-source correlation: Test whether an analyst can link a container event to a host event using timestamps and identifiers.
- Digest checks: Include an inject where the expected image digest differs from the one running, and confirm the alert reaches the right queue.
- Vendor confirmation: Ask the platform vendor and your hypervisor support contract which audit fields are guaranteed in your release.
Check that the range can show, for each container and hypervisor event, the image or binary path, the launching identity and the source system.
Detection alone does not close a masquerading event. This tab covers what good triage looks like and how the analyst hands the case to the incident team. In the range, the analyst receives an alert from Wazuh or Security Onion and must decide whether the name, path, hash and parent process match a known-good baseline. Triage notes should record what was observed, what was compared, and what remains unknown. The handoff packet should include the alert identifiers, the affected hosts, the time window, the Zeek or Wazuh evidence, and the containment decision. Facilitators score the exercise on clarity and completeness, not only on whether the alert fired. Illustrative scenario: the analyst finds a renamed binary, confirms it is not in the baseline, isolates the host under the agreed procedure, and passes a reproducible timeline to the incident lead.
- Triage checklist: Compare name, path, owner, hash and parent process against the baseline before drawing a conclusion.
- Evidence preservation: Export the relevant Wazuh and Security Onion records and note the collection time.
- Containment step: Follow the isolation procedure your organization has approved, and record who approved it.
- Handoff packet: Include alert IDs, scope, timeline, open questions and the next owner.
- Lessons capture: Log every false positive and missed signal, then assign a rule or process change with an owner.
Check that a second analyst can reproduce the triage from the handoff packet alone, without asking the first analyst for missing context.
Questions SOC leads and detection engineers ask about T1036
How do we reduce false positives from legitimate renamed binaries?
Start by treating a renamed binary as a signal to check, not as proof of malicious activity. Many legitimate packages ship executables under different names, copy tools into container images, or rename utilities during installation. The practical approach is to build an allowlist from your own estate rather than from assumptions. Compare the original file name recorded in the executable's metadata with the name on disk, and alert when they differ in a path or on a host where that pairing has never been seen. Scope rules by host role, parent process and install path, and review exceptions on a fixed schedule so that allowlist entries do not quietly accumulate. Tune in the range first, where you can replay known-good software deployments and confirm the alert volume before production use.
How do we close sub-technique coverage gaps for T1036?
Map each of the 12 sub-techniques of T1036 to a named detection strategy or analytic in your own rule inventory, then record which data sources feed each one. Gaps usually appear where a platform lacks the telemetry a rule needs, such as container runtime events or ESXi shell logs, rather than where a rule is missing. Use the ATT&CK STIX bundle for the version you target to export the sub-technique list, and keep a coverage table that shows status, owner and last validation date for each row. Prioritize sub-techniques that match your actual platforms and threat model. Confirm telemetry availability with your platform vendors and your logging pipeline before writing rules that depend on it.
How do ATT&CK v19 and v20 changes affect our Stealth rules?
ATT&CK v19 split the Enterprise Defense Evasion tactic: Stealth keeps the ID TA0005, and a new tactic, Defense Impairment, uses ID TA0112. Any rule, dashboard or coverage report that tags techniques by the old tactic name needs a mapping review. Releases can also rename, deprecate or revoke techniques and sub-techniques, and v18 replaced technique-level detections with detection strategies and analytics. Record the ATT&CK version every rule targets, subscribe to the ATT&CK updates page, and diff the relevant STIX bundle on each release. Treat the diff as a change ticket that updates rule metadata, data component references and coverage tables together.
What telemetry should we retain for container and ESXi hosts?
For containers, retain host-level process creation events, container runtime events, image creation and pull records, and file modification events from the container filesystem where your tooling can see them. For ESXi, retain shell and command execution logs, service and daemon start events, and changes to configuration files, forwarded off the host to a central store. Both platforms are easy to under-collect because default logging is often short-lived or local. Confirm with your platform vendor which events are available, at what verbosity, and how long they persist. Set retention so that investigations can reach back past the typical dwell time you expect in your own threat model, and verify that timestamps are synchronized across hosts before you rely on correlation.
How do we measure detection quality for T1036 in a cyber range?
Measure detection quality with a fixed set of scenarios, a recorded ground truth and clear pass criteria. Run each masquerading variant that applies to your platforms in a private range, record the time each event occurred, and note whether the expected alert fired, fired late, or did not fire. Track precision separately by replaying known-good software deployments so you can see false positive volume alongside detection rate. Keep results per rule and per ATT&CK version, and rerun the same scenarios after every tuning change so you can show whether a change helped or hurt. Your scenario list and results should be the evidence you show an assessor, not a single pass or fail figure.
Can our internal team run this detection program without outside help?
Many teams can run the core program internally if they already operate a SIEM, endpoint telemetry and a change process for rules. The work splits into one-time setup, such as building the coverage map, collection pipelines and a range, and recurring work, such as tuning, reviewing ATT&CK releases and rerunning scenarios. The main drivers of effort are the number of platforms in scope, how much telemetry is already collected, and how many rules need platform-specific tuning. When you request a quote from any provider, ask for the written scope, the platforms covered, which sub-techniques are included, how validation evidence is delivered, and who maintains the range after handover.
Which mitigations should we confirm before relying on Audit for T1036?
Confirm that the Audit mitigation and Behavior Prevention on Endpoint are both in place where your platforms support them. Audit depends on logging that is complete and retained, so verify that process creation and file events reach your SIEM for every in-scope host. Behavior Prevention on Endpoint depends on your endpoint product's capabilities on each operating system, including Linux, macOS and any container hosts, which vary. Document which of these you have confirmed in your environment and which you assumed, and test each one in the range before reporting it as a control.
How DeployOpen builds masquerading detections and range scenarios
DeployOpen approaches T1036 Masquerading as a written, fixed-scope engagement inside your own infrastructure. We turn Process Creation, Command Execution and File Modification telemetry into detections you can test, document and hand over, and we rehearse them in a private cyber range before they reach production.
How we scope
- Agree in writing which platforms are covered, such as Containers, ESXi, Linux, macOS and the other platforms your estate runs.
- Confirm which T1036 sub-techniques are in scope, and record the ATT&CK version the detection mappings will target.
- Inventory the telemetry sources already collected, and list gaps in Process Creation and File Modification logging before any build work starts.
How we build
- Write detection logic in open-source tooling such as Wazuh, Sigma rules and Security Onion, using the ATT&CK detection strategies for T1036.
- Map each rule to the Audit and Behavior Prevention on Endpoint mitigations so your control evidence lines up with the detections.
- Document tuning decisions, known benign process names and exception handling so analysts can review each rule later.
How we hand over
- Deliver the rule set, data source requirements and validation results as versioned artifacts in your own repository.
- Run cyber range exercises that replay masquerading scenarios against the detections and record which alerts fired and which did not.
- Provide a response runbook covering triage, host isolation and evidence collection, and walk your security operations team through it.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, so detections keep pace with new ATT&CK releases.
- Re-run range scenarios after platform upgrades or telemetry changes to confirm that masquerading detections still fire.
- Confirm with your team, before engagement, who owns rule changes, alert tuning and the cadence of range rehearsals.
