Detecting T1654 Log enumeration

Why T1654 log enumeration matters to your SOC

Your SOC needs to know whether an adversary is studying your logging before it acts on anything else. T1654 Log enumeration is the ATT&CK technique in which an adversary looks at the logs an environment keeps, which tells them what the defenders can see, where those records live and how long they are retained. In the MITRE ATT&CK Enterprise matrix, the technique sits under the Discovery tactic (TA0007), whose stated purpose is that the adversary is trying to figure out the environment. The reference version for these pages is ATT&CK 20.0, so detection mappings should be checked against that version before they are deployed.

Log enumeration matters because it is a planning step. An adversary who understands which sources are collected, which hosts forward events and which systems keep short retention windows can choose its next actions to stay below the threshold of what is watched. Discovery activity of this kind tends to show up early in an intrusion, after initial access and before movement across the estate, and it is often mixed in with routine administrative work. For that reason, the question for your SOC is less about whether a single event is malicious and more about whether the pattern of access to logging infrastructure is expected. Ask your team to name the owners of each log source and the accounts allowed to read them, and to confirm which of those accounts should never query them interactively.

Before you build detections, confirm three things in your own environment: which log stores and forwarders your SOC depends on, which identities and service accounts can read or modify them, and how your current telemetry covers reads of log files and log management interfaces. Treat any gap in those answers as a finding to fix, since it limits what you can later prove about this technique. Your detection engineering and incident response leads should agree on the telemetry and the escalation path before the first cyber range exercise, so that an alert on this technique leads to a clear action rather than a debate about whether it matters.

Which telemetry reveals T1654 log enumeration

This table maps the data components Process Creation (DC0032), Command Execution (DC0064) and File Access (DC0055) to the signal each gives for T1654 on ESXi, IaaS, Linux and macOS, along with open-source collectors that gather them. Read each row as a question to answer in your own environment: which logs exist, who collects them, and whether the platform records enough detail to show that log files were queried. The main takeaway is that log enumeration is mostly visible as file access and command activity on the host, so file auditing and retained shell history matter more than any single product.

Platform or data component	Signal for T1654	Open-source collection to confirm
Process Creation (DC0032) on Linux	Utilities that read or search log directories appear as new process events, often with arguments naming log paths	auditd execve rules shipped to Wazuh, with Wazuh agent process inventory as a fallback
Command Execution (DC0064) on Linux and macOS	Interactive or scripted commands that list, tail or search log files, captured as command history or endpoint command records	Shell history forwarded by the Wazuh agent, plus auditd records where shell history can be altered
File Access (DC0055) on Linux	Reads against protected log paths such as system and application log directories, recorded when watch rules cover those paths	auditd file watch rules feeding Wazuh, tuned to the log directories the organization actually uses
File Access (DC0055) on macOS	Reads of unified and file-based log locations, which depend on how the endpoint is configured to retain them	Wazuh agent file integrity or file access telemetry where supported, confirmed per macOS version
ESXi hosts	Shell or SSH sessions that read host log files, and log forwarding status changes that reduce what is retained	Syslog forwarding from ESXi to a Wazuh or Security Onion collector, with host shell logins audited
IaaS control planes	API calls that read or export audit and log storage, and access to log buckets or workspaces from unexpected identities	Cloud audit log export to a collector such as Wazuh or a SIEM pipeline, confirmed against each provider's log options
Network context (Zeek or Suricata)	Bulk transfers of log archives or log exports to unfamiliar destinations, which help confirm collection intent	Zeek or Suricata sensors on segments that carry log archives, correlated with host events

Detection logic for T1654 log enumeration in Sigma and Wazuh

T1654 Log Enumeration shows up as ordinary reads of log locations, so no single event proves an attacker is present. The cards below combine behavior across process and file access events, account baselines, host-role thresholds and authentication context, and each one lists the false positive sources to rule out before alerting. All mappings target Enterprise ATT&CK version 20.0.

Process and file access pairing

Pair a command execution event that lists or searches log directories with file access events on those same paths within a short window on the same host. Alert on the pairing rather than on either event alone, because a single directory listing is common during troubleshooting. Map the rule to the Process Creation (DC0032), Command Execution (DC0064) and File Access (DC0055) data components, and confirm which log paths your Wazuh agents collect. Pair the process event with the file access event on the same host.

Baseline of log readers

Build a list of accounts and service identities that normally read log locations on each host class, using at least several weeks of collected telemetry. Flag interactive or unfamiliar accounts that begin reading audit, authentication or application logs they have never touched before. Review the baseline when staff change roles or when new agents are rolled out. The baseline should be stored as version-controlled lookup data so that changes are reviewed like any other detection content.

