The log rings don’t lie: historical enumeration in plain sight

Logs are often celebrated as the defender’s best friend. They are repositories of forensic gold, anomaly detection signals, and accountability. Security teams rely on them to reconstruct incidents, monitor activity, and trigger alerts. But what happens when we flip the perspective? What if an attacker views logs not as a threat, but as an opportunity?

Let’s explore the overlooked offensive potential of logs in cloud infrastructure. Every log entry carries more than just an event; it includes source IP addresses, identities, resource names, request parameters, response codes, user agents, and more. To a defender, these fields are breadcrumbs. But to an attacker, they can be intelligence, pivot points, and even covert communication channels.

We'll dive into how an attacker can use logs to perform enumeration, learning about identities, services, endpoints, and resource hierarchies by analyzing log data. By walking through real-world scenarios, live demos, or simulations (where applicable), this presentation will show just how deep the rabbit hole goes when logs are turned from a defense tool into an attack vector. Finally, we’ll look at practical mitigations: how defenders can detect this kind of misuse, which configurations to avoid, and how to rethink log access and visibility from a zero-trust perspective.

Logs tell the story of our systems. But like any good story, they can be read by anyone, friend or foe. It’s time we start considering that the rings of our digital trees might be telling more than just our history; they might be telling our secrets.

Logging in cloud environments

Due to the sheer amount of services offered by cloud providers and the need for their resources to be monitored, a Security Engineer operating on a Cloud Provider will be faced with a massive amount of different log types and groups. Almost all, if not all, resources on every service will generate logs based on the activities they perform. Some will be generated and managed by the audit log tool of the cloud provider, especially the ones dealing with identity and access management, while others will be generated by the resource in a specific format and retained in cloud storage or a specific storage and querying service.

The table below shows several log sources on AWS, Azure, and GCP. Again, these are not the only log types, just a fraction of all the services and their logs.

As far as this research goes, we will only look into AWS, Azure, and GCP based infrastructure, as the most used cloud providers, but the same logic can be applied to any other cloud provider.

AWS

The two main services that manage events in an AWS Organization or account are AWS CloudTrail and AWS CloudWatch. AWS CloudTrail stores and manages the audit logs, while AWS CloudWatch is a service that allows different log sources to be merged, queried, and dashboarded depending on the need.

The main log service, which also manages the audit logs on AWS, is AWS CloudTrail. AWS CloudTrail logs events related to the AWS API, monitoring all the management activities inside the AWS Organization or account. There are other types of events that get generated, which do not get stored or managed by CloudTrail, such as VPC Flow Logs, serverless execution logs, EC2 instance metrics, Route53 related logs, etc., which can be configured to be stored on S3 Buckets or CloudWatch. Storing events on CloudWatch is more expensive, but allows for easier querying of the events.

AWS CloudTrail

AWS CloudTrail manages logs triggered by events executed using the AWS API and contains information related to the identity, service, and resources being accessed by a specific identity from a specific endpoint. CloudTrail Logs are used as security audit logs, which will allow Security Engineers to monitor activity regarding access an identity has on resources and services throughout an account or Organization. The event below is an example of an AWS CloudTrail event for the creation of an IAM User.

AWS CloudWatch

AWS CloudWatch is a service that collects and manages logs from AWS resources or other parties integrated into AWS. In essence, services hosted and managed in the cloud are just reused on-premise services. This is where the quote “the cloud is just someone else’s computer” comes in. As with previous on-premise services, each of the services comes with its own log formats, not necessarily compatible with AWS log formats. CloudWatch Logs are the response AWS has to these logs. It collects and manages any log from any resource and either formats or encapsulates those events into specific fields, which makes it easier to be managed and accessed by the administrator.

The screenshot below shows the flow of logs for a Lambda function, from the beginning of its execution, up to the output being retrieved.

Not all logs that can be managed by CloudWatch will be managed by CloudWatch. When a resource is created, the creator can choose to send the logs either to CloudWatch or to an S3 bucket. The latter will be cheaper, but will prevent the user from using other features CloudWatch offers, like dashboards. Some other resources, like Lambda functions, will create CloudWatch log groups by default on their creation.

