Dealing with Storage Data Logs in the Cloud: A Hidden Challenge

Dealing with Storage Data Logs in the Cloud: A Hidden Challenge

Speakers: Maayan Bentor, Cloud Threat Researcher, Wiz; Zoe Rabi, Cybersecurity Researcher, Wiz

Conference: fwd:cloudsec Europe 2025

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

Overview

Maayan Bentor and Zoe Rabi, cloud security researchers at Wiz, delivered a comprehensive cross-cloud analysis of storage data logging — the high-volume, often-neglected logs that are essential for detecting and investigating data exfiltration, ransomware, and storage-level attacks. Walking through real-world attack scenarios across GCP, Azure, and AWS, they demonstrated how attackers exploit storage services and what forensic evidence is (and is not) available in data-plane logs. The talk covered GCP bucket exfiltration via copy operations, Azure blob storage attacks leveraging anonymous access and SAS tokens, and AWS S3 ransomware using SSE-C encryption and mass deletion — all with detailed log analysis showing defenders exactly what to look for.

Background

▶ Watch: GCP blind spots: public objects not tracked, browser downloads redacted in logs (3:30)

Cloud storage services — GCP Cloud Storage, Azure Blob Storage, and AWS S3 — are among the most targeted assets in cloud environments. They hold backups, secrets, customer data, and application state. The management-plane logs (CloudTrail management events, GCP Admin Activity logs, Azure Activity logs) that most organizations rely on capture bucket-level configuration changes but miss the critical data-plane operations: who downloaded what, who copied where, and who deleted which objects.

Data access logs (GCP's storage data access logs, Azure's resource logs, AWS S3 data events) provide this visibility, but they are high-volume, expensive, and not enabled by default in most environments. More importantly, each cloud provider implements data logging differently, with unique blind spots, authentication quirks, and metadata fields that forensic investigators must understand before an incident occurs. The presenters structured the talk around a consistent set of investigative questions applied to each cloud: Is data access logging enabled? Is the storage resource publicly accessible? What authentication method was used? Who accessed it? Which API method was used?

Key Findings

▶ Watch: New GCP metadata.destination field reveals attacker bucket in copy operations (10:00)

GCP: Hidden Limitations in Storage Data Access Logs

GCP's storage data access logs have two critical blind spots that defenders must know about. First, public objects are not tracked in logs — neither anonymous nor authenticated access to publicly accessible objects generates log entries. Second, the authenticated browser download method (using browser cookies to access storage objects) results in redacted logs where the principal information is replaced with a generic @.com identifier, regardless of the actual domain or user.

