Ransomware Recovery & Zero-Trust Rebuild for London Law Firm

At 11:47 PM on a Friday, the IT manager of a 70-user central London law firm received an automated alert: file shares on the primary document management server were returning access-denied errors. Within minutes, the alert escalated — the firm's practice management system (Lexis Visualfiles) had gone offline, and the backup server itself was returning the same errors. By midnight, the IT manager called our emergency incident response line.

When our incident response engineer connected via a secure remote session at 12:15 AM, the situation was already critical. The ransomware — later identified as a LockBit 3.0 variant — had encrypted the firm's three file servers, the practice management database server, and the primary domain controller. The attackers had gained initial access through a compromised VPN account belonging to a former employee whose account had been disabled in Active Directory but not removed from the VPN gateway's local authentication database — a six-month-old oversight that created a persistent backdoor.

The ransom note demanded £850,000 in Bitcoin, with a threat to publish the firm's client matter files — including sensitive conveyancing completions, litigation strategy documents, and client financial records — on a leak site within 72 hours. For a law firm regulated by the Solicitors Regulation Authority, the data exposure threat was arguably worse than the encryption. The firm's managing partner was on the phone within the hour, and we were given a single directive: recover everything, secure the perimeter, and ensure this never happens again.

Our first priority was containment — preventing the ransomware from spreading to any remaining systems and preserving forensic evidence. We physically disconnected the firm's secondary domain controller (which had not yet been encrypted due to a network segmentation quirk) and the Mimecast email gateway appliance. We also isolated the Microsoft 365 tenant by disabling all on-premises synchronisation and forcing password resets for every account via Entra ID.

The critical question was whether the firm's backups had survived. The ransomware had targeted the backup server — a common attacker tactic — but the firm had a secondary backup repository that we had configured six months earlier as part of a 3-2-1 backup strategy: three copies of data, on two different media types, with one copy off-site. The off-site copy was an immutable Azure Backup vault with soft-delete and ransomware protection enabled, meaning backups could not be deleted or modified even by an attacker with administrative credentials. This was the lifeline.

We verified the integrity of the Azure Backup vault — the most recent successful backup was from 8 hours before the attack, meaning the firm would lose less than a day of work. We then began forensic preservation: capturing memory images from the encrypted servers before wiping them, exporting VPN gateway logs, and preserving the ransom note and any attacker artefacts for potential law enforcement referral. This evidence would later prove critical in understanding the attack chain and closing every vulnerability the attackers had exploited.

Recovery began at 4:00 AM on Saturday. We provisioned a clean recovery environment in Azure — a virtual network with a jump host, a new domain controller, and staging servers for file recovery. We chose to recover into Azure rather than rebuilding on-premises because it gave us a clean, isolated environment free from any residual attacker presence, and because we could scale compute resources up during recovery and down afterward to minimise cost.

The recovery process was methodical. First, we restored the Active Directory domain from a system state backup, bringing up a fresh domain controller in Azure and verifying that no attacker-created accounts or backdoors existed in the restored directory. We found two: a hidden admin account created three weeks before the attack and a Kerberos service account with unconstrained delegation — both were removed immediately.

Next, we restored the file servers from the Azure Backup vault. The firm's document management system stored matter files in a structured hierarchy on the file servers, and we recovered the entire 4.2 TB file set over 14 hours, verifying file integrity against backup checksums. The practice management database was recovered separately — a 180 GB SQL Server database that was restored to a point in time 8 hours before the attack, with transaction log replay bringing it to within minutes of the encryption event.

By Sunday at 6:00 PM — less than 42 hours after the initial alert — all critical systems were restored and operational in the Azure recovery environment. Lawyers were able to access their matter files and practice management system via Azure Virtual Desktop, with multi-factor authentication enforced on every connection. The firm was operational for Monday morning, albeit working from the cloud recovery environment while we designed the permanent on-premises rebuild.

With systems recovered and the firm operational, we conducted a full forensic investigation to understand exactly how the attackers had entered, what they had accessed, and what needed to be fixed to prevent a recurrence. This investigation was essential not only for security remediation but also because the SRA and the firm's cyber insurance provider both required a detailed incident report.

The attack chain, reconstructed from VPN logs, domain controller event logs, and Mimecast email logs, told a clear story. The initial access vector was the compromised VPN account of a former employee who had left the firm six months earlier. The account had been disabled in Active Directory but the VPN gateway — a legacy Cisco ASA appliance managed separately from AD — still had the account in its local user database with the original password. The attacker had been brute-forcing VPN credentials and found this account, which still had a weak password set when the employee was onboarded two years ago.