Azure

Azure offers several services split into three major licenses:

• Azure Subscriptions, which include every service allowing deployment and management of cloud infrastructure through IaaS and PaaS solutions
• M365 services, providing SaaS solutions, used to manage user related tasks, such as a mail server, file storage, endpoint and cloud security, DLP, etc.
• Entra ID, which manages the IAM in the cloud, including users, groups, apps, service principals, their roles, and Identity Provider related tasks

Several types of log groups need to be enabled and managed in Azure.

Azure (broad platform / Azure Monitor)

• Activity Log (Platform/Control-plane events) subscription/management-group/tenant level events (resource creation, role changes, deployment failures, service health). Used for auditing control-plane operations.
• Resource Logs (formerly “Diagnostic logs”) per-resource operational logs emitted by Azure services (storage, NSG flow, Application Gateway access/firewall, etc.). Each service exposes its own resource-log categories/schemas.
• Metrics numerical time-series measurements (CPU, requests/sec, latency) emitted by resources; distinct from logs but often ingested alongside them.

Microsoft Entra ID (Azure AD) identity platform logs

EntraID events are managed through the Diagnostic Settings, where the administrator can select the log types to store and the storage method. The events can be stored on:

• Log Analytics
• Storage Accounts
• Streamed into Event Hub
• Sent to any partner solution (usually offered as a service through Azure)

As far as log types go, they include audit logs, signin logs, provisioning logs, network and risk related events.

• AuditLogs - Records administrative actions and changes made to your Entra ID tenant, such as user creation, group modifications, and policy updates.
• SignInLogs - Captures interactive user sign-in attempts including successful logins, failures, and authentication details like location and device.
• NonInteractiveUserSignInLogs - Tracks automated sign-ins performed by applications on behalf of users without direct user interaction, such as token refreshes.
• ServicePrincipalSignInLogs - Records authentication activities of service principals (applications and managed identities) accessing Azure resources.
• ManagedIdentitySignInLogs - Specifically logs sign-in events for Azure managed identities authenticating to services.
• ProvisioningLogs - Documents user and group provisioning activities between Entra ID and connected applications like automatic account creation or synchronization.
• ADFSSignInLogs - Captures sign-in events from Active Directory Federation Services (ADFS) when federated with Entra ID.
• RiskyUsers - Lists users flagged as risky based on detected anomalous behavior or compromised credentials by Identity Protection.
• UserRiskEvents - Details specific risk detections for users such as leaked credentials, anonymous IP usage, or impossible travel scenarios.
• NetworkAccessTrafficLogs - Records network traffic flowing through Microsoft's Global Secure Access (formerly Entra Private/Internet Access).
• RiskyServicePrincipals - Identifies service principals flagged as potentially compromised or exhibiting suspicious behavior.
• ServicePrincipalRiskEvents - Documents specific risk detections for service principals like anomalous sign-in patterns or credential leaks.
• EnrichedOffice365AuditLogs - Provides enhanced Office 365 audit events with additional Entra ID context and enrichment data.
• MicrosoftGraphActivityLogs - Tracks API calls and operations made through Microsoft Graph API for monitoring and security analysis.
• RemoteNetworkHealthLogs - Monitors the health and connectivity status of remote network connections in Global Secure Access deployments.
• NetworkAccessAlerts - Contains security alerts generated by Microsoft's Global Secure Access service for threat detection.
• NetworkAccessConnectionEvents - Records individual connection events and sessions through Global Secure Access network tunnels.
• MicrosoftServicePrincipalSignInLogs - Logs sign-in activities specifically for Microsoft's first-party service principals and internal applications.
• AzureADGraphActivityLogs - Tracks API calls made to the legacy Azure AD Graph API (deprecated, predecessor to Microsoft Graph).
• NetworkAccessGenerativeAIInsights - Provides AI-generated insights and analytics about network access patterns and security posture in Global Secure Access.

