Beyond learning what privilege escalation is – an identity, whether it is a user or piece of compute, gaining access to rights or privileges beyond what’s intended for their level of access – is graduating to the question, “How do I detect privilege escalation in my cloud?” Before we address this question, we need to shed some light on the background behind this modern challenge.
What I often see at Sonrai are customers who are ready to secure their organizations, but they’re speaking the language of firewalls, antivirus, endpoint protection, and vulnerability scanning. A point we’ll make time and time again is that public cloud infrastructure is entirely different from on-prem. Because of this, Information security needs to be reimagined to suit this new world. If you’re not focused on identity and access controls, then you are blind to today’s threat landscape.
Attack methods are now different and the way bad actors move through your environment is different – so bringing old security concepts and solutions to this ball game isn’t going to cut it.
One constant is that at the end of every attack path is crowned jewel data. Which is why having data protection at the core of your strategy and working outwards, is the best path forward. Today, it’s not just users accessing your data. Non-person identities are vague and vast today – taking on service principals, roles, access keys, functions and more. These entities have vast over entitlements, as sometimes security isn’t the focus behind developers work.
Now that the groundwork is laid, we’re gonna focus on a specific common method that capitalizes on this complex mess of identity, data, and permissions – privilege escalation.
After this blog, you’ll have a better sense of how to prevent and mitigate privilege escalation by knowing the types, how it works, and walking through an end-to-end attack.
Privilege Escalation Can Happen Easily
Bad actors often start with a low-level identity, and then exploit permissions to move laterally through an environment. As they laterally move through your environment, they gain a level of permissions poised to cause irreparable damage.
Because of inherent risks and the fact that many organizations have failed to cover the fundamentals in cloud security, there are many gaps for bad actors to exploit without a lot of effort. Privilege escalation regularly goes unnoticed, especially in a complex cloud environment where companies already have difficulty gaining visibility into their internal users, identities, pieces of compute, services, and actions. A bad actor could spend days, if not weeks, inside your environment and you may not even know it. They could even expose sensitive data and, in some cases, you might be completely unaware of the breach until a third party informs you of it.
Types of Privilege Escalation
Bad actors seem to always find new ways to infiltrate your cloud environment. To help you understand better how criminals move throughout your cloud, we’ve broken down the types of privilege escalation down into categories.
There are two routes when it comes to privilege escalation:
- Horizontal privilege escalation—an attacker expands their privileges by taking over another account and misusing the legitimate privileges granted to the other user.
- Vertical privilege escalation—an attacker attempts to gain more permissions or access with an existing account they have compromised.
Furthermore, through Sonrai research we’ve identified five ‘profiles’ of privilege escalation in the public cloud. Let’s review them below:
Direct Self Escalation
This is when an Identity can modify its own rights. It has all the permissions it needs to move throughout your environment e.g. make itself an administrator.
This is where one identity can modify another identity’s credentials to impersonate it. For example, an identity has the permission to modify roles in AWS. While this identity is unable to read sensitive data itself, it can modify other roles so that they can read that data, and then jump into this new role and reach their goal ultimately.
This is often the result of the complexity in your cloud, including a web of rules, policies, trust relationships and permissions that give access at an unintended level. For example in Azure, a security team using a VM may have that identity at least privilege, but then higher up in the RBAC model, at the management group level, it was set that all devs in the application group have permission to read across the tenant. The result is a VM having unintended inheritance to read data across the environment.
An identity with a low set of permission gets access to a resource or a service with a higher level of permission and then uses that to perform actions on its behalf. For example, an EC2 instance has an instance profile with access to read sensitive data. The low level identity uses the EC2 to read all of the sensitive data on its behalf.
Resource Permissions Escalations
An identity has the permissions to change the configuration settings on a resource to allow the identity to perform unintended actions on that resource. For example, this identity is at least privileged itself, but it somehow has the permissions to change the configurations of a datastore that normally it only has read access to, but now they want the ability to delete it all.
What Does a Privilege Escalation Attack Look like?
The classic cyberthreat killchain has evolved to meet the public cloud. Here is the basic breakdown of how privilege escalation works end-to-end.
Recon: An attacker is going to do recon, this can look like scanning GitHub, or searching for low-hanging fruit like a publicly accessible S3 bucket, or simply capitalizing on a zero day threat they exploit on a workload.
Infiltration. Successful entryway, this is when your environment becomes their playground. This is when they sniff around and get an idea of the different identities, roles they could assume.
Privilege Escalation: The actual execution of leveraging permission boundaries and assuming new personas.
Lateral Movement. Here they move across your environment finding the way to access whatever their end-goal is.
Exfiltration: Your crowned jewel data is downloaded and they exit.
Impact: The brand image cost, and financial impact. Or fines and penalties.
The Attack Simulation
To help you better understand what privilege escalation looks like, we’re going to walk through a real-life example.
Put yourself in a bad actor’s shoes. We are now an attacker. First, we start off by going to GitHub, where we can search for any number of goodies, like credentials or publicly available datastores. For this example, we search the company name‘Sonrai’, and get several hits. One of which is a misc_app_info repository. Within that we find a URL that leads us to AWS S3, which piques our interest.
The XML file shows there’s some stuff in the bucket, including a file name – which we copy and paste to amend the S3 bucket URL, to enumerate the file. Once enumerated, we see a credential, an admin ID, and a secret key.
This command line key credential is for an identity in the organization’s AWS environment – ‘Sneaky Sam.’
Opening up Terminal, we enter a basic AWS configure command, where we enter the credentials, and access key, we just found through GitHub – we are now Sneaky Sam, in Sonrai’s AWS environment.
Now that I’m in, I want to enumerate some dynamoDB Tables, but this identity doesn’t hold that permission. Here’s where we get tricky. In Terminal, we see if we have access to any roles that may be useful. One gets our attention – codeDeploy-Dev.
We generate the credential and assume the identity of codeDeploy-Dev. We’re not satisfied, we want to move throughout the environment and see what else we can access. We find we can assume the role Pipeline-Create, and do so. Sneaky Sam is now in Production.
We try again, seeing if we can now access any DynamoDb List Tables, and sure enough come across the tables ‘PurchaseHistory’ and ‘transactions’.
Upon enumerating ‘PurchaseHistory’, we find an invoice including credit card information, and our job is done. Theft, misuse, selling on the darkweb, or any other nefarious activity is all possible.
Detecting Privilege Escalation
In terms of detecting privilege escalation there’s not one single answer. There are a range of ways a privilege escalation can be detected whether through proven cybersecurity tools and software solutions, or mistakes on the part of the attacker.
A critical component of CIEM solutions is the continuous monitoring. CIEM solutions will have a picture of what your ‘in policy’ environment looks like, so when there is anomalous behavior, there go the alarm bells. Once you detect an indicator that your environment is compromised, you can take the necessary steps to neutralize it—pausing or terminating the access session or monitoring the bad actor to see what exactly they’re after.
However, as important as detection of privilege escalation is, the reality is we are humans, and there will be mistakes. Credentials will be exposed, and bad actors will find their way in – so why not mitigate the impact as much as possible? Before detection, there is prevention.
Preventing Privilege Escalation
The key to privilege escalation is an organization losing control over all the identities in their environment and what they have access to do. This lack of visibility and the unknown risk is exactly what an attacker capitalizes on. So, you can better prevent privilege escalation by terminating excessive permissions and striving towards least privilege.
The real danger lies in all the permissions that covertly add up to create toxic combinations, or abilities beyond what was intended. These dangerous combos are what can allow any old low-level identity in a Sandbox environment to somehow maneuver their way into Prod where they can access customer PII in an AWS S3 bucket.
However, you can’t clean up what you can’t see. You need a way to see the Effective Permissions of all the identities in your environment – that is, the true end-to-end scope of abilities tied to an identity. This is no easy feat, but there are security solutions to help with this granular level of insight.