Suspicious AWS EC2 Key Pair Creation from Non-Cloud Autonomous System

Adversaries targeting AWS environments may attempt to establish persistence or prepare for unauthorized access to EC2 instances by creating new SSH key pairs. This brief details an Elastic detection rule designed to identify such suspicious activity. The rule triggers when an AWS IAM principal successfully executes the CreateKeyPair API call from a network whose Autonomous System (AS) organization is not a recognized cloud provider (such as Amazon, Google, or Microsoft). This detection is particularly sensitive as it focuses on the first time a given principal performs this action from an unusual source AS, which can be an early indicator of a compromised account being used to stage access materials. Defenders should investigate these alerts to determine if the activity aligns with legitimate operational changes or represents an attacker's attempt to gain a foothold.

Attack Chain

1. Initial Access: An adversary gains unauthorized access to an AWS environment, often by compromising an IAM user or role via phishing, exposed credentials, or exploiting a vulnerable application.
2. Credential Compromise: The attacker acquires credentials for an existing IAM principal (user or role) within the target AWS account.
3. Persistence Staging: Using the compromised credentials, the attacker calls the CreateKeyPair API from an unusual network location (i.e., an AS organization not belonging to a major cloud provider). This action generates a new SSH key pair.
4. Key Material Exfiltration: The CreateKeyPair API returns the private key material to the caller. The attacker immediately downloads and stores this private key.
5. SSH Access Preparation: The newly created public key is associated with the AWS account, allowing it to be injected into new or existing EC2 instances.
6. Lateral Movement/Persistence: The attacker uses the exfiltrated private key to establish SSH connections to EC2 instances launched with, or updated to use, this key pair, thereby achieving persistence and enabling further malicious activities.
7. Impact: Once SSH access is established, the attacker can perform actions such as data exfiltration, deployment of malicious software, or further enumeration of the environment.

Impact

If adversaries successfully create and leverage new EC2 key pairs from unusual network locations, it directly leads to unauthorized persistence and potential remote access to critical cloud infrastructure. This can enable a range of damaging activities, including data theft from EC2 instances or S3 buckets, resource hijacking for cryptocurrency mining, further privilege escalation within the AWS environment, or disruption of services. Such breaches can result in significant financial losses due to compromised data, operational downtime, and regulatory fines, alongside severe reputational damage. The ability to maintain access via SSH keys makes detection and remediation challenging, allowing attackers extended dwell time.

Recommendation

• Deploy the Sigma rule AWS_EC2_CreateKeyPair_New_Principal_Non_Cloud_AS to your SIEM to detect suspicious CreateKeyPair activity.
• Ensure AWS CloudTrail logging is enabled and configured to capture event.dataset: "aws.cloudtrail" data, including event.provider: "ec2.amazonaws.com" and event.action: "CreateKeyPair".
• Investigate all alerts generated by the AWS_EC2_CreateKeyPair_New_Principal_Non_Cloud_AS rule, examining aws.cloudtrail.request_parameters, response_elements for keyName, and correlating source.ip, source.geo, and user_agent.original with the principal’s normal administrative paths.
• If unauthorized activity is confirmed, delete the suspicious key pair using DeleteKeyPair, review IAM policies for ec2:CreateKeyPair permissions, and rotate any credentials used by the compromised IAM principal.