How T1202 indirect command execution hides inside normal Windows activity
The SOC lead's problem is that direct shell alerts are either noisy or silent. An adversary who wants to avoid obvious command interpreter activity can ask a program that already runs on the host to carry out commands on its behalf. ATT&CK places this under the Stealth tactic, TA0005, which describes adversaries hiding and concealing their actions so that they appear as normal behavior. In intrusions, this usually shows up after initial access, when the operator is trying to keep activity looking routine while they move through the environment. For a defender, the practical consequence is that a rule written only for a shell launched from an unusual parent may never fire. The detection work starts with the question of which legitimate programs on your Windows estate can launch other programs, and whether your team knows what normal looks like for them.
Windows telemetry gives you the pieces needed to answer that question, but no single event is decisive. Process Creation records the parent and child relationship, which is where an intermediary launching an unexpected child process becomes visible. Network Connection Creation and File Creation add context, such as an outbound connection or a new file written by a process that has no reason to make one. The useful signal is the combination of these events for one process tree, not any one event on its own. Decide now which of these data sources your Windows endpoints forward to your SIEM, at what fidelity, and for how long. If Process Creation auditing or command line capture is not enabled consistently, the detection will have gaps that no rule can close.
This page targets Enterprise ATT&CK 20.0, released by MITRE on 2026-10-13. Mappings change between versions: ATT&CK v19 split the former Defense Evasion tactic into Stealth, which keeps ID TA0005, and Defense Impairment, so older rules tagged to Defense Evasion may need relabeling. Before you rely on any mapping, check the technique, its sub-techniques and its data component references against the STIX bundle for the version you run, which is published in the attack-stix-data repository. Record the version in your detection documentation so that a later review can see exactly what the rule was built against.
Which Windows telemetry reveals T1202 and which open-source tool collects it
This table maps each data component named for T1202 to the signal defenders should look for on Windows, the telemetry source, and the open-source collector that gathers it. Read it as a starting point for a detection design, then confirm field availability in your own environment before relying on any rule. The main takeaway is that no single data component is sufficient on its own, so parent-child process context, network context and file context should be correlated together.
| Data component | Signal to look for | Windows source and collector |
|---|---|---|
| Process Creation (DC0032) | Child processes launched through an indirect path, where the parent and child relationship or the originating user does not match the expected administrative pattern | Windows Security or Sysmon process creation events, forwarded and parsed by Wazuh |
| Command Execution (DC0064) | Supporting context on the arguments and working directory of a process, used to judge whether a launch is routine | Sysmon process creation fields and endpoint command history, collected with Wazuh or Velociraptor artifacts |
| Network Connection Creation (DC0082) | Outbound connections initiated by a process that would not normally make network calls, or unexpected destinations after a launch | Sysmon network connection events on the endpoint, with Zeek or Suricata sensors providing network-side context |
| File Creation (DC0039) | New executable, script or staging files written shortly before or after a suspicious process launch | Sysmon file creation events, collected by Wazuh, with Velociraptor used to hunt for matching files on demand |
| Fields to confirm in your environment | Parent image and child image, the originating user and logon session, integrity level, and hash or signer where recorded | Confirm these fields exist and are populated in Wazuh and in the Sysmon configuration before writing or tuning rules |
| Retention and time alignment | Ability to join process, network and file events on host identifier and timestamp within a short window | Confirm clock synchronization across endpoints and sensors and the retention period set in your Wazuh indexer |
Detection logic for T1202 that SOC teams can tune
The four ideas below approach T1202 Indirect command execution from different telemetry angles: process lineage, network behavior, file staging and cross-source correlation. Each one produces noise in environments that legitimately run deployment tools and agents, so each card names the threshold to tune and the benign sources to exclude before alerts reach an analyst.
Unusual parent-child process lineage
Build a baseline of which parent processes normally spawn which children on each host role, such as domain controllers, application servers or workstations. Flag child processes whose parent is a host-role outlier, especially when the parent is a utility that rarely launches interpreters. Tune by grouping by host role and counting first-seen pairs over a learning window. Main false positives come from software deployment tools, configuration management agents and scheduled admin scripts, which should be allowlisted by signed path and service account.
Network connection from non-network process
Alert when a process that normally has no outbound role opens a network connection, particularly to an address outside the approved management ranges. Pair Process Creation with Network Connection Creation telemetry so the process image and destination are evaluated together. Tune the threshold by excluding hosts that legitimately run updaters and by setting a minimum count of distinct destinations per hour before alerting. Main false positives come from management agents, backup clients and endpoint security components that call home to their own cloud services.
File written then executed quickly
Watch for an executable, script or archive written to a user or temporary directory and then launched within a short window by a different process. The pattern matters for T1202 because the staged file often arrives from a path that is not part of normal software installation. Tune the window and directory list per environment, and record the hash and signer of each new file. Main false positives come from software installers, patch tools and developers compiling code locally, so exclude known build paths and signed installer packages.
Correlated process and file events
Join Process Creation and File Creation events on host, user and time to show one chain: a file appears, a process starts from it and then a network connection follows. A single signal is weak, but the joined sequence is what analysts should triage. Tune the correlation window and require at least two of the three events before raising priority. Main false positives come from scheduled jobs and software updates that produce the same chain, so suppress chains that match a documented change window.
How to validate that the T1202 detection fires
This sequence proves, in a private cyber range, that the T1202 Indirect command execution detection produces the expected alert from Windows telemetry, and it leaves a repeatable record of time to alert, fields present and gaps. Teams can rerun the same test after every rule change.
Confirm telemetry collection on test endpoints
The detection engineer and the range operator confirm that Windows endpoints in the cyber range forward Process Creation, Network Connection Creation and File Creation events to the SIEM. They check the audit policy and the Sysmon or equivalent collector configuration against the documented baseline, then confirm events from a benign test action appear in the SIEM under the expected host and channel. The step is done when every test endpoint shows all three event types with the fields the rule depends on, such as parent process, image path and command line.
Approve the emulation plan in writing
Before any activity, the range owner and the security lead sign a written plan that describes the indirect command execution behavior to be emulated, the target endpoints, the accounts involved, the time window and the stop conditions. The plan states that the test runs only inside the private range and names who can halt it. It also references the ATT&CK version the detection targets, so results map to a known technique definition. The step is complete when the signed plan is filed with the test record.
Run the scoped emulation on range endpoints
A trained tester runs the approved emulation on the scoped range endpoints while a second operator watches the console and logs the start time, end time and any deviation from the plan. The team uses an emulation approach agreed in the plan rather than improvised actions, and records each step against its time stamp. The step is done when the run has finished or been stopped under the stop conditions and the operator log is complete.
Check expected events arrive in the SIEM
The analyst searches the SIEM for the test host and time window and confirms that the Process Creation, Network Connection Creation and File Creation events from the run are present. They compare the events with the operator log to make sure nothing expected is missing and nothing outside the window is attributed to the test. The step closes when each planned action has a matching event or a documented reason for its absence.
Measure time to alert and field coverage
The analyst records the time between the first emulated action and the alert, then checks that the alert contains the fields the triage process needs, including the originating process, parent process, user context and target. Missing or empty fields are logged as gaps with the event source that should have supplied them. The step is complete when the alert record lists time to alert, populated fields and every gap in one table tied to the run identifier.
Log gaps and assign fixes
The detection engineer reviews each gap and classifies it as a telemetry problem, a parsing problem, a rule logic problem or an expected limitation. Each item gets an owner and a ticket that references the rule version under test. The step is done when every gap has a classification and an owner, and no gap is left without a next action.
Repeat the test after each rule change
After any change to the T1202 rule, the telemetry configuration or the parsing pipeline, the team reruns the same approved scenario on the same range endpoints so results are comparable. They confirm the rule version and the ATT&CK version in the run record, then compare the new results with the previous baseline. The step is complete when the comparison shows whether alerts, fields and time to alert improved, held steady or regressed.
Retain results as audit evidence
The team stores the signed plan, operator log, SIEM query exports, alert records, gap table and the rule version history in a controlled repository with restricted access and a retention rule agreed with the compliance lead. Auditors and internal reviewers can then trace a claim that the detection works back to a specific run. The step is done when the evidence bundle for each run is indexed by run identifier and can be retrieved without rebuilding it.
Preventive controls mapped to T1202 in ATT&CK
The six mitigations below are the ones ATT&CK most often maps to Stealth techniques and their sub-techniques in the Enterprise 20.0 bundle. Each one targets a different part of the problem: visibility, execution control, account scope, file permissions and privilege. A mapping is not proof of coverage, so confirm for the ATT&CK version you target whether each mitigation is mapped to T1202 specifically.
Audit (M1047)
Audit is about configuring and reviewing the logs that detection depends on. T1202 is hard to see without process creation events that record the parent, the child and the full command line, because the activity runs through a trusted Windows utility. Check that audit policy is enabled on endpoints, that command line capture is on, and that these events reach your SIEM. Then confirm in the STIX bundle whether M1047 is mapped to T1202 for your target version.
Behavior prevention on endpoint (M1040)
Behavior prevention on endpoint refers to endpoint security products that block or flag suspicious process behavior, not only known file signatures. For T1202, this means reviewing whether your endpoint agent can act on a trusted utility launching a child process it does not normally start. Ask the vendor which behaviors it prevents and which it only alerts on. Test the policy in a cyber range before relying on it, since a mapping in ATT&CK does not show how a specific product behaves.
Execution prevention (M1038)
Execution prevention covers controls that decide which programs and scripts may run, such as application allowlisting or policy-based restrictions on binaries. T1202 relies on legitimate programs, so allowlisting alone may not stop it. The useful question is whether your policy limits which trusted utilities can start child processes in your environment, and whether any exceptions were granted for administrative tasks. Document those exceptions and review them on a fixed schedule.
User account management (M1018)
User account management limits which accounts exist, what they are granted and how long they stay active. Indirect execution often runs under the identity of the user who launches it, so the scope of that account determines what follow-on commands can reach. Review standard user rights, remove unused accounts and confirm that interactive logons are restricted on servers where administrative utilities are present. Confirm in the STIX bundle whether M1018 is mapped to T1202 for your target version.
Restrict file and directory permissions (M1022)
Restricting file and directory permissions limits who can write to or modify the locations that programs load from or that scripts and configuration files depend on. For T1202, the relevant question is whether standard users can create or change files in directories that trusted utilities read or execute from. Review write access on system paths, application directories and user profile locations. Pair this review with file creation telemetry so that new files in restricted paths are visible to your analysts.
Privileged account management (M1026)
Privileged account management controls how administrator rights are assigned, used and monitored. If an indirectly executed command runs with elevated rights, the impact of a single successful invocation grows. Confirm that administrative accounts are separate from daily accounts, that elevation requires an approved process, and that privileged sessions are logged. Check the mapping for T1202 in the STIX bundle for your target version, and record which privileged paths you have tested in your cyber range.
How to triage and respond when a T1202 alert fires
Start triage by establishing who asked the host to run what. For a T1202 alert, confirm the parent process that launched the indirect execution, the child process it started, and the full command line recorded in Sysmon Process Creation events. Next, identify the user account and the host's role, because an administrator on a jump server and a service account on a file server carry different risk. Check the network destinations and any files written by the same process tree through File Creation events, and record their full paths and hashes. Then decide whether the activity matches an approved administrative task by checking the change record, the maintenance window and configuration management history. If none of those explain it, treat the alert as suspicious until the evidence shows otherwise.
Containment should follow the evidence, and the order of steps matters. Where possible, capture volatile data before isolation with Velociraptor, including running processes, network connections and memory-relevant artifacts, because isolating a host can change what remains in memory. Confirm that your EDR or Wazuh active response tooling can isolate the endpoint while keeping your management channel open, and test that path before you need it. Collect the Sysmon and Windows Security event logs for the incident window and preserve copies of the written files for analysis. Then search the fleet for the same parent process, destination and file path indicators to see whether other hosts show the pattern. Keep any host you cannot reach in scope until it is cleared.
Close the incident with a written record that a reviewer can follow without the analyst present. Include the original alert, the triage answers, the containment steps, a timeline and the final decision: approved, malicious or inconclusive. Tag the record with T1202 and the ATT&CK version your detection targets, because technique details can change between releases, as the ATT&CK updates page shows. Then feed the findings back into the detection. If the alert was benign, narrow the rule using specific parent, user and destination conditions tied to the approved task, and avoid broad exclusions. If it was malicious, add the indicators to hunts and confirm the detection fired on every relevant host. Finally, record the outcome in your ATT&CK-based coverage review so that any gap stays tracked.
Rehearsing T1202 detection and response in a private cyber range
The cyber range is a private, isolated environment built for this exercise and not connected to production networks or corporate identity services. It mirrors the Windows endpoints, logging pipeline and network path that the detection depends on, so the blue team works with the same kind of telemetry it would see in its own estate. Before anything is built, the scope, the systems in the range, the exercise objectives and the rules of engagement are agreed in writing with the client.
- Windows endpoints with Sysmon: Build a small set of Windows hosts with Sysmon configured to record process creation, network connections and file creation, so the data components behind T1202 are present.
- Wazuh or Security Onion stack: Forward endpoint events to a Wazuh or Security Onion deployment, with rules and dashboards matching the target ATT&CK version named in the detection plan.
- Zeek sensor: Place a Zeek sensor on the range network to record connection metadata, so network-side evidence can be correlated with host events.
- Isolated network: Keep the range segmented from production, with controlled egress and documented data handling for every log source.
- Written baseline: Record the configuration, versions and log retention settings at the start, so results can be reproduced and reviewed later.
Confirm with DeployOpen's scoping process which products, versions and log sources the range will use before the first exercise day.
Injects are the scripted scenario phases that drive the exercise. The blue team does not see them in advance, so the test measures real triage and response rather than rehearsed answers. Each inject has a written objective, an expected set of telemetry, and a defined point at which the exercise control team can stop or adjust it. Injects are designed to be safe, reversible and limited to the range.
- Phased sequence: Run injects in a defined order, starting with benign baseline activity and then introducing indirect command execution behavior that matches the T1202 detection strategy.
- Expected telemetry per phase: For each inject, document which process creation, network connection and file creation events should appear, so gaps in coverage are visible.
- Controlled timing: Release phases at agreed intervals, and record the time of each inject so detection latency can be measured against the expected window.
- Variation in noise: Mix in normal administrative activity so analysts must separate the scenario from routine operations.
- Stop conditions: Define when the control team halts an inject, for example if a log source fails or the range boundary is at risk.
Confirm with the client who approves the scenario content and who holds the inject schedule, since that person must be able to reconstruct the timeline afterward.
A good detection is an alert that fires within the expected window, carries the fields analysts need, and leads to correct triage. The test is not only whether a rule exists but whether it produces an event that someone can act on. Detection quality is judged against the exercise plan and the telemetry expected for each inject, so results can be compared across runs and across ATT&CK versions.
- Timely alert: The alert appears within the window the exercise plan sets for each inject, and the timing is recorded from the inject log rather than from memory.
- Complete fields: The alert includes host, user, parent and child process, command context, network destination where relevant and the source log, so triage does not depend on pivoting through several tools.
- Correct triage: The analyst classifies the alert, links it to related events and reaches the correct conclusion about scope and severity.
- Mapping accuracy: The rule is tagged with the T1202 technique and the data components it relies on, and the mapping names the ATT&CK version it targets.
- Gap register: Missed or late detections are logged with the cause, such as a missing Sysmon event or a rule threshold, and assigned an owner.
Check whether each detection is tested again after any change to the logging configuration, since a silent telemetry change can remove the signal without any visible error.
A good response contains the activity, preserves evidence, removes the scenario artifacts from the range and turns the exercise into lessons the client can act on. The response is judged on the sequence and quality of actions, not on speed alone. Every action is recorded in the exercise log so the review can reconstruct what happened and why.
- Containment: The team isolates the affected range host or account in a way that is documented and reversible, and confirms that the containment did not reach other range systems.
- Evidence preservation: Relevant logs, process records and network metadata are exported and hashed before any clean-up, and the chain of custody is noted.
- Clean-up: Scenario artifacts are removed and the range is returned to its baseline configuration recorded at the start.
- Communication: Status updates go to the exercise control team and the client contacts at agreed points, using the escalation path defined in the plan.
- Lessons learned: The review covers detection gaps, response timing, decision points and changes to runbooks, with owners and due dates set during the session.
Confirm with the client how the lessons learned will feed into production detection content, change control and future range exercises.
Questions SOC leads ask about T1202 detection
How do I reduce false positives from management tools on T1202?
Scope exceptions to the specific management tool, not to the process name alone. Management, software deployment and remote administration agents often launch child processes indirectly, which produces the same process creation telemetry as the behavior this detection targets. Key each allowlist entry on several fields at once: the parent process, the signing publisher, a command line pattern and the host group where the tool runs. Tie each exception to the service account that the tool uses, so an exception cannot be reused by other activity. Review exceptions on a fixed schedule and record who approved each one. Before you rely on any suppression feature, confirm in your SIEM and Wazuh or Security Onion version how exceptions are stored, versioned and audited.
Do Sysmon configuration changes affect T1202 detection coverage?
Yes. Sysmon records only the events its configuration includes, so an exclusion for signed system binaries, a trusted path or a noisy parent process can remove the events this detection depends on without any visible error. Keep the Sysmon configuration in version control, record which event types are enabled, and require a change request for every exclusion. Before a change reaches production, replay a known test set in your cyber range and confirm the expected events still arrive. Also confirm which Sysmon version your endpoints run, because event fields and defaults can differ between releases. Your Windows endpoint team should own this review jointly with the detection engineers.
How should we handle ATT&CK version changes that move technique mappings?
Pin every detection rule to the ATT&CK version it was written against, and record the technique ID, sub-technique and tactic in the rule metadata. ATT&CK v19, released April 28, 2026, split the Enterprise Defense Evasion tactic into Stealth, which keeps ID TA0005, and a new Defense Impairment tactic with ID TA0112. Rules that carry a tactic label may need relabeling even when their logic is unchanged. Compare the STIX bundles for the old and new versions, list every changed mapping that touches your rules, and re-review those rules in a single change window. Follow the ATT&CK updates page to plan these reviews before each release.
How do we measure detection coverage for T1202 in a meaningful way?
Measure coverage as a chain of checks rather than a single yes or no. For each in-scope Windows host group, confirm four things: the required process creation and related telemetry is collected, the detection rule is enabled and version-pinned, the rule has been tested in your cyber range within a period you set, and alerts from it are triaged within your documented process. Report each check as a count over the in-scope host groups you defined, and keep the scope list with the report so auditors can trace it. Avoid publishing a single coverage figure without the scope and the test date attached, because a figure without those is hard to verify. A layer file that maps your rules to ATT&CK techniques can support the report if your tooling exports one.
How can we tell whether a T1202 gap is in telemetry or in detection logic?
Walk the pipeline in order and stop at the first layer that fails. Run a known, approved test in the cyber range, then check each layer in turn: the raw event exists on the endpoint, the event reaches the SIEM or Wazuh manager, the fields the rule needs are parsed and populated, and only then does the rule's condition match. If the raw event is missing, the gap is in endpoint configuration or collection, and Sysmon settings are the first place to look. If the event arrives but a field is empty, the gap is in parsing or normalization. If every field is present and the rule still does not fire, the gap is in the logic. Keep a record of each run so the same test can be repeated after every change.
Can our own team own T1202 detection, or do we need outside help?
Your own team can own the detection, and most organizations keep ownership in-house once it is built. Ownership usually means someone maintains the rule and its metadata, someone reviews telemetry changes, someone runs the cyber range test on a schedule, and someone triages the alerts. DeployOpen can plan, implement and document the Wazuh, Security Onion or Sysmon setup, build the cyber range exercises and hand over the runbooks. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing tuning, upgrades and continuous testing are available as retainers if your team wants that support after handover.
How DeployOpen builds T1202 detections and cyber range exercises
DeployOpen approaches T1202 Indirect command execution as a fixed-scope engagement: the detection is built into the client's own self-hosted open-source stack, then rehearsed in a private cyber range before it is handed over. Each step is agreed in writing so the client knows what is delivered and what is validated.
How we scope
- Confirm the Windows telemetry sources available, such as Process Creation, Network Connection Creation and File Creation, before any rule work starts.
- Record the ATT&CK version the detection targets, since releases can rename or deprecate techniques and sub-techniques.
- Agree in writing which hosts, log pipelines and Wazuh, Security Onion or Sigma components are in scope for T1202.
How we build
- Write detection logic in plain terms for Process Creation and Network Connection Creation, then translate it into Sigma rules and the client's SIEM format.
- Deploy the rules and log collection inside the client's own infrastructure, including the agents and parsers needed for Windows event data.
- Map each rule to the ATT&CK mitigations Audit and Behavior Prevention on Endpoint so coverage gaps are visible to the client.
How we hand over
- Deliver written runbooks for triage, escalation and containment of T1202 alerts, with the data the analyst needs at each step.
- Document rule logic, known false positive sources and the tuning decisions made during the engagement.
- Provide a cyber range exercise report that records which detections fired, which did not and what changed afterward.
How we support
- Review detection performance after handover and adjust rules when the client's Windows estate or ATT&CK version changes.
- Rerun the cyber range scenarios when rules are updated, so validation stays tied to the current configuration.
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial engagement.
