In late May 2026, ShinyHunters started exploiting an unauthenticated remote code execution bug in Oracle PeopleSoft. Over about two weeks they hit more than a hundred organisations, roughly two thirds of them universities and colleges, and published the results on their leak site.

On 22 September the same group defaced the FBI's job application portal and claimed they had used a PeopleSoft zero-day to take roughly 2 TB from the bureau.

They did not ask for money. They asked the FBI to delete a public service announcement.

The first part is documented in detail by Google Threat Intelligence and Rapid7. The second part is a claim by an extortion group, which is a different category of thing entirely. The gap between the two is most of what this article is about - and the demand attached to the second part is the most interesting thing in the story.

[INFO]
Primary sources: Google Cloud Threat Intelligence, ShinyHunters Targets Education Sector with Oracle PeopleSoft Exploit; Rapid7, Active Exploitation of Oracle PeopleSoft Zero-Day (CVE-2026-35273); and reporting on the FBI claim from The Hacker News, 23 September 2026. Campaign indicators are Mandiant's (tracked as UNC6240). The FBI advisory at the centre of the September incident is IC3 PSA I-051526-PSA, 15 May 2026.
◈ interactive artifact
Two Weeks, a Hundred Organisations
The actual commands Mandiant recovered, with the detection opportunity at each stage.

//The Bug

CVE-2026-35273 is a server-side request forgery in Oracle PeopleSoft Enterprise PeopleTools 8.61 and 8.62 that escalates to remote code execution. CVSS 9.8, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, no authentication required.

The reachable surface is two endpoints: /PSEMHUB/hub and /PSIGW/HttpListeningConnector. The first belongs to the Environment Management Hub, a component most PeopleSoft administrators have never deliberately thought about, which is exactly the kind of thing that ends up exposed.

One secondary effect is worth noting for hunting: successful exploitation can cause outbound SMB connections on TCP 445 to external destinations, which is a chance to capture Windows NetNTLM hashes. An internal application server making outbound SMB connections to the internet is not a subtle event, and it is trivially alertable.

The timeline is the uncomfortable part

Exploitation ran from 27 May to 9 June 2026. Oracle published an out-of-band alert and patch on 10 June. CISA added it to the KEV catalog on 12 June.

So the campaign was essentially complete before the patch existed. By the time defenders had something to install, the data was already on the leak site - ShinyHunters published on 9 June, the day before Oracle's advisory. Patching was the right thing to do and it was never going to be the thing that saved anyone in this window.

//What They Did Once Inside

The post-exploitation is the interesting half, and it is a good illustration of an operator using entirely legitimate software.

MeshCentral wearing an Azure badge

Rather than a custom implant, they deployed MeshCentral - an open-source remote management platform - installing v1.1.59 on staging infrastructure on 27 May at 22:14 UTC. Eleven minutes later they installed the acme-clientnpm package to automate Let's Encrypt certificates for it.

That eleven-minute gap tells you something. They stood up the C2, then immediately made sure it would present a valid certificate. Two days later they were looking at authenticode binary signing tools.

The agents were named meshagent64-azure-ops.exe and beaconed to wss://azurenetfiles[.]net:443/agent.ashx, a domain built to read as Microsoft Azure NetApp Files. Valid TLS, plausible domain, legitimate signed RMM software, WebSocket over 443. None of the individual components are malicious.

The fanout script

Lateral movement was a shell script, pushed to agents through the MeshCentral CLI:

node meshctrl.js RunCommand --loginuser admin --loginpass '[password]' --id '[agent_id]' --run 'bash /tmp/[victim]_fanout.sh'

The script enumerates internal hosts out of /etc/hosts, then sprays a small list of usernames and passwords at each one over SSH using sshpass, with StrictHostKeyChecking=no and a six second timeout. On success it copies a file into the PeopleSoft web server directories and moves on to the next host. If password auth fails it falls back to trying key-based auth as the current user.

The file it copies is named README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT.

Two observations. First, this is not sophisticated - it is a bash loop with hardcoded credentials and no error handling worth the name, and it counts successes with OK=$((OK+1)). Second, it worked, at scale, across a hundred organisations, because internal SSH between application hosts is usually permitted and rarely instrumented.

The defacement file is also an operational choice, not vandalism. Dropping a marker into three specific web server paths creates proof of access that the victim will find, which is leverage in an extortion negotiation.

Exfiltration

Staging and compression used zstd, with a progress meter:

pv -s "$(du -sb exfil | awk '{print $1}')" | zstd -3 -T0 -o exfil.tar.zst

Then SSH to 176.120.22[.]24, described by Mandiant as a public mirror of the ShinyHunters leak site.

zstd at level 3 with all threads is a speed-over-ratio choice. pv is there so a human could watch it. This is someone working interactively, not an automated collector.

Persistence worth knowing about

Two mechanisms, both PeopleSoft-specific and both easy to miss: unauthorised .jsp files under PSEMHUB.war/, and XMLDecoder remote code execution via .xml files planted in <docroot>/envmetadata/data/environment/, which fire when the application restarts.

