The File That Contained the Keys Has Been Removed: An Analysis of Secret Leaks in Cloud Buckets and Responsible Disclosure Outcomes

The File That Contained the Keys Has Been Removed: An Analysis of Secret Leaks in Cloud Buckets and Responsible Disclosure Outcomes

Speakers: Soufian El Yadmani, PhD Researcher, Leiden University

Conference: fwd:cloudsec Europe 2025

YouTube: https://www.youtube.com/watch?v=y1-sVKoQxrw

Overview

Soufian El Yadmani, CEO of Dutch security startup Modat and PhD candidate at Leiden University, presented peer-reviewed academic research analyzing secret leaks in publicly exposed cloud storage buckets across four major providers—AWS S3, Azure Blob Storage, GCP Cloud Storage, and DigitalOcean Spaces. The research analyzed approximately half a million exposed buckets, identified 215 valid credential leaks across 160 organizations, conducted responsible disclosure to all affected parties, and systematically measured how organizations responded to the notifications. The findings reveal that cloud bucket credential exposure remains a pervasive and cross-industry problem, that leaked credentials provide attack paths far beyond the bucket itself (including lateral movement, privilege escalation, and third-party compromise), and that 40% of notified organizations failed to remediate during the research period—with many who did remediate making critical mistakes like deleting the file without revoking the exposed credentials.

Background

▶ Watch: Unit 42 research confirms threat actors actively targeting S3 buckets for cre... (2:00)

Public cloud bucket exposure has been a recurring headline for years, typically framed around PII or PHI data leaks. However, El Yadmani identified a significant gap in existing research: the analysis of credentials stored within exposed buckets and their potential for lateral movement and privilege escalation in cloud environments. Recent work from Unit 42 validated this attack vector, documenting threat actors actively targeting S3 buckets to harvest credentials for further cloud infrastructure compromise. The Shiny Hunters ransomware group was also documented using the same bucket-to-credential-to-infrastructure attack chain. The research was a collaboration between Modat, Leiden University, and TEAFT, and was conducted alongside CERT Global, a Dutch nonprofit that hunts for vulnerabilities and zero-days in internet-facing infrastructure.

Key Findings

▶ Watch: Responsible disclosure response: 60% fixed, but only 19 organizations perform... (8:00)

The research analyzed approximately 500,000 publicly accessible buckets across four providers, with AWS leading in volume. The team targeted specific file types commonly used by DevOps engineers and developers to store credentials: PowerShell scripts, YAML files, JSON configs, batch files, Python scripts, and general configuration files. From these files, they extracted and validated 215 unique credential leaks and successfully attributed 160 to identifiable organizations.

The credential types discovered were diverse: AWS access keys led the findings, followed by GCP service account keys, Slack tokens, Stripe API keys, username/password combinations, Dropbox tokens, GitHub tokens, and CI/CD credentials. Affected organizations spanned every industry and geography—including government ministries, hospitals, police departments, major international banks, and IT companies across the US and globally.

A particularly striking finding was the age of some exposures: files with valid credentials had last-modified dates going back to 2007, yet their owners still actively remediated when notified, proving these weren't abandoned systems. During responsible disclosure, 60% of organizations remediated their exposed credentials, but the remediation quality was often inadequate. Only 19 out of the responding organizations performed all three necessary steps: revoking the credentials, restricting or deleting the file, and securing the bucket. Six organizations restricted the file and bucket but never revoked the tokens, leaving the credentials usable by anyone who had previously harvested them. Some organizations deleted the exposed file only to have it reappear via scheduled tasks or cron jobs that recreated the configuration file with fresh credentials.

Technical Deep Dive

▶ Watch: Remediation monitoring: organizations delete the file but forget to revoke th... (12:00)

The methodology leveraged two data sources. GrayhatWarfare indexes publicly accessible buckets by scraping the internet including GitHub, GitLab, and other sources, attempting to list and index bucket contents. Modat's own internet scanning platform maps IP-connected devices daily, providing a complementary dataset. The team cross-referenced these sources, filtered for target file types, deduplicated results, and validated credential authenticity through controlled testing.

