DET0128: Detection Strategy for Hidden Windows
DET0128 is a MITRE detection strategy object for identifying activity related to Hidden Window behavior, where adversaries may conceal otherwise visible ap...
Analyst context for executives and security teams
DET0128 is a MITRE detection strategy object for identifying activity related to Hidden Window behavior, where adversaries may conceal otherwise visible application windows from users. The business significance is that user-visible cues are often a weak but important last line of awareness; if malicious or unauthorized activity can run without visible prompts, help desk reports and user observation become less reliable. Because the strategy object itself has no official description, detection text, tactics, or platforms, teams should treat it as a pointer to validate monitoring for the related ATT&CK technique T1564.003 rather than as a complete detection specification.
Executive priority
Prioritize this as an endpoint visibility and SOC validation question, not as a standalone risk claim. Leaders should ask whether endpoint monitoring, incident response procedures, and audit evidence can identify stealthy process or application activity even when nothing is visible to the user. This matters for operational resilience because hidden-window behavior can reduce early human reporting and may complicate triage unless SOC teams have reliable endpoint telemetry across the operating systems in scope for the related technique: Linux, macOS, and Windows.
Technical view
The supplied relationship says this detection strategy detects T1564.003 Hidden Window, a stealth technique on Linux, macOS, and Windows. SOC and detection engineering teams should validate whether existing endpoint detections can correlate process execution, parent-child process relationships, application/window state indicators where available, command-line or script activity, and user-session context to identify applications operating in a concealed or non-interactive manner. Because the DET0128 object has no official detection logic, teams should not assume coverage from the ATT&CK entry alone; they should map local telemetry and analytics directly to the related technique behavior.
Likely telemetry
- Endpoint process creation and termination events
- Parent-child process lineage and command-line arguments
- User session, desktop, or interactive logon context
- Application execution telemetry from Linux, macOS, and Windows endpoints where collected
- Window or GUI state metadata where available from endpoint tools
Detection direction
- Confirm whether current endpoint tooling records enough context to distinguish expected administrative background execution from suspicious hidden or non-interactive application activity.
- Tune detections with environment-specific allowlists for legitimate system administration and software deployment activity, since the related technique description notes administrators may hide windows to avoid disrupting users.
- Correlate hidden or non-visible execution indicators with process lineage, user context, and unusual administrative or scripting activity rather than alerting on window state alone.
- Review coverage separately for Linux, macOS, and Windows because the related technique spans all three, while DET0128 itself does not specify platform-specific logic.
- Document gaps explicitly where endpoint products do not expose window state or comparable GUI/session metadata.
Mitigation priorities
- Establish a baseline for legitimate administrative tools and deployment mechanisms that may run without visible windows.
- Ensure endpoint logging and EDR policies capture process lineage, command-line data, and user-session context on systems where the related technique is relevant.
- Restrict and monitor administrative or scripting capabilities according to least privilege and approved operational procedures.
- Include hidden-window behavior in incident response triage checklists so analysts do not rely on user-visible symptoms as evidence that activity is absent.
- Use detection validation exercises to prove whether SOC telemetry can surface concealed application activity in the local environment.
Analyst notes and limits
This object is a detection strategy with external ID DET0128 and a relationship to T1564.003 Hidden Window. The supplied ATT&CK fields provide no official description or detection content for DET0128, so the practical guidance is derived only from the relationship to the Hidden Window technique and its supplied description, tactics, and platforms.
The DET0128 object has no official detection text, no object-level platforms, and no object-level tactics in the supplied fields. Any production detection, severity, false-positive model, or coverage claim requires local telemetry review and validation against the organization’s endpoint tooling and administrative practices.
Detection Strategy for Hidden Windows
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1564.003 | Hidden Window Sub-technique | This object detects Hidden Window. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 883eabc6a0df… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0128Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.