The second one is the nastier of the two. Restarting the application server is the first thing many teams do during incident response, and here it is the trigger.

//The FBI Claim

On 22 September 2026, ShinyHunters defaced apply.fbijobs.gov with a message stating the site had been seized by them, and claiming they held personally identifiable information and protected health information belonging to FBI employees, former employees and applicants. The group says the banner was visible only briefly before the bureau noticed and pulled the service. Both apply.fbijobs.gov and the Special Agent Application Portal went offline and have been showing a maintenance page since.

They claim roughly 2 TB, naming FBIJOBS, HR, CJ, PEGA, PHIRE and a system called Medlink. They told The Register they exploited a new Oracle PeopleSoft zero-day, saying they found it on the Monday night and used it against the FBI shortly afterwards, and that the flaw remains undisclosed.

The FBI's position is that it is "aware of claims regarding unauthorized activity affecting FBIjobs.gov" and investigating, that it is "working closely with those third-party providers that support FBIJobs.gov", and that the point of breach is "still undetermined - whether a third-party or the FBI's enterprise".

Established: the defacement happened, two FBI recruitment services went offline and stayed offline, and the bureau has confirmed an investigation involving third-party providers. Saying the point of breach is undetermined is not a denial.

Not established: the 2 TB figure, the system list, the contents, and the existence of a second PeopleSoft zero-day. No data has been published, no independent verification exists, and no CVE has been assigned.

The demand is the story

There was no ransom. The single demand was that the FBI remove a public service announcement, with a one-week deadline.

The PSA in question is I-051526-PSA, published by IC3 on 15 May 2026 and titled ShinyHunters: Cyber Criminal Group Attacks Learning Management System. It was issued after the group's attack on Instructure, which runs Canvas.

ShinyHunters' stated objection is that the PSA contains false information and is, in their words, an attempt to disrupt their operations and hinder their clients' trust.

Read that word again. Clients. The organisations they extort.

So what does the PSA actually say that is worth attacking a federal agency over? Two things.

It tells victims plainly: "Do not send payment or respond to their demands."

And it says this about the group's honesty: "Threat actors may falsely claim to have sensitive or compromising information, including embarrassing photographs or videos of victims, which frequently do not exist."

That second sentence is the one that costs them money. An extortion business runs on the belief that the data is real and that paying makes it go away. A federal law enforcement agency telling the market that this particular group routinely claims to hold things it does not hold attacks the product, not the operation. You can rebuild infrastructure after a takedown. You cannot easily rebuild a reputation for actually having the goods.

The PSA also documents the pressure tactics: threatening texts and calls to victims and their family members, and in some cases swatting. That is context worth carrying into any assessment of the group.

The recursion nobody seems to have noticed

The FBI published an advisory saying ShinyHunters frequently claim to hold data that does not exist.

ShinyHunters responded by making a large, unverified, unpublished claim about data they say they hold, and demanding the advisory be withdrawn.

The claim made in retaliation for the advisory is precisely the kind of claim the advisory warns about. That does not make it false. It does mean the appropriate epistemic standard here is the one the FBI already published, and it is the reason this article does not repeat the 2 TB figure as fact.

One genuine discrepancy in the reporting, which matters for reading their intent. CyberScoop reports no direct threat to release the data. CyberInsider reports a threat to leak if the deadline passes. Those cannot both be right, and the difference is the difference between a pure retraction demand and conventional extortion wearing a political costume. It is unresolved.

The question defenders actually need answered

Is this a second PeopleSoft zero-day, or an unpatched system still vulnerable to CVE-2026-35273?

Those need completely different responses. A new zero-day means every patched PeopleSoft deployment is still exposed and there is nothing to install. An unpatched host means the June fix works and someone was three months late.

Nothing public settles it. ShinyHunters say new; no CVE exists; Oracle has published nothing since June. Their claim is self-serving in an obvious way, because a novel zero-day is better for their reputation than finding a server nobody patched - and reputation is, on the evidence of the demand itself, what this operation was for.

Against that, the group demonstrably had at least one PeopleSoft zero-day this year, which makes a second considerably less far-fetched than it would be from an actor with no track record. That is a reason to take the possibility seriously, not a reason to believe it.

Until something resolves it: verify your PeopleTools version is patched, assume that might not be sufficient, and monitor the endpoints rather than relying on the patch alone.

//The Education Thread

The two halves of this article are connected, and the connection runs through schools.

Between 25 April and 12 May 2026, ShinyHunters breached Instructure, which operates Canvas. Roughly 8,809 educational institutions were affected. The group claimed 3.65 TB covering around 275 million users. Instructure attributed it to an issue related to Free-For-Teacher accounts and said it found no evidence that passwords, dates of birth, government IDs or financial information were involved - which is itself an early example of the claimed scope and the confirmed scope diverging.

On 15 May, three days after that intrusion ended, the FBI published the PSA.

On 27 May, twelve days later, the PeopleSoft campaign began - and 68% of the hundred-plus organisations notified were universities and colleges.

