How to Pull Off a Near Undetectable DDoS Attack Using DNS

How to Pull Off a Near-Undetectable DDoS Attack Using DNS

Speaker: Simon Wijckmans

Conference: BSidesSF 2025 — April 26-27, 2025, San Francisco

YouTube: Watch the full talk

Reading time: ~7 minutes

TL;DR

Simon Wijckmans, founder of c/side (formerly Csides), demonstrated how an attacker could build a nearly undetectable DDoS botnet using nothing but malicious JavaScript running in legitimate human browsers — no malware installation required, no suspicious IP addresses, no IoT devices. The attack exploits the structural neglect of client-side security and would defeat virtually every existing DDoS mitigation technique. The defense, frustratingly, must also begin on the client side.

Introduction

DDoS mitigation has a well-established set of tools: IP rate limiting, ASN blocking, layer-3 packet inspection, client hello fingerprinting, CAPTCHAs, and challenge-response mechanisms. For the past decade, the security industry has poured resources into detecting and absorbing volumetric attacks, primarily because the most common attack sources — compromised cloud servers, IoT device botnets, consumer router infections — leave detectable signatures.

Simon Wijckmans's talk at BSidesSF 2025 presented a threat model that defeats all of those defenses simultaneously. By building a botnet from legitimate human browsers, using JavaScript distributed through existing web infrastructure rather than installed malware, an attacker can launch a Layer 7 DDoS attack with residential IP addresses, full SSL decryption, complete browser rendering — and no meaningful fingerprint distinguishable from normal human traffic.

Wijckmans is the founder of c/side, a client-side security company, and previously worked at Microsoft, Cloudflare, and Vercel. Much of his experience at Cloudflare informed this talk's analysis of both how DDoS attacks are typically built and why this new variant evades standard defenses.

Why Existing DDoS Sources Are Detectable

▶ Watch: Traditional DDoS attack vectors and their detection signatures (04:00)

Wijckmans walked through the two most common DDoS botnet sources and why they are detectable.

Cloud server botnets are easy to identify. Traffic from AWS, Azure, or GCP IP ranges is inherently suspicious for most consumer-facing websites. The IP addresses belong to known ASNs, and blocking cloud provider IP ranges — while imperfect — is a standard defensive option. Additionally, cloud servers run recognizable operating systems and expose distinctive TLS fingerprints.

IoT device botnets are harder to block by IP, but IoT devices run lightweight, constrained operating systems that produce distinctive network behavior. Their packet sizes, TLS client hello parameters, and HTTP header signatures differ from real human browsers in ways that modern bot detection systems can fingerprint.

The result, Wijckmans noted, is that the DDoS mitigation industry has built an impressive and expensive apparatus for detecting traffic that doesn't look like it came from a real human browser. The obvious adversarial response is to use traffic that actually comes from real human browsers.

Building the Ideal DDoS: The Attacker's Design Constraints

▶ Watch: Designing a browser-based DDoS botnet (08:00)

Wijckmans framed the attack design as an engineering problem: if you wanted to build the most effective DDoS possible, what would the requirements be?

• Real human browsers (Chromium-based), not headless or emulated browsers
• No malware installation required — getting users to install something requires marketing, creates evidence trails, and is logistically expensive
• Residential IP addresses, not datacenter ranges
• No IoT devices with their lightweight OS fingerprints
• Layer 7 execution, post-SSL decryption, so the defending DDoS protection company must expend maximum compute to evaluate each request

All of these requirements are satisfied by a single mechanism: malicious JavaScript running inside a legitimate browser without the user's knowledge. The browser handles SSL, full page rendering, and executes HTTP requests with a complete, authentic browser fingerprint. The IP address is genuinely residential. No malware was installed.

The remaining question is distribution: how do you get JavaScript running in thousands or hundreds of thousands of browsers?

The JavaScript Distribution Attack Surface

▶ Watch: Methods for injecting JavaScript into target browsers (10:00)

Wijckmans outlined several distribution mechanisms, ranging from sophisticated to almost trivially easy.

Compromised ad networks. The secondary and tertiary ad network ecosystem — particularly networks that serve gambling, adult content, and high-traffic but lower-reputation sites — has minimal security investment and significant CVE exposure. Placing malicious JavaScript through an ad network can reach tens of thousands of active browsers with a single buy.

Unpatched CVEs in marketing scripts. Wijckmans cited the 2024 Polyfill attack: a domain acquired by a Chinese-affiliated organization was held for six months before the attack was executed, exploiting the fact that the Polyfill JavaScript library was included by hundreds of thousands of websites. The attack surface doesn't require supply chain attacks on major vendors — there are many twenty-year-old marketing analytics companies with severe server-side CVEs that have been unpatched for years.

Expired S3 buckets. This is, Wijckmans said, the easiest vector of all. When JavaScript files are served from S3 buckets and those buckets expire without being removed from the website's code, anyone can register the bucket name and begin serving content from it to every site that still references the old URL. c/side runs tooling that automatically registers such buckets when they detect them, specifically to prevent attackers from doing so first.

