The offboarding time bomb: how a departing engineer can weaponize aws-nuke

Yes, a departing engineer can wipe your AWS account, and they don’t even need to be there when it happens. If they held broad IAM access, they can schedule aws-nuke, a legitimate tool that deletes every resource in an account, to fire days after they’ve gone. With no monitoring of what privileged automation actually does, nobody sees it until the account is empty.

What is aws-nuke, and why is it dangerous in the wrong hands?

aws-nuke is an open-source tool that deletes every resource in an AWS account. It exists for a good reason: teams spin up test and sandbox accounts, and cleaning them by hand is miserable, so aws-nuke does it in one sweep.

By design it’s careful. It only lists resources unless you add --no-dry-run, and it asks twice for the account alias before it deletes anything. On a laptop, that’s plenty of friction to stop a mistake.

The problem is those guardrails are interactive. They protect a human at a terminal. Wire the same tool into a scheduled job with --no-dry-run baked in and no resources excluded, and the confirmations are gone. The tool doesn’t know the difference between a sandbox cleanup and your production account.

How does a departing engineer turn it into a time bomb?

They use the access they already have. A senior engineer or DevOps lead usually holds broad IAM permissions, often enough to create roles, Lambdas, and scheduled rules across the account. That broad access is the real weapon here.

The setup is quiet. Create a Lambda that runs aws-nuke against the account, give it a role with admin-level delete rights (they already had the authority to grant it), and trigger it on a schedule or a condition. A common variant is a logic bomb: the job stays dormant and fires only when something changes, like their own user getting disabled. So the offboarding itself pulls the trigger.

While it’s being built, none of it looks like an attack. It’s one more piece of automation in an account that already runs hundreds.

Why does nobody see it coming?

Two things hide it. One is that most small and mid-sized teams don’t watch what their privileged actions actually do. They keep CloudTrail logs, but you read a log afterward, and it can’t stop a deletion that’s already running. The other is that standing permissions go untracked. Nobody has a clean answer to “what could this person’s access still do?”, because it was handed out over years and never pulled back.

Offboarding makes it worse. Most checklists cover the SSO seat and forget the layer underneath, so long-lived keys, roles, and automation the person created keep working after they leave. Disabling a login does nothing to a Lambda that runs on its own role.

Put those together and a planted deletion job sits in plain sight with live permissions, waiting. Usually the outage is the first anyone hears of it.

Has this actually happened?

It has, more than once. In the cases below it came down to the same two things: access nobody switched off, and nothing watching what that access did.

At Cisco, an engineer resigned in April 2018 and his AWS credentials were never revoked. Months later he logged back in and deleted 456 virtual machines running WebEx Teams, taking down more than 16,000 accounts for up to two weeks and causing around $2.4 million in damage. He was sentenced to two years in prison. The tool was nothing exotic; his credentials just still worked.

In Singapore, an engineer fired from NCS used credentials that still worked and ran a script to delete 180 virtual servers, a cleanup that cost roughly S$678,000. In another case, a developer at Eaton planted a logic bomb set to trigger the moment his own account was disabled, and was sentenced to four years. We told these three stories in full over here: engineers who wiped their old companies.

How do you close the gap?

Trust doesn’t stop a deletion, and by the time a log shows one, it has already happened. The fix is layered, and every layer earns its place on its own.

Kill every path to access the day someone leaves, not just their login. That means IAM keys, active sessions, roles they can assume, and any automation they created, checked one by one rather than assumed handled by SSO.

Remove standing admin rights so no single person carries account-wide delete in the first place. Zero standing privileges and just-in-time access mean access is granted for a task and expires on its own, so a departing engineer has nothing lingering to abuse and no admin role to hand a Lambda.

And monitor privileged actions as they happen. A log tells you what was destroyed. A live control can catch the run mid-delete and cut the session there.

Where Korvalis fits

Korvalis is the live layer. It sits inside your own AWS account, watches what a privileged session is actually doing, and cuts it off in seconds when it turns destructive. It doesn’t care whether the actor is a person, an AI agent, or a job someone left running before they walked out. A mass deletion looks the same to it.

It also hands out access just-in-time, scoped and auto-expiring, so fewer sessions can go wrong and there’s less standing power to inherit. You install it observe-first, so it watches before it ever blocks, and you’re live in about half an hour with no security hire.

None of this makes your team trustworthy or your offboarding perfect. It means that when the standing access and the clean checklist both fail, which they do, something is still watching the actions, ready to stop a destructive run before it finishes.

If “a departing engineer with too much access and nobody watching” sounds a little too familiar, join the waitlist and we’ll show you how it works on your own account.

Common questions

Can a fired employee delete my whole AWS account? Yes, if their access wasn’t revoked and they held broad permissions. They can run or schedule a deletion tool like aws-nuke against the account. At Cisco, an engineer deleted 456 virtual machines months after resigning because his credentials were never revoked.

What is aws-nuke and is it safe? It’s a legitimate tool that deletes every resource in an AWS account, built for cleaning up test accounts. It’s safe by design for that job, with a dry-run default and a double confirmation, but those guardrails are interactive and can be stripped out when the tool is wired into an automated job.

How do you stop a departing engineer from sabotaging your cloud? Revoke every path to access the day they leave, remove standing admin rights so no one holds account-wide delete, move to just-in-time access that expires on its own, and monitor privileged actions so a destructive run gets cut while it’s happening.

Does removing someone’s login stop their scheduled scripts? No. A Lambda, cron job, or EventBridge rule they already created keeps running on the role you gave it. The automation has its own permissions and doesn’t need the person to be logged in.