| Region | Organisation | Undetected for | How it surfaced |
| Australia | Napoleon Perdis, via supplier Retail Express | About 7 months | Supplier reported an attack |
| Japan | Green Monster (FX Navi app) | Almost 6 months | Investigating a different intrusion |
| South Korea | Coupang | About 10 months | Breach report filed 20 Nov 2025; regulator investigation |
| United States | ETS, for the California Department of Education | About 4 months | Unauthorised SFTP activity identified |
| United States | MicroCode, an IT vendor to CommonSpirit Health | About 85 days | Ransomware |
| United Kingdom | South Staffordshire Water | About 20 months | IT performance problems, then a ransom note |
The cosmetics brand told customers on 17 October 2026 that an unauthorised party had accessed customer records held by Retail Express, the third party that stored them, between November 2025 and June 2026. Napoleon Perdis learned of the attack in June, and Retail Express confirmed the access window in August.
About 339,055 customer records were affected, including names, dates of birth, contact details and purchase histories.[1]
The lesson: the intrusion ran for seven months in a system the brand didn’t operate. Its evidence, and the timeline, belonged to the supplier.
On 17 October 2026, Green Monster detected unauthorised access to FX Navi, its demo FX trading app. Investigating that access, it found something else: a different party, using a different IP address, appears to have continuously pulled user data through a function of the app’s API between 27 and 30 April 2026.
About 6.19 million records, including email addresses, may have been obtained.[2]
The lesson: today’s incident can expose yesterday’s compromise. The October investigation only reached April because API, authentication and application evidence from April still existed.
South Korea’s Personal Information Protection Commission found that a former employee used an authentication signing key, taken before leaving at the end of 2024, to access customer accounts from January to October 2025. Coupang filed its breach report on 20 November 2025. The data of 33,222,472 members was involved.
The evidence problem made the outcome worse. After regulators ordered access logs preserved, Coupang manually deleted about six months of web access logs, and its routine six-month auto-deletion kept running. About 13% of the logs covering the attack period were lost, making it impossible to identify every victim. In June 2026 the PIPC imposed a record 624.7 billion won (about US$409 million) fine and referred Coupang for prosecution over the destruction of evidence.[3]
ETS, a testing contractor to the California Department of Education, identified unauthorised activity on an SFTP site on 25 September 2026. An unauthorised party had used a compromised login credential to copy files containing student information at various times between 22 May and 18 September 2026.
The data covers students enrolled in California public schools over the previous three school years, including identifiers, demographics, disability status and assessment results.[4]
The lesson: a valid credential on a file-transfer system looks like routine business. Proving what was copied, and when, depends on authentication and transfer logs from months earlier.
MicroCode, an IT vendor hosting a CommonSpirit Health database used to track medical malpractice insurance, suffered a ransomware event on 14 April 2026. Forensic investigation found unauthorised access to the server had begun on 19 January 2026. The breach was reported to the Washington Attorney General on 30 July 2026.[5]
The lesson: ransomware is often the event that reveals the intrusion, not the one that started it. Initial access and persistence evidence was nearly three months old by the time responders needed it.
In May 2026 the UK Information Commissioner’s Office fined South Staffordshire Plc and South Staffordshire Water Plc £963,900 over an earlier compromise. Malware installed through a phishing email remained in their systems for 20 months. The attacker gained domain administrator privileges in May 2022, more than 4.1TB of data was published on the dark web, and 633,887 people were affected.
The breach was found only when IT performance problems prompted an investigation in July 2022. The ICO found that only 5% of the IT environment was being monitored, and that some devices ran unsupported software including Windows Server 2003.[6]
The lesson: the first sign isn’t always a security alert. When it’s a performance problem, the investigation depends on whatever evidence was being collected and survived.
Security teams invest heavily in detection speed. They should. But detection architecture and evidence architecture solve different problems.
| Detection asks | Evidence asks |
| Is something happening now? | What happened before we knew to look? |
The longer the gap between compromise and discovery, the more the second question decides the outcome. For an average incident, identified 183 days after initial access, the investigation may need:
| Evidence | Typical sources |
| Authentication history | Windows 4624, 4625, 4648, 4768, 4769; identity provider sign-ins, including non-interactive and service principal sign-ins |
| Privilege and directory changes | Windows 4672, 4720, 4728, 4732; directory and cloud role changes |
| Process, command and PowerShell activity | Windows 4688 with command line; PowerShell script block logging (4104) |
| Persistence | Services (7045, 4697), scheduled tasks (4698), registry changes |
| DNS and network activity | DNS Analytic and Debug logs, firewall, proxy and VPN events |
| Cloud, SaaS and API activity | Control-plane operations, SaaS audit events, API calls, token and service-account use |
| Logging tampering | Audit policy changes (4719), log cleared (1102), agent or collector gaps |
| Events filtered out of the SIEM | Verbose telemetry retained outside the analytics platform |
And those records must still be available, attributable, timestamped, searchable and trustworthy.
Keeping logs somewhere is not enough. An archive that takes days to restore is an operational problem. A dataset that can’t be searched without rebuilding infrastructure is another. Logs that can’t be tied to a reliable source, identity and timestamp weaken every conclusion drawn from them. And evidence kept only inside the current SIEM becomes a dependency the day the organisation changes platform.
A useful security evidence layer supports three states:
| State | What it needs |
| Now | Events required for current monitoring and detection |
| Then | Historical evidence, searchable and replayable when an investigation reaches backwards |
| Next | Evidence that stays available when analytics platforms, SIEMs or operating models change |
That distinction is where logging architecture becomes more than log forwarding.
THE SNARE PERSPECTIVE – Snare Insider Issue 15