#NSBCS.140 - What Policing Taught Me About Ransomware Investigations
Our Cyber Director, James Vickers, shares his perspective on how his policing background taught him that the most valuable habits in incident response are not the technical ones.
Before anyone touched the computers, we photographed and documented them.
We had a person of interest who knew computers well enough that deletion and obfuscation were realistic concerns rather than theoretical ones. Nothing could be assumed to still be there an hour later, so the machines and the external storage devices connected to them were photographed and documented in situ, exactly as we found them, before a single cable was moved. One of those machines had encrypted volumes open at the time we arrived.
Nothing about that scene had anything to do with ransomware. But almost everything I did in that room, I have done again since, in environments where the compromised assets are physical or virtual, spread across a corporate network, and belong to a client losing money by the hour.
The technical knowledge transfers in the obvious way. A disk is a disk, and the artefacts do not care who is paying for the analysis. But it is not the part I lean on hardest. What transfers, and what separates a useful incident investigation from an inconclusive one, are three habits: how you approach a scene, what you protect first, and who you talk to.
A ransomware incident is a crime scene. It is bigger than most, spread across a network rather than a room, and usually damaged deliberately before you arrive. The instincts still apply.
The case
It began with a call to the IT helpdesk. A staff member could not remotely log in. Not a note on a screen, not a document that would not open because it had a random file extension, just a routine-sounding access problem reported by someone who had no idea they were reporting an incident.
By the time we were engaged, our client and their IT team had already settled on an incident start date. Two days earlier, they had seen an account log into a server it would not normally touch. That was the incident, as far as anyone could see.
The timeline said six days.
Not six days of the same activity they had already found. The account they were watching was one of several, the server one of many, and the thing that mattered most had already happened somewhere they were not looking.
Initial access came through a brute-force attack against an internet-exposed and unsecured remote access service. There was no multi-factor authentication and the password was weak (unfortunately, in our line of business, this is a common story).
That left four days nobody had accounted for. Inside them: a software deployment tool installed and used, plaintext credentials accessed, credential dumping and harvesting, lateral movement, network scanning, several days of data exfiltration, anti-virus disabled, a remote monitoring and management (RMM) tool installed for persistence, and the backups destroyed.
Encryption is not the start of a ransomware incident. It is the last thing that happens, once everything worth taking has been taken and everything that would have helped you recover is gone. By the time that helpdesk phone rang, the incident was already over.
1. Assume the scene has been interfered with
The reason for photographing that room was not procedural box-ticking. Electronic evidence is not all-encompassing. If a system does not record information about itself or what it monitors, there is an evidence gap. In that room, the gap was what had been physically connected to what, and operating system artefacts are incomplete on this at the best of times, worse still when someone technically capable has had time and motive to clean up. So you capture the state of things before it changes, including the things that do not look like evidence yet, because you do not yet know which questions you will need to answer.
You approach the scene assuming it has been interfered with, and you work outward from whatever the interference did not reach.
In the ransomware case, the interference was total. Servers and endpoints were fully encrypted at the disk level, as comprehensively destroyed as a scene can reasonably be.
We still established how they got in, because data recovery methods returned evidence that survived the encryption. The rest of the timeline was assembled from what the environment had recorded about itself along the way: system and user activity records, files and folders the attacker had created to look like legitimate system components, tooling of a kind we see used again and again, and network records supporting a finding of data theft.
No single source tells the story, and several are only meaningful once the others sit alongside them. Together they produce a timeline you can defend, and a client who thought they had a two-day problem learns they had a six-day one.
2. Know what disappears first
Those open encrypted volumes were the most fragile thing in the room. Open, readable, and one power-down away from being permanently beyond reach. Had the order of volatility not been followed, that opportunity would have vanished for good.
Order of volatility is the discipline of knowing which evidence has a clock on it, and dealing with that evidence first regardless of what is most convenient or most obviously relevant.
In the ransomware case, the firewall logs were the open encrypted volume. They were not preserved when the incident was identified, and days of relevant evidence were lost. That evidence does not come back later. It rolls off, and then it is simply gone.
Organisations tend to get this backwards: exhaustive about the systems that are easy to preserve, casual about the logs that are about to expire.
What went wrong here was not unwillingness. Roles and responsibilities were not clearly understood, the network was remote, and preservation kept losing out to other priorities despite repeated prompts about how time-critical it was. With the right material captured at the outset, the investigation would have finished considerably sooner, and the client would have had the answers they needed a great deal earlier.
3. Talk to the people in the room
Artefacts will not tell you who was authorised. This is the habit that transfers most directly and the one technical investigators are most inclined to skip.
During a ransomware response, your IT team are working in the same environment as the threat actor, frequently with the same privileged accounts, sometimes on the same servers within minutes of each other. In the logs, an administrator responding to an incident and an attacker moving laterally look much alike, and separating them by analysis alone is slow and sometimes impossible.
Testimony resolves it. A short conversation with the system administrator — "was that you, and what were you doing at that point?" — can save days of work and resources expended where they were never needed.
It works the other way too. In a website compromise involving a credit card skimmer, the logs available to us were disparate, incomplete and of little value, and the site itself had not been preserved. What made the investigation possible was that our client had screen-recorded the problem, because customers were complaining, before anyone knew it was a compromise. That recording showed the skimmer operating and mimicking a valid online transaction, and let us connect the initial compromise to the realised impact in a way static analysis never would have.
Nobody made that recording for us. It existed because someone was trying to solve a different problem, and we only knew about it because we asked.
Two clocks
The obvious difference between the two careers is what the clock is measuring.
In policing, timeliness matters because someone's life is materially affected in either direction. Cut corners and the victim may not get justice. Charge a person of interest on findings where the hypotheses have not been fully tested, and their liberty is at stake along with a reputation that may never recover.
In incident response, the clock is revenue. An organisation can lose millions a day while out of operation, and if that runs long enough it reaches whether staff can be paid. Risk-based decisions get made on partial findings because waiting for complete ones costs more than the risk of being wrong. That is why cyber and legal expertise need to sit alongside each other while those decisions are made.
It is tempting to frame these as opposites. In practice they converge. Policing sometimes has to act immediately where there are concerns for someone's safety, knowing it may compromise the prosecution. And in incident response we work with organisations responsible for parts of the public's lives, including their finances and healthcare. An incident that stops operations does not stop at the balance sheet.
The same risk and reward calculation, in a different currency.
What I would want you to take from it
The technical failures in that case are easy to list, and a recurring theme across similar investigations. No multi-factor authentication on an internet-facing remote access service. A weak password. Both worth fixing, and both fixable this week.
But the thing that cost the most was not the way in. It was that the first indication arrived six days late, and that evidence capable of explaining those six days was still being lost while the organisation worked out whose job it was to preserve it.
You will not decide that well in the middle of an incident. Decide now who preserves what, and who has the authority to direct it. The organisations that come through these events best are not the ones that avoid incidents. They are the ones that know, in the first hour, what needs capturing before it is gone.
That instinct is not something I brought with me alone. NSB Cyber brings together deep 'special situations' experience in high-pressure and crisis situations, with law enforcement and military experience a key backbone of our capability.
What we read this week
SonicWall Patches Two Actively Exploited Zero-Days in SMA 1000 Series - SonicWall has issued an urgent advisory for two zero-day vulnerabilities in its Secure Mobile Access (SMA) 1000 series appliances that are being actively exploited in the wild. CVE-2026-83548 is a pre-authentication server-side request forgery (SSRF) flaw in the Appliance Work Place interface (CVSS 10.0) that allows remote unauthenticated attackers to gain unauthorised access to sensitive functionality. CVE-2026-83549 is a post-authentication OS command injection issue in the Appliance Management Console (CVSS 7.8) that can enable remote code execution when chained. Affected models include the 6210, 7210 and 8200v. Hotfixes are available; organisations must upgrade immediately, review systems for indicators of compromise, and re-image or redeploy compromised appliances while rotating credentials.
International Operation Disrupts 23-Year-Old Sality P2P Botnet - Law enforcement agencies from the United States, Bulgaria, Hungary and Romania, working with CrowdStrike and the Shadowserver Foundation, have disrupted the long-running Sality peer-to-peer botnet. Active since 2003, Sality infected tens of thousands of machines and was used to distribute malware, including clipjacking tools that stole cryptocurrency. The operation involved a peer-to-peer sinkhole that manipulated super-peer lists to isolate bots from the operator, alongside domain seizures. Infected machines now beacon to defender-controlled infrastructure, and owners are being notified through ISPs and national CERTs.
Dropbox Accounts Compromised via Lenovo ID Authentication Flaw - Dropbox has confirmed that approximately 5,000 user accounts were accessed without authorisation between 4 and 21 August 2026 after attackers exploited a legacy integration with Lenovo ID. An issue in Lenovo’s email verification process allowed threat actors to register Lenovo IDs using victims’ email addresses and then log into linked Dropbox accounts that lacked two-factor authentication. Files were viewed or downloaded from fewer than a third of the affected accounts. Dropbox has expired the relevant sessions, severed the Lenovo ID links, and now requires a Dropbox password for any such access. Affected users should change passwords, enable multi-factor authentication, and review account activity.
NSW Health Denies MedusaLocker Ransomware Claims - MedusaLocker listed NSW Health on its leak site around 27 August, claiming to have extracted a small set of emails and sharing a limited file tree. NSW Health has stated it can find no evidence that its systems were compromised. The documents that appeared carried letterheads from various medical and dental practices (particularly North Coast and Hunter regions) rather than NSW Health itself, raising the possibility that the material originated from a third-party provider or unrelated clinics. Patient scans, Medicare numbers and personal details dating back years appear among the exposed material.
Sydney App Developer DigiGround Investigating Qilin Ransomware Claims - The Qilin ransomware group listed Sydney-based bespoke app developer DigiGround late the previous week. The company has said it is investigating the claims but has so far found no evidence of compromise. The listing adds to a series of Australian organisations named by Qilin and other groups in recent weeks. Organisations should continue to prioritise offline backups, multi-factor authentication, email security and rapid incident response readiness.