Akhter Insider Breach: Offboarding Failures, Plaintext Passwords, and AI Prompts

On May 7, 2026, a federal jury in Alexandria, Virginia convicted Sohaib Akhter, a former federal contractor, after prosecutors said he and his twin brother Muneeb Akhter deleted roughly 96 U.S. government databases hosted by their employer shortly after being fired on February 18, 2025. The case is not just a lurid revenge-hacking story with an unusually cinematic cast. It is a clean-room example of what happens when privileged access, weak offboarding, contractor sprawl, and poor hiring controls meet inside systems that quietly run the machinery of government.
The Akhter case should make IT leaders uncomfortable because the technical lesson is embarrassingly old. The alleged and proven conduct involved database deletion, credential theft, log destruction, and unauthorized access — not science fiction. The novelty is that the blast radius crossed dozens of federal customers and that one of the defendants reportedly turned to an AI tool for help covering tracks after the damage had begun.

Futuristic cyber-security dashboard shows terminated access and data deletion status with red alerts.The Insider Threat Was Not Hidden in the Noise​

The core facts are stark. Muneeb and Sohaib Akhter worked for a Washington, D.C.-area technology company providing software and services to more than 45 federal agencies, including systems used for Freedom of Information Act processing and case management. The company has been identified in reporting as Opexus, a government contractor whose products sit in the bureaucratic plumbing of public records, investigations, and agency workflows.
According to prosecutors, the brothers were fired during an online meeting on February 18, 2025, after the company discovered Sohaib Akhter’s prior felony conviction. Immediately after that meeting, the brothers moved against the company and its government customers. Over several hours, about 96 databases storing U.S. government information were deleted.
That sequence matters more than the headline number. The frightening part is not merely that databases were destroyed; it is that the window between termination and retaliation existed at all. In competent offboarding for privileged technical workers, access ends before the employee hears the words.
This is why many workers first learn they have been fired when Slack stops loading, their VPN token fails, or their mailbox becomes unavailable. That practice can feel cold, but the Akhter case is the counterargument written in SQL. If a person can still reach production systems after being terminated, the termination process has already failed.

The Databases Were Boring, Which Is Why They Mattered​

The affected systems were not glamorous weapons platforms or spy satellites. They included Freedom of Information Act processing data, case management systems, and sensitive investigative files. That kind of data often sits outside the public imagination of “national security,” but it is exactly where government accountability, legal process, and citizen interaction with agencies live.
FOIA systems are not just inboxes for curious journalists. They hold request histories, agency correspondence, identity information, document workflows, redaction decisions, and records tied to investigations or disputes. When those systems are damaged, the harm is not limited to a backup restoration ticket. Deadlines slip, cases stall, evidence chains become messier, and agencies lose confidence in the integrity of their own records.
For Windows admins and database teams, this is the part that should feel familiar. The most important systems in an organization are often the least glamorous. They are old enough to have accumulated exceptions, important enough to be connected to everything, and bureaucratic enough that nobody wants to touch their architecture unless forced.
That makes them prime targets for insiders. An external attacker may need reconnaissance to understand which tables matter, which jobs run overnight, and which databases support which customers. A privileged contractor may already know.

AI Was the Search Box, Not the Supervillain​

The AI angle is irresistible, and prosecutors’ description practically writes the headline. After deleting a Department of Homeland Security database, Muneeb Akhter reportedly asked an AI tool how to clear system logs from SQL servers after deleting databases. He also reportedly asked how to clear event and application logs from Windows Server 2012.
That is damning evidence of intent if proven, but it is not evidence that AI created a new class of attack. The questions resemble what someone could have typed into a search engine, a forum, or a Stack Overflow-adjacent corner of the web years ago. AI lowered the friction and packaged the answer-seeking in conversational form, but the underlying behaviors were old: delete data, obstruct recovery, erase traces.
The industry should resist the comforting myth that banning AI prompts would solve the problem. A contractor with production access, database privileges, and an active session after termination does not need generative AI to be dangerous. The dangerous part is the access.
Still, AI changes incident response in one practical way. Investigators and defenders should now treat chatbot histories, enterprise AI audit logs, browser histories, and prompt telemetry as potential forensic evidence. If an organization allows AI tooling in operational environments, it should assume that prompt logs may become part of the timeline after a breach.

The Password Theft Story Is the Real Governance Failure​

