DET0353: Detection Strategy for Hidden User Accounts
DET0353 is a MITRE ATT&CK detection strategy for finding hidden user accounts, tied to the Hidden Users technique (T1564.002). For leaders, the practical i...
Analyst context for executives and security teams
DET0353 is a MITRE ATT&CK detection strategy for finding hidden user accounts, tied to the Hidden Users technique (T1564.002). For leaders, the practical issue is not just account visibility; hidden accounts can undermine trust in identity inventories, privileged access reviews, endpoint hardening, and incident scoping. If defenders cannot reliably prove which local or system accounts exist across Linux, macOS, and Windows, response teams may miss persistence or unauthorized access paths.
Executive priority
Prioritize this as an identity and endpoint visibility control question: can the organization prove that local and administrative accounts are known, expected, and reviewed across supported operating systems? This matters for incident response readiness, audit evidence, privileged access governance, and operational resilience because hidden or obscured accounts can outlive password resets, user offboarding, or narrow endpoint cleanup efforts.
Technical view
The supplied ATT&CK object has no official description or detection logic, but it detects T1564.002 Hidden Users under the stealth tactic. SOC, detection engineering, and IR teams should validate whether their controls can enumerate, baseline, and alert on unexpected local account creation or modification across Linux, macOS, and Windows. Detection should focus on differences between authoritative account inventories, endpoint-observed account state, login-screen or user-interface visibility, and privileged group membership. macOS deserves specific validation because the related ATT&CK description notes hidden users may involve manipulation of plist files, folder attributes, and user attributes.
Likely telemetry
- Endpoint account inventory and local user/group enumeration results
- Operating system audit logs for local account creation, modification, deletion, and privilege changes
- Authentication and logon records tied to local or administrative accounts
- Configuration or file change telemetry for account-related system files and attributes, especially where collected on macOS
- EDR or system management inventory showing user visibility, home directories, and administrative group membership
Detection direction
- Validate that account inventory covers Linux, macOS, and Windows endpoints where those platforms are in scope for T1564.002.
- Compare newly observed or modified local accounts against approved administrative, service, break-glass, and management accounts to reduce false positives.
- Tune for hidden-account indicators in context: account visibility changes, privilege membership changes, unusual home directory or profile attributes, and mismatch between UI-visible users and system-enumerated users.
- Use relationship context carefully: this detection strategy maps to Hidden Users, but the official DET0353 object does not provide specific analytics, data components, or detection text.
- Watch for blind spots where endpoint telemetry is intermittent, local audit policy is weak, macOS configuration changes are not collected, or privileged account inventories are maintained outside the SOC workflow.
Mitigation priorities
- Establish and maintain an approved inventory of local, administrative, service, and break-glass accounts by platform.
- Require change control and review for local account creation, privilege assignment, and account visibility or profile changes.
- Centralize account and endpoint configuration telemetry so SOC and IR teams can compare expected versus observed account state.
- Include hidden or unexpected local account checks in incident response triage, endpoint rebuild criteria, and post-incident validation.
- Use periodic privileged access reviews and compliance evidence collection to verify that hidden or unmanaged accounts are not being normalized as accepted risk.
Analyst notes and limits
This take is based on the DET0353 detection strategy object and its relationship to T1564.002 Hidden Users. Because the strategy itself contains no official description, detection text, tactics, or platforms, the technical guidance is intentionally framed as validation direction rather than a claim of specific MITRE-provided analytics.
ATT&CK supplies sparse fields for DET0353. Platform relevance comes from the related Hidden Users technique, not from the detection strategy object itself. Local operating system configuration, logging policy, endpoint management coverage, and approved administrative account practices are required to determine actual detection coverage.
Detection Strategy for Hidden User Accounts
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.002 | Hidden Users Sub-technique | This object detects Hidden Users. |
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 | 8052bc572c93… |
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 DET0353Open 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.