Credential validation was performed carefully—initial validation confirmed the credentials worked, and during responsible disclosure, if organizations requested proof, the team demonstrated access in a controlled manner. The research uncovered several notable attack chains:

Slack token to production credentials: A leaked Slack OAuth token provided access to workspace channels where developers were sharing production environment credentials in plaintext, creating a direct path from a misconfigured bucket to production systems.

CrowdStrike Falcon API access: Exposed credentials provided full access to an organization's CrowdStrike Falcon instance, enabling enumeration of all security rules, policies, endpoints, and analyst email addresses. The email addresses were actually used to identify and contact the affected organization.

Cascading bucket access: A single set of credentials from one bucket provided access to 230 additional buckets containing backups, database exports, and system configurations—a massive lateral movement opportunity from a single credential leak.

GCP service account impersonation: Exposed GCP service account keys enabled impersonation of other accounts with elevated privileges, demonstrating the privilege escalation risk unique to cloud IAM credential exposure.

Admin credentials in scripts: Automation scripts stored in buckets contained not only cloud API credentials but hardcoded Active Directory administrator credentials, bridging the cloud-to-on-premises attack path.

The remediation monitoring revealed concerning patterns. Most organizations that responded did so within 1-2 days, with a second wave of remediations occurring between 7 and 30 days. One particularly illustrative case involved an organization that deleted the exposed file, only for it to reappear shortly after—indicating a scheduled job was regenerating the configuration file with credentials. Cloud provider engagement was minimal; AWS was the only provider to respond to the researchers' reports, stating that bucket security was the customer's responsibility.

Demo / Proof of Concept

▶ Watch: Case study: deleted credential file reappears via cron job with new credentials (14:00)

El Yadmani presented multiple real-world case studies demonstrating the impact of exposed credentials, including accessing CrowdStrike Falcon management consoles, cascading access to 230 additional buckets from a single credential, and sending emails from a security team's SMTP address using exposed AWS SMTP credentials (after the security team initially claimed the credentials were not exploitable). The case studies were drawn from actual responsible disclosure engagements rather than a contrived demonstration environment.

Defensive Implications

▶ Watch: Cascading access: one set of credentials leads to 230 additional buckets full... (16:00)

Organizations should implement automated scanning for publicly accessible buckets in their cloud environments and specifically scan bucket contents for credential material—not just PII or sensitive data. When credentials are discovered in exposed locations, all three remediation steps are essential: revoke the credentials, remove or restrict the file, and secure the bucket. Simply deleting a file is insufficient if the credentials remain valid or if automated processes recreate the file. DevOps teams should audit automation pipelines that write configuration files to storage buckets, as cron jobs and CI/CD processes may continuously republish credentials. Cloud providers should be pressured to take more proactive action on publicly exposed buckets containing credential material, following GCP's model of automated flagging. Organizations should also audit Slack channels and other collaboration tools for credential sharing, as leaked Slack tokens can expose entire production environments.

Key Takeaways

• Cloud bucket credential leaks are widespread across all major providers and affect organizations of all sizes and industries, including government agencies and major banks
• Exposed credentials enable lateral movement far beyond the bucket itself—including access to 230+ additional buckets, CrowdStrike management, Slack channels with production credentials, and GCP privilege escalation
• 40% of notified organizations failed to remediate during the research period, and many who did remediate missed critical steps like credential revocation
• Automated processes recreate credential files after deletion, requiring organizations to fix the root cause (the pipeline) rather than just the symptom (the file)
• Cloud providers offer minimal assistance: AWS explicitly stated that bucket credential exposure is the customer's responsibility
• Legacy exposures still matter: credentials in files last modified in 2007-2015 were still valid and actively used by their owners

About the Speaker(s)

Soufian El Yadmani is the founder and CEO of Modat, a Dutch cybersecurity startup based in The Hague that operates an internet-connected device search engine. He is also a PhD candidate at Leiden University researching threat attribution and hacking automation, and serves as volunteer Head of Research at CERT Global, a Dutch nonprofit focused on identifying and disclosing vulnerabilities in internet-facing infrastructure. The research was published as a peer-reviewed academic paper in collaboration with Leiden University and TEAFT.