Satine Sentinel: July 3, 2026

This week the pattern wasn’t a single flashy exploit, it was arithmetic. One zero-day from late May kept generating new victim disclosures for five straight weeks, and this week the bill came due for a carmaker, a farm equipment manufacturer, and the body that regulates America’s insurance industry, all in the same 48 hours. A Japanese insurer’s customer portal sat open to intruders for ten days before anyone noticed. A password-spraying campaign proved that having MFA turned on and having MFA actually cover how your employees log in are two different claims. And Japan’s government ordered a nationwide check of USB drives after discovering that counterfeit flash drives carrying Chinese-linked malware had been plugged into classified military networks for the better part of a year.

This week: what happens when a single ERP vulnerability keeps producing new victims a month after the exploit window closed, why an insurance company’s own customer portal became its biggest liability, how attackers turned a legacy Microsoft login flow into an MFA bypass at scale, and what a hardware supply chain failure inside a national military looks like when nobody checks the box before it ships.

The Oracle PeopleSoft Zero-Day Keeps Finding New Victims: Nissan, Kubota, and NAIC Disclose in the Same Week

What happened:

Between May 27 and June 9, threat actors linked to ShinyHunters exploited CVE-2026-35273, a critical, unauthenticated remote code execution flaw in Oracle PeopleSoft’s Environment Management Hub, as a zero-day before Oracle shipped an emergency out-of-band patch on June 10. Google’s Mandiant notified more than 100 organizations whose systems matched the exploitation pattern, and victim disclosures have been arriving in waves ever since rather than all at once. This week that wave crested: Nissan Americas filed notice with the California Attorney General on June 26 confirming theft of current and former employee data across the US, Canada, Mexico, and Brazil, Kubota North America disclosed a nearly identical PeopleSoft HCM data theft affecting employees and dependents, and the National Association of Insurance Commissioners, the standards body that supports every US state insurance regulator, confirmed its own PeopleSoft instance was hit and that stolen files were published on ShinyHunters’ leak site.

Technical details that matter:

Mandiant’s incident response traced the exploitation to a “gadget chain,” meaning the newly disclosed zero-day was combined with older, previously known PeopleSoft vulnerabilities to achieve full unauthenticated remote code execution against internet-facing Environment Management Hub (PSEMHUB) endpoints. Once inside, the attackers deployed a customized MeshCentral remote management agent, version 1.1.59, disguised behind a lookalike domain built to resemble Azure NetApp Files, and used it to run administrative queries against the compromised PeopleSoft and WebLogic environments. A lateral-movement script, individually named for each victim, sprayed a hardcoded list of usernames and passwords over SSH against internal hosts pulled straight from each server’s own /etc/hosts file, and read the PeopleSoft application server’s psappsrv.cfg configuration file to extract database credentials outright. Stolen data was compressed with zstd before exfiltration. The compromised organizations span PeopleSoft’s core use case almost exactly: HR, payroll, benefits, and tax administration data, meaning Social Security numbers, dates of birth, driver’s license numbers, direct deposit bank details, and dependent and beneficiary information at Nissan and Kubota. NAIC’s case is the more reassuring outlier so far, the organization says its own analysis indicates the exposed data was largely public-facing regulatory filings and outdated logs rather than sensitive personal information, though that assessment is still being reconciled against what ShinyHunters actually posted.

Why critical institutions should care:

PeopleSoft is core HR and payroll infrastructure at universities, manufacturers, automakers, and now a national insurance regulator, which means a single vendor zero-day produced a cross-sector mass-casualty event rather than an isolated breach. The uncomfortable detail for any organization that patched on June 10 or later: exploitation predated the patch by two weeks, so applying the fix closes the door but does not tell you whether someone already walked through it. If your organization runs PeopleSoft, or a vendor in your supply chain does, “we’re patched” answers a different question than “were we compromised during the exploitation window.”

Key sources:

Aflac Japan: Ten Days of Undetected Access Through the Customer Portal Everyone Uses

What happened:

Aflac Life Insurance Japan disclosed on June 30 that unauthorized attackers accessed its policyholder portal, known as Yoriso Net, multiple times between June 15 and June 25 before the intrusion was detected, exposing personal and financial data belonging to approximately 4.38 million customers and agents, plus contact information for roughly 40,000 partner insurance agencies. This is a separate incident from the PeopleSoft campaign above and, per Aflac’s own statement, unrelated to the 22.65 million-person breach the company disclosed in the US just last year. Exposed data varies by individual but includes names, addresses, phone numbers, dates of birth, gender, policy numbers, and coverage details, and roughly 230,000 customers also had their insurance premium transfer bank account information, financial institution name, branch, account type, and account number, exposed. Aflac says no credit card numbers or Japan’s national ID numbers (My Number) were compromised.

Technical details that matter:

Public disclosures so far describe the entry point as unauthorized access to the customer-facing Yoriso Net portal rather than a network-wide compromise, and Aflac has not detailed the specific vulnerability or technique used to gain that access. What is confirmed is the dwell time: attackers returned to the portal repeatedly across a ten-day window before anomalous activity was flagged on June 25, which points either to a lack of behavioral monitoring on customer-portal query patterns or thresholds tuned to miss repeated, low-and-slow access rather than a single large exfiltration event. Aflac’s response, suspending portions of the portal and several dependent services including medical checkup scheduling and its AI support concierge, indicates the containment required taking customer-facing functionality offline rather than isolating a narrow backend system, which suggests the compromised access was tied closely to production portal infrastructure rather than a segregated data store.

Why critical institutions should care:

Insurance portals sit at an uncomfortable intersection: they are customer-facing by design, meaning they must be internet-reachable and usable by millions of ordinary policyholders, while holding exactly the data an attacker wants, personal identifiers, coverage details, and banking information for premium transfers. A ten-day detection gap on a system built for high-volume legitimate customer traffic is a telemetry problem as much as an access-control one: distinguishing an attacker methodically pulling records from thousands of customers doing exactly the same thing requires baselining normal portal query behavior, not just perimeter defense. For any institution running a customer or patient self-service portal, particularly one holding both personal and banking data, this is a second data point this month (after London Hydro last week) that portal-layer monitoring deserves the same investment as network-layer detection.

Key sources:

Your MFA Isn’t Covering What You Think It Covers: The Azure CLI Password Spray Campaign

What happened:

Cybersecurity firm Huntress disclosed on June 30 a sustained, automated password spray campaign against Microsoft’s Azure command-line interface that, between June 12 and June 26, generated more than 81 million login attempts and successfully compromised at least 78 Microsoft 365 accounts across 64 organizations. Compromises started at a slow trickle of two to four accounts a day, then spiked to 30 compromised identities across 23 businesses in a single day on June 22. The traffic originated almost entirely from an IPv6 range controlled by internet infrastructure provider LSHIY LLC, tied to Hong Kong and mainland China business addresses, and Huntress says it reported the activity through LSHIY’s abuse channel without response. The activity ceased around July 2 after LSHIY reportedly terminated service to the responsible customer, though Huntress frames this as one wave within a much larger trend: credential spray volume across its customer base has increased over 155-fold in the past six months.

Technical details that matter:

The technique is not a new vulnerability, it’s an old, deprecated OAuth flow that many organizations forgot was still active. Attackers replayed previously breached, never-rotated username and password combinations against Azure CLI’s use of the OAuth 2.0 Resource Owner Password Credentials (ROPC) grant, which sends the raw username and password directly to the token endpoint and mints a valid, user-delegated access token with no interactive MFA prompt at all, because ROPC predates modern authentication flows and was never built to support one. That matters because a meaningful share of the compromised organizations, 15 of the 23 hit in the June 22 spike, had Conditional Access Policies enforcing MFA. The MFA simply never triggered, because the policies covered “All Cloud Apps” through browser-based sign-in but not “Other clients,” the Conditional Access category that includes Azure CLI, PowerShell, and legacy protocols like IMAP and Exchange ActiveSync, or because MFA was scoped only to specific user groups (commonly “Admins Only”) that excluded the accounts actually targeted, or in a smaller number of cases because MFA was configured in report-only mode and never actually enforced. Eight of the impacted businesses had no MFA policy at all. Once authenticated, attackers gained full mailbox, SharePoint, and OneDrive access and were observed creating mailbox forwarding rules to exfiltrate mail externally and searching SharePoint for financial documents.

Why critical institutions should care:

This is the uncomfortable finding for any organization that has checked the “we require MFA” box and moved on: MFA enforcement is not binary, it is scoped, and the scoping gaps are invisible until someone tests the specific authentication path attackers actually use. Azure CLI and PowerShell are not edge-case tools, they’re standard in IT administration, DevOps pipelines, and increasingly AI-agent tooling across every sector, which means the blind spot this campaign exploited is common infrastructure rather than a niche configuration error. Any institution relying on Microsoft 365 or Entra ID, which is to say nearly all of them, should treat this as a direct prompt to verify Conditional Access actually covers every client app type, not just the browser sign-in flow security teams tend to test.

Key sources:

Japan Orders Nationwide USB Review After Counterfeit, Malware-Laced Drives Sat Inside Classified Military Networks for a Year

What happened:

A note on timing before this one: the underlying compromise was discovered by the Japan Ground Self-Defense Force back in February 2025, and Nikkei’s investigative reporting that first brought it to public light broke on June 25, just outside this edition’s window. We’re covering it this week because the government response, a nationwide security review, was announced on July 3 and represents a live, developing story with direct institutional consequences, not because the breach itself is new. Nikkei’s reporting, based on leaked internal documents, found that counterfeit USB drives distributed to the JGSDF’s Middle Army headquarters in Itami in March 2024, during Noto Peninsula earthquake disaster relief operations, were infected with malware linked to a known Chinese hacking group. Six of eight tested drives carried the malware, which had connected to more than 50 of 480 computers at the facility, nearly half of them on closed, air-gapped networks used for classified command-and-control information, before anyone noticed. This week, Japan’s Cabinet confirmed that the internal affairs ministry is preparing a nationwide inspection of USB memory device usage across local governments in response.

Technical details that matter:

The drives were counterfeit hardware: labeled as 1TB flash storage but actually built around cheaper, slower microSD cards with roughly a quarter of the advertised capacity, a common “capacity-expanded” counterfeiting technique, with malware embedded during manufacturing rather than added later. The infection went undetected for nearly a year because JGSDF’s antivirus scanning regime, despite requiring scans of removable media on receipt and during use, did not actually include USB drives within its scanning scope, a gap that rendered the organization’s own stated security control moot in practice. The malware was discovered only when a soldier at Middle Army headquarters noticed a computer running abnormally slowly in February 2025, triggering a forensic look at a recently inserted drive. Japan’s Ministry of Defense has since characterized the specific payload as a “legacy type” limited to self-replication that did not perform data exfiltration or external command-and-control communication, and said it did not spread beyond directly connected machines, though the broader research community has linked the same malware family to prior operations against government, education, and telecommunications targets in Vietnam and Australia. Procurement records for the drives cannot be located: Ishikawa Prefecture, which allegedly supplied them during disaster relief, says it has no record of purchasing or providing them, leaving the actual supply chain entry point unresolved.

Why critical institutions should care:

This incident is a case study in the gap between a written security policy and what it actually covers in practice: an organization can require scanning of removable media and still have zero protection against USB-borne malware if the scanning tool’s configuration silently excludes the device class in question. It’s also a textbook example of counterfeit hardware entering a sensitive environment through an emergency-response side channel, disaster relief logistics, that bypassed normal procurement vetting entirely, and of an institution choosing not to disclose a known compromise for well over a year despite the counterfeit product remaining commercially available to others. For any government, defense, or critical infrastructure operator, the actionable question is not “do we scan removable media,” it’s “does our scanning tool’s policy actually apply to every device class we think it does,” and whether emergency procurement processes get the same hardware vetting as routine purchasing.

Key sources:

The Pattern This Week

Three of this week’s four stories share a detection problem, not an access problem. Nissan, Kubota, and NAIC didn’t fail to patch fast enough, they were compromised during a two-week zero-day window that existed before a patch was even available, and are only now, a month later, working out who else touched their PeopleSoft environments in that window. Aflac Japan’s attackers walked in and out of a live customer portal ten separate days before anyone flagged it. The JGSDF’s malware sat inside classified military networks for nearly a year because a security control that looked complete on paper, “we scan removable media,” had a silent gap that made it meaningless in practice. Only the Azure CLI campaign involved genuinely novel technique, and even there the novelty was rediscovering that a deprecated authentication flow from before modern MFA existed is still live and still exploitable at scale.

The throughline: every one of these organizations had a control in place that should have caught the problem faster, a patch cycle, portal monitoring, antivirus scanning, MFA policy, and in each case the control had a scope gap invisible from the outside until an attacker (or a Nikkei investigation) found it. Fast detection matters more than perfect prevention when the initial compromise vector is a zero-day, a legacy protocol, or counterfeit hardware smuggled in through an emergency logistics channel. None of this week’s institutions could have simply patched their way out of what happened to them.

See you next week.

What Your Business Can Do This Week

If you run Oracle PeopleSoft, or know a vendor that does, assume compromise during May 27 to June 9 regardless of current patch status. Applying the June 10 patch for CVE-2026-35273 closes the vulnerability going forward, it does not tell you whether an attacker was already inside during the exploitation window. Review PeopleSoft and WebLogic logs from that period for unexplained MeshCentral agent installations, connections to unfamiliar domains resembling Azure or cloud infrastructure names, and unexpected outbound SSH or zstd compression activity. If you have vendors who process your HR or payroll data through PeopleSoft, ask them directly whether they were in scope.
Audit your Conditional Access policies for client app coverage, not just user and app coverage. The Azure CLI campaign succeeded specifically because MFA policies covered “All Cloud Apps” through browser sign-in but excluded “Other clients,” the category covering Azure CLI, PowerShell, IMAP, and Exchange ActiveSync. Confirm every Conditional Access policy explicitly targets all client app types, not just interactive browser logins, and consider enabling the userStrongAuthClientAuthNRequired setting to block ROPC token grants outright. If you haven’t tested your policies against Microsoft’s “What If” simulator recently, do it this week.
If you operate a customer-facing portal handling personal or financial data, verify it has behavioral monitoring, not just access logging. Aflac Japan’s ten-day dwell time and London Hydro’s incident from two weeks ago both point to the same gap: a valid, authenticated session accessing records at an unusual volume or pattern didn’t trigger alerts fast enough. Confirm your portal monitoring can distinguish a single account browsing thousands of other customers’ records, or a single account returning to pull data across many separate sessions, from normal usage patterns.
Confirm your antivirus and endpoint security tools actually scan the device classes your written policy says they cover. The JGSDF incident is a stark reminder that “we require scanning of removable media” and “our tools actually scan removable media” are two different claims. Spot-check your own environment: does your endpoint protection genuinely inspect USB storage devices on connection, or does its default configuration silently exclude that device class the way JGSDF’s did?
Treat emergency and disaster-response procurement with the same hardware vetting as routine purchasing. The counterfeit USB drives entered JGSDF’s environment through a disaster relief logistics channel that bypassed normal procurement controls. If your organization has an emergency-response or crisis-procurement process that can source equipment quickly outside standard vendor vetting, confirm it still requires verified-vendor sourcing for any hardware that will touch your network, even under time pressure.

The Oracle PeopleSoft Zero-Day Keeps Finding New Victims: Nissan, Kubota, and NAIC Disclose in the Same Week

Aflac Japan: Ten Days of Undetected Access Through the Customer Portal Everyone Uses

Your MFA Isn’t Covering What You Think It Covers: The Azure CLI Password Spray Campaign

Japan Orders Nationwide USB Review After Counterfeit, Malware-Laced Drives Sat Inside Classified Military Networks for a Year

The Pattern This Week

What Your Business Can Do This Week

Like this:

Ready to Strengthen Your Defenses?