I made AWS email me the moment someone creates an access key. Here's the 10-minute setup.

Attackers love creating new access keys for persistence. A free, 10-minute CloudTrail + EventBridge + SNS lab that alerts you when it happens, with an attack test and cleanup included.

Shivaji Rathod

Cybersecurity Enthusiast | Aspiring Cloud Security Engineer

Published Oct 4, 2026

Last modified Oct 4, 2026

Quick question before we start

If someone created a new access key in your AWS account right now, how long until you'd notice?

A) Minutes, I have alerts
B) Whenever I check the console
C) Honestly, never

Most of us are B or C. Let's fix that in 10 minutes.

Why this alert?

After an attacker gets a foothold, one of the first moves is persistence: create a fresh access key for a user so they keep access even if you rotate the original credentials. It's quiet, cheap, and often unmonitored.

The good news: every one of those calls is recorded by CloudTrail, and EventBridge can react to it for free.

Flow diagram: attacker calls CreateAccessKey, IAM, CloudTrail, EventBridge rule, SNS topic, email alert

🧪 Lab (use a test account, region us-east-1)

IAM is a global service and its events show up in us-east-1, so build everything there.

1. Create the topic and subscribe your email

1
2
3
4
5
6
7
export AWS_REGION=us-east-1

TOPIC_ARN=$(aws sns create-topic --name iam-key-alerts \
  --query TopicArn --output text)

aws sns subscribe --topic-arn $TOPIC_ARN \
  --protocol email --notification-endpoint you@example.com

Confirm the subscription from your inbox.

2. Create the rule

1
2
3
4
5
6
7
8
9
10
11
12
aws events put-rule --name alert-create-access-key \
  --event-pattern '{
    "source": ["aws.iam"],
    "detail-type": ["AWS API Call via CloudTrail"],
    "detail": {
      "eventSource": ["iam.amazonaws.com"],
      "eventName": ["CreateAccessKey"]
    }
  }'

aws events put-targets --rule alert-create-access-key \
  --targets "Id=1,Arn=$TOPIC_ARN"

3. Let EventBridge publish to the topic. Without this, the alert silently goes nowhere.

1
2
3
4
5
6
7
8
9
10
aws sns set-topic-attributes --topic-arn $TOPIC_ARN \
  --attribute-name Policy --attribute-value '{
  "Version":"2012-10-17",
  "Statement":[{
    "Effect":"Allow",
    "Principal":{"Service":"events.amazonaws.com"},
    "Action":"sns:Publish",
    "Resource":"'"$TOPIC_ARN"'"
  }]
}'

🔴 Attacker test

Play the attacker against a throwaway IAM user:

1
2
aws iam create-user --user-name lab-victim
aws iam create-access-key --user-name lab-victim

Within a minute or two, an email should arrive. If it doesn't, check these in order: subscription confirmed? Region us-east-1? SNS policy applied?

🧹 Cleanup (don't skip)

1
2
3
4
5
6
aws iam list-access-keys --user-name lab-victim
aws iam delete-access-key --user-name lab-victim --access-key-id <KEY_ID>
aws iam delete-user --user-name lab-victim
aws events remove-targets --rule alert-create-access-key --ids 1
aws events delete-rule --name alert-create-access-key
aws sns delete-topic --topic-arn $TOPIC_ARN

🔵 Defender view: make it better

Raw JSON emails are ugly. Add an input transformer so the alert says who created a key for whom
Add a second rule for root console sign-ins
Route to Slack or a ticket instead of email
Add GuardDuty on top for behavior-based detection (unusual API calls, credential exfiltration)
Better yet: ask why anyone is creating long-lived keys at all. Roles and temporary credentials remove most of this problem

Where this falls short

It tells you that a key was created, not whether it's malicious. You still need to triage
Alert fatigue is real. Tune it before you add ten more rules
An attacker with enough permissions can tamper with rules, so protect them and send logs to a separate account

Your turn 💬

Did the alert fire for you? How long did it take?
What should we alert on next? Vote: 1) root login, 2) disabling CloudTrail, 3) public S3 bucket created
Drop your improved event pattern in the comments