Thresholds by host role

Set read-volume thresholds separately for domain controllers, hypervisors, build servers and general application hosts, since each role produces very different log access patterns. A hypervisor or jump host that reads many files in a short window may be normal, while the same count on a web server may not be. Start with conservative thresholds in alert-only mode and tune them using the observed distribution per role. Document each threshold and its owner so auditors can trace why it was chosen.

Authentication anomaly correlation

Correlate log enumeration alerts with authentication events from the same session, such as unusual logon times, new source addresses, failed attempts followed by success, or privilege use shortly before the reads. Correlation raises confidence sharply when an alert shows both unfamiliar reading and unfamiliar sign-in context. Confirm that your Wazuh deployment ingests authentication telemetry from every host and identity source in scope, since gaps in coverage will suppress correlated alerts.

False positive sources to exclude

Log shippers, backup agents, configuration management runs, and vulnerability scanners all read log directories routinely and will trigger naive rules. Add each as a named allowlist entry tied to its service account, binary path and host group, not to a broad pattern. Review exclusions after every agent or scanner upgrade, because a changed binary path can silently reopen the alert. Record the exclusion rationale so the detection can be defended during assessment.

Mitigation through account management

Map the ATT&CK mitigation User Account Management (M1018) to the rule set by restricting which accounts can read audit and application log locations in the first place. Fewer readers means fewer legitimate events to filter out and a cleaner baseline. Ask your platform team to confirm how log file permissions are set on each platform in scope, and test the restriction in your cyber range before rolling it into production.

How to validate the T1654 detection before you trust it

This sequence turns a T1654 detection from a rule on paper into evidence you can defend. It confirms that the detection fires on a controlled emulation, that the events arrive in the SIEM on time, and that gaps are written down with an owner.

Agree the emulation scope in writing
The security lead, the platform owner and the range operator sign a short scope note before any activity starts. The note names the target platforms (for example ESXi, IaaS, Linux or macOS hosts), the test accounts, the isolated lab or range segment, the people who may stop the exercise, and what data may be touched. Done means every named party has signed or approved the note and a stop condition is written down.
Map the test to the detection strategy
Pick the ATT&CK version the detection was written against and record it on the test plan, because releases can rename or deprecate techniques. Then pull the T1654 detection strategy and its analytics for that version and list which data components they expect, such as Process Creation, Command Execution and File Access. Done means each analytic has a matching test step and a named telemetry source that should produce it.
Confirm baseline telemetry before the run
Before the emulation, the platform engineer checks that the log sources named in the plan are forwarding to the SIEM from the lab hosts and that timestamps are synchronized. This step catches a silent collector failure that would otherwise look like a missed detection. Done means a benign test event from each source is visible in the SIEM with the expected fields.
Run the emulation in a controlled window
The range operator runs the agreed test steps inside the approved window while a second person records each action with a time, host and account. Observers watch the SIEM and the alert queue live, and the operator stops the test if the scope note's stop condition is met. Done means the activity log matches the test plan, with no steps added outside the scope.
Check that events reached the SIEM
After the run, the analyst searches the SIEM for the recorded actions and confirms each expected event arrived, with its fields intact. Missing events point to collection, parsing or retention problems rather than rule logic, so they go to the platform owner before the detection is judged. Done means every expected event is either present or logged as a collection gap with a cause.
Measure detection time and alert fidelity
The analyst compares the time of each recorded action with the time of the matching alert and notes whether the alert named the right host, account and behavior. Alerts that fire on unrelated activity during the window are counted as false positives for the test. Done means the team has a detection time per analytic and a fidelity note that says what the alert actually described.
Record gaps and assign remediation
The team writes a results report listing each analytic, whether it fired, the detection time, the alert quality, and every gap with an owner and a retest date agreed in advance. The report is kept with the scope note and activity log so an assessor or auditor can trace the evidence. Done means the detection is marked trusted only for the conditions it passed, and every open gap has a named owner.

Preventive controls for T1654 log enumeration

Preventive controls reduce how easily an adversary can enumerate logs once they have a foothold. The cards below center on ATT&CK mitigation User Account Management (M1018), with the access decisions that decide who can read log locations and log management interfaces, and they note where other mapped mitigations may also apply.

Restrict read access to log directories

Log files often sit in shared, world-readable or broadly grouped locations, which lets any local account list and read them. Review the owner, group and permission bits on directories such as system log paths, application log folders and audit trail stores. Confirm that only the service accounts and log-review roles that need access can list or read these paths, and record the exceptions. Test the result with a non-privileged account, because a permission that looks restrictive on paper can still be inherited from a parent directory.

Limit access to log management interfaces

