Centralize AWS Multi-Account Logging & Detect Defense Evasion with LogRhythm SIEM

Amazon Web Services (AWS) is a widely known cloud service provider, but organizations that use AWS products face unique cybersecurity challenges. Leveraging techniques that reduce risk against new cloud security challenges will help you stay ahead of threats across your AWS environment. In this blog, you will learn:

• How multiple AWS accounts impact security
• Defense evasion techniques that attackers are leveraging
• Best practices for AWS security
• Ways to improve visibility and detection of CloudTrail logs using SIEM

Let’s get started!

Security considerations for using multiple AWS accounts

AWS accounts can be created per application workloads (e.g., development account, staging account, production account, admin account). Therefore, a large organization can have a hundred-plus AWS accounts for its business units or applications.

As your organization grows and the technology architecture becomes more complex, AWS recommends having multiple accounts as a best practice; security posture can be improved logically by separating the accounts and resources used in each account. For example, if an account is potentially compromised, an attacker will only be able to use the resources in that compromised account. The logical isolation protects other AWS accounts from getting compromised, minimizing the blast radius. You can also centrally manage multiple accounts can using AWS organizations.

What you need to know about CloudTrail Logs

CloudTrail logs provide the event history of AWS account activity. The CloudTrail service records AWS API calls for an AWS account, and then the security team can monitor suspicious API calls. The CloudTrail is enabled within a single AWS account. Typically, CloudTrail API calls can be streamed into Amazon Simple Storage Service (Amazon S3) buckets locally for longer retention. If the AWS account is compromised, the attacker could tamper with the logs stored in the S3 bucket within that compromised account. Modifying the trail does not mean deleting and modifying the logs in CloudTrail event history, and by default, CloudTrail event history is stored for 90 days. You can learn more about CloudTrail here.

Multiple AWS accounts can write CloudTrail logs to a central CloudTrail S3 bucket on a separate AWS security account. The below screenshot shows three different accounts writing their CloudTrail logs to a separate AWS account S3 bucket.

How to create a trail and bucket policy for multiple accounts

CloudTrail log files are stored in an S3 bucket as a gzip archive. The S3 bucket folders are formatted with the originating account ID, and the logs corresponding to each account are stored under the original account number. Learn more here.

How LogRhythm SIEM Collects CloudTrail Data

Open Collector brings modern logs, usually in JSON format, from cloud log sources, flat file, or other formats, into the LogRhythm SIEM platform. It is designed for easy mapping of JSON fields to the schema.

Disruption of CloudTrail Logging by an Adversary

Let’s explore several use cases for how to detect and respond to suspicious activity across CloudTrail logging in your AWS environment.

1. Detecting StopLogging with SIEM

Suppose an attacker has potentially compromised an AWS account with administrator privileges. The attacker can turn off logging for a trail using console or AWS Command Line Interface (CLI). Stopping the trail will stop logging CloudTrail data into an S3 bucket as part of defense evasion. The below API calls are suspicious and very important to monitor because an adversary may disrupt trails in attempt to evade defense.

The AI Engine monitors suspicious AWS API calls using the message, classification, directionality, and several other factors in determining a risk-based priority (RBP) score. The RBP score is a number between 0 and 100 and characterizes the activity’s associated risk level: zero represents low risk, and 100 represents an extremely high risk. A RBP score is assigned to each activity processed by LogRhythm SIEM.

You can quickly drill down using the Alarm Drill Down to discover the Top Impacted AWS Accounts associated, then further to see all logs in detail (including metadata and raw log message) for the impacted AWS account. From there, drill down into the indexed log, with final navigation to the raw log message through a simple click on the “log message” tab of the Web UI.

The drill down of the alarm will help you identify the metadata quickly, what AWS accounts are compromised, and the user in question.

2. Detecting DeleteTrail

If an attacker got the required IAM permission over the compromised account, they could delete the trail on the victim’s AWS account for defense evasion.

In this example, you can drill down on the alarm to get more information and proceed with the investigation.

The drill down of the alarm will help you investigate the suspicious delete trail API call.

3. UpdateTrail

An attacker can create cloud instances in unused geographic regions to evade detection. For example, an adversary could use an unused AWS region for cryptocurrency mining, which can cost an organization a substantial amount of money. CloudTrail can send logs to S3 buckets from a single region or multi-region. The below screenshot shows the configuration is set for multi-region to be true in production. The organization is logging all the activities across all the regions in an S3 bucket. The attacker may disable the multi-region trail for all regions. The activities which happen in the other regions will not get logged by disabling the CloudTrail. Learn more about UpdateTrail here.

The below screenshot shows an example of how an attacker has disabled the multi-region trail part of defense evasion.

You can drill down on the alarm to get more information and proceed with the investigation.

Again, you can drill down on the alarm for further investigation.

The LogRhythm SIEM Dashboard displays the event layer of log data and provides the ability to drill down to the underlying raw log data. The raw log shows the multi-region is set to be disabled by the attacker.

AWS is all about shared responsibility model. Customers are responsible for the security in the cloud and AWS is responsible for the security of the cloud. CloudTrail event history is essential for incident response. An attacker with the right permissions can gather information about the target environment and then disrupt the logging of CloudTrail to stay under the radar. Modifying the trail does not mean deleting and modifying the logs in CloudTrail event history, and by default CloudTrail event history is stored for 90 days.

AWS Security Best Practices

It’s critical to continue to improve your cloud security defenses and leverage AWS security best practices to reduce risk to your organization. Here are couple of tips to live by moving forward:

• When configuring CloudTrail, apply trail to all regions.
• Consolidate all the region logs.
• Configure central logging to one single bucket in a separate AWS security account.
• Enable multi-factor authentication to delete the S3 buckets.
• Configure AWS organization and apply service control policies where no one can tamper with CloudTrail logging.
• Monitor suspicious API calls.

To learn more about AWS security best practices, check out this practical guide for plugging AWS in your SIEM solution.