Microsoft 365 / Office 365 (audit & service logs)

Microsoft 365/Office 365 provides a wide range of logs that capture user activity, administrative actions, and service-level events across the platform. Understanding these logs is key for compliance, security investigations, and operational monitoring. Below is an overview of the main log types and where they fit within the Microsoft 365 ecosystem.

• Unified Audit Log (Microsoft Purview Audit) central audit store that aggregates activities across Exchange, SharePoint/OneDrive, Teams, Azure AD/Entra, Power BI, Defender, etc. Used for searching user/admin actions across Microsoft 365. Retention/feature depends on license (E5 vs other SKUs).
• Exchange/Exchange Online logs
  
  • Mailbox audit logs mailbox owner/delegate/admin mailbox activities (message reads, send as, folder access).
  • Exchange Admin Audit Log admin changes performed in Exchange admin center or via cmdlets.
  • Message trace/transport logs mail flow records for message delivery and routing.
• SharePoint / OneDrive audit events file/folder access, sharing, sync, and admin changes (surfaced into Unified Audit).
• Teams audit events channel/file/chat/team membership changes, meetings, policy changes (available via Purview Audit).
• Security product logs Defender for Office 365 / Defender for Endpoint / Microsoft 365 Defender produce their own alerts, detections, and telemetry (often integrated into the Compliance/Security center and the unified audit/alerts streams).

GCP

Similar to Azure, Google offers Google Cloud Platform (GCP), which includes the infrastructure side of the cloud deployment and Google Workspace, which include the user related services, such as mail, DLP, Google docs, drive, etc. As such, each one of them will contain different types of logs generated, depending on the type of activity performed.

GCP audit logs (control-plane and data-plane events)

Google Cloud Platform (GCP) provides unified logging through Cloud Logging, which captures activity, system, data, and security events across all services. The primary categories are Audit Logs, which record administrative and data access actions.

• Admin Activity Logs: Control-plane operations (create/update/delete resources). Always enabled.
• System Event Logs: Actions by Google systems on your behalf (e.g., auto-scaling, maintenance). Always enabled.
• Data Access Logs: Data-plane reads/writes (e.g., reading an object from Cloud Storage, querying BigQuery). Must be explicitly enabled due to volume.
• Policy Denied Logs: Records access requests denied by org policy constraints.

Each one of them are configured to be generated and maintained on GCP Projects, Organizations, Billing Accounts and Project Folders.

   projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity
   projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access
   projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fsystem_event
   projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fpolicy

   folders/FOLDER_ID/logs/cloudaudit.googleapis.com%2Factivity
   folders/FOLDER_ID/logs/cloudaudit.googleapis.com%2Fdata_access
   folders/FOLDER_ID/logs/cloudaudit.googleapis.com%2Fsystem_event
   folders/FOLDER_ID/logs/cloudaudit.googleapis.com%2Fpolicy

   billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com%2Factivity
   billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com%2Fdata_access
   billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com%2Fsystem_event
   billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com%2Fpolicy

   organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity
   organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access
   organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fsystem_event
   organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fpolicy

GCP platform logs

Platform logs in Google Cloud Platform capture the operational and performance data generated by the infrastructure and services that run user workloads. Unlike audit logs, which focus on administrative or access actions, platform logs provide visibility into how the system behaves, including network traffic, compute activity, and application performance. Examples include VPC Flow Logs for network flows, Firewall Logs for rule enforcement, Load Balancer Logs for request and latency details, and Cloud NAT Logs for connection tracking. These logs are invaluable for performance tuning, troubleshooting, and detecting anomalies such as unusual traffic spikes or failed connections. By exporting platform logs to Cloud Logging, BigQuery, or SIEMs, organizations can correlate operational data with security and application insights for full-stack observability.

Enumerating cloud permissions using logs

There are many fields containing information about the event executed, the identity executing the event, and the resources being targeted.

