AWS offers hundreds of cloud services for organizations to power their business. Monitoring these services individually for detection and response can be challenging at best. Thankfully CloudTrail helps centralize AWS logs into a single format. Allowing security teams to create multiple detections with a minimal variance – making it easier to write, test, and deploy new detections in minutes. This blog will discuss five critical detections across AWS log types by leveraging CloudTrail.

Monitoring PUT Requests to S3

Organizations typically use S3 buckets to house sensitive customer data or internal information. Security teams are often looking to establish policies to control user access permissions. Particularly permissions to manipulate stored data. The sample log below is an example of a GET request into an S3 bucket:

Security teams could create checks that monitor for GET or PUT requests into S3 buckets that contain highly sensitive information. By looking at the “eventName” field, CloudTrail makes it easy to determine the type of API call this is. Therefore, we can create a detection that verifies when an API call occurs for S3 and then checks if the call is to a sensitive bucket. Here’s what the respective code would look like:

A security engineer can accomplish this with just lines 14 & 15 of the code. However, the checks beforehand help filter the detection engine in Panther to pass over event logs that don’t apply faster. By monitoring PUT and GET requests, security teams can quickly signal if a potential intruder is calling into their most sensitive S3 buckets.

Alert for Terminated EC2 Instances

Now, let’s move on to EC2.  Downtime for EC2 production instances can impact critical business functions. Security teams can monitor for potential state changes to any EC2 instance. Let’s look at an event log of a recently terminated instance.

Because CloudTrial logs are formatted the same way for any AWS resource they are logging, security teams can easily reuse previous code to write similar detections. You’ll see the code below looks very similar to the one we previously wrote.

By simply changing the initial “eventName” and “eventSource” we can now monitor EC2, searching for the Terminate instance state. Teams can run additional checks by creating a library of all crucial EC2 instances or weed out AWS users with permissions to execute such tasks.

Monitor Root Level Policy Access with IAM

Next, we’ll monitor an Identity Access Management group policy change with CloudTrail. Security teams will typically create strict IAM policies that only provide users access to AWS services they require for their jobs. IAM policies ensure that very few users possess a “God-Mode” level of permissions. The sample log below shows a user being created and given root permissions to all AWS services within the organization.

Whether this is intentional or not, it’s essential for security teams to monitor this activity and store it for historical purposes. New permissions can also indicate compromised accounts trying to gain higher permissions.

Similarly to the last two examples, by using the same code, we can check if the event log is related to IAM, if a root user created the new user, and if one of the root-level policies applied to the newly added user. This way, the alert stays less noisy. Again, using the same code block, I created a new detection for IAM due to CloudTrail’s consistent log formatting and the ease of Python reuse.

Protecting Critical CloudFormation Stacks

Infrastructure teams use CloudFormation to spin up and down critical company resources. Typically, organizations only deploy critical stacks in AWS regions where they choose to operate. For this example, let’s take a log from a team that only deploys new CloudFormation templates in ‘us-west-1’ and ‘us-west-2’.

Now, we can create a detection that alerts when a low-privileged user makes a CloudFormation stack in an AWS region where the organization doesn’t operate.

Using a severity function, we can dynamically alert for any CF template created in a permitted AWS region vs. a non-permitted one. A stack in a permitted region will provide an “INFO” level severity alert vs. a non-permitted region at a “HIGH” alert.

Enriching GuardDuty Findings with Threat Intelligence

This blog focuses primarily on using CloudTrail as a standardized format to write python detections. With GuardDuty, we can do the same thing; however, Panther can add a deeper portion of analysis by leveraging threat intelligence partner GreyNoise directly in a detection. First, let’s take a look at a GuardDuty finding sent to a CloudTrail log.

By first filtering the event and severity of the finding, we can call in GreyNoise to search the source IP address responsible for the alert within its database. GreyNoise classifies IPs as malicious, benign, or unknown. Based on this information, we can use the severity function we used in our previous detection to categorize alerts as “Info” if the source is benign or “Critical” if it’s malicious.

This enrichment happens during the ingestion process when the logs are parsed and normalized by Panther’s detection engine. It will then analyze the detections in real-time with the information from GreyNoise and offer immediate remediation to low-level GuardDuty alerts.

Conclusion

With detection-as-code principles applied to CloudTrail, security teams can create, test, deploy, and iterate detections quickly and efficiently to secure their AWS cloud stack.

We hope these sample detections can give you a starting point to protect your AWS environment at a deeper level. If you’d like to learn more about how to apply python-detections to a SIEM tool, read this blog.