Ransomware on Endpoints and a Domain-Joined Backup NAS
A manufacturer has 1,500 Windows endpoints, of which 400 are remote and only 65 percent have the EDR agent reporting in the last seven days. It also runs 60 Linux VMs in two cloud regions, protected by security groups and a cloud-native firewall but with no host agent. On a Monday, the EDR console flags a ransomware-like encryption pattern on three endpoints and, 40 minutes later, on a file server share. Two of the affected user accounts are domain admins. Backups run nightly to an on-prem NAS that is domain-joined. The CISO wants all endpoints isolated immediately; operations says the three HMIs on the plant floor VLAN cannot tolerate disconnection.
1. Set out a containment and triage sequence for the first two hours. Justify the order and say what you would not do.
Read the worked answer
First, stop spread without breaking the plant: use EDR network containment on the three affected endpoints and the file server, then isolate the plant VLAN at the switch or firewall only for the segments that are not the HMI VLAN. The HMIs get a targeted rule set that permits only their known control traffic, not blanket isolation. Second, disable the two domain-admin accounts and reset their credentials, and check for active sessions and scheduled tasks. Third, preserve evidence before wiping: memory capture, EDR process trees, and the file server's SMB session logs.
Then scope: query EDR and firewall logs for the same file names, hashes, and command lines across all reporting endpoints, and identify the initial access vector. Do not immediately rebuild machines, because that destroys the evidence needed to find the entry point. Do not assume the 35 percent of agents not reporting are clean; treat them as unknown and check them via network telemetry. Escalate to a domain-wide compromise assessment if the admins' credentials were used interactively on a domain controller.
2. The cloud VMs have no host agent, and 35 percent of endpoints are not reporting. How do you close these visibility gaps during the incident, and what permanent change do you recommend?
Read the worked answer
During the incident, use what exists: cloud-native flow logs, security group change logs, and the cloud firewall to identify outbound connections to known-bad infrastructure and unusual east-west traffic. Snapshot the 60 Linux VMs for offline analysis and, where the provider supports it, run agentless file integrity or disk scanning. For the missing endpoints, use NAC or switch port data to locate them, push the agent through management tooling, and quarantine the ones that cannot be reached until they are inspected.
Permanently, require agent health as a condition of network access for managed endpoints, with a documented exception process for OT devices. In the cloud, deploy a workload protection agent or an agentless snapshot-scanning pipeline, and keep security groups under change control. Set an SLO for agent coverage, for example 98 percent reporting within 24 hours, and alert on drops. The 65 percent figure was itself a finding: the incident response should not be the first time coverage is measured.
3. The NAS is domain-joined and was encrypted. What does that imply for recovery, and what backup design would you put in place?
Read the worked answer
A domain-joined NAS inherits domain trust, so compromised domain-admin credentials can reach it, delete shadow copies and encrypt backup files. That makes the nightly backups untrustworthy as a clean recovery source until proven otherwise. Recovery must use an offline or immutable copy: snapshots on the NAS are not enough if the attacker had admin rights. Rebuild to isolated infrastructure, restore from the last known-good offline copy, and validate by checking file hashes and by scanning before reconnecting to the domain.
The redesigned backup should follow the 3-2-1 principle with at least one immutable, offline or object-lock copy that the domain cannot delete, separate credentials for the backup service, and a tested restore runbook with a defined RTO and RPO. Remove domain join from the backup target or place it in a separate tier with no interactive admin logon. Test restoration quarterly and include a ransomware scenario in the test, because an untested backup is a hypothesis, not a control.