An intruder who can read your logs learns who logs in where, which security tools are running and whether your responders have noticed them yet. MITRE ATT&CK T1654 Log Enumeration covers adversaries reading or exporting system, security and cloud logs to find useful data: authentication records, installed security software and the hosts in the network. ATT&CK v20 places it in the Discovery tactic (TA0007) for ESXi, IaaS, Linux, macOS and Windows. This guide covers how real groups have used it, what MITRE's detection strategy DET0255 looks for on each platform, the controls that shrink who can read logs at all, and how to test your coverage. It is written for detection engineers, SOC analysts and cloud security teams.
Key takeaways
- Logs are reconnaissance data. Security event logs reveal logon patterns, admin accounts and security tooling, which is why groups such as Volt Typhoon query them before moving laterally.
- Reading logs is also counter-intelligence. ATT&CK records actors watching logs in real time to track incident response; Permiso observed GUI-vil querying CloudTrail event history from the console during eviction attempts.
- Read access is the control. The only mitigation ATT&CK v20 maps is M1018 User Account Management: limit who can access and export sensitive logs. Most organisations grant far more log read access than they realise, especially to automation identities.
- Detect the actor, not the read. Administrators and log shippers read logs all day. Alert on log queries from unexpected identities, unusual tools, bulk exports, and log reads followed by file writes or network transfer.
- It often precedes log tampering. Enumeration is how an adversary picks which entries to delete or which logging to disable, so pair this coverage with detection for log clearing and tool tampering.
What T1654 covers
ATT&CK describes adversaries enumerating system and service logs to find valuable insight, such as user authentication records (linked to T1087 Account Discovery), security or vulnerable software (T1518 Software Discovery) or hosts within the network (T1018 Remote System Discovery). It lists four ways this happens:
- Host utilities:
wevtutil.exeor PowerShell on Windows to access or export security events; shell utilities against/var/logon Linux and ESXi; the unified log on macOS. - Cloud tooling: ATT&CK cites the Azure VM Agent's
CollectGuestLogs.exebeing used to collect security logs from cloud hosted machines, and records the Pacu framework collecting CloudTrail event histories and CloudWatch logs. - Central logging: adversaries may target SIEMs and other central log platforms, and may bulk export logs to their own infrastructure for offline analysis.
- Real-time monitoring: adversaries may watch logs to follow incident response and adjust their techniques to keep persistence.
T1654 has no sub-techniques. Deleting or altering entries is a different technique (T1070 Indicator Removal), and turning logging off is T1685 Disable or Modify Tools; see the T1685 Disable or Modify Tools Defensive Guide. This page covers the read side only.
Why the read matters
Windows wevtutil shows how much a single utility exposes. Microsoft documents subcommands to list every log (el), show a log's configuration and file path (gl), read events with a structured query (qe) and export events to a file (epl), alongside cl to clear a log. The same binary therefore supports discovery, collection and evasion, which is why the command line, not the binary name, carries the signal.
How adversaries use it: recorded cases
| Actor or software (ATT&CK v20) | What was recorded | What the adversary gained |
|---|---|---|
| Volt Typhoon (G1017) | Used wevtutil.exe and Get-EventLog security to search Windows logs for successful logons. CISA advisory AA24-038A reports PowerShell history on a domain controller filtering instance ID 4624 and writing output to a file in a public user folder, and a logins.ps1 script querying domain controllers for the past day's successful logons. | Logon patterns and candidate accounts and hosts for lateral movement |
| Ember Bear (G1003) | Enumerated SECURITY and SYSTEM log files during intrusions (cited to the 2024 CISA advisory on GRU unit 29155). | Host and account context |
| Aquatic Panda (G0143) | Enumerated authentication logs on Linux before deleting selected entries. | Knowledge of which entries to remove |
| Mustang Panda (G0129) | Used Wevtutil to gather Windows Security event logs. | Authentication history |
| APT5 (G1023) | Used the BLOODMINE utility to parse and extract information from Pulse Secure Connect logs. | VPN user and session data from an edge appliance |
| Pacu (S1091) | Can collect CloudTrail event histories and CloudWatch logs. | Cloud activity and responder actions |
| Akira_v2 (S1194), Megazord (S1191) | Can enumerate or print trace, debug, error, info and warning logs. | Host state before encryption |
Case: watching the responders in AWS
Permiso's research on the cloud actor it calls GUI-vil, cited by ATT&CK for this technique, describes a group that obtained AWS access keys from public sources such as GitHub and Pastebin, then worked through the AWS Management Console once it controlled an IAM user with console access. Permiso reports that GUI-vil monitored CloudTrail for changes victims made while trying to evict them, which let the group adapt its persistence. The sample event Permiso shows is a LookupEvents call from a console session filtered for write events. AWS documents that LookupEvents searches management events from the last 90 days in a Region, limited to two requests per second per account per Region. In other words, any identity with this read permission can see your containment actions as you take them.
Case: guest log collection in Azure
Mandiant's analysis of UNC3944 activity in Azure, also cited by ATT&CK, describes the actor using Azure VM extensions for reconnaissance, including the guest agent log collection extension that remotely gathers event logs, OS logs, Azure logs and selected registry keys for offline troubleshooting. Mandiant found cmd.exe launched by CollectGuestLogs.exe on an affected host and recommends watching process creation (event 4688) for that parent and child pair, together with Azure Activity Log operations for extension changes, Run Command and serial console connections.
What to detect and where
ATT&CK v20 maps detection strategy DET0255 to T1654 with one analytic per platform. The table restates MITRE's analytics and adds the tuning that makes each usable.
| Platform (analytic) | What MITRE suggests watching | Log sources named | Tuning that makes it work |
|---|---|---|---|
| Windows (AN0705) | wevtutil.exe or PowerShell cmdlets such as Get-WinEvent and Get-EventLog enumerating or exporting logs; access to Security or System channels by non-administrative users or processes, correlated with file export or network transfer | Security 4688 (process creation); 4656, 4663, 4670 (file access) | Turn on command line capture in 4688 or use Sysmon event 1; key on qe, epl and Security channel queries; allow-list known collectors and backup jobs; raise severity when output lands in public or temp folders |
| Linux (AN0706) | cat, less, grep or journalctl against /var/log; bulk access to several logs, especially auth.log and secure, in a short window | auditd SYSCALL (execve), auditd PATH (open) | Use file watch rules on authentication logs rather than all of /var/log; exclude the log agent's own account; flag interactive sessions and web or service accounts reading auth logs |
| macOS (AN0707) | log show, fs_usage or shell utilities against /var/log/system.log; plist changes that enable verbose logging | Unified log | Baseline which management tools legitimately call log show; alert on calls from user sessions or new binaries |
| IaaS (AN0708) | Cloud API calls that export or collect guest or system logs: Azure CollectGuestLogs outside maintenance windows, high frequency CloudWatch GetLogEvents across instances | AWS CloudTrail, Azure Activity Log | CloudTrail event history records read and write management events by default, but check that your trails and diagnostic settings also keep read events and any data events you rely on; alert on new principals calling log read APIs, use from new networks, and LookupEvents filtered on write events during an incident |
| ESXi (AN0709) | Shell or API access to vmkernel.log, hostd.log or vpxa.log by unexpected accounts | ESXi shell, hostd | Forward shell.log and auth.log off host; any interactive shell use outside a change window is already worth review |
For the plumbing behind these sources see the Sysmon Guide, the Linux Logging and auditd for Defenders Guide, the AWS CloudTrail Guide and the ESXi Logs Detection Guide.
Cloud and SaaS audit APIs
Control plane and audit API reads are where non-human identities matter most. In Microsoft Entra, listing directory audit records through Microsoft Graph (GET /auditLogs/directoryAudits) needs the AuditLog.Read.All permission as least privileged, with Directory.Read.All as the higher privileged option; delegated callers need a role such as Reports Reader, Security Reader or Security Administrator. Every application granted AuditLog.Read.All can therefore read who signed in, what changed and, during an incident, what your responders did. Review those grants as carefully as write permissions. The Microsoft Graph Exfiltration Detection guide covers the Graph activity logging needed to see such reads.
Behaviour sequences worth an alert
- Security log query for logon events (4624) on a domain controller, followed within minutes by a new file in a user writable folder.
- Log export (
wevtutil epl,Export-style cmdlets, CloudWatch or Log Analytics export) followed by outbound transfer from the same host or principal. - Log enumeration followed by log clearing (Security event 1102 or System event 104) or by changes to audit policy. CISA's Volt Typhoon advisory asks that every 1102 entry is investigated.
- A cloud principal that has never called LookupEvents, GetLogEvents or Graph audit APIs suddenly doing so, especially from a new IP range or user agent.
- Reads of the SIEM or log platform's own audit trail, saved searches or detection rules by an account outside the SOC. See Securing the SIEM itself.
Mitigations and controls
ATT&CK v20 maps one mitigation to T1654: M1018 User Account Management, described as limiting the ability to access and export sensitive logs to privileged accounts where possible. The rest of this section is NHI Mgmt Group's practical recommendation for applying it.
| Control | Where | What to set |
|---|---|---|
| Restrict Security log readers | Windows | Keep the Event Log Readers group empty except for named collector accounts; review local Administrators on servers, since admins can read every channel |
| Restrict auth log access | Linux | Keep auth.log and secure readable only by root and the log group; do not add service or application accounts to that group |
| Separate log read from operations roles | AWS | Do not grant cloudtrail:LookupEvents, logs:GetLogEvents or logs:FilterLogEvents through broad read-only policies to workload roles that do not need them; centralise CloudTrail in a dedicated log archive account |
| Review audit permissions on apps | Microsoft Entra | Inventory service principals holding AuditLog.Read.All or Directory.Read.All; remove unused grants |
| Ship logs off host quickly | All | Forward to a central platform the source system cannot modify, so the intruder reading a local copy does not control the record |
| Protect the log platform | SIEM | Strong authentication for SIEM users, separate admin accounts, audit of searches and exports |
Retention and protection of the central copy are covered in the Log Management and Retention Guide.
Where identity fits
Several of the strongest log readers in an estate are non-human: SIEM collectors, cloud security posture tools, backup agents and monitoring integrations hold standing permission to read every audit trail. GUI-vil started from leaked access keys. A stolen collector credential or an over-scoped integration app gives an attacker the same view your SOC has, with no host footprint at all. Treat log read permissions held by machine identities as sensitive, rotate their credentials, bind them to expected networks where the platform allows, and alert when they are used from anywhere else. If a key with log read access leaks, follow the Cloud Access Key Leak Playbook and assume the holder has seen your recent response activity.
Common failure patterns
- No command line in process events: 4688 without command line logging shows
wevtutil.exeran, not whether it listed logs, queried logons or exported the Security channel. - Cloud read events not collected: trails or diagnostic settings that keep only write events cannot show LookupEvents, GetLogEvents or audit API reads, so the most useful cloud signal never arrives.
- Blanket allow-listing of admins: Volt Typhoon used valid administrator accounts. Suppressing every log query by an administrator removes the case you most need to see.
- Response actions visible to the attacker: containment planned and executed in the same account the intruder can read lets them adapt, as Permiso describes. Coordinate eviction out of band and rotate credentials together.
- Treating enumeration and clearing separately: analysts who triage a log query without checking for a 1102, 104 or audit policy change shortly after miss the evasion that follows.
How to test your coverage
- Inventory readers: list every human group, role and service principal that can read Windows Security logs, Linux auth logs, CloudTrail, CloudWatch Logs, Entra audit logs and the SIEM. This is the baseline for both mitigation and allow-lists.
- Emulate in a lab or approved test window: from a non-admin and an admin context, query the Security log for logon events and export it to a temporary folder; repeat on Linux against the authentication log; call LookupEvents and a Graph audit query from a test principal. Use harmless test identities agreed with the system owners.
- Confirm telemetry: check that each action produced the expected 4688 or Sysmon event with command line, auditd record, CloudTrail event or Graph activity record in the SIEM, and how long it took to arrive.
- Check the analytic: the sequence rules above should fire for the export and the unexpected principal, and stay quiet for the scheduled collector.
- Roll back: delete exported files and test principals and record the result against DET0255 in your coverage map. See the MITRE ATT&CK Coverage Mapping Guide.
Metrics
- Number of identities, human and machine, with read access to each critical log source, tracked over time.
- Percentage of Windows servers sending 4688 with command line or Sysmon event 1 to the SIEM.
- Percentage of cloud accounts and tenants where log read API events are captured centrally.
- Median time from a test log export to SIEM alert.
- Alerts on log enumeration closed as benign per week, as a noise and allow-list health measure.
Framework mapping
| Framework | References |
|---|---|
| ATT&CK | T1654 Log Enumeration (Discovery TA0007); related T1087, T1518, T1018, T1070, T1685 |
| ATT&CK mitigation | M1018 User Account Management |
| ATT&CK detection | DET0255 with analytics AN0705 to AN0709 |
| NIST SP 800-53 Rev. 5 | AU-9 Protection of Audit Information, AU-9(4) Access by Subset of Privileged Users, AU-6 Audit Record Review, Analysis, and Reporting, AU-12 Audit Record Generation, AC-6 Least Privilege, SI-4 System Monitoring |
| NIST CSF 2.0 | PR.PS-04 log records generated and available for monitoring, DE.CM-03 personnel activity and technology usage monitored, DE.AE-02 adverse events analysed |
| CIS Controls v8.1 | Control 8 Audit Log Management, Control 6 Access Control Management. See the CIS Control 8 Audit Log Management Guide. |
Practitioner checklist
- List every identity, including service principals and collectors, that can read or export each critical log source.
- Empty Event Log Readers and equivalent groups of anyone who does not need them.
- Capture process command lines on Windows (4688 with command line, or Sysmon event 1).
- Add auditd watch rules on Linux authentication logs and forward them centrally.
- Collect cloud log read events (LookupEvents, GetLogEvents, Graph audit reads) and alert on new callers.
- Correlate log enumeration with export, outbound transfer and log clearing within a short window.
- Investigate every Security event 1102 and System event 104.
- Assume an intruder can see your logs during eviction: coordinate containment out of band.
- Test the analytics twice a year and record results against DET0255.
Standards and references
- MITRE ATT&CK: T1654 Log Enumeration
- MITRE ATT&CK: M1018 User Account Management
- CISA: PRC State-Sponsored Actors Compromise and Maintain Persistent Access to U.S. Critical Infrastructure (AA24-038A)
- Microsoft Learn: wevtutil
- AWS: CloudTrail LookupEvents API Reference
- Microsoft Learn: List directoryAudits
- Permiso: Unmasking GUI-vil
- Google Cloud (Mandiant): SIM Swapping and Abuse of the Microsoft Azure Serial Console
Related NHI Mgmt Group resources: Log Management and Retention Guide · T1685 Disable or Modify Tools Defensive Guide · Volt Typhoon Threat Actor Profile · Cadet Blizzard Threat Actor Profile Guide · T1087 and T1069 Account and Permission Group Discovery Defensive Guide