Image Not FoundImage Not Found

  • Home
  • Cybersecurity
  • Renewed ShinyHunters PeopleSoft Attacks Show Why WAF Rules Aren’t Containment
A systems administrator reviews web server logs on dual monitors in a quiet office with a network rack blurred in the background.

Renewed ShinyHunters PeopleSoft Attacks Show Why WAF Rules Aren’t Containment

Google’s threat intelligence team and Mandiant said Sept. 25 that UNC6240, a cluster Mandiant associates with ShinyHunters, has resumed mass exploitation of Oracle PeopleSoft by altering the request path just enough to slip past some web-application-firewall rules and still reach the same vulnerable backend service. The practical consequence is bigger than a clever URL trick: organizations that treated a WAF rule as containment now have a current incident-response problem.

The question many defenders are really asking is not whether a path-blocking rule ever reduced noise. It is why that mitigation failed against renewed exploitation, and what evidence an organization needs before it can responsibly say the incident is contained.

Why the WAF rule failed

The underlying flaw was not new in September. Oracle’s June 10 security alert covers CVE-2026-35273 in PeopleSoft PeopleTools 8.61 and 8.62, describes it as remotely exploitable over HTTP without authentication, and assigns it a CVSS 3.1 base score of 9.8. The vulnerable component is Updates Environment Management, which exposes the PSEMHUB/Environment Management Hub service.

In the renewed campaign, Mandiant and Google Threat Intelligence Group reported that attackers changed the path from the obvious /PSEMHUB/ form to an encoded variant such as /%50SEMHUB/. A security control that matches the literal request path may not recognize that string as the blocked endpoint. The PeopleSoft application server, however, can decode %50 into the letter P and route the request to /PSEMHUB/ anyway.

That mismatch is the core lesson. A WAF or reverse proxy can inspect one representation of a URL while the application ultimately processes another. The public reporting does not say this works against every WAF, proxy, or PeopleSoft deployment, and it should not be read as a universal bypass. But it is a documented example of a familiar defensive failure mode: string-based blocking reduces obvious exposure, then creates false confidence when nobody tests how the backend normalizes the request.

Why this became an enterprise incident-response story

Mandiant said the May-June exploitation wave was concentrated in higher education. The September activity spread much wider, with web shells observed on dozens of systems globally across higher education, technology, IT services, healthcare, agriculture, transportation, and government. Reuters independently reported the same broad pattern: attackers adapted after some organizations relied on WAF rules without applying Oracle’s patch.

That sector expansion matters because PeopleSoft is not a fringe web application. It often sits near human resources, finance, supply chain, and student-administration data. A pre-authentication remote-code-execution bug in an internet-reachable management component is not just a website problem; it can become a route into credentials, database connection strings, application data, and internal systems tied to the platform.

Mandiant also described what happened after initial access in investigated compromises. It observed web shells, Neo-Regeorg tunneling components, and the legitimate MeshCentral MeshAgent used for remote management. In those observed cases, about one quarter of commands executed as root or NT Authority\SYSTEM. The rest ran under PeopleSoft or WebLogic service accounts. Even without full operating-system privilege, those accounts could reach configuration files, stored connection strings, and business data that materially expand the blast radius.

None of that proves every exposed PeopleSoft server was fully compromised, or that every victim lost sensitive records. Mandiant did not publish a victim list, a complete intrusion count, or a public tally of data exfiltration. Separately, Reuters reported that ShinyHunters has claimed access to FBI data, but Reuters could not corroborate the claim and the FBI said it was aggressively investigating a reported breach. What the reporting does show is that for organizations that postponed patching, the risk is now bigger than blocking a URL at the edge.

What to verify before calling it contained

Start with the obvious item that too often gets treated as a paperwork exercise: confirm whether the Oracle patch was actually applied to supported PeopleTools 8.61 and 8.62 systems, when it was applied, and whether any internet-facing nodes remained unpatched during the September wave. This is not a September zero-day story. It is a story about renewed exploitation of a June-patched flaw.

Then validate exposure at the application boundary, not just the firewall boundary. Mandiant recommends disabling the Environment Management Hub in multi-server configurations or removing the PSEMHUB application in single-server configurations when that is operationally safe. Access logs should be searched for both the literal /PSEMHUB/ path and percent-encoded variants such as /%50SEMHUB/, along with suspicious POST activity or JSP requests around the same time.

From there, containment becomes a filesystem, identity, and outbound-traffic exercise. Inspect the PeopleSoft web-application directory for unauthorized files, especially unexpected JSPs or other web-shell artifacts. Review process execution and installed tooling for Neo-Regeorg, MeshAgent, or other remote-management and tunneling components. Check outbound connections from the host for command-and-control or remote-administration traffic that would not be expected in normal operations.

Credential review is just as important. If PeopleSoft or WebLogic service accounts could read configuration files or stored secrets, rotate the credentials and connection strings those accounts could access, then work outward to connected databases and adjacent systems. Database administrators, identity teams, application owners, and incident responders all hold pieces of the containment evidence here. A clean WAF dashboard does not answer whether the server filesystem was modified, whether a service account exposed secrets, or whether an attacker established persistence.

The deeper lesson is governance. “WAF rule added” is a compensating control, not a postmortem. If an organization cannot patch immediately, the temporary control needs an owner, an expiry date, and a test that exercises how the backend normalizes requests. Attackers in this campaign appear to have counted on the gap between those layers — and on the chance that defenders would stop at the first green status light.