When Decryption Fails Responding to File-Locking Attacks

Ransomware that locks business files without leaving a path to recovery has reshaped how Australian security teams think about continuity planning. Unlike the early strains that security vendors could routinely crack with publicly available decryptors, modern campaigns often rely on proprietary cryptography, extortion-only models, or pure data theft, leaving victims with no tool to reverse the damage.

This playbook focuses on situations where no working decryption utility exists, whether because the strain is new, the threat actor withholds the key, or the attack has destroyed any chance of restoration through backup corruption. It applies Australian regulatory obligations, ACSC guidance, and the operational realities of businesses running across Sydney, Melbourne, Brisbane, Perth, and regional centres.

The Uncomfortable Reality of Permanent File Lockout

For many years, the standard ransomware response assumed that a working decryptor would surface eventually. That assumption no longer holds. Today's groups increasingly combine strong symmetric and asymmetric encryption with operational discipline, and even when law enforcement or researchers obtain keys, those keys may apply only to a subset of victims or to early variants that have long since been superseded.

Australian organisations hit by file-locking malware have absorbed this lesson directly. The Nine Entertainment disruption in 2021, the Toll Holdings incident in 2020, and the wave of mid-market attacks on legal and accounting firms across Brisbane and Perth all saw restoration come from backups, rebuilt systems, or supplier channels, not from a recovered key.

The pattern has been particularly stark for industrial operators, where groups now target hardware vendors serving critical infrastructure. Reporting on industrial control vendor attacks confirms that file-encrypting payloads now reach the factory floor as readily as the finance team.

Why Decryption Tools Do Not Always Exist

A handful of well-publicised decryptors, including some for older Dharma builds, only worked because police operations seized private infrastructure or because analysts reverse-engineered the underlying encryption. Many modern strains, however, are intentionally designed so that the operator is the only party holding the working decryption material. Once attackers know their encryption has been broken, they rotate to new family, new key generation, and new tradecraft.

Signs that a working decryptor is unlikely to appear

In these cases, the question stops being "when will the decryptor be available?" and becomes "how do we restore service without it?"

The First 24 Hours in an Australian Context

The first day of an incident determines the trajectory of the recovery. Australian organisations subject to the Security of Critical Infrastructure Act or APRA CPS 234 should treat isolation as a regulated activity, not just an IT task, and should involve the executive sponsor before the clock runs past the point where legal privilege becomes harder to protect.

Practical steps during the first day revolve around three pillars. Network segmentation is applied aggressively, with manufacturing zones, point-of-sale environments, and finance systems walled off even if it means halting production lines in a Melbourne factory or a Brisbane distribution centre. Identity hardening follows, with every privileged credential rotated, every remote access tool re-authenticated, and every third-party VPN reviewed, because the same initial access vector that delivered the payload often remains open. External communication is the third pillar. Engaging the Australian Cyber Security Centre early unlocks technical advice, threat intelligence, and, in serious cases, on-site assistance, which helps frame any subsequent OAIC assessment with credible evidence rather than speculation.

Under the Notifiable Data Breaches scheme, an assessment of whether personal information has been accessed or exfiltrated must occur within thirty days, and early ACSC engagement materially improves the quality of that assessment.

Eradication, Forensic Capture, and Safe Rebuild

Removing the attacker from the environment is rarely as simple as re-imaging a single server. Threat actors commonly persist through scheduled tasks, modified Group Policy preferences, hijacked remote monitoring agents, and unmanaged cloud workloads that the IT team did not know existed. A clean rebuild starts with a thorough inventory of every asset touched during the incident window, including remote laptops used by staff travelling between Sydney headquarters and Perth branch sites.

Forensic preservation matters for two reasons. Regulators and insurers expect the chain of evidence to be defensible, particularly when the OAIC investigates or when APRA-regulated entities must show how operational risk was identified. Threat intelligence benefits from preserved artefacts as well, confirming the specific malware family, the command-and-control infrastructure, and the lateral movement tradecraft, which together confirm that the build will not simply reintroduce the same foothold.

Once the scope is mapped, eradication should follow a clean-room approach: rebuild from known-good gold images, rehydrate identity providers from trusted seeds, and validate network paths before reconnecting systems. This is where many Australian mid-market operations stall, because they lack a tested offline image library, and so they attempt a partial rebuild that leaves residual access intact.

Restoration Through Clean Sources

Restoration is where the absence of a decryptor becomes most acute. Without a working key, every encrypted file or memory unit must be replaced from backup, golden image, or supplier channel. This makes the quality of pre-incident backups the single most important variable in determining how quickly the business resumes trading.

Backups must be immutable, offline, and regularly tested. The Australian Signals Directorate's Essential Eight maturity model treats backup restoration testing as a core control precisely because an untested backup may be just as compromised as the live environment, particularly if the threat actor had weeks inside the network before encryption began.

Restoration sequencing also matters. Customer-facing systems in retail or hospitality often need to come back before back-office finance, while in a hospital the clinical triage and policy comes first. Establishing that order before the incident, with documented runbooks that reflect the actual business priorities of a Sydney clinic or a Hobart freight operator, prevents restoration arguments during a crisis.

Regulatory Disclosure and Reporting Obligations

Australian ransomware incidents rarely stay internal. The Privacy Act triggers notification to the OAIC and to affected individuals when personal information is involved in a way that is likely to result in serious harm. The Notifiable Data Breaches scheme provides a structured assessment framework, and an organisation that engages ACSC's ReportCyber portal within days of detection typically has a smoother regulatory interaction than one that delays reporting.

Critical infrastructure operators face additional obligations. The Security of Critical Infrastructure Act requires reporting of cyber security incidents that have a relevant impact on the asset, and sector-specific regulators may impose further expectations. Healthcare providers must also consider the My Health Records Act obligations, particularly when ransomware touches systems containing health information, and financial services entities must align with APRA CPS 234.

Financial considerations run in parallel. Cyber insurance policies in the Australian market typically require prompt notification to both the insurer and, often, to law enforcement. Paying the ransom is not prohibited, though the Department of Home Affairs discourages it, and ASIC has been clear that boards must document the decision-making process around any payment, including the financial crime and sanctions-related risks of transacting with a designated group.

Building Operational Resilience After Recovery

Closing the immediate gap is not enough. Threat actors frequently return to organisations they have already mapped, particularly when residual credentials or unmanaged devices remain available. A structured hardening programme addresses the root causes rather than the symptoms.

When no decryption tool is forthcoming, the practical options compare as follows.

Recovery approach Time to operational recovery Direct financial exposure Residual compromise risk Regulatory posture
Paying the ransom for a working decryptor Days if negotiation succeeds High, including ransom and advisory fees High, since the attacker may retain access or supply only partial keys Discouraged; requires board-level documentation and ACSC notification
Full rebuild from immutable, tested backups One to three weeks for most environments Moderate, covering overtime and infrastructure Moderate, depending on how recently the backups were taken Aligned with Essential Eight maturity three
Hybrid restoration combining golden images and selective restore One to two months for complex estates High, primarily in engineering hours Low, as rebuilds use known-good baselines Aligned with APRA CPS 234 and SOCI Act obligations
Supplier channel restoration for application or hardware Weeks to months per vendor Variable procurement and licensing cost Medium, if vendor channels share the same root cause Disclosed to the OAIC where personal data is implicated

Controls that consistently close the door in post-incident reviews

The single most valuable next step is to schedule a ransomware tabletop exercise within the next ninety days, built around your own most likely initial access vector, with the ACSC invited to participate as an observer.