AWS Key Leak Exposes Data of 1,000+ Charities: A Painful Lesson in Machine Identity Management

A Data Breach That Required No Hacking Wizardry

When we think of cybersecurity incidents, we often imagine attackers wielding sophisticated zero-day exploits or carefully crafted phishing emails to breach defenses layer by layer. But the Beacon CRM data breach reveals a far more unsettling reality: what pierced the data defenses of over 1,000 charities was nothing more than an AWS access key embedded in a publicly accessible JavaScript build artifact.

AWS access keys consist of two parts — an Access Key ID and a Secret Access Key — and serve as the core credentials in AWS Identity and Access Management (IAM) for programmatic access to AWS services. Unlike human users who log into the console with usernames and passwords, these keys are designed specifically for applications and automation scripts. Once someone possesses a valid key pair, they can execute any authorized operation under the identity of the associated IAM entity — no secondary verification required, no manual approval needed.

No phishing attack. No zero-day exploit. Just a machine identity that should never have been there, placed in a publicly visible location. Once discovered, nothing could prevent it from being used to extract data at scale.

What makes this incident terrifying isn't its complexity — it's how ordinary it is. It's not an anomaly; it's the "default outcome" of how most organizations manage non-human credentials today.

Machine Identities: The Overlooked Attack Surface in Cloud Environments

Why Machine Identities Are So Dangerous

With the widespread adoption of cloud-native architectures, microservices, and automated pipelines, machine identities and service identities have far surpassed human accounts in number, becoming the dominant attack surface in cloud environments. According to security vendors like CyberArk, machine identities outnumber human identities by a factor of 45 or more in a typical enterprise environment — and this ratio continues to climb in cloud-native architectures. This means a company with 500 employees might have over 22,000 machine identities, each one a potential entry point for attackers. Yet the vast majority of organizations manage them in an extremely rudimentary fashion.

Compared to human accounts, machine identities suffer from several critical structural problems:

• Almost never rotated: Human passwords typically have mandatory change cycles, but an AWS key might go years without being updated after creation. Many organizations lack even the basic ability to track key age, resulting in massive numbers of "zombie keys" — keys that were created, never used, and never revoked.
• Excessive privilege accumulation: Machine identities often carry permissions far beyond what their original purpose requires. To save time, developers frequently assign broad permissions (such as AdministratorAccess or S3FullAccess), meaning that once leaked, the scope of what an attacker can access is enormous. This phenomenon is known as "privilege creep" in the security world — as projects evolve, permissions only grow, never shrink.
• Scattered in unaudited corners: These keys end up in build artifacts, client-side bundles, CI logs, and other locations that no one thought to audit when the keys were first created.

The Typicality of the Beacon Incident

In the Beacon case, an AWS key was embedded in a publicly accessible JavaScript build artifact — meaning anyone who accessed the website's frontend resources could, in theory, extract the key.

Modern frontend development commonly uses build tools like Webpack, Vite, and Rollup to bundle source code into browser-executable JavaScript files. These build artifacts are ultimately deployed to CDNs or web servers, and any user can view their contents directly through browser developer tools. Even after minification and obfuscation, strings embedded within them — such as API keys and database connection strings — can still be extracted through simple text searches or regex matching. GitGuardian's 2024 annual report shows that over 12 million new hardcoded secrets appear in public code repositories every year, and frontend bundles are among the most frequently overlooked leak channels. This wasn't a covert internal leak — it was a credential exposed on the open internet.

For charities, the data stored in their CRM systems typically includes donor names, addresses, email addresses, phone numbers, donation amounts, bank account or credit card information, and in some cases, highly sensitive data about beneficiaries' health conditions and family backgrounds. In the UK, such data is strictly protected under the Data Protection Act 2018 (UK GDPR), with violations potentially incurring fines of up to £17.5 million or 4% of global annual turnover. Charities typically operate with limited IT budgets and small security teams, relying heavily on SaaS vendors to host and protect their data. This "one falls, all fall" supply chain dependency means a single vendor's credential leak can simultaneously impact over a thousand organizations. The compromise of a single key meant the trust foundation of over a thousand institutions was shaken at once.

The Exposure-to-Discovery Window: The True Hard Metric of Security

Many reports highlight "1,000+ affected organizations" as the headline number of this incident. But from a security practice perspective, an even more alarming figure deserves attention: the time window between when the key was exposed and when someone noticed.

How wide was this window? Wide enough for attackers to complete a full data extraction before any alarm was triggered.

This is the real crux of the problem. Credential leaks themselves may never be entirely preventable, but a mature security posture should be able to raise alerts the moment anomalous access occurs. When a key is used from an unfamiliar IP address, at abnormal frequencies, pulling data volumes far exceeding normal business operations, detection systems should intervene immediately.

In the AWS ecosystem, CloudTrail records all API call logs, while GuardDuty uses machine learning models to analyze these logs in real time and identify anomalous patterns. For example, if a service account that normally only calls S3 GetObject from within a specific VPC suddenly initiates a flood of ListBuckets and GetObject requests from a foreign IP address, GuardDuty would flag it as a potential credential compromise event. UEBA (User and Entity Behavior Analytics) technology has also begun covering machine identities in recent years, with SIEM platforms like Splunk and Microsoft Sentinel offering anomaly detection rule sets specifically for service accounts. However, in the Beacon incident, this line of defense was missing.

