SIRS study materials
SIRS study resources

Encoded PowerShell on a Radiology Workstation: Event or Incident?

SIRS · Put your knowledge to work in context.

All case studies

Encoded PowerShell on a Radiology Workstation: Event or Incident?

At 02:14 on a Saturday, the EDR console at a 420-bed hospital alerts on workstation WS-RAD-117. The alert shows powershell.exe -enc <base64> spawning from a scheduled task named AdobeUpdate, followed by an outbound TLS connection to 185.199.108.153. Three other radiology workstations show the same scheduled task but no outbound connection yet. The hospital has 4,200 endpoints and two analysts on call. The on-call analyst notes that the imaging software vendor uses PowerShell during updates and recommends closing all four alerts as benign. The IR lead is asked to make the call before the morning clinical shift. The EDR policy is set to detect but not block, and the workstation holds unencrypted local caches of patient studies. No user has reported anything unusual.

1. Is this an event or an incident? Apply a recognized definition and justify your answer with the evidence in the setup.

Read the worked answer

A security event is any observable occurrence in a system or network; an incident is an event that actually or potentially jeopardizes confidentiality, integrity, or availability. The evidence here crosses that line provisionally: an encoded PowerShell command, persistence via a scheduled task, an external TLS connection, and three additional hosts with the same task. The analyst's explanation is plausible but unverified. Legitimate vendor updaters usually have a documented hash, signer, and predictable destination; an unattributed IP and encoded payload are not enough to close. The correct decision is to treat this as a suspected incident, not a benign event, while confirming vendor legitimacy. Provisional severity should reflect potential impact: patient study caches are present, and the task appears on multiple clinical systems. I would set it at a mid-level severity pending scope confirmation, because impact is potentially high but evidence of data exfiltration is not yet confirmed. Closing the alerts without baselining the task, hash, and network destination would be confirmation bias and would violate the principle that ambiguous malicious-looking activity requires investigation, not assumption.

2. Which IR lifecycle phase are you in, and what are the next three actions? Explain why each action is chosen over alternatives.

Read the worked answer

This is detection and analysis, moving into containment planning. The next three actions are: first, preserve volatile evidence from WS-RAD-117 - process tree, scheduled task definition, PowerShell history, network connections, and memory if policy allows - before any reboot or reimage. Second, use EDR to hunt the scheduled task name, command-line pattern, and file hash across all 4,200 endpoints to establish scope; this is faster and less disruptive than network scanning. Third, isolate the four known hosts through EDR network containment rather than powering them off, because isolation preserves memory and remote access while stopping lateral movement. In parallel, contact the imaging vendor to confirm whether the task is legitimate and to obtain the expected signer and destination. I would not immediately close the alerts, wipe the hosts, or send a hospital-wide notice, because scope and impact are unknown and premature disruption to radiology would harm patient care. Document each decision with timestamps and rationale, because the incident log may later support regulatory or legal review.

3. What documentation and internal communication should occur if this is confirmed as an incident?

Read the worked answer

Documentation should begin immediately, even before confirmation, because the timeline is the backbone of later reporting. Record the alert time, analyst observations, the exact command line, hash, destination IP, affected hostnames, and every action taken with timestamps and the person responsible. Preserve the vendor's written confirmation or denial. If confirmed, open a formal incident record with a unique ID, severity, incident commander, and current phase. Internal communication should go to the CISO, IT operations, and clinical leadership on a need-to-know basis; the radiology director needs to know if imaging availability may be affected, but the whole hospital does not. Avoid asserting data exfiltration before it is confirmed. If patient data exposure becomes likely, engage privacy counsel early, because health-sector breach notification timelines can be short and the decision depends on the data types involved. The key reasoning is that documentation and limited internal escalation preserve options; broad premature communication can create rumor and legal risk without improving response.