Hunting LSASS Without the Telemetry
You are the threat hunting lead at a healthcare provider with 6,000 endpoints and 900 servers. EDR covers 82% of endpoints, Sysmon is deployed only on servers, PowerShell script block logging is off, and SIEM retention is 30 days. A CTI report says a ransomware affiliate is using comsvcs.dll MiniDump (T1003.001), certutil for download and decode (T1105/T1140), mshta (T1218.005), and PowerShell (T1059.001) against healthcare targets in your region. The CISO asks for 'a hunt for this actor by Friday.' You have two hunters, no dedicated network detection, and 40 hours total. The SOC has seen three unconfirmed alerts on lsass.exe access in the past week, all closed as 'IT admin activity.'
1. Turn the report into a hunt hypothesis and scope. What exactly will you test, and what will you explicitly not do?
Read the worked answer
Hypothesis: 'If this affiliate is present in our environment, we will observe rundll32.exe loading comsvcs.dll and accessing lsass.exe memory, or certutil/mshta spawning PowerShell and making external network connections, on servers or EDR-covered endpoints within the last 30 days.' This is testable and falsifiable. It is not 'search for the actor's IOCs,' which would only confirm known infrastructure and miss modified tooling.
Scope:
- Time: last 30 days, because SIEM retention is the hard limit. State that older compromise cannot be excluded.
- Assets: 900 servers with Sysmon and EDR telemetry; 4,920 EDR-covered endpoints; 1,080 endpoints with no EDR are out of direct scope and must be flagged as a coverage gap.
- Data: EDR process trees, command lines, image loads, network connections; Sysmon events on servers; Windows Security events where available; proxy or DNS logs if they exist.
Explicit non-goals:
- No IOC-only sweep of the report's hashes and domains.
- No full disk or memory forensics; that is an IR activity, not a 40-hour hunt.
- No attribution claim. We are testing for behavior, not naming an actor.
- No 'clean' conclusion for the 1,080 unprotected endpoints or for activity older than 30 days.
The three closed lsass alerts are leads, not noise. Reopen them and examine source image, parent process, user context, signature, and whether comsvcs.dll was loaded. If the source was a signed IT tool with a known maintenance window, document it as a baseline; if it was rundll32 with no parent context, escalate to IR immediately.
2. Given the telemetry gaps, how do you allocate the 40 hours and what compensating collection do you request?
Read the worked answer
Allocate by risk of wasted effort, not by query count:
- 6 hours: validate data sources and build the baseline. Confirm which EDR event types retain command lines and image loads, what Sysmon events exist on servers, and how far back each source actually goes. Test the queries against known benign admin activity.
- 14 hours: triage the highest-value hypotheses: comsvcs.dll/rundll32 accessing lsass, certutil making outbound connections or decoding files, mshta spawning PowerShell, and unusual PowerShell parent-child chains. Start with servers and endpoints used by IT administrators, because those are the likely first targets and the source of the closed alerts.
- 6 hours: validate hits with asset owners and IR. Separate true malicious behavior from admin tooling; preserve evidence for any escalation.
- 8 hours: convert validated behavior into detection rules and a triage playbook.
- 6 hours: document coverage, gaps, and handoff.
Compensating collection requests, in priority order:
- Reopen and review the three lsass alerts with full EDR process context.
- Pull proxy, DNS, and firewall logs for certutil and mshta egress from servers and EDR-covered endpoints.
- Ask IT for the software deployment and admin-tool inventory so benign lsass access can be baselined rather than repeatedly triaged.
- Request emergency approval to enable PowerShell script block logging on domain controllers and high-value servers, and to extend Sysmon coverage to endpoints where EDR is absent or limited. This will not help Friday's hunt fully, but it prevents the next blind hunt.
- Start an EDR coverage remediation ticket for the 1,080 endpoints.
Do not spend the 40 hours building a perfect ATT&CK coverage map. Spend it testing the hypothesis and converting gaps into owned actions.
3. What outputs make this a successful hunt even if no actor is found, and how do you avoid the 'no findings equals success' trap?
Read the worked answer
A hunt succeeds when it reduces uncertainty and improves future detection, not only when it finds malware. Required outputs:
- A hunt report stating the hypothesis, data sources used, time window, asset coverage, queries, and limitations. It should say 'no evidence found in 4,920 EDR-covered endpoints and 900 servers over 30 days' rather than 'no compromise.'
- Detection content: at least one behavioral rule for comsvcs.dll/rundll32 lsass access and one for certutil/mshta egress, with tuning notes and known false positives.
- A validated benign baseline for lsass access by IT tools, so the SOC can close future alerts faster and escalate the outliers.
- A data-source gap register with owners and dates: PowerShell logging, Sysmon endpoint coverage, EDR gaps, retention, and network telemetry.
- An ATT&CK coverage note showing which techniques were testable and which were not.
- A triage playbook for the three reopened alerts and any new hits.
Avoiding the trap: define 'inconclusive' as a legitimate outcome. If PowerShell logging is off and 18% of endpoints lack EDR, a quiet result cannot be called 'clean.' Report confidence separately from findings. Give the CISO a one-page statement: 'We tested these behaviors; we found no confirmed malicious activity in covered data; we cannot exclude it in these blind spots; these are the actions and dates to close them.' That is more honest and more useful than a green dashboard. Also track whether the hunt produced a detection that later fires or a gap that gets funded; those are lagging indicators of hunt value.