Im November 2025 wehrte Cloudflare den grössten jemals öffentlich dokumentierten DDoS-Angriff ab: 31,4 Terabit pro Sekunde, während 35 Sekunden. Der Datenverkehr kam nicht aus einem Rechenzentrum. Er kam aus einem Botnet: geschätzt ein bis vier Millionen gekaperte Endgeräte, die meisten davon billige Android-TV-Boxen, deren Besitzer nichts davon wussten.

Genau das ist die entscheidende Eigenschaft eines Botnets, und der Grund, weshalb es hinter fast jedem grossen DDoS-Angriff steckt: Der Angreifer besitzt die Hardware nie selbst. Sie gehört Ihnen. Oder Ihren Kunden.

Was ist ein Botnet?

Ein Botnet ist ein Netzwerk internetfähiger Geräte, die mit Schadsoftware infiziert und unter die Fernsteuerung eines einzelnen Betreibers gestellt wurden, des sogenannten Bot-Herders. Jedes infizierte Gerät ist ein «Bot» (oder «Zombie»). Die Besitzer merken davon fast nie etwas: Das Gerät funktioniert weiter, die Malware arbeitet unauffällig im Hintergrund.

Drei Bausteine machen das System aus:

• Die Bots. Jedes Gerät mit Prozessor und Netzanschluss kommt infrage: Heimrouter, IP-Kameras, Videorekorder, Smart-TVs, Set-Top-Boxen, Cloud-Server, gelegentlich auch PCs. Das Mirai-Botnet von 2016 bestand fast vollständig aus Consumer-IoT-Geräten, das AISURU-Botnet von 2025 aus No-Name-Android-TV-Boxen.
• Der Command-and-Control-Kanal (C2). Die Infrastruktur, über die der Betreiber Befehle erteilt: klassisch ein zentraler Server, in neueren Architekturen ein Peer-to-Peer-Netz ohne zentralen Abschaltpunkt.
• Der Betreiber. Immer öfter nicht dieselbe Person, die das Botnet einsetzt. Grosse Botnets werden als «DDoS-for-hire» vermietet. Wer den Verkehr auf eine Bank richtet, hat dafür womöglich nur ein Abo für wenige Dutzend Dollar bezahlt.

Wie wird ein Gerät zum Bot?

Ohne Zutun des Besitzers. Botnet-Malware findet Geräte selbstständig, indem sie das gesamte Internet nach drei Arten von Schwachstellen absucht:

• Werkseitige Standard-Passwörter. Mirais Methode, bis heute die ergiebigste. Die Malware führt eine kurze Liste von Standard-Zugangsdaten mit (admin/admin, root/12345) und probiert sie bei jedem gefundenen Gerät durch. Gemäss der USENIX-Security-Analyse von 2017 wuchs das Botnet allein damit auf einen Spitzenwert von rund 600’000 infizierten Geräten.
• Ungepatchte Schwachstellen. Consumer-Geräte erhalten selten Updates. Eine Lücke, die heute in einer Router-Firmware bekannt wird, ist Jahre später auf Millionen Geräten noch offen.
• Manipulierte Software und Lieferketten. Das AISURU-Botnet bestand zu grossen Teilen aus kompromittierten No-Name-Android-TV-Boxen: Geräten, die schon manipuliert ausgeliefert wurden, statt nachträglich gehackt zu werden.

Jeder neue Bot beginnt sofort selbst mit der Suche nach weiteren Opfern. Deshalb wachsen Botnets exponentiell: Mirai infizierte in den ersten 20 Stunden fast 65’000 Geräte und verdoppelte sich anfangs etwa alle 76 Minuten.

Wofür werden Botnets eingesetzt?

Ein Botnet bündelt die Ressourcen von Millionen Geräten: Bandbreite, IP-Adressen, Rechenleistung. Betreiber nutzen oder vermieten sie für:

• DDoS-Angriffe. Der wichtigste Einsatzzweck, und das Thema dieses Blogs. Alle Mitglieder fluten gleichzeitig ein Ziel, bis dessen Kapazität erschöpft ist und legitime Nutzer nicht mehr durchkommen.
• Credential Stuffing. Geleakte Zugangsdaten werden gegen Login-Seiten durchprobiert, verteilt über Tausende IPs, sodass kein Rate-Limit anschlägt.
• Spam- und Phishing-Versand. IPs aus Privathaushalten passieren Reputationsfilter, an denen Rechenzentrums-IPs scheitern.
• Residential-Proxy-Netze. Die IP-Adressen der Bots werden an jeden vermietet, dessen Traffic aussehen soll, als käme er aus einem Privathaushalt.
• Kryptomining. Gestohlener Strom und gestohlene Rechenleistung, in grossem Stil.

