DET0255: Detection Strategy for Log Enumeration
This detection strategy is intended to help identify activity related to Log Enumeration, where an adversary looks through system or service logs for infor...
Analyst context for executives and security teams
This detection strategy is intended to help identify activity related to Log Enumeration, where an adversary looks through system or service logs for information that can support further discovery, such as accounts, software, vulnerabilities, or hosts. For security leaders, the practical issue is whether log access itself is monitored as a sensitive behavior, not just whether logs are retained for investigations.
Executive priority
Prioritize this as a discovery-stage visibility question: can the organization prove who or what accessed important logs on ESXi, IaaS, Linux, and macOS environments where those platforms are in scope? The business value is stronger incident scoping, better audit evidence around sensitive operational records, and earlier recognition that an intruder may be preparing follow-on actions based on information found in logs.
Technical view
The ATT&CK object provides no official detection logic or platform list for the detection strategy itself, but its relationship states that it detects T1654 Log Enumeration, a discovery technique associated with ESXi, IaaS, Linux, and macOS. SOC and detection engineering teams should validate whether they can observe unusual or unauthorized access to system and service logs, especially access patterns that align with account, software, vulnerability, or host discovery. Incident responders should treat confirmed suspicious log enumeration as context for broader discovery activity rather than as a standalone conclusion of impact.
Likely telemetry
- Authentication and authorization records for access to log repositories or log files
- File access events for system and service logs on in-scope hosts
- Administrative command or process execution telemetry involving log inspection utilities
- Cloud or IaaS audit events showing reads, exports, or queries of logging services
- ESXi, Linux, and macOS system audit records where available
Detection direction
- Validate that access to high-value system and service logs is itself logged and attributable to a user, service account, host, or workload.
- Baseline expected administrator, monitoring, backup, and troubleshooting access to logs to reduce false positives.
- Look for unusual volume, breadth, timing, or source of log access, especially by accounts or processes not normally associated with operations or security monitoring.
- Correlate suspected log enumeration with related discovery behaviors referenced by ATT&CK context, such as account, software, and remote system discovery.
- Identify blind spots where local log access, cloud log reads, or hypervisor log review are not forwarded to the SOC or are overwritten quickly.
Mitigation priorities
- Define and enforce least-privilege access to system, service, cloud, and hypervisor logs.
- Ensure administrative log access is auditable and retained long enough to support investigations and compliance evidence.
- Separate routine operational access from security-sensitive log repositories where feasible.
- Review service account permissions that allow broad log reading or export.
- Include log-access review in incident response playbooks for discovery-stage investigations.
Analyst notes and limits
This take is based on the detection strategy object DET0255 and its relationship to ATT&CK technique T1654 Log Enumeration. Because the official detection strategy description and detection text are not provided, recommendations are framed as validation questions and evidence classes rather than specific analytics.
Platforms and tactic are inferred only from the related T1654 technique, not from the detection strategy object itself. No active exploitation, actor attribution, impact, or guaranteed detection coverage is stated by the supplied fields. Local architecture, logging configuration, and normal administrator workflows are required to make this actionable.
Detection Strategy for Log 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 | T1654 | Log Enumeration | This object detects Log Enumeration. |
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 | 3bce98a122f2… |
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 DET0255Open 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.