DET0034: Detection of Adversarial Process Discovery Behavior
DET0034 is a detection strategy for adversarial process discovery behavior, tied to ATT&CK technique T1057 Process Discovery. The business significance is...
Analyst context for executives and security teams
DET0034 is a detection strategy for adversarial process discovery behavior, tied to ATT&CK technique T1057 Process Discovery. The business significance is that process enumeration often helps an intruder understand what software, security tools, and services are running before deciding what to do next. For leaders, this is less about a single command and more about whether the organization can see early discovery activity across important non-Windows platforms such as ESXi, Linux, macOS, and network devices where the related ATT&CK technique applies.
Executive priority
Prioritize this as an early-warning and incident-scoping capability. Process discovery can inform follow-on adversary decisions, so weak visibility here may delay containment and make incident responders dependent on incomplete endpoint or infrastructure evidence. Security leaders should ask whether managed detection, SOC runbooks, and IR evidence collection cover the relevant platform estate, especially servers, virtualization infrastructure, macOS endpoints, Linux systems, and network devices where process visibility may be inconsistent.
Technical view
The supplied detection strategy has no official ATT&CK detection text or platform list, so implementation should be anchored to the relationship with T1057 Process Discovery. SOC and detection teams should validate whether they can observe process-listing or process-inspection behavior on the related platforms: ESXi, Linux, macOS, and network devices. Detection logic should focus on unusual process discovery activity in context, such as unexpected users, administrative sessions, management interfaces, or discovery occurring near other suspicious discovery or intrusion signals. IR teams should ensure collected evidence can show who initiated process discovery, from where, on which asset, and what happened before and after.
Likely telemetry
- Endpoint process execution and command-line telemetry where available
- User, administrator, and service account activity logs
- Remote administration and management session logs
- ESXi, Linux, macOS, and network device system or audit logs where supported
- Security tool, EDR, or managed detection alerts related to discovery behavior
Detection direction
- Map current detection coverage to T1057 Process Discovery rather than relying on DET0034 text, because no official detection guidance is supplied for this detection strategy object.
- Validate visibility separately for ESXi, Linux, macOS, and network devices; coverage on one platform should not be assumed to apply to another.
- Tune for context: administrators and monitoring tools may legitimately inspect processes, so prioritize unusual users, unusual hosts, unusual timing, or discovery activity chained with other suspicious events.
- Confirm logs preserve enough detail to distinguish local administrative activity from remote or automated discovery.
- Review blind spots around infrastructure and network devices, where process telemetry may be sparse, inconsistently normalized, or retained for shorter periods.
Mitigation priorities
- Establish asset and platform coverage requirements first, especially for systems matching the related T1057 platforms.
- Ensure logging and audit policies capture process and administrative activity at a level useful for investigation.
- Limit and monitor administrative access because elevated access may provide better process detail according to the related ATT&CK technique description.
- Baseline expected administrative and monitoring behavior to reduce false positives while preserving sensitivity to unusual discovery.
- Integrate detections into SOC triage and IR playbooks so process discovery events trigger scoping questions rather than isolated alert handling.
Analyst notes and limits
This take is intentionally conservative because the ATT&CK detection strategy object provides no official description, detection text, tactics, or platforms. The main usable context is the relationship indicating that DET0034 detects T1057 Process Discovery. Defensive value comes from validating telemetry and detection logic around that related technique in the local environment.
The source object does not specify detection analytics, data components, procedures, mitigations, or platforms. Platform references come only from the related T1057 technique context. Local asset inventory, logging configuration, administrative practices, and SOC tooling are required to determine actual coverage and priority.
Detection of Adversarial Process Discovery Behavior
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 | T1057 | Process Discovery | This object detects Process 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 | 9c2048417069… |
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 DET0034Open 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.