AWS IAM security explained

Executive summary

AWS Policies are a key foundation in good cloud security, but they are often overlooked. In this blog, we take a quick look on some AWS Policies, particularly for Identity and Access Management (IAM), that could become problematic if not properly managed. We'll discuss how they can be used against us to generate attacks like: Ransomware, data exfiltration, credential abuse, and more. Finally, we'll suggest some Open Source tools for cloud policy assessment and pentesting.  

The first step in achieving good security is having effective policies to regulate what can and cannot be done in an environment, both physical devices and cloud infrastructure. These regulatory policies are frequently hard to define and keep up-to-date, especially in a fast-paced environment using infrastructure-as-a-service (IaaS). This blog looks at some changes in policies which can reduce success in some common attack types involving: exfiltration, ransomware, credential abuse, and more. For that reason, AT&T Alien Labs is sharing an easy ‘what to look for’ list in order to detect some red flags in AWS policy changes. It is our hope that this list will be helpful for security analysts and forensic investigators.

Policies are spoiler alert, defined by AWS Policies, which define permissions for identities and resources. Every time AWS Identity and Access Management makes a request of any kind to a resource, a policy determines if the IAM is allowed or denied access to that specific resource under the policies for the involved parties.

A full understanding of AWS policies (types, creation, enforcement, etc.) is outside the scope of this blog, but it can be found in AWS documentation.

People implementing AWS policies should have knowledge of the organization, adapting policies to needs of the business. Afterwards, detection rules should be generated for red flags in CloudTrail or other security tools. By doing this, we are avoiding policy changes in a generic manner, for example using ‘*’ to cover the whole Principal without setting any Conditions to it (MFA, IP, usernames, etc.). The problem resides in changes occurring on a daily basis to the policies, which are often overlooked by analysts. The impact that these changes could have is as big as any other event or alert investigated.

In order to classify all AWS actions involving a policy change that could be used by attackers, we’ll sort them based on the potential final attack type. Most of the following techniques would fall under Modify Cloud Compute Infrastructure (T1578) but we have attempted to classify them outside of their specific Cloud technique - as if the activity was happening in a traditional environment.

Endpoint Denial of Service (T1499): Adversaries may perform Endpoint DoS attacks to degrade or block the availability of services to users. This blockage could be used as an additional impact on top of Data Encrypted for Impact (T1486) to avoid or slow down recovery efforts in a ransomware attack. In this scenario, attackers could be trying to block access to several AWS resources like: S3, EC2 through EFS or EBS, or backups between others.

S3: Amazon’s storage service can suffer a DoS by adding policies that block access to its contents. Buckets and Access Points are both S3 resources that could be impacted by an excessively restrictive policy or access control list (ACL), hence their relevance.

Detection Guidance:

Event/command:	PutAccessPointPolicy or PutBucketPolicy or PutBucketACL or PutObjectAcl
Effect:	Deny
Action:	s3:* or s3-outposts:*
GuardDuty alert:	Policy:S3/AccountBlockPublicAccessDisabled or Policy:S3/BucketBlockPublicAccessDisabled (previously known as Policy:IAMUser/S3BlockPublicAccessDisabled)

Additionally, the events DeleteAccessPointPolicy or DeleteBucketPolicy would have a similar effect, since they would be removing the policies where the public access is allowed.

Detection Guidance:

Event/command:	DeleteAccessPointPolicy or DeleteBucketPolicy
GuardDuty alert:	Policy:S3/AccountBlockPublicAccessDisabled or Policy:S3/BucketBlockPublicAccessDisabled (previously known as Policy:IAMUser/S3BlockPublicAccessDisabled)

In a similar situation, Amazon’s Elastic File System (EFS): any policy change denying access to this storage solution could also lead to a DoS. Due to this, these events and resource policies should be closely observed.

Detection Guidance:

Event/command	PutFileSystemPolicy
Effect	Deny
Action	elasticfilesystem:ClientMount or elasticfilesystem:ClientWrite
GuardDuty alert	-

Log Removal

Indicator Removal on Host (T1070): Adversaries may delete or alter generated artifacts on a host system, including logs or captured files, such as quarantined malware. In this case, removed indicators not only affect the host, but the whole cloud and the log ingestion platform in charge of generating alerts. The main affected resource is CloudWatch, but there are others too.

CloudWatch is the monitoring service for AWS resources tracks logs coming from different resources and accounts in AWS. Blocking the logging access to resources would have a similar effect as deleting logs in a traditional computer.

PutResourcePolicy gives permission for other AWS services to put log events to the current account. A new policy with Effect Deny on all could avoid resources logging on their expected log file, and delay alerting on a detection. Additionally, PutDestinationPolicy has a similar behavior - it has the capability of creating an access policy for existing log destinations. A restrictive policy could lead to a logs not being in the expected log location. In this case, PutResourcePolicy API or CLI does not allow specifying * as the Principal, and each sender account must be listed separately in the policy.

