CyberDefenders — AWSRaid Lab Writeup
Overview
In this incident response investigation, we analyze an AWS environment compromise that began with a successful brute-force attack against a high-privileged IAM user. The attacker leveraged compromised credentials to gain entry via the AWS Management Console, subsequently performing reconnaissance on S3 storage to identify sensitive CAD designs and intellectual property. The scope of the attack expanded as the adversary actively manipulated S3 security configurations to remove public access blocks, creating a significant risk of data exposure.
To ensure long-term access, the attacker executed persistence maneuvers by creating a backdoor IAM account and elevating its privileges through group membership. This writeup demonstrates the critical importance of monitoring CloudTrail logs for unusual sign-in patterns and unauthorized modifications to account-level security guardrails. By correlating authentication failures with subsequent API calls, we can effectively map the attacker’s path from initial access to data exfiltration and persistence.
Scenario
Your organization utilizes AWS to host critical data and applications. An incident has been reported that involves unauthorized access to data and potential exfiltration. The security team has detected unusual activities and needs to investigate the incident to determine the scope of the attack.
Lab Reference: Blue team CTF Challenges | AWSRaid
Analysis
Q1. Knowing which user account was compromised is essential for understanding the attacker’s initial entry point into the environment. What is the username of the compromised user?
Run the following query to identify pattens of failed authentication attempts. While a couple of failed authentications signal user error, an abnormally large number within a short span of time requires investigation.
index="aws_cloudtrail" eventSource="signin.amazonaws.com" eventType=AwsConsoleSignIn
| table _time, sourceIPAddress, userAgent, userIdentity.userName, errorMessage
On 2023–11–02 at 09:54:04 a successful authentication event is logged from 185.192.70.84 for the helpdesk.luke account following 9 failed attempts within ~40 seconds.
Q2. We must investigate the events following the initial compromise to understand the attacker’s motives. What is the timestamp for the first access to an S3 object by the attacker?
Set your time filter to limit results to event immediately following the successful authentication. Focus on AwsApiCall events, where the user is helpdesk.luke. By selecting a few important fields we can quickly identify the first S3 bucket accessed by the attacker at 09:55:53.
index="aws_cloudtrail" "userIdentity.userName"="helpdesk.luke" userAgent="[Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36]"
| stats count by _time, eventType, sourceIPAddress, requestParameters.bucketName
| sort -_time
Q3. Among the S3 buckets accessed by the attacker, one contains a DWG file. What is the name of this bucket?
A slight modification to the previous query will help us find what we need — add the field “resources{}.ARN” and review the results. We can confirm that the product-designs-repository31183937 bucket contains a file named “Product2_CAD_Designs.dwg”.
index="aws_cloudtrail" "userIdentity.userName"="helpdesk.luke" userAgent="[Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36]"
| stats count by _time, eventType, sourceIPAddress, requestParameters.bucketName, resources{}.ARN
| sort -_time
Q4. We’ve identified changes to a bucket’s configuration that allowed public access, a significant security concern. What is the name of this particular S3 bucket?
Get JBXSec’s stories in your inbox
Join Medium for free to get updates from this writer.
In AWS CloudTrail, the PutBucketPublicAccessBlock event name indicates that a user or process has configured or modified the "Public Access Block" settings for a specific Amazon S3 bucket. This API call is used to explicitly enforce restrictions that prevent the bucket and its objects from being made publicly accessible via ACLs or bucket policies.
Run the SPL query shown below to visualize a series of “Get” requests to obtain current configuration, followed by a “PutBucketPublicAccessBlock” where the configuration to block access is set to “false”, i.e., disabled — this removed public access restrictions normally in place to safeguard sensitive contents.
index="aws_cloudtrail" "userIdentity.userName"="helpdesk.luke" "*public*"
| stats count by _time, userIdentity.userName, sourceIPAddress, eventName
| sort -count
index="aws_cloudtrail" "userIdentity.userName"="helpdesk.luke" "*public*"
| stats count by _time, userIdentity.userName, eventName, requestParameters.PublicAccessBlockConfiguration.BlockPublicPolicy
| sort -count
To obtain the bucket name, add the requestParameters.bucketName field to your query:
index="aws_cloudtrail" "userIdentity.userName"="helpdesk.luke" "*public*"
| stats count by _time, userIdentity.userName, eventName, requestParameters.PublicAccessBlockConfiguration.BlockPublicPolicy, requestParameters.bucketName
| sort -countThis setting was applied to the backup-and-restore98825501 bucket.
Q5. Creating a new user account is a common tactic attackers use to establish persistence in a compromised environment. What is the username of the account created by the attacker?
Search for the “CreateUser” eventName to identify the newly created user.
index="aws_cloudtrail" "*CreateUser*"
On 2023–11–02 at 09:59:33 the helpdesk.luke (compromised user) created a new user “marketing.mark” for persistence.
Q6. Following account creation, the attacker added the account to a specific group. What is the name of the group to which the account was added?
adding to our previous query, filter for eventName=AddUserToGroup, where marketing.mark is included in the record.
index="aws_cloudtrail" "*marketing.mark*" eventName=AddUserToGroup
On 2023–11–02 at 09:54:04 the marketing.mark user was added to the Admins group.
Summary
The investigation concludes that the threat actor successfully established a foothold in the environment through a brute-force attack, eventually gaining access to the helpdesk.luke account. Once inside, the adversary focused heavily on data discovery and the systematic degradation of security controls, specifically targeting S3 buckets containing sensitive CAD designs. By executing a PutBucketPublicAccessBlock command with all protective parameters disabled, the attacker successfully neutralized the environment’s automated safety guardrails, preparing the backup-and-restore98825501 bucket for potential public exfiltration.
The incident escalated from a simple data breach to a long-term security risk when the attacker moved to establish persistence. By creating the marketing.mark user and immediately assigning it to the Admins group, the actor ensured they would maintain full administrative control even if the initial compromised credentials were reset. This sequence of events highlights a classic progression from initial access to privilege escalation, underscoring the need for immediate, automated alerting on any modifications to IAM identities or global S3 security settings.
