Three incidents crossed my desk in the last few days of September 2026. A food delivery company getting squeezed through its own customers, a Japanese railway operator confirming ransomware, and an automated attacker deleting an Azure tenant from the inside. Different targets, different crews, but the same lesson keeps showing up: the controls that fail are boring ones.
LPG Group is billing Flink's customers directly
LPG Group claims it stole data on more than one million Flink shoppers and roughly 13,000 employees. Rather than negotiate only with Flink, the group is contacting customers individually and asking them to pay a small ransom themselves. Cybernews reported the campaign.
This is triple extortion, and the third pressure point is the interesting part. A company has cybersecurity insurance, outside counsel, an incident response retainer, and a legal department that can tell it to refuse payment. A customer has a text message and a vague sense of dread. The demand is priced small on purpose, below the threshold where you'd hire a lawyer to look at it.
Paying buys nothing. The data can still be sold, the payment confirms your contact details are live, and you've now taught the operator that the tactic converts. If you used Flink, change your password, turn on two-factor authentication if the account supports it, and expect phishing that name-drops your order history or a delivery address. That last one is the part people underestimate. An email that knows your last three grocery orders reads very differently than a generic one.
Keio confirms ransomware, Tokyo Metro reports unauthorized access
Keio Corporation confirmed a ransomware attack in the early hours of September 26, 2026, after a systems failure. The company shut down its network to stop further damage, reported the incident to police, and brought in external experts to trace the intrusion and assess what was touched.
The affected systems were on the hospitality side of Keio's business, not train operations. Local media reported payment system disruptions. Keio says it is still determining whether customer or partner data was accessed.
The same weekend, Tokyo Metro disclosed that attackers gained unauthorized access to its systems and reached 59,000 member email addresses. Tokyo Metro says the breached systems held only email addresses and that the weakness used has been identified and closed.
Two Tokyo transit operators hit on the same weekend is the kind of coincidence that makes people reach for a conspiracy. I'd hold off. Neither company has published anything linking the incidents, and railway operators share vendors, contractors, and sometimes infrastructure in ways that make coincidence less surprising than it first looks.
JadePuffer turned loose credentials into a demolition run
Microsoft published research on September 25, 2026 describing an attack in early June that it attributes to JadePuffer, tracked as Storm-3168. Sysdig identified the group in July as the first documented large language model-driven ransomware operation. Microsoft's post is credited to Microsoft Security Research along with Yossi Weizman and Tushar Mudi.
The attacker compromised two service principals in the same Azure tenant. One handled reconnaissance and resource discovery. The second handled discovery, destructive operations, and credential collection. After hours of mapping, the destruction started and moved fast: more than 100 attempts to delete storage accounts, most of which succeeded. The same service principal also deleted an Azure Key Vault, a Function App, and an App Service plan in the same resource group.
Parallel attempts to delete Azure SQL databases failed because the attacker's tooling called an unsupported API version. Sit with that for a second. A cloud environment survived a wipe because of an API version mismatch, not because of a guardrail anyone built.
Thirty minutes after the deletion spree, the service principal requested an inventory of storage accounts, including Site Recovery-related ones, then made more than 30 successful ListKeys calls to pull their access keys. Microsoft did not observe a ransom note and could not confirm exfiltration. Whatever the intent, the capability was there.
How did the attacker get in? Microsoft could not confirm the initial vector, but it found that the service principal's client ID, client secret, and tenant ID had been pasted in plaintext into a public GitHub issue by an employee of the affected organization. The issue was edited later to strip the secret. GitHub preserves edit history, so the secret stayed readable.
What I'd actually change
Long-lived client secrets do not belong anywhere a scraper can reach. If a credential has ever appeared in a public issue, gist, or commit, treat it as burned and rotate it. Editing the post does not rotate anything.
Service principals with delete permissions need the same scrutiny as human admin accounts. The JadePuffer intrusion spent hours on discovery before touching anything. Bulk delete and recovery operations against storage accounts, key vaults, and app service plans are rare and loud. Alert on them, and make sure someone is awake when the alert fires.
Test whether your backups survive a compromised identity. The JadePuffer campaign went after Site Recovery-related storage after the initial destruction. If your backups live in the same tenant and a service principal can list their keys, they are not backups. They are another target.
For Flink customers, the advice is unglamorous and short. Rotate the password, enable two-factor authentication, watch for phishing that references real order details, and do not pay an individual demand. The extortion only works on people who panic.
LPG Group's demand to Flink will be paid or refused, and the story will move on. The client secret in that GitHub issue will still be in the edit history.