Several GuardDuty finding types could notify of any policy log tampering that could impact detection of indicators.

Detection Guidance:

Event/command:	PutResourcePolicy or PutDestinationPolicy
Effect:	Deny
Action:	logs:*
GuardDuty alert:	Stealth:S3/ServerAccessLoggingDisabled or Stealth:IAMUser/CloudTrailLoggingDisabled or Stealth:IAMUser/LoggingConfigurationModified

Other log events could be of relevance, like PutRetentionPolicy, but none of their effects would be as drastic as the previously mentioned or are not strictly determined by policies.

Ransomware

Inhibit System Recovery (T1490): blocking access to the backups or modifying permissions to delete them, most likely with ransomware intentions.

EFS offers an automatic Backup System through the command PutBackupPolicy, which could be disabled in a ransomware scenario causing slower recovery efforts.

Detection Guidance:

Event/command:	PutBackupPolicy
Status:	DISABLED

Backups: AWS offers several solutions for backing up systems (as we have already seen with the EFS solution). Looking into the AWS Backup official solution and disabling it or removing permissions to access them has the direct impact of a DoS, and aggravates the ransomware scenario.

Detection Guidance:

Event/command:	PutBackupVaultAccessPolicy
Effect:	Deny	Allow
Action:	Backup:*	Backup:Delete*
GuardDuty alert:	-

Exfiltration

Exfiltration Over Web Service (T1567): exposes current resources to the Internet with the intention of exfiltrating data outside of the organization.

S3: As we saw in the DoS section, a change in policies could remove public Internet access to a Bucket or Access Point. In this situation we are looking at the opposite scenario, a private S3 being made public to leverage it for exfiltration purposes.

Detection Guidance:

Event/command:	PutAccessPointPolicy or PutBucketPolicy or PutBucketACL or PutObjectAcl
Effect:	Allow
Action:	s3:* or s3-outposts:*
GuardDuty alert:	Policy:S3/BucketPublicAccessGranted or Policy:S3/BucketAnonymousAccessGranted

Elasticsearch: If the domain associated with an Elasticsearch instance is public, an attacker could modify any existing condition, like IP addresses or command restrictions - to increase the actions that can be performed on this public domain. AWS does not have a specific command to modify its Access Policies for Elasticsearch, but they can be modified from the user interface or the API through the Domain Config, on an individual domain basis.

Detection Guidance:

Event/command:	PutResourcePolicy
Effect:	Allow
Action:	es:* (in particular es:UpdateElasticsearchDomainConfig)
GuardDuty alert:	-

Attackers could also create a new Elasticsearch domain and include the above-mentioned policies. It is outside the scope of this blog to discuss operations involving new resources to exfiltrate data (Elasticsearch, S3, EFS, etc.). This attack would become noisier, since it involves creating new resources, applying the mentioned policies, and copying any relevant data to these resources. Just for reference, this attack would classify as Transfer Data to Cloud Account (T1537).

Elastic Container Registry (ECR): provides the capability to store Docker containers and have them ready for deployment. This deployment availability can also be turned around and be used for exfiltration by downloading docker containers from a pre-signed Amazon S3 download URL. This privilege can be obtained by modifying the SetRepositoryPolicy for the corresponding ECR and allowing the action GetDownloadUrlForLayer to access it externally.

Detection Guidance:

Event/command:	SetRepositoryPolicy or PutRepositoryPolicy
Effect:	Allow
Action:	ecr:GetDownloadUrlForLayer
GuardDuty alert:	-

Credential Access

OS Credential Dumping (T1003): uses a lack of security to dump credentials either encrypted, hashed or in clear text, to use them later in towards lateral movement or accessing confidential information.

AWS Secrets Manager is a great example of a target for a Credential Access scenario. The secrets in this vault need to be accessed by internal or external resources eventually, and a bad security policy might allow an attacker to take those credentials. These might be encrypted with a KMS key, but attackers would still be one step closer to their their goal.

An escalation of privileges (or decrease in security) could be achieved through the PutResourcePolicy for SecretsManager. An excess of allowed privileges could make credential access easier.

Detection Guidance:

Event/command:	PutResourcePolicy
Effect:	Allow
Action:	secretsmanager:* (in particular GetSecretValue)
GuardDuty alert:	-

AWS Key Management Service (KMS): is Amazon’s key manager to control what users and applications have access to certain cryptographic keys. Access to these keys is, as you can expect at this point of the blog, given by a specific policy. Changes made to this policy can enable several different attacks (like a DoS if access is denied to all users), but in this case we are looking at a too permissive policy set with PutKeyPolicy.

Detection Guidance:

Event/command:	PutResourcePolicy
Effect:	Allow
Action:	kms:PutKeyPolicy
GuardDuty alert:	-

