- Das Ziel: keine Website, sondern der Kern einer Zahlungsinfrastruktur
- Phase eins: Replay-Angriff mit gestohlenen Transaktionsdaten
- Phase zwei: Layer-7-Flut mit einer Session pro IP
- Herkunft: Indonesien, China, Russland – und westliche Infrastruktur als Durchlaufstation
- Wie die Mitigation griff – und wo die Grenze lag
- Was dieser Fall über moderne Angriffsmethodik aussagt
- Drei Erkenntnisse für IT-Verantwortliche
Es war kurz nach halb zwölf nachts. Auf den Dashboards des Security Operations Centers war alles im grünen Bereich. Erst gab eine Handvoll Anfragen pro Minute, was dem entspricht, was für eine .de-Domain zu dieser Uhrzeit zu erwarten war. Doch dann, innerhalb von fünf Minuten, explodierten die Zahlen: Mehr als 900.000 Anfragen gegen eine einzige API. Was wie ein plötzlicher Angriff aussah, war keiner. Der Angriff hatte schon vorher begonnen – er hatte sich nur Zeit gelassen.
Das Ziel: keine Website, sondern der Kern einer Zahlungsinfrastruktur
Bei DDoS-Angriffen denkt man oft als Erstes an überlastete Websites und blockierte Startseiten. Dieser Angriff zielte jedoch auf die API eines europäischen Finanzdienstleisters, der über die Schnittstelle Transaktionen der Kartenterminals in Echtzeit authentifiziert. Jeder Bezahlvorgang an einem Kassenterminal läuft über genau diese Schnittstelle: Das Terminal sendet eine Anfrage, der Server verifiziert die Anfrage und gibt die Transaktion frei oder lehnt sie ab.
APIs dieser Art sind deutlich sensibler als klassische Webanwendungen. Ein Ausfall bedeutet nicht nur eine unerreichbare Seite, sondern auch gescheiterte Zahlungen. Das lässt vermuten, dass die Wahl dieses Angriffsziels kein Zufall war.
Erfahren Sie mehr über eine einfach zu implementierende und äußerst effektive WAAP-Lösung.
Alles aus einer Hand und auf Wunsch als vollständig verwalteter Service.
Phase eins: Replay-Angriff mit gestohlenen Transaktionsdaten
Was diesen Fall besonders macht, ist der Einstieg. Die Angreifer begannen nicht mit roher Gewalt. Bei einem Replay-Angriff fängt ein Angreifer eine legitime Datenübertragung ab – in diesem Fall Authentifizierungsanfragen aus einem echten Kreditkartentransaktionsflow – und sendet diese anschließend erneut an das Zielsystem. Das System erkennt die Anfragen als valide und verarbeitet sie, da sie strukturell identisch mit echten Transaktionen sind.
Die Angreifer hatten also zuvor reale Anfragen abgefangen und nutzten diese als Vorlage, um massenhaft legitim wirkende Requests zu erzeugen. Für die Schutzsysteme sahen sie aus wie echter Traffic, da sie es technisch gesehen auch waren.
Signaturbasierte Erkennungssysteme, die auf bekannte Angriffsmuster prüfen, haben in diesem Fall nicht angeschlagen, da die Requests keine bekannten Angriffssignaturen trugen. Sie enthielten vermeintlich echte Transaktionsdaten.
Phase zwei: Layer-7-Flut mit einer Session pro IP
Nachdem die initiale Replay-Phase die Abwehr sondiert hatte, verschärfte sich der Angriff mit mehr als 900.000 Anfragen, die ausschließlich diesen einen Endpunkt betrafen. Das Traffic-Muster war so gestaltet, dass es organisch wirkte: Eine Session pro IP-Adresse, verteilt über ein globales Netz aus autonomen Systemen.
Kurz vor dem Peak stiegen Unique Sessions und IP-Adressen auf über 4.000 gleichzeitige Quellen an. Die Bandbreite erreichte einen Spitzenwert im einstelligen Gigabit-Bereich. Keine einzelne Quelle war laut genug, um sofort aufzufallen, doch zusammen erzeugten sie eine Last, die zu Fehlermeldungen führte. Der Server konnte die Anzahl der Anfragen schlicht nicht mehr verarbeiten.
Herkunft: Indonesien, China, Russland – und westliche Infrastruktur als Durchlaufstation
Der Traffic kam überwiegend aus Indonesien, China und Russland, gefolgt von den USA, Brasilien, Kolumbien und mehreren europäischen Ländern. Für eine .de-Domain eines europäischen Finanzdienstleisters gibt es in Indonesien jedoch kaum eine reguläre Kundenbasis. Mitten in der Nacht erfolgte ein Angriff aus geografisch weit gestreuten Quellen auf einen API-Endpunkt für Kartenauthentifizierung.
Auffällig ist auch das ASN-Profil der angreifenden Netzwerke: Darunter befinden sich sowohl große Hosting-Provider und Transit-Netzwerke als auch kleinere autonome Systeme. Ein klassisches Zeichen für ein verteiltes Botnet, das legitime Infrastrukturen als „Durchlaufstation“ nutzt.
Wie die Mitigation griff – und wo die Grenze lag
Die Erkennung erfolgte nicht über Signaturen, sondern über Verhaltenskontrollen. Sobald die Schwellenwerte überschritten wurden, griff die Mitigation. Der entscheidende Faktor war, dass zusätzliche Regeln spezifisch für Kreditkartentransaktionspfade eingerichtet wurden – mit einer Begrenzung eindeutiger Identifikatoren pro Quell-IP. Dadurch wurde die Granularität der Erkennung genau dort erhöht, wo der Angriff am stärksten war.
Was dieser Fall über moderne Angriffsmethodik aussagt
Dieser Angriff ist ein Lehrstück für einen Wandel, der sich in den vergangenen Jahren beschleunigt hat. Das klassische DDoS-Bild, bei dem massiver Flood-Traffic Leitungen verstopft, greift zu kurz. Angreifer, die über gestohlene Transaktionsdaten verfügen und diese als Legitimationsgrundlage für ihre Requests nutzen, agieren auf einer anderen Ebene.
Sie kennen den angegriffenen Dienst. Sie wissen, wie valide Requests aussehen. Und sie sind geduldig genug, um Phase eins – den Replay-Angriff – als Sondierungsangriff zu nutzen, bevor in Phase zwei die Last hochgefahren wird.
Drei Erkenntnisse für IT-Verantwortliche
Für den API-Schutz sind eigene Baseline-Profile erforderlich. Generische Rate-Limits bieten keinen ausreichenden Schutz für transaktionskritische APIs. Ohne Kenntnisse darüber, wie normaler Traffic auf einem spezifischen Endpunkt aussieht – zu welcher Uhrzeit, in welcher Session-Tiefe und aus welchen Regionen –, können Anomalien nicht zuverlässig erkannt werden. Baseline-Monitoring pro Endpunkt ist keine Option, sondern Voraussetzung.
Die signaturbasierte Erkennung allein reicht nicht aus. Dieser Angriff hat keine bekannten Signaturen ausgelöst, da er keine trug. Behavioral Detection, also die Analyse von Verhaltensmustern anstelle von Payload-Signaturen, war der einzige wirksame Mechanismus. Wer ausschließlich auf WAF-Signaturen vertraut, hat gegen Replay-Angriffe mit validen Payloads keine wirksamen Mittel.
Incident Response ist Teamarbeit mit dem Kunden. In diesem Fall war die schnelle Einbindung des Kunden mitentscheidend. Wer Kommunikationswege, Eskalationspfade und gemeinsame Monitoring-Übersichten erst im Angriffsfall abstimmt, verliert wertvolle Zeit.
Manchmal täuscht der Traffic. Die Aufgabe besteht darin, früher zu erkennen, wann dies der Fall ist, und die Werkzeuge so einzurichten, dass sich diese Frage überhaupt stellen lässt.
Sie wollen Ihre Systeme prüfen und Ihre Werkzeuge entsprechend einrichten? Kommen Sie jederzeit gerne auf uns zu und sprechen Sie mit einem unserer Experten.
Das könnte Ihnen auch gefallen:
