When a customer notification from AWS landed at a U.S. organization warning that an access key had been exposed, the internal alert that arrived minutes later was worse: CloudTrail logging had been disabled. Credential compromise combined with logging disruption often indicates that an attacker obtained access to the environment and attempted to remove forensic visibility. The investigators had a problem familiar to anyone who has worked a cloud breach — the logs that would tell them what happened had become part of what happened.
Cloud audit logs are the closest thing to a black-box recorder that exists for a modern enterprise environment. They are also the most commonly misunderstood evidence source in incident response, because what gets captured by default versus what requires explicit configuration differs across providers, across services within a provider, and even across log types within a single service. This article walks through what AWS, Microsoft, and Google actually record, what they don’t, and where the seams between control plane and data plane create gaps investigators repeatedly fall into.
The Control Plane Is the Default — and the Limitation
Every major cloud provider distinguishes between two categories of activity. Control plane events are API calls that change configuration: creating an EC2 instance, modifying an IAM policy, deleting a storage bucket, rotating a key. Data plane events are interactions with the data those resources hold: reading an object from S3, querying a BigQuery table, opening an email message in Exchange Online.
The default-on logs across all three providers cover the control plane. AWS CloudTrail records AWS API calls at the management event level, by default, and data event level, if configured. Google Cloud’s Admin Activity audit logs are log entries written by user-driven API calls or other actions that modify the configuration or metadata of resources, and crucially, Admin Activity audit logs are always written; you can’t configure, exclude, or disable them. Azure’s equivalent — the Activity Log — captures subscription-level management operations with similar always-on semantics.
This is a deliberate design choice, and a useful one. CloudTrail captures control plane activity, which is where most cloud attacks occur, because cloud-native attacks generally manifest as API misuse: a stolen access key calling CreateUser, an over-permissioned role calling AssumeRole across accounts, a service account being granted impersonation rights it shouldn’t have. Control plane logs answer the question “who did what to which resource” with rich identity context.
But control plane logs cannot tell you what data was read. They cannot tell you which file an attacker downloaded, which mailbox they accessed, or which database row they exfiltrated. For that, you need the data plane logs — and those, almost universally, are not on by default.
What Each Provider Actually Captures
The structure is parallel across providers but the defaults differ in ways that matter operationally. The table below is the reference investigators reach for when scoping what evidence even theoretically exists for a given incident.
The pattern that emerges from this table is the most important fact about cloud forensics: the cheap, default logs tell you about identity and configuration; the expensive, opt-in logs tell you what happened to your data. Most organizations that suffer breaches discover the second category was never enabled.
The Anatomy of a Single Audit Event
A CloudTrail record — and its rough equivalents in other clouds — captures more than most investigators initially realize. When a role is assumed in your account from another AWS account, a log is fired off in both accounts, and they’re joined by a sharedEventID. This is a very useful forensic artifact. That cross-account correlation is gold during multi-tenant or supply-chain investigations, because it lets a victim and a cooperating partner — or law enforcement with a warrant — bind activity across accounts that otherwise look unrelated.
Each event typically includes the calling identity (IAM user, role, federated principal, or service account), the source IP, the user-agent string, the API name, request parameters, response elements where applicable, and a timestamp. In Google Cloud, audit logs record the identity of the entity performing operations on a Google Cloud resource. The caller’s identity is stored in the authenticationInfo field of the AuditLog objects, and that field carries detail down to service-account delegation chains and third-party identity provider information for federated logins.
What investigators need to internalize is that the user-agent string and source IP are often the most useful fields, even when identity is known. A legitimate IAM role being called from an unfamiliar IP via the AWS CLI when the same role is normally only invoked from the AWS console by a Lambda runtime is a high-confidence signal of stolen credentials. When searching CloudTrail logs or interactions with the S3 bucket within the time frame of the attack, the event log indicates that the user agent who generated the event is an AWS CLI user agent, which is an anomalous behavior— that is a real pattern Wiz has documented in container-compromise investigations, and it generalizes across providers.
The Microsoft 365 Unified Audit Log: A Different Beast
Microsoft’s logging architecture diverges from AWS and GCP in ways worth flagging because investigators trained on cloud IaaS often get tripped up on M365.
The Unified Audit Log (UAL) is the central evidence repository for activity across Exchange Online, SharePoint, OneDrive, Teams, and Entra ID. There are over 3,500 different operations in the Unified Audit Log. The UAL contains all Office 365 data, including interactive sign-ins and Azure AD admin activity. Keep in mind that non-interactive, service principal and managed identity sign-ins do not appear in the UAL. That last sentence is the trap. Token-based attacks — where an adversary obtains a refresh token or service principal credential — generate sign-ins that are invisible in the UAL and must be hunted in the Entra ID sign-in logs separately.
Retention is also asymmetric. UAL data is retained for 90 days by default, and 365 days for E5/F5/A5/G5 licensed customers or customers with the correct add-on package. For mailbox-level forensics, the MailItemsAccessed event is the closest M365 gets to per-message data plane logging, but it has a known failure mode: if a mailbox is throttled, you can probably assume there was MailItemsAccessed activity that wasn’t recorded in the audit logs. Attackers running automated mailbox scrapers can deliberately or incidentally trigger that throttling, leaving investigators with confirmation that something happened but no per-message detail.
Operationally, UAL features a time lag for audit logs. Depending on the platform, delays can range from 30 minutes to 24 hours. Real-time response off UAL alone is impossible; investigators routinely pair it with Entra ID sign-in logs and Defender for Cloud Apps to fill the gap.
Network and DNS: The Forgotten Layer
Audit logs are not network logs. This sounds obvious, but it is the single most common scoping failure in cloud incident response. Coralogix’s recent post-incident review of six common AWS investigation scenarios identified the same pattern repeatedly: a GuardDuty alert fires on suspicious egress, the team pulls CloudTrail and finds nothing useful, and only then discovers the most important log source, VPC Flow Logs, was never enabled for the VPC. As a result, they have no way to determine which internal resource is responsible for the traffic.
VPC Flow Logs (and their Azure and GCP equivalents) capture connection-level metadata: source and destination IPs, ports, protocol, byte and packet counts, and whether the flow was accepted or rejected. They do not capture packet contents. For exfiltration scoping, this is usually enough — knowing that 47 GB left a specific instance toward a specific IP over a specific six-hour window is what you need to bound a breach disclosure.
DNS logs sit one layer up. The absence of Route 53 Resolver query logs created a critical visibility gap, obscuring the adversary’s DNS infrastructure and severely slowing down containment. The team could identify which instance was generating suspicious DNS traffic, but not the domains being contacted. Without this data, they also could not analyze for techniques such as DNS tunneling, where attackers embed exfiltrated data within DNS queries themselves. Modern command-and-control increasingly relies on DGA-generated domains and DNS over HTTPS, both of which are invisible without resolver-level query logging.
Integrity, Tamper Evidence, and the Adversary’s Counter-Move
A log is only forensically useful if you can demonstrate it wasn’t altered. Sophisticated attackers know this, and disabling or corrupting audit logs is a documented MITRE ATT&CK technique (T1562.008, Disable or Modify Cloud Logs).
AWS’s response is CloudTrail log file integrity validation. This feature is built using industry standard algorithms: SHA-256 for hashing and SHA-256 with RSA for digital signing. This makes it computationally infeasible to modify, delete or forge CloudTrail log files without detection. Each digest file also contains the digital signature of the previous digest file if one exists — a hash chain that turns the digest stream into a tamper-evident ledger. If an attacker deletes a log file, the next digest fails validation; if they delete a digest, the chain breaks at that point and the gap is provable.
Google Cloud takes a different architectural approach: log entries written by Cloud Audit Logs are immutable, and Admin Activity audit logs and System Event audit logs are always stored in the _Required bucket in the project where the logs were generated. The bucket has fixed 400-day retention that cannot be modified by customers, and Admin Activity logs cannot be disabled even by project owners. The attacker’s path to destroying GCP control-plane logs runs through compromising Google itself, not the customer tenant.
This is also why the AWS investigation that opened this article is instructive. The attacker attempted to cover their tracks by disabling CloudTrail logging through administrative API calls such as DeleteTrail. Disabling audit logging is a common defense evasion technique used to reduce forensic visibility and hinder incident response investigations. The DeleteTrail call itself is logged — but only up until the trail stops delivering. The window between trail deletion and detection is the attacker’s working time, which is why monitoring for StopLogging, DeleteTrail, and UpdateTrail API calls belongs in every cloud SIEM rule set, alongside their Azure and GCP equivalents.
diagnosticSettings/delete
logging.sinks
-UnifiedAuditLogIngestion $false
filter exclusions
(IsLogging:false)
Association
aggregated sinks
(scope reduction)
-AuditEnabled $false
(remove log types)
What Investigators Should Pull First
The triage order is roughly the same across providers, even when the tooling differs. Identity comes first — sign-in logs, federation events, and any API calls under iam, sts, or their equivalents. Then control-plane changes during the suspected window: new principals created, permissions granted, resources deployed in unexpected regions. Then network telemetry: VPC Flow Logs and DNS query logs to scope blast radius. Finally, data-plane access logs if available, to determine what was actually read or moved.
Sygnia’s GCP triage methodology captures this sequence cleanly: After reviewing alerts, the identity logs (User log, Admin log, SAML log, etc.) will help to pinpoint any abnormal access into the Google Cloud domain. Once the affected identities have been scoped, identifying actions taken within GCP itself is observable in the Security and Platform logs. More specifically, begin by examining the default enabled Admin Activity audit log for GCP resource modifications and the Data Access audit log (if available) for user-driven resource access. The phrase “if available” is doing a lot of work in that sentence, and it’s the right framing — half of what you want to look at probably wasn’t recorded.
Two practical points often missed. First, the AWS console only shows 90 days of CloudTrail history and caps exports at 50 events per query, which makes it useless for any investigation older than a quarter or wider than a few hundred events; to extend the retention of the logs past 90 days, you need to configure a trail to send the logs to an S3 bucket, and that S3 bucket needs to be in a separate, locked-down logging account. Second, CloudTrail logs land in S3 every 15 minutes, not in real time, so a fast-moving attacker’s last 15 minutes of activity may not be evidentially recoverable if the trail is destroyed before delivery.
FAQ
How long are cloud logs actually retained by default? It varies sharply. AWS shows 90 days of CloudTrail in the console; persistent storage requires a configured trail to S3, where you control retention. Microsoft 365 retains UAL data for 90 days under Audit Standard, extended to 365 days for Entra/Exchange/SharePoint records under Audit Premium. Google Cloud retains Admin Activity logs for 400 days in a non-modifiable bucket, but Data Access logs default to 30 days and require routing to extend.
Can a cloud provider give me logs about my account if I didn’t enable them? Generally no, with narrow exceptions. Providers retain some metadata for billing and operational purposes, and law-enforcement requests can sometimes reach data customers cannot. But “we’ll just ask AWS for the logs” is not a recovery plan. If you didn’t enable the log, assume it doesn’t exist.
What about logs for managed services I don’t operate? This is the shared-responsibility seam. The provider logs their plane (hypervisor, control plane, network fabric) and exposes some of it to you; you log your plane (workloads, applications, data access). For managed databases, serverless platforms, and SaaS workloads, you get only what the provider chose to expose. Fully-managed offerings tend to have less granular customer-visible logging than their IaaS equivalents.
Are control-plane logs admissible as forensic evidence? With proper integrity controls, yes — and providers explicitly position them as such. Validated log files are invaluable in security and forensic investigations. For example, a validated log file enables you to assert positively that the log file itself has not changed, or that particular user credentials performed specific API activity. The chain-of-custody work is on the investigator: documented collection procedures, hash verification at acquisition time, and storage in a locked bucket separate from the production environment.
The Real Problem Isn’t Capture, It’s Configuration
Cloud providers have built genuinely sophisticated audit infrastructure. Tamper-evident logging, cross-account event correlation via shared event IDs, immutable storage for control-plane events, and identity context that on-prem environments never had access to — all of this exists and works.
The reason cloud forensics still routinely fails is that the most evidentially valuable logs are opt-in, generate cost, and tend to be enabled in response to incidents rather than in anticipation of them. By the time you need S3 data events, EKS audit logs, or Route 53 Resolver query logs, it is generally too late to enable them. The investigation you can run is bounded entirely by the logging configuration that existed when the attack started.
The practical implication for security teams is that “what does our cloud provider capture?” is the wrong question. The right question is “what have we configured them to capture, where is it stored, who can delete it, and how long does it live?” That is an answer your tenant can give you in an afternoon — and the answer is almost always less than you assumed.