In addition to the already mentioned events and AWS resources, there are others that could be leveraged by attackers, but these fall out of the scope of this blog to keep it a reasonable length. Just to mention some of these - they would be: Amazon Simple Queue Service (SQS) through sqs:AddPermission, Amazon Simple Notification Service (Amazon SNS) through sns:AddPermission, AWS Elemental MediaStore through PutContainerPolicy, AWS Lambda through lambda:AddPermission, etc.

After analyzing some of the most relevant policy changes impacting the cloud environment’s security in your organization, we’ll take a look at some of the AWS penetration testing tools available for free, and how they use policies.

AWS IAM Access Analyzer

AWS offers an Access Analyzer capable of assessing existing resource-based policies, and focuses on identifying any resources shared with external entities. Amazon refers to an external entity as any other AWS account, root user, IAM user or role, federated user, AWS service, anonymous user, or other entity.

It is a great resource for some critical resources like S3, KMS or SecretManager. However, it lacks coverage to other resources that could be as important, like Elasticsearch domains or CloudWatch resource policies.

Endgame

This free cloud pentesting tool provides a deep test of existing policies in AWS. The only prerequisite is an AWS API credential with privileges to update resource policies. It is capable of running in ‘expose’ mode, modifying just the necessary resources to achieve a BackDoor, or ‘smash’ mode, revealing potential security concerns by: enumerating resources, reading and modifying current policies, and finally implanting as many BackDoors as possible through weaknesses in the victim’s IAM security policies.

It offers approximately 30% more coverage than AWS IAM Access Analyzer, including coverage for:

• ACM private CAs
• CloudWatch Resource Policies
• EBS Volume Snapshots
• EC2 AMIs
• ECR Container Repositories
• EFS File Systems
• ElasticSearch Domains
• Glacier Vault Access Policies
• IAM roles
• KMS keys
• Lamda functions
• Lambda layers
• RDS Snapshots
• S3 Buckets
• Secrets Manager Secrets
• SQS Queues
• SNS Topics

In the full list of policies required to achieve all the BackDoors included with the tool, we can see some policies already mentioned in this blog: ecr:SetRepositoryPolicy, elasticfilesystem:PutFileSystemPolicy, es:UpdateElasticsearchDomainConfig, kms:PutKeyPolicy, lambda:AddPermission, logs:PutResourcePolicy, s3:PutBucketPolicy, secretsmanager:PutResourcePolicy.

Cloudsplaining

Cloudsplaining performs a deep assessment on all the AWS IAM security policies and identifies violations of least privilege, producing a full HTML report. The report includes triage items as well as remediation indications, offering the user a very helpful resource to analyze their current configuration and offering improvement possibilities.

Hacking the cloud

Hacking the cloud is an online encyclopedia supported by volunteers. The webpage contains a list of attacks/tactics/techniques that offensive security professionals can use to pentest their cloud environments. The attacks are not very policy focused, but it does use them in some attacks, like in the “Unauthenticated Enumeration of IAM Users and Roles”, which is present in Pacu too.

There are many other open source useful tools for cloud pentesting or policy assessment, like: Parliament, Pacu, PMapper, Repokid, Policy Sentry.

Conclusion

In this blog we have seen several attacks that could be performed using AWS policies - especially if they weren’t properly set up. We've discussed the importance of AWS policies as the foundation of a good cloud security. We have seen how GuardDuty detects some dangerous policy changes, but leaves out many others that can only be detected through constantly reviewing Cloudtrail logs. The pentesting tools seen in the blog can help detect holes in the policies. An alternative solution is the use of SIEMs like USM Anywhere, with specific detection rules added on a daily basis, thanks to the threat content that the AT&T Alien Labs team adds to the USM Anywhere platform.

Resources

AWS Policies: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html

Endgame: https://endgame.readthedocs.io/en/latest

Cloudsplaining: https://github.com/salesforce/cloudsplaining

Hacking the cloud: https://hackingthe.cloud/aws/general-knowledge/connection-tracking/

Parliament: https://github.com/duo-labs/parliament

Pacu: https://rhinosecuritylabs.com/aws/pacu-open-source-aws-exploitation-framework/

PMapper: https://github.com/nccgroup/PMapper

Repokid: https://github.com/Netflix/repokid

Policy Sentry: https://github.com/salesforce/policy_sentry/

Mapping to MITRE ATT&CK

The findings of this report are mapped to the following MITRE ATT&CK Matrix techniques:

• TA0005: Defense Evasion:
  • T1070: Indicator Removal on Host
  • T1078: Valid Accounts
  • T1578: Modify Cloud Compute Infrastructure
• TA0006: Credential Access
  • T1003: OS Credential Dumping
• TA0010: Exfiltration
  • T1537: Transfer Data to Cloud Account
  • T1567: Exfiltration Over Web Service
• TA0040: Impact
  • T1486: Data Encrypted for Impact
  • T1490: Inhibit System Recovery
  • T1499: Endpoint Denial of Service