Ransomware on a File Server With Adjacent Backup Infrastructure
At 03:12 on a Tuesday, endpoint protection raises alerts on 14 workstations and one file server for a family of encrypting malware. By 03:40, roughly 300 files on a 40 TB departmental share have been renamed with a new extension, and a ransom note is present. The share is hosted on a virtual machine in the same cluster as the backup server. Backups run nightly at 23:00 to tape, and a replicated copy lands on a NAS in the same rack as the file server. The backup service account is a domain account with local administrator rights on the file server and is used interactively by two administrators for troubleshooting. There is no MFA on administrative access to the virtualization console. The security team has one analyst on call and no tested incident-response playbook. Business units are already calling the service desk because the share is unavailable.
1. Set out the priorities for the first 60 minutes and justify the sequence.
Read the worked answer
Sequence: contain identity and the virtualization layer first, then the network, then preserve evidence, then communicate.
Why that order: the fastest way for this to become an unrecoverable event is for the attacker to reach the backup server and the NAS, which sit in the same cluster and rack as the encrypted host. The backup service account has local administrator rights on the file server, so it must be presumed compromised and disabled before anything else is touched. Administrative credentials to the virtualization console are the next most dangerous capability; rotate them and enable MFA before restoring anything.
Concrete actions: disable the backup service account and the two interactive administrator accounts; snapshot the affected VM's memory and disk for evidence if the platform permits it without destroying the snapshot itself; isolate the 14 workstations and the file server at the network layer rather than shutting them down, because shutting down loses volatile evidence and does not stop the attacker's other footholds. Do not delete the ransom note or the encrypted files.
Communication: tell the service desk to state that the share is down for maintenance, with a named owner and a review time. Speculation to users creates its own incident. If the share holds regulated data, notify the privacy office within the hour rather than after recovery.
2. Leadership wants to restore from last night's backup immediately. What is your decision, and what conditions would change it?
Read the worked answer
Decision: Do not restore until three conditions are met: the backup copies are verified clean and reachable from a trusted host, the initial access vector is identified and closed, and the restore target is a rebuilt or offline-verified system.
Reasoning: restoring over a system that still holds the attacker's persistence reinstalls the same encrypted outcome on a delay. The NAS is in the same rack and reachable from the compromised host, so its contents must be treated as suspect until checked - a restore from a compromised backup is worse than no restore, because it consumes the recovery window and destroys confidence. The tape copy is more likely intact but is only useful if the tape library and the restore path are outside the attacker's reach, which has not been established.
Conditions that would change this: if the backups are found intact and the initial access vector is confirmed closed, restore in priority order starting with the share the business needs, on a rebuilt host, with the domain account removed from local administrator. If no clean copy exists, decryption becomes relevant, and payment should be evaluated by legal and insurance, not by IT, with the explicit understanding that a decryptor is not guaranteed to work.
State to leadership: a realistic restore time, not an optimistic one, and the risk that the share returns with data lost between the last clean backup and the encryption.
3. What does the absence of an administrative MFA control and the shared backup account tell you about the likely root cause, and how do you confirm it?
Read the worked answer
Assessment: the conditions are consistent with credential-based lateral movement rather than a purely opportunistic payload. A domain account with local administrator rights on the file server, used interactively by two people, is a plausible path from a single infected workstation to the server and then to the backup infrastructure. The missing MFA on the virtualization console offers a second, shorter path.
How to confirm: review authentication logs for the backup account and the two administrator accounts for the 72 hours before 03:12 - source hosts, times, and whether the account authenticated from a workstation it should never touch. Compare that timeline against the first endpoint alert and the first encrypted file timestamp. Check virtualization console logins for new sessions or new accounts. Examine scheduled tasks and services created on the file server in the same window. Look at whether the backup catalogue shows deletions or modifications, which would indicate the attacker targeted recovery.
What I would avoid: concluding from the encryption extension or the ransom note. Those describe the payload, not the intrusion. Without the identity timeline you will rebuild, redeploy, and be re-entered through the same account, and the second encryption event will be faster than the first.