GetCallerIdentity in CloudTrail: The First Call Made With a Stolen Key

What it records

GetCallerIdentity returns the account ID, ARN and user ID of the identity whose credentials signed the request. CloudTrail logs it as a management event from sts.amazonaws.com with readOnly true in the recorded events, and both requestParameters and responseElements are null there: there is nothing to request, and the answer is not repeated because userIdentity already holds it.

AWS states that the call needs no permissions and still works when a policy explicitly denies sts:GetCallerIdentity, since the same information comes back when access is denied. Every valid credential can make the call, whatever its permissions, and nothing about it fails, which makes it the cheapest way to check that a key works.

When it matters

Because it always succeeds and changes nothing, GetCallerIdentity is the first call people make with credentials they have just found: to learn whose key it is and which account it opens (MITRE ATT&CK T1087.004). Leaked keys in code repositories, CI logs and public container images are tested this way, and an attacker who already holds a key runs it to confirm which identity a session acts as.

The same call is made all day by legitimate tooling, so a record is suspicious only in context:

• A long-term key (AKIA…) used from a new place. Its first call from an address, network or country it has never used, especially a hosting provider, is the classic sign of a leaked key being tested.
• A client the key has never used, such as a scripting SDK for a key that normally runs a single application.
• What follows. Discovery calls (ListBuckets, ListUsers, Describe* across services) or persistence (CreateAccessKey, CreateUser, CreateLoginProfile) from the same key and address minutes later turn a test into an intrusion.

How to investigate

1. Note userIdentity.accessKeyId, userIdentity.arn, sourceIPAddress and userAgent.
2. Compare the address and client with the key’s history. A key that has always called from your build servers and now calls from elsewhere is enough to act on.
3. List every event with the same userIdentity.accessKeyId from the first unfamiliar call onwards. For an ASIA key, also follow the identity in userIdentity.sessionContext.sessionIssuer.arn back to where the session came from.
4. If the activity is not explained, deactivate the key with UpdateAccessKey, then look for persistence it created.

GetCallerIdentity calls in Microsoft Sentinel from a key and address pair not seen in the previous 30 days:

let Known = AWSCloudTrail
    | where TimeGenerated between (ago(30d) .. ago(1d))
    | distinct UserIdentityAccessKeyId, SourceIpAddress;
AWSCloudTrail
| where TimeGenerated > ago(1d)
| where EventName == "GetCallerIdentity"
| join kind=leftanti Known on UserIdentityAccessKeyId, SourceIpAddress
| project TimeGenerated, UserIdentityArn, UserIdentityType, UserIdentityAccessKeyId, SourceIpAddress, UserAgent

Everything a long-term key did in the hour after such a call:

let Tested = AWSCloudTrail
    | where TimeGenerated > ago(1d)
    | where EventName == "GetCallerIdentity" and UserIdentityAccessKeyId startswith "AKIA"
    | summarize TestedAt = min(TimeGenerated) by UserIdentityAccessKeyId;
AWSCloudTrail
| where TimeGenerated > ago(1d)
| join kind=inner Tested on UserIdentityAccessKeyId
| where TimeGenerated between (TestedAt .. (TestedAt + 1h))
| summarize Calls = count(), Actions = make_set(EventName, 40), Addresses = make_set(SourceIpAddress, 10)
    by UserIdentityAccessKeyId, UserIdentityArn

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

SELECT useridentity.accesskeyid, useridentity.arn, sourceipaddress, useragent,
       min(eventtime) AS first_seen, count(*) AS calls
FROM cloudtrail_logs
WHERE eventname = 'GetCallerIdentity'
GROUP BY useridentity.accesskeyid, useridentity.arn, sourceipaddress, useragent
ORDER BY first_seen DESC
LIMIT 200;