Detection engineering is both a role and an activity. It’s the discipline of building and maintaining the logic that identifies malicious or risky behavior within your organization. It’s where security analysis meets software engineering, turning raw logs and telemetry into actionable detections that defenders can rely on.

Detection engineers bridge the gaps between security operations, threat intelligence, and infrastructure. They understand how attackers operate, how defenders respond, and how systems generate the data that supports those detections. A well-built detection can mean the difference between an alert that matters and one that drowns in noise.

Precision and Recall: The Balancing Act

Every detection faces a trade-off between precision and recall.

Precision measures how much you can trust your alerts: of everything that fired, how much was actually malicious? High precision = fewer false positives = analysts trust the tool.

Recall measures how much you’re catching: of everything malicious that happened, how much did you detect? High recall = fewer blind spots = threats don’t slip through.

Detection engineering lives in the tension between the two: too much precision risks missing subtle threats; too much recall floods analysts with false positives. The goal is calibration through testing, iteration, and feedback.

Core Components of Detection Engineering

1. Scoping and Prioritization

Start with intent. What are you trying to detect, and why? Define the threats, behaviors, or assets that matter most, then align your work with frameworks such as MITRE ATT&CK®. Evaluate risk and value to determine which detections provide the highest impact for the effort required. Prioritize based on business importance and available telemetry.

2. Data and Telemetry

Great detections rely on great data. Keep inventory of your logs. Validate that each contains the data you need. Normalize and enrich your logs so detections remain consistent across tools and environments. Understanding how logs are generated is essential to writing logic that fits your environment.

3. Detection Logic Development

This is where hypothesis meets code. Write queries or rules that detect behaviors, not just static indicators. Combine multiple approaches:

• Signatures for known indicators of compromise (IoCs)
• Behavioral logic for Tactics, Techniques, and Procedures (TTPs) and patterns
• Anomaly models for statistical outliers

4. Testing and Validation

Use adversary emulations or frameworks like Atomic Red Team to verify that your detections actually fire and your logging is working. Measure quality through precision, recall, and additional factors like confidence (how certain you are it’s malicious) and criticality (how severe the impact would be).

5. Deployment and Tuning

Monitor performance, including trigger frequency, false positive rates, and analyst response time. Detection engineering is iterative and ongoing, not “write once and done.”

6. Documentation and Knowledge Transfer

Good detections come with context. Record what the detection looks for, why it matters, what data it uses, and how it was tested. Version control your rules using Git and promote collaboration so analysts, hunters, and engineers can learn from one another. Playbooks and detection libraries ensure institutional knowledge does not disappear when staff change roles.

7. Metrics and Continuous Improvement

Track measurable outcomes such as coverage across ATT&CK® techniques, number of validated detections, false positive rates, and mean time to detect. Regularly retire stale detections, update ones that drift, and automate validation wherever possible. Detection-as-Code practices keep everything maintainable and scalable.

Building the Skillset

Detection engineering requires a strong foundation in logging, security tooling, and incident response. You should understand when it’s best to detect, when to block, and how to use data sources effectively.

Whether you’re building your first rule or managing hundreds, the mindset remains the same: test everything, learn constantly, and make each detection better than the last.

Get Started

Explore resources like:

detectionengineering.net and SigmaHQ.

Follow community leaders like:

Zack Allen (Detection Engineering Weekly) and Haider Dost (Threat Detection Maturity Framework).

Study detections and see how others approach logic design at:

research.splunk.com

Read:

Practical Threat Detection Engineering.

For more resources check out:

https://bit.ly/notlogic

Here’s a counterintuitive truth: the ultimate goal of threat hunting isn’t to find more security incidents—it’s to drive continuous improvement across your entire security program. We’re not hunting merely to find present bad; we’re hunting to decrease the probability of future bad.

Think of it like debugging. You don’t debug just to find bugs—you debug to build better software. Each bug you find teaches you something about your system, improves your testing, and makes future bugs less likely. Threat hunting works the same way.

The Cyclical Nature of Threat Hunting

Every threat hunting framework can be thought of as a cycle that improves with every revolution.

Step 1: Determine Your Focus

The biggest challenge in threat hunting? Answering this question: “Where do we even start?” You can’t just randomly poke around in logs hoping to find something interesting. You need a method to focus your efforts.

The good news is that there are several effective approaches, and you don’t have to pick just one. In fact, most mature programs blend approaches over time.

Hypothesis-driven hunting starts with an educated guess, perhaps informed by the latest threat intelligence. Maybe something like, “I bet adversaries are using scheduled tasks for persistence on our web servers.”

Baseline hunting flips the question entirely: instead of rooting around for specific threats, you map what “normal” looks like in your environment, then investigate anything that doesn’t fit the pattern.

Statistical analysis tools like RITA let you approach those patterns from yet another angle. They surface statistically weird behaviors and connections, giving you a prioritized list of anomalies to consider and maybe investigate.

Machine learning models can highlight specific events that deviate from learned baselines, essentially saying “start here” with confidence scores attached.

