Monitor AWS Admin Groups

With the increase in popularity and adoption of cloud platforms comes an increased NEED for being able to monitor these environments for abnormal, dangerous, or suspicious changes and activity. Cloud providers provide a service that can be super useful but in order to enable businesses to adopt their platform quickly they leave securing the services being used by the customer up to the customer.

AWS is a great example — they provide managed IAM (Identity Access Management) policies (you can think of them like permissions) which enable user’s of AWS to quickly start using the various services easily. A listing of the various useful managed policies broken down into common job functions can be found HERE. AWS will actually recommend NOT using these policies, rather, they suggest customers use the policies as a template and build their own specific to the function (known as customer managed policies). Least privilege is the name of the game and in a moment you’ll see why. Which policy type is best is out of scope for this blog post, however, I encourage all AWS administrators to review AWS’ best practices for IAM policy management to ensure you’re aware of the risks involved and can make educated decisions based on your risk appetite.

The focus of this blog post is on a single, very dangerous AWS managed policy — arn:aws:iam::aws:policy/AdministratorAccess. With this policy attached to an IAM user/group/resource that target (user/group/resource) has full permission to do whatever they want within the AWS account. Here is what that account permissions looks like:

One way to monitor this policy being granted to users is to monitor when users are added to groups with that policy attached. In order to do that we need to be collecting AWS Cloudtrail and Configuration logs into your SIEM or other monitoring solution (full disclosure — config logs are noisy, i suggest implementing a shorter data retention policy on these logs unless you like spending lots of money in Splunk license costs). To accomplish this via Splunk (which is what i’ll be doing) you can follow this user guide HERE.

First — we need to build the query which identifies any resource with the arn:aws:iam::aws:policy/AdministratorAccess associated with it. For this we’ll be looking at the config logs.

index=aws sourcetype=aws:config TERM(arn:aws:iam::aws:policy/AdministratorAccess) configuration.attachedManagedPolicies{}.policyArn=”arn:aws:iam::aws:policy/AdministratorAccess”
| stats values(resourceName) as requestParameters.groupName

You’ll notice the “TERM(…Access)” — this will speed up the search a little which is going to be beneficial because these logs are very verbose (and there are a lot of them). You’ll also notice we’re renaming the “resourceName” to the “requestParameters.groupName”. This is because we’ll use this search as a subsearch into our main search. Basically we’re finding resources with that policy attached then sending it to Cloudtrail logs to find activity where a user is added to that resource (group).

index=aws sourcetype=aws:cloudtrail eventName IN (AddUserToGroup)
```subsearch to get all groups with AdministratorAccess permissions```
[search index=aws sourcetype=aws:config TERM(arn:aws:iam::aws:policy/AdministratorAccess) configuration.attachedManagedPolicies{}.policyArn=”arn:aws:iam::aws:policy/AdministratorAccess”
| stats values(resourceName) as requestParameters.groupName]
| eval userAdded = ‘requestParameters.userName’, responsibleUser = mvindex(split(‘userIdentity.arn’,”/”),-1)
| eval group_name = ‘requestParameters.groupName’
| eval alert_message = “The user, “.userAdded.”, was added to the sensitive security group, “.’requestParameters.groupName’.”, which has administrative privileges.”

To summarize the SPL above: we’re looking for any resource with Admin privs, then looking specifically for groups that have had a user added to that group. Keep in mind subsearches are limited to 10K results so if you’re in a very large environment that might be a factor — hopefully you dont have 10K resources with admin privs through :O). If that is the case you can always swap the logic and look for users being added to ANY group as the subsearch then look at the config logs (either via join or subsearch) and find out of that group has the admin privs associated with it.

I like to add alert_message to my SIEM alerts to give the SOC analyst more context into why the alert was triggered. What we get is an alert where anytime a user is added to a group with administrative permissions the SOC is notified. The account owner can be notified of the change and can determine whether the change is authorized or needed.

Hope you enjoy and good luck!