AI agents investigate every alert, add context, and prepare cases for response, on a full-stack SecOps platform that captures and correlates all your security data.
Cloud-based SIEM platform providing visibility across all your data sources
Every alert investigated, with a verdict and the evidence behind it
Manage your external footprint, publicly available data, and Dark Web leaks
Log management and threat detection across any of your log sources
Get ultimate assurance that your environment is free from threat actors
Fully featured distrubuted NDR for on-premises and public cloud environments
A SecOps platform purpose-built for industrial and OT environments
Integrated endpoint agent providing deep visibility, response and forensics
Deploy honeypots and honeytokens and stay ahead of threat actors
24x7 security operations from our Australian SOC. AI investigates every alert, and experienced analysts validate findings and contain threats around the clock.
24x7 managed detection and response across endpoint, network, cloud, identity, and log sources
Eyes-on-glass SOC and continuous threat hunting
Expert hunters and AI agents find attacker activity your alerts missed
Quickly recover from cyber attacks and breaches
ThreatDefence is the only SecOps as a Service company providing broad coverage across your entire technology stack with evidence-based security.
We provide security teams with full-stack SecOps infrastructure – you get deep visibility from day one, gain control over your security data, and get access to a comprehensive set of ready-to-use tools, detections, workflows, playbooks and scenarios.
24x7 SOC, Continuous Monitoring, Threat Containment and Incident Response
Visibility and actionable insights for all IT assets
Leverage our Cyber Range to train defenders based on real-world scenarios and simulations
OT and industrial cyber security services for critical infrastructure
Essential Eight monitoring, reporting, and evidence for ongoing compliance
Privacy Act reform impacts, obligations, and practical security considerations
Monitoring and compliance support for critical infrastructure environments
A practical guide to securing critical infrastructure with continuous monitoring
A practical buyer’s guide for schools evaluating SIEM and SOC services
A practical guide to selecting the right SIEM and SOC service for local government
Articles on security operations, AI and compliance
Events, awards and company news
Read what our customers say about us
Solution briefs and datasheets
How we keep your data secure
Technical support and knowledge base
Guides, case studies, and advisories in one place
How AI agents investigate alerts and run security operations
Free ebook: a practical guide to adopting an AI SOC platform
A practical guide to incident response and digital forensics
Where SOAR playbooks fit and where AI agents take over
October 31, 2026
November 2, 2026
We provide end-to-end SecOps solutions for Managed Security Service Providers (MSSPs), Managed Service Providers (MSPs), and Value-Added Resellers (VARs).
Find out how you can become a ThreatDefence partner.
Protect your entire technology stack and build your SecOps on your own pace
White-labeled AI SOC for every client tenant, co-managed with our SOC team
Launch your SOC business without any upfront investment
Embed security operations, threat intelligence and exposure data in your product
Sovereign SOC for Australian MSPs and MSSPs, with onshore analysts and client data
Set the rules for closing alerts automatically, with evidence checks and review
How MSPs deliver branded security monitoring with a SOC partner
ThreatDefence was an official partner of the Cyber Resilience Summit NSW, 29 October 2026 at Hilton Sydney.
Our team was back at BSides Canberra, and our cyber quiz was a hit again.
Two days in Perth with our partner Ever Nimble, on security operations and cyber resilience.
Sponsors of the AUSCERT Cyber Security Conference on the Gold Coast.
Sponsors of the Gartner Security & Risk Management Summit in March.
Sponsors of the Cyber Security for Critical Assets Summit in Perth, February 2026.
Expert conversations with speakers and attendees at CyberCon Melbourne 2025.
A threat hunting methodology gives your team a repeatable way to search for attacker activity that existing detections may have missed. It defines the question to test, the evidence to examine, and how to investigate and act on the results.A useful hunt leaves more than a findings list. It can uncover an intrusion, expose a logging gap, or establish where a suspected behavior was not found.
A threat hunt investigates a security question through to a supported conclusion. Running a query is one part of that work.
Searching for failed logins may return thousands of events without explaining whether an attack occurred. Looking for password spraying that led to mailbox access gives the investigation a direction. The hunter must connect the events, check legitimate explanations, and assess whether the available records support the conclusion.
An alert investigation usually begins with activity a detection has flagged. A hunt examines behavior that may have escaped that coverage, prompted by intelligence, an incident, an anomaly, or a suspected blind spot. Both can lead into incident response. When comparing threat hunting with MDR, separate the investigative activity from the service that delivers it.
Before searching, define what the hunt should answer and what evidence would be sufficient. That keeps unusual but unrelated events from turning a focused question into an investigation with no clear endpoint.
A new campaign report and an unexplained change in normal activity provide different leads. Choose an approach that fits the evidence available:
Test a specific idea about attacker behavior, such as scheduled tasks launching scripts from user-writable directories.
Translate a report or advisory into activity to examine locally. Confirm that the affected technology and attack conditions are relevant to your environment.
Establish expected activity for comparable users or systems, then investigate deviations. Account for maintenance, business changes, and differences between roles.
Search for known hashes, addresses, domains, or other indicators. These can identify exact matches but may miss variants using different files or infrastructure.
These approaches overlap. An indicator match can become the starting point for a behavioral investigation, while an anomaly can lead to a more specific hypothesis. Frameworks also classify hunting approaches differently.
A rare event provides a reason to investigate, not a malicious verdict. Likewise, no indicator matches do not rule out the broader technique. Retrospective threat hunting applies new intelligence to historical evidence, using both indicators and behavior where the data supports them.
A good hunting hypothesis describes attacker behavior that evidence could support or challenge. It states where to look, over what period, and why the question matters now.
“Look for suspicious logins” leaves the analyst to decide what suspicious means. “An attacker may have gained mailbox access after password spraying accounts without phishing-resistant MFA” identifies a sequence and a population to examine.
Write down the test before searching:
The stronger example still needs investigation. Failed attempts and a success from one IP address can involve unrelated users behind a shared gateway. Connect the targeted account, successful session, and subsequent mailbox activity before treating them as one attack.
Check what the mailbox rule did and whether it had an approved purpose. Test the legitimate explanation too: does the application owner recognize the activity, and do configuration or change records support that account?
Keep the original hypothesis when findings lead elsewhere. Record revisions and the evidence behind them so a reviewer can understand how the investigation developed.
Prioritize questions that connect a relevant threat with something your organization needs to understand. Useful inputs include:
Techniques reported against similar organizations or technology you use.
Access paths, affected accounts, or persistence methods that warrant a wider review.
Vulnerable services, leaked credentials, or critical systems that may have been targeted.
Behavior existing rules cannot reliably identify, including activity below alert thresholds.
A common vocabulary for selecting techniques and organizing the behavior examined.
Turn the input into a local question. An OAuth-abuse report becomes actionable when you identify which consent events, permissions, and application activity your team can examine.
Maintain the hypothesis, required data, owner, last run, result, and review cadence in a shared library. Keep blocked hunts visible. Missing audit history should become a collection priority rather than a question that quietly disappears from the schedule.
For the OAuth example, examine the app’s permissions and actual mail access against its approved purpose. An unfamiliar address alone does not establish abuse. Validate the consenting identity and application activity before deciding what the match means.
A library status such as “clear” must also retain its scope. A result from one covered site does not answer the same question for unmonitored sites.
Use a consistent threat hunting process, with room to change direction when the evidence warrants it. The steps below cover the work from the initial question to its operational follow-up.
Record the hypothesis, systems or accounts, time window, and evidence required. Confirm that the sources contain the relevant event categories for that period. A healthy connection can still lack the history or fields needed to test the question.
Inspect sample records and check timestamps and identifiers across tools. Set an effort limit, define who reviews uncertain findings, and establish when suspected compromise should enter incident handling.
Start with summaries that expose the behavior, then inspect the records behind them. For password spraying, review failures across accounts before examining successful sessions and mailbox changes.
Save query versions, parameters, and exact time ranges. Follow leads into other sources or widen the window when justified, recording why the scope changed. Verify query completion and result limits before treating the output as complete.
Connect activity through accounts, devices, sessions, processes, and destinations. Establish what happened before and after the event that attracted attention.
Check competing explanations. A remote administration tool may be approved while its use on a finance workstation is unexpected. Examine who ran it, what it accessed, and whether the timing and purpose fit known work. Keep contradictory evidence in the investigation record.
Separate attacker activity, security weaknesses, legitimate behavior, and unresolved questions. An exposed service may require remediation without showing that it was exploited. A suspicious sequence may require more evidence before it can be classified as malicious.
For negative results, distinguish not found from not observable. Complete, successful searches can establish that the behavior was not found within the covered scope and window. Missing records or unavailable sources leave the affected part of the question inconclusive.
Escalate suspected or confirmed compromise under incident procedures. Containment should not wait for the wider hunt or final report. Hunters can continue looking for related activity while responders address the immediate risk.
Assign the other outcomes too. A missing source becomes a collection task, a weakness becomes a remediation item, and repeatable attacker behavior becomes a detection proposal. Record the receiving owner and follow-up rather than leaving recommendations unassigned.
Preserve relevant results, searches, conclusions, limitations, and actions. Include legitimate explanations that were tested and evidence that changed the assessment.
Update the library with what the hunt established and what comes next: a recurring search, a revised hypothesis, or another question raised by the findings.
The “nothing found” outcome applies only to the behavior, sources, and period actually tested. If the requested window was only partly searchable, state that boundary in the conclusion.
Choose a framework according to the task. A process organizes investigations, a maturity model helps develop capability, and a behavior catalog helps decide what to examine.
Splunk’s PEAK framework stands for Prepare, Execute, and Act with Knowledge. It supports hypothesis-driven, baseline, and model-assisted hunts, with organizational knowledge and intelligence informing each stage.
Use it to establish a common way to plan analysis, conduct the hunt, and act on the results. Its model-assisted category includes analytical models and should not be treated as another name for generative AI agents.
TaHiTI stands for Targeted Hunting integrating Threat Intelligence. Developed through Dutch financial-sector collaboration, it organizes work into initiate, hunt, and finalize phases.
It emphasizes how intelligence guides investigations and how findings improve other security work. This is useful when a team needs a consistent route from a threat report to a local hunt, then into monitoring, incident response, intelligence, or remediation.
MITRE ATT&CK describes attacker tactics and techniques. Use it to select behavior and identify related activity worth examining. Map the behavior actually tested: a technique label does not establish that the required data was available or that the hunt covered every way to perform it.
The Pyramid of Pain considers the effort attackers face when defenders detect and deny different indicators or behaviors. It helps explain the value of finding a technique that persists across changing files or addresses. A query still needs validation; behavioral wording alone does not make it reliable.
PEAK and TaHiTI can structure the investigation, while ATT&CK and the Pyramid of Pain help focus its content. Apply the parts that improve the work without turning every hunt into an unnecessary checklist.
David Bianco’s Hunting Maturity Model describes five levels of organizational hunting capability, including how teams develop methods and put successful analysis into regular use.
Use the model to identify a practical next improvement. A team relying on indicator sweeps might adapt an established behavioral procedure. A team with successful manual hunts might document them and automate repeatable checks.
The goal is to free hunters to develop useful new analysis while proven methods remain in operation. Buying a platform or increasing the number of searches does not establish maturity. Baseline hunting is an analytical approach, not a separate maturity rank.
A hunt record should let another analyst review the conclusion and repeat the work. Include:
The hypothesis, why it mattered, and changes made during investigation.
Systems, accounts, sites, or tenants examined, with exact dates and times.
Sources searched, collection gaps, failed queries, and unavailable history.
Query versions, parameters, relevant results, and source references.
The conclusion, explanations tested, supporting evidence, and remaining uncertainty.
Incident references, remediation owners, collection tasks, and proposed detections.
Retain enough evidence to support the conclusion after the underlying logs expire, subject to the applicable retention and access rules. A summary without its scope and searches cannot show what was actually tested.
When a hunt identifies repeatable attacker behavior, define the observable pattern and data needed to detect it. Test the proposed logic against known malicious examples and expected activity in retained records.
Preserve the context that made the original finding suspicious. If the hunt relied on account role, application permissions, and an event sequence, reducing it to an unfamiliar address may lose the behavior while creating noise.
Send proposed rules or tuning changes through review, assign an owner, and monitor their performance after deployment. Check both unwanted matches and whether the rule still identifies the intended activity.
Some methods depend on context that is difficult to express in a reliable production alert. Keep those as repeatable hunts and schedule them according to risk and available history.
Choose a relevant question, verify that the evidence is available, and take it through the full process. Review the conclusion and limitations before deciding what to repeat or automate.
Close the work with a supported answer or an explicit unresolved question, and an owner for any follow-up. Keep the record so the next hunt builds on what the team has already established.
ThreatDefence applies this methodology within its 24x7 SOC. Hunters work from a shared hypothesis library mapped to ATT&CK, AI agents search every connected source, and every hunt receives a write-up, including those with no findings.
Confirmed findings move directly into incident response, which is included in the service. Repeatable findings become reviewed detections.
Explore threat hunting for your organization, from investigation coverage to reporting and next steps.
CountryAustraliaUnited StatesNew ZealandUnited KingdomCanadaSingaporeOtherI'm an MSP, MSSP, or reseller
Δ
Hypothesis-driven threat hunting tests a specific idea about attacker behavior against security evidence. Define the question, scope, time window, and expected evidence before searching, then investigate whether matches support the idea or have a legitimate explanation.
An investigation examines activity to establish what happened and what needs action. Threat hunting is a proactive form of investigation that searches for attacker activity existing detections may have missed. An alert or incident can prompt a hunt, and a hunt can uncover an incident requiring immediate response.
Choose one your team can apply consistently. PEAK supports hypothesis-driven, baseline, and model-assisted hunts. TaHiTI emphasizes the relationship between intelligence, hunting, and follow-up. ATT&CK helps describe behavior, while the Hunting Maturity Model helps plan capability improvements.
Duration depends on scope, data readiness, and the findings requiring investigation. A bounded search with prepared evidence can be brief; a hunt involving several systems or missing records can take longer. Set an effort limit and record unresolved questions instead of forcing a conclusion when time runs out.
Threat hunters need knowledge of attacker behavior, the systems being examined, and the evidence those systems produce. Query writing, analysis, and environmental context help connect events and test explanations. Clear documentation and a willingness to challenge the original assumption are equally important.
Yes. Start with a narrow, relevant question and an established procedure using available data. Set aside manageable time, record the outcome, and reuse successful methods. Managed support can provide additional capacity when daily investigations leave little time for hunting.
Threat Hunting Service
Retrospective Threat Hunting
AI Threat Hunting