CQURE Hacks #72: KQL Threat Hunting – One Query, Three Hunts

In active-duty security, time is your most valuable asset. Most hunters struggle because they try to write a brand-new query for every single alert. This creates a messy library of code that is hard to manage.

Kajetan, one of our frontline experts, shows you how to use one “Base Query” as a launchpad for three critical scenarios:

1. Web Reconnaissance: We filter our base query for HTTP traffic. By adding a simple scoring system, we can instantly flag attackers probing your web apps for vulnerabilities.

2. UDP Broadcast Analysis: By switching the protocol in our base logic, we spot unusual broadcast spikes. This catches attackers trying to spoof identities or move through your network.

3. Abnormal TCP Patterns: We adjust the same base query to look at session length and data volume. This reveals the tiny signals left behind by data theft or malware “calling home.”

Smart hunting isn’t about how many queries you have; it’s about how adaptable they are. By building once and adapting many times, you gain:

• Speed: Pivot between different threats in seconds.
• Consistency: Use the same data structure for every hunt.
• Clear Results: Move from raw data to a clear story of what happened.

Level up your KQL skills and become the proactive defender your organization needs. Consider this your “hacking license” for data.

Want to know more?

Join us for the 5-day course: System Forensics, Incident Handling and Threat Hunting

TRANSCRIPT

Hey, everyone.

Welcome back to our KQL Threat hunting series.

Today, I’m going to show you something really powerful, how to take one base KQL query and transform it into three completely different threat hunts.

This is about working smarter, not harder, and getting maximum value from your security data.

We will be analyzing real network traffic to detect web reconnaissance, unusual broadcast, and abnormal TCP patterns. Let’s dive in.

This is our foundation, a simple but powerful query that gives us an overview of all network traffic.

Let’s have a look what it does.

We are looking at a specific hour and a half window aggregating by source IP, destination IP port and protocol.

Keymetrics, total bytes, send received, packet counts, connections, and duration.

This gives us a baseline, so understanding of what normal looks like in our environment.

But the real power comes when we specialize this query for the specific threat hunting scenarios.

Now, watch how we transfer our base query into first-hand, so detecting web reconnaissance.

Attackers often scan web application before attacking them.

Here’s what we have changed.

First, filter to HTTP traffic, so only TCP on port 80 or service HTTP HTTP.

Added recon-specific metrics, so counting unique targets and ports.

Time-based scoping, looking at activity in 30-minute windows. Added thresholds, more than five HTTP request from a single source.

And the last, scoring system, so calculates recon likelihood.

What this really detects? For example, automated scanner, scrolling, web applications, attackers probing for vulnerable web apps, TVWA, PHP admin, and so on, and reconnaissance before credential traffic or simply brute force attacks. Legitimate users typically access a few resources, but recon tools hit many paths and hit many paths quickly.

This query catches this pattern. Next hound takes a completely different angle. Udp Brokos analysis. Normal networks have predictable Brokos patterns. Here’s our transformation.

Switch to the UDP protocol. Different thread surface. Added categorization. So Netbios, MD-Ns, DHCP, LLMNR. Different metrics, broadcast count, package size, and duration. Also longer time window.

One hour periods for broadcast analysis and lower thresholds. Just two broadcasts which can be suspicious. What it detects?

Network discovery scans using Netbios. M DNS and LLMNR spoofing attacks, DHCP-exhaustioned attacks, warm propagation using broadcast, unusual service discovery patterns.

Brokast traffic should follow predictable patterns. Sudden spikes or unusual sources indicates scanning or attack activity. Finally, hand number three.

This one looks like TCP session behaviors. This is about connection quality and patterns.

Here we have risk scoring system, so weights, different suspicious behavior, behavior analysis, so connection, duration, data volume and states, and service anomalies, HTTP with tiny responses, unknown service with data.

Also, the pattern detection, so port scanning, rapid connections, short-lived sessions. What this detects? Port scanning, so many short-fade connections.

Data exfiltration, so large transfer in short time. Also C2 beconning, so regular short connections, service enumeration, and fast flux networks. Legitimate connections have predictable duration and data patterns.

Malicious activity often shows us statistical outliers. To summarize, start with the base. Understand your data structure. Filter for the thread. So this for the web, UDP for the broadcast. Add thread-specific logic, recon scoring, broadcast categorizing, or risk scoring.

Add use time window. Set appropriate thresholds, so based on what’s suspicious for each protocol. And add a contextual output, so clear with investigation nodes. This approach gives you consistency, so same base structure. Efficiency, build once, adapt many times. And maintable, easy to update thresholds.

Also, the scability. And that’s how you create three powerful trade hands from one base KQL query. Remember, effective threat hunting isn’t about writing thousands of queries. It’s about writing smart, adaptable queries and give you multiple perspectives on your data.

Try this approach with your own security data. Start with a simple base query, then specialize it for different threat scenarios. You will be amazed at what you can discover. If you found this useful and helpful, please like and subscribe for more KQL and threat hunting content. Thanks for watching.

And happy hunting.

Want to know more?