惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

I
InfoQ
G
Google Developers Blog
Engineering at Meta
Engineering at Meta
月光博客
月光博客
博客园 - 聂微东
博客园 - Franky
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
有赞技术团队
有赞技术团队
A
About on SuperTechFans
Microsoft Azure Blog
Microsoft Azure Blog
Blog — PlanetScale
Blog — PlanetScale
U
Unit 42
T
Tailwind CSS Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
云风的 BLOG
云风的 BLOG
S
SegmentFault 最新的问题
F
Fortinet All Blogs
H
Help Net Security
J
Java Code Geeks
酷 壳 – CoolShell
酷 壳 – CoolShell
博客园 - 叶小钗
L
LangChain Blog
Martin Fowler
Martin Fowler
N
Netflix TechBlog - Medium

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
45% of Hostile Bot Traffic Passes Your WAF. Here's Why. W...
BotConductSt · 2026-04-30 · via DEV Community

Most enterprise WAFs are configured to block IPs above a certain abuse confidence threshold. AbuseIPDB threshold 50 is a common SOC default. The assumption is that hostile traffic gets caught at the gate.

We tested that assumption.

Of 240 hostile actors detected by behavior on our infrastructure over 19 days, operating from 380 distinct IPs, 45% have AbuseIPDB scores below 50. They pass standard WAF configurations because their IPs aren't reported enough times to trigger blocking. They behave hostile but they don't yet have the reputation to match.

Here's what we found, and what it means.


The data

We cross-referenced a sample of 100 hostile actors detected by behavioral analysis against two public threat intelligence sources: GreyNoise Community API and AbuseIPDB.

The methodology was simple. For each IP we asked: does any public threat feed know this is hostile?

The results, ordered by threshold:

Threshold % of hostile actors that pass
0 reports (completely unknown) 18%
0-2 reports (noise level) 25%
0-5 reports (under the radar) 30%
Score below 25 (typical SOC threshold) 32%
Score below 50 (typical WAF threshold) 45%

The 45% figure is operational. It's not "completely invisible to threat intel." It's "low enough confidence that automated systems leave them alone."


Why this happens

Public threat intelligence works by aggregation. Someone has to report an IP. Multiple reports increase confidence. Eventually the IP crosses thresholds and gets blocked.

That model breaks against actors who do three things:

One: rotate infrastructure aggressively. A single hostile actor using residential proxies through providers like Chiron Software LLC operates from IPs that look like home internet connections. Those IPs cycle out before they accumulate reports.

Two: stay below volume thresholds. An actor making 5-15 requests per IP, then rotating, never triggers per-IP detection. The aggregate behavior is hostile. The per-IP behavior looks like noise.

Three: target sites that don't report. Most websites block hostile traffic silently. They don't submit IPs to public databases. The hostile activity happens but never enters the threat feed loop.

The result is a class of actors that operate hostile, persist for weeks, and remain technically invisible to reputation-based defenses.


What 18% completely invisible looks like

The cleanest data point is the 18% who have zero reports anywhere. We checked the profile of those 18 IPs:

  • 12 of 18 (67%) belong to Chiron Software LLC, a US residential proxy provider
  • 14 of 18 (78%) are categorized as "Fixed Line ISP"
  • 13 of 18 (72%) geolocate to United States

Translation: hostile actors are running through US residential proxy networks and getting traffic that looks like home internet users. There's nothing in the IP metadata that triggers suspicion. The only way to identify them is to look at what they do, not who they are.


What this means operationally

If you depend on IP reputation to filter traffic, you're catching the actors who already burned their cover. The careful operators slip through.

Three concrete implications.

For SOC teams: AbuseIPDB threshold 50 catches the loud actors but misses 45% of the careful ones. Lowering threshold catches more but generates noise. The structural problem is that reputation-based detection has a built-in delay. By the time an IP earns a reputation, the actor has rotated to a new one.

For compliance and audit: "We block known malicious IPs" is a defensible technical statement that doesn't reflect reality on the ground. The hostile traffic on your infrastructure isn't all coming from known-bad addresses. A meaningful portion is coming from addresses that no public source has flagged.

For procurement of security tools: Vendors that price by IP reputation feeds are pricing the easier 55%. The harder 45% requires behavioral measurement that most current tooling doesn't do.


How we detected what threat feeds missed

The actors that pass WAFs aren't invisible to behavioral observation. We detected them through behavioral trajectory analysis -- patterns in how they navigate, what they request first, how their sessions evolve over days, and inconsistencies between their declared identity and their technical fingerprint.

None of these signals require knowing who the actor is. All of them produce evidence that holds up under audit.

The structural difference between behavioral detection and reputation-based detection is timing. Reputation tells you what an IP did somewhere else, after someone reported it. Behavior tells you what an actor is doing on your infrastructure, right now, before anyone else sees it.


What we're publishing next

The full Bot Conduct Report 2026 will cover all 421 actors observed across 19 days, with behavioral profiles, infrastructure mapping, and the methodology in detail.

For now, the practical takeaway is narrow and verifiable: if your defense depends on IP reputation, 45% of hostile traffic is configured to walk past it.

If you want to see what hostile traffic looks like on your specific infrastructure, our Site Risk Assessment produces an independent forensic report.

Full write-up: https://botconduct.org/blog/waf-bypass-45-percent/


Methodology details available on request. Data from BotConduct Observatory, April 2026.