Achieve better AWS security with just 10 Cloudtrail logs alerts

cloudtrail logs alerts

CloudTrail logs track actions taken by a user, role, or an AWS service, whether taken through the AWS console or API operations. In contrast to on-premise-infrastructure where something as important as network flow monitoring (Netflow logs) could take weeks or months to get off the ground, AWS has the ability to track flow logs with a few clicks at relatively low cost.

Some basic tracking is enabled by default with AWS CloudWatch and CloudTrail, but you should review the configuration and use this guide to apply the most important best practices.

Most services publish CloudTrail events but only save the most recent events from the past 90 days. In order to save data long term, you’ll need to create a Trail and enable continuous delivery to an S3 bucket. By default, when you create a Trail, it captures data from all regions.

Integrating your Cloudtrail logs into Coralogix is super easy and requires you to simply deploy a Lambda. Integrate your Cloudtrail logs with Coralogix for smarter analytics. Regardless, most alerts in this post will work with any ELK based solution. (Note AWS Open Distro has alerts for ELK as OSS!)

Cloudtrail logs can help meeting your Security requirements

Today’s cloud based applications allow users unprecedented access which. Users can access the application using different end points or locations. It is very important for companies to understand quickly if application activity is hostile or part of normal business. In some companies security organizations will come up with a formal list of requirements for DevOps and engineering in order to satisfy internal risk management or outside auditing in case of regulated industries. Putting formality aside, it is essential for every AWS based company to monitor user, admin and application activities continuously and identify red flags or malicious activity. There is a reason for AWS making Cloudtrail logs available for customers.  

In this paper we will show examples of how Coralogix simple but powerful alerts’ capability, combined with AWS Cloudtrail, can help companies implement such security requirements. The first example includes details about the different fields in the alert page. Other example will focus on the use case (unless new alerts fields and options are introduced).

1. Assigning privileges

In this example, the organization will be alerted when admin privileges are granted. The security org needs to make sure that it is a legitimate operation.

A Coralogix alert definition will look like this:

Assigning privileges alert cloudtrail logs

The filter, eventName:

AttachUserPolicy AND requestParameters.policyArn:AdministratorAccess

will capture logs where user policy is changed and the request field indicates that admin access was granted. In this case we did not choose specific app/subsystem or any other parameter in addition to the filter.

The alert will be generated upon log detection (‘Notify immediately’).

Notification will include only fields of interest out of a sizable Cloudtrail log. In this case we chose the username and request parameters.

Notification will be sent to a special mailbox as well as sec-ops slack channel, using Coralogix out of the box integration. An additional notification channel was defined using Coralogix webhooks and will send a message to an application that can act on the message.


2. Process failure

Getting an error or failure response to legitimate control plane operation or even worse to illegitimate one is a red flag. In either case security organization will want to be notified about it, as it represents a potential malicious change of policies. In this example we are looking for two of these failure codes.

Process failure alert cloudtrail logs

The filter InternalReason:


is an example for capturing logs with failure codes.

3. New admin

It is critical to know about new admin addition. If it is not a legitimate operation the environment  is exposed. The following example looks for ‘add admin’ operation.

New admin alert cloudtrail logs

In this example the filter, eventName:

AddUserToGroup AND requestParameters.groupName:/.*admin.*/

looks for the operation of adding a user to a group and using regular expression looks at all groups that have the string ‘admin’ in them.


4. Security group modified

Modifying a security group is another operation that sits in a critical vulnerability path. Done by an unauthorized user it can have devastating security effect.

The filter: requestParameters.groupId:sg-g666abcd OR requestParameters.groupId:sg-e666dcef

Is looking only at critical security groups. We don’t care what is the operation. We care which security groups were operated on.

5. Login with temporary credentials

In this example the security org wants to be notified when a user from outside the account is trying to assume a role within the account. 

The filter: eventName:AssumeRole NOT userIdentity.accountid:012345678901 is looking for a log with an event type AssumeRole that has an account ID different than the role owning account.

6. Granting permission to a key

The grant allows the grantee principal to use the CMK when the conditions specified in the grant are met. When setting permissions, grants are an alternative to key policies. Some companies would like to be notified if the grantee is from a different account.

The filter: eventName:CreateGrant NOT userIdentity.arn.keyword:/.*\d{12}.*/

where userIdentity.arn holds the grantee Amazon Resource Name that includes the account number. Here \d{12} is a generic placeholder for any Amazon account number. You can, of course create your own regex that fits your specific account number and use case. Like in the previous example, we will look for account numbers that are different than the key account.


7. Code deployment

In this use case the account is extremely sensitive to malicious code deployments. DevOps chooses specific time windows for deployments.

code deployments alert cloudtrail logs

Activity time is defined as 12:00 AM – 11:00 PM. Using the filter eventName.keyword:/.*deployment.*/ the alert will be triggered by any deployment event that is not between 11:00 PM and midnight, the allowed deployment time window.


8. Specific login to AWS console

This example will alert if a specific user tries to login into AWS’s console.

The filter to use is:

userName:specific username AND eventName:consoleLogin

You can, of course use regular expressions and look for sets of usernames. Another option is to look for usernames that are NOT part of a legitimate set.

9. Too many login failures to AWS console

In this example we are looking for too many failures to the AWS console in specific timeframe. The threshold will of course change between environments. Coralogiix gives you a very efficient way to find the thresholds by using our Loggregation mechanism. Coralogix Machine learning algorithms will automatically identify the number of failures and will generate a graph that indicates normal behavior.

Too many login failures to AWS console alert

The green line indicates the expected behavior along a timeline and the blue the actual behavior. Like with example 7, by using ‘activity time option’ you can very easily adapt the alert to the expected behavior at a specific time window.

too many failed logins alert cloudtrail logs

We defined the filter to be: eventName:consoleLogin AND responseElement.console.Login:failure, in this example we used a threshold of 100 failure in 10 minutes, by selecting the ‘more than’ option. We also chose to be notified on the distribution of different USER_NAME values, if the alert is triggered, by selecting the ‘group by’ option.

10. No log stream

Due to the  alerts defined on cloud watch logs and their effectiveness, hackers will try to stop the flow of logs for a period of time while changing a critical infrastructure element. Using Coralogix ‘less than’ configuration option can help users identify such quiet periods.

no cloudtrail logs alert

With this configuration, Coralogix will trigger an alert if for 30 minutes, no logs are being sent from a specific infrastructure component designated by an Application name.

For more information about Cloudtrail logs and other AWS logs, visit our extensive AWS logging guide.

This blog post focused on how to create security alerts based on AWS Cloudtrail logs. It showed some examples of such alerts. There is a vast universe of Cloudwatch logs out there. You will most likely have your own use case and requirements. So, you are encouraged to take the methods and concepts shown here and adapt them to your own needs. If you need help or have any questions, don’t hesitate to reach out to You can learn more about unlocking the value embedded in AWS and other logs in some of our other blog posts.

Start solving your production issues faster

Let's talk about how Coralogix can help you better understand your logs

Managed, Scaled and Compliant ELK Stack

No credit card required

Get a personalized demo

Jump on a call with one of our experts and get a live personalized demonstration