Central log platforms, dashboards and query APIs can expose every event an adversary would want to enumerate. Map which accounts can open saved searches, export data, change index settings or read raw events, then remove roles that bundle these rights with unrelated administration. Confirm that interface access is tied to named identities, that API tokens for log reading have owners and expiry dates, and that unused accounts are disabled rather than left active.

Review privileged group membership

Membership in administrator, root, wheel or audit-reader groups determines what a compromised account can list in the log store. Run a recurring export of members for every group that can read or manage logs, and compare it against the approved roster kept by the platform owner. Remove nested memberships that were added for a one-time task, and flag any service account that has interactive logon rights. Confirm the review cadence with your identity and access team, since the right interval depends on how often roles change in your environment.

Separate log administration from system administration

When the same administrators can change system settings and edit or purge logs, an intruder who gains that role can also hide their activity. Assign log administration, such as retention changes, forwarder configuration and audit policy edits, to a distinct role or group with its own approval path. Keep those duties off the accounts used for daily system work. Confirm with the platform owner that forwarders and collection agents run under accounts that cannot delete the events they ship.

Check fit with other mapped mitigations

ATT&CK maps other mitigations to Discovery techniques, including Audit (M1047) and Operating System Configuration (M1028), which can also limit log access through policy and hardening. Network Segmentation (M1030) can restrict which hosts reach central log interfaces. Confirm with your platform owners and system administrators whether each of these applies to your environment, because their controls depend on the specific product, deployment model and network design.

Triage steps when a T1654 log enumeration alert fires

The first decision when a T1654 Log Enumeration alert fires is whether the log access came from a process and account the organization expects to read logs. Start with the account and session context: who or what identity performed the read, whether it is a service account tied to a scheduled backup, log forwarder, SIEM collector or configuration management job, and whether that identity's usual behavior includes reading the affected log paths at that time of day. Check the parent process and the session origin, including whether the activity came from a管理 workstation, a jump host, or an unexpected interactive login. Confirm each of these against your own change calendar and runbooks, since the expected schedule for backup and forwarding jobs differs between environments and should be documented before an incident, not reconstructed during one.

Next, correlate the alert with other Discovery activity on the same host and identity. A single read of audit or system logs by a known collector is routine, but log enumeration that appears alongside account discovery, system information discovery, process discovery or network service discovery on the same host within a short window is a different pattern. Review the Discovery alerts from the sibling detections in your Wazuh, Security Onion or equivalent stack, and widen the view to the identity across other hosts. Where your data supports it, note whether the same identity recently failed authentication, was granted new privileges, or started new sessions. Preserve the relevant logs before making any change to the host, including the alert record, the audit trail covering the activity window and the process and session records, and hash or copy them to a location with restricted write access so that later changes do not overwrite the evidence. Then decide on containment, and record that decision and its reason. For a confirmed benign job, the usual outcome is tuning the rule with a documented exception tied to the specific account, host and path rather than a blanket allowlist. For an unexplained identity, consider restricting that account's sessions or disabling it, while weighing the operational impact on logging, since disabling a collector can create a blind spot. Document a timeline from first alert to decision, with timestamps in one time zone, the analyst who made each call and the evidence references, so that the record supports later review under your incident response and compliance procedures.

Rehearsing T1654 detection in a private cyber range

This tab covers hypervisor hosts and cloud control planes, where log enumeration usually shows up as access to management logs, audit trails or log export settings. The range should mirror your production layout: a small ESXi cluster or nested hypervisor lab, a vCenter-style management plane if you run one, and a cloud sandbox account with the same logging services enabled as production. Forward hypervisor and cloud audit logs to the same SIEM used in production so the rehearsal tests ingestion as well as alerting.

Range topology: Hypervisor hosts, a management plane, a log collector and a SIEM node, all in an isolated segment with no route to production.
Planned injects: A scripted scenario in which a service account reads and exports host and management logs outside its normal duties, run at an agreed time and recorded in the exercise plan.
SIEM detection: Alerts on log access by accounts that do not normally read those sources, tied to Process Creation or Command Execution events where the platform provides them, and to File Access events on log directories.
Response in the case record: The account owner, the scope of logs read, the time window, and whether log forwarding or retention settings changed during the exercise.
Confirm with the vendor: Which audit events your hypervisor and cloud platform emit for log reads and exports, and their retention limits.

Check that the exercise produced a case record a reviewer could follow without access to the range team.

Questions SOC leads ask about detecting T1654 log enumeration

Should we detect T1654 with process creation or file access telemetry?

