Twin Brothers Wiped 96 Government Databases After Being Fired — One Minute at a Time

Security pros have a saying that’s making the rounds again: the scariest threat actor isn’t some hooded figure in a basement — it’s the person who already has the keys. Case in point: a pair of twin brothers, both IT staffers at a government agency, reportedly logged in after being fired and deleted 96 databases one after another. Minutes apart. It sounds like a Mr. Robot subplot, but the failure modes it exposes are sitting in plenty of real org charts right now.

What actually happened

The story is depressingly simple. The brothers ran IT operations for a government agency. They got the termination notice. Then they used their still-active credentials to walk into the systems they’d been paid to protect and started wiping databases — methodically, one every few minutes.

Here’s the uncomfortable part: this wasn’t a “hack” in any meaningful sense. No exploit, no zero-day, no phishing. They were legitimate users with legitimate access. To the security stack, the logins looked identical to every other Tuesday morning.

How does anyone delete 96 databases in one sitting?

The number is what should make every CISO wince. Ninety-six is not a slip-up or a single rage-quit click. It’s a sequence — which means three different controls failed in a row.

Broken offboarding. The moment HR delivers a termination notice, accounts should be deactivated, VPN access killed, and admin rights revoked. The window between “you’re fired” and “your access is gone” is what the industry calls the golden window — and it’s the single most dangerous hour in any employee’s tenure. Here, that window stayed open long enough to wipe nearly a hundred systems.

No separation of duties. If two people can touch and destroy 96 production databases without anyone else in the loop, the access model is the problem, not the people. Privileged access should require a second pair of eyes — especially for destructive operations.

No behavioral detection. Databases disappearing on a steady cadence is the textbook signature of malicious activity. If no alert fired, the monitoring stack was either not watching or not tuned to notice. Both are unacceptable for government infrastructure.

Why insider incidents cost more than breaches

The Ponemon Institute’s annual insider threat reports have been beating this drum for years: the average cost of an insider incident now sits north of $17 million, materially higher than the typical external breach. The reason isn’t mysterious.

An outside attacker has to spend days, sometimes weeks, mapping the environment — figuring out where the crown jewels live. An insider already knows. The asset map an external red team would kill for is sitting in their head. That collapses the kill chain from a campaign into a single afternoon.

And database deletion isn’t just “data loss.” For a government system, you’re looking at citizen services going dark, administrative paralysis, rebuild costs, and a trust hit that doesn’t show up on a balance sheet. Even with backups, restoring 96 databases and reconciling cross-system consistency is a multi-month engineering project.

The checklist every org should run this week

This isn’t a security-team problem. It’s an HR-IT-Legal problem, and all three have to move in lockstep.

• Pre-staged access revocation. Before the termination meeting happens, the access-kill script should already be queued. The gap between notification and lockout should be measured in seconds, not hours.
• Multi-party approval for destructive actions. No single admin should be able to drop production databases unilaterally. AWS, GCP, and most modern DB platforms support this natively — turn it on.
• Immutable audit logs. You can’t undo a deletion, but you can guarantee a forensic trail. Write-once logs in a separate trust domain are non-negotiable for privileged operations.
• UEBA, not just SIEM. User and Entity Behavior Analytics catches the “right credentials, wrong behavior” pattern that signature-based tools miss entirely.

Trust is not an access control

Every technical safeguard ultimately rests on an assumption about people. The moment “this person is trustworthy” stops being true, the entire security model has to be rebuilt around that gap. The answer isn’t to treat every employee as a future arsonist — that way lies a miserable workplace and worse security culture. The answer is to bake one principle into the system itself: trust and privilege are not the same thing.

So here’s the question worth asking in your next security review: if someone on your team got fired in the next hour, how long until every door closes behind them? If the honest answer is “we’d have to check,” this story isn’t about somebody else.