The FBI jobs portal claim: a recruiting front door, and what the attackers say sat behind it

On September 22, 2026, visitors to the FBI’s jobs site found a banner from the extortion group ShinyHunters reading “This site has been seized by ShinyHunters.” According to public reporting from TechCrunch, The Record, and CBS News, the group claimed it had used the jobs portal as a way in and had stolen data on FBI agents, employees, and job applicants. The FBI said it was “aware of claims regarding unauthorized activity affecting FBIjobs.gov and is currently investigating,” and the special agent application portal went offline.

For days, nearly everything beyond the defacement was a claim. ShinyHunters reportedly told journalists it exploited an undisclosed Oracle PeopleSoft vulnerability that allowed unauthenticated remote code execution, then moved into FBI-managed AWS GovCloud infrastructure and downloaded between 2 and 3 terabytes. The group allegedly listed HR, criminal justice, and Medlink systems among its sources, and Reuters reported that records circulated by the hackers included psychiatric and medical evaluations. Reuters and 404 Media found that portions of the samples corresponded to real FBI or Justice Department personnel, but CBS News noted that neither outlet established that the records originated from FBI systems. A day later the FBI said the point of breach was still undetermined, “whether a third-party or the FBI’s enterprise.”

That changed on September 29. According to CBS News and NBC News, the FBI acknowledged in an internal notice to staff that personal information of some employees had been stolen, and NBC reported that a Justice Department notification described the jobs portal as holding Social Security numbers, dates of birth, phone numbers, addresses, and emergency contact information. The same day, the FBI and Dutch police announced the September 15 arrest of a 24-year-old Amsterdam man suspected of ShinyHunters membership. The FBI did not tie him to the jobs-portal breach, which appears to have happened after he was detained, and neither report indicated that the bureau had settled the point of breach.

The group framed the operation as retaliation for a May 15 FBI advisory about its tactics and gave the bureau a week to retract it. On September 28 it told CBC News, Hackread, and Nextgov that it never intended to publish the data. That may limit the exposure for the people involved, if the claim holds, while the architectural question the incident raises stays open.

If the attackers’ account is accurate, the detail that matters most is the distance between the front door and what they say was behind it. A recruiting portal takes applications from the public. Psychiatric evaluations, prescriptions, and drug test results are among the most sensitive files any employer holds. Those two things should not be reachable along the same chain of trust, and when an application server can be walked into a store like that, the files are effectively protected by whatever the application is protected by.

This pattern could appear at nearly any large organization. HR suites, applicant tracking, and occupational health systems grow integrations over years, and each integration tends to carry a service identity with broad read rights. RackTop’s analysis of Oracle application breaches and mass file exfiltration covers the same shape in the private sector: an attacker who owns the application inherits the application’s reach.

Attribute-based access control (ABAC) evaluates each request on who is asking, from where, on what device, at what time, and how the data itself is classified. In RackTop BrickStor SP, those decisions apply per file and per operation across SMB, NFS, S3, and Web Drive. A folder of medical evaluations can carry a label that restricts it to the occupational health roles and networks that process it. An identity that belongs to an internet-facing recruiting workflow does not match that policy, so even a fully compromised portal service would be denied at the storage layer rather than trusted because it arrived through an approved application.

Least privilege at the file limits what a zero-day is worth. That is the core idea of Zero Trust data security: every request is decided at the data, and a successful exploit upstream buys the attacker only the files that identity was ever entitled to read.

Moving 2 to 3 terabytes, as the group claims, is not a quiet operation for a system that watches reads. Active Defense, the behavioral engine in BrickStor SP, profiles normal access for each user, host, and dataset and flags bulk reads, systematic directory walks, and identities touching data they have never touched. It can terminate an offending session in under a second. Detecting mass file reads on live data is a core requirement of Cyberstorage. RackTop filed the provisional application for its Active Defense patent on November 13, 2020, about eight months before Gartner named the category in July 2021.

The FBI’s own statement points to the second control. “Third party or enterprise” is an audit question. BrickStor SP keeps an immutable record of every file operation: the identity, its attributes, the file, the action, and the policy decision. With that record, determining whether a given evaluation was read from an agency store, and by which session, is a query rather than a months-long reconstruction, and the answer supports precise notification instead of warning everyone who might be affected.

The FBI is investigating and, according to Nextgov, has urged personnel to take protective steps. For every agency and contractor whose recruiting, HR, and medical workflows share plumbing, the lesson sits upstream of the headline: decide access at the data by its label, watch reads as closely as writes, and keep the record that ends the argument about where the files came from.