“Now, here, you see, it takes all the running you can do, to keep in the same place.” — The Red Queen, Through the Looking-Glass
This post is an edited excerpt from my upcoming book — “A Dance of Red and Blue”, which will be released in the near future. Stay tuned!
===============================================================
In 1973, evolutionary biologist Leigh Van Valen proposed a hypothesis that would reshape how we understand the natural world. He observed that the probability of a species going extinct didn’t decrease with age — a species that had survived for ten million years was no safer than one that had survived for one. He called this the Red Queen Hypothesis: organisms must continuously adapt and evolve not to gain advantage, but merely to survive against equally evolving opposing organisms.
Detection engineers live inside this dynamic every day. But most of us misunderstand where we sit in it.
Where the Arms Race Actually Lives
The co-evolutionary dynamic is real. But it doesn’t happen between your SOC and “your” attackers. It happens between threat actors and the security vendor ecosystem — and your detection team is downstream of both.
When an attacker group stops using Cobalt Strike and moves to Brute Ratel, they’re not evading your detections. They’re evading CrowdStrike’s signatures. Microsoft Defender’s behavioral rules. The collective detection surface of every EDR product that published a blog post titled “Hunting for Cobalt Strike.” The evasion pressure comes from the industry’s shared, public-facing detection capability — not from anything an individual detection program built.
This is the actual topology of the arms race:
Attackers ←→ Security Vendors (EDR, AV, Cloud Providers)
↓
Public Threat Intel (blogs, signatures, rules)
↓
Your Detection Team (consumer, not participant)
The arrows of co-evolution flow between the top two. Your team consumes the output of both sides — attacker TTPs that have already been shaped by vendor pressure, and detection content that vendors publish in response. You are not a combatant in the arms race. You are an ecologist studying the results.
And it’s quite liberating. Because once you stop pretending your rules pressure attackers, you can start thinking clearly about what your rules actually do.
What Your Detections Actually Do
If your detections don’t change attacker behavior, what are they for?
They catch the attackers who haven’t updated their tooling yet.
That’s it. And that’s not nothing — it’s actually the majority of real-world intrusions. Most attackers are not APT groups with custom toolkits and red-team-grade opsec. Most attackers are running commodity ransomware and hoping nobody’s looking. Your detections exist to catch the median threat, not the cutting edge.
This reframing has three implications:
1. Your Rules Have a Shelf Life — But It’s Set by Vendors, Not Attackers
A detection rule becomes less effective over time not because an attacker encountered your rule and adapted, but because the vendor ecosystem detected a technique so thoroughly that the attacker population collectively migrated. The shelf life of powershell -encodedcommand detection wasn’t determined by any individual SOC. It was determined by how long it took Microsoft Defender, CrowdStrike, SentinelOne, and a hundred other products to make that string toxic to use.
In many cases, your job isn’t to outrun the attacker. It’s to stay current with the vendor-driven evolutionary cycle and ensure your detection coverage reflects where the attacker population currently lives — not where it lived when you wrote the rule. If you have the maturity to actually pursue cutting-edge — be my guest and do it!
2. The Attacker Doesn’t Know You Exist — Use That
Since the adversary isn’t studying your detection surface, your custom rules operate in a genuine blind spot. The attacker has priced in EDR. They’ve priced in default AV signatures. They’ve priced in whatever gets published in vendor blog posts. They have not priced in the weird behavioral rule you wrote.
This is the actual value proposition of a detection engineering team: you detect what the vendor can’t or won’t. Vendors build for scale — generic signatures across millions of customers. You build for your environment, your telemetry, your baseline of normal. The attacker can’t adapt to what they don’t know about, and they will never know about the rule you wrote on Tuesday that fires on a pattern specific to your network.
The less your detections resemble public detection content, the more durable they are. Not because you’re in an arms race — but because you’re invisible.
3. Stable Equilibria Are Vendor-Side, Not SOC-Side
Why does LSASS credential dumping persist despite a decade of detection? Not because attackers have weighed the cost of your specific rule against the value of cleartext credentials. They persist because the attack works on unpatched/unprotected hosts and the tooling is free. The technique’s survival is a function of the global attack surface (millions of Windows machines without Credential Guard) and commodity tool availability (Mimikatz is on GitHub). It has nothing to do with any individual defender’s detection investment.
When you see a technique that “refuses to die,” you’re not observing a co-evolutionary stable equilibrium between you and an adversary. You’re observing a technique whose environmental conditions — tool availability, vulnerable hosts, low attacker skill barrier — sustain it regardless of detection pressure.
The Three Tiers of Adaptation — Corrected
The attacker population does evolve. But the selection pressures are worth understanding accurately:
Fast Tier: IOC Rotation (Days)
IOCs rotate constantly — but not because anyone detected them. Infrastructure gets burned on VirusTotal. Domains age into blocklists. Hashes get submitted to malware sandboxes. This is environmental decay, not adaptation to your rules. If your detection strategy is anchored at this tier, you’re not even running the Red Queen’s race. You’re picking up shells on a beach where the tide already went out.
Medium Tier: Tool Migration (Months)
When Cobalt Strike became the poster child of every EDR vendor’s detection blog post, the attacker population migrated to alternatives. This adaptation was driven by public detection content — vendor blogs, conference talks, YARA rules on GitHub. Not by any SOC’s custom rules.
This tier is where the arms race is most visible and most honestly bilateral — but the combatants are threat actors and security vendors, not threat actors and your SOC.
Slow Tier: Tradecraft Shifts (Years)
The migration from malware-on-disk to fileless execution. From endpoint compromise to identity attacks. From on-premise exploitation to cloud control plane abuse. These are genuine speciation events, driven by cumulative vendor-side pressure that made entire categories of tradecraft prohibitively expensive against the average defended environment.
Your detection team didn’t cause these shifts. But you have to respond to them — and this is where the Red Queen metaphor actually applies to you. Not because you’re co-evolving with an adversary, but because the environment you’re detecting in is constantly changing underneath you.
If Not an Arms Race, Then What?
So what’s the right metaphor for a detection engineering program?
I’d argue it’s ecology, not warfare. You’re not a combatant. You’re a field biologist tracking a migrating population. The population evolves in response to pressures you didn’t create. Your job is to understand where the population is now, predict where it’s going next, and position your observation equipment accordingly.
This means:
Track the vendor-driven evolutionary cycle. When a vendor publishes “Detecting X,” the clock starts ticking on X’s viability. Don’t only write a rule for X — write a rule for what replaces X. Read red team tooling releases with the same attention you give defender content. The attacker’s next move is usually already on GitHub.
Maximize your blind-spot advantage. Your most valuable detections are the ones that don’t appear in any public blog post, any vendor signature database, any rule repository. The behavioral patterns specific to your environment, your telemetry, your understanding of what “normal” looks like for your users and your infrastructure. This is your genuine edge — not because you’re pressuring the attacker, but because you’re operating in a space they can’t see.
Stop measuring your rules against APT tradecraft. Your rules will likely not catch a nation-state operator who has custom tooling and operational security designed to evade the collective vendor ecosystem. That’s not what your rules are for. Your rules catch the other 95% — the ransomware affiliate using Impacket, the insider threat using PowerShell because it’s convenient, the compromised credential being used by someone who doesn’t know your environment. Measure your program against the threats you actually face, not the ones that make for exciting conference talks.
Invest in what vendors can’t sell. Vendors sell generic detection. They can’t sell knowledge of your environment’s baseline behavior. They can’t sell understanding of your specific business processes, your users’ access patterns, your network’s normal traffic flows. Every detection you build on environmental knowledge — behavioral baselining, anomaly detection against your data, correlation across your specific telemetry sources — is a detection no vendor can replicate and no attacker can anticipate.
Running the Race
The Red Queen’s race is real in threat detection. But most of us are wrong about who’s running it.
The race is between threat actors and security vendors. It plays out in public — in blog posts and tool releases and CVE disclosures and signature updates. It’s been running for decades and it won’t stop.
Your detection team isn’t in that race. You’re in a different one: the race to understand your own environment faster than it changes. To build detections on knowledge that’s local, behavioral, and invisible to the attacker. To avoid the trap of rewriting public detection content that already lives in your EDR and pretending that makes you a combatant.
The attacker isn’t adapting to you. They don’t know you’re there.
Make that count.
If you enjoyed the article, feel free to connect with me!
www.linkedin.com/in/koifman-daniel
https://x.com/KoifSec
https://koifsec.me
https://bsky.app/profile/koifsec.bsky.social
The Red Queen’s Race: Arms Race Dynamics in Threat Detection 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: https://detect.fyi/the-red-queens-race-arms-race-dynamics-in-threat-detection-4f532a149fda?source=rss----d5fd8f494f6a---4