Detecting AWS Access Key Abuse in CloudTrail

Long-lived access keys leak through public repositories, build logs, laptops and misconfigured servers, and attackers test them within minutes. CloudTrail records every call with the key ID, source IP, user agent and region, so each key has a behavioural fingerprint you can baseline. A new fingerprint plus an enumeration burst is the standard compromise pattern.

Signals at a Glance

Baselining a Key

The Athena cloudtrail_logs table exposes useridentity.accesskeyid, sourceipaddress, useragent and awsregion. Compare the last day against the preceding month and keep keys whose source is new:

-- Athena SQL - access keys used from an IP never seen in the prior 30 days
WITH history AS (
  SELECT DISTINCT useridentity.accesskeyid AS keyid, sourceipaddress
  FROM cloudtrail_logs
  WHERE from_iso8601_timestamp(eventtime) BETWEEN current_timestamp - interval '30' day
                                               AND current_timestamp - interval '1' day
    AND useridentity.accesskeyid IS NOT NULL
),
recent AS (
  SELECT useridentity.accesskeyid AS keyid, useridentity.arn AS arn, sourceipaddress,
         awsregion, useragent, count(*) AS calls, min(eventtime) AS first_seen
  FROM cloudtrail_logs
  WHERE from_iso8601_timestamp(eventtime) > current_timestamp - interval '1' day
    AND useridentity.type = 'IAMUser'
    AND useridentity.accesskeyid IS NOT NULL
  GROUP BY 1, 2, 3, 4, 5
)
SELECT r.*
FROM recent r
LEFT JOIN history h ON r.keyid = h.keyid AND r.sourceipaddress = h.sourceipaddress
WHERE h.keyid IS NULL
ORDER BY calls DESC;
-- tune/validate: add partition predicates (year, month, day) for cost; exclude AWS service IPs (sourceipaddress like '%.amazonaws.com')

• Rank candidates by what the key did, not only that it moved: IAM, STS, S3 and EC2 calls from a fresh IP deserve the fastest look.
• Enable GuardDuty; its credential exfiltration finding for instance credentials used outside AWS is high confidence and cheap to route.
• Replace long-lived user keys with roles and short-lived credentials so the baseline question becomes much smaller.

Enumeration and Honeytokens

After a successful call, attackers map what the key can do. A short burst of distinct read-only calls across many services, often starting with GetCallerIdentity, is the discovery signature. Many of these calls fail with AccessDenied, which is itself useful:

-- Athena SQL - enumeration burst: many distinct List/Describe/Get calls and denials from one key
SELECT useridentity.accesskeyid AS keyid, sourceipaddress,
       count(DISTINCT eventname) AS distinct_calls,
       count(DISTINCT eventsource) AS services,
       count_if(errorcode IN ('AccessDenied', 'UnauthorizedOperation', 'Client.UnauthorizedOperation')) AS denied,
       min(eventtime) AS first_call, max(eventtime) AS last_call
FROM cloudtrail_logs
WHERE from_iso8601_timestamp(eventtime) > current_timestamp - interval '1' day
  AND (eventname LIKE 'List%' OR eventname LIKE 'Describe%' OR eventname LIKE 'Get%')
  AND useridentity.accesskeyid IS NOT NULL
GROUP BY 1, 2
HAVING count(DISTINCT eventname) > 25 AND count(DISTINCT eventsource) > 4
ORDER BY distinct_calls DESC;
-- tune/validate: inventory and CSPM tools enumerate by design; allowlist their keys and roles

• Plant canary access keys in repositories and wikis; any use of one is, by definition, unauthorised and can alert immediately.
• On confirmation, deactivate the key, then review everything it did, including role assumptions and new IAM users, before deleting it.