Thomas J Nagel – CISSP, CPTS, SSCP

🔐We Watched You Delete the Key

🔐We Watched You Delete the Key
You thought that was the end.

You opened the console.
You deleted the access key.
You told the room, “We’re good. They’re out.”

We were still logged in.

IAM Doesn’t Mean Immediate

AWS IAM is eventually consistent.
That’s not a footnote — that’s an opening.

When you delete a key, detach a policy, or revoke a role, the control plane doesn’t snap shut. It drifts. For a few seconds, the old reality and the new one overlap.

That overlap is where we live.

Four seconds is generous.
Four seconds is eternity.

Especially when we’re not human.

The Moment You Touched IAM, We Knew

We don’t guess when you’re responding.

We poll:

  • sts:GetCallerIdentity
  • harmless-looking API calls
  • permission checks that cost nothing and tell us everything
When behavior changes — latency, denial, error shape — we know the cleanup started.

That’s the signal.

What We Do Before It’s “Deleted”

Once the signal hits, it’s muscle memory:

  • Create a new access key
  • Assume a role one last time
  • Attach something you didn’t review
  • Create something you won’t notice
  • Leave behind something that looks legitimate

Sometimes it’s a role.
Sometimes it’s a policy.
Sometimes it’s a Lambda with a name that matches your naming standard.

You call it cleanup.
We call it persistence refresh.

You Believe in State. We Believe in Timing.

You think in objects:

  • users
  • roles
  • policies

We think in milliseconds.

We don’t need long access.
We need just enough.

Your revocation didn’t fail.
It just arrived late.

Why This Works So Often

Because your incident response assumes something that isn’t true:

“If the key is deleted, access is gone.”

IAM doesn’t work like that.

The system lies briefly — and consistently — every time you change it.

That lie is exploitable.
Predictable.
Automatable.

And once you know it’s there, you plan around it.

How We Survive Your Containment

Here’s what actually keeps us in:

  • Sequential cleanup instead of immediate deny
  • No SCPs during response
  • Long-lived credentials
  • No alerting on IAM writes during IR
  • No expectation that the attacker will fight back
You clean.
We counter.

And by the time you’re done, we’re no longer using the thing you deleted.

The Part Defenders Hate

The most dangerous moment of a cloud intrusion isn’t initial access.

It’s when you realize we’re there.

That’s when we move fastest.
That’s when you make the most assumptions.
That’s when the gap matters.

How You Actually Beat This (And Most Teams Don’t)

If you want us gone, you don’t start with IAM.

You start with denial that doesn’t propagate.

  • SCPs that say “no” everywhere, instantly
  • Account-level lockdowns
  • Blast-radius containment before cleanup
  • Controls that assume we’re watching you
You don’t revoke.
You suffocate.

Then — and only then — you clean.

Final Truth

IAM eventual consistency isn’t a bug.
It’s a feature we’ve already weaponized.

If your response plan doesn’t assume:

  • we’re automated
  • we’re watching
  • we will react immediately

Then we’ll be there after the postmortem.

Not because you missed something.

Because you trusted deletion to mean now.

And in AWS…

“Now” doesn’t exist.