The Ransomware Note With No Encryption
Monday 09:10. A user reports a text file on their desktop claiming all files are encrypted and demanding payment. You find the note on 6 machines in one department. File shares show no mass renaming and no extension changes. EDR shows a scheduled task created Friday 17:55 on those 6 machines, running a signed remote-management tool that the IT team does use, launched from a parent process of powershell.exe -enc <base64>. Two of the six machines have outbound connections to an IP with no reputation data. Backups run nightly at 01:00 and completed successfully on Sunday. Leadership wants to know whether to pay, and whether to invoke the full incident response plan.
1. Is this a ransomware incident? Justify your answer and state what you would tell leadership in the first ten minutes.
Read the worked answer
It is an intrusion with a ransomware pretext, but encryption has not been confirmed. The note is present on 6 hosts, yet there is no mass renaming, no extension changes and no share damage - the observable effects of encryption are absent. That means either the encryption stage has not run yet, or the note is a bluff, or encryption is happening somewhere you have not looked.
The scheduled task is the strongest signal: created Friday evening, running a legitimate signed remote-management tool, launched by an encoded PowerShell command. That is a hands-on-keyboard intrusion using living-off-the-land techniques, regardless of whether encryption follows. Two hosts beaconing to an unknown IP supports an active foothold.
What to tell leadership in ten minutes: this is a confirmed intrusion, encryption is not yet confirmed, backups from Sunday are intact, and payment is not on the table at this stage. Do not speculate about data theft yet. Invoke the incident response plan - an active foothold with a remote-management tool is exactly the case the plan exists for, even without encryption. The judgement point is not to let the ransom note define the incident; the intrusion does.
2. Outline your first-hour actions and explain the priority order.
Read the worked answer
Priority order follows: stop spread, preserve evidence, understand scope, then decide on recovery.
- Contain the network: isolate the 6 hosts at the switch, block the unknown IP at the perimeter, and disable the scheduled task centrally. Do not power off - preserve memory.
- Preserve: capture memory from at least one host, export EDR telemetry and SIEM logs for Friday onward, and record the base64 PowerShell payload for decoding.
- Scope: hunt for the same scheduled task, the same remote-management tool and the same IP across all endpoints. Six known hosts is a floor, not a total.
- Decode the PowerShell and identify how the task was created - which account, from where. That tells you whether credentials are compromised.
- Verify backups are genuinely clean and restorable before anyone relies on them.
Why this order: containment first because the foothold is live; preservation second because isolation changes state and memory is perishable; scoping third because you cannot decide recovery until you know what is affected. Payment is not discussed until scope is known. Note the 09:10 start and the Friday 17:55 task creation - the intruder had roughly 63 hours of access before detection, so assume more was done than you can currently see.
3. The remote-management tool is legitimately used by IT. How does that affect detection and how would you distinguish malicious use from normal administration?
Read the worked answer
Legitimate tooling removes the easy signal - you cannot alert on the binary, the signature or the vendor name. Detection has to move to context: who launched it, from where, when, and what it did next.
Discriminators to check:
- Parent process. A remote-management tool spawned by encoded PowerShell is not normal IT administration; a helpdesk tool launched from an RMM console or an interactive session is.
- Timing. Friday 17:55 is outside normal change windows and just before a weekend, a common choice for intruders seeking quiet time.
- Account. Which account created the task, and does that account normally do so? Compare against the change record - was there an approved change for these 6 machines?
- Scope pattern. Six machines in one department is a target set; routine administration usually follows a broader or ticketed pattern.
- Outbound behaviour. Connections to an IP with no reputation data from a management tool are not expected.
The judgement: the tool being legitimate is not exculpatory, and its presence should not be dismissed as "just IT." Equally, do not assume malice - confirm with IT whether a change was scheduled. If no change record exists, the combination of encoded PowerShell parentage, weekend timing and unknown outbound IP is enough to treat as malicious. Document the comparison so the finding survives review.