How T1679 selective exclusion hides activity in Windows estates
If you are a SOC lead or detection engineer, the first question is whether you can see T1679 Selective Exclusion on your Windows endpoints and servers today. Start by confirming the technique's definition, any sub-techniques and its platform list on the ATT&CK page for Enterprise version 20.0, because the supporting material for this page does not include a technique description or sub-technique count. Then check how your current telemetry maps to the data components the technique's detection strategy references, and record any gaps before you write new analytics.
ATT&CK places the Stealth tactic (TA0005) in the category of adversary behavior that is meant to hide and conceal actions so they appear as normal activity. In an intrusion, that concealment matters most where it reduces what your tools record. Confirm with the ATT&CK tactic page how T1679 is assigned to Stealth in version 20.0, and then map its described behavior to the Windows systems where it could plausibly occur, such as endpoints that run security agents, domain controllers and administrative workstations. The purpose is to decide where coverage is most needed, not to assume the technique is present.
Make three decisions before you build anything. First, choose the ATT&CK version your detections target and record it, since releases can rename or deprecate techniques. Second, inventory the Windows estate by host role and confirm which Process Creation, Command Execution and File Modification sources are already collected. Third, agree who owns changes to security tool configuration, so that any legitimate change can be separated from suspicious change during triage. These decisions determine whether the detection you rehearse in the cyber range reflects your real environment.
Windows telemetry that reveals selective exclusion
This table maps each Windows data component to the signal it can show for selective exclusion and the open-source collector that gathers it. Treat the first three rows as the primary evidence set and the last two as secondary context that applies only if the detection strategy for your ATT&CK version references them. Check every data component ID against the ATT&CK version you deploy, because releases can rename or deprecate them.
| Data component | Signal to look for | Open-source collector |
|---|---|---|
| Process Creation (DC0032) | New processes whose parent, image path or command line does not match the expected baseline for the host role | Sysmon process creation events forwarded by Wazuh agents, plus Windows Security process auditing with command line logging enabled |
| Command Execution (DC0064) | Commands or script content that change exclusion, scope or inspection settings for security tooling | PowerShell script block logging collected by Wazuh agents, with Sysmon command line capture for cross-checking |
| File Modification | Writes to configuration files, policy stores or exclusion lists that narrow what security tooling inspects. Confirm the ID for this component in your ATT&CK version. | Wazuh File Integrity Monitoring on agreed paths, with Sysmon file change events as a second source |
| Process Access (DC0035), secondary | Access to security or monitoring processes from sources outside the expected baseline. Use only if the targeted detection strategy references it. | Sysmon process access events, filtered to protected processes and tuned in Wazuh against a host baseline |
| Module Load (DC0016), secondary | Unexpected modules loaded into processes that govern scanning or logging. Use only if the targeted detection strategy references it. | Sysmon image load events, filtered to monitored processes and forwarded to Wazuh |
Detection logic for T1679 selective exclusion on Windows
T1679 Selective exclusion hides activity by adding or changing exclusions in Windows security controls so that specific paths, processes or file types are no longer inspected. The cards below describe detection ideas built on Process Creation, Command Execution and File Modification telemetry, each with the baseline to tune and the false positives to expect before any rule reaches production.
Exclusion changes made outside change windows
Watch for modifications to the Microsoft Defender exclusion settings, which are stored under the policy and preferences registry paths and set through the Defender configuration interface. Changes to exclusion lists are rare on most endpoints, so any modification by an account or host outside an approved change window deserves review. Build a baseline of who normally changes exclusions, typically the endpoint management platform service account, and alert on everything else. Expect false positives from endpoint management and software deployment tools that push exclusions during installs, so allow-list their service accounts only after confirming their exact behavior in your lab.
Exclusion commands run from scripts
Detect Command Execution events where the Defender configuration cmdlets or the Defender command-line utility are invoked to add exclusions. Interactive administrators rarely do this, so a script host, a scheduled task or a remote session running these commands is a stronger signal. Tune the threshold to zero for exclusion additions on workstations and to a short review queue for servers, where administrative scripts are common. The main false positives come from configuration management, golden image builds and database or backup agents that require exclusions for performance, so keep a documented list of those tools with their expected parent processes.
Exclusions pointing at user-writable paths
Compare the paths in new exclusions against a short list of locations that legitimate software uses, such as program directories and approved data volumes. Exclusions covering user profile folders, temporary directories or public download locations are the higher-risk pattern for T1679 Selective exclusion, because they can shelter unsigned binaries. Use File Modification or File Creation events on the Defender settings store to capture the change, then enrich it with the path. Expect false positives from developer workstations and build agents, which legitimately exclude project folders, so scope the rule by device group.
Broad exclusions followed by new process activity
Correlate a newly added exclusion with Process Creation events from the excluded location within a short window. The sequence matters more than the exclusion alone: a broad exclusion followed by new unsigned executables starting from that path is the behavior to escalate. Set the window and the minimum count of new executables in your Sigma rule after measuring normal change rates in the cyber range. Software installers and updaters commonly create this sequence, so exclude signed publishers only after verifying the certificate chain in your environment.
How to validate that the detection fires
This sequence confirms that the T1679 Selective Exclusion detections fire on Windows telemetry when the behavior is emulated in a controlled range. It produces a documented record of expected versus observed telemetry, alert timing and content, and the tuning decisions that follow from each run.
Agree the ATT&CK version and scope in writing
The detection owner, the range operator and the SOC lead agree in writing which ATT&CK version the detections target, which Windows hosts and log sources are in scope, and which emulation boundaries apply. Name the version explicitly, because releases can rename, deprecate or revoke techniques and the mapping must match the version the team is testing against. The step is done when the signed scope note lists the version, the hosts, the data sources and the people authorized to run the emulation.
Map each detection to expected telemetry
For each detection tied to T1679, the detection engineer writes down which data components should produce evidence, such as Process Creation, Command Execution and File Modification, and which fields in the Windows event data should carry that evidence. Confirm the current detection strategy and analytics for the targeted ATT&CK version rather than relying on older page text. The output is a mapping table with one row per analytic, listing the expected event source, the key fields and the expected alert logic, reviewed by a second engineer.
Confirm log collection before the run
The platform engineer verifies that the Windows endpoints in the range forward the required event channels to the Wazuh or SIEM pipeline, that clocks are synchronized, and that rule files for the mapped analytics are loaded at the expected version. Run a benign test event on each host and confirm it arrives with the expected fields. The step is complete when every in-scope host shows a healthy log path and the test event is searchable within the normal ingestion window.
Run the emulation in a controlled range
The red team or range operator executes an approved emulation of the selective exclusion behavior on isolated range hosts, following the agreed scope and a written runbook that records start and end times for each action. The operator does not share procedure details beyond the runbook, and the blue team does not see the plan in advance so that the test reflects normal alert handling. The step produces a timestamped action log that the detection team can compare with the telemetry later.
Check alert timing and content
The detection engineer compares the action log with the events and alerts generated in the SIEM, checking whether the expected analytic fired, how long after the action the alert appeared, and whether the alert contains the host, user, process and file context needed for triage. Record any missing fields or misleading titles. The check is complete when each expected analytic has either a matching alert with its timing and content noted, or a documented miss.
Record gaps and tune the detections
The team classifies each miss or weak alert as a telemetry gap, a logic gap, a noise problem or a documentation gap, then decides on a change such as adding a log source, adjusting a field, or refining exclusions. Each tuning decision is reviewed for its effect on false positives, which the team tests by replaying benign administrative activity from the range baseline. The step is done when every gap has an owner, a decision and a retest date agreed in the change record.
Log each run in a validation record
After each run, the team saves a validation record that includes the run date and time, the ATT&CK version, the host identifiers, the alert IDs, the log sources consulted, the timestamps for action and detection, and every tuning decision with its reviewer. Store the record alongside the detection version so that later runs can be compared and auditors can trace how coverage was confirmed. The record is complete when a reviewer who was not involved can reproduce the outcome from the stored details.
Preventive controls that reduce selective exclusion exposure
Selective exclusion works by carving out parts of a security control's coverage, so these preventive controls focus on who can change exclusions, what those changes are allowed to permit, and whether the changes are recorded. The mitigations below are ATT&CK mitigations that map to Stealth techniques in general. Confirm the mapping for T1679 Selective exclusion on its ATT&CK page for your targeted version before you cite it in a control matrix.
Audit exclusion changes
Audit (M1047) means enabling the logging that records changes to security tool settings, including exclusion lists, along with the account and process that made each change. For T1679, the key question is whether your endpoint, EDR and policy logs capture who added an exclusion, when, and from which path or console session. Test that the events reach your SIEM, such as Wazuh, and alert on any new exclusion. Confirm the T1679 mapping on its ATT&CK page before relying on this control in an audit.
Keep behavior rules active
Behavior Prevention on Endpoint (M1040) addresses suspicious activity by what a process does, not only by its file signature. Selective exclusion often aims to make a known behavior invisible to one control, so the test is whether behavioral blocking still applies to excluded paths and processes. Review each exclusion to confirm it removes only the signature check it was meant to remove, and document any exclusion that also disables behavioral rules.
Gate execution from excluded paths
Execution Prevention (M1038) covers controls that block unapproved programs and scripts from running, such as application control or allowlisting. An exclusion in one tool should not automatically allow code to run from a directory that other controls are meant to inspect. Check whether your allowlisting policy still applies to excluded locations, and test a benign, approved-by-policy program in a cyber range to see which controls still fire.
Limit who manages policy
User Account Management (M1018) concerns how accounts are created, scoped and removed. For T1679, this means restricting which accounts can edit exclusion policy in endpoint and security consoles, using role-based access where the product supports it, and removing dormant or shared accounts. Ask your platform owner to produce a current list of every account that can change exclusions, and review it on a fixed schedule.
Protect exclusion configuration files
Restrict File and Directory Permissions (M1022) limits which accounts and processes can write to the files and directories that hold security tool configuration. If exclusion lists are stored in local files or configuration management repositories, write access should be limited to the service accounts that need it. Verify permissions on the agent configuration directories in your fleet, and monitor for modifications to them with File Modification telemetry in Wazuh or Velociraptor.
Control privileged administrative access
Privileged Account Management (M1026) covers how administrator credentials are issued, used and retired. Changing exclusion policy usually requires elevated rights, so separate administrative accounts for security tooling, time-limited elevation and vaulted credentials reduce the chance that a single compromised account can add exclusions. Confirm that break-glass procedures are documented and that every privileged session on the security console is logged.
What SOC analysts do in the first hour after an alert
The first decision for a T1679 alert is whether the activity is real before anyone widens the search. Start with the raw Process Creation, Command Execution and File Modification events behind the alert on the Windows endpoint, and confirm that the fields the rule depends on are present and parsed correctly. A parsing gap can make a clean host look suspicious or hide a genuine hit. Then establish context in a fixed order: the host and its role, the account that ran the activity, the parent process that launched it, and the command line and file paths involved. Check the change calendar, the ticketing system and the relevant administration runbooks for an approved task that explains the same actions. Record who was checked and what was found, because that record decides whether the outcome is an incident or a tuning task.
Once the activity is confirmed as malicious or unexplained, widen the search before changing anything on the host. Query the same pattern across other Windows endpoints for the same time window, grouping results by account, parent process and file path, so the scope is known before containment alerts an actor. Preserve evidence first: export the matching records from Wazuh or Security Onion, collect the affected artifacts with Velociraptor, and hash any modified files while keeping a documented chain of custody. Choose containment to match the impact. Isolating one host through the EDR platform or a Wazuh active response may be enough, while disabling an account is a decision for the identity owner. Escalate to the incident commander when the account is privileged, when the pattern appears on several hosts, when a production system is affected, or when no administrator can explain the activity.
Close every alert with a disposition that feeds rule tuning: confirmed activity, false positive with the approved change reference, or inconclusive with the telemetry gap noted. For false positives, add narrow exclusions tied to a specific host group, signed binary, service account or change ticket, and record an owner and review date in the rule metadata so exclusions do not become permanent blind spots. Avoid excluding on a single field that an attacker could also set. Confirmed cases should produce a detection review that checks whether the telemetry captured the activity, plus an update to the response playbook. Re-test every tuned rule in the cyber range against both benign administration and adversary emulation scenarios to prove the change works. Finally, confirm that the rule maps to the ATT&CK version your team uses, since the ATT&CK updates page records changes that can affect technique mappings.
Rehearsing selective exclusion detection in a private cyber range
The range should be a segmented Windows lab that mirrors the production logging path closely enough that a detection built in the lab will behave the same way in your estate. Keep the lab on its own network segment with no route to production identity or data stores, and use a monitoring stack built from open-source components such as Wazuh for agent-based collection, Security Onion for network visibility and Velociraptor for endpoint collection and triage.
- Segmentation. Place the Windows endpoints, the monitoring stack and the range controller in separate zones, and document every permitted path between them.
- Endpoint telemetry. Enable process creation, command execution and file modification logging on each endpoint, and confirm which event sources are active on each build before the exercise.
- Collection pipeline. Forward events from agents to the manager and indexer, then verify that each telemetry type appears in the dashboards with consistent timestamps.
- Baseline capture. Record normal activity for a fixed period before any scenario runs, so that analysts can separate routine administration from exercise activity.
- Reset process. Use snapshots or rebuild scripts so each exercise starts from the same state.
Before the first exercise, confirm with your platform team and the vendors involved which versions are supported and which logging settings are required for each data source.
Injects should be benign, scripted and written at a level that describes the behavior being observed, without reproducing commands or payloads. The purpose is to confirm that the detection logic fires on the expected telemetry and produces alerts that analysts can act on. Each scenario should state its expected detections before it runs, so that the outcome can be scored against a written expectation rather than judged afterward.
- Scenario design. Describe each inject as a sequence of benign administrative actions that produce the process, command and file events the detection is meant to interpret. The sequence is illustrative and should be reviewed by the detection engineer.
- Expected detections. For each scenario, list the rule or analytic expected to fire, the data source it depends on and the severity it should carry.
- Negative controls. Include scripted actions that resemble the behavior but should not alert, so that false positives are measured as well as true detections.
- Timing and sequence. Run injects in a fixed order and record when each one starts and ends, so that alerts can be matched to actions.
- Scoring sheet. Keep a single record of expected and observed results for every inject.
Review each scenario with the security operations lead and confirm that it stays within the rules of engagement agreed for the range.
A successful exercise is one where the expected alerts fire on the expected telemetry, analysts triage them with complete notes, and any gaps lead to documented changes. Measure the result against the scoring sheet written before the exercise, and avoid judging the detection only by whether an alert appeared. Treat the exercise as a test of the whole chain, from telemetry collection to the analyst's decision.
- Alert coverage. Confirm that each expected detection fired, and record any scenario that produced no alert along with the likely reason.
- Time to alert. Compare alert timestamps with inject timestamps and note where delay came from, such as ingestion lag or rule scheduling. Set targets only after you have baseline data from your own range.
- Triage quality. Check that analysts recorded what they saw, which telemetry they used, what they ruled out and what they escalated.
- Documented tuning. Log every rule change, exclusion or threshold adjustment with the scenario that prompted it, the reviewer who approved it and the test that confirmed it.
- Retest. Rerun the affected scenarios after tuning and confirm the new behavior, including that negative controls still stay quiet.
Before you consider the exercise complete, confirm with your security leadership which findings need a formal owner, deadline and follow-up review.
Questions SOC leads and detection engineers ask about T1679
How do I confirm which ATT&CK version a detection rule targets?
Check the rule's metadata for the ATT&CK version it was written against, then compare that version with the current release before you rely on its technique mapping. Record the target version in the rule itself, such as in a tag or custom field, so later reviewers know which technique and sub-technique IDs were in scope when the rule was built. Releases can rename, deprecate or revoke techniques, so a mapping that was correct for one version can drift. The ATT&CK updates page lists each release. For version-level comparison, the STIX 2.1 bundles in the attack-stix-data repository are published per domain and version, so you can diff technique objects between two releases. Confirm the version your SIEM content library pins with the rule owners, since the current release is version 20.0, released on 2026-10-13.
How do I handle false positives from administrative tooling?
Start by building an inventory of the administrative tools that legitimately run in your Windows estate, then document who owns each one and which accounts and parent processes they use. Tune exclusions on specific combinations of parent process, account, host group and command context rather than on a tool name alone, because a broad exclusion also hides adversary activity that borrows the same binary. Keep every exclusion in version control with a reason, an owner and a review date. Run the rule against a benign baseline from a normal change window and against the admin activity you know about, and track how many alerts remain. Treat any exclusion that stops matching as a finding to investigate, not as routine housekeeping.
Which data sources do I need for Windows coverage of T1679?
For Windows, the core telemetry is process creation with command-line logging enabled, command execution context, and file activity on the paths your rules watch. In ATT&CK's data component model, Process Creation (DC0032), Command Execution (DC0064) and File Creation (DC0039) are the components most often referenced by Stealth techniques, so start there. Confirm the exact data components that the T1679 detection strategies reference in the Enterprise bundle for your ATT&CK version, because the topic's telemetry list includes File Modification, and you should verify how that maps in the version you run. Make sure the events reach your SIEM with parsed fields, timestamps and host identifiers intact, and test that a sample of endpoints actually produces them. Missing fields are the most common reason a correct rule never fires.
How do I test a Sigma rule before deploying it?
Test in three layers. First, validate the rule's syntax and field names with the Sigma tooling in your pipeline, so a broken rule fails in the build rather than in production. Second, replay recorded log samples that contain both known-bad and known-benign events, and confirm the rule matches the bad ones and ignores the benign ones. Third, run the technique in a private cyber range that mirrors your Windows build and logging configuration, then confirm the alert reaches the right queue with enough context to triage. Keep the test data and expected results with the rule so each change can be re-tested. Document what the range does not cover, such as production-only tooling or unusual network paths, so the gap is visible to the SOC.
How do I measure detection coverage across the Stealth tactic?
Map each deployed rule to ATT&CK technique and sub-technique IDs, then compare that inventory with the Stealth tactic's contents in the version you target. In the Enterprise 20.0 bundle, 31 techniques list Stealth (TA0005) as one of their tactics, and 31 of them list it first. Those techniques have 120 active sub-techniques between them, so count coverage at the sub-technique level where your telemetry allows. Record three states for each ID: rule deployed and tested, telemetry present but no rule, and no telemetry. Tools such as ATT&CK Navigator can visualize the layer, but the underlying spreadsheet or rule metadata is what auditors and engineers will ask to see. Confirm your counting method with your detection engineering lead before reporting a percentage.
How often should ATT&CK mappings be reviewed when techniques change?
Review mappings after every ATT&CK release, because releases can rename, deprecate or revoke techniques and change detection guidance. Recent releases include v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026, and each one can affect Stealth technique IDs. Assign a named owner for the mapping inventory, diff the new STIX bundle against the version your rules target, and log each change with a decision: keep, update, retire or add a rule. The ATT&CK v19 notes describe the split of the Defense Evasion tactic into Stealth (TA0005) and Defense Impairment (TA0112), which is the kind of change that moves rules between tactic views. Agree the review window internally with your SOC and compliance leads, and keep the review record so that reviewers can see when each mapping last changed.
How DeployOpen builds T1679 detections and range exercises
DeployOpen approaches T1679 Selective exclusion as a fixed-scope engagement inside your own environment, with the detection logic, telemetry checks and range exercises agreed in writing before work starts. The result is a detection you can explain, validate and maintain after the engagement closes.
How we scope
- Confirm which Windows endpoint groups and telemetry sources are in scope for T1679 Selective exclusion.
- Record the ATT&CK version the detections target, since releases can rename or revoke techniques.
- Agree in writing which data components, such as Process Creation and File Modification, must be available.
How we build
- Write detection logic for T1679 Selective exclusion in words and map it to the telemetry each rule needs.
- Build or adapt Sigma rules and Wazuh rules that run against your existing Windows log pipeline.
- Test each rule against benign administrative activity to document expected false positives before go-live.
How we hand over
- Deliver a written detection record covering logic, required telemetry, known gaps and tuning notes.
- Document a response runbook for analysts who triage alerts for T1679 Selective exclusion.
- Rehearse detection and response in a private cyber range and record the results for your evidence file.
How we support
- Engagements are fixed-scope, so scope changes for T1679 Selective exclusion are agreed in writing first.
- Ongoing support, upgrades and continuous testing for these detections are available as a retainer.
- Ask any provider to confirm how they will re-validate detections after each ATT&CK version update.
