Is That PowerShell a Developer Test or an Intrusion?
At a 500-bed hospital, EDR flags PowerShell on a developer workstation: powershell.exe -nop -w hidden -enc downloads a .ps1 from cdn-verify[.]top, a domain registered three days ago with a self-signed TLS certificate. The script is obfuscated and attempts to disable AMSI. No other host has contacted the domain. The user says they were testing a deployment script and that the domain belongs to a vendor demo. Change management shows no approved test. The workstation has access to a clinical imaging share. You have two hours before a containment decision; reimaging requires clinical-application owner approval and could delay imaging. You have EDR, DNS, proxy, and authentication logs, but no sandbox.
1. Build competing hypotheses and map the evidence to MITRE ATT&CK.
Read the worked answer
Hypotheses: H1 malicious intrusion, commodity or targeted; H2 developer testing; H3 compromised developer account; H4 red-team exercise. Evidence favoring H1 includes hidden-window encoded PowerShell, obfuscation, AMSI bypass, a three-day-old domain, a self-signed certificate, no approved change ticket, and access to a clinical share. Evidence favoring H2 is the user's claim and the single-host scope. H3 would be supported by anomalous authentication or impossible travel. Map activity to ATT&CK: T1059.001 PowerShell, T1027 obfuscation, T1562.001 impair defenses, T1105 ingress tool transfer, and T1071 web protocols. Use the Diamond Model: unknown adversary, infrastructure cdn-verify[.]top, capability obfuscated script, victim workstation. Use ACH to score consistency and seek disconfirming evidence such as vendor confirmation that the domain is legitimate.
2. What immediate collection and containment decisions would you make?
Read the worked answer
Preserve volatile data first: memory image if possible, PowerShell operational logs, EDR process tree, command line, parent process, and network connections. Isolate the workstation from the network while keeping power, and block the domain at DNS and proxy. Query DNS and proxy logs for any other host contacting the domain. Review authentication logs for lateral movement and access to the imaging share. Interview the user and manager and contact the claimed vendor. Do not reimage until memory is captured and the clinical-application owner approves. Consider disabling or resetting the user account only after reviewing authentication evidence. Contain one workstation rather than the imaging suite to preserve patient care.
3. How would you communicate risk to clinical leadership without overstating attribution?
Read the worked answer
Say: 'We have a suspicious script on one workstation that has access to the imaging share. We have not confirmed data access or actor identity. We are isolating the workstation and preserving evidence; imaging operations on other workstations can continue. We will update in two hours.' Avoid naming an actor. State confidence as low and separate observed behavior from attribution. Frame options in patient-care terms: immediate isolation versus monitored containment, and the downtime risk of reimaging. Document the rationale so the decision is defensible later.