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

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.

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..

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..

There is a certain kind of conversation that doesn’t get written up in a post-mortem, doesn’t generate a ticket, and never makes it into an end-of-quarter report. It happens on the margins—at a conference, in a hallway, or, in this case, at 30,000 feet above sea level. It’s the conversation where two people who are solving the same problem from opposite ends of the table finally sit down next to each other.

The post Same Problem, Different Angles: When Red Team and Blue Team Actually Talk to Each Other appeared first on Black Hills Information Security, Inc..

In the ever-evolving world of cybersecurity, staying ahead of the curve is not just a goal—it’s a necessity. As new vulnerabilities emerge, the race to identify and mitigate them begins. But how do we, the guardians of the digital realm, rapidly pinpoint these threats as they become public? Let’s dive into the fascinating world of vulnerability identification and see how the magic happens.

The post How to Identify and Exploit New Vulnerabilities appeared first on Black Hills Information Security, Inc..

This blog will not dive too deeply into BloodHound itself; instead, we will focus on various methods to collect AD data to provide BloodHound as input.

The post A Practical Guide to BloodHound Data Collection appeared first on Black Hills Information Security, Inc..

An offensive security perspective on Microsoft Edge WebView2 Runtime, including architectural weaknesses, existing vulnerabilities, and exploitation methods.

The post Signed, Trusted, and Abused: Proxy Execution via WebView2 appeared first on Black Hills Information Security, Inc..

Advice about getting started in pentesting from the BHIS pentest lead, including a learning path and why you should go all in on offensive security skills.

The post Getting Started In Pentesting – Advice From The BHIS Pentest Lead appeared first on Black Hills Information Security, Inc..

Learn about a pentesting tool using the Pluggable Authentication Module for privilege escalation, lateral movement, and persistence in Linux.

The post The “P” in PAM is for Persistence: Linux Persistence Technique appeared first on Black Hills Information Security, Inc..

Malicious attacks are increasing in frequency, sophistication and damage. Defenders need to find and harden system weaknesses before attackers can attack them.

The post Cyber Insights 2026: Offensive Security; Where It Is and Where It’s Going appeared first on SecurityWeek.

This scenario simultaneously tests identity confirmation tooling (SSPR, MFA, Conditional Access), how users act under pressure, and the organization's ability to detect and follow-up on social engineering attacks.

The post Social Engineering and Microsoft SSPR: The Road to Pwnage is Paved with Good Intentions  appeared first on Black Hills Information Security, Inc..

This article was originally published in the second edition of the InfoSec Survival Guide. Find it free online HERE or order your $1 physical copy on the Spearphish General Store. […]

The post How to Perform and Combat Social Engineering appeared first on Black Hills Information Security, Inc..

DomCat is a command-line tool written in Golang that helps the user find expired domains with desirable categorizations.

The post DomCat: A Domain Categorization Tool appeared first on Black Hills Information Security, Inc..

A Content Security Policy (CSP) is a security mechanism implemented by web servers and enforced by browsers to prevent various types of attacks, primarily cross-site scripting (XSS). CSP works by restricting resources (scripts, stylesheets, images, etc.) on a webpage to only execute if they come from approved sources. However, like most things in security, CSP isn't bulletproof.

The post Bypassing CSP with JSONP: Introducing JSONPeek and CSP B Gone appeared first on Black Hills Information Security, Inc..

An Infosec Survival Guide Resource, released as blog posts, with fully designed, printer-friendly PDF cheatsheets.

The post Offensive Tooling Cheatsheets: An Infosec Survival Guide Resource appeared first on Black Hills Information Security, Inc..

One tool that I can't live without when performing a penetration test in an Active Directory environment is called NetExec. Being able to efficiently authenticate against multiple systems in the network is crucial, and NetExec is an incredibly powerful tool that helps automate a lot of this activity.

The post Getting Started with NetExec: Streamlining Network Discovery and Access appeared first on Black Hills Information Security, Inc..

Social engineering is the manipulation of individuals into divulging confidential information, granting unauthorized access, or performing actions that benefit the attacker, all without the victim realizing they are being tricked.

The post How to Design and Execute Effective Social Engineering Attacks by Phone appeared first on Black Hills Information Security, Inc..

TL;DR If you only have access to a valid machine hash, you can leverage the Kerberos S4U2Self proxy for local privilege escalation, which allows reopening and expanding potential local-to-domain pivoting paths, such as SEImpersonate!

The post Abusing S4U2Self for Active Directory Pivoting appeared first on Black Hills Information Security, Inc..

Burpference is a Burp Suite plugin that takes requests and responses to and from in-scope web applications and sends them off to an LLM for inference. In the context of artificial intelligence, inference is taking a trained model, providing it with new information, and asking it to analyze this new information based on its training.

The post Augmenting Penetration Testing Methodology with Artificial Intelligence – Part 1: Burpference appeared first on Black Hills Information Security, Inc..