On 17 August 2026, Quest Apartment Hotels — one of Australia’s largest serviced-apartment operators, trading for roughly 35 years across more than 160 properties in Australia, New Zealand and Fiji — identified unauthorised access to a database system, tracing the entry point to a vulnerability in a third-party service provider rather than its own infrastructure. Its initial disclosure described the exposure as “primarily names, email addresses, and/or other contact details.”
That initial picture didn’t hold. A mid-September update, following completed forensic analysis, confirmed the incident affected approximately 1,991,613 customers — and that the exposed data included 297,739 credit card numbers (46,727 with CVV), 104,268 passport and/or driver’s licence numbers, 225,300 vehicle registration numbers, and a small number of Medicare and NDIS numbers. All records predate June 2025.
Between the 17 August disclosure and the mid-September revision, the scope of “what was taken” grew by roughly 500,000 records and added three entirely new categories of exposed data — CVVs, passports and Medicare numbers — none of which featured in the first public account.
Source: Cyber Daily, Information Age, SBS News, Insurance Business magazine — August–September 2026
The Cyber Security Act 2024’s mandatory ransomware payment reporting requirement has been in full enforcement since 1 January 2026. ASD’s ACSC responded to 138 ransomware incidents in FY2024–25 — a number regulators will now see reported in closer to real time, whether or not the organisations involved want it that way.
Source: Cyber Security Act 2024; ASD’s ACSC Annual Cyber Threat Report 2024–25
LOGGING LESSON
Three different mechanisms, one shared gap. Quest’s exposure sat in a vendor’s environment. Mathspace’s sat in the three weeks between a published patch and an applied one. Agrimac and Ramsey Bros sit inside a sector-wide campaign where the same group is working down a list of similarly under-defended dealerships.
None of that is visible from inside a single organisation’s own alert queue. What makes it visible is retained, correlatable evidence across all three layers:
- Vendor and SaaS integration logs — an independent record of every API call or data pull a third party’s integration makes against your own systems, not just their post-incident summary.
- Vulnerability-to-patch timelines, logged and queryable — not just “patched: yes/no”, but when the advisory landed, when the patch was applied, and what activity occurred in between.
- Sector and threat-actor pattern data — if a ransomware group is working through an industry vertical, your own indicators are more useful read alongside everyone else’s, not in isolation.
Example AskSnare query for this: “Show me every system still running an unpatched version of a vulnerability disclosed in the last 30 days, and how long each one has been exposed.” A question like that only has an answer if patch status and vulnerability timelines are being logged and retained, not just tracked in a ticketing system that doesn’t talk to your evidence layer.
In late June 2026, an unauthorised party accessed files belonging to Japan’s Government Solution Service (GSS) using the account of a maintenance and operations employee. It wasn’t until a follow-up investigation in July that GSS traced the entry point to an exploited vulnerability in a VPN product used for remote administrative access. Japan’s digital agency disclosed the incident publicly in September, confirming that attackers compromised more than 246,000 records — names, addresses, email addresses and phone numbers belonging to public officials, administrative staff, and businesses and individuals working with the agency.
The sequence is the story here, more than the record count: access in late June, root cause identified in July, public disclosure in September. For roughly two months, GSS knew a VPN vulnerability had been exploited before it could say publicly what had actually been taken — because establishing the “what” required reconstructing the compromised account’s activity after the initial access, not just patching the vulnerability that let the attacker in.
Source: Kaseya, “The Week in Breach News,” September 23, 2026; Japan Digital Agency disclosure, September 2026
LOGGING LESSON
Put Gyazo and the APIS exposure either side of GSS and the range gets wide fast: a same-evening detection that was still too late, a possible multi-year blind spot nobody can bound, and a three-month gap between knowing the door was open and knowing what had been taken.
Speed of detection and completeness of evidence are two different problems, and solving one doesn’t solve the other. Gyazo proves that even fast detection doesn’t roll back data already exfiltrated — which shifts the question from “how fast did we notice” to “what can we now prove was taken, and when.” The APIS case proves that an asset nobody is actively monitoring can sit exposed for years with no one able to answer that question at all.
- Asset discovery and exposure monitoring that covers infrastructure outside the core estate — a database matching “pax-info” or similar naming patterns on an external scan is a finding, not background noise.
- Upload and object-storage access logging with enough granularity to bound exactly what was read or downloaded in a compromise window measured in hours, not just whether the service was reachable.
- Session and resource-access logging for any compromised identity, retained long enough to cover a realistic gap between exploitation and root-cause discovery — GSS’s was roughly a month, M-Trends 2026’s global median is 14 days.
Example AskSnare query for this: “List every external-facing data store added or re-indexed in the last 90 days that has no corresponding access-logging policy attached.” Turning that into a natural-language question against retained inventory and logging-policy data is the kind of query an analyst can ask without first becoming a query-language expert.
On 12 September 2026, British fintech Revolut confirmed it had disclosed sensitive customer data to an unauthorised third party — not through a system intrusion, but through a fraudulent information request. The request arrived from an email address operating inside a real government agency’s own domain, and it carried valid SPF, DKIM and DMARC authentication. Revolut’s compliance and legal team, satisfied the request was genuine because it passed every technical check designed to catch exactly this kind of spoofing, released files for a limited number of customers: identity documents including passports and driver’s licences, dates of birth, addresses, phone numbers, and in some cases verification selfies, account statements and transaction histories including cryptocurrency activity.
A threat actor then stood up an extortion site claiming to hold the full dataset and demanding payment.
Source: TechCrunch, The Register, Infosecurity Magazine, Security Affairs — September 2026
As of this September, the EU Cyber Resilience Act requires hardware and software manufacturers to report any actively exploited vulnerability or severe security incident within 24 hours, to national CSIRTs and ENISA’s new Single Reporting Platform. Fines for serious breaches reach €15 million or 2.5% of global turnover.
Source: Euronews, “The EU spent billions on a cyberattack shield — nobody checked if it worked,” September 2026
THE LOGGING LESSON
Two of the three UK/Europe stories this fortnight involved no attacker at all. Southampton’s notebook and records-destruction issue and P&O’s misdirected text are process failures — which matters, because it means the evidence gap here isn’t only about detecting intruders. It’s about being able to prove, after the fact, exactly what was shared, with whom, and when, regardless of whether anyone broke in.
Revolut’s incident makes the same point from the opposite direction: every technical authentication control worked, and the data still went out the door, because domain authenticity and requester authority are two different things, and only one of them was checked.
- An independent, retained authorisation trail for any data release made in response to an external request — who approved it, what verification was completed, and what specifically was sent — separate from the channel that triggered the release.
- Outbound-communication logging for any message, link or attachment containing personal data at volume, so a misdirected send can be scoped by exactly who received it, not estimated after the fact.
- Records-disposal and retention-policy logging, so a premature deletion is visible as an event in its own right rather than discovered only when someone goes looking for a record that should still exist.
Example AskSnare query for this: “Which customer-data releases in the last 30 days have no matching verification record on file?” That’s a question about process evidence, not intrusion evidence — and it only has an answer if authorisation steps are logged as rigorously as authentication events are.
On 1 September 2026, an unauthorized third party, posted on a cybercrime forum claiming to have extracted 7.49 million customer records from CenterPoint Energy, a Houston-based utility serving roughly 7 million electricity and gas accounts across Texas, Indiana, Minnesota and Ohio. The actor described the source as one of CenterPoint’s own public APIs, lacking rate limiting and adequate authentication — meaning the data wasn’t stolen through a breach of internal systems, but scraped at scale through a feature the company had deliberately exposed to the internet.
CenterPoint confirmed the breach in a Form 8-K filed with the SEC on 14 September, acknowledging that an unauthorised party had accessed customer information — names, phone numbers, addresses, account numbers, billing amounts, and partial Social Security numbers — through an external-facing system, while stressing that electricity and gas delivery systems were unaffected. Class-action filings allege the exfiltration window ran from 17 August to 1 September, roughly two weeks before the public disclosure. The same actor separately claimed a future attempt would target “the main infrastructure” rather than customer data.
Source: The Record, SC World, Board Cybersecurity, Tech Insider — September 2026
CISA’s CIRCIA final rule has slipped from its original October 2025 target to May 2026, and then to September 2026. After holding town hall meetings, CISA has sent the final rule to the Office of Management and Budget for review, with publication expected before the end of the year. As proposed, it would require covered critical infrastructure entities to report a substantial cyber incident within 72 hours of determining that it has occurred, and to report a ransom payment within 24 hours of making it — timelines that assume the evidence needed to meet them already exists when the clock starts.
Source: HIPAA Journal, “CISA CIRCIA Final Rule Sent to White House for Review,” 5 October 2026; CISA CIRCIA rulemaking
THE LOGGING LESSON
The Florida credential and CenterPoint’s API sit at opposite ends of the same spectrum. One is a single stolen credential reaching a tightly restricted, high-sensitivity database. The other is a public, unauthenticated endpoint reached at a volume nobody thought to cap. Neither looked like an intrusion from inside an authentication log — one was a valid login, the other had no login to log.
McKesson adds a third variant: a breach that routed through third-party applications rather than McKesson’s own core systems, echoing Quest’s vendor-origin exposure in this week’s Australia story.
- Credential-storage and personal-device policy violations treated as a loggable, alertable event — not just a policy document nobody checks compliance against.
- Per-key and per-IP request-rate logging with alerting thresholds for any public API handling personal data, plus response-size and record-count logging, not just HTTP status codes.
- Third-party application and integration inventories correlated against the access each one actually uses, so a compromised app’s blast radius can be bounded quickly rather than discovered business-unit by business-unit.
Example AskSnare query for this: “Which of our public APIs have no rate-limiting or per-key request logging configured?” Asked in plain language against an evidence layer that already spans API gateways, identity systems and third-party integrations, that’s a five-minute answer instead of a week of pulling configs by hand.
Ten stories across four regions this fortnight — vendor compromises, unpatched vulnerabilities, sector-wide ransomware campaigns, a years-old possible exposure nobody could bound, an email that passed every technical check, two records-management failures, a stolen officer credential, and a rate-limit nobody set. Not one of them required malware reaching all the way to encryption, and more than half of them involved no attacker-side technical failure at all — the access itself was legitimate, authorised, or simply misdirected.
That breadth is the point. A single incident per region makes it easy to read this as a run of unlucky one-offs. Ten stories make the pattern harder to miss: the evidence a security team needs to answer “what happened” rarely lives in the system that failed. It lives in the vendor’s access log, the patch timeline, the authorisation trail, the request-rate counter — scattered across sources that don’t talk to each other unless something is deliberately built to correlate them.
That correlation is exactly what AskSnare is built to make askable. Every bolded question in this week’s Logging Lessons — which systems are still exposed, who authorised a release, which APIs have no rate limiting — is a natural-language query against evidence that Snare Agent, Central and Reflector have already collected, normalised and retained. AskSnare doesn’t replace an analyst’s judgement or act on its own; it shortens the distance between asking the right question and getting a retained-data answer, which is the gap every story above fell into.
THREAT SPOTLIGHT: The Investigation Gap