Scoping the Incident: How Far Did They Get?

You have confirmed the alert on WS-FIN-014 is real: a loader pulled a second stage from a VPS in a data center nobody does business with. Now the question that keeps CISOs awake: is this one workstation, or is it everywhere? Scoping is the discipline of answering "how far did they get" without either panicking the whole company or missing patient zero.

Scoping starts from the IOC, not the host

Indicators of compromise — hashes, domains, IPs, file paths, mutex names, registry keys — are your sweep terms. Extract them from the confirmed host first, then hunt everywhere else for the same fingerprints.

A bad IOC sweep looks for evil.exe. A good one looks for the things the attacker cannot easily change: the C2 domain with its JA3 fingerprint, the named pipe, the scheduled task name OneDrive Sync Health, the registry run key pointing at %APPDATA%\Update\.

Sweep the fleet with what you already have

If you run osquery (a free, mature fleet-query tool — version 5.x is current), a scoping sweep is a few queries away:

-- Every host that resolved the C2 domain recently
SELECT DISTINCT h.host, a.address
FROM dns_resolvers r
JOIN interface_addresses a USING (interface)
JOIN host_details h ON 1=1
WHERE r.host IN (SELECT host FROM dns_resolvers);

-- Scheduled tasks not signed by Microsoft (Windows)
SELECT name, path, action, hidden
FROM scheduled_tasks
WHERE action NOT LIKE '%Microsoft%';

-- Persistence locations on Linux
SELECT * FROM crontab;
SELECT path, contents FROM file WHERE path IN
  ('/etc/rc.local', '/etc/init.d/', '/usr/lib/systemd/system/');

No osquery? Windows Event Logs carry the same signal if you know the IDs:

• 4624 — logon success (type 3 = network logon, your lateral-movement indicator)
• 4648 — explicit credential use (someone passed a password or hash)
• 4698/4702 — scheduled task created / enabled
• 7045 — a service was installed (classic persistence)

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} |
  Where-Object {$_.Message -match 'Logon Type:\s+3'} |
  Select-Object TimeCreated, Message -First 100

On Linux, /var/log/auth.log (Debian) or /var/log/secure (RHEL) gives you the same story:

grep 'Accepted' /var/log/auth.log | awk '{print $9, $11}' | sort | uniq -c | sort -rn

A login from WS-FIN-014 to the domain controller at 02:31 is not an accident.

Draw the blast radius explicitly

Scoping output is a list, not a vibe. You want three columns:

"Exposed" is a real category — credentials on that host may have been stolen even if no malware landed. Kerberos tickets and LSASS memory do not care whether the attacker installed a payload on the DC.

The bug that ships: scoping too narrow

The most expensive IR mistake is calling it "one workstation" because you only looked for the dropper's hash. Attackers rotate hashes trivially; they rarely rotate tradecraft. Sweep for behavior (encoded commands, unusual parent-child pairs, logon patterns) not artifacts.

The opposite failure — declaring everything compromised — is nearly as bad. If you cannot separate exposed from compromised, you will rebuild the domain on a hunch, and you still will not know where they came in.

Try this

Your confirmed host ran net group "Domain Admins" /domain and then a type-3 logon hit SRV-FS-02 at 02:47. Write the three IOC classes you would sweep for across the fleet, and the specific log or table you would query for each.

Pitfalls

• Log retention. If auth logs rotate after 7 days and dwell time was 40 days, your sweep has a hole — say so in the scope report rather than implying a clean bill.
• Cloud gaps. Endpoint telemetry is easy; remember OAuth grants, SaaS audit logs, and IaaS flow logs are separate sweeps.
• Confirmation bias. Build the "clean" case as hard as the "compromised" case. An absence of evidence where you should see evidence is itself a finding.