DWELL TIME
HUNTING
LOOK-BACK
FIRST SEEN
DetectionBlue TeamSOCOctober 12, 2026•9 min read

Dwell-Time Hunting for Pre-Encryption Footholds

Alerts find what you wrote rules for. A look-back hunt finds the access that has been sitting in your network for weeks, waiting for a buyer.

Scroll

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 questionDataATT&CK
Which accounts authenticated after 60 or more idle days?Identity logs, 4624T1078
Which VPN users appeared from sources never seen before?VPN logs, 90 daysT1133
Which remote-management tools first appeared on servers?EDR inventoryT1219
Which services or tasks were created by unusual accounts?7045, 4698T1543.003
Which new local administrators exist outside provisioning?4732, 4720T1136.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")`
Vetted sources

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 EngineeringManaged Detection & ResponseThreat HuntingIncident ResponsePurple Teaming
  • 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.
Written by: Mjolnir Threat Research (MTAC)  |  Published: October 12, 2026  |  Last reviewed: October 12, 2026