Session CRT-20260620 — 20 June 2026 · Afternoon Edition

Let me checkpoint what James has just added on the Splunk side. The room now has a concrete same-day sequence for CVE-2026-20253, based on Alex’s earlier technical framing: affected Splunk Enterprise ranges are 10.0.0 through 10.0.6 and 10.2.0 through 10.2.3, the exposed issue is unauthenticated arbitrary file creation or truncation via /v1/postgres/recovery/backup, and the clean patch targets are 10.0.7 and 10.2.4. James’s prioritization is clear: patch first, and if the instance is reachable from untrusted networks, isolate or remove it from exposure until the upgrade is complete.

The defensive nuance here is important. This is not just “apply an update when convenient.” If patching cannot happen immediately, the compensating step is to disable the PostgreSQL sidecar according to Splunk’s advisory and restart. And if there is any reasonable suspicion of exploitation, James is telling us not to treat this as a simple configuration cleanup. Preserve the evidence — disk image, Splunk logs, authentication logs, network flow, service and persistence changes, and artifacts around that recovery backup endpoint — then rebuild from known-good rather than trying to sanitize the host in place.

What we have not independently verified in this round is active exploitation volume, attacker identity, or whether a given environment is compromised merely because it runs an affected version. The practical threshold remains exposure plus suspicious endpoint access, file changes, truncation behavior, restarts, or lateral movement from the Splunk host.

That sets up the next turn well. We’ve moved from credential-abuse risk on FortiGate to a specific exposed enterprise service weakness in Splunk. Now we shift to a more actor-and-tooling-centered question: Alex will take us into the FishMonger and SprySOCKS-for-Windows reporting, especially the ESET-linked WIN_DRV and WIN_PLUS components and what defenders should actually hunt for there.

Let me pause the room on Alex’s FishMonger and SprySOCKS guidance, because this changes the way defenders should think about evidence. The key takeaway is that once kernel-level stealth is plausible, the endpoint’s own view becomes suspect. Alex is telling us not to rely on ordinary host commands or visible process, file, registry, and connection listings as the primary source of truth. If WIN_DRV is hiding connections, processes, files, registry keys, and even diverting TCP traffic, then the hunt has to move toward harder-to-fake or external vantage points: earlier EDR telemetry, driver load and service installation records, memory capture, Sysmon or ETW where available, and network-side evidence of command-and-control behavior.

He also gave us an important discipline point on the UEFI angle. ESET’s reporting, as Lena relayed it, includes only low-confidence or limited indications of a possible bootkit component, potentially around CVE-2023-24932. Alex is not dismissing that, but he is warning us not to overstate it. The threshold to escalate that concern should be corroborating evidence: EFI partition changes, unusual boot entries, Secure Boot or BCD manipulation, suspicious firmware-level components, or persistence that survives an operating-system reimage. Until then, treat it as a hypothesis to preserve evidence around, not as a confirmed bootkit finding.

Operationally, the containment message is also measured: isolate the segment, preserve memory and disk, and avoid rushing into destructive remediation before you understand what needs to be collected. That keeps defenders from losing the very evidence that would distinguish ordinary backdoor persistence from kernel tampering or deeper boot-level compromise.

We’re now going to pivot from stealthy endpoint intrusion back to same-day enterprise defense. James has a narrow follow-up on PeopleSoft CVE-2026-35273 in PeopleTools 8.61 and 8.62, with reported active exploitation attributed to ShinyHunters, so the question becomes: what should defenders do today to reduce exposure and detect compromise?

Let me pause us on James’s PeopleSoft guidance. The practical message is straightforward: if an organization has internet-facing PeopleTools 8.61 or 8.62, the safe operating assumption is that it is exposed to active risk now. James is not treating this as a slow advisory-cycle issue; because the reported exploitation is unauthenticated over HTTP and tied in reporting to UNC6240 / ShinyHunters, his advice is to prioritize immediate patching, not prolonged investigation first.

Where patching cannot happen the same day, the compensating control is to sharply reduce reachability: remove the PeopleSoft web and app tier from untrusted access, allow only known administrative or jump-host paths, and treat connected trust relationships as part of the blast radius. The important added point is secret rotation. James specifically called out app-server and scheduler secrets in configuration such as psappsrv.cfg, along with node and trust credentials. In other words, defenders should not only ask, “Was the server vulnerable?” but also, “What could the app server authenticate to, and should those credentials still be trusted?”

The caveat is that this action did not include peer challenge or independent validation of every public attribution detail. We have a clear defensive posture from James, and it aligns with the reported Oracle and Google/Mandiant framing he cited, but the room should keep attribution and exploit-chain specifics separate from immediate exposure management. Patch, isolate, rotate, and review logs and trust paths now; refine actor confidence as more evidence comes in.

That leads naturally to Lena’s panel check next. Before we synthesize, we need to reconcile an evidence gap: the briefing and expert answers have treated several items as operationally important, but our corpus search did not independently return clean same-day matches for all of them. So the next step is not to undo the guidance, but to label confidence correctly and separate what is confirmed, what is reported, and what remains unverified in our source set.

Let me pause us for the confidence check before we synthesize. Lena’s review gives us an important calibration point: the PeopleSoft issue should remain high priority, but we need to be precise about what is confirmed and what is still attribution or actor-supplied reporting. The solid core is that Oracle has a real unauthenticated PeopleSoft vulnerability, CVE-2026-35273, and Google/Mandiant observed ShinyHunters activity exploiting it in late May through early June. The strongest victim pattern called out is education, and the reported tradecraft — propagation scripts, node mapping, and theft of credentials from configuration files — is consistent enough to drive urgent defensive action.

The caveat is equally important: Oracle has not publicly confirmed exploitation in the wild, and the numbers being repeated around “300 instances” or “100 organizations” come from ShinyHunters’ own claims. So we should not present those figures as independently established. Operationally, though, that does not soften the recommendation much. For exposed PeopleSoft, the executive assumption remains: treat the system as potentially compromised until logs, credentials, and app-tier configuration files have been reviewed and validated.

On FishMonger, Lena is drawing a clear line between the confirmed Windows-side tooling and the weaker boot-level claim. ESET’s reporting on SprySOCKS variants, including WIN_DRV and WIN_PLUS, is the firmer ground; WIN_DRV’s kernel-driver stealth and TCP diversion are confirmed in that reporting, and the victim set includes government targets in Honduras, Taiwan, Thailand, and Pakistan. But the UEFI or bootkit angle should be handled carefully. The references to limited indications and CVE-2023-24932 as a possible enabler do not make that a settled finding.

So, as we move into final synthesis, the pattern is: act decisively where exposure and exploitability are clear, but label confidence honestly. PeopleSoft deserves immediate containment and investigation. FishMonger deserves serious detection and hardening attention, while the UEFI element should be framed as a low-confidence lead rather than a proven capability.