Warum ist Botnet-Verkehr so schwer zu filtern?

Weil jede Anfrage für sich genommen legitim aussieht. An genau dieser Eigenschaft scheitert naive DDoS-Abwehr:

• Echte Geräte, echte IPs. Der Verkehr stammt von echter Consumer-Hardware an privaten Anschlüssen, aus demselben Adressraum wie Ihre Kunden. Wer nach IP-Reputation blockt, blockt auch Kunden.
• Verteilung. Eine Million Quellen mit je einer Anfrage hebeln jedes Rate-Limiting pro IP aus. Keine einzelne Quelle überschreitet je einen Schwellenwert.
• Echte Browser, echtes Verhalten. Moderne Botnets auf Android-Hardware können echte Browser-Engines starten, JavaScript ausführen und Bot-Erkennung bestehen. Unser Browser-Flood-Beitrag behandelt dieses Szenario im Detail.
• Geografische Streuung. Der Verkehr kommt aus allen Regionen gleichzeitig. Geo-Blocking sperrt Märkte aus, nicht den Angriff.

Die unbequeme Konsequenz für Verteidiger: Ein Filter, der auf «offensichtlich gefälschten» Verkehr geeicht ist, lässt das meiste durch, was ein modernes Botnet sendet.

Von Mirai bis AISURU: Wie gross werden Botnets?

Drei Datenpunkte, jeder zu seiner Zeit ein öffentlicher Rekord, zeigen die Entwicklung:

• September 2016: Mirai gegen KrebsOnSecurity. Über 600 Gbps gegen die Website eines einzelnen Journalisten, aus rund 600’000 infizierten IoT-Geräten (Antonakakis et al., USENIX Security 2017).
• 21. Oktober 2016: Mirai gegen Dyn. Dasselbe Botnet, gerichtet auf einen DNS-Anbieter, nahm Twitter, Netflix, Spotify und Amazon für weite Teile der USA und Europas offline. Angegriffen wurden die Resolver eines einzigen Unternehmens; zu spüren war es im halben Internet.
• November 2025: AISURU gegen Cloudflare-Kunden. 31,4 Tbps, rund das Fünfzigfache des Krebs-Angriffs, aus geschätzt ein bis vier Millionen Geräten, gefolgt von einer HTTP-Kampagne mit über 200 Millionen Anfragen pro Sekunde (Cloudflare DDoS Threat Report, Q3 2025).

Und das Tempo steigt. Allein in den dreizehn Monaten bis November 2025 fiel der öffentliche Rekord vier Mal:

Das Wachstum hat eine einfache Ursache: Jedes Jahr gehen Milliarden billige, ungepatchte, vernetzte Geräte ans Netz, und jedes einzelne ist ein potenzieller Bot.

Was bedeuten Botnets für regulierte Institute?

Für eine Bank, einen Versicherer oder eine Finanzmarktinfrastruktur wird aus der Botnet-Bedrohung eine konkrete regulatorische Erwartung: der Nachweis, dass die eigenen Dienste unter genau dieser Last verfügbar bleiben.

• DORA (Verordnung (EU) 2022/2554) verlangt mindestens jährliche Tests der digitalen operationalen Resilienz für ICT-Systeme, die kritische Funktionen stützen (Artikel 24); szenariobasierte Tests gehören zu den aufgeführten Methoden (Artikel 25).
• Die FINMA erwartet von Schweizer Instituten das Management operationeller Risiken für kritische Dienste, einschliesslich Cyber-Szenarien, gemäss Rundschreiben 2023/1.
• NIS2 (Richtlinie (EU) 2022/2555) verpflichtet wesentliche und wichtige Einrichtungen zu Massnahmen für die Kontinuität ihrer Dienste, einschliesslich Angriffsresilienz (Artikel 21).

Keines dieser Regelwerke akzeptiert «wir haben einen DDoS-Schutz-Vertrag» als Nachweis. Gefragt ist, ob die Abwehr funktioniert. Und das lässt sich nur unter realistischem Druck feststellen.

Wie testet man gegen Verkehr in Botnet-Grössenordnung, ohne Botnet?

