Career path
Threat Hunting / Detection
What people in this area work on
Security tools only alert on what they have been told to look for. Threat hunting starts from the possibility that something slipped past them. A hunter writes a hypothesis, a testable idea about how an attacker might behave, and searches logs for evidence for or against it.
Detection engineering is the related work of writing and tuning the rules that produce alerts. A good rule catches the behavior it targets without burying analysts in false alarms, and it is tested against both suspicious and ordinary activity.
Both roles depend on knowing what normal activity looks like, writing precise searches, and being honest when the evidence is inconclusive.
Terms used on this page
- Hypothesis
- A specific, testable statement, such as “repeated failed logins were followed by a successful unauthorized login.”
- Query
- A search written in a log tool’s language to find matching records.
- Detection rule
- Saved logic that raises an alert whenever matching activity appears.
- Baseline
- A description of normal activity used for comparison.
- False positive
- An alert on harmless activity.
How the work flows
One piece of work, start to finish. Every step below is something you can practise in the starter project.
- HypothesisA testable idea about attacker behavior
- QuerySearch the logs that would show it
- CompareRule out ordinary explanations
- FindingsState what the evidence supports
- RuleTurn it into an alert that lasts
Examples of everyday tasks
- Write a hunt hypothesis based on a known attacker technique.
- Search authentication, process, or network logs for supporting evidence.
- Compare suspicious results with normal activity to rule out ordinary explanations.
- Draft or tune a detection rule and measure how often it fires.
- Document hunts so they can be repeated later.
Related job titles
- Threat hunter
- Detection engineer
These are career areas to explore, not a checklist. Some of these job titles usually require experience, and completing a starter project does not by itself make someone ready for them.
Starter project
Hunt for Suspicious Login Activity
Test the hypothesis that repeated failed logins may have been followed by unauthorized access by searching a public practice authentication dataset.
What you’ll use
- A public practice dataset that includes authentication (sign-in) events
- A tool that can filter and count records, such as a spreadsheet, Python, or a free log search tool
- A document to record your queries and findings
Resources to start with
- Los Alamos National Laboratory: User-Computer Authentication Associations in Time (opens in a new tab)
A public dataset of anonymized authentication events from a real enterprise network.
- Security Datasets (Open Threat Research Forge) (opens in a new tab)
Recorded logs from simulated attacks, useful for testing hunts and detection rules.
- Sigma (opens in a new tab)
An open format for writing detection rules that can be shared across log tools.
More projects for this path
Each one comes with the framework to follow, five name ideas and a walkthrough for publishing it on GitHub.
- Failed-Login Hunt
Search a public authentication dataset for password spraying and prove or disprove it.
- Beaconing Traffic Hunt
Look for machines phoning home on a schedule inside public network logs.
- Sigma Rule Pack
Write five detection rules and test each against attack and normal data.
Project walkthrough
- Write the hypothesis: repeated failed logins may have been followed by unauthorized access.
- Read the dataset’s documentation so you know what each field means, such as time, account, source, and result.
- Find accounts or sources with bursts of failed logins, and save the query you used.
- Check whether a successful login from the same source, or to the same account, followed soon after.
- Examine timing, accounts, and source information, and look for ordinary explanations such as a mistyped password or a service using an expired password.
- State what the evidence supports and what it does not. A failed-login pattern alone does not prove compromise.
- If the pattern holds up, draft a detection rule that describes when an alert should fire.
What to publish
- The hypothesis
- Each search query, with a sentence on what it looks for
- The evidence you found, such as tables or screenshots
- Findings, alternative explanations, and limitations
- Any proposed detection rule
Optional extension
Test the rule against both suspicious and ordinary activity.
Example résumé bullet
Numbers are what make a bullet worth reading, so count them while you work: how much data you searched, how many findings you fixed, how many tests you added. Every figure should be one a reader can find in your report. Write the line after the work is done, and leave out impact or experience you cannot show.
Numbers to record while you work
| Count | Where it comes from |
|---|---|
| Records searched | dataset size and date range |
| Queries written | the query list in the report |
| Accounts or sources flagged | findings table |
| Rule results on normal activity | baseline test |
Project name | tools, datasets and frameworks | link
BeaconPython, pandas, Sigma, MITRE ATT&CK, LANL authentication datasetGitHub
Hunted 1.4 million authentication records for password spraying; wrote 6 queries that isolated 1 source trying 3 passwords across 400 accounts, and drafted a detection rule that fired 0 times on a normal-day baseline.
Give the project a name of its own: “Beacon” is an example, not a label to copy. List the tools, datasets and frameworks you actually used, since several relevant ones show more than a single tool does. Hyperlink the last part to your published repository or report.
A day on the job
Try the work before you try the project
A short walkthrough of a realistic situation. Nothing is scored: each choice explains what would happen, so you can talk through the reasoning later.
Intel says a group is spraying passwords at universities
A published report says attackers try a handful of common passwords across many accounts. Nothing has alerted. Check whether it happened here.
What is your hypothesis?
Your first query returns 60,000 failed logins. What now?
Choose above to continue.
One source tried 3 passwords across 400 accounts and then signed in successfully once. What do you do with it?
Choose above to continue.
Turn your project into a portfolio piece
A project becomes easier to evaluate when someone can understand what you did, inspect the evidence, and follow your reasoning.
Create a short report, GitHub README, or portfolio page. A clear two-to-four-page report is a useful starting point, not a strict requirement.
Include:
- Goal: What question or problem did you investigate?
- Environment: What tools, practice data, or systems did you use?
- Your work: What did you personally do, and why?
- Evidence: Include useful screenshots, queries, code, or test results.
- Findings: What did you discover? What remains uncertain?
- Fix or recommendation: What should change, and did you test it?
- Sources and limitations: Credit datasets and guides. Clearly identify simulated work.
Use sample or redacted information in the public version.
Publish the report somewhere accessible without requesting permission, and check the link before putting it on a résumé.
Put numbers in it
Count as you work, and put the figures in the report: records searched, findings confirmed, tests added, checks failing before and after. A reviewer can check every one of them against your evidence, which is exactly why they are worth including. Leave out business impact you cannot show.
Name it, then show your tools
A résumé line works best in three parts: your project’s own name, the tools and frameworks you used, and a link to the work. “Role-Based Access Lab” reads like a class exercise. A name plus a tool list tells a reviewer what you can actually work with, and every tool, dataset or framework you list honestly is another thing an interviewer can ask you about.
Project name | tools, datasets and frameworks | link
- Role-Based Access LabTurnstile | Keycloak, RBAC design, NIST SP 800-63, Docker | GitHub
- Login HuntBeacon | Python, pandas, Sigma, MITRE ATT&CK | GitHub
- Cloud ProjectBedrock | Terraform, Checkov, AWS IAM, CIS Benchmarks | GitHub
Why link a report?
Your résumé gives a short description of the project. The linked report lets a reviewer inspect your work and gives you concrete evidence and decisions to discuss during an interview.
Not every recruiter will open it, but it makes your work available for review.
BeaconPython, pandas, Sigma, MITRE ATT&CK, LANL authentication datasetGitHub
Investigated a public authentication-log dataset for repeated failed logins followed by successful access; documented search queries, supporting evidence, and limitations in a reproducible hunt report.
Hyperlink the last part to the published work, so “GitHub” or “Project Report” opens your repository or report. Check the link before you send the résumé.
Preview the write-up template
# Project title > Practice project. Describe the simulated scenario, practice data, or lab used. ## Goal What question or problem did you investigate? ## Environment What tools, practice data, or systems did you use? Link datasets and guides. ## My work What did you personally do, and why? ## Evidence Screenshots, queries, code, or test results. Use sample or redacted information only. ## Findings What did you discover? The numbers behind it (records searched, findings confirmed, tests added). What remains uncertain? ## Fix or recommendation What should change, and did you test it? ## Sources and limitations - Datasets and guides used: - What was simulated: - Limitations: