Skip to content

CreateAccessKey

AWS

CreateAccessKey

service: AWS - IAM
techniques:

Event

CreateAccessKey creates a long-term programmatic credential for an IAM user. The API can also create a root access key when called in the corresponding context without a user name; inspect the identity rather than assuming every request targets an IAM user. AWS API reference.

Security Context

An attacker who can create a key for another identity may gain durable access through that identity. The impact depends on the target’s permissions; creating a key does not itself add privileges to the target user.

Legitimate uses: a documented key rotation or provisioning for a workload that still uses IAM user credentials. Cross-user creation can be approved administration, so compare the actor, target, and change record.

Mapping rationale: adding a credential to an existing account supports the Additional Cloud Credentials mapping when used to retain or extend access. A successful creation is not, by itself, evidence that the new key was used.

Log Source

Search CloudTrail management events for eventSource: iam.amazonaws.com and eventName: CreateAccessKey. Include write management events and global-service activity in the trail collection strategy. IAM logging guidance.

Key Fields

FieldInvestigation use
userIdentity.arnIdentify who requested the new credential.
requestParameters.userNameIdentify the requested target when present; omission does not mean the request had no target.
responseElements.accessKey.userNameConfirm the resulting key owner when included.
responseElements.accessKey.accessKeyIdPivot to use of the new key; do not confuse it with the caller’s key.
userIdentity.accessKeyIdIdentify the credential used to perform the creation.
errorCode and errorMessageSeparate unsuccessful attempts from completed creation.

What to Investigate

  1. Confirm the target user and compare its access with the creator’s. Explain any cross-user creation using the approved workflow, not just the display names.
  2. Search later events for the new access key ID. Check its first observed origin, services accessed, and whether the activity matches the expected workload.
  3. Review nearby AttachUserPolicy and PutUserPolicy calls for changes to the target’s permissions.
  4. For an expected rotation, look for UpdateAccessKey or DeleteAccessKey affecting the old key. Creation alone does not prove rotation finished.

Sample Event

Synthetic scenario — approved provisioning. Hermione creates a key for Ron for a planned migration. The different caller and target warrant context, not an automatic malicious verdict. The response key ID is the investigation pivot; the sample contains no secret access key.

{
"eventVersion": "1.09",
"userIdentity": {
"type": "IAMUser",
"principalId": "AIDAHERM10NE000ADM1N",
"arn": "arn:aws:iam::555123456789:user/hermione",
"accountId": "555123456789",
"accessKeyId": "ASIAHERM10NEEXAMPLE1",
"userName": "hermione",
"sessionContext": {
"attributes": {
"creationDate": "2026-04-15T13:42:11Z",
"mfaAuthenticated": "true"
}
}
},
"eventTime": "2026-04-15T14:07:33Z",
"eventSource": "iam.amazonaws.com",
"eventName": "CreateAccessKey",
"awsRegion": "us-east-1",
"sourceIPAddress": "198.51.100.42",
"userAgent": "aws-cli/2.15.30 Python/3.11.6 Linux/5.15.0-1052-aws exe/x86_64.ubuntu.22 prompt/off command/iam.create-access-key",
"requestParameters": {
"userName": "ron"
},
"responseElements": {
"accessKey": {
"userName": "ron",
"accessKeyId": "AKIAR0NWEA5LEYEXAMP2",
"status": "Active",
"createDate": "Apr 15, 2026 2:07:33 PM"
}
},
"requestID": "90000000-0000-4000-8000-000000000001",
"eventID": "90000000-0000-4000-8000-000000000010",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "555123456789",
"eventCategory": "Management",
"tlsDetails": {
"tlsVersion": "TLSv1.3",
"cipherSuite": "TLS_AES_128_GCM_SHA256",
"clientProvidedHostHeader": "iam.amazonaws.com"
}
}

Sources

MITRE ATT&CK Mapping

Tactics: Persistence Privilege Escalation

Techniques:
  • T1098.001 — Additional Cloud Credentials — Adversaries may add adversary-controlled credentials to a cloud account to maintain persistent access to victim accounts and instances within the environment.
Documentation reviewed: September 28, 2026. Samples are synthetic illustrations, not captured production logs or lab-validated fixtures.