The year is 50 BC. Gaul is entirely occupied by the Romans. Well, not entirely … . One small village of indomitable Gauls still holds out against the invaders.

Like those indomitable Gauls, you face down legions of mysterious invaders who would love to conquer your Amazon Web Services (AWS) resources. In this article, I look at how many AWS attacks happen and what you can do about them, but before I get started, I'll take a moment to explain how permissions work on AWS.

AWS Permissions

A principal, which can be a human or a machine, makes a request for an action on any AWS resource. Principals must authenticate with their credentials to send a request to AWS, unless the resource permits anonymous access, which is not the case for most services. The principal can use the root user or an Identity and Access Management (IAM) user. Of course, being the root user is not security best practices.

Once you authenticate, you can only access resources on which you have some kind of authorization. During authorization, AWS checks for policies that apply to the request, which it then uses to determine whether to allow or deny the request.

This topic can get very complex, so I will not dive deep, but the concept is very similar to, for example, Microsoft authentication, where you need to have a user account and permissions to access any resource on the network. Cloud providers have an extensive selection of permissions or capabilities that makes it difficult for admins to use the principle of least privilege when configuring policies for users and roles.

The Israeli cybersecurity company CyberArk explains, "… there are many cases where Shadow Admins might be created. Despite the appearance of limited permissions, a Shadow Admin with just a single permission has the ability to gain the equivalent power of a full admin" [1].

I refer to the term shadow admin often in this article. Simply, a shadow admin is a user or role with some assigned capabilities, that, if not configured properly, can escalate privileges to full administrator. A shadow admin account is thus nearly as dangerous as the root account, and it receives far less attention from security staff.

CyberArk has stated that 10 shadow admin permissions exist, but as you will see later, there are even more than that. CyberArk has released an open source tool called SkyArk [2] with which you can scan Azure and AWS environments and identify shadow admin accounts. To scan your account, you just need to set up a user account with IAM read-only permissions, because it just needs to check for the assigned permissions of all users and roles, and create an access key for that account.

SkyArk is useful for identifying accounts that could be vulnerable to privilege escalation. The results of the scans can be used by defenders (blue team) and pentesters (red team) to test the security of their company and remove all shadow admins with unnecessary permissions. However, bad actors can also use the results to break into cloud accounts. As a security professional, you need to know all those permissions and how to protect and detect them. Table 1 shows the AWS permissions that CyberArk identifies as shadow admin permissions.

Rhino Security Labs [3], the creators of the open source web penetration framework Pacu [4], takes a more expansive view of what permissions are dangerous enough to be shadow admin permissions. The Rhino team lists 21 shadow admin permissions. Table 2 shows the additional permissions that made the Rhino list.

The people at Rhino Security Labs have done a brilliant job creating a Python script, aws_escalate.py [5], to identify all 21 shadow admins.

Preparing the Invasion

Julius Caesar wanted to launch a big invasion into Gaul to defend Rome and earn glory for himself. However, nowadays, motivations are different, and they include espionage, spamming, disruption, fun, credibility, theft, abuse, financial interference, revenge, and so on.

To get the key to the castle, a bad actor needs to get a user's credentials first. The easiest way would be to ask the user, but perhaps that option will not succeed, so the attacker might need to take a unique approach.

As you know, developers, software engineers, DevOps folks, and others that usually interact with AWS resources sometimes keep credentials in clear text on their computers, unless they make the effort to deploy some sort of protection like password vaults, but I'll assume those are few. Employing a very common hacking method like phishing is a likely way the attacker will take the first step.

For instance, the attacker could browse to Gmail or any other email web provider and create an account with a name that is descriptive of an existing company. (I will not give you any specific ideas here.) Next, they could get a list of recipients for the email that might comprise a small team of developers or employees with similar roles, which can probably be found on LinkedIn. Other methods are suitable for finding credentials in the wild. For instance, intruders can use a tool called shhgit [6] to find secrets and sensitive files across GitHub code.

The attacker can now send a fake calendar appointment with a subject line that is likely to get the attention of the recipient (e.g., a salary increase or a free Christmas dinner). In the body of the message is a link to a URL that everybody would love to click. Malware could then be deployed, or the link could redirect the legitimate traffic to a fake AWS console login.

An attacker who succeeds in compromising one user can then navigate to the user profile .aws folder and get the credentials file that contains the AWS access key and secret. Yes, it is all in clear text.

Exploring the Castle

Once the attacker has slipped through the defenses, the next step is to use scanners to do some reconnaissance and collect information about the castle.

The two tools I described previously, SkyArk (PowerShell) and aws_escalate.py (Python) will scan for accounts that offer the best possibilities for privilege escalation. SkyArk provides a much more complete report, but it won't find some of the additional shadow admin permissions identified by aws_escalate.py. The two tools complement each other.

SkyArk will work for both AWS and Azure. If you are interested in exploring SkyArk, the instructions to install it are on its web page and are very straightforward. The user running the scan needs to have IAM read-only permissions, so the attacker needs those capabilities, and it is still possible to use the Pacu tool to see if the current user could be vulnerable.

In a PowerShell command prompt window (CMD), run the following command under the SkyArk folder:

PS C:\SkyArk> Scan -AWShadowAdmins -AccessKeyID AKIA5DWQIQ2MR6OXXXXX -SecretKey BYptvF+QF2kk8W4DJUiu5xQPffr34AFqYptXXXXX -DefaultRegion us-west-2

AWShadowAdmins is just a module of the program, but you might find other modules interesting, as well (e.g., AWStrace, which analyzes logs).

Figure 1 shows some very complete report output, but the attacker is most interested in the shadow admin line and needs to discover which user is associated with which permission. The golden ticket is to find a user with a vulnerable shadow permission.

Figure 1: SkyArk report output.

The next step might be to use Pacu. Installation is very straightforward by following the instructions on their website. Once installed, you should run it and configure the first session with the access key and secret. If you type whoami and hit Enter, the tool will give information about the access key being used, but it is not enough information to play around. To get more information, run the first module to enumerate permissions by typing

run iam__enum_permissions

Now you know the stolen credentials were from Cleopatra (Figure 2).

Figure 2: Permissions enumerated by Pacu.

If you run whoami again, you will get much more information, but the most important thing you could discover about Cleopatra is a shadow permission or capability (Listing 1).

01 "Policies": [
02     {
03       "PolicyName": "Shadow_CreateNewPolicyVersion",
04       "PolicyArn": "arn:aws:iam::901306156697:policy/Shadow_CreateNewPolicyVersion"
05     }
06 And:
07 "iam:SetDefaultPolicyVersion": {
08     "Resource": [
09       "*"

You could also run the aws_escalate.py tool with the access key and secret previously stolen from the user to generate a CSV output file that is very simple, but concise and directly to the point. As you can see in Figure 2, the tool scans all the users and lists all the associated permissions, but if some confirmed Shadow permissions exist, it will show them onscreen.

According to the creators, a blank means the associated account is not vulnerable). Confirmed means that the privilege escalation method works for that user, and Potential means that the privilege escalation method might work, but requires further investigation.