DET0093: Behavioral Detection of User Discovery via Local and Remote Enumeration
DET0093 is a detection strategy for spotting attempts to discover users locally or remotely, as represented by its relationship to ATT&CK technique T1033,...
Analyst context for executives and security teams
DET0093 is a detection strategy for spotting attempts to discover users locally or remotely, as represented by its relationship to ATT&CK technique T1033, System Owner/User Discovery. This matters because user discovery is often a decision point for an intruder: it helps them understand who uses a system, whether someone is active, and which accounts may be useful for follow-on activity. Even though this ATT&CK object does not provide an official detection description, it highlights a practical defensive question: can the organization see unusual user-enumeration behavior across endpoints and relevant infrastructure before it becomes part of a broader intrusion?
Executive priority
Treat this as a coverage-validation item for discovery-stage behavior, not as a standalone incident conclusion. Security leaders should ask whether SOC, incident response, and identity teams can produce evidence of user-enumeration activity across the environments relevant to T1033: Windows, Linux, macOS, and network devices. The business value is in earlier investigation and better incident scoping: knowing when an actor is mapping users can help prioritize response, preserve evidence, and validate that identity-focused controls and monitoring are working.
Technical view
The supplied ATT&CK relationship says this strategy detects T1033, System Owner/User Discovery, under the Discovery tactic. Because the detection strategy itself has no official detection text and no explicit platform field, teams should build validation around the related technique context rather than assuming a complete analytic exists. SOC and detection engineering should confirm whether they can observe local and remote user-enumeration behaviors, distinguish expected administrative inventory from unusual discovery, and correlate such activity with nearby discovery or credential-access signals where available. IR teams should use detections for this behavior as a prompt to identify which accounts, hosts, and sessions were queried, not as proof of compromise by itself.
Likely telemetry
- Endpoint process and command execution records where available
- Authentication and session records that show active or logged-in users
- Operating system audit logs relevant to account and user queries
- Directory or identity-service query logs where remote enumeration is possible
- Network device administrative and audit logs for user or session discovery
Detection direction
- Validate visibility for the related T1033 behavior across Windows, Linux, macOS, and network devices where those platforms exist in the environment.
- Tune analytics to separate routine administrator, help desk, asset inventory, and compliance scanning activity from unusual enumeration by unexpected users, hosts, times, or management paths.
- Correlate user-discovery events with other Discovery tactic activity and with credential-access indicators when present, while avoiding a conclusion of compromise from enumeration alone.
- Prioritize detections that preserve context: initiating account, source host, target host, queried user data, execution method, and whether the activity was local or remote.
- Document blind spots caused by missing endpoint command telemetry, limited identity-service logging, unmanaged network devices, or logs that do not retain enough detail to distinguish benign administration from adversary-like discovery.
Mitigation priorities
- Establish a baseline of authorized user-enumeration activity by administrators, IT tools, and inventory systems.
- Ensure logging is enabled and retained for endpoints, identity services, remote administration paths, and network devices relevant to the related T1033 platforms.
- Apply least-privilege and administrative access controls so routine users and service accounts do not have unnecessary ability to enumerate sensitive user or session information.
- Create incident-response playbooks that define how analysts should triage user-discovery alerts, including account review, host scoping, and preservation of relevant logs.
- Use detection testing or purple-team validation to confirm that expected telemetry is collected and that alerts provide enough context for SOC action.
Analyst notes and limits
This take is based on the ATT&CK detection strategy object DET0093 and its stated relationship detecting T1033, System Owner/User Discovery. The strategy name references local and remote enumeration, but the object does not include an official description, detection logic, tactics, or platforms. Platform and tactic context therefore comes from the related T1033 technique only.
The supplied ATT&CK fields do not provide analytic logic, data sources, command examples, detection thresholds, false-positive guidance, mitigations, or evidence of real-world use. Local environment architecture, logging configuration, administrative practices, and identity infrastructure are required to determine actual coverage and alert quality.
Behavioral Detection of User Discovery via Local and Remote Enumeration
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 | T1033 | System Owner/User Discovery | This object detects System Owner/User Discovery. |
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 | b9afbbd033b0… |
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 DET0093Open 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.