Practical Guide to Non-Human Identity Lifecycle Management

Tightening Controls Across Three Dimensions

Drawing from the lessons of this incident, organizations managing non-human identities in production environments should address at least the following areas:

Enforce Rotation and Short-Lived Credentials

Avoid using long-lived static keys. Prioritize short-lived temporary credentials (such as AWS STS, IAM Roles, and OIDC federation) so that even if a key is leaked, it expires quickly.

AWS Security Token Service (STS) is an AWS service for generating temporary security credentials. Through STS, applications can obtain a set of temporary credentials comprising an Access Key, Secret Key, and Session Token, typically valid for between 15 minutes and 12 hours, after which they automatically expire. The companion IAM Roles mechanism allows compute resources such as EC2 instances, Lambda functions, and ECS tasks to securely access AWS resources without storing long-term keys — runtime credentials are automatically injected and rotated by AWS infrastructure, and developers never need to touch the keys themselves. OIDC (OpenID Connect) federation takes this even further, allowing external CI/CD platforms like GitHub Actions and GitLab CI to establish trust relationships with AWS through standard protocols, completely eliminating the need for key storage. This "keyless" architecture is considered the current best practice in cloud security.

For long-term keys that are absolutely necessary, establish mandatory rotation mechanisms with a recommended cycle of no more than 90 days.

Strict Enforcement of the Principle of Least Privilege

Every machine identity should possess only the minimum permissions required to complete its task. Regularly review permission scopes and eliminate "just in case" over-provisioning. Tools like AWS IAM Access Analyzer can automatically generate least-privilege policy recommendations based on actual API call records in CloudTrail logs — reducing a role with S3FullAccess to one with only GetObject permission on specific buckets. This way, even if credentials are leaked, the damage an attacker can cause is contained to the smallest possible scope.

Proactive Secret Scanning and CI/CD Integration

Integrate secret scanning into CI/CD pipelines to automatically detect hardcoded credentials during code commits and build packaging stages. Leading secret scanning tools currently include the open-source Gitleaks, TruffleHog, and detect-secrets, as well as commercial offerings like GitGuardian and GitHub Advanced Security's Secret Scanning feature. These tools use regex matching, entropy analysis (detecting high-randomness strings), and known key format recognition to intercept hardcoded credentials at pre-commit hooks, Pull Request reviews, and build packaging stages. Since 2023, GitHub has enabled push protection by default for all public repositories, blocking pushes when known key formats are detected.

However, it's important to note that many organizations only deploy scanning at the code repository level, overlooking downstream stages such as build artifacts, container images, and log files — and in the Beacon incident, the key was discovered precisely in a build artifact. Therefore, scanning coverage must extend across the entire delivery pipeline. Never let secrets enter client-side bundles or public build artifacts. Also conduct continuous monitoring of already-published resources.

Anomaly Detection: The Last Line of Defense

No matter how thorough preventive measures are, they can never guarantee zero leaks, so anomaly detection must serve as the safety net. Establish behavioral baselines for machine identities, and the moment an abnormal access pattern appears — unusual geographic locations, sudden spikes in data pull volumes, activity outside business hours — immediately trigger alerts or even automated blocking.

In practice, establishing behavioral baselines requires a learning period of at least 2–4 weeks, during which the system records the normal behavioral characteristics of each machine identity: typical API call types, data transfer volume ranges, source IP address ranges, active time windows, and so on. Once the baseline is established, any deviation from normal patterns is flagged as anomalous. Combined with AWS Lambda or Step Functions, organizations can achieve end-to-end automation from detection to response — for example, automatically revoking suspicious keys, isolating affected resources, and notifying security teams — compressing response times from hours to seconds.

Security Fundamentals Worth Industry-Wide Reflection

The Beacon incident is worth discussing repeatedly precisely because it was so unremarkable. It involved no flashy attack techniques, yet it caused enormous impact. This reminds us that security's weakest links are often found not in the most cutting-edge defense technologies, but in the most fundamental credential management practices.

There's a widely circulated saying in the security industry: "Attackers don't need to find the most complex vulnerability — they just need to find the simplest one." The Beacon incident is a perfect illustration. While organizations pour massive budgets into WAFs, IDS/IPS, Endpoint Detection and Response (EDR), and other advanced defense tools, a single key exposed in a public JavaScript file is enough to render all those investments meaningless.

Every organization running a cloud environment should ask itself:

• How exactly are we managing the lifecycle of our non-human identities? Do we have a complete asset inventory covering all service accounts, API keys, OAuth tokens, and certificates?
• Are access scopes strictly constrained? Are there machine identities with admin privileges that only need read access?
• If a key were leaked today, how long would it take us to find out? Once an anomaly is detected, is an automated response mechanism in place?

The answers to these questions are often the true measure of an organization's security posture.

Key Takeaways