Verifying Credentialed Access to Your Hybrid Cloud Sprawl Matters More Than Ever

Over the few years, the number of assets in our environments has exponentially expanded. This is because of:

• Cloud adoption and migration
• Work-from-home options
• Company growth and expansion

Let’s start with the cloud. Are you there already? Are you moving there? Are you moving back? Why?

Everyone is talking about infrastructure and environments, the cost, the speed – but core to all that incredible capability remains our credentials. The shared security model for our cloud environments is heavily based on credentialed access, which begs the larger question: do you understand the reach (blast radius) in your cloud account if an attacker obtained a credential for a specific user or role?

Why does this matter?

1. Statistics show companies are accelerating and growing their cloud environments:
   1. REF: https://www.grandviewresearch.com/industry-analysis/cloud-computing-industry
   2. REF: https://www.insiderintelligence.com/content/consistent-growth-cloud-spending-defies-down-economy
2. Research indicates attacker trends are conducting malware-less attacks and living off the land more and more:
   1. REF: https://www.crowdstrike.com/resources/reports/overwatch-threat-hunting-report/
   2. REF: https://securityintelligence.com/articles/credential-stuffing-attacks-2021/
3. Autonomous decision-making platforms make this attack vector easier and faster than ever to execute:
   3. REF: https://www.horizon3.ai/

See what we did there?

Background

We’ll start with what is currently the most commonly used cloud service option available, Amazon Web Services (AWS). There are two main types of identities in AWS: users and roles. To authenticate to AWS as a user you must have either:

• the username and password for that user, or
• a set of AWS API keys for that user

Roles operate a little differently and are instead assumed by other AWS services, users, or roles. To assume a role, one only needs to know the account ID and the name of the role. As roles are discovered, these roles could be assumed, allowing attackers to pivot and expand their reach within an AWS account.

Even more interesting is that roles in one AWS account can be assumed by users or roles in another AWS account. This may be common if multiple AWS accounts are tied to a single AWS Organization or in some severe cases any other (unrelated) AWS account.

Credentials

NodeZero, our autonomous attacker, has multiple vectors through which it can discover AWS Account IDs and AWS roles needed to use these new capabilities just like a human cyber threat actor.

NodeZero Discovers AWS Account IDs through:

1. Active or expired AWS keys associated with the account. The user may inject keys when configuring an op, or NodeZero may discover keys during an op.
2. An AWS account ID specified by the user when configuring an op.
3. AWS credentials that have permissions to see other accounts linked in the same AWS organization. The user may inject credentials when configuring an op, or NodeZero may discover credentials during an op.

NodeZero discovers AWS roles by:

1. Using brute force tactics to find valid role names.
2. With an AWS credential that has permission to list roles in an AWS account.

Now for the fun part: chaining these discoveries together.

Attack Path #1

BLUF: In this environment, the cloud domain had a role in its AWS account which was misconfigured to allow any AWS user or role in any AWS account to assume this role.

Using the AWS account ID, NodeZero first enumerates common roles resulting in the discovery of this particular role. NodeZero then attempts to assume this role using its AWS CloudZero keys. Due to the misconfiguration, the ‘assume role’ request is successful and AWS returns AWS temporary keys. This allows NodeZero to then log in with the now compromised role.

Furthermore, with this credential and role, NodeZero was able to compromise AWS services like Beanstalk and Route 53, which could allow an attacker to spin up additional cloud services and instances (e.g., high-end GPUs for crypto-mining or password cracking) on the company dime.

Attack Path #2

This path is much like the previous, but instead of a common role, NodeZero could have discovered a credential elsewhere in the environment (even on-prem), but here a credential was injected to verify the blast radius of a particular credential.

Note: This might be the most valuable perspective in securing your cloud, hybrid, and on-prem environments!

NodeZero was injected with a credential we will call ‘assumable-user’ to keep our stories straight. During the pentest operation, NodeZero found a role in the AWS account that could be assumed by assumable-user. NodeZero then attempted to use that credential to list AWS users and roles, however, assumable-user did not have the required permissions. NodeZero then used the injected credential’s AWS keys to discover the AWS account ID. Using the account ID, NodeZero attempted to brute-force common AWS roles.

In this case, NodeZero discovers the Audit role and then attempts to assume this role with the assumable-user credential. The assumable-user successfully assumed the Audit role, and NodeZero surfaced this weakness to the customer.

What’s interesting here is that the role name can be complicated, so users have another opportunity to confound and limit an attacker.

But they often don’t.

Attack Path #3

If a role was given a complicated name, this will drastically limit the ability for an attacker to assume a role, and therefore compromise additional services in an organization’s private cloud. However, this defensive measure can be circumvented when a credential is compromised.

While it is unlikely an attacker, or even NodeZero, would be able to brute force a complex named role quickly and without drawing attention, if a credential is compromised elsewhere which has access to this AWS account, an attacker can list the roles for that credential in a target account and then easily assume a role now that it knows the name.

The Fix

Horizon3.ai recommends the following steps:

1. Find your hybrid cloud assets, especially those keys stored in reachable files and misconfigured accounts and credentials, and discover attack paths leading them deeper.
2. Fix keys, roles, and credentials and the access to critical data each of them has, especially those on your production cloud environments which could impact your business and brand.
3. Verify your security posture by attacking your hybrid cloud environments, and level up your game by injecting a credential just to see what impact an attacker could levy on your cloud

Conclusion

Credentials are the new RCE – even more so now in our sprawling cloud and hybrid environments. By continuously attacking your cloud environment, you can start fighting through the sprawl and attacking back to find, fix, and verify what matters most.