Gains:
- Understand how threat hunting begins with a testable hypothesis, not an alarm, and how artificial intelligence helps in hypothesis generation and query drafting.
- Ability to apply that the contrary/rare signal highlighted by artificial intelligence does not automatically mean malicious intent, and that the hypothesis must be confirmed with raw evidence.
- Ability to verify the MITER ATT&CK technical numbers and event IDs given by artificial intelligence with the official source and eliminate fabricated technical details
Classic security monitoring works with the logic of "wait for the alarm, look when it comes". But the most dangerous attackers try not to raise alarms: they use legitimate tools (this is called “exploiting” — that is, abusing tools that already exist on the system, such as PowerShell, WMI), move slowly, and interfere with normal traffic. That's why threat hunting was born: without waiting for an alarm, "if there was a currently undetected attacker in my organization, where would he be?" Proactively searching for traces with the question: Threat hunting starts with a hypothesis, not an alarm.
Artificial intelligence is very useful in two places in threat hunting. The first is hypothesis generation: give an attack technique and ask "If this technique was used in my institution, on which logs and in what pattern would it leave a trace?" you can ask. The second is signal extraction: it can highlight the rare, outlier, "different from normal" in big data. But AI doesn't know what's normal for your organization and may fall into the trap of thinking a hypothesis is "proven." In threat hunting, AI is a mind partner and scanner; The hunter (analyst) decides whether the prey finds a real threat and whether this will be reported.
Steps of threat hunting
- Hypothesise. A concrete, testable sentence: "An attacker may be scanning the internal network during non-business hours with a compromised account." You can use AI for brainstorming here.
- Identify the data source. Which log proves/disproves the hypothesis? (For example, firewall and DNS logs for network scanning, identity logs for privilege escalation.)
- Design the query. The query that will search for the targeted pattern (SIEM query language, KQL, SQL-like). AI helps in drafting queries; but you review the query and run it.
- Extract the result. Filter the real signal from hundreds of lines output. Here AI does clustering and summarization.
- Confirm or refute. Confirm with raw evidence and context whether the trace found is truly malicious or innocent.
- Document the result and turn it into a determination. Convert the actual pattern found into a permanent detection rule; If the hypothesis failed, record that too (a negative result is also information).
Terms: TTP (Tactics, Techniques, Procedures — attacker's behavioral pattern). MITER ATT&CK is an enumerated and documented library of attacker techniques (e.g. T1078 “Valid Accounts”); It provides a common language in threat hunting. IOC (Indicator of Infringement — bad IP, hash, domain). White noise (whitelist/known-good) is normal behavior known to sacrifice prey.
Table of threat hunting approaches
Approach
starting point
Contribution of AI
Attention
Hypothesis based hunting
"If there was such an attacker..."
Hypothesis generation, pattern description
Hypothesis is not evidence
IOC based hunt
Known bad indicator
Matching IOCs to logs
Old/incorrect IOC misleads
TTP/ATT&CK based hunting
A technique (T-number)
Converting the technique to log pattern
Technique ≠ single pattern
Anomaly based hunting
Statistical deviation
Highlight the outlier
Contrarian ≠ bad faith
Stack frequency analysis
"What's the rarest?"
Finding the rare event
Rare ≠ dangerous
three mini cases
Case 1 — Finding the rare. A hunter might ask, "Which process on the internal network runs on the fewest computers but establishes the most network connections?" establishes his hypothesis. The AI highlights a pattern from the anonymized process-connection data: a process named svchost32.exe, seen on only 2 machines, is connecting to 340 different external addresses. The hunter examines this; It finds a malware that mimics the legitimate svchost.exe. AI filtered the rare; The hunter made the diagnosis and intervention.
Case 2 — The failed (but valuable) hunt. One hunter asked "could there be mass data downloading during non-business hours?" establishes his hypothesis; AI writes the relevant query draft. Result: 3 users downloaded at night, but all three of them are overseas office workers and work during business hours due to time zone differences. The hypothesis is refuted. The hunter documents this as a "negative result" and notes these 3 users as exceptions for future hunts. Even the unsuccessful hunt allowed us to get to know the institution better.
Case 3 — Contrived technical trap. A hunter asks AI "How do I look for the T1055 technique in my organization?" says. The AI writes a convincing query and assertion that “T1055 generates the following event ID”; but the event ID he gave is wrong and the model made up an ATT&CK sub-technique. Avcı opens the MITER ATT&CK record, confirms the technical description and real log sources, and corrects the incorrect event ID. Lesson: Verify every technical detail the AI gives (event ID, T-number, log field) with the official source.
Weak prompt / Strong prompt
Weak prompt:
Find out if there is an attacker on my network.
This claim is hypothesis-free, data-free, unlimited and unverifiable. AI produces a general or made-up list; it is of no use.
Powerful prompt:
Your role: assistant who gives ideas and outlines to the threat hunter. Don't decide, don't say "there is a threat". My hypothesis: "A compromised account may be scanning internal ports during non-business hours." Generate the following: (1) list the log sources that will prove and DISFUSE this hypothesis, (2) describe the concrete pattern to be searched (which fields, what thresholds), (3) write a draft of an example query and comment out each line, (4) write down which innocent explanations will be eliminated in the resulting result. Suggest the relevant MITER ATT&CK technique, but mark the T-number and event ID as "[must be verified from MITER]", don't make it up.
The strong claim starts with a concrete hypothesis, establishes the balance of evidence/refutation, has the query explained, and leaves the technical detail to verification.
Copiable prompt templates
HYPOTHESIS GENERATION TEMPLATEFor my institution [entity: e.g. Generate testable threat hunting hypotheses in the context of [Active Directory / cloud / endpoint]5. For each hypothesis: (1) which attacker behavior it targets, (2) which log source will provide evidence/refutation, (3) the expected pattern. Make testable sentences, not general ones.
TECHNIQUE PATTERN PATTERN I will search for the following attack technique in my [technique name] institution. Generate: (1) log areas where the technique typically leaves its mark, (2) concrete patterns and thresholds to look for, (3) innocent (false positive) situations that could trigger this pattern. Offer relevantMITRE ATT&CK T-number but with "[Must be verified from MITER]" flag; do not give fabricated event ID/number.
QUERY DRAFT TEMPLATEWrite a [SIEM/KQL/SQL] query draft that looks for the following pattern: [pattern description].Comment each line, explain which field you are filtering and why, and mark performance risks. I'll review the query and run it; don't assume you'll run it. Leave the field names marked "[correct to schema]" according to the scheme I know.
RESULT ELIMINATING TEMPLATEThe result of my hunt yielded the following lines (anonymous): [paste]. Group them, and for each group write (1) a malicious scenario, (2) at least 2 innocent explanations, and (3) additional evidence to look for to differentiate. Decision making; Don't let me separate you. Mark "[no basis]" for a claim that has no evidence.
Common mistakes
- Hunting without hypotheses. Saying “find something” pushes the AI to guess and make up; The hunt begins with a concrete, testable sentence.
- Mistaking a hypothesis for evidence. The hunt tests a possibility; The trace found is not a "threat" until it is confirmed by raw evidence.
- Automatically considering the contrary as bad. The rare/outlier is often innocent (maintenance, new software, one-off job); Sift with context.
- Not verifying technical detail. AI can match event ID, T-number and log field; Confirm with MITER ATT&CK and product documentation.
- Throwing away the wasted catch. The negative outcome is also knowledge: gets to know the organization better, reducing future false positives; document.
Tip: A good threat hunting hypothesis should be “testable”: a concrete claim that may turn out to be true or false. "Is there anything bad in my network?" cannot be tested; “Did account X connect to more than 50 internal IPs during non-business hours?” can be tested.
Attention: Threat hunting is only done on systems you are authorized to do. Asking the AI to "probe" another organization, a person, or a network for which you do not have permission is an attempt to gain unauthorized access and is outside of this module.
In summary
Threat hunting is proactively searching for traces of a hidden attacker without waiting for an alarm, and it starts with a hypothesis, not an alarm. AI offers two powerful contributions in this process: generating testable hypotheses and query drafts, and filtering rare/outlier signals from big data. But AI does not know what is normal for your organization, it can make up technical details and fall into the trap of mistaking a hypothesis for evidence. So the hunt has six steps (hypothesis, data, query, extract, verify, document) and at each step the decision is up to the hunter. Contrarian ≠ bad, hypothesis ≠ evidence, technical detail given by AI ≠ correct; all confirmed by raw evidence and MITER ATT&CK.
Application task
Get 5 threat hunting hypotheses from AI with the “Hypothesis Generation” template for your own organization (or a sample environment). Choose the most testable, draft a query with the “Pattern Technique” and “Query Draft” templates, validate each row in the query and each suggested T-number in MITER ATT&CK. Write down the outcome (was the hypothesis confirmed, disproved, what did you learn) in a short hunt note.
checklist
- [ ] I began my hunt with a concrete, testable hypothesis.
- [ ] I have identified log sources that will both prove and disprove the hypothesis.
- [ ] I reviewed every line of the query draft and adapted it to my own schema.
- [ ] I verified the proposed MITER ATT&CK technique and event IDs with the official source.
- [ ] I confirmed each signal with raw evidence and context; I did not automatically consider the contrary as bad.
- [ ] I also documented the hypothesis that failed (the negative result is information).
- [ ] I only hunted on systems I was authorized to hunt.