02:14 on a Saturday

Sequence, in order, with the reason for each:

1. Isolate the host at the network layer, not by shutdown. Pull the switch port / apply the EDR network containment so the machine stays running but cannot reach anything. Isolation stops encryption of network targets (the other shares and, critically, the NAS) within seconds. Powering off is worse on three counts: it destroys volatile memory - running processes, network connections, and often the encryption key or its seed, which is exactly what recovery may need - it may leave files in a half-written state and lose the opportunity to see what the malware was about to touch, and it doesn't stop anything that already has credentials and is running elsewhere.
2. The counter-argument: if the payload is encrypting local disk, isolation doesn't stop that, and shutdown would. The correct answer here is that the margin is small and the evidence loss is large; isolate, and if encryption on local volumes continues and you have no other lever, then shut down - but say which side of that trade-off you took and why.
3. Simultaneously kill the blast radius: disable the backup service account, and check whether the NAS shows the same process or unexpected file changes. Do this before anything else time-consuming - it is the one action that prevents the incident becoming unrecoverable.
4. Escalate. Two analysts is a detection team, not an incident team. Page the incident commander and the backup owner; open the bridge and a timeline document with timestamps in UTC.
5. Protect the 04:00 batch by disabling or holding the scheduling service account, and tell the warehouse operations lead what is about to stop working.
6. Preserve before you remediate: memory capture if the tooling is available, EDR telemetry export, and a snapshot of the file server. Do these while containing, not after.

What not to do in the first hour: reimage FS-03, delete the encrypted files, or run a 'cleaner' tool. Each destroys the ability to recover data or determine initial access.

The NAS is the priority because it is the recovery path, and it is currently within reach of the attacker. Domain-joined storage with the backup service account's credentials cached on the compromised host is the exact configuration in which ransomware encrypts the backups first and the production data second. The catalogue on FS-03 is the map the attacker needs, and the credentials are on the machine they already control. If the NAS is encrypted, this stops being a restore and becomes a rebuild of 2 TB of business data - and 40% encrypted shares becomes 100%.

Actions, in this order:

1. Verify what the NAS actually holds. Is last night's 01:40 job complete and unmodified? Compare file counts, sizes, and an integrity check against the job report; check the NAS audit/access logs for the backup service account between 23:00 and 02:14.
2. Cut the link. Disable the backup service account, remove its cached credentials from FS-03 and any other host, and block FS-03-to-NAS traffic at the firewall. Do not delete the account until you have checked what else uses it.
3. Protect the good copy. If 01:40 is clean, mark the backup set immutable / move it to media the domain cannot write to, or take a one-off copy to a system the attacker has no path to. Only then is the restore source safe.
4. Check the tape or offsite tier, if one exists, and whether it was written before the compromise. Anything written after the attacker gained access is suspect.
5. Test the restore now, in parallel with the investigation, into isolated infrastructure. Eleven months without a test means the restore is unproven exactly when you need it, and 'we have backups' is a claim, not a capability.

The reasoning to make explicit: availability of a clean backup determines the entire response strategy - restore in place, restore to new hosts, or rebuild - and it determines whether this is a bad weekend or a business-ending event. Nothing else in the first hours has that leverage.

Decide on evidence, not on speed - but decide by a deadline. State the criteria first, then the call.

Criteria:

• Is the initial access vector identified and closed? If it isn't, restoring in place rebuilds the target and invites the second wave, which is extremely common - attackers leave a foothold and return after the restore. Without a credible answer on the vector (credential theft, exposed service, phishing, supply chain), in-place restore is not an option.
• Is the clean backup provably clean and provably restorable? Tested, integrity-checked, and outside the attacker's reach.
• Is the host itself trustworthy? A compromised file server with a live foothold should not be put back into service unchanged.

The call, on the stated facts: the backup from 01:40 predates the 02:14 encryption and the NAS appears intact, but the initial access vector is not yet known and the same credentials are still in play. So: restore to clean, rebuilt infrastructure from the 01:40 set, with the old FS-03 held as evidence, and only return it to a domain-scoped network once the vector is closed and the restored data is scanned. Restore is faster and preserves 60% of the shares that are unaffected - do not overwrite those, verify them in place instead.

What I will not do:

• Reconnect FS-03 to production to 'save time' after the restore.
• Rotate nothing. Assume all credentials that touched FS-03 are burned - service accounts, cached domain credentials, and any admin account used on the host - and rotate them as part of the recovery, not after.
• Pay the ransom on the assumption the keys work; recovery decisions should not depend on a criminal's honesty when a tested backup exists. (If no clean backup exists, that becomes a genuine business decision for executives - present it with the recovery-time estimate, not as security's preference.)
• Declare closure at restore. The incident ends when the vector is understood, the timeline is written, and the notification decision is documented.

Also at 05:30: the regulatory clock may already be running. Get the legal/privacy lead into the bridge now - the determination of whether this is notifiable depends on data classification of the affected shares, which the business, not the SOC, owns.