Google Mandiant says PeopleSoft attacks linked to ShinyHunters have resumed at scale, with operators changing their infrastructure to bypass some defenses introduced after the earlier campaign. The key warning is practical: a web application firewall rule can reduce exposure to a known request pattern, but it is not a substitute for installing Oracle’s security update and checking whether a system was already compromised.
PeopleSoft attacks: what is confirmed
Reuters reported on September 26 that Mandiant had observed dozens of affected systems across higher education, technology, healthcare, agriculture, transport, and government. The earlier activity ran from May 27 to June 9 and heavily targeted universities. The renewed activity shows that attackers monitor published defensive guidance and adapt when temporary controls become common.
ShinyHunters also claimed that the same access path yielded data connected to the FBI, but Reuters could not independently verify that claim. The FBI said it was investigating the reported incident. That distinction matters: renewed mass exploitation of PeopleSoft is supported by Mandiant’s observations, while the scope of the alleged FBI data theft remains an attacker claim.
Why a firewall rule is not enough
A web application firewall can block a known request structure, address, or behavior. It does not remove the vulnerable code. If an attacker changes request formatting, infrastructure, or the order of operations, a narrow rule may stop matching. A patch addresses the underlying flaw, which is why Mandiant specifically highlighted systems that had deployed defensive rules but remained unpatched.
PeopleSoft installations often handle human resources, finance, procurement, payroll, and student records. A compromise can therefore expose far more than an application login page. Possible data includes employee or student details, banking information, tax records, health-related data, and privileged credentials. Administrators should also assume that a compromised application server may become a starting point for movement into other systems.
Immediate actions for administrators
- Identify the exact PeopleTools and PeopleSoft versions and install the applicable Oracle security update.
- Review web, application, identity, and outbound network logs from late May onward for unusual administrative actions and bulk exports.
- Rotate privileged passwords, API keys, and service credentials when any sign of compromise exists.
- Isolate affected systems and preserve evidence before rebuilding or deleting files.
- Inventory public test, disaster-recovery, and forgotten instances instead of checking production alone.
Indicators from an earlier campaign should be used as context, not as a complete checklist. Attacker domains and addresses change. The absence of an old indicator does not prove a system is clean. Teams should build a timeline from software versions, patch records, accounts, processes, scheduled tasks, configuration changes, and network activity.
Don’t miss this
How to verify remediation
Record the patch identifier, installation time, rescan result, and the system owner who confirmed that business functions still work. Verify that the vulnerable route is no longer exposed and keep WAF controls as an additional layer. In large environments, asset discovery is often the hardest step, so CMDB records should be compared with network scanning and cloud inventory rather than accepted without verification.
If compromise is plausible, handle the case as a potential data breach rather than routine maintenance. SajberSfera’s Serbian report on the actively exploited Check Point VPN vulnerability describes the same operational sequence: patch and contain, then investigate evidence and document decisions.
Data protection and notifications
Legal and privacy teams should be involved after the technical scope is established. Notification duties depend on the data, affected people, location, and applicable law. Teams should not delay containment while debating language, but they should avoid making unsupported claims about impact. Preserve the facts needed to explain what happened, which records were accessible, and what protective steps users should take.
Resetting every password without understanding the access path may destroy useful evidence and still leave service credentials exposed. A coordinated response should define who owns containment, forensics, communications, and recovery. External incident-response support may be appropriate when the organization lacks clean logging or when regulated data is involved.
Conclusion
The renewed PeopleSoft attacks do not mean firewall controls are useless. They show why a temporary mitigation cannot be treated as a patch. Organizations should confirm the actual software version, install Oracle’s update, identify every exposed instance, and investigate signs of compromise. ShinyHunters’ ability to adapt to public defenses makes evidence-based verification more important than assuming an earlier rule still works.
