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).

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].

Conclusion

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.