The Log Rings Don't Lie: Historical Enumeration in Plain Sight

The Log Rings Don't Lie: Historical Enumeration in Plain Sight

Speakers: Bleon Proko, Security Researcher, Exa Force

Conference: BSides NYC

YouTube: https://www.youtube.com/watch?v=GEAEOOoVZ64

Overview

In a revealing talk at BSides NYC, security researcher Bleon Proko from Exa Force illuminated a critical, yet often overlooked, attack vector in cloud environments: the weaponization of logs for historical enumeration. While logs are universally understood as vital tools for defense, monitoring, and forensics, Proko demonstrated how these very data sources can be repurposed by attackers to gather extensive intelligence about identities, resources, and permissions across major cloud providers like AWS, Azure, and Google Cloud Platform (GCP). This research is a subset of a larger ongoing effort to weaponize various cloud features, embodying a "living off the land" approach where an attacker leverages existing cloud functionalities for malicious purposes.

Proko's presentation, titled "The Log Rings Don't Lie," challenges the conventional wisdom of log management, urging defenders to consider the offensive implications of readily accessible log data. The talk highlighted specific techniques and observable patterns within CloudTrail, Azure Activity Logs, Entra ID audit logs, and GCP Audit Logs that can reveal granular details about an organization's cloud infrastructure and user behavior. By dissecting the structure and content of these logs, Proko showcased how an attacker can infer privileges, identify active identities, discern authentication mechanisms, and map out resource interactions without triggering overt alerts typically associated with direct enumeration attempts.

This discussion is particularly pertinent in the current cloud security landscape, where complex permissions and vast service offerings often create blind spots for defenders. Proko's work serves as a crucial reminder that what is designed for transparency and accountability can, in the wrong hands, become a potent reconnaissance tool. The research emphasizes the need for a paradigm shift in how organizations manage access to their logging infrastructure, advocating for stringent least privilege principles even for seemingly innocuous log-reading permissions to prevent sophisticated, stealthy enumeration attacks.

Background

▶ Watch: Introduction: Logs as an enumeration method (0:30)

The modern cloud environment, characterized by its immense scale and complexity, presents unique challenges for both defenders and attackers. Each major cloud provider—AWS, Azure, and GCP—offers hundreds of services, and almost every action within these services generates a log entry. For defenders, aggregating, analyzing, and retaining these logs is a monumental task, often relying on centralized logging services like AWS CloudWatch, Azure Monitor, or GCP Cloud Logging. These services collect logs from various sources, including API calls, resource activity, and authentication events, providing a critical audit trail.

For attackers, however, this abundance of logged information can be a goldmine. Cloud environments typically operate on a whitelisting permission model: identities are explicitly granted what they are allowed to do, rather than explicitly denied what they are not. This makes traditional enumeration techniques, such as fuzzing permissions, highly inefficient and often risky, as a misstep could lead to unintended modifications or deletions. Therefore, attackers are constantly seeking stealthier methods to understand their target's cloud footprint.

Proko explains that logs contain a wealth of historical information about what specific identities have done on specific resources. This includes details about the identities themselves, their source IP addresses, endpoints (via user agents), successful and failed actions, and even the input and output parameters of API calls. The sheer volume and detail within these logs offer an unparalleled window into an organization's operational patterns and security posture. Key logging services across the major providers include:

