Cloud logs as an attack surface for cloud enumeration

At a glance

What this is: The article shows how cloud audit logs can become an enumeration source for attackers because they contain identity, resource, and request detail.

Why it matters: IAM, PAM, and cloud security teams need to treat log read access as sensitive because audit visibility can become an attacker intelligence source after initial compromise.

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%.

👉 Read Exaforce's analysis of how cloud logs enable attacker enumeration

Context

Cloud audit logs are built to support investigation, detection, and accountability, but they also expose rich metadata that can help an attacker map identities, services, and resources. In the context of cloud logs, the primary governance issue is that read access is often broader than teams assume, and that makes log stores a secondary reconnaissance surface, not just a defensive control.

The article focuses on AWS, Azure, and GCP audit and operational logs, showing that they can reveal source IPs, resource names, request parameters, response codes, and identity details. That matters for NHI governance because service accounts, roles, and cloud log readers can all become intelligence-gathering identities when their permissions are not constrained as carefully as write or admin access.

Key questions

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. Use role-based access, narrow query permissions, and environment scoping so people and service accounts only see the logs they need. Keep retention, export, and cross-account visibility under explicit governance, not default inheritance.

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. If a compromised account can read logs, it can turn defenders' telemetry into reconnaissance data, revealing naming conventions, service relationships, and potential pivot points for follow-on activity.

Q: What do teams get wrong about read-only access to logs?

A: They often assume read-only means low risk. In practice, log readers can gather enough operational intelligence to support enumeration, target selection, and lateral movement planning. Read access must be reviewed with the same seriousness as other privileged entitlements, especially in cloud environments.

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.

Technical breakdown

How cloud audit logs expose enumeration data

Cloud audit logs often contain the exact fields an attacker wants for mapping an environment: identity identifiers, resource names, API actions, source IPs, user agents, request parameters, and outcome codes. In AWS this is commonly surfaced through CloudTrail, in Azure through Activity and diagnostic logs, and in GCP through Audit Logs. The log record is meant for accountability, but that same granularity can expose hierarchy, naming conventions, and service relationships. Once an attacker has read access, the log store becomes a structured inventory of the environment rather than a passive record of events.

Practical implication: Treat log-read permissions as sensitive access and segment telemetry so one compromised identity does not reveal the whole environment.

Why log query permissions are a governance issue

Log access is not just an observability choice. In cloud platforms, querying logs requires explicit permissions that can be separated from operational administration, which means log readers are effectively privileged identities. If those permissions are broad, persistent, or inherited by default, the result is an intelligence layer that an attacker can use after initial access. This is especially important in NHI-heavy environments where service accounts and automation roles may inherit rights to inspect logs for troubleshooting or monitoring.

Practical implication: Review log-reader roles through the same privilege lens you apply to admin and break-glass accounts.

Cloud logging as shared adversarial infrastructure

The core mechanism here is that the same observability data powers both defence and reconnaissance. Defenders use logs to reconstruct activity and detect anomalies, while attackers use the same data to identify valuable identities, services, and paths for follow-on action. That creates a shared-resource problem: once an adversary can read logs, they inherit the organisation's own telemetry design. Zero Trust thinking applies directly here because the reader of a log stream should never be assumed benign simply because they are inside the environment.

Practical implication: Monitor log-query behaviour itself and flag unusual access patterns, not just suspicious workload activity.

Threat narrative

Attacker objective: The attacker wants environment intelligence that reduces uncertainty and helps them identify high-value identities, exposed resources, and next-step paths.

1. Entry occurs after an attacker gains initial access to an environment and reaches a log-reading identity or role with sufficient permissions to query cloud audit data.
2. Escalation happens when the attacker uses log content to enumerate identities, services, resource naming patterns, request parameters, and access paths across AWS, Azure, or GCP.
3. Impact follows when the attacker converts telemetry into targeting intelligence for lateral movement, privilege abuse, or more precise exfiltration planning.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Visibility is now a dual-use control surface. CloudTrail, Azure monitoring, and GCP audit logs are designed to support accountability, but in adversary hands they become an internal map of the environment. This is a classic NHI governance issue because service accounts, automation roles, and delegated admin identities often receive broad diagnostic access without equivalent scrutiny. The implication is that log access must be scoped, attributed, and reviewed like any other sensitive entitlement.

