Part 1: Intro to Threat Hunting AWS CloudTrail with Sentinel
By Sean Fernandez | Threat Researcher | Binary Defense
Note: this is a four-part blog post based on research from our threat hunting team. We will release this series over the next few weeks.
The adoption of cloud has been sharply rising in recent years. Global and small enterprises are flocking to large scale cloud computing such as Amazon Web Services (AWS) for increased security, stability, cost efficiency and greater networking and development tools.
Concurrently, this rapid digital change has expanded the attack surface propelling threat actors to evolve their exploit strategies across cloud environments. Cyber security teams working in cloud platforms are also rapidly evolving their strategies but face setbacks when approaching cloud challenges with on-premises tools and practices. Cloud providers use a shared responsibility model, where the provider is responsible for protecting the infrastructure that runs all the services offered in the cloud and the customer responsibility will be determined by the cloud services selected. According to Amazon Web Services (AWS), “customers are responsible for managing their data (including encryption options), classifying their assets, and using IAM tools to apply the appropriate permissions.”
Global reports show that some Security Operation Centers (SOCs) lack familiarity in cloud security tooling and are challenged by the monitoring of high-volume data. Uncommon log collection methods can lead to increased visibility gaps that make detections harder to fine-tune, and in turn, increase false positives. Not developing a proper foundation of processes in AWS could result in budgetary shortfalls, alert fatigue, and lack of mitigation in a timely manner.
Threat actors have modified their tactics, capitalizing on misconfigured assets and Identity and Access Management (IAM) permissions sprawl. Common cloud-based vulnerabilities include IAM policies and permissions, misconfigured S3 buckets and security tokens. SOC teams will benefit from taking a proactive approach to uncover these types of malicious behaviors. Threat hunting in Sentinel with Kusto Query Language (KQL) will quickly narrow down the focus and efficiently uncover AWS CloudTrail anomalies.
AWS CloudTrail is a native service which operates as a central logging source for almost any API call in an AWS account. CloudTrail logs, continuously monitors, and retains account activity related to actions across an AWS infrastructure, giving users control over storage, analysis, and remediation actions. By default, CloudTrail stores logs for 90 days but can be configured for longer storage in S3 buckets. The data is stored in JSON format for each event. The JSON records can be extracted, translated, and manipulated by standard tooling.
What makes this a valuable out-of-the-box tool is that the span of visibility can potentially uncover suspicious activity, such as listing buckets, creating users, changing policies, and stopping logs.
Augmented Threat Hunting with Sentinel SIEM
Microsoft Sentinel is a security information and event management (SIEM) system for detecting and responding to threats. By ingesting the AWS service log data into a SIEM such as Microsoft Sentinel, Splunk, AT&T Cybersecurity, or another system, we can run custom investigative queries to build detections. Sentinel makes it easy to add sophisticated search capabilities and fine-tune search indices. In addition, connecting AWS logging into Sentinel can provide alerts and run threat checks using multiple threat intelligence feeds. Sentinel can initiate a coordinated response and retain data long term for compliance purposes.
Threat Hunting AWS CloudTrail with Sentinel
In this blog series, we will identify threat hunting opportunities in AWS logs. Using a test AWS environment that emulated a small organization (with a set of users, roles, groups, and policies) we will go over attack simulations to identify suspicious activity that can be leveraged into hunting queries and custom detections. In each section, we will break down each simulation attack, from its set up to how to analyze the logs uncovered by Sentinel using KQL queries. This series provides SOC teams valuable insight into adversary tactics, techniques and procedures (TTPs) that are cloud-specific.
Simulated Attacks in AWS Environment
Attacks and detection techniques deployed in our AWS testing environment can be mapped back to the MITRE ATT&CK® framework, which was expanded to cover cloud attacks. This is a great resource for strategizing hunting methods. Refer to the table below to view the breakdown of each attack.[KJ1] [SF2]
|Operations in S3 Buckets (Part II -add link)||AWS||Collection||T1530||Data from Cloud Storage Object||Access data from improperly secured S3 bucket|
|Back Door (Part III-add link)||AWS||Persistence||T1078.004||Valid Accounts: Cloud Accounts||Second IAM key created|
|Atomic (Part IV-add link)||AWS||Persistence||T1136.003||Create Cloud Account||Create New IAM User|
|AWS||Persistence||T1098.001||Account Manipulation: Additional Cloud Credentials||Create Programmatic Access Keys|
|AWS||Persistence||T1098||Account Manipulation||Create New AWS Group|
Attacks executed in our AWS test environment:
- Steals credentials from a misconfigured S3 buckets
- Creates a second set of keys for an admin user
- Obtains security token within the compromised AWS account
- Creates a new IAM user
- Creates access keys for the new IAM user
- Creates group and adds new user to the group
Offensive Security Toolkits Used for Attacks
To conduct our simulations, we utilized open-source toolkits. In the first attack, we used the multi-cloud OSINT tool “cloud_enum” that produced a scan of our S3 buckets. In the second attack, we utilized “Pacu,” from Rhino Security Labs, with the backdoor module. And in our final attacks, we used the “Atomic Red Team” library that was built specific to AWS.
Conducting adversary simulations can provide a clearer image of what threat actors may do in cloud environments and how they differ from traditional on-premises attacks. In this four-part series, we demonstrated common attack scenarios. We enabled log data via CloudTrail and ingested them into Sentinel – which recently released new data connector that can ingest VPC Flow Logs, GuardDuty and CloudTrail (management and data events). Sentinel also has built-in hunting queries supporting MITRE ATT&CK techniques. Once all relevant data was onboarded onto Sentinel, we were able to detect our simulated threat activity with KQL queries that you can apply in your own threat hunts.
In part 2 of this blog series, we simulated an attack on a misconfigured S3 bucket with the open-source OSINT tool “cloud_enum” and the AWS CLI.