What is a cloud identity?

If someone was using your cloud identity right now, how would you know?

What do we even mean when we refer to an identity in the cloud? My first thought was that it’s like your license or ID—something to show who you are. But it’s actually a little more complicated than that.

It’s easier to understand cloud identity when you compare it to a system rather than one tangible thing; for example, airport security.

Last week, I flew to Baltimore from Boston. When I arrived at the airport, I showed the transportation security officer my boarding pass with my name, airline, and assigned seat.

He glanced at my pass and said, “You’re in the wrong terminal. JetBlue is on the other side of the airport.”

He directed me to the right area, where another security officer confirmed I was at the right place and checked to make sure my pass had the TSA PreCheck symbol, before allowing me to enter the designated security line. When I reached the front of the line, another employee scanned my license to ensure it was valid and that my face matched my picture before I was allowed to walk through the full body scanner. And then I still needed my boarding pass one more time to get onto the airplane and find my seat.

Together, my license and boarding pass (and myself) served as my identity.

This might seem like a lot of backup checking, but when it comes to identity verification in the cloud, it’s just as important.

Why are cloud identities important? 

If you understand why your identity is essential to travel, it’s easy to see why you need identities in the cloud too. Just like my identity in the airport is more than just my license or ID, identities in the cloud are more than just someone’s name and picture too. In the AWS re:Inforce session on security best practices with AWS identity and access management (IAM), Brigid Johnson explained identity very succinctly:

Identities tell us who can access what in the cloud.

Who can refer to human or non-human users. Human users are you—developers, security teams, etc. Non-human users are applications, workloads, service accounts, etc. that can make decisions on behalf of a human.

What refers to your resources (like a storage bucket or function). Finally, when we say “can access,” we’re talking about permissions. Permissions connect who and what.

When you put it all together, you have an identity.

So many variations of who can access what in the cloud gets complicated quickly. That’s where identity and access management (IAM) comes in, which is a set of policies, processes, and applications that helps you manage access permissions.

Going back to the airport comparison, IAM would represent the security officers, the rules they follow, and the technology they use to verify that you are who you say you are.

How can attackers take advantage of your cloud identity? 

Each of the most popular cloud providers (AWS, Microsoft Azure, Google Cloud) has a unique approach to managing identity access and authorization, which means that there are different policies and procedures for you to follow, as well as roles for you to understand for each cloud. This can get really confusing for the 90% of enterprises that use more than one cloud.

In their Black Hat USA 2022 session, IAM the One Who Knocks, security researchers and detection experts Igal Gofman and Noam Shimon Dahan explained some of the common identity and access concepts that users find confusing. AWS has several managed policies, which are policies created and administered by AWS.

While the AWS read only access managed policy sounds innocent, it actually allows users to read all of your AWS services and resources, and usually, this isn’t necessary. For example, in AWS S3, your data is stored in containers called buckets. One AWS S3 account can have up to 100 buckets. If you want to grant someone access to view files in just one of your S3 buckets, using the read only access policy will grant them access to the data and files in all 100 of your buckets.

How are you supposed to keep that straight?

It’s confusing, and hackers know this. These types of complications and security gaps inherent to a multi-cloud environment give them countless opportunities to access your data.

Why are cloud identity attacks gaining traction? 

On top of taking advantage of your confusion, hackers are improving their identity attack strategies—you’re making mistakes that expose your credentials, and they’re noticing. They’ve even figured out how to automatically catch mistakes in code.

“This is a tactic we’ve seen pick up steam and be incredibly successful. Extending from this is the whole aspect of adversaries no longer needing to touch actual systems in order to execute largely impactful attacks,” said Greg Foss, Lacework cloud security researcher.

For example, users sometimes accidentally commit AWS access keys in a public repository like Github, although Github will often notify you in under a minute if this happens, not every service does. AWS access keys are long-term user credentials that include an access key ID (like a username) and a secret access key (similar to a password). Access keys are powerful because they allow whoever has them to initiate actions on your resources.

Hackers now have a way to quickly find and take advantage of them. They subscribe to receive notifications any time new changes are made to a repository, and then they take this information and filter it to only show access keys. Once they have those keys, they can use them to automate access and attacks.

That’s like if you dropped your license and boarding pass at the airport, and a hacker got an alert immediately notifying them where and when you dropped them. They’re stolen before you even realize you dropped them.

Attackers are also selling access credentials in underground forums. They use cryptocurrency to remain anonymous throughout these transactions, which makes selling credentials easier, safer, and more profitable.

Another reason we’re seeing more powerful identity attacks is that hackers are learning new techniques from each other and the government.

According to Director of Threat Research James Condon, “Techniques to get credentials are more well known than they were a few years ago; for example, compromising a host to get temporary credentials from a metadata service.”

