Stories from the Darkside: A Set of Stolen Access Keys and a Complete Cloud Takeover

The simplicity of this attack isn’t what makes it shocking. It’s not even the speed with which the attacker seized control of an entire cloud environment. The alarming part is that it didn’t take advanced techniques to break in. The mistakes that allowed this to happen? Well, they happen. All. The. Time.

So what should we have done to prevent the attack? Let’s first look at how it unfolded.

The Attack Breakdown

Launching a brute-force attack on a user account with weak credentials, the attacker gains access to the system. Once inside, they locate a JSON file on the disk that contains an access key. They copy this key to their system, and using the stolen key, they successfully authenticate.

In the environment, the attacker discovers that the compromised service account has overly permissive access, including owner permissions. The excessive level of permissions exposes the system, particularly because it should never be granted to a service account (machine access).

Seizing the opportunity, the attacker writes a script designed to download all the data available in cloud storage. They begin enumerating serverless function environment variables, as these often contain sensitive information that could advance the attack.

Having uncovered valuable details — access tokens or configuration data — the attacker uses the owner's permissions to move laterally through the system, targeting virtual machines. Along the way, they find a shared jumpbox used by multiple users, which contains cloud credentials for various users, significantly widening the attack surface.

At this point, the attacker spots their target — an account with owner permissions to critical areas. It's linked to human resources, sales and IT projects. They seize control of the account and with a few swift commands, the entire cloud environment falls under their control.

Breaking Up This Attack Path

Many interconnected risks, rather than one, led to the success — and magnitude — of this attack. Let’s take a look at the various components and what security measures and best practices could have prevented or limited the damage.

IAM and the Principle of Least Privilege

According to a recent Microsoft report, more than 50% of identities are super admins — users or workloads that have access to all permissions and resources. Nothing says we have an urgent need to reassess access management policies to protect sensitive data and infrastructure like the absence of foundational IAM best practices.

In the attack breakdown, the attacker leverages a compromised service account with overly permissive access. This highlights a critical flaw in identity and access management (IAM) — ignoring the principle of least privilege. The least privilege principle dictates that each user or service should only have the minimum permissions necessary to perform their role. Excessive permissions, like the owner permissions granted to the service account, create an attack surface inviting exploitation.

To prevent attacks like this, security teams must enforce least privilege policies across all accounts, especially service accounts (machine users), which are often overlooked and pose a significant risk when granted broad permissions. With this attack, the service account could perform actions beyond its scope, such as accessing sensitive data — and inadvertently allowing the attacker to move laterally within the environment.

Actionable IAM Guidelines

1. Understand the net-effective permissions assigned to identities: Can you definitively say who has access to what? Unless you have complete visibility across your cloud ecosystem, it’s unlikely you have access to each user’s (human and machine) net-effective permissions, considering that each CSP has its own unique IAM policy framework and user IdPs.

Related Article: Why Are Net-Effective Permissions Critical for Cloud IAM?

1. Conduct regular audits of all permissions, focusing on service accounts. Remove any excessive or unnecessary permissions that don’t align with the account’s intended purpose.
2. Use role-based access controls (RBAC) to assign permissions based on specific roles. Ensure service accounts only have access to resources needed for their function, and nothing more.
3. Implement time-bound or just-in-time access for high-privilege accounts. In cases where elevated privileges are required temporarily, limit the window of time for those permissions.

Least-privileged access could have prevented the attack from escalating. Even if the initial brute-force attack succeeded, limited permissions would have stopped the attacker from downloading sensitive data or moving laterally across the environment.

Multifactor Authentication (MFA)

The attack began with a brute-force attack on a weak user password, exposing a vulnerability that could have been neutralized by multifactor authentication (MFA). Had MFA been enforced, the attacker would have needed a second form of authentication to access the environment, making a successful brute-force attempt less likely.

MFA could have minimized damage at several key stages of the attack:

1. Initial entry: Enforcing MFA on all user accounts, especially those with access to cloud resources, would have blocked the attacker from logging in with stolen or guessed credentials.
2. Lateral movement: MFA combined with role-based access control could have been applied to sensitive areas, such as virtual machines or data storage. Each attempt to move laterally would require additional verification, significantly slowing the attacker’s progress.
3. Account takeover: If MFA was required for high-privilege actions, like accessing the HR, sales or IT projects, the attacker would have been stalled or blocked from taking full control of the environment.

