Proactive Threat Hunting: How to Find Threats Before Alerts

On April 12, 2024, Palo Alto Networks published an advisory for a command injection in GlobalProtect that attackers were already using. The first community detection rule for it merged twelve days later. Proactive threat hunting is the work a defender does inside those twelve days.

Instead of waiting for a mature signature or detection rule, defenders can hunt for the underlying behavior described in the available intelligence. A public writeup tells you what an attacker has to make the software do, and that behavior shows up in telemetry you already collect, long before anyone writes a rule that names it. The rule closes the gap later. The hunt covers it now.

Key takeaways about proactive threat hunting

• A hunt counts as proactive when the thing that started it was intelligence rather than an alert. The trigger is what changes. The loop that follows it stays the same.
• The time between a vendor disclosure and the availability of relevant public detection content can create a measurable coverage gap. For CVE-2024-3400, one useful benchmark is the interval between Palo Alto Networks’ April 12 advisory and the later SigmaHQ rules targeting the vulnerability.
• Hunting without a rule means hunting without a known-good baseline, so run it against a small, intelligence-selected set of techniques rather than against everything you read.
• Code, cloud, identity, and endpoints are four telemetry sources answering one hypothesis. Treating them as four hunting programs is how mid-size teams end up staffing none of them.

What Is Proactive Threat Hunting?

Start with the objection, because it is a fair one. Every hunt reacts to something: a report, a rumor, a colleague’s hunch, a number on a dashboard that looked wrong. Nobody wakes up and hunts from a standing start. If proactive only means enthusiastic, the word is marketing.

It earns its place when you define it by the trigger. Proactive threat hunting doesn’t mean acting before anything happens. It means acting on intelligence rather than on an alert.

That distinction is operational. An alert-triggered investigation begins with a detection that already exists, which means someone already decided the behavior was worth catching and wrote it down. An intelligence-triggered hunt begins with a behavior nobody has encoded yet. The hypothesis loop that follows is identical either way. What changes is who set the clock.

Why AI-Powered Attacks Demand a More Proactive Defense

The case for waiting. Community and vendor rule authors have seen a technique across more environments than you have. Their rules arrive with a false-positive profile someone else paid for, they get tested against telemetry shapes you do not own, and they get maintained after the news cycle ends. A four-person detection team that hunts every advisory itself will not reach the end of the quarter. Waiting is triage, and triage is the correct instinct most weeks.

The exception. When exploitation is confirmed in the wild against something on your perimeter, the waiting period and the exposure period are the same days. Automation can shorten the time between public disclosure and widespread exploitation, while defenders may still need time to develop, test, tune, and deploy reliable detections.

This is the same shape as the argument against chasing every vulnerability. A patch exists on a date. A rule exists on a date. Neither of those dates is the day it started protecting you, and the distance between them is not a scheduling problem you can staff your way out of.

Hunting for New TTPs Before Detection Rules Exist

Take one edge device and follow the clock. Every date below is public and checkable.

Method, so you can reproduce it. Take the vendor advisory’s publication date, then take the merge date of the first commit adding a rule for that CVE under rules-emerging-threats in the SigmaHQ repository. The difference is the rule-availability gap. Here it is twelve days, and the last leg of the journey, deployment into a live environment, carries no public timestamp at all.

Twelve days is the honest cost of writing something that will not drown a stranger’s SOC in false positives. Nobody is at fault in that table. The window exists anyway.

You do not have a rule on day two. You do have a mechanism. By April 16 the public writeup told you the appliance was writing attacker-controlled filenames into its own telemetry directory and then handing them to a shell. Once the behavior is understood, teams that already collect the relevant telemetry can begin translating it into hunting queries without waiting for a finalized community rule.