Genau für dieses Problem wurde Obsidio gebaut. Ein realistischer Test muss die Eigenschaften reproduzieren, die Botnet-Verkehr gefährlich machen (echte Geräte, private Netze, globale Verteilung, echtes Browser-Verhalten), ohne je ein gekapertes Gerät anzufassen.

Obsidio führt DDoS-Simulationen mit über 100’000 echten, ethisch beschafften Geräten weltweit durch: Hardware, deren Besitzer ihre Kapazität bewusst zur Verfügung stellen, orchestriert in Trusted Execution Environments mit vollständigem Audit-Logging. Der Verkehr ist von einem echten Botnet-Angriff nicht zu unterscheiden, weil er dieselbe Form hat. Aber jede Simulation verlangt einen expliziten Eigentumsnachweis für das Ziel, läuft unter Ihrer Kontrolle mit progressivem Ramp-up und lässt sich anhand von Live-Metriken jederzeit sofort abbrechen.

Mit anderen Worten: der Realismus eines Botnets, mit der Autorisierung, der Kontrolle und den Nachweisen, die ein Compliance-Team braucht. Jeder Lauf erzeugt einen kryptografisch attestierten Bericht, der sich auf die Erwartungen von FINMA, DORA und NIS2 abbilden lässt.

Wenn Sie wissen wollen, wie sich Ihre Abwehr verhält, wenn eine Million harmlos aussehender Anfragen gleichzeitig eintrifft: Unser Leitfaden DDoS-Schutz testen ist der Einstieg. Oder sprechen Sie mit unserem Team über eine kontrollierte Simulation gegen Ihre eigene Infrastruktur.

Die meisten Teams lernen die Grenzen ihres DDoS-Schutzes erst während eines echten Angriffs kennen. Das ist der denkbar schlechteste Zeitpunkt, um festzustellen, dass eine WAF-Regel zu locker war oder ein Origin-Server nie abgeschirmt wurde. Zu wissen, wie Sie Ihren DDoS-Schutz vor einem Vorfall testen, ist der Unterschied zwischen einem kontrollierten Befund und einem öffentlichen Ausfall.

Dieser Leitfaden richtet sich an die Menschen, die dieses Risiko in einem regulierten Institut verantworten: Security-Engineers, Betreiber von WAF und Load Balancern sowie Compliance-Verantwortliche, die Resilienz gegenüber einer Aufsichtsbehörde nachweisen müssen. Er zeigt, was ein sauberer Test misst, wie Sie ihn durchführen, ohne sich selbst offline zu nehmen, und wie Sie das Ergebnis in prüffähige Nachweise verwandeln.

Was das Testen Ihres DDoS-Schutzes wirklich bedeutet

Ein DDoS-Test sendet kontrollierten, realistischen Angriffsverkehr an eine Infrastruktur, die Ihnen gehört, und misst dann, ob Ihre Abwehr ihn absorbiert und wie sich Ihr Dienst unter Last verhält. Ziel ist nicht, die Website lahmzulegen. Ziel ist, den Punkt zu finden, an dem der Schutz nachgibt, damit Sie ihn nach Ihrem eigenen Zeitplan beheben können.

Zwei Dinge ist er nicht:

• Er ist kein Booter oder Stresser. Solche Dienste feuern anonymen Traffic auf beliebige Ziele. Sie sind illegal, sobald sie auf etwas gerichtet werden, das Ihnen nicht gehört, und liefern keine Messung, keinen Autorisierungsnachweis und keinen Bericht.
• Er ist kein gewöhnlicher Lasttest. Ein Lasttest fragt: „Können wir 10.000 legitime Nutzer bedienen?“ Ein DDoS-Test fragt: „Was passiert, wenn der Verkehr feindlich, fehlerhaft oder gezielt darauf ausgelegt ist, eine Ressource zu erschöpfen, die unser Lasttest nie berührt?“ Anderer Verkehr, andere Fehlerbilder.

Der Wert liegt in der Genauigkeit. Ein guter Test sagt Ihnen, welche Schicht versagt hat, bei welchem Volumen und ob Ihre Mitigation rechtzeitig ausgelöst hat.

Autorisierung kommt vor dem ersten Paket

Die eine Regel, die legitimes Resilienztesting von einem Angriff trennt, ist die Autorisierung. Sie testen nur Assets, die Ihnen gehören oder für die Sie ausdrücklich beauftragt sind, und Sie weisen dieses Eigentum nach, bevor Verkehr fliesst.