Actionable MFA Guidelines

• Mandate MFA for all cloud access: Every user account, including service accounts where applicable, should require MFA to authenticate.
• Ensure MFA is used for sensitive actions: Activities such as changing permissions, accessing sensitive data or performing administrative tasks should trigger an MFA prompt.
• Regularly test MFA setups: Conduct phishing simulations and test MFA systems to ensure they are working effectively and that users understand their importance.

By enforcing MFA, the attacker’s ability to gain access to the environment and escalate privileges would have been significantly hindered, likely stopping the attack before it began.

Data Security Posture Management (DSPM)

Once inside the system, the attacker wrote a script to download data from cloud storage, exploiting the lack of data security controls, emphasizing the need for data security posture management (DSPM) technology and strategy.

In this attack, cloud storage permissions were left wide open, and sensitive data was easily accessible once the attacker gained the required permissions. DSPM tools continuously monitor and assess data storage systems to ensure that sensitive data is protected, access is limited, and anomalies are quickly identified.

Actionable DSPM Guidelines

1. Classify and tag sensitive data: Security teams should properly classified and labeled data in the cloud, as it allows for better management of access controls, encryption and monitoring.
2. Enforce strict access controls on storage: Storage buckets and databases should be accessible only by specific roles. Public or overly permissive access to cloud storage is a critical vulnerability.
3. Monitor and alert on abnormal activity: DSPM solutions can flag unusual data download patterns or bulk access to storage resources, which would have detected the attacker’s script downloading large amounts of data.
4. Encrypt sensitive data at rest and in transit: Encryption adds another layer of security, ensuring that even if the attacker accessed the data, they wouldn’t be able to easily read or use it.

A proactive DSPM strategy would have raised red flags the moment the attacker began accessing cloud storage, allowing the security team to respond before the data could be fully compromised.

Detect Malicious Activity and Respond

One of the most critical failures in the attack was the lack of monitoring for anomalous behavior. Threat detection leveraging user and entity behavior analytics (UEBA) could have detected several suspicious actions early in the attack, long before the attacker took control of the cloud environment.

UEBA works by establishing a baseline of normal user and system behavior, then flagging any deviations from this baseline as potential threats. In this attack, several activities would have triggered alerts:

1. Brute-force login attempts: UEBA would have detected multiple failed login attempts of a legitimate user account and immediately flagged the activity as suspicious. It could have blocked or quarantined the account until verified by the security team.
2. Access to unusual resources: The attacker accessed a JSON file containing an access key, which may have been outside the typical usage for the compromised account. UEBA would detect such unusual file access and trigger an alert.
3. Unusual data downloads: When the attacker began downloading data from cloud storage, UEBA would have flagged the activity as abnormal, especially if it deviated from typical usage patterns for the service account.

Actionable Guidelines for Anomaly Detection

• Deploy UEBA tools that monitor across the entire cloud environment: ‘Entire environment’ includes IAM activity, storage access and application behavior.
• Set up alerts for anomalies: Configure alerts for any deviations from baseline behaviors, such as unexpected login attempts, data access or permissions changes.
• Conduct regular behavior analysis: Regularly review and update the baseline behaviors to adapt to evolving business needs and emerging threats.

UEBA could have stopped the attack early by detecting the brute-force attempt or unusual data access patterns. Implementing UEBA as part of a broader monitoring strategy ensures that even when an attacker slips past traditional defenses, their actions will not go unnoticed.

Cloud Security Platform Reduces Risk and Eliminates Breaches

The highlighted attack underscores the persistent and evolving threats in cloud environments, as well as the importance of rigorous and proactive security.

Prisma Cloud empowers organizations to get ahead of threat actors and effectively reduce security incidents, including data breaches. By integrating comprehensive security measures across the application lifecycle, the Code to Cloud^TM platform enables teams to ship secure code from the outset, fortify application infrastructure, and stop sophisticated attacks in real time. Leveraging Precision AI^TM, Prisma Cloud proactively identifies vulnerabilities — enforcing best practices — and ensures continuous compliance.

Learn More

For more IAM best practices, check out our infographic CIEM: Identity Is the New Perimeter. And if you haven’t tried Prisma Cloud and wonder how our Code to Cloud^TM platform could have helped you prevent this attack, consider booking a personalized demo or registering for a free 30-day Prisma Cloud trial.