Education is not an accident for this group. It is under-resourced, it runs large enterprise platforms like PeopleSoft and Canvas, it holds enormous quantities of personal data on people with no relationship to the security decisions being made for them, and it rarely has the budget to respond well. The FBI advisory that triggered September's defacement exists because of an education-sector attack, and the campaign that followed it targeted the education sector again.

//One Small Thing From Our Own Files

Worth recording because it is a near miss on this site's own indicator hygiene.

Earlier this month a research package arrived here attributing the address 176[.]120[.]22[.]230 to the PivotC2 FortiGate campaign. It could not be corroborated against SOCRadar or any other source, so it was omitted from the published article on the grounds that a wrong IOC is worse than no IOC.

Mandiant independently documents 176[.]120[.]22[.]24 as a ShinyHunters leak site mirror. Same /24, entirely different campaign and actor.

A shared /24 is weak evidence on its own and no claim is being made that the two are related. What it does suggest is that the unverifiable indicator had probably drifted in from ShinyHunters reporting and been misfiled against PivotC2. Indicators cross-contaminate between campaigns in aggregated intelligence, and the damage lands on whoever hunts for them in the wrong place.

//Detection Opportunities, Ranked

Outbound SMB from an application server. Exploitation can force TCP 445 connections to external hosts. There is no legitimate reason for a PeopleSoft server to do this, and it sits at the very start of the chain.

Unexpected .jsp or .xml files under PSEMHUB.war/ and envmetadata/. File integrity monitoring on those two paths is cheap and catches both persistence mechanisms.

sshpass anywhere. It exists to feed passwords to SSH non-interactively and is almost never in a legitimate administrative workflow on a production application host.

MeshCentral agents the organisation did not deploy. Same problem as RustDesk in the Akira intrusion and GoTo Resolve in the Gentlemen intrusion: legitimate RMM software needs an allowlist, not a blocklist.

zstd or pv on a production server. Neither is commonly installed or used on a PeopleSoft application host. Compression tooling appearing next to a directory called exfil is about as clear as it gets.

The defacement filename itself. README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT is a free retrospective search across every file server you own.

[IOC]
All indicators from Google Threat Intelligence (UNC6240) unless noted.
Staging: 142.11.200[.]186 through 142.11.200[.]190
C2: azurenetfiles[.]net · wss://azurenetfiles[.]net:443/agent.ashx
Leak site mirror / exfil: 176.120.22[.]24
meshagent64-azure-ops.exe f02a924c9ff92a8780ce812511341182c6b509d45bc59f3f7b522e37225d24fc
meshagent64-v2.exe d83fdb9e53c5ff03c4cb0451ea1bebd79b53f29eadc1e2fa394c7af13a86ce2f
meshagent32-azure-ops.exe c7e9332731b06644fc73e0046a2a89eaa59b09f54250e9bd622467187351711f
meshagent (Linux) 68257a6f9ff196179ec03624e849927f26599eb180a7c82e14ef5bc4e93bc309
.bash_history 2ab684d93c1553fad87041b4dea97188a97e78589deee2a7bacff905564f3a35
Filenames: README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT, [victim]_fanout.sh
Endpoints: /PSEMHUB/hub, /PSIGW/HttpListeningConnector
Affected: PeopleTools 8.61, 8.62 · Patched 10 June 2026 · CISA KEV 12 June 2026

//Sourcing and Uncertainty

The campaign detail - the UNC6240 designation, the 27 May to 9 June window, the 100-plus notified organisations and the 68% higher education figure, the staging IPs, the MeshCentral timestamps, the fanout script, the hashes and the exfiltration method - is Google Threat Intelligence's. The CVE detail, CVSS vector, affected versions, endpoints, SMB side effect and patch timeline are from Rapid7 and the CVE record.

The September incident is sourced from reporting by CyberScoop, CyberInsider, ASIS and The Hacker News between 22 and 23 September 2026. The PSA text is quoted directly from IC3 I-051526-PSA, 15 May 2026. The Instructure figures come from the public record of that breach, with 3.65 TB and 275 million users being ShinyHunters' own claims rather than confirmed totals, and the list of what was not found being Instructure's own statement.

The FBI section is deliberately hedged and should stay that way.An extortion group's claim about the volume and contents of stolen data is marketing until somebody checks it - a standard the FBI's own advisory articulates better than this article could. What has been confirmed is stated as confirmed, what has not is stated as not, and the difference is not split.

The interpretation is mine: reading the eleven-minute gap between MeshCentral and certificate automation as deliberate preparation, the argument that the defacement file is extortion leverage rather than vandalism, the point that restarting the app server triggers the XMLDecoder persistence, the ranking of detection opportunities, the analysis of the second-zero-day question, the reading of the retraction demand as brand protection rather than politics, and the observation about the recursion between the advisory's warning and the claim made in response to it.

Three gaps worth stating. The usernames and passwords in the fanout script are redacted in the source, so the spray list is unknown. Whether the FBI incident involves PeopleSoft at all rests entirely on ShinyHunters saying so - the bureau has named third-party providers of FBIJobs.gov without naming a product. And the reporting conflicts on whether a leak threat accompanied the retraction demand, which is flagged above rather than resolved, because open sources do not settle it.