ShinyHunters Claims FBI Breach

On Tuesday, September 22, the cyber extortion group ShinyHunters posted a statement to its dark web site claiming it had compromised the U.S. Federal Bureau of Investigation. The group says it holds "very sensitive data on almost ALL FBI Agents and individuals who filed an application with the FBI for a job." If even part of that holds up, the people exposed are the ones whose identities matter most to keep quiet: serving agents, former staff, and applicants who handed a government portal their background in good faith.

The motive, by the group's own account, is not money. ShinyHunters says it went after the FBI because of a May 2026 public service announcement that detailed its targeting of Canvas, an online learning management system, and urged victims not to pay. An extortion crew is now attacking the agency that told its victims to stop paying. That is the story, and it should worry every defender who has ever made a public no-pay call.

What ShinyHunters claims

A ShinyHunters spokesperson told The Hacker News the stolen data runs to roughly 2 TB and touches FBI PEGA, Medlink, FBIJOBS, HR, CJ and PHIRE, with more internal services possibly affected. The group singled out Medlink, saying it contains medical information, prescriptions, medical discharges, clinic visits and diagnoses tied to agents.

On entry, a spokesperson told The Register the group used a new Oracle PeopleSoft zero-day to get remote code execution and deface the FBI jobs site with a "This site has been seized by ShinyHunters" banner. The site now shows a scheduled maintenance page. The claim was first reported by 404 Media.

What the FBI has confirmed

Less, and carefully worded. The FBI told Reuters it is "aware of claims regarding unauthorized activity affecting FBIjobs.gov and is currently investigating." In a post on X, the Bureau said the point of breach is still undetermined, meaning it could sit with a third party or inside the FBI enterprise, and that it is working with the third-party providers that support FBIJobs.gov to mitigate risk.

That third-party framing matters. A recruiting portal is exactly the kind of system that gets outsourced, integrated with HR back ends, and forgotten by the core security team until something breaks.

The PeopleSoft angle

The zero-day claim is unverified, but the pattern is not new. In June 2026, ShinyHunters weaponized a similar PeopleSoft flaw, CVE-2026-35273, to break into enterprise networks and extort victims. A group that has already monetized one PeopleSoft bug has every reason to keep hunting in the same codebase. Organizations running internet-facing PeopleSoft should assume they are on the target list whether or not this specific zero-day turns out to be real.

A brand, not a crew

The FBI claim lands days after ShinyHunters hijacked the leak site of the Clop ransomware crew and posted an 8-figure demand against it. The group also rejects any link to The Com collective, calling that label propaganda from the security industry, and blames impersonators for threats sent to journalists and researchers.

Etay Maor, VP of threat intelligence at Cato Networks, said the claim "should absolutely be taken seriously" and noted that while nation-state groups have hit law enforcement before, citing the 2015 OPM breach, a cybercrime brand publicly claiming an FBI compromise is different. He pointed to the September 23 timestamp on a post that surfaced September 22 in the U.S. as a possible, non-definitive hint of activity in Asia. He also described ShinyHunters as a brand that outlasts takedowns, arrests and forum seizures by recruiting new operators, with a recent playbook built on help-desk social engineering, malicious OAuth applications and stolen SaaS integration tokens.

The RedEye take

Take the claim seriously and the rhetoric not at all. The public argument about disinformation and brand reputation is a sales pitch aimed at future victims: ShinyHunters is telling the market that paying it is safe and that law enforcement guidance is wrong. The Clop hijack and the FBI post are the same move, status plays designed to make the brand look untouchable. The real risk sits below the noise. Whether the door was a PeopleSoft zero-day or a third-party provider, the target was an HR and recruiting system holding medical and identity data on people whose safety depends on it staying private. Most organizations run the same class of system with far less scrutiny than their production perimeter. That gap is the lesson, not the drama.

What defenders should learn

• Put HR, recruiting and occupational health systems in the crown-jewel tier. Medlink shows that the most damaging data is often in back-office systems, not the ones the SOC watches most closely.
• Map every third party that touches your applicant portal. The FBI still cannot say whether the breach sits with a provider or its own enterprise; you should be able to answer that for your own stack within an hour.
• Treat public statements against an extortion group as a trigger for elevated monitoring. The FBI PSA in May preceded this attack; if you name a group publicly, harden and watch your exposed surfaces first.
• Audit OAuth grants and SaaS integration tokens as rigorously as firewall rules. The group's recent playbook abuses trusted identity paths, not just perimeter bugs, so a clean vulnerability scan is not a clean bill of health.
• Stop exposing PeopleSoft login pages directly to the internet. Two PeopleSoft attacks by the same group in one year is a strong signal to put those portals behind VPN, a zero trust proxy or at minimum a strict WAF policy.

SELECT TOOLSREL, LASTREFRESHEDDTTM FROM PSSTATUS;

HOST=hr.example.com; curl -s -o /dev/null -w "%{http_code}\n" "https://$HOST/psp/ps/?cmd=login"

Connect-MgGraph -Scopes Application.Read.All; $t=(Get-MgContext).TenantId; Get-MgServicePrincipal -All | Where-Object { $_.AppOwnerOrganizationId -and $_.AppOwnerOrganizationId -ne $t } | Select-Object DisplayName, AppId, AccountEnabled

sudo firewall-cmd --add-rich-rule='rule family="ipv4" source address="10.0.0.0/8" port port="443" protocol="tcp" accept' && sudo firewall-cmd --remove-service=https

$spId = (Get-MgServicePrincipal -Filter "appId eq 'APP_ID_FROM_CHECK'").Id; Update-MgServicePrincipal -ServicePrincipalId $spId -AccountEnabled:$false