Detecting Backdoor Attacks
By Sean Fernandez | Threat Researcher | Binary Defense
In , Threat Hunting AWS CloudTrail with Sentinel, we simulated a series of adversary attacks focusing on persistence with backdoor access to a secondary access key and temporary security credentials. The attacks were deployed on our test AWS environment that emulated a small organization with a set of users, roles, groups, and policies. We utilized Sentinel to gather raw event information and to analyze the logs produced during the simulation.
We’ll walk through the steps to conduct the simulation, how to analyze the logs uncovered by
sentinel and most importantly the way we can detect threat activity with KQL queries, which can be applied in your own threat hunts.
Attack 01: Attacker Creates a Secondary Access Key for an IAM User
In this scenario, the threat actor has valid credentials and has authenticated via the AWS CLI as the ‘AWSCloudAdmin’ user. The attack commands will operate within the AWScloudAdmin context. Next, the actor will enumerate the account for users and access keys. The actor then targets the ‘BackupAdmin’ and lists the active keys for the user. After determining that the ‘BackupAdmin’ has one active primary access key, a secondary set is created.
Before initiating the attack, the AWS CLI must be installed and configured with the AWS default profile using:
~$ aws configure
// enumerate IAM users ~# sudo aws iam list-users --AWSCloudAdmin
// enumerate active keys // Determine if the target has one or two active keys ~$ sudo aws iam list-access-keys --user-name BackupAdmin --profile AWSCloudAdmin
Displays the user has one access key // Create a new access key for the target user ~$ sudo aws iam create-access-key --user-name BackupAdmin --profile AWSCloudAdmin
// Lists active keys ~$ sudo aws iam list-access-keys –user-name BackupAdmin –profile AWSCloudAdmin
The threat actor successfully created a secondary access key and now has a backdoor authentication method for the IAM ‘BackupAdmin’ account. This also provides a secondary option to authenticate if access was lost to the primary keys.
Attack 02: Backdoor Access and Privilege Escalation with Temporary Credentials
In this attack, the threat actor abuses an AWS AssumeRole policy that assigns temporary token credentials, which can also grant access to additional resources within the account.
The diagram below illustrates how the actor makes the API call to the Security Token Service (STS) and receives temporary, limited-privilege credentials.
For this attack, we leveraged the open-source AWS security-testing kit, Pacu from Rhino Security Labs.
Pacu was designed for offensive security testing against cloud environments and exploits configuration flaws within an AWS account.
// Launch Pacu ~$ sudo python3 cli.py // named the session Pacu> backdoor
// Imports keys from the AWSCloudAdmin account // Any commands run within Pacu will operate within the AWScloudAdmin context Pacu> import_keys AWSCloudAdmin
Pacu> run iam__enum_users_roles_policies_groups Pacu> run iam__enum_permissions
// Pacu iam_backdoor_assume_role module // Attempts to locate a policy to backdoor Pacu> run iam_backdoor__assume_role
// lists the backdoored policies ~$ sudo aws iam get-role --role-name Administrators --profile AWSCloudAdmin
Successfully executed, the threat actor can call on the policy that will assign temporary security credentials as a means of backdoor access and privilege escalation.
Hunting CloudTrail Logs in Sentinel with KQL Queries
The following is a breakdown of our CloudTrail log analysis and hunting process of the API calls during our simulation. The CloudTrail logs ingested into Sentinel were first analyzed with basic KQL queries. To further narrow in on the attacks more specific queries were executed.
Hunting for access key creation
Query filters: CreateAccessKey and UserIdentityUserName AWSCloudTrail | where EventName in ("CreateAccessKey", " UserIdentityUserName ") | distinct TimeGenerated, EventName, UserIdentityUserName, RequestParameters, SourceIpAddress, UserAgent | sort by TimeGenerated asc
Hunting for AWS account enumeration
Query filters: ListAccessKeys, ListUsers, ListGroups, ListRolePolicies
AWSCloudTrail | where EventName in ("ListAccessKeys", "ListUsers", "ListGroups", "ListRolePolicies", "GetCallerIdentity") | distinct TimeGenerated, EventName, UserIdentityUserName, RequestParameters, SourceIpAddress, UserAgent | sort by TimeGenerated asc
Hunting for suspicious user agents
Query filters: “Kali”
AWSCloudTrail | where UserAgent has "kali" | distinct TimeGenerated, EventName, UserIdentityUserName, RequestParameters, SourceIpAddress, UserAgent | sort by TimeGenerated asc
Hunting for created roles
Query filters: CreateRole
// Investigate created roles and who created them AWSCloudTrail | where ReqeustParameters has “CreateRole” | sort by TimeGenerated asc
Hunting for a role added to an instance profile
Query filters: AssumeRole and UserIdentityUserName
// Investigate role added to the instance profile AWSCloudTrail | where UserIdentityUserName == "AWSCloudAdmin" | where RequestParameters has "AssumeRole" | sort by TimeGenerated asc
Hunting for a specific role
Query filters: UserIdentityUserName, GetRole, RequestParameters
// Investigating specific API activity AWSCloudTrail | where UserIdentityUserName == "AWSCloudAdmin" | where EventName has "GetRole" | where RequestParameters has "Administrators" | sort by TimeGenerated asc
SOC analysts managing cloud SEIM assets should set detections on enumeration commands, which create a lot of noise during the threat actor’s information harvesting phase. Additional malicious indicators can include accounts created from unrecognized IPs, different city/state, country from admin(s) and abnormal user hours. Detections can also monitor the threshold for allotted admins on an account.
In order to effectively detect these attacks, SOC Analysts can alert on the events we investigated and build custom detections for your environment.
The API actions logged in our simulation include:
Utilizing test environments to run adversary simulations can generate useful data, which can be further analyzed through hunting queries that can expose suspicious activities. Mitigating found flaws and incidents can provide metrics for prioritizing event logs in cloud. Build baselines and tune false positives to more effectively monitor cloud assets.
In our next blog, we’ll look at Atomic Red Team Attacks with “Atomics” built specifically for AWS.