Once inside the network, the attacker spent 18 days performing reconnaissance — mapping the network, identifying domain admin credentials by dumping LSASS memory on a server they'd compromised via a missing patch (CVE-2023-23397, a Microsoft Outlook privilege escalation vulnerability that had been patched three months earlier but not deployed to all servers), and identifying the backup infrastructure. The attacker then deployed the ransomware via a Group Policy Object they created using stolen domain admin credentials, ensuring it executed simultaneously across all target servers.

The investigation revealed that the attacker had accessed approximately 12,000 client matter files during the reconnaissance phase. Under GDPR and SRA rules, this constituted a personal data breach requiring notification to the Information Commissioner's Office within 72 hours and notification to affected clients. We prepared the breach notification documentation and worked with the firm's compliance partner to manage the regulatory reporting process.

The firm's managing partner was unequivocal: the rebuilt environment would not simply restore the old architecture with patches. They wanted a fundamentally different security posture — one designed to assume breach and limit the blast radius of any future compromise. We designed a zero-trust architecture built on Microsoft 365, Azure, and Microsoft Defender for Endpoint, with the following principles: never trust, always verify; least-privilege access by default; assume the network is hostile; and verify explicitly on every access request.

Identity became the new perimeter. We deployed Entra ID with Passwordless authentication (FIDO2 security keys for all partners and IT staff, Microsoft Authenticator push with number matching for all other users), conditional access policies that evaluated device compliance, location, and sign-in risk on every authentication, and Privileged Identity Management (PIM) for all administrative roles — meaning admin access was time-bound, approval-gated, and fully audited. No account had standing admin access; IT staff activated admin roles on demand, and every activation was logged and reviewed.

Device management moved entirely to Microsoft Intune with conditional access enforcement. No device could access firm resources unless it was enrolled, compliant with security baselines (disk encryption, patch level, anti-malware), and registered as a trusted device. We deployed Microsoft Defender for Endpoint as the primary EDR, replacing the firm's legacy Symantec installation, and configured automated investigation and remediation so that detected threats were isolated and remediated without manual intervention.

Network segmentation was redesigned with micro-segmentation in Azure. The practice management database was placed in a separate subnet with a network security group allowing traffic only from the application server on specific ports. File servers were moved behind Azure Private Link, accessible only from within the virtual network. The VPN gateway was replaced with Azure AD Application Proxy and Global Secure Access, eliminating the need for traditional VPN and removing the class of vulnerability that had enabled the initial breach.

The backup strategy that saved the firm — the immutable Azure Backup vault — was retained and strengthened. We implemented a multi-layer backup architecture: Azure Backup for VM-level protection with immutable vault and soft-delete for 14 days, Microsoft 365 backup via a third-party SaaS provider (the firm had previously assumed Microsoft 365 data was automatically backed up — it was not), and a secondary immutable storage account with a write-once-read-many (WORM) policy enforced at the storage account level, meaning even an attacker with full Azure admin credentials could not delete or modify the backups.

We also implemented automated backup testing. Every Sunday, a random backup was selected, mounted in an isolated recovery environment, and verified for integrity — file counts, database consistency checks, and boot tests for critical VMs. The results were logged and alerted on, ensuring that the firm would never face a situation where backups existed but were corrupt or unrestorable. This testing had already been in place for the Azure Backup vault, which is why recovery was successful — but we extended it to all backup targets.

Finally, we documented a formal incident response runbook specific to ransomware, with step-by-step procedures for containment, recovery, and communication. The runbook was tested in a tabletop exercise with the firm's partners and IT team three months after the rebuild, simulating a different ransomware variant and a different initial access vector. The exercise identified two gaps — a delay in notifying the cyber insurer and a missing contact for the ICO out-of-hours line — which were remediated immediately.

The firm returned to full normal operations within 10 days of the attack, with zero permanent data loss and zero client departures. The SRA breach notification was filed within 72 hours, affected clients were notified with a clear communication plan, and the cyber insurance claim covered £340,000 of incident response costs including our emergency recovery, forensic investigation, and the zero-trust rebuild. The firm's professional indemnity insurer confirmed that the rapid recovery and transparent communication did not affect the firm's coverage or premiums.

The attack became a catalyst for transformation. The zero-trust architecture we implemented was fundamentally more secure, more resilient, and more flexible than the environment it replaced. Lawyers could now work securely from any location — court, home, client sites — without VPN, and the firm's IT costs actually decreased by 22% in the first year due to the elimination of on-premises server hardware and the consolidation of security tooling onto the Microsoft platform.

The most important lesson — and the one the firm now shares with every peer who asks — is that the backup strategy saved them. Not the firewall, not the anti-malware, not the MFA. Those controls reduce the probability of an attack succeeding, but they do not guarantee it. The immutable, tested, off-site backup was the control that guaranteed recovery. Every other control is probabilistic; backup is deterministic. The firm now treats backup testing with the same rigour as financial audit — because it is the one control that, when everything else fails, determines whether the business survives.