Shadow admin permissions and your AWS account

Shadow Boxing

Defending the Empire

The inhabitants of the small Gaulish village have a hidden secret that can only be passed down through the Druids by word of mouth. A magic potion gives the Gauls a superpower, like an AWS full admin. For decades, Romans have been trying to get the ingredients with no success.

Now that you know how malicious people can leverage these tools of the AWS environment to compromise your account, it is time to get some excellent defenses and detections in place.

Most organizations use a prevention-focused security approach. This strategy to security is a more old-fashioned method than detection-based security. By deploying security controls in the cloud, like Security Groups, network access control lists (ACLs), endpoint detection and response (EDR), antivirus, vulnerability management processes, web application firewalls (WAFs), and other methods, a company can dramatically decrease the probability of being breached; however, these strategies are not always effective. Some small companies that do not have the budget to hire security professionals tend to focus on these methods of prevention. Of course, no perfect tool exists that can prevent all attacks.

With detection, you are just watching how thieves break into your house. Prevention and detection complement each other, allowing an organization to address potential threats that may happen. The ingredients to the magic potion include ample portions of both prevention and detection.

Whenever you need to apply a policy, be very careful with the "Resource" section. For example, the following policy, if replaced by built-in variables, follows the principle of least privilege, which means that instead of using an asterisk (*) for all resources, you can use the "aws:username" variable to allow users to perform the same action while still limiting the scope to themselves. To be clear: When applying a policy, if you enter a wildcard in the resource section, you allow the specific action to everyone, which is much too permissive. The goal should be to limit the scope as much as possible to a specific user or resource.

One example is an IAM policy to allow changing the password. If you enter the * in the resource section, any IAM user would be allowed to change not only its own password, but all user passwords, including any privileged user or administrator, and that is how privilege escalation works. The alternative is to have something like the following in resource section:

"Resource": "arn:aws:iam::account-id-no-hyphens:user/${aws:username}"

The bad practice of allowing any actions to all resources is directly related to the vulnerability of shadow permissions. Although some good use cases can be found when the resource needs to be set to * (e.g., if you have a team that is responsible for creating users and changing passwords), that situation must be planned carefully, and you need controls in place and some detection mechanism. The AWS documentation [7] lists the variables that could be used in policies (Table 3).

Table 3

Available Policy Variables

Variable Function
aws:CurrentTime For conditions that check the date and time.
aws:EpochTime The date in epoch or Unix time; for use with date/time conditions.
aws:TokenIssueTime The date and time that temporary security credentials were issued; for use with date/time conditions. Note: This key is only available in requests that are signed with temporary security credentials. For more information about temporary security credentials, search for "Temporary Security Credentials in IAM" on the Internet.
aws:PrincipalType Indicates whether the principal is an account, user, federated, or assumed role (see the explanation that follows).
aws:SecureTransport A Boolean value that represents whether the request was sent by SSL.
aws:SourceIp The Requester's IP address from which the API call is coming. Applying these variables will restrict and secure your policies to only those specified IPs. Refer to IP address condition operators for information about when SourceIp is valid and when you should use a VPC-specific key instead.
aws:UserAgent A string that contains information about the requester's client application. This string is generated by the client and can be unreliable. You can only use this context key from the AWS command-line interface.
aws:userid The unique ID for the current user. When IAM creates a user, user group, role, policy, instance profile, or server certificate, it assigns to each resource a unique ID that looks like AIDHJQAULZS4A3QDU476D.
aws:username A string containing the friendly name of the current user.
ec2:SourceInstanceARN The Amazon resource name (ARN) of the Amazon EC2 instance from which the request is made. This key is present only when the request comes from an Amazon EC2 instance using an IAM role associated with an EC2 instance profile.

For corporate users, some restrictions could apply to IAM users, like geolocation (IP address range) restrictions, which limit where the actions can be performed (e.g., a VPN connection or within a corporate office). This setting will definitely decrease the threat of someone using access keys to compromise the account. The variable to configure in the policy is "aws:SourceIp", where you can deny or allow specific IPs to make the API call.

Additionally, you can limit by time frame. If you know that users work at 8AM and leave by 5PM, you could restrict any changes to that time range. Of course, this step alone won't save you from attack, but it will narrow the window and provide an additional barrier.

For detection controls, you can use your logs going to your SIEM to create alerts when some of these permissions are used. One good example would be CreateAccessKey. If you configure an alert that triggers when a user creates an access key for another user other than himself, you will receive notification by email or SMS, which will allow you to respond promptly to the attack – possibly while it is still in progress. The detection control used will depend on your own environment, because every organization and its needs are completely different. AWS CloudTrail logs will help, as well as services like Amazon GuardDuty [8], which is a threat detection system.

If you find something suspicious when monitoring the usage of access keys and temporary tokens on your accounts, you must investigate further. A suitable tool that is also part of the CyberArk arsenal is SkyWrapper [9].


The AWS identity and access management system is the main entry gate for malicious attackers, so you should use the principle of least privilege on your IAM accounts. To identify misconfiguration on your accounts and remediate them before someone else does, use scan tools periodically. Also, keep a close watch on changes to permissions and create alerts to help you respond to any unauthorized change. Pacu can facilitate red teaming exercises from time to time.

If you already have some findings, you should already have some logs. With that information, you are now ready to create security alerts, but you do not want to waste time and money responding to noisy false positive alerts, so choose your alerts carefully and keep a special focus on any events that could be directly or indirectly related to shadow admin permissions.

The Author

Raul Lapaz works as a cloud security engineer at the Swiss pharmaceutical company Roche. His primary role is to design, implement, and deploy a secure cloud environment for health care digital products in AWS. Years ago, Raul wrote articles for Windows NT Magazine .

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Exploiting, detecting, and correcting IAM security misconfigurations
    Three IAM security misconfiguration scenarios are rather common: allowing the creation of a new policy version, the modification of a role trust policy, and the creation of EC2 instances with role passing. We look at ways to avoid and detect IAM security holes.
  • Hands-on Exchange rights management
    Exchange Server 2013 provides a comprehensive, role-based rights management feature. Rights and roles can be managed in the Exchange console, with PowerShell, or with additional tools. We demonstrate all three options.
  • New administration options on Windows Server 2016
    Redmond is set to launch the next-generation Windows Server 2016. Microsoft promises to make administration more secure, which is a good enough reason to take a closer look at the new Privileged Access Management feature.
  • Protect privileged accounts in AD
    Granular protection for highly privileged accounts is granted by the Protected Users group in Active Directory and Kerberos authentication policies.
  • Privileged Identity Management in Azure AD
    Azure Active Directory privileged identity management provides just enough administration for admins to carry out their work, while minimizing the possibility of security breaches through privileged admin accounts.
comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs

Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>


		<div class=