XDR Ransomware Gap in a Plant Floor Policy
Helios Manufacturing has 1,200 endpoints across three endpoint groups: Corporate (800), Plant Floor (300), and Legacy Lab (100). A ransomware event encrypts file shares on 40 Plant Floor hosts. Cortex XDR alerts show 'Behavioral Threat Protection' detected the process on Corporate hosts and blocked it, but Plant Floor hosts only generated 'Local Analysis' malware alerts after encryption began. The Plant Floor policy has a module-wide exception for Behavioral Threat Protection, added six months ago for a vendor application. The Legacy Lab runs agent 7.9; the rest run 8.3. Sixty Plant Floor endpoints were offline during the attack and reconnected after containment. The vendor app is still required for production. The plant cannot tolerate a full agent upgrade during the current production run.
1. What is the most likely reason Corporate blocked the ransomware while Plant Floor did not, and what immediate containment actions would you take across the 40 encrypted and 60 reconnected hosts? Justify the order.
Read the worked answer
The most likely cause is the Plant Floor module-wide exception for Behavioral Threat Protection. Corporate had behavior-based blocking; Plant Floor had it disabled, so only signature-based Local Analysis remained. A new ransomware binary will often be missed by Local Analysis until encryption behavior is already visible. Containment should be simultaneous where possible, but if triage order is forced: first isolate the 40 encrypted hosts to stop active encryption and lateral spread through file shares. Immediately isolate the 60 reconnected hosts as untrusted, because they were offline, may have missed content updates, and may carry dormant persistence. Do not treat reconnected as clean just because they were offline during the visible encryption. Then block the affected file-share path, check for lateral movement to Corporate, and preserve memory or disk evidence before reimaging. Do not simply delete the vendor exception during the incident; that may break production and obscure the cause. Reset credentials if there is any sign of domain compromise.
2. The plant refuses an agent upgrade during production. How would you redesign the exception to restore Behavioral Threat Protection without breaking the vendor app? Include scope and validation steps.
Read the worked answer
Replace the module-wide exception with the narrowest exception that still lets the vendor app run. Scope it to the Plant Floor endpoint group and to the vendor process by name, path, signer or hash, parent process, and command line. If the product supports behavior-level exceptions, exclude only the specific behavior triggered by the vendor app while keeping ransomware and credential-theft protections active. If only a module exception is possible, compensate with a custom BIOC that alerts on the ransomware behavior, plus a policy restricting the vendor binary to its expected parent and path. Pilot on five representative Plant Floor hosts during a maintenance window, run the vendor workflow, and confirm that Behavioral Threat Protection still blocks a safe ransomware simulation on those same hosts. Monitor for 48 hours before broad deployment. Put an expiry date on the exception and schedule the agent upgrade after the production run.
3. How would you verify that the 60 reconnected endpoints are clean, and what XDR telemetry would you use to rule out persistence?
Read the worked answer
Do not rely on one full scan. Use XQL over the period before and after reconnection to examine process execution, file writes to startup folders, registry Run and RunOnce keys, services, scheduled tasks, WMI subscriptions, new local users, and network connections. Check whether any BIOC or malware alert fired before the host went offline. Use causality analysis to trace any suspicious process to its parent and child processes. A host is not clean merely because a scan returns no malware. Look for shadow-copy deletion, backup tampering, new remote-access tools, and outbound connections to newly registered domains. Use live terminal to collect autoruns and compare against a known-good baseline. If the host has no reliable telemetry from the offline period, reimage rather than accept a weak clean verdict. Document the evidence for each host.