Use both, because they answer different questions. Process creation and command execution records show which binary ran and with which arguments, which is the strongest signal that someone invoked a log-reading tool on a host. File access records show which log files were opened, which catches activity that does not spawn an obvious process or that runs through a service account. ATT&CK's data components for this family of techniques include Process Creation (DC0032), Command Execution (DC0064) and File Access (DC0055), so a detection strategy that draws on more than one of them is easier to validate. Confirm in your own environment which of these your agents and auditd or equivalent sources actually collect before you write the rule.

How do we stop log shipper noise from drowning T1654 alerts?

Start by inventorying every legitimate process that reads log files: log shippers, SIEM forwarders, backup agents, configuration management runs and monitoring checks. Then scope exclusions by parent process, service account, executable path and hash rather than by host alone, so a renamed or relocated binary still alerts. Keep a documented exception register with an owner and a review date for each entry. Test each exclusion in the cyber range by replaying the normal shipper behavior and confirming that unrelated enumeration still fires. Tuning should narrow the match conditions, not switch off the rule.

How do we tune T1654 detection for ESXi and IaaS hosts?

Treat these platforms as separate telemetry sources. ESXi hosts usually have limited agent options, so confirm which shell, syslog and command records your build exposes before writing logic that depends on them. On IaaS instances, the bulk of log reads often come from cloud-init, the cloud provider's agent and managed logging services, which should be whitelisted by service identity. Map each platform to the data components it can actually provide, and document the gaps as residual risk. The ATT&CK technique page for T1654 lists the platforms it covers, so check that list against your fleet when you scope the rule.

How often should we re-validate T1654 detections after an ATT&CK release?

Re-validate whenever the ATT&CK version your detection mappings target changes, and whenever a technique you map to is renamed, deprecated or revoked. MITRE's recent releases included v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026, and v18 replaced technique detections with detection strategies and analytics and deprecated data sources. Record the version in every rule's metadata, diff the STIX bundle for your target version, and re-run the cyber range scenarios against the updated mapping. Between releases, schedule a regular review cadence agreed with your detection engineering team.

How do we prove T1654 coverage to an auditor?

Auditors generally want to see a traceable chain: the technique, the detection logic, the data source that feeds it, a validation record and the response procedure. Keep a coverage matrix that links the ATT&CK technique and version to each rule, the telemetry it depends on, the last test date and the test result, plus the cyber range run logs as evidence. Make clear which parts are your own controls and which are findings for an independent assessor to judge. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or attestations; those come from independent auditors and certification bodies. Confirm the evidence format your assessor expects before you build the matrix.

Which ATT&CK mitigation should we pair with T1654 detection?

The mitigation most often mapped to this technique family is User Account Management (M1018). It is a useful pairing because log enumeration usually depends on the account running the command having read access to log directories. Review which accounts can read system and application logs, remove standing access that is not needed, and alert on new group memberships that grant log read rights. Pair this with the detection so that you know both whether access was tightened and whether any enumeration happened after the change. Check the mitigation text in the version of ATT&CK you target.

Can our own team build and rehearse T1654 detection without outside help?

Often yes, if you have detection engineers familiar with your SIEM, endpoint telemetry and a private test environment. The work breaks into mapping the technique to telemetry, writing and tuning rules, building a cyber range scenario, running it, and documenting results. Your costs are mainly staff time and the lab infrastructure, and most of them recur when you update rules for new ATT&CK versions. An outside partner can take on the scoping, the range build and the evidence pack under a written, fixed scope. Ask any provider to state in writing what is delivered, who runs the tests, and how the results are handed over.

How DeployOpen builds T1654 detections and range scenarios

DeployOpen approaches T1654 Log enumeration as a written, fixed-scope engagement inside the client's own environment. The work covers telemetry review, detection logic built on open-source tooling, validation in a private cyber range, and documentation the client's own teams can operate.

How we scope

Confirm which platforms in scope, such as ESXi, IaaS, Linux and macOS, actually generate log access telemetry.
Map Process Creation, Command Execution and File Access sources to the platforms your SOC monitors today.
Record the ATT&CK version the detection targets, since technique mappings can change between releases.

How we build

Write detection logic for T1654 Log enumeration in Sigma form and translate it to your SIEM or Wazuh rules.
Tune rules against administrator, backup and log shipping activity so routine reads do not flood analysts.
Test collection gaps, such as logs not forwarded off the host, and document which telemetry is missing.

How we hand over

Deliver the detection logic, data source mapping and validation results in a format your engineers can maintain.
Rehearse T1654 Log enumeration in a private cyber range and capture the alerts and analyst steps observed.
Document response actions and the mitigation User Account Management, including the controls you should confirm in your own environment.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer if detections need periodic revalidation.
Ask for a written quote tied to the scope, and confirm which items are one-time work and which recur.

T1654 Log enumeration