• The type, ID, and name of the identity executing the API Call
• The source IP and User Agent of the client executing the API Call
• The resources targeted by this execution
• The input parameters and output values
• Whether the event is allowed or denied

Enumerating resources using audit logs

Each cloud provider audit logs services have a retention period and a way to retrieve those events. Based on the type of log and the cloud provider, it can go from 30 days for GCP events, which can be configured up to 10 years, to 90 days for AWS and Azure, which can be later stored somewhere else, such as cloud storage (S3 Buckets and Azure Storage) or a log analytics service (CloudWatch or Log Analytics).

To list logs, specific permissions are needed:

• AWS: cloudtrail:LookupEvents, lists the retained events
• Azure Cloud Audit Logs:
  
  • Microsoft.OperationalInsights/workspaces/search/action: Executes a search query against a Log Analytics workspace to retrieve log data.
  • Microsoft.Insights/eventtypes/values/read: Reads Activity Log events for a subscription (audit trail of management operations).
  • Microsoft.Resources/subscriptions/providers/read: Lists or retrieves resource providers registered under a subscription.
• Entra ID Audit Logs: AuditLog.Read.All
• GCP: logging.logEntries.list: Lists GCP audit logs for a specific scope

On each audit log, there are some information that can be retrieved from the event:

• Information about the identity that executed the event: Each event will contain information about the identity executing an API call.
  
  • On AWS CloudTrail Logs, it’s the type and the ID of the identity (IAM user or role) (field CloudTrailEvent.userIdentity.principalId), as well as the ARN of the identity executing the permission (field CloudTrailEvent.userIdentity.arn)
  • On Azure Activity Logs, Each event will contain a caller field, which contains the name of the identity executing the call. Then, inside the claims field, we can see the full name (claims.name) and source IP (claims.ipaddr) of the identity. Another field on claims, is http://schemas.microsoft.com/claims/authnmethodsreferences, which lists the authentication methods of the identity executing a call.
  • On GCP Audit Logs, the field authenticationInfo will contain the information about the identity requesting the call.
• Resources being targeted by the execution: Each event affecting a resource (create, update, list, retrieval), will contain a list of those resources on the Resources field. If a resource is not affected, the field will still be present, but empty.
  
  • In AWS, the field is called Resource and it contains the resource name and type for each affected resources

[
      {
          "ResourceType": "AWS::IAM::User",
          "ResourceName": "bleonUser"
      },
      {
          "ResourceType": "AWS::IAM::User",
          "ResourceName": "AIDA***************"
      },
      {
          "ResourceType": "AWS::IAM::User",
          "ResourceName": "arn:aws:iam::012345678901:user/bleonUser"
      }
  ]

• In Azure, the event will contain the resource group field (resourceGroupName), resource type (resourceType) and resource id (resourceId)

"resourceGroupName": "test-resource-group-name",
"resourceProviderName": {
    "value": "Microsoft.Resources",
    "localizedValue": "Microsoft Resources"
},
"resourceType": {
    "value": "Microsoft.Resources/subscriptions/resourceGroups",
    "localizedValue": "Microsoft.Resources/subscriptions/resourceGroups"
},
"resourceId": "/subscriptions/abcd1234-1234-4567-90ab-abcdef123456/resourceGroups/test-resource-group-name",

• GCP also has a field called resource, where information on the affected resources is stored:

"resource": {
  "labels": {
    "email_id": "bsidesnyc-test-account@my-project-12345-123456.iam.gserviceaccount.com",
    "project_id": "my-project-12345-123456",
    "unique_id": "108093650973646504873"
  },
  "type": "service_account"
},

• Another place to look for resources, are the input parameters required by the API call and the output information retrieved by a successful execution. These fields do not only contain resources, but also other custom information like policy documents, or tags.
  
  • AWS contains this information inside requestParameters and responseElements:

"requestParameters": {
  "userName": "bleonUser"
},
"responseElements": {
  "user": {
    "path": "/",
    "userName": "bleonUser",
    "userId": "AIDA***************",
    "arn": "arn:aws:iam::012345678901:user/bleonUser",
    "createDate": "Aug 5, 2025, 8:02:49 PM"
  }
},