NPM dependency hijacking. An open-source JavaScript dependency with sufficient reach is a ready-made distribution mechanism for anyone who can push a malicious update or acquire the package.

Four JavaScript DDoS Execution Methods

Once JavaScript is running in a target browser, there are four primary ways to execute the DDoS:

▶ Watch: JavaScript execution techniques for DDoS attacks (12:00)

1. Direct fetch flooding. A simple JavaScript fetch() loop that continuously requests the target domain. A browser executing 100 requests per second, multiplied across 10,000 active sessions, produces one million requests per second — sufficient to take down any medium-sized business.

1. Hidden iframe loading. An invisible iframe is created pointing to the victim's domain. The browser loads and renders the entire page, consuming server resources at the target and producing full Layer 7 traffic indistinguishable from a legitimate user.

1. Web Worker-based flooding. A background web worker executes the fetch flooding independently of the main browser thread, making it invisible to the user and resilient to tab switching or navigation.

1. Hidden window.open tab floods. While Chrome has improved its handling of tab flood attempts, hidden tabs can still be created programmatically and made invisible to the user. Each hidden tab renders the victim's page, contributing to the attack.

Wijckmans ran the math: 10,000 active browsers producing 100 requests per second each generates one million requests per second. Scale that across a larger distribution — not difficult with a compromised ad network — and the numbers become capable of disrupting infrastructure at a national level.

The critical point: all of these attacks originate from real human browsers, on real residential IP addresses, executing full Layer 7 requests with complete TLS handshakes and authentic browser fingerprints. CAPTCHA bypass libraries exist and are lightweight enough to include alongside the attacking code. IP reputation feeds and threat intelligence are irrelevant — these are grandparents and students and office workers browsing the web.

What Site Owners Can Do

▶ Watch: Defensive options and their limitations (14:01)

The defensive options are more limited than most organizations realize, and they all begin on the client side — meaning the attack must be stopped at the source rather than at the destination.

Content Security Policy (CSP). A properly configured CSP restricts which third-party scripts can execute in the browser. This is the highest-leverage defensive control, but Wijckmans noted that CSP deployment remains poor across the web.

Subresource Integrity (SRI). Hashing of JavaScript assets to detect tampering. SRI is effective for static scripts but does not handle dynamic or frequently-updated scripts — which is most of the modern JavaScript ecosystem. A new specification for SRI is under development in the W3C that includes reporting endpoints to surface violations.

Script governance processes. The most underrated defense: having a formal process for evaluating any third-party script before it is added to a production codebase. A marketing intern requesting addition of an obscure SEO-boosting script from an unrecognized vendor is a real and common attack vector. The question every engineering team should be able to answer is: what is the process for approving client-side script additions?

Trust established vendors. Wijckmans noted he has never seen a client-side injection originate from Google Analytics. Companies with resources and reputations to protect maintain their security posture. The risk concentrates in small, obscure, or legacy scripts whose maintainers lack both the incentive and the capacity to secure them.

The fundamental conclusion is uncomfortable: stopping this attack at the target is extremely difficult because the traffic is indistinguishable from legitimate users. The real intervention point is the script distribution mechanism itself — which requires the security community to treat client-side script governance as seriously as it treats server-side security.

Notable Quotes

"If I could get my hands on a whole bunch of real human browsers, that would be great. Real Chromium browsers, on residential IP addresses, no malware installed, Layer 7 execution, post-SSL decryption."

— Simon Wijckmans, ▶ 08:00

"Ten thousand active laptops loading your JavaScript, each browser doing a hundred requests a second — now you've ended up with a million requests a second. You could take down pretty much any medium-sized business very easily. Amplify that to just the numbers, and you basically can take down an entire country."

— Simon Wijckmans, ▶ 14:01

"S3 buckets do expire, and people do forget to remove them from client-side code. We have a little tool that when we see one of those S3 buckets, we automatically register it again — because we know it's just a matter of time before somebody does, and we'd rather have it ourselves."

— Simon Wijckmans, ▶ 10:00

Key Takeaways

• Browser-based botnets defeat all existing DDoS fingerprinting. Real human browsers on residential IPs, executing full Layer 7 HTTP requests with valid TLS, produce traffic that is definitionally indistinguishable from legitimate users. IP reputation feeds, ASN blocking, and CAPTCHA challenges all fail against this model.
• JavaScript distribution is easier than most organizations assume. Compromised ad networks, expired S3 buckets, unpatched CVEs in legacy marketing scripts, and compromised NPM packages all represent viable, low-cost distribution channels for attacker-controlled JavaScript.
• The math is brutal. 10,000 browsers at 100 requests/second equals 1 million requests/second — enough to take down a medium business. The infrastructure to recruit 10,000 browsers through cheap ad networks costs less than a dark web botnet rental.
• Defense must happen at the source. Stopping this attack at the target is structurally difficult. The real leverage is controlling which third-party scripts execute in one's own application — through CSP, SRI, formal script governance, and vendor vetting.
• Client-side security has been chronically neglected. The gap between investment in server-side and endpoint security versus client-side security is large, widely known, and actively exploited. The browser is a full compute environment, and what runs in it is largely unmonitored.