Ransomware at 08:05 on a Monday

Rank by 'what stops spread and preserves options'.

1. Declare and staff the incident. Name an incident commander, open a timeline, start a single evidence log with UTC timestamps.
2. Contain at the network layer. Disable the shared admin01 account, isolate affected segments, block known C2 at egress and proxy, disable the backup service account, and physically disconnect the NAS and take the tapes offline. Host quarantine alone will not stop domain-wide spread.
3. Preserve before rebuilding. Capture memory from one encrypted server and the rebooted domain controller, export EDR telemetry and the ransom note with hash. This takes under an hour and is unrecoverable later.
4. Scope persistence. Hunt for scheduled tasks, new or modified GPOs, newly created domain accounts, service creation events, and remote-execution artefacts. Assume the attacker has domain admin until proven otherwise.
5. Reset credentials in tiers. krbtgt twice with an interval, then privileged accounts, then standard users. Do this before any restore.
6. Notify per policy and pull in legal, comms, and cyber insurance.

Not yet: rebuild everything (the CEO), pay (the CFO), and restore from the NAS. Rebuilding before persistence removal and krbtgt reset just re-infects the estate.

Treat the NAS as compromised by default and validate the tapes as untrusted.

Reasoning: the NAS is domain-joined and uses the same privileged service account as production. An operator with domain admin almost certainly had access to it, which means both the backups and the backup catalogue may be tampered with. The tapes are a different story only because they are physically offline, and only if the offline period began before the intruder arrived.

Validation steps:

• Restore a sample to an isolated network and scan it with current signatures; look for ransomware binaries, stray executables in file shares, and staging folders.
• Review NAS access logs for the intrusion window: unusual service-account logons, mass reads, or deletion of shadow copies and backup jobs.
• Check whether backup job schedules, retention settings, or the backup service account were modified.
• Confirm the tape rotation really is offline; a tape left in a library overnight is not an offline copy.

The 400 GB claim means exfiltration is likely, so restore is a recovery milestone, not the end of the incident. Restore in priority order from verified clean media, with new credentials, only after persistence is removed and segmentation is in place.

Provide facts and constraints, not a verdict.

Payment is a business, legal, and sanctions question. The technical contribution is an honest assessment:

• Do you have a decryptor sample or test decryption on a low-value file? Groups frequently ship broken decryptors, and paying for a tool that fails leaves you paying twice.
• Are clean backups verified? If yes, payment buys very little.
• What is the actual data exposure behind the 400 GB claim? If the group runs a re-extortion play, paying to stop a leak buys a short window, not silence.
• Is the group sanctioned? Paying a sanctioned entity is a legal exposure independent of the incident.

On the statement: scope is unknown at 08:05 and the attacker is still in the environment. Commit only to a holding statement with a date, the fact of the incident, that customers are not being asked to act yet, and when you will next update. Do not name the group, do not state a cause, and do not estimate impact. Preserve the ransom note and any contact channel for law enforcement before anyone replies to it.