Stolen or illegally purchased credentials can allow an adversary to perform a variety of attacks on the cloud management plane; but shared API keys in general are even more concerning.

API keys, which are codes used to identify and authenticate users, are not usually tied to a single identity, which means that when employees leave companies, they aren’t rotated. If a hacker gets hold of an API key, they’ll have a way to easily return back into the organization for years to come.

You’re not the only target

Non-human identities are harder to compromise than humans are; however, hackers are finding the effort very worthwhile. Non-human identities are a crucial part of cloud infrastructure. They’re helpful because they can make decisions on behalf of humans, but if they’re attacked, the massive amounts of data that can be compromised is alarming. We’ve seen it in several instances over the past few years.

The 2020 attack on IT management company SolarWinds service accounts highlighted the dangers of hackers gaining access to non-human identities. A hacker used authentication tokens and credentials to access admin accounts and then add themself as an over-privileged user to access SolarWinds’ software system. They then added malicious code to the system, which infected the networks of SolarWinds’ customers when they deployed software updates.

The hackers then installed additional malware to spy on customers, which included several US government agencies and companies including Microsoft and Cisco. The attackers went undetected for months, giving them the opportunity to access 18,000 SolarWinds customers.

In 2021, a ransomware gang exploited a zero-day vulnerability in Kaseya VSA, a remote monitoring and management software platform used by managed services providers. The vulnerability enabled the hackers to bypass authentication and then push out malicious software updates to VSA servers of up to 1,500 companies.

Identity attacks are here to stay

Identity attacks aren’t going anywhere, and hackers will continue to evolve their techniques. Just last month, the FBI issued a warning about credential stuffing, explaining that they found two websites selling more than 300,000 sets of user credentials obtained using this method.

With credential stuffing, an attacker buys or steals a list of known username/password combinations from one organization; then, they use a network of computers infected with malware to automatically enter those credentials on many websites simultaneously to see if the username/password combinations work. Many times, they’re successful because people reuse the same credentials on several sites.

In May, hackers used this tactic on the wedding planning website Zola. They compromised about 3,000 accounts and used victims’ credit cards and bank account information to purchase gift cards and transfer funds. At the time, Zola did not require multi-factor authentication to log in to user accounts, making it even easier for hackers to execute a credential stuffing attack.

How are hackers getting away with it?

Cloud logs-data collected from apps and infrastructure-are better than ever before. But because they’re so detailed, we’ve learned to rely on them to understand our environment and build better permissions. To identify which permissions we don’t need, we examine logs to see what users are actually doing.

But attackers know that we expect logs to show when something out of the ordinary occurs, which is why they have started tampering with logs to cover their tracks.

Sometimes, instead of changing your logs, hackers overwhelm them with tons of actions so you never see what they are actually doing.

While hackers might know activities that are “normal” in general, they don’t always know what’s normal in your environment. If you do know what’s normal in your environment, you can see past hackers’ attempts to go undetected by changing your logs.

Think like a hacker: What’s their final destination?

Hackers don’t successfully attack critical assets simply by compromising an identity. You need to think about what happens next.

If someone successfully compromised your identity and got on your plane, what would they do next? What’s their end goal, and what’s the point of all of their hard work?

They make an attack path, usually combining multiple issues to attack the assets that matter most to an organization. Attack paths start from a breach point, and then navigate their way through your cloud until they get something valuable.

After they enter your environment, which assets could they compromise? What other accounts could they take over—are there any over-permissioned users? What would those accounts give them access to? If you’re thinking like a hacker, you’ll know that they won’t want to stop until they finally land on a critical asset. And there’s never just one path—there are many ways an attacker can pivot.

Why you need to prioritize and visualize

For you to more effectively manage risk, you need to see all of the various ways an attacker could pivot to reach critical assets. Every environment has vulnerabilities, but they’re not all equally dangerous. Regardless of how big your team is, it’s impossible to remediate them all—that’s why you need to be able to prioritize remediations and measure risk, and understand how it is all connected. A visual explanation is key to help understand where the issues are. When you understand a hacker’s attack path, you can better protect the things important to you.

Stay one step ahead of attackers

If attackers are using legitimate credentials, how can you tell the difference between a hacker and the actual account owner? You already know to pay attention to new users, hosts, connections, etc. But preventing identity attacks is different. You need to keep an eye on your existing accounts.

Instead of waiting for an alert that something malicious has happened in your account, you need to stay one step ahead of attackers. Look for deviations from your normal activity in the cloud. In order to do that, you need to have a baseline and know what’s normal in your environment. Data is key to accurate threat detection.

The more data you have, the easier it will be to identify anything out of the ordinary. To learn more about how and why hackers are targeting your credentials, check out our blogs on initial access brokers and how to protect your accounts.