How T1010 application window discovery shows up in an intrusion
T1010 Application window discovery lets an adversary see which applications and windows are open on a system the adversary has already reached, so it can judge which user tasks are active, which tools the person is using and where a next step is likely to be noticed or to succeed. In MITRE ATT&CK, the technique sits under the Discovery tactic (TA0007), which ATT&CK describes as the adversary trying to figure out the environment. This section reflects Enterprise ATT&CK 20.0. For a SOC lead, the practical point is that this activity happens after an initial foothold, often alongside other discovery techniques, and it can look like ordinary desktop activity because nearly every user has windows open at any moment.
The reason it is easy to miss is that the behavior is quiet. An intruder does not need to change a file, install software or open a network connection to learn what is on screen, so the activity may produce little more than a short burst of enumeration by a process that is not expected to query window state. Before tuning any detection, confirm with your endpoint team which legitimate software on your Linux, macOS and Windows fleet calls window or desktop enumeration interfaces, such as accessibility tools, remote support agents, screen readers, automation frameworks and endpoint security products themselves. That baseline determines whether a rare caller stands out or just reflects normal administration.
Plan now for the decisions that follow a suspicious hit. Decide who on the SOC can pivot from a process-level alert to the parent process, the logged-on user and recent command execution on the same host, and confirm that your retention window covers the period before the alert. Agree in advance whether a discovery-stage hit alone triggers host isolation or only an investigation, because discovery is usually one signal among several in an intrusion. Confirm these details against the ATT&CK version your detection content targets, since ATT&CK 20.0 is the version this page uses and later releases can change how a technique is described.
Signals and data sources for T1010 detection
This table maps Linux, macOS and Windows to the data components most relevant to T1010 Application Window Discovery, the signal to look for and an open-source collector that can gather it. Read each row as a starting point: confirm the data component mapping against the Enterprise 20.0 STIX bundle before you write detection content.
| Platform | Data component and signal | Open-source collector | Confirm before deployment |
|---|---|---|---|
| Linux | Process Creation (DC0032): child processes of graphical session or desktop tools that query window lists or window titles on the X11 or Wayland session | auditd execve rules shipped to Wazuh, or Velociraptor artifacts for process events | Confirm the DC0032 mapping for T1010 in the enterprise-attack 20.0 bundle |
| Linux | Command Execution (DC0064): interactive shell commands invoking window enumeration utilities from a non-desktop user context | auditd command logging with Wazuh rules, or Velociraptor hunts over shell history | Confirm DC0064 linkage and whether analytics name Linux command telemetry explicitly |
| Linux | OS API Execution (DC0021): limited visibility without instrumentation; relies on library or syscall tracing where available | Velociraptor or eBPF-based tooling where the team has approved it, with Wazuh for alert routing | Confirm DC0021 applicability to Linux for this technique in the 20.0 bundle; coverage is often partial |
| macOS | Process Creation (DC0032): process starts of scripting or automation interpreters that enumerate application windows through the operating system scripting interface | Endpoint logging via the macOS unified log forwarded to Wazuh, or Velociraptor process artifacts | Confirm DC0032 mapping and which macOS process fields the analytic expects |
| macOS | Command Execution (DC0064): terminal or script commands that call window or accessibility enumeration from user sessions | Wazuh command and log collection, or Velociraptor artifacts that capture command lines | Confirm DC0064 linkage for macOS platforms in the 20.0 bundle before writing rules |
| macOS | OS API Execution (DC0021): calls to accessibility or window management interfaces by unexpected binaries | Velociraptor for endpoint interrogation; Sysmon-style logging is not native on macOS, so confirm the collector chosen | Confirm DC0021 applicability and expect gaps where the API is not logged by default |
| Windows | Process Creation (DC0032): process creation events for scripts or binaries that enumerate top-level windows or window titles | Sysmon process creation events forwarded to Wazuh, with Velociraptor for hunting | Confirm DC0032 mapping and the Windows event fields named in the analytic |
| Windows | Command Execution (DC0064): command-line content from scripting hosts and shells that run window enumeration | Sysmon or Windows command-line auditing into Wazuh, with Security Onion for network-side correlation | Confirm DC0064 linkage and that command-line auditing is enabled in the target fleet |
| Windows | OS API Execution (DC0021): API calls related to window enumeration made by processes outside expected software inventory | Velociraptor endpoint collection and Wazuh correlation; API-level visibility depends on the tooling configured | Confirm DC0021 applicability for Windows in the 20.0 bundle and the telemetry your EDR or collector actually exposes |
Detection logic for T1010 that analysts can tune
T1010 Application Window Discovery is easy to confuse with legitimate desktop activity, so the detection ideas below work best as a set rather than as single alerts. Each card pairs a logic pattern with the thresholds analysts should tune and the benign software that most often triggers it. Start with a baseline of normal window-enumeration activity in your own environment before you set any alert level.
Process lineage tied to user sessions
Check whether a process that enumerates windows was started from an interactive user session or from a service context that has no reason to inspect a desktop. Group events by logon session and flag enumeration tooling launched by accounts that have no prior interactive history on the host. Tune the threshold by counting how many distinct parent processes launch window-enumeration utilities per host per day, and review hosts above your baseline first. Expect false positives from accessibility tools, remote support sessions and screen readers, which legitimately query windows on behalf of a user. Confirm the parent chain before you escalate.
Enumeration from unusual parent processes
Alert when a process whose parent is a script interpreter, an Office application, a browser or a remote management agent executes utilities that list open windows or query window titles. Process Creation telemetry supplies the parent image, command line and user, which lets you filter for those combinations without inspecting file contents. Set the initial threshold to any occurrence outside a reviewed allowlist, then relax it for hosts where IT inventory agents run on a known schedule. Be aware that some endpoint management and patching tools start helper processes from script hosts, so pair the parent check with the signing certificate of the child binary.
OS API activity from non-standard binaries
Window enumeration usually relies on operating system interfaces such as the Windows user32 functions or the X11 and Wayland window listing calls on Linux. Correlate OS API Execution telemetry, where your sensor exposes it, with binaries running from user-writable paths, temporary directories or renamed executables. A useful tuning rule is to flag repeated enumeration calls from a binary that has never been seen on that host before. Accessibility frameworks, screen readers and remote support clients make heavy use of the same interfaces, so maintain a hash and path allowlist for them and review the rest. Confirm which API hooks your sensor actually records before relying on this card.
Cross-platform correlation of discovery bursts
T1010 rarely appears alone, so raise priority when window enumeration on a host occurs within the same time window as other discovery activity such as process, network share or account enumeration. Build a shared timeline across Linux, macOS and Windows endpoints in your SIEM, keyed on host and user, and alert when two or more discovery techniques follow one another from the same session. Set the window length and the minimum number of distinct techniques from your own baseline, since patch tools and inventory scans can produce bursts on a schedule. Ask your SOC whether scheduled inventory jobs are documented so that known bursts can be suppressed without hiding novel ones.
Validating tuning in the cyber range
Replay a documented set of benign and simulated enumeration activity in a private cyber range before any rule reaches production. Record the expected alert outcome for each scenario, including accessibility tools, remote support sessions and inventory agents, so that every allowlist entry has a traceable reason. Re-run the same set after each change to a rule threshold or after a sensor update. Keep the test set mapped to the ATT&CK version you target, because technique definitions can change between releases, and confirm current mappings in the official update notes before you rely on them.
How to validate the T1010 detection in a lab
This sequence turns the T1010 Application Window Discovery detection into a tested control by agreeing scope, running an authorized emulation on each platform, and recording which alerts fired and which gaps remain. The output is a dated validation record tied to the ATT&CK version the detection targets.
Confirm scope and authorization in writing
The security lead, the range owner and the system owners agree in writing which hosts, operating systems and user accounts are in the exercise, which Wazuh or SIEM tenant receives the telemetry, and who can stop the exercise. Nothing runs against a system that is not named in the signed scope. The step is complete when the signed scope document lists every platform covered by the T1010 detection: Linux, macOS and Windows.
Agree the emulation plan and expected telemetry
The red team or range operator and the detection engineer write a plan that describes the discovery behavior to be emulated in plain terms, such as enumerating windows of running applications, without publishing command lines. For each platform, the plan lists the expected data components, including Process Creation, Command Execution and OS API Execution, and the alert the detection should raise. The step is complete when each expected alert has a named owner and a pass or fail criterion.
Confirm log sources are flowing before the run
The platform team checks that the agents or collectors on each test host forward process and command telemetry to Wazuh or the chosen SIEM, and that timestamps and host names match. Gaps in collection are fixed before the emulation starts, because a missing source would look like a missed detection. The step is complete when a harmless test event from each host appears in the SIEM search with the expected fields.
Run the emulated activity on each platform
The range operator runs the agreed emulation on each Linux, macOS and Windows test host in a fixed order, and logs the start and end time of each run in the exercise record. The detection engineer does not see the operator's notes until the run ends, so the test measures what the pipeline shows. The step is complete when every planned run has a start time, an end time and a note of any deviation from the plan.
Confirm alerts fire in Wazuh or the chosen SIEM
The detection engineer searches the SIEM for the expected alerts within the run windows and checks the rule identifier, the host, the user context and the matched fields against the plan. Each platform is marked as detected, partially detected or not detected, and the matching Sigma or local rule version is recorded. The step is complete when every expected alert is either matched to an event or logged as a missed detection.
Measure gaps and assign remediation
The team compares the results with the plan and sorts gaps into categories: missing telemetry, rule logic that did not match, noisy rules that would flood analysts, and response steps that did not trigger. Each gap receives an owner and a retest date agreed with the range owner. The step is complete when every gap has a ticket, an owner and a stated fix such as a rule change, a collection change or an accepted risk signed by the risk owner.
Record results for each ATT&CK version targeted
The team writes the validation record with the ATT&CK version the detection maps to, the MITRE technique and any sub-technique identifiers, the data components used, the rule identifiers, the platforms tested and the outcome for each. The record is stored with the detection repository so auditors and future engineers can trace it. The step is complete when the record names the ATT&CK version explicitly and a second engineer has reviewed it.
Re-validate when ATT&CK content changes
The detection engineer checks the MITRE ATT&CK updates page for each new release and reviews whether T1010 or its data components were renamed, deprecated or revoked. If any of them changed, the detection is re-mapped and the full validation runs again on the affected platforms before the rule is considered current. The step is complete when the record shows the new ATT&CK version, the review date and either a passed retest or a documented reason no retest was needed.
Preventive controls that reduce T1010 exposure
Preventive controls shrink what T1010 can reveal and how much a user-level process can do with it. Three ATT&CK mitigations carry most of the weight, and each also supports detection, because a host that logs well and runs fewer tools is easier to watch.
Audit to keep enumeration visible
Audit (M1047) is the mitigation that makes window enumeration visible at all. Enable process creation and command execution logging on Windows, macOS and Linux hosts, and forward it to a central store so unusual sequences of desktop-related queries are searchable later. Check that the audit policy is applied on every host class, that logs reach the SIEM without gaps, and that retention covers the period in which a suspected intrusion is investigated.
Hardening operating system configuration
Operating System Configuration (M1028) covers the settings that decide how user-level features and utilities behave on a host. Review desktop session settings, restrict which accounts can run scripting interpreters, and set defaults for local and remote administration tools. The aim is to make routine enumeration from a standard user session harder and easier to notice. Ask your platform team for a per-OS baseline, document exceptions, and test the baseline on a cyber range image before rollout, because some settings affect legitimate business applications.
Removing unneeded utilities and features
Disable or Remove Feature or Program (M1042) reduces the number of tools an adversary can use to ask the operating system which windows are open. Inventory scripting runtimes, accessibility helpers, administration utilities and compilers on each host class, then remove or disable what the business does not need. Keep a register of exceptions with an owner and a review date. A smaller tool set also shrinks the baseline you must monitor, which makes Process Creation and Command Execution analytics easier to tune.
Confirming the mapping before citing
ATT&CK mappings change between releases, so the relationship between T1010 and these mitigations should be verified before anyone relies on it. Pull the Enterprise 20.0 STIX bundle from the attack-stix-data repository, filter for the technique and its mitigation relationships, and record the exact ATT&CK version in your control matrix. Repeat the check when a new release appears, since releases can rename, deprecate or revoke techniques. Store the query and its output with the evidence pack so an assessor can reproduce the mapping.
Triage and response when a T1010 alert fires
Start triage by establishing what the alert actually points to: the host, the logged-on user session and the parent process that launched the enumeration activity. On Windows, the process creation record and its parent chain usually show whether the activity came from an interactive desktop session, a scheduled task, a remote management agent or a script host. On Linux and macOS, confirm the controlling terminal or service manager that spawned the process. Record the host identity, the account, the session start time and the parent executable before you decide anything else, because later steps depend on those facts and volatile context can disappear once a host is rebooted or a session ends. Next, test whether the activity matches an approved administrative, support or accessibility tool. Ask the owning team for the change or support ticket, the service account that is expected to run the tool, and the hosts where it is authorized. Accessibility and screen-reader software, remote support clients and window-management utilities are common legitimate sources of window enumeration, so the approved-tool list should name the exact executables and their signing details rather than a product family. If the parent process, path or account does not match the approved record, treat the alert as unexplained. Then correlate with the events immediately before and after it, such as logon sessions, process creation for other discovery commands, file access to configuration or credential stores, and any remote access from the same source. A burst of window enumeration followed by other discovery or access activity raises priority, while an isolated event from a known tool usually closes quickly. Escalate to incident response when the parent chain or account cannot be explained, when the activity is correlated with other discovery or access events, or when it occurs on a host that should not run interactive user tools, such as a server or a privileged administration workstation. Containment should preserve evidence: isolate the host at the network level or restrict its egress through the firewall or endpoint controls your team already operates, rather than powering it off or deleting the suspicious process. Capture volatile data, such as running processes and active sessions, before any disruptive change, and confirm with the incident response lead which artifacts must be collected under your evidence procedure. Confirm the handoff contents in advance, including the alert identifier, the triage record, the timeline and the open questions, so responders do not need to repeat the investigation.
Rehearsing T1010 detection in a private cyber range
On Linux, the range should include at least one workstation-class host and one server-class host, each forwarding process and command execution telemetry to the SIEM through an agent such as Wazuh. Windowing discovery on Linux usually depends on desktop sessions and graphical display services, so the range image should run a lightweight desktop environment with a seeded set of user applications. Confirm with your platform team that audit rules for process execution are enabled on every range host before any inject is scheduled.
- Range build: Keep one desktop host and one headless host, so the team can compare detections where a display server exists and where it does not.
- Injects: Schedule a benign, pre-approved inject that enumerates open application windows through a display-server query, run by a dedicated test account in the authorized range.
- SIEM expectation: Process creation and command execution records should appear with the host, user, parent process and full command line, mapped to the relevant ATT&CK detection strategy for T1010.
- Tuning check: Measure how often the same benign administrative tooling triggers the rule, and document exclusions with an owner and a review date.
- Response record: Capture the alert, the triage notes, the affected account, and the decision to close, escalate or contain.
Check that the rule fires on the injected activity within the agreed detection window, and that the case record can be reconstructed by someone who was not on the exercise.
macOS ranges need endpoint telemetry that captures process execution and scripting activity, typically through an agent such as Wazuh with its unified logging or endpoint collection modules, or through a commercial or open-source endpoint sensor that your team has already validated. Because macOS exposes window and application state through system frameworks, the detection team should confirm which events their chosen agent actually records before writing expectations. Use managed test accounts with no production access.
- Range build: Deploy at least one managed macOS endpoint with a standard user profile and a seeded set of applications, and enroll it in the same time source as the rest of the range.
- Injects: Use a scripted inject that performs a window-listing action through a sanctioned administrative utility, executed by a test user during a declared exercise window.
- SIEM expectation: The alert should show the originating user, the process chain and the time of execution, and should correlate with any scripting interpreter activity on the same host.
- Telemetry gaps: Record which fields are missing from the agent output, such as full arguments or parent process, and log them as detection engineering work.
- Response record: Note whether the analyst pivoted to user session history and whether the endpoint was isolated, released or left in place.
Confirm with your endpoint vendor or agent documentation which macOS events are available in your version, because coverage differs between releases.
Windows ranges are usually the richest source of T1010 telemetry, because enumeration of top-level windows commonly runs through API calls and scripting hosts that generate process and command records. The range should forward Security and Sysmon-style process events, and PowerShell script block logging should be enabled where your policy allows. The Windows host should run a seeded set of visible applications so that window enumeration has realistic targets without using real business data.
- Range build: Deploy at least one domain-joined workstation and one standalone member server, both forwarding events to the SIEM through Wazuh or Security Onion collectors.
- Injects: Schedule an approved inject that lists visible application windows through a scripting host, run under a named test account, with start and stop times recorded in the exercise log.
- SIEM expectation: Look for process creation events with command line capture, and for OS API activity where your telemetry supports it, correlated to the test account and host.
- Sigma validation: Test the matching Sigma rule against the captured events, and record the false positive rate observed on the range.
- Response record: Document containment decisions, the process tree, any artifacts the analyst collected, and the closure reason.
Verify that API-level telemetry is actually enabled on your endpoints, since many Windows environments capture command lines but not every API call.
Common questions from SOC leads about T1010 detection
How do I separate benign window listing from attacker application window discovery?
Treat the process that made the call as the first filter, then the context around it. Window enumeration is common in legitimate software such as accessibility tools, remote support agents, screen recorders, and some update or installer frameworks, so a single event rarely justifies an alert on its own. Look for enumeration launched from an unexpected parent process, from a user session that does not normally run administrative tooling, or in a short burst that is followed by other discovery activity such as process or network share enumeration. Build an allowlist from baseline data collected over a representative period, and record the reason for each entry so that reviewers can challenge it later. Confirm the exact telemetry your Linux, macOS and Windows agents provide for command execution and OS API calls before writing rules, because coverage differs by platform and by logging configuration.
How do I tune T1010 alerts on shared admin hosts without losing coverage?
Shared administration hosts generate the most noise, so tune by scoping rather than by suppression. Create separate rule conditions for these hosts, keyed to specific user groups and parent processes that are known to be approved, and keep the broader rule active for everything else. Set suppression windows only on known-benign combinations, never on a whole host or account, and review every exception on a fixed schedule. Track how many alerts each tuning change removes and sample the suppressed events to confirm they still match the approved pattern. Document the rationale in the rule metadata so that an auditor or new analyst can see why the exception exists. A change log that links each exception to a ticket and an owner makes this review repeatable.
How often should I re-validate T1010 detections after an ATT&CK release?
Re-validate after any ATT&CK release that changes the technique, its detection strategy, or its data components, and also on a regular schedule that your team can sustain. MITRE publishes ATT&CK updates several times a year and states that releases can rename, deprecate or revoke techniques, so each detection mapping should name the ATT&CK version it targets. Compare the release notes for the technique against your rule inventory, then diff the affected STIX objects in the enterprise-attack bundle for that version. Re-run your range scenarios for every changed mapping, and record the version in the validation evidence. Teams often choose a quarterly review as a baseline, adjusted to their change volume and the number of platforms in scope.
Which data sources should I prioritize for T1010 when log volume is limited?
Prioritize process creation and command execution telemetry first, because they show which programs were started and with what arguments on each platform. OS API execution data is the next most useful for T1010 because window enumeration often happens through API calls rather than through a visible command. Add file access logging only where it supports a specific hypothesis, since it adds volume quickly. Confirm each source is collected from every platform in scope, including Linux, macOS and Windows endpoints, and that the collection does not depend on a single agent version. Use your SIEM or detection platform to check which fields are populated, because a source that is enabled but missing key fields gives little value.
How do I measure detection coverage for T1010 in a way auditors will accept?
Measure coverage by platform and by test outcome, not by the number of rules deployed. For each platform in scope, record whether the required telemetry is collected, whether the rule is enabled, and whether a validation test in your cyber range produced an alert within the expected review window. Map each rule to the ATT&CK technique and version it targets, and keep the test evidence with the rule. Report gaps explicitly, such as a platform where command execution logging is not enabled, instead of averaging them away. Independent auditors and certification bodies decide what evidence satisfies a given control, so confirm the expected format with your assessor before you build the report.
Can my team run T1010 detection validation in-house, or do we need an outside partner?
Many SOC teams can run the validation themselves if they have a controlled test environment, a clear rule inventory, and time for review. The effort depends on how many platforms you cover, how many rules you maintain, and how often you re-validate. A partner is useful when the internal team lacks cyber range capacity, needs independent testing evidence, or wants a fixed-scope rehearsal with written deliverables. DeployOpen runs security testing and private cyber ranges, and most engagements are fixed-scope with scope and deliverables agreed in writing before work starts. Ask any provider to state the platforms, data sources and deliverables in the written scope so that the quote reflects your environment.
What is the difference between a T1010 test in a cyber range and one in production?
A cyber range test uses an isolated environment where the team can run benign window enumeration scenarios repeatedly, change logging settings, and review the results without affecting business systems. A production test carries operational and safety risk, so it should be limited, approved in advance, and run only where the blast radius is understood. Use the range to tune rules and confirm telemetry, then use a narrow, approved production check to confirm that the same signal appears in live logs. Document both environments separately in the validation record so that results are not mixed. Confirm your range design and change approval process with your risk owner before the first run.
How DeployOpen builds T1010 detections and range exercises
DeployOpen works on T1010 Application window discovery as a fixed-scope engagement inside your own environment. We start from the telemetry your Linux, macOS and Windows estate already produces, then build and test detections against an agreed ATT&CK version and document the results for your team.
How we scope
- Confirm which operating systems, endpoint agents and log sources are in scope for T1010 detection.
- Record the ATT&CK version the detection mappings will target, since releases can rename or deprecate techniques.
- Agree in writing which data components, such as Process Creation, Command Execution and OS API Execution, must be covered.
How we build
- Map existing Process Creation and Command Execution telemetry to T1010 detection logic described in plain language.
- Build Sigma-style rules and Wazuh alerting content in your own deployment, with tuning notes for admin tooling.
- Stand up the open-source collection pipeline so endpoint events reach your SIEM with the fields the rules need.
How we hand over
- Deliver a written runbook covering detection logic, expected false positives, triage steps and escalation paths.
- Run cyber range exercises in a private range so your analysts can see the detection fire and validate it.
- Document the validation results and open gaps so your team and any independent assessor can review them.
How we support
- Offer ongoing support as a retainer to update T1010 rules when ATT&CK releases change the technique.
- Schedule periodic re-testing of the detection after endpoint agent or operating system upgrades.
- Confirm with your team how new rule changes are reviewed and approved before they reach production.
