Friday ransomware at a building-supplies wholesaler

Use the incident-response logic: prepare, detect/validate, contain, eradicate, recover, learn - with communication running throughout.

From 17:40, the first priority is to confirm this is a real incident, not a permissions fault. Three independent reports plus the .locked extension justify treating it as a ransomware incident immediately.

Before eradication:

1. Mobilise and escalate. Activate the incident policy, contact the incident lead and the director, and use the contact list even though it is stale. The IT manager on leave should not be the single decision-maker.
2. Contain, don't just switch off. Disconnect the file server and NAS from the network in a controlled way. Powering off the file server may preserve disk state but destroys volatile memory evidence; the better move is network isolation, disabling compromised accounts and blocking known command-and-control indicators. The 40-minute delay allowed the encryption to spread, so check other servers and endpoints.
3. Protect backups. The mapped Z: drive is the critical finding: the NAS may already be encrypted or reachable. Isolate it, check whether any offline or immutable copy exists, and do not reconnect it to the domain.
4. Preserve evidence. Record the timeline, keep the ransom note, capture logs before they roll over, and make hashed copies. The insurer will ask what happened, when and what was contained.
5. Assess business impact and invoke continuity. ERP is up, but order fulfilment may depend on shared documents. Decide manual workarounds and tell affected staff, customers and suppliers what they can expect.
6. Engage specialists and authorities as required. Do not pay under time pressure without legal, insurer and management involvement; payment is not a recovery strategy.
7. Recover from a known-clean source and only reconnect after credentials are reset and the entry path is closed.

The switch-off was understandable but shows the plan lacked a containment decision tree. That should be fixed in the post-incident review.

The biggest failure was four days of silence after the Tuesday phishing email.

The administrator opened an .html attachment and did not report it. That is not simply carelessness: the company had no evidence that reporting was expected, easy or safe. The incident policy was signed, but a signed document is not awareness. Staff may not recognise an .html attachment as suspicious, and they may fear blame.

Relevant requirements:

• A.6.8 Information security event reporting - there must be a reporting route and staff must know when and how to use it.
• A.6.3 Awareness, education and training - role-relevant training, including for administrators, on phishing and attachment handling.
• A.5.24 Planning and preparation for incident management and A.5.25 Assessment and decision on information security events - the organisation must decide quickly whether an event is an incident. Here the decision was made 40 minutes after three reports, by phone, with no criteria.
• A.8.16 Monitoring activities - nobody was watching for unusual file renaming, mass encryption or anomalous account behaviour.
• Clause 7.3 Awareness and Clause 5.1 Leadership - management must make reporting visibly acceptable.

The practical fixes are a one-click report button or a known phone number, a no-blame reporting message from the director, and a short exercise in which staff practise recognising a suspicious attachment. The administrator should not be disciplined for reporting late if the organisation never gave a route; that would suppress future reporting.

Evidence the insurer and auditor will expect:

• An incident log with timestamps: first report 17:40, decision to switch off the server, who was contacted, when systems were isolated.
• The ransom note, affected file listings or screenshots, and preserved logs.
• A containment record showing which accounts were disabled, which network segments were isolated and when.
• A recovery record: which backup was used, its date, whether it was verified, and the restore outcome.
• Communications with staff, customers, the insurer and authorities.
• A post-incident report with root cause and corrective actions.

A.5.28 Collection of evidence is the relevant control: evidence must be collected in a way that preserves its value, with a chain of custody.

Why the backup design fails availability:

The NAS was mapped as drive Z: on the same domain. That means the backup target was reachable with the same credentials as the file server. Ransomware running under a domain account can encrypt the live data and the backup, sometimes within minutes. A backup that is online, writable and domain-joined is not a last line of defence.

The 19-month gap since the last restore test is equally serious. Nobody knew whether the backup was usable, how long a restore would take or whether the ERP data was consistent. A backup is only a control if it can be restored within the business's tolerance for downtime.

Corrective design: at least one offline or immutable copy, a copy outside the domain, credentials not usable from the file server, regular restore tests with recorded results, and clear retention. A.8.13 Backup and A.5.29/A.5.30 ICT readiness and preparedness for business continuity are the relevant controls. The continuity plan also needs a cyber scenario; a fire-only plan does not tell staff how to take orders manually.