CreateAccessKey in CloudTrail: Spotting Backdoor AWS Access Keys

What it records

CreateAccessKey creates a long-term access key for an IAM user. AWS documents that new keys are Active and that, without a user name, IAM uses the identity that signed the request, which means the call also creates access keys for the root user. The record from iam.amazonaws.com names the creator in userIdentity, the target in requestParameters.userName, and the new key in responseElements.accessKey: its accessKeyId, userName, status and createDate. The secret access key is never in it; AWS notes the secret is only available when the key is created.

The recorded attack-simulation event below is a management event with readOnly false, made with one user’s key for another user. That shape, one identity creating a key for a different one, is the attack the event is watched for.

When it matters

An access key is the easiest durable foothold in AWS: it works from anywhere, needs no MFA and survives a password reset. Creating one for an existing user is MITRE ATT&CK T1098.001 (additional cloud credentials). The records worth stopping on:

• A key created for someone else. requestParameters.userName differs from the caller, particularly when the caller is a role session, a workload identity or an unfamiliar address.
• A root access key. userIdentity.type Root and no user name in the request.
• A second key for a user. The user’s existing key creating another one keeps access alive after the first is rotated or disabled.
• The sequence around it. GetCallerIdentity from a new address, then CreateUser, CreateAccessKey and AttachUserPolicy in a few minutes is a stolen key building a backdoor account.

How to investigate

1. Read who created the key (userIdentity.arn, userIdentity.accessKeyId, sourceIPAddress, userAgent) and for whom (requestParameters.userName, responseElements.accessKey.userName).
2. Ask the owner of the target user whether they requested a key. Developers rarely create keys for other people’s accounts.
3. Follow the new key: every event whose userIdentity.accessKeyId equals responseElements.accessKey.accessKeyId.
4. Look at the creator’s other calls in the same hour for users, login profiles, policy attachments and changed role trust policies, and deactivate the key with UpdateAccessKey while you confirm.

New keys in Microsoft Sentinel, with the ones created by someone other than the key’s owner flagged:

AWSCloudTrail
| where TimeGenerated > ago(7d)
| where EventName == "CreateAccessKey" and isempty(ErrorCode)
| extend Response = parse_json(ResponseElements)
| extend KeyOwner = tostring(Response.accessKey.userName), NewKeyId = tostring(Response.accessKey.accessKeyId)
| extend MadeBySomeoneElse = UserIdentityType != "IAMUser" or KeyOwner != UserIdentityUserName
| project TimeGenerated, UserIdentityType, UserIdentityArn, KeyOwner, NewKeyId, MadeBySomeoneElse, SourceIpAddress, UserAgent
| order by TimeGenerated desc

What each new key did after it was created:

let NewKeys = AWSCloudTrail
    | where TimeGenerated > ago(7d)
    | where EventName == "CreateAccessKey" and isempty(ErrorCode)
    | project CreatedAt = TimeGenerated, CreatedBy = UserIdentityArn,
        NewKeyId = tostring(parse_json(ResponseElements).accessKey.accessKeyId);
AWSCloudTrail
| where TimeGenerated > ago(7d)
| join kind=inner NewKeys on $left.UserIdentityAccessKeyId == $right.NewKeyId
| summarize FirstUse = min(TimeGenerated), Calls = count(), Actions = make_set(EventName, 30),
    Addresses = make_set(SourceIpAddress, 10) by NewKeyId, CreatedBy, CreatedAt

In Athena, over a table on the trail’s S3 bucket (named cloudtrail_logs here):

SELECT eventtime, useridentity.type, useridentity.arn AS created_by,
       json_extract_scalar(responseelements, '$.accessKey.userName') AS key_owner,
       json_extract_scalar(responseelements, '$.accessKey.accessKeyId') AS new_key,
       sourceipaddress, useragent
FROM cloudtrail_logs
WHERE eventname = 'CreateAccessKey' AND errorcode IS NULL
ORDER BY eventtime DESC
LIMIT 200;