Detection Gaps: The Hidden Enemy in SOC Threat Hunting & Detection Engineering

The Blind Spot Nobody Talks About

If you spend any time in a SOC, you’ll notice one common theme: everyone is obsessed with reducing false positives. Playbooks, tuning sessions, endless SIEM rules — all designed to cut down the noise.

But here’s the problem: while we’re busy fighting the noise, we rarely talk about the silence.

That silence comes from detection gaps — the places in your environment where you have zero visibility. No logs, no telemetry, no alerts. Attacks can happen there, and you wouldn’t even know.

As I like to put it:
“False positives waste your time. Detection gaps waste your visibility.”

And without visibility, there is no detection, no hunting, no response.

In this article, we’re diving into one of the most overlooked challenges in SOC operations: False Positives vs Detection Gaps — and why the latter is often more dangerous.

Here’s what you’ll find inside:

1. False Positives vs Detection Gaps — What’s the Difference?
   We’ll break down why gaps are scarier than noise.
2. Real Examples of Detection Gaps
   From PowerShell and MSHTA to LOLBins — with Sigma rules and Splunk detection queries to show how to catch them.
3. How Detection Gaps Affect Threat Hunting
   Learn how gaps impact the Detection Engineering lifecycle and how missing telemetry can actually stall the loop.
4. Mini Playbook: Run a Gap Analysis
   Practical steps to map threats to data sources and fix blind spots in your environment.
5. Practical Method: Gap Analysis with MITRE ATT&CK
   Use the MITRE Dettct tool to generate a coverage matrix, identify missing detections, and track improvements over time.
6. The Real Impact
   Why detection gaps matter, how they increase dwell time, and why SOC maturity = visibility first, tuning second.

By the end, you’ll have a structured approach to uncover blind spots in your detection program — and actually do something about them.

False Positives vs Detection Gaps — What’s the Difference?

In SOC operations, false positives are the alerts that trigger but turn out not to be real threats. They’re noisy, they eat analyst time, and they can create fatigue. Every SOC knows this pain.

But detection gaps are something entirely different — and often more dangerous. A detection gap is when an attacker’s activity happens but you don’t generate any alert at all because you don’t have the right visibility, telemetry, or detection logic in place.

Think of it this way:

• A false positive is like a fire alarm going off when someone burned toast. Annoying, but at least you heard something.
• A detection gap is like a fire starting in your basement and your alarm system isn’t even wired to that room. Silent, invisible, and far more destructive.

And here’s the catch: most SOCs actively measure false positive rates… but almost nobody measures their detection gaps.

Quick example:
If you don’t have PowerShell ScriptBlockLogging enabled, an attacker can run malicious commands through PowerShell and you’ll never see them. No alerts, no logs, no traces — just a blind spot.

And trust me — a shocking number of organizations still ignore this telemetry just because of the noise even tho it’s common it attacks . (Yes, somehow in 2025. ‍♂️)

Want to know exactly why logging PowerShell commands matters? Check out the ATT&CK data source for PowerShell ScriptBlockLogging here. It’s listed under DS0017 — Command: Command Execution, which emphasizes capturing textual command executions for detection purposes.

Real Examples of Detection Gaps

Detection gaps aren’t abstract — they show up in real attacks every day. Let’s look at some common blind spots that attackers love to exploit:

Example 1: Fileless PowerShell Attacks (ATT&CK T1059.001)

PowerShell is extremely powerful, but without ScriptBlockLogging or ModuleLogging, most malicious commands run completely under the radar.

• The gap: No PowerShell logging → no way to detect encoded commands, download cradles, or privilege escalation scripts.
• Why it matters: Many modern malware families (e.g., Emotet, Cobalt Strike stagers) abuse PowerShell for execution.

Below is a Sigma rule for suspicious PowerShell usage. You can convert Sigma to your favorite SIEM query language using Uncoder.io. Since I use Splunk in my lab, here’s how the same detection looks in Splunk SPL

title: Suspicious PowerShell Encoded Command
id: f91dbe4a-4c9a-11ee-8c99-0242ac120002
status: experimental
description: Detects PowerShell execution with EncodedCommand flag
author: 0Xzetss
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\powershell.exe'
    CommandLine|contains: '-EncodedCommand'
  condition: selection
level: high

index=win_logs sourcetype="WinEventLog:Security" 
(Image="*\\powershell.exe") 
(CommandLine="*-EncodedCommand*")
| stats count by Computer, User, CommandLine, _time

