You might enjoy investigating suspicious activity, but would you rather build the alerts that help uncover an attack or go looking for threats those alerts haven't detected?
That's one of the main differences between detection engineering and threat hunting.
Both are important parts of defensive cyber security. They involve understanding how attackers operate, examining security data, and identifying activity that could indicate a compromise.
But they approach the problem differently.
Detection engineering focuses on creating reliable ways to identify suspicious behaviour. Threat hunting focuses on proactively searching for evidence of threats that may already be present in an environment.
If you're choosing what to learn next, we explain how both disciplines work, the skills they require, and how to practice them through TryHackMe.
What Is Detection Engineering?
Detection engineering is the process of designing, building, testing, and maintaining security detections that identify potentially malicious activity.
A security detection is a rule or analytical method used to recognise activity that may indicate a threat.
For example, an organisation might want to identify suspicious commands running on employee workstations.
A detection engineer investigates what that activity looks like, determines which security data can reveal it, and develops a rule to identify relevant events.
That rule can then generate an alert for a security analyst to investigate.
The work involves several stages:
- Research: Understand the attacker behaviour or security problem the detection should address.
- Data collection: Identify which logs and security events can reveal that behaviour.
- Rule development: Write the logic that determines when the detection should match.
- Testing: Check whether the rule identifies suspicious activity without generating excessive irrelevant alerts.
- Maintenance: Improve the detection as attacker techniques, applications, and environments change.
Detection engineers also document what their rules can detect and where visibility is limited. A good detection gives analysts useful evidence to investigate. It doesn't necessarily prove that an attack has occurred.
For a deeper explanation, see TryHackMe's guide to how detection engineering works.
What Is Threat Hunting?
Threat hunting is the proactive process of searching security data for evidence of malicious activity that existing alerts may have missed.
Rather than beginning with an alert, a threat hunter often starts with an investigative question.
That question might come from a known attacker technique, recent threat intelligence, an incident, or an unusual pattern of activity.
For example, a hunter might ask:
Are there signs that an attacker has used legitimate Windows administration tools to investigate systems inside our network?
They would then examine relevant security logs, search for suspicious activity, and investigate any findings.
This is often called hypothesis-driven threat hunting.
A hypothesis is a specific idea that can be tested against evidence. In threat hunting, it gives the investigation direction and helps determine which data to examine.
A typical hunt involves:
- Developing a hypothesis about possible malicious activity.
- Identifying the systems and security data needed to test it.
- Searching the available evidence for relevant behaviour.
- Investigating suspicious results and checking legitimate explanations.
- Documenting findings, limitations, and recommended follow-up actions.
A hunt might uncover an active threat, identify a gap in monitoring, or find no supporting evidence within the data examined.
Each outcome can be useful when the investigation is well documented.
Detection Engineering vs Threat Hunting: Key Differences
The biggest difference is what each discipline aims to achieve.
Detection engineers create repeatable ways to identify suspicious activity. Threat hunters investigate whether a particular threat or behaviour is occurring.
The roles overlap considerably.
A threat hunter might discover suspicious behaviour that becomes the basis for a new detection rule. A detection engineer may investigate real security events to understand which behaviour is worth detecting.
In smaller security teams, one practitioner may handle both responsibilities.
Explore both disciplines hands-on and discover where you want to take your blue team career next.
How Would Both Roles Investigate the Same Threat?
Imagine a company suspects that an attacker may be using legitimate Windows commands to gather information about compromised computers.
This activity is known as reconnaissance, the process of collecting information about systems, accounts, or an environment.
Attackers may use reconnaissance to understand what resources are available and decide what to target next.
For this example, consider three Windows commands:
These commands have legitimate administrative uses. Their presence alone does not establish malicious activity.
However, an unusual combination of commands, executed under unexpected circumstances, might warrant investigation.
How a Threat Hunter Would Approach It
The threat hunter starts with a hypothesis:
An attacker may be using Windows administration commands to gather information after gaining access to a workstation.
They examine process execution logs across the relevant systems.
A process is a running instance of a program. Process execution logs can show which programs ran, the accounts associated with them, and sometimes the commands supplied when they started.
The hunter might investigate which accounts executed the commands, when they ran, and what launched them. The program that launches another process is called the parent process. This relationship can provide useful context about how an activity began.
If several reconnaissance commands appear under an unexpected parent process, the hunter could investigate related authentication or network activity.
They would then assess whether the evidence suggests legitimate administration or possible compromise.
The outcome is an investigation report explaining the findings and any recommended next steps.
How a Detection Engineer Would Approach It
The detection engineer considers how the behaviour could be recognised automatically.
They might develop a detection that looks for a combination of reconnaissance commands running within a defined time period, together with relevant process or account context.
The engineer then tests the rule using examples of suspicious activity and legitimate administrative work. The goal is to find logic that generates useful alerts without overwhelming analysts. They also consider what happens when the alert fires.
Will the analyst know which account executed the commands? Can they identify the affected workstation and retrieve the supporting events?
The outcome is a tested detection with enough context for investigation.
A threat hunt can uncover suspicious patterns worth monitoring.
Detection engineering can turn those patterns into repeatable security alerts.
What Skills Do You Need Before Learning Either Discipline?
Both disciplines build on core SOC and investigation skills.
A Security Operations Centre (SOC) is a team or function responsible for monitoring an organisation's security environment, investigating threats, and coordinating responses.
Before specialising, become comfortable with the following areas.
Log Analysis and Security Monitoring
A log is a record of activity generated by a system, application, or security tool.
Logs can record events such as user authentication, process execution, network connections, and configuration changes.
Log analysis means examining those records to understand what happened and identify activity that might require investigation.
The broader term telemetry refers to data collected about system activity and behaviour.
Logs are one common form of security telemetry. You'll use this information when developing detections or investigating threats.
SIEM Tools and Querying
A Security Information and Event Management (SIEM) platform collects and helps analyse security data from different sources.
SOC analysts use SIEM platforms to search events, investigate alerts, and identify patterns across systems.
A query is a search instruction that tells the platform which records or conditions to retrieve.
For example, you might write a query to find all failed login attempts associated with a particular account during a given period.
Being able to query security data is essential for both disciplines.
TryHackMe's Elastic: Query Languages room can help you develop more advanced searching skills.
Operating Systems and Attacker Techniques
You should understand how Windows and other common operating systems work.
Focus on processes, user accounts, permissions, authentication, and system activity.
You'll also benefit from learning common attacker techniques, such as credential theft, persistence, and lateral movement.
Persistence describes methods attackers use to maintain access to a system.
Lateral movement occurs when an attacker moves from one system or resource to another within an environment.
Understanding these techniques helps you recognise the behaviour detections and hunts are designed to uncover.
If you're new to defensive security, start with TryHackMe's SOC Level 1 learning path. It develops foundational skills in alert triage, log analysis, and security investigations.
Alert triage is the process of reviewing security alerts to determine which require investigation and how urgently they should be handled.
Should You Learn Detection Engineering or Threat Hunting First?
Your choice should depend on your current skills and which type of work you want to practice. Both are valuable, and learning one can make you better at the other.
Choose Detection Engineering First If You Want to Build Better Alerts
Detection engineering is a good starting point if you already understand basic SOC investigations and enjoy developing technical solutions.
You might find it particularly interesting if you've investigated alerts and wondered why they triggered or how they could be improved.
You'll learn how to translate attacker behaviour into detection logic, test rules, and refine them as new information becomes available.
Where to start: TryHackMe's Intro to Detection Engineering introduces the detection engineering lifecycle and the challenges involved in creating useful security detections.
It recommends familiarity with SIEMs, SOC alerts, and querying. As you progress, aim to understand why a detection works, which activity it catches, and what it might miss.
Choose Threat Hunting First If You Enjoy Investigating the Unknown
Threat hunting may suit you if you're comfortable examining security data and enjoy deciding where an investigation should go next.
Instead of responding to an existing alert, you'll practise asking investigative questions and searching for evidence.
That requires curiosity, structured reasoning, and an understanding of how legitimate activity can resemble attacker behaviour.
Where to start: TryHackMe's Threat Hunting: Introduction covers the foundational concepts and approaches used in threat hunting.
It expects basic security knowledge, familiarity with Windows event logs, and an understanding of attack techniques.
As you practise, focus on developing clear hypotheses and explaining what the available evidence supports.
How to Practice Detection Engineering and Threat Hunting on TryHackMe
Once you've learned the foundations, practical exercises can help you understand which discipline you enjoy more.
Try one exercise from each area and compare the work you produce.
Detection Engineering Exercise: Build and Test a Rule
TryHackMe's Detection Rules Development room covers practical detection creation and tuning.
Its listed prerequisites include Intro to Detection Engineering, Elastic querying, and Windows Security Monitoring.
Alongside the room's tasks, practise documenting:
- The behaviour your detection is designed to identify.
- The logs and fields required to identify it.
- The rule logic and examples used during testing.
- Any legitimate activity that generates an alert.
- The information an analyst would need to investigate a match.
One important concept you'll encounter is a false positive.
A false positive occurs when a detection identifies activity as suspicious even though the activity is actually benign.
For example, a legitimate administrator running reconnaissance commands might trigger a rule designed to identify suspicious system discovery.
Detection engineers evaluate these results and refine their rules without unnecessarily hiding malicious behaviour.
Threat Hunting Exercise: Investigate a Possible Compromise
TryHackMe's Threat Hunting: Foothold lets you investigate evidence associated with potential attacker activity.
The room uses security logs and network data to explore signs of compromise.
A foothold is an initial level of access an attacker establishes within a system or network, which may allow further activity.
As you work through the exercise, practice turning the investigation into a short report. Include your original hypothesis, the systems and time period examined, the searches you performed, and the evidence supporting your findings.
Explain what you would investigate next if additional information became available. This helps you develop the reasoning and documentation skills used in real threat hunting work.
Explore both disciplines hands-on and discover where you want to take your blue team career next.
How Do You Measure Your Progress?
Detection engineering and threat hunting have different outcomes, so it makes sense to evaluate them differently.
Measuring Detection Engineering Skills
Start by testing whether your detection identifies the activity it was designed to find.
You'll encounter several terms:
- True positive: The detection correctly identifies the activity it was intended to flag.
- False positive: The detection flags activity that should not be classified as positive under the test's criteria.
- False negative: The detection misses activity it was expected to identify.
- Precision: The proportion of detection matches that are correct positive results.
- Recall: The proportion of all known positive examples that the detection successfully identifies.
For example, consider a hypothetical dataset containing 100 labelled events, of which 10 are malicious.
Your detection flags 20 events. Eight of those are malicious, while 12 are benign.
That means the rule correctly identified eight malicious events but missed two.
In this example, the detection identifies most of the known malicious events, but many of its alerts are associated with benign activity.
That gives you specific cases to investigate when improving the rule.
These calculations describe a labelled test dataset. In a real SOC, you may not know every malicious event that occurred, so production recall is much harder to establish reliably.
Also remember that a behaviour-based rule may intentionally flag legitimate activity for investigation. Whether a match counts as a false positive depends on the detection's defined objective.
Measuring Threat Hunting Skills
Threat hunting is less about producing alerts and more about conducting a useful investigation.
Evaluate whether you can:
- Develop a clear, testable hypothesis.
- Identify the evidence needed to investigate it.
- Query relevant data and follow promising leads.
- Consider legitimate explanations for suspicious activity.
- Explain your findings and the limits of your investigation.
A hunt doesn't have to uncover an attacker to be worthwhile. For example, you might discover that important authentication events aren't being collected.
That visibility gap is a useful finding because it identifies a limitation in the organisation's ability to investigate suspicious activity.
The important thing is to explain what you searched, what you found, and which conclusions the evidence supports.
How Do Detection Engineering and Threat Hunting Support Incident Response?
Both disciplines contribute to how organisations find and respond to threats. Detection engineering helps create alerts that bring suspicious behaviour to the SOC's attention.
Threat hunting can identify activity that existing detections miss and provide investigative leads for incident responders.
Incident response is the process of investigating a security incident, limiting its impact, removing the threat, and restoring affected systems.
For example, a hunt might uncover evidence of suspicious account access. The SOC or incident response team could then investigate the broader compromise.
The findings might also reveal that an existing detection failed to identify the activity, giving detection engineers an opportunity to improve monitoring.
TryHackMe's SOC Level 2 learning path provides opportunities to develop these disciplines alongside more advanced security investigations.
If you're interested in investigating how attacks unfold on Windows systems, the Windows Incident Response & Forensics path offers further practice with forensic evidence, attacker activity, and incident reconstruction.
That combination can help you understand how detection, hunting, and incident response fit together.
Start With the Cyber Security Skills You Want to Develop
Detection engineering and threat hunting are closely connected, but each develops a different part of your defensive security abilities.
If you enjoy writing queries, improving alerts, and developing repeatable ways to identify threats, detection engineering is a natural next step.
If you prefer following evidence, investigating unfamiliar activity, and asking questions that existing alerts haven't answered, threat hunting may be the better place to start.
TryHackMe gives you a practical way to explore both.
Start with Intro to Detection Engineering or Threat Hunting: Introduction, then continue into the SOC Level 2 learning path as you develop your skills.
Explore both disciplines hands-on and discover where you want to take your blue team career next.
Ayomide Joseph A.