The database deletion is the spectacular event, but the credential story is the systemic one. Prosecutors said Sohaib queried an Equal Employment Opportunity Commission database for a third party’s plaintext password and gave it to Muneeb, who then used it to access that person’s email account without authorization. Reporting also says Muneeb had assembled thousands of usernames and passwords taken from company network data.
Plaintext passwords in a database should set off alarms in any modern security review. Passwords should not be retrievable by support staff, developers, contractors, or anyone else with a convenient query. They should be salted, hashed, and handled in a way that makes “looking up a user’s password” impossible by design.
If a system allows an employee to retrieve a plaintext password, the organization has converted an authentication secret into ordinary data. That means every database admin, developer with read access, backup operator, reporting tool, and compromised service account becomes a potential identity thief. The Akhter case shows why that is not a theoretical concern.
This is where “insider threat” programs often become too theatrical. Organizations imagine malicious employees exfiltrating crown jewels through elaborate channels, while the more basic problem is that sensitive secrets are stored in places where too many people can query them. The best insider defense is often not surveillance. It is architecture that denies insiders the easiest path.

The Previous Convictions Make the Hiring Question Unavoidable​

The brothers were not unknown to the criminal justice system. In 2015, both pleaded guilty in a prior hacking and fraud case involving stolen credit card data and unauthorized access. Muneeb received a three-year prison sentence, while Sohaib received a two-year sentence.
That history does not mean every person with a conviction should be permanently unemployable in technology. Blanket exclusion is both ethically crude and practically self-defeating in a labor market that claims to value rehabilitation. But when a company places a person into a role with access to federal systems, sensitive records, production databases, and customer credentials, background risk cannot be waved away as an HR footnote.
The issue is not moral purity. It is role design. A person with a prior computer-fraud conviction may still contribute meaningfully in many technical contexts, but giving that person broad privileged access to government-hosted systems requires extraordinary controls, not ordinary trust.
Opexus reportedly acknowledged after the incident that its screening protocols needed to be more robust. That statement is unsurprising, but it also risks understating the problem. Screening is only the front door. The deeper question is why any single worker, or pair of workers, could allegedly cause this much damage before containment.

Federal Contracting Multiplies Trust Faster Than It Multiplies Oversight​

Government agencies often depend on contractors because building and maintaining bespoke internal software across the federal enterprise is slow, expensive, and politically difficult. Vendors promise specialization, reuse, and operational maturity. In exchange, agencies hand over not only data but also trust.
That trust can become strangely diffuse. One contractor may support dozens of agencies. One platform may host records for multiple missions. One privileged account may touch systems whose owners sit in different departments, with different risk tolerances and different oversight cultures.
The Akhter incident sits precisely in that seam. Prosecutors described a company serving more than 45 federal agencies, with government data hosted on servers in Ashburn, Virginia. From a procurement perspective, that looks like scale. From a security perspective, it can look like concentration risk.
The federal government has spent years pushing zero trust, stronger identity controls, endpoint detection, software supply-chain scrutiny, and incident reporting mandates. Those policies are necessary, but they collide with the mundane reality of outsourced operations. A zero-trust memo does not revoke a fired admin’s token. A compliance attestation does not restore a deleted production database.

Offboarding Is a Security Control, Not an HR Chore​

Every sysadmin knows the awkward choreography of a termination. HR wants the conversation to happen at a specific time. Legal wants documentation. Management wants discretion. IT wants to know exactly when to disable accounts, rotate secrets, revoke sessions, retrieve devices, and preserve evidence.
When the employee has privileged access, the order of operations is not a nicety. It is the control. Accounts should be disabled, sessions killed, tokens revoked, SSH keys removed, database users locked, cloud roles stripped, and shared credentials rotated before or at the exact moment the termination begins. If the person is remote, device management and conditional access become even more important.
The Akhter case appears to have unfolded in the gap between employment status and access state. That gap is where many breaches live. Organizations obsess over external perimeter defenses while leaving termination workflows dependent on calendar invites, manual tickets, or a manager remembering to notify IT.
For administrators, the lesson is brutally practical: if your offboarding process cannot handle a hostile privileged user in real time, it is not an offboarding process. It is a hope.

Backups Are Not a Strategy Unless Restoration Is Practiced​

Deleting 96 databases sounds catastrophic, but the operational harm depends on restoration posture. Were backups current? Were they immutable? Were they segregated from the same credentials used to administer production? Could teams restore service quickly without overwriting forensic evidence? Could agencies verify that restored data was complete and trustworthy?
Those questions matter because attackers increasingly target recovery paths. Ransomware crews learned years ago that deleting backups is more valuable than encrypting endpoints. A malicious insider may understand backup schedules, retention windows, administrative consoles, and where the organization has cut corners.
Government contractors should treat destructive insider scenarios as tabletop exercises, not after-action surprises. A production DBA is fired at 4:30 p.m. A privileged service account begins issuing destructive commands at 4:38 p.m. Logs start disappearing at 4:59 p.m. Who gets paged, what gets frozen, what gets revoked, and what evidence is preserved?
If the answer is a conference call, the attacker has already won time. If the answer is automated anomaly detection, immutable backups, just-in-time privilege, and rehearsed emergency access revocation, the organization has a fighting chance.