So the hunt is narrow: file-creation events under /opt/panlogs/tmp/device_telemetry/ where the filename carries shell syntax instead of a telemetry archive name. The device’s own log answers the same question from a second angle, with malformed values inside failed to unmarshal session(.

The benign look-alike. PAN-OS enforces no filename convention in that directory, so an odd name is not evidence by itself, and support or diagnostic tooling that stages files there produces events you cannot distinguish from the attack. Treat what comes back as a shape worth reading, then confirm it against the second angle.

**Where this falls ****apart.**Hunting before a mature rule exists often means working with a less established baseline and a less understood false-positive profile. Your first pass returns the whole directory, you build the baseline by reading it, and the work is expensive in the only currency a detection lead actually has, which is analyst hours.

That is why this runs against a small set rather than everything you read. A practical prioritization model is to favor hunts where exposure is meaningful, exploitation is confirmed or highly credible, the affected asset matters to the business, and relevant telemetry is already available. Then accept that you will pick wrong often.Many advisories will ultimately prove irrelevant to a particular environment, which is why asset exposure and business context should drive prioritization rather than advisory volume alone.

One boundary worth naming. This is the conversion side of the intelligence problem, turning a specific report into something that runs. The separate question of what your feeds never told you in the first place belongs to threat intelligence gaps, and confusing the two produces hunts with no source and sources with no hunt.

A usable detection rule may arrive later. The operational question is what coverage you had while it was still being researched and tested.

Finding Threats Across Code, Cloud, Identity, and Endpoints

One compromised appliance is not one surface. The hypothesis stays fixed and the telemetry rotates, which is how a small team covers four domains without funding four programs.

Code. Ask which pipelines and repositories can reach the affected system, and which of them hold credentials for it. Source-control and CI logs answer that faster than an asset inventory that was accurate last quarter. Benign look-alike: dependency bots touch the same files on the same schedule as someone probing them.

Cloud. Ask what the device’s identity can do in the control plane once an attacker holds root on it. Control-plane logs record every call it makes. Benign look-alike: backup and configuration management make the same API calls, on a timer, from the same principal.

Identity. Ask which sessions and tokens the device issued during the exposure window, and which of them survived the patch. Benign look-alike: a VPN concentrator legitimately issues sessions from unfamiliar addresses all day, which is the entire point of a VPN concentrator.

Endpoints. Ask what the first internal hop looks like from a device that has no business initiating one. Benign look-alike: remote administration tools and vulnerability scanners generate that same outbound pattern from that same segment.

Four questions can support one hypothesis across different telemetry sources, often using tools and data the organization already operates. Teams end up with four disconnected hunting efforts because each surface arrived with its own console and its own owner. The attacker never respected the boundary.

Why Human-Only Hunting Can’t Keep Pace With Machine-Speed Attacks

The usual version of this argument insults the reader. A senior analyst is not slower than an attacker at reasoning about an appliance’s behavior. Hand that analyst the writeup and the telemetry, and the hypothesis takes an afternoon.

The constraint is coverage over time. One analyst is awake for a third of the day, works a queue, and holds two live hypotheses at once. The advisory lands on a Friday. Automated exploitation does not observe the weekend, and neither does the offense and defense at the same speed dynamic that now governs how fast a public writeup becomes a working exploit.

The deficit is continuity: how many hypotheses stay live, across how many surfaces, for how many days, without anyone remembering to re-run them.

Using AI for Continuous and Real-Time Hunting

Frame the machine’s job as endurance. A model that reads an advisory, extracts the behavior, translates it into queries against the log sources you happen to own, and then keeps re-running those queries for the six weeks a technique stays interesting is doing work no human schedule accommodates. Your analyst would reach the same conclusion on day one. They would not still be re-running it on day forty.

Two words get used interchangeably here and they should not be. Real-time threat hunting is literal only where the hunt sits on a streaming pipeline and evaluates events as they arrive. Retrospective sweeps across ninety days of history are continuous, and calling them real-time sets an expectation your retention cannot honor.

Judge any such system on the boring criteria: what it does with a technique that has no rule, how it behaves when the log source is missing, and whether it tells you which hypotheses it quietly stopped testing.

How Mars Security Hunts Emerging Threats at Machine Speed

That gap is the problem Mars Security was built around. Mars ingests threat intelligence across the ecosystem, extracts the attacker behavior rather than the indicators, and turns it into hunts that run against your data wherever it already lives: SIEM, EDR, identity providers, cloud telemetry, Snowflake, Databricks. No ingestion pipeline. No rip-and-replace. Hunts run continuously instead of arriving as a quarterly project, and the test to hold us to is the one above: an advisory lands on a Friday, no rule exists anywhere, and something is querying by Saturday.

Frequently Asked Questions About Proactive Threat Hunting

What starts a proactive hunt if not an alert?

A named source. In practice that means a vendor advisory, a CISA entry, a research writeup, a red-team finding, or a change in your own environment such as a newly exposed service. Recording which source triggered each hunt is what lets you audit the program later, because it shows what you acted on and what you ignored.

How is this different from vulnerability scanning?

A scanner answers whether you are exposed to a known flaw. A hunt answers whether someone already used it against you. The two run on different clocks: the scanner needs a signature for the affected version, the hunt needs a description of the behavior, and the behavior is usually public first.

Do proactive threat hunting services replace an in-house team?

They change who carries the on-call burden. The outcome stays yours. A service can run the sweeps and staff the hours, but it cannot know that your finance segment has an odd yet sanctioned admin workflow. Most teams that buy delivery keep hypothesis selection and environment context internal.

How much log retention does this require?

Enough to cover the exposure window, which usually runs longer than the advisory window. If a technique was exploited quietly for six weeks before disclosure, thirty days of retention means your retrospective hunt can only ever confirm good news. Check retention per source rather than in aggregate, because the cheapest source to store is rarely the useful one.

How do you measure a hunting program that finds nothing?

Count hypotheses tested, sources covered, and elapsed time from intelligence arriving to a query running. A hunt that finds nothing has still ruled something out, and writing that down is what stops three analysts asking the same question three times in a year.

When should a hunt become a permanent detection rule?

Once it has survived enough passes to have a false-positive profile you can predict. Until then it stays a query someone runs and reads. Promoting it early is how teams end up with rules nobody trusts and a queue that trains analysts to close things fast.

Twelve days is a small number and a real one. You cannot make the next rule arrive sooner, and you have no say in which advisory lands on a Friday. You do decide whether anything was running while the rule was being written. If you would rather that window were covered by continuous hunts on new intelligence than by whoever happens to read the advisory first, start by working out how long your last one stayed open.