• In Azure, depending on the execution, an event will have a request body (requestBody), with the request parameters inside, a response body (responseBody), with the output values, both or neither.

"requestBody": "{\"id\":\"/subscriptions/abcd1234-1234-4567-90ab-abcdef123456/resourceGroups/test-resource-group-name\",\"name\":\"test-resource-group-name\",\"type\":\"Microsoft.Resources/resourceGroups\",\"location\":\"centralus\",\"tags\":{\"SomeKey\":\"SomeValue\"}",

"responseBody": "{\"id\":\"/subscriptions/abcd1234-1234-4567-90ab-abcdef123456/resourceGroups/test-resource-group-name\",\"name\":\"test-resource-group-name\",\"type\":\"Microsoft.Resources/resourceGroups\",\"location\":\"centralus\",\"tags\":{\"SomeKey\":\"SomeValue\"},\"properties\":{\"provisioningState\":\"Succeeded\"}}",

• In GCP, this information is stored on request and response fields

"request": {
  "@type": "type.googleapis.com/google.iam.admin.v1.CreateServiceAccountRequest",
  "account_id": "bsidesnyc-test-account",
  "name": "projects/my-project-12345-123456",
  "service_account": {}
},

"response": {
  "@type": "type.googleapis.com/google.iam.admin.v1.ServiceAccount",
  "email": "bsidesnyc-test-account@my-project-12345-123456.iam.gserviceaccount.com",
  "etag": "MDEwMjE5MjA=",
  "name": "projects/my-project-12345-123456/serviceAccounts/bsidesnyc-test-account@my-project-12345-123456.iam.gserviceaccount.com",
  "oauth2_client_id": "108093650973646504873",
  "project_id": "my-project-12345-123456",
  "unique_id": "108093650973646504873"
},

• Source IP and by extension geolocation of the identity executing the API call, through the source IP field: "sourceIPAddress": "1.2.3.4"
• The Operating System, the context, or the tool being used to achieve a specific task, through the User Agent: "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:141.0) Gecko/20100101 Firefox/141.0

Enumerating identity permissions by checking permission addition

Each cloud provider can be accessed using the API. In order for an identity to be able to execute a task, it needs to have access to that task. Access to a service, resource, or just a simple API call is given through Roles (on Azure and GCP) and Policies (on AWS).

When a privilege is added to an identity, an event is triggered. These events are usually considered to be high priority, administrative events, so every cloud provider will log them.

Aside from the API privilege addition, some resources will also contain access policies. These policies will allow or deny access to a resource of a service from an identity, even though they might have access to execute tasks on the other resources of that service.

Enumerating identity permissions by iterating security logs

Permissions the identity will have on an API Call. Each API call will have 2 fields called errorCode and errorMessage. errorCode will give a reason why the execution failed, while the errorMessage will give a description of the error. In case an API call is not allowed to be executed, the field errorCode will have a value of AccessDenied.

"errorCode": "AccessDenied",
"errorMessage": "User: arn:aws:iam::012345678912:user/attacker is not authorized to perform: iam:CreateUser on resource: arn:aws:iam::012345678912:user/someuser with an explicit deny in a service control policy"

If the errorCode value is not AccessDenied, there is a high chance the permission is allowed. And since CloudTrail logs, when retrieved from both Event History and then S3 Bucket are ordered in a descending order, from newest to oldest, we can iterate through them and see the newest error on each of the events.

• If the errorCode value is AccessDenied, and the event has not been allowed before, it means the event is denied.
• If the errorCode value is AccessDenied, and the event has been allowed before, it means the permission is allowed.
• If the errorCode value is not AccessDenied, and the event has not been denied before, it means the permission is allowed.

Knowing this principle, we can enumerate any identity on the Account, just by using one API call cloudtrail:LookupEvents.

Drawbacks to enumerating permissions using AWS CloudTrail logs

