EDR Threat Hunting: Finding Threats Beyond Endpoint Alerts

An analyst opens the EDR console on a Tuesday afternoon with three spare hours and no alert to chase. That is where EDR threat hunting begins. The console already holds weeks of process, network and file telemetry, and most of it has never been read by a person.

Key takeaways about EDR threat hunting

• Endpoint hunting means querying telemetry your agent already stores for behavior it was never tuned to alert on. The vendor's alert set is a cross-customer compromise; your environment permits narrower questions.
• Confirm logging and retention before writing a query. Windows process-creation auditing and command-line capture are both off by default, and several Sysmon event types stay disabled until someone configures them.
• Many endpoint detections collide with legitimate admin work, because attackers use the same signed binaries your administrators do. Name the benign look-alike before you tune, or the hunt hands you a triage queue.
• Start with signed binary proxy execution, built-in downloaders, directory reconnaissance, Active Directory enumeration and relocated system binaries. Then follow the finding into identity and cloud data, which is where many hunts stall.

What Is EDR Threat Hunting and How Does It Work?

EDR threat hunting is the practice of querying telemetry your endpoint agent already collects. This includes process creations, command lines, parent-child relationships, network connections, and module loads. The goal is to find attacker behavior beyond what the vendor’s detection set alerts on. The data is already sitting there. The query is the missing part.

Two boundaries hide inside the phrase "beyond endpoint alerts." Beyond alerts means working inside endpoint data. Beyond the endpoint means leaving it. This article does the first, and reaches the second only at the end, as the consequence of a finding.

The case for leaving it to the EDR. Your vendor may watch the same behavior across a large fleet. Their detection engineers do this full time, with telemetry from environments you will never see, and their coverage of common attacker techniques will often beat what you write on a Tuesday afternoon.

So the honest recommendation is narrow. Hunt what is specific to your estate: your admin tooling, your naming conventions, your build hosts, your service accounts. That is the part a cross-customer false-positive budget cannot account for. Your EDR is not failing to alert. It is alerting on what its vendor decided was worth waking someone for.

What Endpoint Data Should Security Teams Hunt Across?

Before writing a query, find out what is in the store. An endpoint hunt can fail before it starts because the event it depends on was never recorded.

Microsoft makes the first row concrete. Its command-line process auditing documentation states that Audit Process Creation and the separate policy adding command-line text to event 4688 are not configured by default. Without enabling both, the most useful field in an endpoint hunt does not appear in the event.

Sysmon closes that gap and opens another. It logs process creation with the full command line, but its network, image load and DNS events each require configuration.

Microsoft attaches a warning to command-line auditing worth reading twice: once arguments are logged, anyone who can read the security event log can read them, passwords included. Turning it on improves every hunt below and adds to the pile of secrets sitting in your logs.

Common Endpoint Threat Hunting Use Cases

Five hunts you can run this week. Each names the legitimate activity it will collide with, because on an endpoint the attacker's tools and the administrator's tools are the same binaries.

• Signed binary proxy execution. rundll32.exe, regsvr32.exe, mshta.exe and msiexec.exe can run attacker code through Microsoft-signed binaries, which is the point of the system binary proxy execution family (T1218). Query those images for command lines referencing a user-writable path, a URL, or no exported function. Benign look-alike: Windows calls rundll32.exe for Control Panel applets and printer drivers all day, and deployment tooling runs msiexec.exe against packages staged in temp paths. Filter on argument shape rather than image name.
• Built-in downloaders. certutil.exe -urlcache -f fetches a payload through a utility every host already trusts (T1105), and bitsadmin.exe does the same job through the transfer service. Query either binary for http in the command line. Benign look-alike: certutil.exe is a certificate administration tool, and PKI scripts use it to pull revocation lists; certutil -hashfile turns up in build pipelines. The URL argument narrows it.
• Directory and file reconnaissance. An operator who lands on a host walks it: recursive dir /s across mapped shares, tree, searches for *.kdbx, .pem or password (T1083). Query for several discovery commands from one process tree in a short window. Benign look-alike: backup agents, search indexers and DLP scanners walk directories on a schedule, and so does the engineer hunting a file they saved last year. The burst and the parent are the signal.
• Active Directory reconnaissance from the endpoint. Active Directory threat hunting usually starts at the domain controller. Start it on the workstation instead: net group "Domain Admins" /domain (T1069.002), net user /domain (T1087.002) and nltest /domain_trusts (T1482), inside minutes of each other on one host. Benign look-alike: helpdesk staff run these exact commands, and so do login scripts and inventory agents. Hunt the sequence and the account behind it.
• System binaries running from user-writable paths. A system utility staged in %APPDATA%, C:\Users\Public or %TEMP% is a simple form of evasion, because rules keyed only to an image name follow the name wherever it goes. Query for system binary names executing from unexpected paths, accounting for legitimate locations such as System32, SysWOW64, and WinSxS. Benign look-alike: installers and updaters stage executables in temp directories constantly. Restrict the query to renamed or relocated copies and the volume collapses to something readable.

