Australia
On 19 August, the Australian Signals Directorate’s ACSC issued a High Alert warning that vulnerabilities affecting the N-able N-central remote monitoring and management platform were being actively exploited within Australia. The alert named CVE-2026-18556 and CVE-2026-18577, both rated high severity at CVSS 8.2, and both authentication bypasses permitting unauthorised access through an alternate path or channel. All current versions were affected, including 2026.3.
The sequence behind that alert matters more than the CVEs themselves. N-able began investigating anomalous activity on 31 July. CVE-2026-18577 turned out to be a second exploitation path left open by an incomplete fix for CVE-2026-18556. An emergency hotfix landed on 2 August; a second, superseding hotfix followed on 6 August. CISA added the flaw to its Known Exploited Vulnerabilities catalog on 4 August with a federal remediation deadline two days later.
What the attackers did after gaining access is the part every MSSP should read twice. Following successful exploitation, they used N-central’s built-in Take Control feature to reach managed endpoints, and deployed Cloudflare Tunnel (cloudflared) to establish persistent remote access. Reported indicators included connections from Mullvad and NordVPN exit nodes, and in at least one case activity under “MSP Support”, a default username tied to legitimate Take Control sessions.
Five days later, on 24 August, the ACSC issued a second High Alert covering active exploitation of JetBrains TeamCity On-Premises. CVE-2026-63077 is an unsafe-deserialisation flaw (CWE-502) in the agent polling protocol, carrying a CVSS base score of 9.8, allowing an unauthenticated attacker with HTTP(S) access to bypass authentication and execute operating-system commands with the privileges of the TeamCity server process. All on-premises versions were affected; fixed builds are 2025.11.7 and 2026.1.3. CISA added it to KEV on 5 August, and proof-of-concept code is public.
For a managed provider, the RMM console is simultaneously the highest-value target in the estate and the primary evidence source for proving what was and was not touched across every customer tenant. Verizon’s 2026 DBIR data was accompanied by industry reporting of a 240% year-on-year rise in RMM abuse. If your remote-management audit trail lives only inside the remote-management platform, you have a single point of failure for both control and proof.
LOGGING LESSON
Neither of these intrusions required malware. In both cases the attacker operated through a legitimate product feature, using an account the platform considered valid, on infrastructure the organisation deliberately trusts.
A signature has nothing to match. What distinguishes the activity is context: which account, from which network, at what hour, targeting which endpoints, and what those endpoints then executed.
That means retaining, at minimum:
- RMM console audit, authentication with source IP and ASN, remote-session (Take Control) initiation and target host, script and scheduled-task execution, agent policy changes, and API token issuance and use.
- Endpoint process creation, Windows Security Event ID 4688 with command line enabled, or Sysmon Event ID 1, where the parent process is the RMM agent binary. This is what makes RMM-delivered execution attributable rather than merely observed.
- Process-level network telemetry, Sysmon Event ID 3, DNS query logs and proxy/firewall egress by process, to catch tunnelling clients such as cloudflared reaching out to infrastructure the host has never contacted.
- CI/CD telemetry, build-server application logs, process creation on build servers and agents (a build service spawning a command shell is the tell), service-account token issuance, artifact publication, and build-configuration changes made outside a merge.
Critically, none of this evidence should exist only inside the platform being compromised. An attacker holding administrative control of an RMM console or a build server can alter or clear its audit trail. Forwarding off-host, at the moment of the event, is the control, not retention length.
Singapore Police and GovTech disrupted two separate Singpass compromise schemes during August.
In the first, officers from Cyber Command and Clementi Division, supported by GovTech’s Singpass Trust & Safety team, arrested three people on 5–6 August. At least 23 work permit holders had reported their Singpass accounts being locked after being offered an $80 cash incentive in exchange for account access, some told the accounts would be used to buy discounted National Day Parade tickets. Over 150 Singpass accounts were ultimately used to register more than 30 LiquidPay accounts and over 1,200 phone lines.
The second is the more instructive one. Following an operation run between 21 and 25 August, police arrested two men who worked at a Singapore mobile phone shop. They allegedly exploited routine customer interactions to reach customers’ Singpass accounts, in one documented case, offering to help a customer update the mobile number linked to their Singpass while the customer was buying a SIM card, then using that access to create a LiquidPay account in the customer’s name. Investigations identified a further 171 victims and more than 160 additional fraudulently opened accounts, since frozen.
The incident reinforces something we explored in Issue 13: a legitimate identity can become the attack path. But it sharpens the point considerably.
Every authentication in these cases was valid. The account holder was physically present. The registered device was correct. Nothing in the identity provider’s authentication log looks anomalous, because nothing about the authentication was anomalous.
So the investigative question is not:
It is:
Logging lesson
The detectable signal sits in the sequence and in the aggregate, not in any single event. Specifically: authentication → change to a registered contact or recovery attribute → high-value downstream action, repeated across unrelated account holders with a shared device, network or point of service.
The enterprise version of this pattern is help-desk-assisted MFA reset followed by a privileged action. In an Entra ID environment the correlation chain runs across audit events for “User registered security info” and “Admin registered security info”, sign-in logs carrying the device identifier and authentication protocol, directory-role assignment events, and application consent grants, then the downstream application and SaaS activity that followed.
None of that correlation is possible if identity events, endpoint events, SaaS audit logs and application transaction logs are retained in different places, for different periods, under different owners.
CrowdStrike’s data points to the same shift at enterprise scale: vishing intrusions doubled in the first half of 2026, and monthly device-code phishing attempts rose fifteenfold, both techniques that end in a completely legitimate authentication event.
On 28 August, the Rhysida ransomware group posted a leak-site entry titled “Berlin, Germany”, claiming 5.79TB of data across roughly 1.44 million files, including approximately 46,500 contracts, emails, phone numbers, credential files and material described as classified. The group opened bidding at 30 bitcoin with a one-week countdown. Berlin’s Governing Mayor stated publicly that the city would not pay.
On 31 August, Berlin officials confirmed that data theft had been forensically verified, with a confirmed exfiltration window of 7–12 August inside the Senate Department for Mobility, Transport, Climate Protection and Environment, one of the departments disconnected from the Landesnetz, the state backbone network.
The operationally significant number is not 5.79TB. It is the gap. Reporting indicates suspicious data movement was first detected around 7 August, and that affected departments were not disconnected from the Landesnetz until 14 August. Berlin’s State Secretary for Digital Affairs is reported as saying data had been leaving for roughly a week before the intrusion was discovered.
There is a second gap worth noting, and it is the one that logging directly addresses. Berlin has validated exfiltration from one Senate portfolio during a five-day window. It has not validated Rhysida’s headline 5.79TB figure, nor the claim regarding personal data belonging to 12,076 individuals.
When an organisation cannot independently reconstruct what left the environment, the attacker’s claim becomes the working assumption, for the media, for the regulator, and for every affected citizen.
The incident reinforces the evolution we covered in Issue 13. Ransomware is not an encryption investigation. It is an investigation into:
THE LOGGING LESSON
The notification clock starts on awareness, not on evidence. Under GDPR Article 33 that is 72 hours to the supervisory authority; under NIS2 Article 23 it is a 24-hour early warning followed by a 72-hour notification and a one-month final report.
Egress evidence is what converts “we cannot rule it out” into a bounded, defensible statement within those windows. That means retaining, at a minimum:
- Proxy and firewall egress records with destination and byte volume, retained long enough to reconstruct a multi-week transfer.
- Network flow data (NetFlow/IPFIX) covering north-south and east-west movement.
- File-share access with the access mask, Windows Event ID 5145 rather than 5140 alone, since 5140 tells you a share was reached and 5145 tells you what was done to what.
- Archive-creation and staging activity on file servers, process creation showing compression utilities operating over shares.
- DLP alerts and cloud-storage upload and external-sharing audit events.
Detection told Berlin something was moving. Only evidence can tell anyone what actually left.
On 2–3 September, Thomson Reuters’ West Publishing unit disclosed a cybersecurity incident affecting C-Track, its court case-management platform. The disclosure states that an unauthorised party obtained certain C-Track files in March 2026, and that the activity was discovered on 30 June 2026. The incident affected court systems across 11 US states, the US Virgin Islands and Ontario, Canada. The statement issued by the chief justices of the three Ontario courts described unauthorised activity in one of Thomson Reuters’ cloud environments, and reporting indicates backup data files were among the material accessed.
Do the arithmetic. Access in March. Discovery on 30 June, roughly three to four months later. Public disclosure a further two months after that.
That is not an outlier. IBM’s 2026 Cost of a Data Breach Report puts the mean time to identify and contain a breach at 247 days, reversing five consecutive years of improvement, and attributes 63% of total breach cost to detection and escalation plus lost business.
THE LOGGING LESSON
On 30 June, the only question that mattered was: what happened in March?
If March’s authentication, data-access and egress records had already aged out of retention, or were technically retained but sitting in a tier that could not be searched inside a working incident timeline, the investigation starts blind, and the scoping statement to regulators and affected parties gets written around an absence.
Retention therefore cannot be designed around yesterday’s detection workload. It has to be designed around tomorrow’s investigation, and around the reality that the investigation will begin months after the evidence was generated.
There is a third-party dimension too. Verizon puts third-party involvement in 48% of breaches, up 60% year on year. Where a platform is operated by someone else, your evidence about it is their evidence, unless you have been pulling the audit feeds they expose via API into your own retention, on your own schedule.
Snare Insider Issue #14 Sept 2026