Many intrusions run for days or weeks before ransomware is deployed, and the early footholds are often quiet enough to pass every live alert. A scheduled look-back hunt exploits what the attacker cannot hide: first-seen events. A tool, account behaviour or persistence mechanism that appeared once and never matched your baseline is worth an analyst’s hour.
Signals at a Glance
| Hunt question | Data | ATT&CK |
|---|---|---|
| Which accounts authenticated after 60 or more idle days? | Identity logs, 4624 | T1078 |
| Which VPN users appeared from sources never seen before? | VPN logs, 90 days | T1133 |
| Which remote-management tools first appeared on servers? | EDR inventory | T1219 |
| Which services or tasks were created by unusual accounts? | 7045, 4698 | T1543.003 |
| Which new local administrators exist outside provisioning? | 4732, 4720 | T1136.001 |
First-Seen Software and Accounts
First-seen analysis is cheap and reliable. Build a baseline over a long window, subtract it from the last week and review what remains. Start with remote-management tools and unsigned binaries on servers:
// Defender / Sentinel (KQL) - remote tools first seen on servers in the last 7 days
let baseline = DeviceProcessEvents
| where Timestamp between (ago(90d) .. ago(7d))
| summarize by DeviceName, FileName;
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("anydesk.exe","screenconnect.clientservice.exe","teamviewer.exe","atera.agent.exe","splashtop.exe","rustdesk.exe","meshagent.exe")
| join kind=leftanti baseline on DeviceName, FileName
| join kind=inner (DeviceInfo | where OSPlatform startswith "WindowsServer" | distinct DeviceName) on DeviceName
| summarize first=min(Timestamp), accounts=make_set(AccountName) by DeviceName, FileName
// tune/validate: extend the list with the tools your own estate does not sanction
Dormant Accounts Returning
Brokers and affiliates favour credentials nobody watches. List accounts that were idle for a long period and then authenticated, with the hosts they reached:
index=wineventlog EventCode=4624 earliest=-90d
| stats count as total count(eval(_time>=relative_time(now(),"-7d@d"))) as recent count(eval(_time<relative_time(now(),"-7d@d") AND _time>=relative_time(now(),"-60d@d"))) as mid values(ComputerName) as hosts by Account_Name
| where recent>0 AND mid=0
| table Account_Name recent total hosts
`comment("tune/validate: the 90-day search window caps the idle test at roughly 60 days; prefer lastLogonTimestamp from AD for longer idle periods")`
- Schedule these hunts weekly. A hunt that runs once finds one intrusion; a hunt that runs every week finds footholds before they sell.
- Convert every confirmed hunt finding into a permanent detection, and note the data source gap it exposed.
- Retain logs long enough to look back at least ninety days, and longer for identity and VPN data.
- When you find a foothold, hunt for its siblings: the same tool, hash, account or source on other hosts.
Splunk ESCU and Elastic hunting content for dormant and first-seen analytics, SigmaHQ remote-tool rules, CISA #StopRansomware guidance on identifying pre-ransomware activity, and DFIR Report-style write-ups of long dwell cases. First-seen baselines are only as good as your retention, so baseline your own environment and data coverage.
Build Detections That Fire
Mjolnir Security helps blue teams turn threat intelligence into high-fidelity detections across endpoint, network, identity and cloud telemetry.
- Detection Engineering We build and tune detections mapped to ATT&CK from your own telemetry.
- Threat Hunting as a Service Hypothesis-driven hunts for the behaviours on this page.
- 24/7 Incident Response Containment when a detection fires. Call +1 833 403 5875.
Stay ahead of emerging threats. Get notified when we publish new intelligence reports and advisories.
Subscribe to Alerts