Example 2: MSHTA Abuse (ATT&CK T1218.005)

Attackers abuse mshta.exe to execute malicious scripts or pull payloads directly from the web. It’s a trusted Windows binary (a LOLBin), so it often slips past AV.

• The gap: If your telemetry doesn’t include process creation with command-line arguments, you’ll never see suspicious MSHTA executions.
• Why it matters: This technique has been used in phishing payloads for years, and still works because orgs don’t always log process trees.

Below is a Sigma rule for suspicious Suspicious MSHTA Execution . You can convert Sigma to your favorite SIEM query language using Uncoder.io. Since I use Splunk in my lab, here’s how the same detection looks in Splunk SPL

title: Suspicious MSHTA Execution
id: 11d40e5c-4c9b-11ee-8c99-0242ac120002
status: experimental
description: Detects mshta.exe executing remote payloads or scripts
author: 0Xzetss
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\mshta.exe'
    CommandLine|contains:
      - 'http'
      - '.hta'
      - '.js'
  condition: selection
level: high

index=win_logs sourcetype="WinEventLog:Security" 
(Image="*\\mshta.exe") 
(CommandLine="*http*" OR CommandLine="*.hta" OR CommandLine="*.js")
| stats count by Computer, User, CommandLine, _time

Example 3: LOLBins in General (Living-off-the-Land Binaries)

Windows comes packed with binaries like rundll32.exe, regsvr32.exe, and wmic.exe that attackers abuse.

• The gap: Default Windows event logs don’t give enough visibility into command-line arguments or parent/child process relationships.
• Why it matters: Attackers love LOLBins because they don’t need to drop malware — making detection without proper logging nearly impossible.

Below is a Sigma rule for Rundll32 Suspicious Execution. You can convert Sigma to your favorite SIEM query language using Uncoder.io. Since I use Splunk in my lab, here’s how the same detection looks in Splunk SPL

title: Rundll32 Suspicious Execution
id: 23f6c4f0-4c9b-11ee-8c99-0242ac120002
status: experimental
description: Detects rundll32.exe executing suspicious payloads (e.g., JavaScript)
author: 0Xzetss
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\rundll32.exe'
    CommandLine|contains:
      - '.js'
      - '.vbs'
      - 'javascript:'
  condition: selection
level: high

index=win_logs sourcetype="WinEventLog:Security" 
(Image="*\\rundll32.exe") 
(CommandLine="*.js" OR CommandLine="*.vbs" OR CommandLine="*javascript:*")
| stats count by Computer, User, CommandLine, _time

The key takeaway?
These aren’t “advanced” attacks — they’re normal tools used in abnormal ways. And if you don’t collect the right telemetry (command-line logging, ScriptBlock logs, Sysmon events, EDR process trees), you’ll never know they’re happening..

How Detection Gaps Affect Threat Hunting

Before we dive into the impact on threat hunting, let’s zoom out for a second. Detection Engineering isn’t random rule-writing — it’s a continuous lifecycle:You’ll often see the Detection Engineering cycle drawn as a loop

photo is from socprime you can learn more about Detection Engineering from there

Gap Analysis lives right at the heart of Collection. It’s the step that makes sure the data you collect actually supports the threats you care about. Without it, the cycle breaks: Direction can point you to a threat, but Processing can’t build detections if the logs don’t exist.

Miss it, and you’ll spend weeks writing clever detections for data you never collected…

And that’s where hunting suffers most. Threat hunting is hypothesis-driven — you take CTI or attacker behavior and ask, “What would it look like in our environment? But if the underlying telemetry isn’t there, your hunt is blind.

Example: You can’t hunt for credential dumping if LSASS process-access events aren’t even collected

Why Gap Analysis is the pivot

• Direction → Collection: CTI says “T1059.001 (PowerShell) & T1218.005 (MSHTA) are active.”
  Gap Analysis translates that into exact telemetry requirements (e.g., Event IDs, fields, process trees).
• Collection → Processing: Once you confirm telemetry exists, you can actually write, test, and tune detections.
• Skip it, and you’ll either over-tune noise you happen to have, or ship detections that never fire.

Minimum Viable Telemetry (Windows endpoints)

To support the examples in this article:

• PowerShell (T1059.001)
• PowerShell Script Block Logging (Event ID 4104)
• (Nice to have) Module Logging (4103), Transcription
• Process creation with full command line (Security 4688 or Sysmon 1)
• MSHTA (T1218.005)
• Process creation (Security 4688 / Sysmon 1) with command line
• Outbound network telemetry (Sysmon 3, proxy/DNS logs)
• Credential Dumping (T1003)
• Sysmon 10 (Process Access) to see handles into lsass.exe
• Process creation (Sysmon 1) to spot procdump, rundll32, comsvcs.dll abuse
• EDR memory-read telemetry (if available)

If any of the above is missing, that’s a detection gap. Fix collection first, then write detections.

Mini Playbook: Run a Gap Analysis (fast)

1. Pick threats from Direction: e.g., T1059.001, T1218.005, T1003 for your sector.
2. Map TTP → required telemetry (events, fields, sensors).
3. Verify collection in your SIEM/EDR (do you see those events now?).
4. Prioritize fixes: deploy/enable missing logging (e.g., 4104, Sysmon config).
5. Only then write detections, test with real data, and disseminate.

Quick Splunk Sanity Checks (are we collecting the basics?)

/* PowerShell Script Block Logging present? */
index=* (sourcetype=XmlWinEventLog:Microsoft-Windows-PowerShell/Operational OR sourcetype=WinEventLog:Microsoft-Windows-PowerShell/Operational)
EventCode=4104
| stats count by host

/* Sysmon Process Creation flowing? */
index=* sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational EventCode=1
| stats count by host Image CommandLine | head 20

/* LSASS process-access visibility (Credential Dumping pre-req) */
index=* sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational EventCode=10
TargetImage="*\\lsass.exe"
| stats count by host SourceImage GrantedAccess

/* MSHTA executions seen? */
index=* sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational EventCode=1 Image="*\\mshta.exe"
| stats count by host CommandLine | head 20

If these return nothing for active endpoints, you’ve found a gap. Close it at the Collection stage — then your Processing (detections, hunts) will actually work, and the whole loop finally turns.

Practical Method: Gap Analysis with MITRE ATT&CK

So, how do you actually uncover your detection gaps in a structured way?

That’s where MITRE ATT&CK becomes your best friend. By mapping your detections to ATT&CK techniques, you can visualize exactly what you cover — and more importantly, what you don’t.

One of the simplest tools to start with is Dettct. It’s lightweight, open-source, and designed specifically for gap analysis.

• You feed it your current log sources and detection rules.
• It maps them against MITRE ATT&CK techniques.
• You get a coverage matrix: using the MITRE ATT&CK Navigator

Why this matters:
It’s common to see SOCs with dozens of phishing detections, but limited coverage for lateral movement . A matrix makes that imbalance painfully obvious.

Dettct also lets you export your coverage as YAML or JSON files, which makes it super handy for:

• Future reference when adding new rules.
• Tracking improvements in your detection program over time.
• Reporting coverage to management in a visual, structured way.

If you want to dive deeper into Dettct and how to set it up, check out this great write-up by NVISO: Dettct — Mapping Detection to MITRE ATT&CK.

The Real Impact

Detection gaps aren’t just a “nice-to-know” problem — they have real consequences:

• Higher dwell time: attackers can live off the land and move laterally without being detected.
• Invisible activity: the longer a threat stays under the radar, the more damage it can do.
• SOC trade-offs: teams spend time tuning noise (false positives) while blind spots silently undermine detection and hunting.

False positives aren’t the enemy (could cause alert fatigue yes ) —but blind spots are.

SOC maturity isn’t measured by how few alerts you generate. It’s measured by visibility first, tuning second. If you don’t see it, you can’t defend it.

Call to Action

Have you ever done a gap analysis of your detections?
If not, start today. Map your telemetry, map your rules, and close those blind spots — your future self (and your SOC) will thank you.

Detection Gaps: The Hidden Enemy in SOC Threat Hunting & Detection Engineering was originally published in Detect FYI on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction to Malware Binary Triage (IMBT) Course

Looking to level up your skills? Get 10% off using coupon code: MWNEWS10 for any flavor.

Enroll Now and Save 10%: Coupon Code MWNEWS10

Note: Affiliate link – your enrollment helps support this platform at no extra cost to you.

Article Link: Detection Gaps: The Hidden Enemy in SOC Threat Hunting & Detection Engineering | by 0xZetss | Sep, 2025 | Detect FYI

1 post - 1 participant

Read full topic

Malware Analysis, News and Indicators - Latest topics