The drawback to using this enumeration technique lies in the time between a permission being allowed or denied and the time it takes to execute. The problem occurs when a permission has been added or revoked after the event has been generated. This happens a lot, especially with temporary privileges, where an identity is allowed access to a specific privilege only for a specific timeframe. The attacker will retrieve the events, thinking the target identity has access to execute a task, when, in fact, they do not have access.

Enumerating identities using sign in logs

Each time a user logs into a cloud environment, a sign-in event is triggered. The log will contain information about the user that logs in.

• Identity logging in
• Source IP
• Authentication mechanism (if they are using SSO, federation, MFA)
• Some might contain User Agents

An attacker with access to read signin logs on a cloud provider can get:

• A list of identity names and authentication mechanisms they are using (including MFA)
• A list of identities that are enabled or not
• A list of reasons why the signin failed
• A list of potential locations from where the identity originates
• A list of IPs that the identity uses.

AWS sign in event

AWS offers different ways to access the Management Console:

• An AWS User Login Profile. Users with a Login Profile can login to the Management Console and get GUI access on the account through it.
• IAM User Federation credentials creating a signin URL (as explained here)
• Login through the AWS Identity Center, where a user will login using credentials or through an IDP and a role will be associated with them, which will allow management access on the Management Console.

When a user is logged into the AWS Management Console, the event triggering will be signin:ConsoleLogin. The event will contain the identity logging in, information about the source IP, User Agent, AWS Account.

• Logging in as an IAM User through the Login Profile, the identity executing the call, will contain the ARN of an IAM User (userIdentity.arn field has format a of arn:aws:iam::012345678912:user/loginUser).
• The User Agent will be a browser (Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:143.0) Gecko/20100101 Firefox/143.0), as the login will be done through one
• On the additionalEventData field, we will also see the console login URL that was used to login, as well as information about MFA usage.

"additionalEventData": {
  "LoginTo": "https://console.aws.amazon.com/console/home?hashArgs=%23&isauthcode=true&state=hashArgsFromTB_us-east-2_addce6de859630d0",
  "MobileVersion": "No",
  "MFAUsed": "No"
},

If a user is logged in through a federated credential, the ARN of the user will contain a format of arn:aws:sts::012345678912:federated-user/loginUserSessionName. The source of the event will be STS, as the credentials will have been retrieved from sts:GetFederationToken.

Also, additionalEventData will not contain any LoginTo field, as the identity does not necessarily need to have a Login Profile to access the Management Console.

"additionalEventData": {
  "MobileVersion": "No",
  "MFAUsed": "No"
},

Lastly. when an identity logs in through the Identity Center, the identity executing the login will be a role, with a session name that is the same as the mail name of the user logging in (arn:aws:sts::0123456789012:assumed-role/AWSReservedSSO_AdministratorAccess_abcdef1234567890/someuser). On Identity Center, each user has access to only one role (unless configured differently), and the session name will be the session name of the user logging in. The most common format of the role name is AWSReservedSSO_AdministratorAccess_abcdef1234567890, though it can be configured to be anything when Identity Center is created.

Entra ID sign in logs

For Azure, the authentication is done through Entra ID. When trying to log in, each event will contain a status and the Sign-In logs in it will have a status field, where the error code (status.errorCode) and the reason for success or failure (status.additionalDetails) will be stored. The status reason will contain a description of the reason the signin was accepted or not. Some of the reasons might be:

