Inside a AWS Incident with Invictus: Analyzing the Attack for Detection Insights

An in-depth analysis of a month-long AWS incident response engagement conducted by Invictus delves into a sustained intrusion, showcasing the threat actor's technical proficiency in navigating the AWS environment while cognizant of detection mechanisms. The incident began when a suspicious support case was created in the client's AWS account, raising concerns about the use of Simple Email Service (SES) which was abnormal given the organization did not utilize the service. Invictus' analysis identified the initial access was gained through an exposed long-term access key with Administrator Access privileges and at the center of the case is an IAM user named DangerDev@protonmail[.]me.

Diving into a three-phase outline of the intrusion the threat actor began utilizing discovery commands pertaining to the Simple Email Service, specifically querying both the quota limit and a list of identities. The threat actor's activity was intermittent with breaks ranging from two days to two weeks between various discovery commands. While initiating reconnaissance and enumeration commands, Invictus observed the TA does not run "typical enumeration commands like GetCallerIdentity and ListAttachedUserPolicies," a potential sign the threat actor recognizes the detections oriented around those API calls. Following the rounds of discovery, the instantiation of the DangerDev@protonmail[.]me was made in IAM. The newly created user was elevated with capabilities to utilize the AWS console and given admin access with the AdministratorAccess policy.

The second phase commenced after a week-long pause, indicated by a surge in AWS API activity. The most abundant calls were made targeting EC2 services, with prominent calls to 'DescribeInstances', suggesting an in-depth examination of EC2 instances. Other significant API calls include those querying VPCs, subnets, and security groups, to examine network configurations and security parameters. A concentrated effort to establish persistence was evident, with a 30-minute focus following the discovery activity, on setting up infrastructure through APIs like CreateKeyPair and RunInstances. Notably, the security group was configured to permit unrestricted RDP access via port 3389. The threat actor gave a preview of their endgame briefly testing EC2 instance deployments, with both small and large instances being activated and then terminated within an hour.

In the final phase, the TA continued to create users and roles while testing actions related to AWS Systems Manager and AWS Secrets Manager. Invictus highlights and warns of a notable action involving the creation of roles that allowed identities from an external AWS account to assume privileged roles within the victim's AWS environment. This means that individuals or entities from an external AWS account could gain elevated permissions within the victim's account. These roles were created with names similar to existing roles, such as "AWSLanding-Zones-ConfigRecorderRoles."

After the creation of these roles, the threat actor performed an "AssumeRole" event, where they assumed these roles from their own AWS account (ID: 671050157472). This maneuver allowed them to gain elevated privileges and access within the victim's AWS environment, potentially enabling further malicious activities. AWS account 265857590823 is also called out, and recognized by AWS as a malicious account. Defense evasion efforts included removing IAM users, and policies, deactivating access keys, and inspecting GuardDuty findings. Additionally, the TA created a LightSail instance upon discovery. The impact of the attack included crypto mining attempts, phishing and spam campaigns through SES, and the creation of fake domains for spear phishing and scams. The TA exhibited knowledge of AWS services, automation scripts, and financial motivations.