Obsidio erzwingt das über eine DNS-TXT-Eigentumsverifizierung. Sie hinterlegen einen Eintrag auf der Domain, die Sie testen wollen, und keine Simulation startet, bevor dieser Eintrag bestätigt ist. Läufe sind kontrolliert, werden schrittweise hochgefahren und lassen sich live abbrechen. Das macht die Übung für eine Rechtsabteilung vertretbar und für eine Compliance-Akte wiederholbar: Die Autorisierung ist dokumentiert, nicht unterstellt.

Behandeln Sie das als die erste Kontrolle, die Sie testen, nicht als Formalie. Wenn Ihr eigener Change-Management-Prozess keine unterschriebene, zeitlich begrenzte Autorisierung für einen Test hervorbringt, wird er das auch für einen Vorfall nicht tun.

Die Angriffstypen, gegen die es sich zu testen lohnt

DDoS ist nicht eine einzige Sache, und ein Schutz, der eine Klasse abwehrt, kann für eine andere blind sein. Ein Testprogramm sollte die verschiedenen Arten durchspielen, auf die ein Dienst versagt. Der Simulationskatalog von Obsidio umfasst vier Kategorien, die jeweils einen anderen Teil Ihres Stacks belasten:

• Angriffe auf der Anwendungsschicht (Layer 7). HTTP Flood treibt hohe Mengen wohlgeformter Anfragen gegen den Anwendungspfad: die Request-Queue, die Anwendungs-Threads und die dahinterliegende Datenbank. Goldeneye hängt zufällige Query-Strings an, sodass jede Anfrage den Cache umgeht und den Origin erreicht, mit rotierenden browserähnlichen Headern. Browser Flood nutzt echte Browser-Sitzungen, die die vollständige Seite samt aller Unterressourcen laden und dabei Verkehr erzeugen, der kaum von echten Nutzern zu unterscheiden ist. Apache Killer sendet überlappende Range-Header (CVE-2011-3192), die einen verwundbaren Apache-Build zwingen, den Antwortkörper vielfach im Speicher zu belegen, eine Anfrage mit geringer Rate, die einen ungepatchten Server erschöpfen kann.
• Langsame Angriffe. Slowloris hält viele Verbindungen offen, indem es Teilanfragen tröpfelt und so den Verbindungspool bei nahezu null Bandbreite erschöpft. RUDY öffnet langsame POSTs, die eine wahrheitsgemässe Content-Length ankündigen und den Body dann Byte für Byte senden, wodurch Request-Handler-Worker blockiert werden. Beide prüfen das Verbindungs-Handling und die Timeout-Konfiguration, einen häufigen blinden Fleck bei volumenfokussierten Abwehrmechanismen.
• Verbindungserschöpfung. TLS Flood schliesst den vollständigen TLS-Handshake ab und lässt den Server die Kosten der asymmetrischen Kryptografie tragen, um die Verbindung dann fallen zu lassen. TCP Connection Flood öffnet rohe Verbindungen und hält sie im Leerlauf, um die Verbindungstabelle, Dateideskriptoren und die Accept-Queue zu erschöpfen. Diese testen Kapazitätsgrenzen, die eine ratenbasierte Abwehr nie zu sehen bekommt.
• Protokollspezifisch und skriptgesteuert. DNS Flood sendet rohe DNS-Anfragen über TCP, eine Verbindung pro Anfrage, und belastet damit Resolver-CPU und TCP-Listener-Ressourcen. Puppeteer Script führt einen skriptgesteuerten Ablauf in echten Browsern (Login, Formularabsendung, ein End-to-End-Prozess) mit vielen parallelen Sitzungen aus, für funktionale und synthetische Nutzerlast statt für rohe Anfragerate.

Der Katalog wächst mit den Techniken der Angreifer. Decken Sie beim ersten Test mehrere Kategorien ab: mindestens ein Flood auf Anwendungsebene und ein langsamer oder Verbindungserschöpfungs-Angriff, weil sie unterschiedliche Teile Ihres Stacks zum Versagen bringen.

Eine wiederholbare Methode: Konfigurieren, Testen, Anpassen, Erneut testen

Ein einzelner Test ist eine Momentaufnahme. Resilienz beweist sich durch Wiederholung. Obsidio gliedert jeden Lauf in vier Phasen:

• Autorisieren. Domain-Eigentum per DNS TXT verifizieren, bevor irgendetwas läuft.
• Konfigurieren. Simulationstyp, Umfang, geografische Verteilung und Dauer wählen. Klein anfangen: Ein Lauf mit geringer Intensität bestätigt, dass Ihr Monitoring und Ihr Abbruchpfad funktionieren, bevor Sie das Volumen erhöhen.
• Simulieren. Den kontrollierten Test aus der verteilten Flotte fahren und dabei Live-Metriken beobachten: Anfragen pro Sekunde, Erfolgsquote und übertragene Daten.
• Berichten. Das Ergebnis als attestierten Nachweis dessen exportieren, was passiert ist.

Dann passen Sie an. Eine WAF-Regel justieren, ein Rate-Limit anpassen, ein Timeout erhöhen und erneut testen, um zu belegen, dass die Korrektur wirkt. Der erneute Test ist der Teil, den Teams überspringen, und der Teil, der am meisten zählt. Eine Korrektur, die Sie nicht unter Last verifiziert haben, ist eine Hypothese, keine Kontrolle.

Was realistischer Verkehr erfordert

Ein Test ist nur so ehrlich wie der Verkehr dahinter. Abwehrmechanismen, die sich an offensichtlichen Signaturen orientieren, etwa einem einzelnen Quell-Subnetz, einem festen User-Agent oder Rechenzentrums-IP-Bereichen, „bestehen“ einen Test, der dieselben Merkmale nutzt, und versagen dann gegen ein echtes Botnetz, das das nicht tut.

Obsidio erzeugt Last aus über 100’000 global verteilten, echten Geräten statt aus virtualisierten Instanzen, bezogen von ethisch einwandfreien Anbietern. Der Verkehr kommt von echter Hardware und Smartphones über viele Netze und Regionen hinweg. Sie testen Ihre Abwehr damit gegen etwas, das wie ein echter verteilter Angriff aussieht, und nicht gegen ein Laborartefakt, das Ihre WAF trivial filtern kann.

Einen Test in Compliance-Nachweise verwandeln

Für ein reguliertes Institut ist ein bestandener Test, der keine Spur hinterlässt, wenig wert. Die regulatorischen Rahmenwerke erwarten heute den Nachweis, nicht nur die Bemühung.

Nach dem Digital Operational Resilience Act (DORA) der EU müssen Finanzunternehmen ein Programm für digitale operationale Resilienz betreiben und mindestens jährlich angemessene Tests der IKT-Systeme durchführen, die kritische oder wichtige Funktionen unterstützen (Artikel 24). Bedeutende Institute müssen zusätzlich mindestens alle drei Jahre erweiterte, bedrohungsgeleitete Penetrationstests (TLPT) durchlaufen (Artikel 26). NIS2 verpflichtet wesentliche und wichtige Einrichtungen, Risikomanagementmassnahmen zu ergreifen und zu testen, und die FINMA erwartet von Schweizer Instituten, operationelle Resilienz auf vergleichbarer Grundlage zu steuern.

Was diese Rahmenwerke gemeinsam haben, ist die Forderung nach nachweisbarem, wiederholbarem Testen, also der Art von Sicherheit, die Sie einem Prüfer oder einem Vorstand vorlegen können. Obsidio erzeugt kryptografisch attestierte, manipulationssichere Berichte, die auf FINMA, DORA und NIS2 abgebildet sind und innerhalb von Trusted Execution Environments erstellt werden, sodass das Ergebnis nicht nachträglich stillschweigend verändert werden kann. Das Ergebnis eines Tests wird zum Beleg in Ihrer Compliance-Akte.

Stärke wird bewiesen, nicht versprochen. Ein Test, den Sie attestieren können, macht aus „Wir sind resilient“ etwas, das ein Prüfer überprüfen kann.

Wo Sie anfangen

Wenn Sie Ihren DDoS-Schutz noch nie getestet haben, beginnen Sie mit einem einzelnen autorisierten Lauf geringer Intensität auf Anwendungsebene gegen eine Staging-Umgebung oder ein geplantes Zeitfenster. Beobachten Sie, wie Ihr Monitoring und Ihre Mitigation reagieren, und weiten Sie den Umfang von dort aus. Der erste Test liefert selten ein sauberes Bestehen, und genau deshalb führen Sie ihn durch, bevor es ein Angreifer tut.

Um eine kontrollierte Simulation gegen Ihre eigene Infrastruktur zu planen, nehmen Sie Kontakt mit dem Obsidio-Team auf oder fordern Sie eine Demo an. Unabhängig, neutral, überprüfbar: Resilienz, die Sie beweisen können.