Step 2: Investigation

The real detective work happens here. Investigation is iterative and rarely linear. You start broad, progressively narrow your focus by filtering out known-good activity, and follow interesting patterns wherever they lead. One scheduled task leads to a user account, which leads to authentication logs, which leads to source IPs, which leads to ... you get it.

The “art” is knowing which threads to pull and which to drop. Something can be technically anomalous but contextually benign, like a DBA running weird queries at 2 AM because production is on fire.

Step 3: Discovery and Analysis

Eventually you reach a conclusion. Maybe you found a threat. Awesome! Now hand it to incident response.

But maybe, or most likely in fact, you found nothing…

Here’s the critical mindset shift: finding nothing isn’t failure. It’s validation—discovery of a different kind, even. A thorough hunt might confirm that your defenses are working and that an attack isn’t happening (win!). Or it might reveal that a detection you thought existed doesn’t, or that it’s misconfigured and wouldn’t fire even if the attack happened (also a win because now you know what to fix).

Approached with this mindset, any outcome is a win, and every hunt ultimately makes you more secure.

Step 4: Knowledge Refinement and Improvement

This is where threat hunting transforms from investigation into force multiplication. Everything you’ve learned feeds back into your security program:

• Create detection rules so you don’t have to manually hunt for the same thing again.
• Document baselines about normal behavior in your environment.
• Share knowledge with your team and the wider community (Document!).
• Generate new hypotheses for the next hunt (Back to Step 1...).
• Close visibility gaps you discovered.
• Measure and communicate your program’s value.

This phase is what makes hunting a continuous improvement engine. Each excursion expands detection coverage, deepens environmental knowledge, sharpens hunting skills, and strengthens overall security posture.

The Self-Improving Loop

The real power of this hunting “loop” is its cumulative nature. Your first few hunts might feel slow and uncertain. But knowledge accumulates. Patterns become obvious. Investigation approaches become routine. Organizations committed to sustained hunting programs often hit critical mass around 12–18 months, where value accelerates dramatically.

Remember: You’re not just looking for today’s threats. You’re building tomorrow’s defenses. Every rotation improves your skills, the program, and the rotations themselves. That’s the threat hunting flywheel.

While "digital forensics" and "incident response" often appear together (as in the acronym "DFIR"), they represent two distinct disciplines.

What's in a Name?

The American Heritage Dictionary defines forensics as "The use of science and technology to investigate and establish facts in criminal or civil courts of law."

Contrast this with IBM's definition of incident response: "Incident response [...] refers to an organization's processes and technologies for detecting and responding to cyberthreats, security breaches or cyberattacks." Note the absence of any reference to legal proceedings—it simply describes the process by which an organization detects, halts, and recovers from an incident.

Legal Considerations

Although most incidents never end up in court, all should be treated as if they might.

Taking the proper steps before, during, and after response ensures that any data collected can be admissible as evidence.

It's important to know the rules of evidence for relevant jurisdictions. Global corporations should consider each jurisdiction they have locations in when developing standard operating procedures (SOPs). Always include legal counsel when developing your organization's SOPs.

Data Preservation

A common rule for digital evidence is the retention of data in its "original state." This is accomplished by using validated hardware and software to create an exact bit-for-bit copy of a piece of digital media. Yet during incident response, it is rare that full forensic images are created—typically, only a small subset of data is collected from victim devices for analysis. Before any action is taken, consult legal advisors to decide whether to collect full forensic images.

A good practice is to create a folder for the original data, generate and document a hash of its contents, and then create a working copy in a separate folder. Only perform analysis on the working copies of your data to preserve the integrity of the original data.

Documentation

Documentation is critical when handling potential evidence. A chain of custody (CoC) records details about what the data is, where it came from, who collected it, whom it was transferred to, a brief description of what was done to it, and so forth.

The National Institute of Standards and Technology (NIST) provides a sample CoC here:

https://www.nist.gov/document/sample-chain-custody-formdocx

Each person working with the data must keep detailed notes: record dates, times, and any actions taken. Binary files often need to be parsed by special tools to make their data human-readable—include any tool names and versions. The same should be done with human-readable data, such as text-based log files. While you likely don't need to document the version of Excel used to read a log file, if you added a column to show UTC date/time stamps in local time, that is worth noting.

The gold standard for documentation is this: notes should be detailed enough that someone with a similar background can recreate your steps and produce the same results.

This is the scientific method part of digital forensics. Processes need to be repeatable and generate the same results.

Tool Validation Procedures