Best Practices for Endpoint Threat Hunting

Best practices for endpoint threat hunting are usually written as virtues. These are written as the five mistakes that cost a small team the most time.

Mistake: hunting before checking what is logged, and for how long. Endpoint hunting is bounded by what the agent collects and how long it keeps it, and that window may be measured in days or weeks. A hunt for a behavior that occurred five weeks ago returns nothing, and returning nothing is not the same as nothing happening. Check retention and the enabled event set first. Every time.

Mistake: hunting the binary instead of the behavior. A hash may change between campaigns; a process relationship or command-line pattern may persist longer. Write queries against process lineage, command-line shape and execution path, which is why behavioral detection lasts longer than the indicator it replaced.

Mistake: hunting what the vendor already alerts on. A query that reproduces a detection already sitting in the console spends an afternoon confirming the EDR works. Point the hunt at what nobody else can see: your service account naming, your admin jump hosts, the one team still running a legacy deployment tool.

Mistake: no baseline, so every result looks anomalous. Count first, judge second. Run the query across thirty days, sort by frequency, and read the tail rather than the head. Without a baseline, a hunt produces a long list nobody has time to triage.

Mistake: leaving the result in the console. A hunt that finds something once and is never written down becomes a story, and the next analyst starts from scratch. Record the query, the window, the result and the exclusions you applied, then hand the repeatable ones to detection engineering.

How Mars Security Extends EDR Hunting Across the Security Stack

An endpoint finding rarely ends on the endpoint. You catch nltest /domain_trusts on a workstation, and the next three questions leave the host entirely: did that account authenticate anywhere unusual, did it assume a cloud role, has the same sequence run on other machines this month. The endpoint told you where to look. It cannot tell you what happened next.

Those answers live in identity logs, cloud control-plane records and whatever the SIEM retained. Three stores, three query languages, three retention policies. That gap can stop a hunt even when the hunt itself is sound.

That is the work we do at Mars Security. The behavioral hypothesis behind a proxied-binary hunt can extend into identity, cloud, and SIEM telemetry, running continuously against the data where it already sits. No new ingestion pipeline. No rip-and-replace. No linear increase in hunting effort. The EDR keeps watching the endpoint in real time. The scope question is what happens to a finding after that.

Frequently Asked Questions About EDR Threat Hunting

Is EDR threat hunting different from XDR threat hunting?

XDR can extend an investigation across endpoint, identity, email, and network telemetry, often through a shared data model or investigation layer. The hunting principles are similar; the difference is scope and integration. A team without XDR can still correlate exported endpoint telemetry with other sources in a SIEM or data platform.

How accurate is EDR data for hunting?

The events are useful, but their coverage is partial. Agents miss activity from before installation, from boot gaps, from unmanaged hosts, and from processes that interfere with the agent. Treat an empty result as evidence about your telemetry as much as about your environment.

Does Active Directory threat hunting need domain controller logs?

For authentication and ticket activity, yes. For enumeration, not always. Endpoint process telemetry can capture reconnaissance commands on the workstation, while domain controller logs provide additional evidence about the directory activity that followed.

How often should a team run endpoint hunts?

Set the cadence from the retention window. If the agent keeps fourteen days, a monthly hunt has already lost half of what it was meant to search. A fixed three-hour slot each week can beat an occasional all-day effort.

What happens when a hunt keeps finding the same thing?

It becomes a candidate detection rule, a different discipline with harder acceptance criteria. A hunt can tolerate a noisy result because an analyst reviews it deliberately. A production rule cannot tolerate the same noise, and the tuning needed to ship one may exceed the work that produced the hunt.

Stop waiting for the console to raise its hand. Start with one written hunt a week, run against telemetry you have confirmed is being collected, and treat every finding as the start of a question rather than the end of one. The next step is usually hunting beyond endpoint telemetry altogether.