The presenters demonstrated that the storage.objects.get event in GCP represents three different operations: a console describe (viewing metadata), a metadata get, and an actual download. The key differentiator is the metadata.requestedBytes field — when bytes are present, a real download occurred. For copy operations (the attacker's exfiltration method in the scenario), a new metadata.destination field was recently added by GCP that reveals the target bucket, providing the full forensic context needed to identify cross-bucket exfiltration.

Pre-signed URL access in GCP is identified by a specific authentication pattern in the log that shows the service account that created the signature, but not the end user who used the URL. The real creation context is found in the signBlob event, which shows the compute instance impersonating a service account to generate the signature.

Azure: SAS Tokens as a Persistent Security Risk

The Azure scenario demonstrated how attackers chain anonymous access to discover publicly exposed blob containers, find SAS tokens stored in accessible blobs, and then use those tokens to exfiltrate data from internal storage accounts. The forensic challenge is that SAS token access provides minimal identity information in logs — only IP address and user agent.

The presenters highlighted four properties that make SAS tokens a major security risk: wide scopes (a single token can grant access to an entire storage account), excessive expiry dates (more than 20% of SAS tokens observed in logs have expiration dates more than a year out, with the Microsoft incident token expiring in 2051), weak identity (anyone possessing the token can access storage, with no user identity in logs), and untrackability (Azure provides no native mechanism to list or retrieve all SAS tokens, and many SAS token creations are not logged at all).

Container discovery was demonstrated through enumeration — the attacker guessed container names against a known storage account, generating a pattern of ResourceNotFound errors followed by a successful anonymous access event.

AWS: Rich Context but Recent Improvements

AWS S3 data events provide the highest context of the three clouds, including full session context, request parameters, and additional event data. Notably, pre-signed URL access in AWS is directly identifiable through the authenticationMethod: QueryString field — no need to correlate with a separate signing event.

For the ransomware scenario, the presenters explained how attackers use SSE-C (Server-Side Encryption with Customer-Provided Keys) to encrypt objects in place. The attacker calls the CopyObject API to copy each object to its same location but with SSE-C applied using the attacker's encryption key. Since SSE-C is rarely used in enterprise environments (most use SSE-S3 or SSE-KMS), its presence in logs is a strong indicator of malicious activity.

For mass deletion, AWS recently added individual DeleteObject events for each object deleted through the DeleteObjects (plural) batch API. Previously, only a single event was logged for the batch operation with no detail on which or how many objects were deleted. The new per-object events include a parentRequestId that correlates back to the batch request, enabling full forensic reconstruction.

Technical Deep Dive

▶ Watch: Azure container enumeration pattern — ResourceNotFound errors followed by suc... (12:00)

The GCP exfiltration scenario demonstrated a multi-step attack chain: an attacker compromises an application running on a GCP compute instance, discovers that the application uses pre-signed URLs to access storage buckets, leverages the instance's service account credentials to download objects, and — when a network proxy blocks direct exfiltration — uses the storage.objects.copy API to move data to an attacker-controlled bucket. The forensic trail shows the service account impersonation in the signBlob event and the exfiltration destination in the newly available metadata.destination field on the copy event.

The Azure attack chain exploits the dual-setting nature of public access in Azure Storage: both the storage account and individual containers must explicitly enable public access. The attacker's enumeration generates a detectable pattern of 404 errors followed by successful anonymous access. The real danger materializes when the attacker discovers a SAS token in the publicly accessible blob — the token provides authenticated access to different storage accounts in the same tenant, and the forensic trail degrades to IP-and-user-agent-only identification.

The AWS ransomware scenario chains leaked IAM access keys (permanent credentials for IAM users) with S3 enumeration, SSE-C encryption via CopyObject, and fallback to mass deletion via DeleteObjects when encryption fails. The improved logging now provides per-object deletion events with parent request correlation, giving defenders complete visibility into the destruction timeline.

Demo / Proof of Concept

▶ Watch: AWS ransomware: SSE-C encryption via CopyObject to same location with attacke... (17:30)

The presenters walked through detailed log analysis for each scenario using actual log entries, showing the specific fields, values, and patterns that defenders should search for. While no live exploitation was demonstrated, the log examples effectively served as forensic playbooks for each attack pattern.

Defensive Implications

▶ Watch: New AWS per-object DeleteObject events with parent request ID correlation (20:00)

Across all three clouds, defenders should:

• Enable data-plane storage logging. This is the single most important action — GCP storage data access logs, Azure storage resource logs, and AWS S3 data events must be turned on for any storage containing sensitive data. Without them, most storage-level attacks are invisible.
• Understand the blind spots in each cloud's logging. GCP does not log access to public objects and redacts browser-authenticated access. Azure SAS token access provides minimal identity. AWS previously lacked per-object deletion events for batch deletes.
• Monitor for SSE-C usage in AWS. Enterprise environments rarely use customer-provided encryption keys — SSE-C activity in S3 data events is a high-fidelity indicator of ransomware or data destruction.
• Audit and track SAS tokens in Azure. Since Azure provides no native inventory mechanism, organizations must build their own tracking through logging and policy enforcement. Monitor for SAS tokens with excessive scopes and distant expiration dates.
• Detect container/bucket enumeration patterns. A sequence of access-denied or not-found errors followed by successful access is a reliable indicator of storage discovery attempts.
• Correlate data-plane events with management-plane events for complete forensic context, such as linking pre-signed URL usage to the signBlob creation event in GCP.

Key Takeaways

• Storage data-plane logs are essential for detecting and investigating cloud storage attacks — management-plane logs alone are insufficient.
• Each cloud has unique logging blind spots: GCP omits public object access, Azure SAS tokens provide minimal identity, and AWS only recently added per-object deletion events.
• SSE-C encryption in AWS S3 is a strong ransomware indicator since enterprises almost never use customer-provided keys.
• SAS tokens in Azure are a persistent security risk due to wide scopes, long expiry dates, and the inability to inventory or revoke them at scale.
• GCP recently added a metadata.destination field for copy operations, finally providing the context needed to detect cross-bucket exfiltration.
• Pre-signed URL forensics differ significantly between GCP (requires signBlob correlation) and AWS (directly identifiable via authentication method field).

About the Speaker(s)

Maayan Bentor is a cloud threat researcher at Wiz (previously at Gem Security) with extensive experience detecting and testing advanced threats across AWS, GCP, and Azure. His prior background is in network security research. Zoe Rabi is a cybersecurity researcher on the CDR (Cloud Detection and Response) team at Wiz, where she proactively identifies malicious activity across major cloud providers. She has a background in penetration testing.