• Expected - auth codes, refresh tokens, and sessions expire over time or are revoked by the user or an admin. The app will request a new login from the user.
• Have the user retry the sign-in and consent to the app.
• Invite the user to the tenant, or ignore this error if the user isn't supposed to be a member of the tenant. This can be the case when someone is sent to a login URL for your tenant without being a member, or picks the wrong user account.
• MFA completed in Azure AD
• MFA requirement satisfied by claim in the token
• No action required, this is expected as part of determining device identities due to application or conditional access requirements.
• The user didn't complete the MFA prompt. They may have decided not to authenticate, timed out while doing other work, or has an issue with their authentication setup.
• The user didn't enter the right credentials. It's expected to see some number of these errors in your logs due to users making mistakes.
• The user was presented options to provide contact options so that they can do MFA.
• This is an expected part of the login flow, where a user is asked if they want to remain signed into this browser to make further logins easier.
• User authentication was blocked because they need to provide password reset information.
• Their next interactive sign in will ask them for this, which the app should trigger next.
• User needs to perform multi-factor authentication. There could be multiple things requiring multi-factor, e.g. Conditional Access policies, per-user enforcement, requested by client, among others.

One other information that is stored on the event, is the location information. Azure will calculate the location based on the IP and ASN from where the request came and give that information.

"location": {
  "city": "Some City",
  "countryOrRegion": "US",
  "geoCoordinates": {
    "altitude": null,
    "latitude": 12.3456,
    "longitude": 65.4321
  },
  "state": "State"
},

Google sign in logs

Google logs the signin events for its users on the organization’s Data Access logs ("logName": "organizations/123456789012/logs/cloudaudit.googleapis.com%2Fdata_access”) under the type AuditLog ("protoPayload.@type”: "type.googleapis.com/google.cloud.audit.AuditLog") and "serviceName": "login.googleapis.com”.

Google allows filtering of logs by success or failure using the protoPayload.methodName field

• google.login.LoginService.loginSuccess
• google.login.LoginService.loginFailure

Failure reasons:

"event": [
  {
    "eventName": "login_failure",
    "eventType": "login",
    "eventId": "3484ada0",
    "parameter": [
      {
        "label": "LABEL_OPTIONAL",
        "value": "reauth",
        "type": "TYPE_STRING",
        "name": "login_type"
      },
      {
        "multiStrValue": [
          "none"
        ],
        "type": "TYPE_STRING",
        "label": "LABEL_REPEATED",
        "name": "login_challenge_method"
      },
      {
        "name": "dusi",
        "value": "INjZurSThIbFLg",
        "type": "TYPE_STRING",
        "label": "LABEL_OPTIONAL"
      }
    ]
  }
]

The other side of visibility

Logs remain essential to security operations. There is no debate about their value in detection, response, and forensic investigation. But as we've explored throughout this research, every capability that makes logs powerful for defenders also makes them valuable for attackers. The same granularity that enables precise incident reconstruction also enables reconnaissance. The same accessibility that supports rapid threat hunting also supports covert enumeration. The uncomfortable truth is that logs are a shared resource in adversarial space. Once an attacker gains initial access with sufficient permissions to read logs, they inherit a ready-made intelligence platform built and maintained by the organization itself. CloudTrail, Azure Monitor, Cloud Logging weren't designed assuming the reader might be hostile, but in breach scenarios, that assumption fails catastrophically.

Logs tell the story of our systems. But stories can be read, misread, or exploited by anyone with access. The techniques demonstrated here, are not just theoretical curiosities, but rather they are practical, effective, and increasingly understood by sophisticated threat actors. Visibility is a double-edged sword, and the defender's best friend can become the attacker's silent partner unless we start treating log access with the gravity it deserves.

So, what is the solution? Should we not log at all, so we can blind the attackers, at the tradeoff of blinding defenders as well? Of course not. But some limits should be set. The best advice against this type of attack, while easier said than done, is to apply least privilege. Log retrieval is a task that gets executed by many identities, both programmatically or not, which makes it harder to limit. Logs contain data. The data logs contain identity information, user agent, IP related, input and output parameters, etc. This data is valuable to defenders and threat hunters, but it is also important for an attacker.

This means applying least-privilege rigorously to log access, treating read permissions as seriously as write permissions. It means segmenting log storage so compromise of one environment doesn't expose telemetry from others. It means monitoring log queries themselves, creating detection rules for anomalous access patterns, and regularly auditing who can read logs and why. Every service account with logging permissions, every identity with CloudTrail access, every role with logging.viewer, should be justified and reviewed, not granted by default.