Notifications
Clear all
Topic starter
02/08/2026 11:40 am
TL;DR: Audit logs in AWS, Azure, and GCP expose identities, resources, parameters, and response data that attackers can use for enumeration once they obtain read access, according to Exaforce. The security problem is not logging itself, but treating log visibility as low-risk instead of privileged access.
NHIMG editorial — based on content published by Exaforce: The log rings don’t lie: historical enumeration in plain sight
By the numbers:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, and 38% have no or low visibility.
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.
Questions worth separating out
Q: How should security teams restrict access to cloud audit logs without losing visibility?
A: Treat audit-log access as privileged access and separate routine operators from investigative readers.
Q: Why do cloud logs increase attacker reach after initial compromise?
A: Because they expose identity, resource, and request detail that helps an attacker map the environment quickly.
Q: What do teams get wrong about read-only access to logs?
A: They often assume read-only means low risk.
Practitioner guidance
- Classify log readers as privileged identities Map every role, service account, and analyst group that can query CloudTrail, Azure activity data, or GCP audit logs.
- Segment telemetry by environment and investigation scope Separate log storage and query access so compromise of one account, subscription, or project does not reveal cross-environment metadata.
- Monitor queries against log stores Detect unusual search patterns, bulk export behaviour, and access from identities that do not normally perform investigation work.
What's in the full article
Exaforce's full blog covers the operational detail this post intentionally leaves for the source:
- Concrete examples of the AWS, Azure, and GCP log fields attackers can mine for enumeration
- Service-specific log retrieval permissions and how they can be abused after initial access
- Configuration choices that shape retention, queryability, and cross-environment visibility
- Practical mitigation ideas for monitoring log queries and narrowing reader access
👉 Read Exaforce's analysis of how cloud logs enable attacker enumeration →
Cloud audit logs as an enumeration risk: are your controls ready?
Explore further
02/08/2026 12:52 pm
Log access has become a privileged identity problem, not an observability problem. The article makes clear that cloud logs expose enough structure to support enumeration once an attacker can read them. That means the governance question is who can query telemetry, under what conditions, and whether those readers are treated as privileged identities in policy and review cycles. The practitioner conclusion is straightforward: telemetry readers belong inside the access-control model, not outside it.
A few things that frame the scale:
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging (37%) and over-privileged accounts (37%), according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
A question worth separating out:
Q: What should organisations do if a log-reader identity is compromised?
A: Contain that identity immediately, review the scope of telemetry it can query, and examine whether the attacker could have used logs for enumeration. Prioritise investigation of search activity, export jobs, and access from unusual locations or roles, then narrow log permissions before restoring access.
👉 Read our full editorial: Cloud logs as an attack surface for cloud enumeration
