Twelve Calls in Fifteen Minutes

Powering off everything destroys the memory image that often contains the encryption key and the operator's tooling, may leave virtual machines in an inconsistent state that is unrecoverable, and takes down the very systems you need for recovery. It is the wrong first move - with one narrow exception noted below.

Order:

1. Protect the backups before anything else. Disable the shared service account, block SMB between servers at the switch, and physically or logically separate the backup server and any offline copies. Recovery capability is the one thing you cannot rebuild after the fact.
2. Contain by isolation, not shutdown. Disable the switch port or use EDR network containment on the receptionist's PC and on the nine servers showing SMB fan-out. Hosts stay powered for evidence.
3. Preserve volatile evidence on the key hosts: memory capture, and photograph or export the ransom note with timestamps. Record who touched what and when.
4. Cut the command-and-control path at the edge and block the Tor-related indicators.
5. Scope before eradicating - the 02:00 backup completed, so the earliest encryption may be much later; check log retention for reconnaissance days earlier.

Exception: if a host is actively encrypting and cannot be isolated within minutes, pulling its power is acceptable - accept the evidence loss knowingly rather than silently.

Treat the backup as untrusted until verified. A completed job is not a restorable backup.

Checks:

• Was the backup server itself compromised? It is domain-joined and uses the same service account as the estate, so assume the credential was available to the attacker. Look for failed and successful logons from unexpected hosts, new jobs, deleted or shortened retention, and disabled immutability or MFA settings.
• Integrity of the backup data: are the files on the repository intact, or does the catalogue show encryption of backup files? Check the repository timestamps around 02:00 onward.
• Dwell time: if the attacker was present before 02:00, the backup may contain their tooling even though it is unencrypted. That is recoverable - you rebuild and re-scan - but it changes the restore plan.
• Restore test: restore a random file, then a domain controller, to isolated infrastructure. Never restore over production.
• Credentials: rotate every credential the backup server can see before restoring, or you will re-infect an otherwise clean environment.
• Offline or immutable copy: does one exist, and how old is it? That determines the data-loss window you present to the business.

Only after these produce a defensible answer do you commit to a restore date.

Order, with content discipline at each step:

1. Internal response lead and the manager, immediately. Confirm roles: who talks to the insurer, who talks to forensics, who handles staff. One voice.
2. Staff, within the hour, out of band. Email may be compromised, so use an SMS or phone tree. Message content: stop using company systems, do not open documents, do not pay anything, report to a named person, and wait for an update time. Give the update time and keep it.
3. Insurance carrier and forensics vendor, well inside the 72-hour clock - do not use the full 72 hours to decide.
4. Legal counsel, engaged early so forensic work can be directed under privilege where applicable.
5. Regulator, customers and law enforcement only after counsel advises. Contractual notification clocks may run independently of the regulatory one.

What must not be said yet: any guess at scope or whether personal data was taken; anything about paying; any public statement or all-staff explanation of how the entry occurred; and no blame directed at the receptionist. Speculation in the company chat will be screenshotted and will outlive your forensic report. Also avoid confirming the ransom demand to anyone outside the response group.