• AWS:
• CloudTrail: The primary service for logging AWS API calls. It captures events related to identity and access management (IAM), resource creation/modification, and data plane operations (if configured for data events).
• CloudWatch: A monitoring and observability service that collects logs from various AWS services, allowing for querying and dashboarding, though often with retention period limitations and higher costs compared to direct storage like S3.
• GCP:
• Audit Logs: Comprising Admin Activity (API calls for administrative actions), System Data Access (Google's actions on your behalf), Data Access (access to user-provided data like storage files), and Policy Denied (actions blocked by organization policies).
• Resource Logs: Specific to different GCP resources.
• Transparency Logs: Actions taken by Google personnel on your account.
• Azure:
• Activity Logs: Provides insight into subscription-level events, including resource creation, updates, and deletions.
• Resource Logs: Emits detailed information about the operations that were performed by an Azure resource.
• Entra ID (formerly Azure AD) Audit Logs: Records activities related to user and group management, application usage, and authentication events.
• M365 Perview Audit: Collects logs from Microsoft 365 services.

While each cloud provider offers native solutions to extend log retention beyond default periods (typically 30-90 days), the underlying principle remains: logs are a persistent, historical record of activity. This persistence, combined with the granular detail, creates a powerful opportunity for an attacker who gains even minimal read access to these log sources.

Key Findings

▶ Watch: Logging overview across major cloud providers (2:35)

Bleon Proko's research unveils that cloud logs, despite their primary defensive purpose, contain sufficient detail to enable comprehensive historical enumeration of cloud environments. The core finding is that an attacker with read access to log sources can infer sensitive information about identities, their associated privileges, the resources they interact with, and even the authentication mechanisms in use, without directly querying the cloud API for this information. This makes log-based enumeration a stealthy and effective reconnaissance technique, aligning with MITRE ATT&CK technique T1535 (Log Enumeration).

Specifically, Proko demonstrated that logs can reveal:

1. Identity Details: A list of active identities (IM users, IM roles, service accounts, UPNs), their names, and the type of credentials they use (e.g., permanent credentials vs. temporary credentials).
2. Source Information: The IP addresses and user agents from which identities operate, aiding in geolocation and endpoint profiling.
3. Privilege Inference: By analyzing the status field of log entries (success or failure) for various API calls, an attacker can programmatically deduce an identity's allowed and denied permissions. This offers a historical snapshot of an identity's capabilities, even if permissions are temporarily granted or revoked.
4. Resource Mapping: Logs explicitly list the resources affected by an action, including their types and identifiers, allowing an attacker to map out the cloud infrastructure.
5. Authentication Mechanism Identification: Distinct patterns in sign-in logs differentiate between various authentication flows (e.g., AWS login profile vs. federated credentials vs. Identity Center), providing insights into an organization's identity management strategy.
6. Operational Flow: The sequence of events and the input/output parameters of API calls can reveal how an organization's applications and users interact with cloud services.

This capability is particularly potent because access to logs is often granted more broadly than access to sensitive configuration APIs. Many roles, even those not explicitly designed for monitoring, might have permissions to read logs for debugging or auditing purposes. An attacker who compromises such an identity can leverage these log-reading permissions to gain a holistic understanding of the target environment, laying the groundwork for more targeted and impactful attacks like exfiltration or privilege escalation.

Technical Deep Dive

▶ Watch: AWS logging explained: CloudTrail and CloudWatch (3:45)

The technical core of Proko's talk lies in dissecting the structure and content of logs across AWS, GCP, and Azure to extract actionable intelligence. The presentation focused on two primary types of log analysis: general activity logs for privilege enumeration and sign-in logs for authentication mechanism identification.

General Activity Log Analysis for Privilege Enumeration

All major cloud providers generate detailed JSON-formatted logs for API calls and resource interactions. From these, an attacker can extract:

• AWS CloudTrail Logs:
• eventSource and eventName: Indicate the service and specific API action performed.
• userIdentity: Contains crucial information about the identity, including its type (e.g., IAMUser, AssumedRole), arn (Amazon Resource Name), and userName. The principalId can differentiate between IM users (permanent credentials) and IM roles (temporary credentials).
• requestParameters and responseElements: These fields provide the input and output of the API call, often revealing specific resource names, IDs, and configurations. While some background AWS actions might show null in these fields, user-initiated actions generally populate requestParameters.
• resources: A list of affected resources, typically formatted as aws:{service}/{resourceType}/{resourceName}, which is invaluable for mapping the infrastructure.
• eventID and eventTime: For historical context.
• sourceIPAddress: The origin of the request.
• errorMessage and errorCode: Critical for privilege enumeration.

• GCP Audit Logs:
• protoPayload.methodName: The API method invoked.
• protoPayload.resourceName: The resource targeted.
• protoPayload.authenticationInfo.principalEmail: The email of the identity performing the action (can be a user or a service account).
• protoPayload.status.code and protoPayload.status.message: Indicate success or failure and provide error details, similar to AWS.
• resource.type and resource.labels: Provide context about the resource involved (e.g., cloud_run_revision, gce_instance).

• Azure Activity Logs / Entra ID Audit Logs:
• operationName: The performed action.
• caller: The identity that initiated the operation, often including the UPN (User Principal Name) for users or client ID for service principals.
• status.value: Indicates Succeeded or Failed.
• properties: Contains additional details, including requestUri, userAgent, and correlationId.

Programmatic Privilege Enumeration:

Proko highlighted a technique to infer permissions by iterating through an identity's log history and observing the status of API calls. By querying logs for a specific identity and filtering for Succeeded or Failed operations, an attacker can build a profile of what that identity is historically allowed or denied to do. For instance, if an identity repeatedly makes s3:GetObject calls to a specific bucket and these calls consistently succeed, it's a strong indicator of read access. Conversely, repeated s3:PutObject failures suggest a lack of write permission.

A significant caveat exists: permissions can be temporary or dynamic. An identity might have had access at one point, performed an action, and then had that permission revoked. The historical log would still show a Succeeded event, even if the permission no longer exists. Despite this, for long-term or permanent permissions, this method provides a high-fidelity picture of an identity's capabilities, which is invaluable for an attacker.

Sign-in Log Analysis for Authentication Mechanism Identification

Understanding how users authenticate provides critical insights into an organization's identity management practices. Different authentication flows leave distinct footprints in logs.

• AWS Sign-in Logs: AWS offers three primary ways for users to access the management console, each with unique log characteristics:

1. Login Profile (IAM User with Password):

• userIdentity.type will be IAMUser.
• The arn will explicitly contain user/.
• Crucially, the additionalEventData field will contain LoginTo: Console. This field explicitly states the mechanism used to access the console via a password.

1. Federated Credentials: This involves obtaining temporary credentials via an API like STS GetFederationToken and then using a specific AWS sign-in URL.

• userIdentity.type will be FederatedUser.
• The arn will contain federated-user/.
• The sessionName (part of the userIdentity) can be custom, often set by tools like PCO (a common penetration testing tool which adds imported-dash to the session name). An attacker can set this to anything, like attack_user.
• Significantly, the LoginTo: Console field will be ABSENT, as the user did not authenticate via a traditional password in the console. Their authentication was the permission to execute the STS API call.

1. AWS Identity Center (SSO): Users authenticate through an external Identity Provider (IdP) or AWS's own directory, then assume a role.

• userIdentity.type will be AssumedRole.
• The arn will contain assumed-role/.
• The role name often follows a pattern like AWSReservedSSO_administratoraccess_alphanumeric_characters, where administratoraccess is the permission set and the alphanumeric characters are unique.
• Importantly, the role name will often include the email prefix of the user who authenticated (e.g., [email protected] might result in a role named Bleon_AWSReservedSSO...). This directly links an SSO role session to a specific user.
• Again, the LoginTo: Console field will be ABSENT, as authentication occurs through Identity Center, not directly via an IAM user login profile.

• Entra ID Sign-in Logs:
• The additionalDetails field is highly informative, containing messages like Complete login MFA accepted, MFA not accepted, User checked "Remember me". These details provide a granular understanding of the authentication flow, including MFA status and user preferences.
• Error messages can differentiate between mistyped passwords and disabled accounts.

• GCP User Login Events:
• Strangely, user login events in GCP (often appearing as Google Workspace events) can be found within Data Access audit logs, which Proko noted was unexpected as they are not strictly "data-related."
• These logs provide clear login success or failure indicators, allowing attackers to quickly filter and analyze user authentication outcomes and reasons for failure.

By understanding these subtle differences in log fields and patterns, an attacker can gain a profound understanding of an organization's cloud authentication mechanisms and user behavior, which can be leveraged for targeted phishing, credential stuffing, or further reconnaissance.

Demo / Proof of Concept

▶ Watch: GCP logging explained: Audit Logs and types (4:45)

While Bleon Proko's talk delved deeply into the technical specifics of log analysis across various cloud providers, the presentation did not include a live demonstration or a specific tool/Proof of Concept (PoC) for log-based enumeration. Proko mentioned that this research is part of an ongoing, larger project and that he has conducted "my tests" to validate the findings. The detailed examples and log excerpts shared during the talk served as illustrative evidence of the described enumeration techniques.

Defensive Implications

▶ Watch: Azure logging architecture: Licenses and log types (7:45)

The implications of log-based enumeration for cloud defenders are significant and complex. Proko stressed that detecting this type of activity is inherently challenging because an attacker is merely reading existing logs, which is a legitimate action for many roles within an organization. Unlike active enumeration where an attacker might make many failed API calls, log-based enumeration is passive from the perspective of the target resources.

Key defensive actions include:

1. Strict Least Privilege for Log Access: This is the most critical recommendation. Organizations must meticulously review and restrict who has permission to read logs across all cloud environments. While many roles require log access for debugging, monitoring, or auditing, this access should be scoped as narrowly as possible. For instance, a developer might need to read application-specific logs but should not have access to global API logs (like CloudTrail) or sensitive identity logs (like Entra ID sign-in logs) unless absolutely necessary for their function. This is challenging to implement in practice due to the intertwined nature of cloud permissions and the sheer volume of services.
2. Monitor Access to Logging Services: While reading logs might be "normal," unusual access patterns to logging services themselves (e.g., a user who typically doesn't access CloudTrail suddenly querying it extensively, or access from an unusual IP address) could be indicative of compromise. Security teams should monitor for these anomalies.
3. Don't Blind the Defender: Proko emphasized that the solution is not to stop logging. Logging is fundamental for security, compliance, and operational insights. The goal is to manage access to logs intelligently, not to reduce the fidelity of the logs themselves.
4. Understand Your Logging Landscape: Defenders must have a comprehensive understanding of where logs are generated, stored, and how they are accessed across their entire cloud estate. This includes awareness of default retention periods, log aggregation strategies, and the permissions associated with each log source.
5. Utilize Security Information and Event Management (SIEM) / Security Orchestration, Automation, and Response (SOAR) Solutions: While not a direct prevention, a well-configured SIEM/SOAR can help aggregate logs, apply advanced analytics, and correlate events to identify suspicious patterns that might indicate an attacker is piecing together information from various log sources.

In essence, the defensive posture against log-based enumeration boils down to treating log data itself as a sensitive resource. Just as an organization protects its production databases, it must protect the historical record of activity that can reveal the blueprints of its operations.

Key Takeaways

• Logs are a Potent Attack Vector: Cloud logs, primarily designed for defense and monitoring, can be weaponized by attackers for comprehensive, historical enumeration of identities, resources, and permissions across AWS, Azure, and GCP.
• Stealthy Reconnaissance: Log-based enumeration is a "living off the land" technique, leveraging existing cloud features, making it difficult to detect as it involves reading legitimate data rather than performing direct, often noisy, enumeration attempts.
• Granular Information Extraction: Attackers can extract identity types (IM user, IM role, service account, UPN), source IPs, user agents, affected resources, and specific API call parameters from various cloud logs.
• Privilege Inference via Status Codes: By analyzing the success or failure status of API calls in historical logs, an attacker can programmatically infer what permissions an identity has (or had), providing a valuable map of an identity's capabilities.
• Authentication Mechanism Identification: Distinct patterns in sign-in logs (e.g., AWS LoginTo field, FederatedUser ARNs, AWSReservedSSO role names, Entra ID additionalDetails) reveal the authentication flows used, offering insights into an organization's identity management.
• Strict Least Privilege is Paramount: The most effective defense is to apply stringent least privilege principles to log access. Treating log data as a sensitive resource and carefully controlling who can read which logs is crucial to prevent this form of reconnaissance.

About the Speaker(s)

Bleon Proko is a Security Researcher at Exa Force, specializing in cloud security. His primary work involves identifying novel ways to utilize cloud resources as attack vectors and subsequently developing detection mechanisms for them. Proko's research focuses on weaponizing various cloud features, often employing a "living off the land" approach. This talk on log-based enumeration is part of a broader, ongoing research initiative exploring how logs can be leveraged for different types of attacks, including exfiltration, command and control, and infiltration. He has been involved in researching and weaponizing cloud features for several years, demonstrating a deep understanding of cloud provider intricacies and their security implications.