Why Rule-Based SIEM Detection Fails Against Modern Threat Actor TTPs

How SIEM rule logic works

A SIEM rule is a conditional statement, nothing more exotic than that. Alert if a user racks up repeated failed logins in a short window. Flag any file whose hash matches a known malware sample. Flag suspicious process relationships based on known-bad parent-child patterns. These are pattern-matching instructions, and they do what they were built to do: ingest logs, compare each event against a library of conditions, raise an alert when a condition is met.

That design is a product of when and why SIEMs were built. It's a product of when and why SIEMs were built, back when attacks carried stable, repeatable signatures, with the same malware hash, the same command string and the same registry key modification showing up across campaigns. For a long stretch of the industry's history, that assumption held well enough to justify the architecture.

The catch sits in the sequencing. A rule can only be written after a technique has been observed, documented, and translated into a condition. Every rule, no matter how recently deployed, describes something that already happened. It has no mechanism for inference, no behavioral baseline, no sense of context beyond the literal condition it checks. It doesn't ask whether an action makes sense given who performed it or when. It asks only whether the pattern in front of it matches the pattern it was told to look for. If the pattern changes slightly, the rule has nothing left to say.

How adversaries adapt their techniques to evade known signatures

Adversaries don't smash through detection rules. They route around them, and the routing is often trivial. Research examining a representative subset of SIGMA rules, the widely used open format for SIEM detection logic, found that roughly a quarter could be evaded with straightforward syntactic changes: rewriting how a command is expressed while leaving its actual behavior fully intact. The malicious action still happens. The rule, built to match a specific string or structure, simply never sees it.

Automation makes the problem worse. Proof-of-concept malware like BlackMamba uses large language models to regenerate its own malicious code on every execution, so no two runs share a signature. Hash-based detection assumes the same bad file produces the same bad hash. That assumption collapses when the file is different every single time.

None of this is improvised on the fly, either. APT groups build their operations around multi-stage, long-dwell campaigns specifically to avoid producing the kind of discrete, isolated event a rule is waiting for. Stretch an attack across weeks, route it through several disconnected actions, and the SIEM never gets the clean trigger it needs.

Living-off-the-land attacks and legitimate tools that defeat signature logic

Living-off-the-land, or LOTL, attacks skip custom malware entirely and use tools the operating environment already trusts: PowerShell, WMI, rundll32, mshta, certutil. These are built into the operating system, used daily by administrators, and explicitly allowlisted by the antivirus and endpoint tools meant to stop bad software.

That's what makes LOTL a definitional problem for signature-based detection. There's no malicious file hash to catch, because there's no malicious file. The SIEM rule expects to see certutil.exe running, because certutil.exe runs constantly in ordinary administrative work. The rule was written assuming that context. It never questions it.

The shift toward these techniques isn't a fringe trend anymore, it's the center of gravity. CrowdStrike's 2025 Global Threat Report found that 62% of the detections in its dataset were malware-free attacks relying on LOTL techniques, and CrowdStrike's OverWatch team specifically flagged widespread abuse of LOLBins, living-off-the-land binaries, including rundll32, mshta, and CertUtil, across multiple distinct threat campaigns. When most real-world attacks stop using malware at all, a detection model built around matching malware stops being the right tool for most of what it's supposed to catch. The architecture isn't underperforming, it's answering a question attackers stopped asking years ago.

The MITRE ATT&CK coverage map shows where rule-based SIEMs go blind

The clearest evidence of the gap comes from CardinalOps' Fifth Annual State of SIEM Detection Risk Report, which analyzed more than 13,000 unique detection rules across hundreds of production SIEM environments, spanning Splunk, Microsoft Sentinel, IBM QRadar, CrowdStrike Logscale, and Google SecOps. Despite a 2% year-over-year improvement, enterprise SIEMs collectively have detection logic for only 21% of the adversary techniques catalogued in the MITRE ATT&CK framework. Flipped around, the number says something starker: 79% of known techniques have no detection rule at all, anywhere, in the environments studied.

Narrow the lens to the techniques attackers actually favor in real campaigns, and coverage gets worse, not better. Organizations in the study covered only 4 of the top 10 most frequently observed techniques. The rules that do exist are disproportionately aimed at the attacks least likely to show up.

Coverage isn't evenly spread across the kill chain either. It clusters around Initial Access, phishing, exploit attempts, the entry point, where detection is comparatively mature. It thins out fast across Defense Evasion, Credential Access, Lateral Movement, and Collection, precisely the stages where adversaries spend the most time before they ever reach exfiltration. The map is strong exactly where dwell time is shortest and weak exactly where it's longest, which is close to the worst possible arrangement a defender could ask for.

Identity and credential attacks expose the late-stage blind spot rule-based detection cannot close

Compromised identities represent a dominant share of cyber incidents, and in many of those cases, attackers aren't breaking through anything. They're logging in.

IBM's research backs this up from the breach-cost side: stolen credentials were the single most common initial attack vector, at 16% of breaches, and those specific breaches took the longest to identify and contain of any category, nearly 10 months on average. That dwell time is a direct consequence of what a credential-based attack looks like from the SIEM's vantage point: it looks like nothing.

