Threat hunting sits in an uncomfortable gap for most Australian IT teams. The SIEM is running. EDR is deployed. Alerts get triaged. The assumption is that the stack will catch what matters. It won't. Skilled attackers, and increasingly even commodity ransomware crews, spend weeks inside a network before triggering a single automated alert. Threat hunting is the practice of going looking for them anyway.
It's different from incident response. Response is reactive: something fired, now deal with it. Hunting is proactive: you form a hypothesis about where an attacker might be hiding and you go test it against real data. Most hunts find nothing, and that's fine. The ones that do find something tend to find it significantly earlier than any alert would have.
Why automated tools leave gaps
Security tools detect known patterns. Signatures, behaviour baselines, rule sets built from previous incidents. An attacker who uses a legitimate remote management tool, moves laterally over existing admin shares, and exfiltrates data through an allowed cloud service can stay invisible for weeks. These are called living-off-the-land techniques, and they're standard operating procedure for most serious threat actors targeting Australian organisations.
The other problem is alert fatigue. If your team is drowning in low-fidelity notifications, the subtle signals that indicate real compromise get lost in the noise. Australian SIEM deployments frequently produce alert volumes that defeat their own purpose, and tuning alone doesn't solve the problem when attackers are deliberately avoiding the triggers you've set.
Threat hunting addresses this by shifting from "what did the tooling flag?" to "what would an attacker do here, and what trace would that leave?" It's analyst-led, not rule-led.
The anatomy of a hunt
Every hunt starts with a hypothesis. Not a vague feeling, but a specific testable statement: "A threat actor with access to our VPN credentials would authenticate outside business hours from an unusual geographic location, then enumerate file shares." That hypothesis tells you exactly what data to pull and what to look for.
Good hypotheses come from three places. First, threat intelligence relevant to your sector. Second, known attacker techniques from frameworks like MITRE ATT&CK. Third, findings from your own previous incidents or post-mortems. All three give you something grounded in reality rather than generic anxiety.
Once you have the hypothesis, you need the data. This is where logging gaps become a real obstacle. Hunters need process creation logs, network flow data, authentication events, and DNS query records at minimum. If those aren't retained and searchable, the hunt stops before it starts. Many Australian teams discover their log coverage is far thinner than they assumed when they try to run their first structured hunt.
Then comes the actual investigation. You pull the relevant data, look for statistical outliers, trace activity chains, and either confirm or disprove the hypothesis. If confirmed, you escalate to incident response. If not confirmed, you document what you checked and what looked normal. That documentation is valuable: it builds a record of your environment's baseline.
What skills a hunting team needs
Threat hunting is not a tool you deploy. It's a human capability. A hunter needs to be able to write queries across log sources, understand attacker tradecraft well enough to anticipate behaviour, and think analytically rather than procedurally.
Most Australian organisations don't have a dedicated hunting team. That's fine. Hunting works as a part-time discipline for senior analysts who already understand the environment. The critical requirements are:
- Comfortable writing queries in whatever language your SIEM or data platform uses (KQL for Microsoft Sentinel, SPL for Splunk, SQL-based for many others)
- Familiarity with MITRE ATT&CK tactics and how they map to observable artefacts
- Access to threat intelligence relevant to Australian targets and your sector
- Enough knowledge of your environment to recognise what's unusual
That last point is often underestimated. A hunter who doesn't know your normal can't identify your abnormal. Time spent understanding baseline behaviour, what services run on which hosts, what accounts authenticate where, what volumes of traffic are typical, is not wasted. It's foundational.
Starting a hunt programme without a dedicated team
The most common objection from Australian IT managers is capacity. A structured hunt programme sounds resource-intensive. Done well, it doesn't have to be.
Start with one hypothesis per fortnight, picked from a published threat intelligence report or a recent ACSC advisory. Run it for two to four hours. Document the result. After three months, you'll have run six hunts, built familiarity with the data, and identified at least two or three gaps in your coverage that you didn't know existed.
That process also feeds directly into your post-incident review discipline. Hunt findings that expose detection gaps become action items. Post-mortem findings that reveal new attacker techniques become future hunt hypotheses. The two practices reinforce each other.
For organisations that genuinely lack the internal analyst depth, co-managed hunting engagements with a local MSSP are a realistic option. The external team brings the methodology and tools; the internal team contributes the environment knowledge. Neither can do it alone effectively.
Common mistakes in early hunting programmes
The most frequent error is confusing hunting with alert triage. If your "hunt" is just reviewing the alerts the SIEM already generated, you're not hunting. You're doing incident response more slowly. Hunting requires moving beyond the alert queue into raw data and forming your own conclusions.
The second mistake is scope creep. A hunt that starts with "let's check for lateral movement" and expands to "let's review all admin activity for the past six months" is unmanageable. Narrow hypotheses produce actionable results. Broad ones produce paralysis.
Third: not documenting failed hunts. When a hypothesis is disproved, the tendency is to discard the work. Don't. A documented null result tells you what you checked, confirms a baseline, and prevents the same ground from being re-covered unnecessarily.
Finally, avoid letting hunting become a pure detective exercise disconnected from your defences. Every hunt should end with a question: "If this attack were real, would our controls have caught it?" The answer should feed directly into detection engineering, whether that's writing a new SIEM rule, improving a log source, or adjusting an alert threshold.
Threat hunting and the Essential Eight
Australia's Essential Eight maturity model provides a useful baseline for measuring defensive posture, but it's a compliance framework, not a detection capability. Organisations can score well against the Essential Eight and still be compromised for months without knowing it. Threat hunting is the practice that closes that gap: it turns static controls into active visibility.
The two approaches are complementary. Essential Eight gives you the controls. Threat hunting tells you whether those controls are actually stopping sophisticated attackers or just making their job slightly harder. At higher maturity levels, hunting becomes an expected part of the security programme rather than an optional extra.
For Australian IT teams that have spent the past two years focused on maturity uplift, threat hunting is the natural next investment. The controls are largely in place. The question is whether you'd know if they were being bypassed.