Before an incident occurs, verify that your hardware and software are working. Test write blockers to ensure they do not alter the evidentiary media. Validate that your forensic software functions correctly (it's not unheard of for new versions to report the wrong date/time stamps when parsing binary data).

While there is no set standard for validation processes, some guidelines exist to help you develop validation SOPs.

Validation SOPs guidelines:

NIST: https://www.dhs.gov/science-and-technology/nist-cftt-reports

SWGDE: http://cet4861.pbworks.com/w/file/fetch/120024474/4861.2014-09-05_SWGDE_Recommended_Guidelines_for_Validation_Testing_V2-0.pdf

Additional Considerations for Incident Handling

When managing incidents, also consider:

• What are the data retention policies of your Endpoint Detection and Response (EDR) tools?
• How is your cloud data preserved?
• Who has access to sensitive or personal data?

These factors often depend on your license agreement with providers. Make sure data can be maintained in a secure, long-term manner, as it can take years until an incident makes it into the courtroom. Implement processes to export incident data from systems and services while preserving integrity and meeting long-term storage requirements that protect its availability and confidentiality. Access to confidential information must always be managed carefully.

Remember: Involve your legal team, validate your tools, work from copies (never original data), document everything meticulously, and maintain chain of custody.

Here's the deal: when adversaries compromise your environment, they don't float around in abstract network flows. They execute on actual systems. They touch files, spawn processes, and mess with registries.

The premise of endpoint threat hunting is simple: if an adversary wants to accomplish anything meaningful, they must eventually execute code on a host. That execution leaves traces.

The Endpoint Advantage: Depth and Context

Endpoint hunting gives you deep, contextual visibility into adversary behavior. You're not inferring what happened from network packets; you're seeing exactly what processes ran, which files were touched, and what registry keys got modified.

Consider credential theft. An adversary running Mimikatz operates entirely in host memory and local file systems. Network detection might catch the tool's delivery, but it won't see the actual credential extraction. Endpoint telemetry captures the process execution, memory access patterns, and specific API calls—providing detection plus meaningful context.

The endpoint also provides crucial user and process context that network data lacks. Suspicious PowerShell execution? Endpoint telemetry tells you which user ran it, what parent process spawned it, what command-line arguments were used, and what it created. This process tree visibility is fundamental to understanding adversary techniques and distinguishing malicious from legitimate activity.

Your Visibility Stack

Effective endpoint hunting requires comprehensive telemetry:

Sysmon is remarkably powerful. This free Microsoft utility generates detailed logs covering process creation, network connections, file changes, registry modifications, and more. When properly configured, it can provide serious, high-fidelity visibility without the EDR price tag.

PowerShell Script Block Logging captures actual commands executed in PowerShell sessions. Given how heavily adversaries rely on PowerShell, these logs are invaluable.

Windows Event Logs provide foundational telemetry. Universally available, they often contain the first indicators that something's off.

Velociraptor brings digital forensics and incident response to scale. This open-source tool lets you hunt across thousands of endpoints simultaneously, collecting artifacts and running detection queries in real-time.

Wazuh provides centralized collection and analysis of endpoint telemetry. While not as feature-rich as a commercial EDR, it aggregates logs from multiple sources, applies detection rules, and gives you a hunting interface across your environment.

EDR platforms have their place, but you don't need expensive tools to start hunting. OS-native telemetry and open-source tools get you remarkably far.

What Endpoint Hunting Misses

External C2 communications present major challenges for endpoint detections. While endpoint tools capture network connections made by processes, they don't deeply inspect connection content. An adversary using encrypted C2 channels generates connections that endpoint logs record, but the malicious nature is often only apparent through network traffic analysis.

Lateral movement patterns across your environment are tough from a purely endpoint perspective. Network monitoring provides this visibility more naturally.

Living Off the Land: The Real Challenge

Modern adversaries "live off the land," using legitimate system tools (PowerShell, WMI, certutil) for malicious purposes. These processes are inherently legitimate; that is, endpoint telemetry shows their execution, but distinguishing malicious from benign requires understanding normal patterns and identifying behavioral anomalies.

This is where endpoint hunting earns its keep. Automated signatures struggle with legitimate tools. But hunters who understand both legitimate uses and adversary abuse patterns can spot differences. Legitimate admins rarely use certutil to download files. PowerShell downloading from pastebin is unusual.

The endpoint's rich context (command-line parameters, parent processes, user context) provides the clues needed to distinguish malicious from benign.

The Endpoint Imperative

Despite limitations, endpoint threat hunting remains essential. Adversaries must execute code, access files, and modify systems. These actions occur on endpoints and generate endpoint artifacts.

The depth that endpoint data provides is unmatched. For detecting privilege escalation, credential theft, defense evasion, and persistence, endpoint hunting isn't just useful—it's necessary. These tactics involve no network activity that distinguishes them from legitimate behavior.

The question isn't whether to invest in endpoint threat hunting, but how comprehensively you can implement it. Because in the assumed breach world we inhabit, adversaries are executing on your systems right now. Endpoint hunting is how you find them.

Security, Orchestration, Automation, and Response (SOAR) is still a foreign concept to some but has rapidly evolved into a necessity for high-performing SOCs. SOCs without a SOAR — or without meaningful automation — will struggle with manual repetition, duplicate alerts, and slow response times as they scale. With SOAR, many of these problems can be addressed or reduced.

While SOAR isn’t a “silver bullet” by any means, the operational impacts are real because of the power it gives a SOC to optimize workflows, centralize security alert management, and minimize threat response time (or mean time to resolution). According to the Ponemon Institute, organizations can receive on average upwards of 17,000 malware alerts per week. The BHIS Active SOC reduced overall ticket volume by roughly 60% through intelligent alert grouping — consolidating related signals into single cases instead of working them as individual alerts.

How SOAR Works

To understand how this is possible, we need to discuss what SOAR is and how it works. A SOAR is a platform specialized primarily around security use cases. This platform serves as a centralized hub for data enrichment, integrations, and response actions, all of which take place in the context of “playbooks.” Think of a playbook as a flowchart, where each step performs a specific operation.

At the top of the flowchart, data (let’s say an EDR alert) initially enters the playbook. As it continues, decision points control the directional flow, API requests gather additional data or perform actions, and finally, there is some sort of output. So, a SOAR is really a technology—a curated set of tools and processes that work together to automate what can be wisely automated so as to serve as a happy medium between total manual management and total automation to maximize a SOC team’s ability to respond quickly and appropriately despite the problems and time constraints that the team encounters due to sheer volume.

Real-World Application

Consider a real-world example: Suppose that a device triggers a low-confidence EDR alert. Since it’s low-confidence, the EDR doesn’t take any action and sends it to the SOAR. The SOAR makes an API call out to VirusTotal (a service for detecting malware) with the indicators of compromise (IOCs) of the alert. If the IOCs return as malicious, the SOAR reaches back to the EDR, which in turn, isolates the host.

Now let’s say that this EDR alert fired 100 times, each on a different signature, all on the same host. Let’s also say that network detections for Command and Control also started firing related to that user. With a SOAR, all of those disparate signals could be condensed into one singular Case, rather than a number of individual alerts. Using logic within your SOAR playbooks, you could group all these events together based on numerous field values, going a layer deeper than you normally could with a SIEM, which usually just allows for the suppression of duplicates.

Challenges of Implementing SOAR

Now that you understand the potential power of a SOAR, you might be asking, “Hayden, why isn’t everyone using a SOAR then?” There are a few good reasons for that:

1. A high price tag: While some offerings are maybe tens of thousands a year, some of the larger enterprise offerings could run you hundreds of thousands a year just to purchase the product.
2. Required expertise: A SOAR is a very powerful, but very delicate, tool. Used correctly, it could do the work of several FTEs for your team; used incorrectly, at best it may not work as you want, and at worst it could cause runaway scenarios of automated containment or remediation. Having qualified SOAR engineers on your team is critical to extract the true value of the technology.
3. Implementation effort: Even the most expensive SOAR won’t solve all your problems immediately. Like any technology, it will require maintenance and updates, but with a SOAR, you also have to build many of the functions that you need or at least cater them to your use cases.

The Bottom Line

It may sound like I’m trying to convince you that a SOAR isn’t worth the effort, but that couldn’t be further from the truth. On the contrary, SOAR is becoming an expectation for any high-performing SOC, rather than a nice-to-have. As volume and complexity of alerts increase, a SOAR becomes essential to respond quickly and adequately to these alerts.

Resources

• Ponemon Institute Report (“The Cost of Malware Containment”): https://www.ponemon.org/local/upload/file/Damballa%20Malware%20Containment%20FINAL%203.pdf
• How to SOAR in a SOC (Antisyphon Webcast): https://www.youtube.com/watch?v=YJC9dSgAjGw
• Hands-On SOAR: https://www.tines.com/blog/practical-security-orchestration-automation/

Many people ask: At what point do I bring in law enforcement during a cyber incident? When should I get outside help such as another consulting firm to support incident response? The honest answer is simple: before you ever need them. The best time to build reinforcements is not during a crisis. It is now.

It’s the same idea as that old proverb: “The best time to plant a tree was 20 years ago. The second best time is now.” Cybersecurity works the same way. Incident response is messy, emotional, and chaotic. You don’t want to be flipping through your contacts for a random phone number when your domain controller is encrypted and your CEO is standing behind you asking for updates. You want relationships, people who already know you and are ready to help.

Build Your Network Before You Need It

Start with your own community. Get involved with organizations such as InfraGard and HTCIA. Attend local cybersecurity meetups, conferences, and regional response groups. Shake hands. Collect business cards. Swap stories. These small moments build the trust you will rely on when your network goes sideways at 2 a.m. on a Saturday.

Identify who your law enforcement contacts are now, such as local FBI field office personnel, state cybercrime investigators, or specialized digital forensic units. Introduce yourself. Learn what they do and how they operate. Because during an incident is a terrible time to be making introductions.

When to Call Law Enforcement

Whenever you are handling an incident, reach out to law enforcement early. They might not jump into every ransomware attack or stolen laptop case, but it is still important to keep them informed. They have something you do not have: legal authority. If you need warrants, subpoenas, or data preserved from third-party providers, law enforcement has the tools to make that happen. If nothing else, contacting them shows you are acting responsibly, and that matters later.

Your next reinforcement is legal. You should already have a law firm on an incident response retainer before something goes wrong. But don’t just pick any law firm. Choose one with real experience handling cyber incidents.

Traditional attorneys often respond to breaches by locking everything down and preventing collaboration. That approach creates chaos. Experienced breach counsel understands that incident response requires teamwork, not isolation.

They know how to:

• Work with law enforcement
• Coordinate with security firms
• Maintain legal privilege where appropriate
• Guide sensitive communications
• Draft clear breach notifications
• Stay cool when everything burns

If they have been through this before, they will not fall apart when it is your turn.

Cyber Insurance Requires Work

If you are in an incident and asking whether your cyber insurance covers it, it is already too late. You either have coverage or you do not. And getting that coverage is becoming harder.

Insurance companies are nervous. Ransomware costs are rising and payouts have become massive. Even if you do get coverage, read the fine print. Most policies require due diligence—you must demonstrate that you were following reasonable security practices. If you have ignored vulnerability management, asset inventory, access control, logging, and backups, your insurer may deny your claim.

Cyber insurance is not a magic safety net. It is a contract that assumes you are taking security seriously.

Build Relationships, Not Just a Plan

If there is one theme here, it is this: In a crisis, you do not rise to the occasion. You fall back on the strength of your relationships. When an incident hits, you should not be scrambling to track down experts. You should already know who to call and they should already know you.

Start building your network today. Law enforcement contacts, legal counsel, insurance providers, and trusted incident response partners should already be in your corner. When the day comes, you will not be calling strangers. You will be calling reinforcements. Friends. Colleagues. People who already have your back.

Start now.

As AI becomes increasingly utilized throughout the security space, it's important to consider how it should be used most effectively. We've all seen companies adding AI into every offering and function they perform, often as much as possible.

In security operations, this creates a divide between two types of companies:

1. Companies that rely primarily on AI to do the work
2. Companies that enable their operators to become higher performers through the use of AI

Both types address a clear problem: volume. Anyone who has worked in a SOC knows that alert volume results in burnout, limits the number of customers you can support, and takes time away from more important tasks. Using AI to accelerate triage of high-volume, lower-complexity alerts is a practical and effective strategy. It frees analysts to focus on the ambiguous cases that require human judgment. With the right context and data, AI can meaningfully assist in distinguishing malicious from benign activity — but "most of the time" isn't good enough when a miss means a breach. AI augments the analyst; it doesn't replace their judgment.

That said, keeping a human in the loop is critical for the fringe cases: AI hallucination, highly complex technical investigations, and even situations where attackers attempt to fool the models with injection or evasion techniques.

Let's talk about some ways you can be the second type of company: the one that enables operators rather than replaces them.

AI for Triage Enhancement

Utilizing AI for enhancement of the triage process is something all security operation centers should be doing right now. While AI may occasionally be wrong or may hallucinate, anyone not taking advantage of it to work across the huge amount of data that SOCs process will fall behind their competitors.

I'm not suggesting that an AI model should be constantly closing alerts. Instead, consider this: Could an AI elevate alerts that would otherwise not have been investigated?

All SOCs process swathes of low-fidelity or low-severity alerts that are usually suppressed, deduplicated, or closed out through automation. What if you could use an AI model to review these alerts that would've been closed anyway and elevate those requiring human response to higher priorities? The worst-case scenario—a false negative—isn't applicable here. These alerts wouldn't have received much attention anyway. In the ideal scenario, you could intelligently review alerts your analysts wouldn't have looked at otherwise, escalating truly concerning activity for a human to look at.

AI for Quality Assurance

Another clear use case for AI in SOCs is quality assurance. Many QA checks on investigations are random, but what if you could curate a set of prompts that tasks AI with looking for common mistakes within your investigations and notifies a human to review them?

The AI could highlight the causes for concern, providing a starting point for the human analyst. It could even offer suggestions to both the reviewer and the analyst, making note of possible improvements. The higher quality the QA prompts, the better the feedback.

AI for Validation

Similar to the first use case mentioned, AI could validate analyst investigations and look for logical gaps or potential blind spots. Effectively, it could be used to provide top cover for analysts, giving them more space to triage quicker without chasing down every lead, knowing that the model (ideally trained on past cases!) is fact-checking and logically validating their investigation, freeing them to confidently triage without second-guessing themselves.

Human Augmentation

While AI excels at handling repetitive high-volume tasks, human expertise remains essential for complex investigations, fringe cases, and maintaining accountability. Rather than viewing AI as a cost-cutting tool to reduce headcount (or to take on many more customers with the same headcount), think of it as an investment that multiplies the effectiveness of your existing team. By strategically deploying AI to handle or fact-check routine work, you free your analysts to focus on the sophisticated threats that truly require human judgment and critical thinking.

If you take one thing from this article, I want it to be this:

Using AI to augment your operators may not show the same immediate "return" as replacing them, but, over time, it will increase your service quality tenfold.

Imagine you are a soldier on the front lines, moving through hostile terrain with only your training, tools, and instincts. That's what threat hunting in cybersecurity feels like. You're not waiting in a bunker for alarms to sound; you leave the wire, patrol the area of operations, and look for signs of the enemy before they strike.

A traditional SOC analyst is a watchtower guard: when an alarm goes off, you investigate, confirm, and respond. A threat hunter is the scout team. Your mission begins when everything appears quiet. You assume the adversary is already inside the wire, moving carefully to avoid detection, and your job is to search the terrain, uncover indicators of intrusion, and expose what automated systems miss.

The Ten Battlefield Principles of Threat Hunting

1. If you were the enemy, where would you hide? Every hunt begins by adopting the minset of the adversary—considering their objectives, prioritized systems, likely blind spots, and possible routes for remaining unseen.

2. Your job is tracking. Threat hunters scrutinize logs, processes, authentication paths, and network flows like scouts reading disturbed ground or broken vegetation. You're searching for what's out of place or subtly altered.

3. You create a hypothesis. A hypothesis defines what you expect to see if an adversary is present, giving the hunt direction and preventing aimless data trawling.

4. You move through the environment tactically. You progress methodically through hosts, logs, and authentication records, validating your hypothesis step by step, and carefully documenting your findings.

5. Intelligence guides the hunt. Threat intelligence, prior incidents, and known TTPs (tactic, techniques, and procedures) shape your approach, just as scouts rely on maps, reconnaissance, and mission briefs.

6. Your tools are your weapon systems. SIEM queries, EDR telemetry, packet captures, forensic utilities, and scripting tools are your rifles, optics, and radios. Mastery of them determines how effectively you can uncover hidden activity.

7. You respect the enemy. Adversaries are adaptive and quiet, hiding in normal traffic and shifting tactics quickly. Respect for their capability keeps you vigilant and prevents complacency.

8. When you find something, you call it in. Threat hunters identify, analyze, and escalate findings. Once hostile activity is uncovered, incident response then takes over, just as scouts report contact so their unit can quickly act.

9. The battlefield changes, and you must adapt. Technology shifts, environments evolve, and infrastructures change. Adversaries adjust accordingly, and so must you, by continuously refining techniques, revising hypotheses, and ever tuning your approach.

10. Above all, threat hunting demands a warrior mindset. Patience, curiosity, discipline, and resilience are essential. You operate in uncertainty, seek the subtle, and work where visibility is low and risk is high.

Threat hunting is not a passive role. It requires intent, stealth, and a willingness to move beyond alerts into uncertainty. By taking on the mindset of the adversary, reading the terrain, and acting with discipline, threat hunters find what the automated systems cannot.

The Pyramid of Pain: Knowing and Exploiting Your Adversary's Weak Points

The Pyramid of Pain analogy shows the hierarchy of difficulty an attacker faces when changing certain indicators and how forcing them to do so is likely to disrupt their operations.

Hash Values These are the most easily modified indicators for an adversary. A file hash changes in seconds. Hunting for hashes is like searching for footprints in loose sand.

IP Addresses Attackers replace IPs frequently because they're disposable and easily rotated. Burning an IP, in practice, disrupts nothing beyond temporary infrastructure.

Domain Names Domains require more effort to rebuild, but adversaries often maintain many of them. Forcing a domain change creates friction but doesn't significantly impair strategy.

Network and Host Artifacts These unusual processes, persistence mechanisms, registry changes, and lateral movement patterns reveal the enemy's hands-on work. Replacing them requires careful planning and technical effort, creating real operational pressure.

Tools Adversary tools like Cobalt Strike, Sliver, Impacket, and custom malware represent major investment. Exposing or disrupting them forces adversaries to retool, redesign workflows, and rebuild capabilities.

Tactics, Techniques, and Procedures TTPs are the enemy's doctrine and operational style. Disrupting TTPs applies serious pressure on them to rethink strategy, retrain operators, and redesign campaigns.

While this battlefield may be digital, the mission is the same: detect the enemy early, deny them freedom of movement, communicate new intelligence, and protect what matters before the first alarm ever sounds.

On a recent external network penetration test, the client's attack surface was quite small. From a tester’s perspective, that is usually bad news, because a handful of exposed services means only a handful of chances to find a way in. Luckily one host in particular jumped out at me, a Bosch Telex Remote Dispatch Console (RDC) Server.

A little research turned up Bosch advisory BOSCH-SA-992447, which maps to CVE-2025-29902, a CVSS 10.0 unauthenticated remote code execution vulnerability in the RDC's REST API, fixed in version 1.3.0 in May of 2025. The patch date on the web server's home page was "2023-07-29", leading me to believe the server was vulnerable. The bad news for me was that there were no public exploits available. I notified the customer who challenged me to demonstrate impact with a working proof of concept. This post walks through my journey trying to track down where the vulnerability was and how to exploit it.

Telex RDC is a dispatch console server used to drive radio communications, the kind of system you find behind dispatch centers for utilities, transit, and public safety. Per the Bosch advisory, the flaw lives in the REST API, affects all versions below 1.3.0, requires no authentication, and was responsibly disclosed by external researcher Omer Shaik. I managed to get in touch with the author of the exploit, but they were not willing to share a proof of concept.

Before I could analyze anything, I needed a copy of the old, v1.2 vulnerable software. The vendor's site offered the latest patched release, v1.3, which already had the fix implemented. Luckily, I was able to track down a download URL for the pre-patched version of Telex RDC, v1.2.

https://telex-downloads.s3.us-east-1.amazonaws.com/Releases/230809_v120_RDC_Server.zip

Now that I had both binaries, it was time to find out what had changed.

The textbook next move is patch diffing where you load both versions into a decompiler, compare them, and let the delta point you straight at the fix. I dropped both binaries into a fresh Ghidra project and ran a version diff, expecting a tidy little patch to jump out.

Ghidra version diff between v1.2 and v1.3

It did not. There were two full years and a complete UI overhaul separating v1.2 from v1.3. The diff was enormous, with thousands of changes and almost none of them related to the security fix. Trying to isolate the one patched code path in that sea of churn was a genuine needle-in-a-haystack problem.

This is the honest reality of patch diffing. It is fantastic when the vendor ships a small, targeted fix, and nearly useless when the vulnerable version is buried under a couple of years of unrelated feature work. Rather than burn the rest of the engagement squinting at decompiled functions, I switched approaches entirely.

If static analysis was going to fight me, I would let the application tell me where the bug was. I installed the RDC Server v1.2 on a Windows VM and stood up a local instance that I could poke at, without any risk to the client's production system.

Telex RDC Server local instance

I went back and reread the security advisory which gave me two extremely useful hints: the vulnerability was triggered over HTTP, and it did not require prior authentication. That narrowed the hunt to one question: which parts of the REST API can I reach without logging in?

So, I automated the question. I configured Autorize, the Burp Suite extension, to replay every authenticated request with the Authorization header removed, flagging any endpoint that answered the unauthenticated copy the same way it answered the authenticated one. Clicking through the entire admin interface with Autorize running produced a nice list of endpoints that were not enforcing authentication at all.

The endpoints reachable with no Authorization header are shown below.

/api/v1/resources?type=IMAGE_FILES
/SystemAdmin/views/activityLog.html
/SystemAdmin/views/selectorchooser.html
/SystemAdmin/views/audiofilechooser.html
/SystemAdmin/views/keylistener.html
/SystemAdmin/views/systemStatus.html
/SystemAdmin/views/radioChannels.html
/api/v1/ssl/status

One of the endpoints stood out from the others.

Autorize flagging endpoints that ignore authentication

The /api/v1/resources endpoint accepted uploads. My next step was to intercept the request in Burp Suite and look over the attack surface. I sent the unauthenticated POST and set the filename to a basic path traversal payload aimed at the root of the drive.

..\..\..\..\..\test.exe

To my amazement, the server responded with "204 No Content", indicating that no error had been encountered, so it was possible the file had been created on the server.

Unauthenticated arbitrary path traversal

Sure enough, browsing to C:\ on the VM showed my test.exe file sitting right there in the root of the drive. I was dumbfounded.

Unauthenticated path traversal successful

So, there it was. An unauthenticated attacker can write an arbitrary file anywhere on disk. That is the core of CVE-2025-29902. It is also, on its own, not remote code execution. Writing a file is only half the battle, because you still need something on the box to actually execute it.

My first idea was classic DLL hijacking. I fired up Process Monitor from the Sysinternals Suite and filtered on "Load Image" operations targeting DLLs under C:\Program Files\Telex\RDC Server\. The application loaded plenty of DLLs, but every one of them was already present on disk, so there was no missing DLL I could simply drop in. Exploiting that would have required DLL proxying.

ProcMon Load Image results, no missing DLLs to hijack

I kept exploring the application looking for a binary that would launch on demand. I found one. The web UI has a feature to regenerate the SSL configuration, and when you trigger it, the application shells out to a bundled openssl.exe living in the install directory.

The app launches its bundled openssl.exe during cert generation

That seemed to be a perfect target, a known, fixed path to an executable that the application itself runs, and one I can overwrite. The only catch was that triggering certificate regeneration requires being logged in, which brings us to the authentication bypass, courtesy of the same file write.

Poking around the install directory, I found SystemConfiguration.txt, which included the administrator username and password. The password appeared to be encrypted and Base64 encoded.

System configuration file with credentials on disk

I created a new Telex RDC server instance with a different username and password and made a copy of that configuration file.

Custom system configuration file

Next, I used the path traversal to overwrite the SystemConfiguration.txt with my modified version.

Overwriting the system configuration with new credentials

Once the service restarted, I logged into the administrator portal with username "jack" and password "admin". With admin access in hand, I used the file write one more time to overwrite openssl.exe with a compiled binary of my own. For a clean and harmless proof of concept, that binary just launches the Windows calculator.

#include <iostream>
#include <cstdlib>

int main() {
system("calc.exe");
std::cout << "Calculator opened. Press Enter to exit..." << std::endl;
std::cin.get();
return 0;
}

Overwriting the bundled openssl.exe as an unauthenticated user

Finally, I logged in with my credentials, browsed to System, then Certificates, then Install Self-Signed Certificate. The application dutifully invoked openssl.exe, which was now my binary, and up popped the most glorious calculator. Notably, it ran with administrator privileges, which meant full compromise of the server. The exploit chain was complete using an unauthenticated file write, authentication bypass, and another file write to finally achieve remote code execution as local administrator.

Proof of concept: arbitrary code execution as administrator on the RDC server

Back in my lab, everything worked but this exploit was scrappy, and there was no chance I was going to run the full chain against a live dispatch server. Instead, I proved reachability with the least invasive check possible, a single unauthenticated GET to /api/v1/resources against the production host. It responded just as the lab instance had, confirming that the vulnerable endpoint was exposed and unauthenticated, which was enough to prove exploitability without writing a single byte to the customer's system. I'm sure there are more elegant ways to get RCE with this path traversal, but this was the way I came up in the two days of testing available.

If you are running a Telex RDC Server, the mitigations are straightforward.

• Patch to RDC Server v1.3.0 or later, and VLink 6.6.0 or later. This is the single most important step.

To check if you are currently vulnerable, send an unauthenticated GET request to the /api/v1/resources endpoint. If you receive a "200 OK" response, the server is vulnerable.

by Dan “Haircutfish” Rearden | haircutfish.com | Guest Author Working in the SOC can be a grind. Whether triaging alerts, escalating to clients, or just trying to understand why users […]

The post Report As You Go: Maintaining Good Documentation for SOC Analysts appeared first on Black Hills Information Security, Inc..

Security Operations Centers (SOCs) serve as a critical line of defense against today's constantly evolving cybersecurity threats. At the heart of these teams are SOC analysts, who monitor, detect, and respond around the clock to potential attacks.

The post The Life of a SOC Analyst: Responsibilities, Challenges, and Strategies for Success appeared first on Black Hills Information Security, Inc..

Spend time performing forensic analysis on the Windows Operating System and you'll see a host of artifacts that can be used to identify adversary activity. From changes to the registry to the System Resource Utilization Monitor, Windows artifacts run deep. The challenge is locating, extracting, and parsing these artifacts in an efficient manner.

The post KAPE 101: A Kroll Artifact Parser and Extractor Cheatsheet appeared first on Black Hills Information Security, Inc..

We're all petrified about missing a critical event or misclassifying an alert, but when we're talking about incident response (IR), there are often hundreds if not thousands of alerts to parse through. It's easy to get caught up with one alert because it feels "too hot" or maybe not spend enough time looking into something that initially seems "too cold."

The post Finding the “Goldilocks” Zone: A Practical Approach to Alert Triage appeared first on Black Hills Information Security, Inc..

Vulnerable and outdated software components are one of the most common issues encountered by BHIS during web application penetration tests. The vast majority of web applications use third-party components such as jQuery, Angular, Bootstrap, or countless other libraries.

The post Finding and Addressing Vulnerable and Outdated Web Application Components appeared first on Black Hills Information Security, Inc..

Insufficient egress filtering is a commonly identified vulnerability found during BHIS penetration tests. The insufficient egress filtering finding indicates that network traffic leaving the organization’s environment is not properly restricted.

The post Insufficient Egress Filtering: How Weak Outbound Controls Enable Attacks appeared first on Black Hills Information Security, Inc..

What we built, Fusion AI, runs at about a third the cost of a traditional external pentest, a human tester still signs off on every finding, and it is not here to replace anybody.
We have been hearing that one a lot. So when Melisa from our Business Capture team sat down with Brian Fehrman and me for this episode of AI Security Ops, she started with, “What is this thing you built, and is it the same hype everyone else is selling?”

The post Everyone’s Selling AI That Kills Pentesting. We Built One That Doesn’t. appeared first on Black Hills Information Security, Inc..

He walked into the lobby with a fake badge clipped to his shirt. He had bought it online the week before. It was not perfect, and it did not need to be. From a few feet away, it looked close enough: a logo, a name, a photo, and a lanyard. The kind of thing most people glance at for half a second before their brain decides, “Looks fine.”

The post The Art of the Badge: A Hard Truth About Physical Security appeared first on Black Hills Information Security, Inc..

Welcome to GoGatoZ — a purpose-built Go tool for GitLab CI/CD security auditing that can perform and automate the entire CI/CD kill chain along with everything those one-off scripts did and then some.

The post Auditing GitLab: The CI/CD Kill Chain appeared first on Black Hills Information Security, Inc..

ANTISOC uses a mix of techniques from traditional penetration tests like red teams, cloud, web applications, externals, internals, and, of course, social engineering. We combine this mix of techniques with a wide-open scope, with the goal of going beyond what a typical pentest can discover.

The post Bad Habits: An ANTISOC Operation appeared first on Black Hills Information Security, Inc..