Identity blast radius is often larger in the log plane than in the workload plane. A compromised workload may expose one application path, but a log-reading identity can expose many paths at once by revealing resource names, error codes, and access patterns across domains. That creates a distinct concept we should name: telemetry blast radius. When a single reader can see across accounts, subscriptions, or projects, the organisation has expanded the attacker's map before any second-stage action occurs. The conclusion is to segment telemetry by tenant, workload, and investigation need.

Least privilege has to extend to read access on operational data. Security teams often focus on preventing log tampering, but the article shows that read-only access can be just as dangerous when it supports enumeration. Overprivileged logging roles, persistent access, and vague ownership all create avoidable exposure. The practitioner takeaway is that log access should be justified, time-bounded where possible, and tied to a named operational purpose.

Zero Trust for logs means assuming the reader may be hostile. The article explicitly shows that log systems were built on a benign-reader assumption that fails in breach conditions. Once that assumption is broken, the right question is no longer whether logs help defenders, but how to preserve their value without turning them into an internal intelligence feed for attackers. Teams should design monitoring, storage, and access boundaries with that failure mode in mind.

From our research:

• 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.
• From our research: 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.
• Forward look: The NHI Lifecycle Management Guide shows why logging permissions, rotation, and offboarding must be treated as one lifecycle control plane, not separate hygiene tasks.

What this signals

Telemetry blast radius is becoming a practical governance concept for cloud teams. If a reader can query too much of the log plane, the environment gives away its own structure before any exfiltration begins, so logging design now has to be reviewed alongside entitlement design.

With 1 in 4 organisations already investing in dedicated NHI security capabilities, according to The State of Non-Human Identity Security, the market is recognising that machine and service identities need controls that extend beyond workload execution into telemetry access.

Teams that already use the NHI Lifecycle Management Guide for provisioning and offboarding should extend that same lifecycle discipline to log-reader roles, because stale diagnostic access can be as risky as stale secrets.

For practitioners

• 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. Require explicit business justification and periodic review for those entitlements.
• 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. Reduce broad shared visibility wherever operationally feasible.
• Monitor queries against log stores Detect unusual search patterns, bulk export behaviour, and access from identities that do not normally perform investigation work. Treat log query activity as an event stream requiring its own detection rules.
• Limit resource metadata exposed in routine logging Review whether request parameters, resource names, and response elements are needed in every log destination. Keep high-value metadata where it is necessary, but avoid unnecessary duplication into broadly readable stores.

Key takeaways

• Cloud logs are not just evidence sources, they are intelligence sources when attackers can read them.
• The risk is largest when log-reader identities are broad, persistent, and poorly reviewed across cloud environments.
• Practitioners should govern telemetry access as privileged access and measure its blast radius like any other sensitive entitlement.

Key terms

• Telemetry Blast Radius: The amount of environment detail exposed when someone can read logs, metrics, or audit data. In cloud identity work, it describes how far a compromised reader can see across tenants, accounts, projects, or services, which often exceeds the access needed for ordinary operations.
• Log Reader Entitlement: A permission set that allows an identity to query, export, or inspect operational logs. It is a privileged access category because read access can reveal identities, resource names, request data, and service relationships that attackers can use for reconnaissance or targeting.
• Cloud Audit Log Enumeration: The use of audit or activity logs to map identities, services, and infrastructure structure. It turns normally defensive telemetry into a discovery source, especially when logs contain request parameters, response codes, and resource metadata that expose naming and dependency patterns.
• Shared Adversarial Telemetry: A logging environment that supports both defender investigation and attacker intelligence gathering. The same data can help with forensic reconstruction or with discovery and planning, so governance must assume the reader may be hostile if the environment has already been compromised.

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

👉 The full Exaforce post covers cloud-specific log sources, field examples, and mitigation ideas.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.