Contribution
This post turns the public reporting into an evidence-location model for defenders. The key distinction is where each observation was made. External POST requests, unexpected PSEMHUB files, MeshCentral agent execution and outbound SMB are signals a victim may be able to find. The Python servers, npm setup, meshctrl.js administration, archive handling and final SSH connection were reconstructed from attacker-controlled staging systems. Mixing those two locations creates attractive but unreliable detections.
The practical contribution is a three-part investigation: establish exposure and exploitation at the PeopleSoft edge, prove execution or persistence on the victim web tier, then look for remote access, internal propagation and data access. Cloud identity and storage activity belong in the last join only when the PeopleSoft deployment actually uses those services.
What is confirmed
Oracle published its security alert for CVE-2026-35273 on 10 June 2026. The vendor says the flaw affects PeopleSoft Enterprise PeopleTools 8.61 and 8.62 in the Updates Environment Management component. It is remotely exploitable without authentication over HTTP or HTTPS, has a CVSS 3.1 score of 9.8, and may result in remote code execution. Oracle also warns that unsupported earlier releases were not tested and are likely to be affected, so an inventory limited to 8.61 and 8.62 is not enough to clear older systems.
The exact root-cause label is less settled than the outcome. Oracle does not disclose the exploit mechanism. CISA catalogues CVE-2026-35273 as missing authentication for a critical function, while Rapid7 reports that TrendAI detection signatures classify the underlying flaw as server-side request forgery. Defenders can use SSRF-shaped request patterns as a hunt lead, but should not state that every exploit request must contain a visible loopback address or that SSRF alone explains the full code-execution chain.
Google Threat Intelligence Group and Mandiant attribute the observed campaign to UNC6240, also known as ShinyHunters. They observed activity from 27 May through 9 June 2026, before Oracle's advisory, and notified more than 100 organisations whose addresses correlated with potentially vulnerable endpoints. Sixty-eight percent operated in higher education. CISA added the vulnerability to its Known Exploited Vulnerabilities catalogue on 12 June with a 15 June remediation due date for agencies covered by its directive.
GTIG ties exploitation to PeopleSoft Environment Management Hub endpoints. Its quick guide tells defenders to search PIA WebLogic access logs for external POST requests to /PSEMHUB/hub and /PSIGW/HttpListeningConnector. The latter path also appears in older PeopleSoft exploit research, so it is a durable high-risk management surface rather than a campaign-exclusive IOC.
Keep the evidence locations separate
The campaign report contains three different evidence locations.
First, the victim-facing evidence includes requests to the two PeopleSoft paths, possible outbound SMB from PeopleSoft servers, unexpected JSP files inside PSEMHUB.war, artifacts under PSEMHUB.war/envmetadata/transactions/, unexpected logs, persistantstorage or scratchpad directories under PSEMHUB paths, and recently created or modified XML files under envmetadata/data/environment/. GTIG says the XML files may be used for XMLDecoder execution after an application restart. These are the strongest retrospective checks because they sit on infrastructure the defender controls.
Second, GTIG found customised MeshCentral agent binaries on attacker staging servers. The Windows agents used Azure-like filenames such as meshagent64-azure-ops.exe and were configured to contact wss://azurenetfiles.net:443/agent.ashx. An unconfigured Linux agent was also staged. Finding one of the published hashes, an unexpected meshagent process, or a connection from a PeopleSoft tier to that domain is victim-side evidence. Finding npm, acme-client or meshctrl.js on a PeopleSoft host is not required by the reported chain: those tools were documented on the attacker staging infrastructure.
Third, the exposed staging-server command history described the attacker's administration and payoff. It showed remote commands used to inspect psappsrv.cfg, WebLogic config.xml, mounts and hosts files on compromised systems. It also showed a fan-out script, SSH credential attempts against internal PeopleSoft hosts, zstd compression of an exfil directory, and a final SSH connection from the staging system to 176.120.22.24, the clearnet mirror of the ShinyHunters data leak site. Those observations explain attacker intent and tradecraft. They do not prove that a victim PeopleSoft server itself connected to the leak-site IP or ran the attacker's staging-server setup commands.
That distinction changes the hunt. Query the five published staging IPs and azurenetfiles.net across victim DNS, proxy, firewall and endpoint data. Treat direct contact as strong evidence. Use the data-leak-site IP as context, but do not require a victim-to-DLS connection that the public report did not establish.
Hunt indicators and scope
Use the campaign indicators with the evidence location attached. GTIG found the following infrastructure and payloads on attacker-controlled staging systems:
142.11.200.186through142.11.200.190: five sequential staging servers that exposed Python SimpleHTTP directories on TCP 8888.azurenetfiles.net: the MeshCentral C2 domain embedded in the configured Windows agents. Search historical DNS and TLS or WebSocket telemetry as well as current resolution.f02a924c9ff92a8780ce812511341182c6b509d45bc59f3f7b522e37225d24fc: SHA-256 formeshagent64-azure-ops.exe.d83fdb9e53c5ff03c4cb0451ea1bebd79b53f29eadc1e2fa394c7af13a86ce2f: SHA-256 formeshagent64-v2.exe.c7e9332731b06644fc73e0046a2a89eaa59b09f54250e9bd622467187351711f: SHA-256 formeshagent32-azure-ops.exe.68257a6f9ff196179ec03624e849927f26599eb180a7c82e14ef5bc4e93bc309: SHA-256 for the unconfigured Linuxmeshagentstaged by the actor.
The staging IPs and domain are hunt indicators, not permanent ownership assertions. Bound searches to the campaign period, retain passive-DNS and certificate context, and confirm present ownership before blocking. The hashes identify staged payloads more durably, but a hash match on a victim host is meaningful only when the file location, execution and surrounding telemetry are preserved.
Why cloud defenders should care
PeopleSoft is enterprise application infrastructure, but its control points often sit in cloud telemetry. Internet exposure may be created by a cloud load balancer, reverse proxy, WAF or firewall policy. The application tier may run on cloud compute, authenticate through central identity, mount managed file storage, or feed object-storage exports and backup jobs. A web-tier compromise can therefore become a cloud incident, but only when those integrations exist.
The immediate cloud question is exposure. GTIG says restricting /PSEMHUB/* and /PSIGW/HttpListeningConnector from the external internet does not break standard end-user PeopleSoft Internet Architecture browser sessions. That makes the route a useful preventive control: identify every public listener that can forward to those paths, then remove or tightly restrict that reachability instead of relying only on WAF body inspection.
The follow-on question is privilege. Record which identities the PeopleSoft web, application, process-scheduler and export tiers use. For each identity, document reachable databases, object stores, file shares, secrets and backup systems. This is not proof that the ShinyHunters campaign accessed cloud storage. It is the blast-radius map needed when a PeopleSoft host is confirmed compromised.
ATT&CK mapping
The entry is T1190, Exploit Public-Facing Application. Oracle describes unauthenticated network exploitation, and GTIG ties the campaign to internet-reachable Environment Management Hub endpoints. T1190 remains the frontmatter mapping because it is the confirmed entry behaviour and has a first-class a13e technique page.
MeshCentral use maps to T1219, Remote Access Tools, when an agent is installed or executed on a victim system. The Azure-like filenames and cloud-adjacent domain are masquerading details, not proof that the traffic is legitimate Microsoft activity. Defenders should validate the binary hash, signer, parent process, installation path and destination rather than trusting the filename.
The propagation script maps to T1021.004, SSH, and may also support password-guessing analysis because it iterated hardcoded usernames and passwords across internal hosts. The extortion marker copied into WebLogic and process-scheduler directories is impact evidence. The zstd command is consistent with T1560.001, Archive via Utility, but the public evidence places that command in exposed attacker staging history. Apply the mapping to a victim only if victim telemetry shows the utility or archive.
The report does not disclose enough transport evidence to assign a precise exfiltration sub-technique to every victim. A staged archive and a later SSH session on attacker infrastructure establish an exfiltration workflow at campaign level, but not the exact source, destination and transport of each victim's stolen data.
Detection guidance
Start with an exposure query, not an IOC query. Inventory internet-facing routes to /PSEMHUB/* and /PSIGW/HttpListeningConnector across cloud load balancers, reverse proxies, WAFs, WebLogic and perimeter firewalls. Record the backend PeopleSoft domain, PeopleTools version, owner and whether the route is required. Older unsupported versions need explicit investigation because Oracle says they were not tested and are likely affected.
At the edge, alert on external HTTP POST requests to /PSEMHUB/hub or /PSIGW/HttpListeningConnector. Add severity when the source is new to the application, when the path is not normally internet-facing, or when Integration Broker headers or parameters contain loopback or internal addresses. Rapid7 and GTIG recommend inspecting 127.0.0.1, localhost, ::1 and internal ranges as SSRF indicators. Their presence raises confidence; their absence does not clear a PSEMHUB request.
where http.method = "POST"
and url.path in ("/PSEMHUB/hub", "/PSIGW/HttpListeningConnector")
and source.zone not in ("trusted_admin", "peoplesoft_internal")
Then inspect the web-tier filesystem. Compare JSP files inside the deployed PSEMHUB.war tree with a known-good release. Search the envmetadata/transactions path for unauthorised files or binary drops, and review the named PSEMHUB subdirectories for recent creation. Examine modified XML files under envmetadata/data/environment/, especially around application restarts. Preserve timestamps and hashes before remediation because a patch does not remove persistence or attacker-created content.
Join those signals to endpoint and network telemetry. Look for the MeshCentral agent hashes listed above, unexpected meshagent execution, connections to azurenetfiles.net, configuration discovery against psappsrv.cfg or WebLogic config.xml, creation or execution of a victim-specific _fanout.sh file, sshpass use, and the extortion marker filename. A sequence of external management-path POST, unexpected JSP or XML change, remote-access agent activity and internal SSH attempts is substantially stronger than any single IOC.
Monitor outbound SMB on TCP 445 from PeopleSoft servers to untrusted internet destinations. GTIG and Rapid7 warn that the exploit chain may coerce outbound SMB to capture Windows machine-account NetNTLM hashes. Block that egress where it is not explicitly required. Also review WebSocket-over-TLS connections and direct traffic to the published staging IPs, but keep time bounds and passive-DNS history because infrastructure ownership can change.
Finally, query identity and data-plane logs only for integrations the compromised tier can reach. Look for unusual database exports, object-store reads, new access grants, backup retrieval, secret access or large file transfers by a PeopleSoft-associated identity after the first web or host signal. Report these as confirmed follow-on activity only when the audit record identifies the principal, resource and time. Do not infer cloud data theft from the ERP exploit alone.
Triage decisions
An exposed route without suspicious requests is a critical exposure that requires immediate mitigation. An external POST to either management endpoint is a hunt trigger, not proof of code execution. Temporally correlate that request with a JSP absent from the shipped baseline, an unauthorised PSEMHUB transaction artifact, an XML change outside approved deployment or restart activity, or outbound TCP 445 to an untrusted internet destination. That combination supports suspected exploitation and urgent host triage. Add a published MeshCentral agent, C2 contact, internal SSH propagation, confirmed web shell or extortion marker and treat the host as compromised.
Data access is a separate decision. Local archive creation, database export activity, object-store reads or unusual backup access after compromise make data theft plausible. A victim-specific leak publication or verified transfer makes it confirmed. Keeping these thresholds separate prevents both under-response to a web-tier compromise and overstatement of an exfiltration path that the available logs do not prove.
False positives should be tuned by role and sequence. Internal administrators may access PSEMHUB during maintenance, and PeopleTools processes legitimately read configuration files. Backup jobs may compress large datasets. What should not be normal is an external source reaching a management path followed by an unknown JSP, MeshCentral C2, outbound SMB, sshpass propagation or a victim-specific extortion marker.
What to do now
Apply Oracle's patch or mitigation guidance immediately for supported PeopleTools 8.61 and 8.62 systems. Identify older releases separately rather than assuming they are safe. Where patching cannot happen immediately, disable the Environment Management Hub service in multi-server configurations, remove the PSEMHUB application in single-server configurations, or block external access to /PSEMHUB/* and /PSIGW/HttpListeningConnector at the perimeter.
Run a retrospective hunt from at least 27 May 2026. Search edge and PIA WebLogic logs first, then preserve and inspect the web-tier filesystem. Review endpoint, DNS, proxy, NetFlow and firewall data for the agent hashes and infrastructure listed above, outbound SMB and internal SSH activity. Patching closes the entry path but does not remove web shells, XMLDecoder persistence, remote-access agents or copied credentials.
Contain confirmed hosts before collecting broad cloud evidence. Remove them from load balancer target groups, restrict egress, preserve volatile and filesystem evidence, rotate credentials available to the tier, and review adjacent PeopleSoft nodes reached by the fan-out pattern. Validate every service account and export integration attached to the affected environment.
The main defender lesson is evidence location. The public reporting gives unusually rich visibility into attacker staging infrastructure, but the incident decision still has to be made from victim-controlled logs. Join the external management request to victim filesystem or execution evidence, then prove the data-access path. That is how an ERP zero-day becomes a defensible detection rather than a list of campaign artifacts.