A rule can catch five failed login attempts in two minutes without trouble. That's a clean pattern to match against. What it cannot catch is one successful login, using a valid, stolen credential, from a location plausible enough not to trip a geo-anomaly threshold. There's no failed condition to flag, because nothing failed. The Blue Report 2025 puts a number on how often that door stands open already: in 46% of tested environments, at least one password hash was successfully cracked, and attacks using valid accounts succeeded 98% of the time. The login attempt, the exact surface rule-based detection was built to guard, has already been cleared by the time detection would even engage.

Three operational failures that compound the structural gap

The structural mismatch above would be serious in a perfectly maintained SIEM. In practice, three operational failures appear consistently across environments and make it worse.

Log collection is the foundation, but it is cracking. Around half of detection rule failures in 2025 traced back to log collection problems: missed log sources, misconfigured agents, settings quietly pointed at the wrong data. A rule written against a log source that never arrives is a permanently silent rule, and nothing in the SIEM tells an analyst that.

Misconfiguration compounds it. Roughly 13% of rule failures in 2025 came down to configuration issues, wrong thresholds, broken correlation logic, poorly defined reference sets. CardinalOps found that on average 13% of an organization's existing rules are non-functional and will never trigger under any circumstance. Teams believe they have coverage that simply isn't there. Overly broad rules create the opposite failure, firing constantly and burying analysts in noise. False positives have held the top spot as the SOC's biggest daily challenge for three years running, and real threats get lost in the pile because everyone is staring at too much.

Cost pressure adds a third failure that never appears in any dashboard. Organizations routinely exclude data sources to manage ingestion expense: DNS logs get turned off, endpoint telemetry gets resampled at lower resolution, cloud audit trails get sampled instead of captured in full. None of that registers as a missed alert, because there was never a chance for an alert to fire. It becomes visible later, as a breach that takes longer to detect and an incident that's harder to reconstruct after the fact, a cost that never appears as a line item and may be the most expensive thing in the security budget nobody can actually point to.

A fourth pressure sits on top of the other three, discussed less often but no smaller. A further pressure comes from performance problems: resource-heavy rules, sprawling custom property definitions, and queries too slow to keep pace with data volume. When detection logic can't keep up with the traffic running through it, response slows down at the exact moment speed matters most.

Why layering more rules onto a broken model does not fix it

Faced with a 1-in-7 detection rate, the instinct to write more rules is wrong. That instinct is understandable, and it's wrong. Adding rules to a model already out of step with how attacks behave doesn't close the gap. It adds volume to both sides of a ledger that's widening either way.

More rules mean more false positives, and analysts are already drowning in the ones they have. Rules that fire often and get dismissed just as often train an entire SOC to ignore alerts, which is the exact opposite of what better detection is supposed to accomplish.

Rule debt makes the same problem quieter and harder to see. Rules written three years ago for a threat environment that no longer exists don't sit there harmlessly, some of them actively get in the way of accurate detection today. Most SOCs carry rules that fire constantly and get dismissed every time, noise generators wearing the label of detections. And because MITRE ATT&CK itself keeps evolving, rules built against an older version of the framework aren't just stale, they're blind to entire categories of technique occurring in active campaigns right now. Piling more rules on top of that just makes the pile bigger. It just makes the pile bigger.

What a detection model capable of matching adaptive TTPs requires

LOTL techniques and credential abuse point to the same underlying fix: detection has to shift from asking what is running to asking how and why it's running. That's a question of behavioral context, not file reputation, not a known signature. A rule can check whether certutil.exe is present. Only behavioral logic can ask whether this instance of certutil.exe, run by this account, at this hour, against this destination, actually makes sense.

Getting there means treating detection engineering as an actual discipline with its own ongoing lifecycle. Detection logic needs to be built, tested against real attack behavior, measured for effectiveness, and retired when it stops working, the same lifecycle software engineering has applied to code for decades. Every missed threat should feed a detection backlog. Every threat caught late should become a tuning ticket. Coverage should be mapped explicitly against MITRE ATT&CK techniques, so teams know precisely what they can see and what they can't, instead of operating on an assumed coverage the CardinalOps data suggests frequently isn't there.

Behavioral and AI-augmented approaches go after the gap at its root instead of patching around it. Behavior-based detection builds a baseline of what's normal for a given account, system, or process, and flags deviation from that baseline. A legitimate tool used in an anomalous way, at an anomalous time, by an anomalous account, generates a signal even with no matching signature anywhere in the rule library. AI-driven correlation extends that further, connecting activity across a multi-stage attack chain that linear, single-event rules were never built to see. Lateral movement using valid, stolen credentials on one system to escalate privileges on another looks like nothing when each event is examined alone. Examined as a sequence, it becomes visible.

That points to a reshuffling of what the SIEM is actually for. Instead of serving as the primary engine of detection, the SIEM becomes the collection and correlation substrate, the place where data lives and gets normalized, while a separate layer of detection intelligence, built for behavior and pattern recognition across time, sits above it and does the real work of deciding what matters.