Windows Server 2012 Is a Detail That Should Not Be Ignored​

One of the reported AI queries referenced Microsoft Windows Server 2012 event and application logs. That detail may or may not indicate the exact operating system environment involved in the affected infrastructure, but it is a reminder of how long-lived government and contractor systems can be.
Windows Server 2012 and 2012 R2 reached the end of regular extended support in October 2023, with paid extended security updates available for organizations that need more time. Many enterprises still run legacy Windows Server estates because the applications tied to them are expensive, brittle, or poorly documented. Government workflows are especially prone to this kind of sediment.
Legacy systems are not automatically insecure, and modern systems are not automatically safe. But older environments often carry accumulated exceptions: service accounts with broad rights, logging that was never centralized, applications that assume local admin privileges, and databases designed before today’s assumptions about credential handling.
For WindowsForum readers, that is the uncomfortable bridge between headline crime and everyday administration. The riskiest system in your estate may not be the flashy new cloud deployment. It may be the aging server everyone is afraid to reboot because it runs a workflow no one fully owns.

The Criminal Case Is Also a Map of Administrative Failure​

Sohaib Akhter now faces serious prison time after his conviction on conspiracy to commit computer fraud, password trafficking, and possession of a firearm by a prohibited person. Muneeb Akhter entered a plea agreement and awaits sentencing. The legal process will determine punishment, but the technical community should not stop at individual culpability.
Criminal prosecutions can create a false sense of closure. The bad actors are identified, the indictment is filed, the jury convicts, and the story becomes a morality play about disgruntled workers. That framing is satisfying because it localizes the problem inside two people.
But insider incidents are rarely only about bad insiders. They are about permissions that were too broad, monitoring that was too slow, secrets that were too exposed, backups that may or may not have been isolated, and offboarding that failed under pressure. The defendants may be responsible for their conduct. The systems around them are responsible for making that conduct so consequential.
That distinction matters because most organizations cannot control whether a future employee becomes angry, desperate, greedy, or reckless. They can control whether that employee can delete production databases after being fired.

The Small Controls Would Have Made the Big Headline Smaller​

The most frustrating part of this case is how many ordinary controls could have reduced the blast radius. None of them are exotic. None require a moonshot AI defense platform. They require disciplined identity management, boring architecture, and management willing to inconvenience privileged users before an incident.
Just-in-time access would have limited standing privileges. Privileged access management could have required approvals, session recording, and rapid revocation. Database permissions could have separated read, write, delete, backup, and administrative functions. Immutable backups could have constrained destruction. Centralized logging could have made log tampering less useful.
The same is true of credential handling. If passwords were properly hashed and never retrievable in plaintext, the alleged EEOC password lookup would not have worked as described. If sensitive records required stronger segmentation and audit trails, bulk credential harvesting would have been harder to hide.
Security vendors love to describe these measures as parts of a maturity journey. That language is harmless until it becomes a way to defer basics. In this case, the basics were the story.

The Lesson for Every Admin Is Written in the Termination Window​

The Akhter case is dramatic because it involves twins, federal agencies, alleged revenge, AI prompts, prior convictions, and a courtroom ending. Strip that away and the operational lesson is painfully direct: privileged access must be treated as temporary, monitored, and revocable at machine speed.
  • Organizations should revoke privileged access before a termination conversation begins, not after a manager submits a ticket.
  • Production databases should not expose plaintext passwords to administrators, developers, contractors, or support staff.
  • Backups should be immutable, regularly tested, and protected from the same identities that can alter production systems.
  • Contractor platforms serving multiple government agencies should be treated as concentration-risk assets, not merely vendor-managed conveniences.
  • AI prompt logs and chatbot usage may become relevant forensic evidence when attackers use generative tools during or after an intrusion.
  • Prior cybercrime convictions do not require permanent exclusion from technical work, but they do require role-specific controls when sensitive systems are involved.
The story of Muneeb and Sohaib Akhter will be remembered for the number 96, because numbers give breaches shape. But the more important number is the handful of minutes after a firing when access apparently still existed and trust had already ended. The next serious insider incident will not need twins, headlines, or an AI chatbot to do damage; it will only need a privileged account left alive slightly longer than common sense allows.

Source: Wide Open Country Twin Brothers Face Decades of Jail Time After Deleting Government Databases, Harvesting User Data
 

Back
Top