← Übersicht

#derimeter: Erpresser listen die Deutsche Bank – und die Ausrede „nur ein Dienstleister" ist seit DORA keine mehr

#derimeter: Erpresser listen die Deutsche Bank – und die Ausrede „nur ein Dienstleister" ist seit DORA keine mehr

5,5 Gigabyte, Frist bis 15. Juli: Was hinter der Erpressung gegen die Deutsche Bank steckt

5,5 Gigabyte wollen die Erpresser von Unsafe bei der Deutschen Bank erbeutet haben. Die Bank sagt: Betroffen war nur ein externer Dienstleister. Warum diese Grenze für Angreifer nicht existiert, für die Aufsicht seit DORA nicht mehr zählt – und was bis zum 15. Juli passieren muss.

5,5 Gigabyte, Frist bis 15. Juli: Was hinter der Erpressung gegen die Deutsche Bank steckt
5,5 Gigabyte, Frist bis 15. Juli: Was hinter der Erpressung gegen die Deutsche Bank steckt

Am Abend des 4. Juli, tauchte die Deutsche Bank auf der Leak-Seite einer Erpressergruppe auf, die sich „Unsafe" nennt. Die Behauptung: 5,5 Gigabyte Daten, erbeutet aus den Systemen des größten deutschen Kreditinstituts. Als Beleg präsentieren die Angreifer Terminal-Mitschnitte, Verzeichnisstrukturen und Datenbankauszüge – darunter Mitarbeiter-Mailadressen, Passwort-Hashes und Anschriften. Die Frist läuft bis zum 15. Juli. Dann, so die Drohung, wird veröffentlicht.


Die Deutsche Bank hat zwischenzeitlich reagiert, die Antwort verdient jedoch genaues Hinsehen. Man sei über einen Cyber-Sicherheitsvorfall „bei einem externen Dienstleister in Deutschland" informiert worden, der eine Marketing- und Incentive-Plattform für Vertriebspartner betreibt, so ein Sprecher der Bank. Es gebe keine Anhaltspunkte, dass interne Systeme oder Netzwerke der Bank betroffen seien, und keine Hinweise auf einen unbefugten Zugriff auf das Banknetzwerk.


Man möchte sagen: Es war nicht die Bank. Sondern der Dienstleister. Das mag technisch zutreffen. Als Entwarnung taugt es weniger – und als Verteidigungslinie gegenüber Aufsicht, Kunden und Vertriebspartnern schon gar nicht.


Was "Unsafe" behauptet – und was davon belastbar ist


Zunächst die Faktenlage: Die Echtheit der präsentierten Daten ist unabhängig nicht bestätigt. Threat-Intelligence-Analysten, die die Proben ausgewertet haben, beschreiben Terminal-Historien mit automatisierten Dateiübertragungen über einen Server der Domain db.com, aktive SFTP-Verbindungspfade sowie Ordnerstrukturen, die auf Transaktionsdaten, Zugriffskontroll-Reports und SAP-Verarbeitung hindeuten sollen. Das klingt spezifisch, beweisen tut es aber noch nichts. Sicherheitsexperten weisen darauf hin, dass die Ausschnitte plausibel wirken, aber ebenso aus älteren Lecks recycelt oder schlicht KI-gestützt fabriziert sein könnten – die Branche hat mit aufgewärmtem Material aus Altvorfällen reichlich Erfahrung.


Dazu passt, dass über die Gruppe selbst wenig Gesichertes bekannt ist. Je nach Quelle ist Unsafe ein Ransomware-as-a-Service-Akteur, der seit 2022 existiert und 2026 nach längerer Pause aggressiv zurückgekehrt ist – oder eine im Juli 2026 erstmals aufgetauchte Marke mit gerade einmal zwei behaupteten Opfern. Beide Versionen kursieren in seriösen Auswertungen. Sicher ist nur: Eine Listung auf einer Leak-Seite ist zunächst ein Druckmittel, kein Beweis. Der Eintrag selbst ist Teil der Erpressung, lange bevor ein einziger Datensatz verifiziert wurde.


Wer den Fall deshalb als (noch) nicht relevant abtut, macht es sich allerdings zu einfach. Denn die Bank bestreitet den Vorfall nicht. Sie verortet ihn nur – beim Dienstleister.


Der Dienstleister ist immer schuld


Die Unterscheidung zwischen „unseren Systemen" und die „des Dienstleisters" ist juristisch sauber und kommunikativ bewährt. Sie hat nur eine Schwachstelle: Für die Angreifer existiert diese Differenzierung nicht. Eine Plattform für Vertriebspartner verarbeitet Daten von Menschen, die im Namen der Deutschen Bank Finanzprodukte verkaufen. Wer dort Mailadressen, Passwort-Hashes oder Anschriften abgreift, hat Material für präzise Phishing-Kampagnen gegen genau die Personengruppe, die Zugang zu Kundenbeziehungen und Vertriebssystemen hat. Ob der Einstiegspunkt im Rechenzentrum der Bank lag oder bei einem Dienstleister in Deutschland, ist für die Verwertbarkeit der Daten zweitrangig.


Daniel Schoenland, CEO des Cybersicherheits-Spezialisten Identiqa, definiert das Problem so: „Angreifer brechen heute nicht mehr ein – sie loggen sich ein. Mit gestohlenen Credentials oder schlicht über Phishing-Angriffe. Aus Angreifersicht ist ein funktionierendes Login ein Einfallstor, egal ob dieses aus dem Kernbankensystem stammt oder von der Incentive-Plattform eines Dienstleisters. Wer seine Sicherheitsarchitektur an der eigenen Firewall enden lässt, hat das Vorgehen von Angreifern nicht verstanden."


Genau dieses Vorgehen zeichnet der Fall nach. Die großen Finanzhäuser haben ihre Kernsysteme in den vergangenen Jahren zwar massiv gehärtet – aber die Angreifer haben die Konsequenz gezogen: Sie greifen dort an, wo dieselben wertvollen Daten und Beziehungen liegen; dort wo Schwachstellen existieren. Marketing-Plattformen, Incentive-Portale, Partnersysteme. Die Peripherie ist das neue Einfallstor.


DORA kennt kein „nur der Dienstleister"


Und hier wird aus dem Vorfall ein regulatorisches Thema. Seit Januar 2025 gilt DORA – und die Verordnung wurde genau für diese Konstellation geschrieben. Finanzinstitute sind seither ausdrücklich für das Risikomanagement ihrer Drittdienstleister verantwortlich: Sie müssen ihre Auslagerungen in einem Informationsregister führen, vertragliche Sicherheits- und Auskunftspflichten durchsetzen und Vorfälle in der Lieferkette in ihr eigenes Meldewesen integrieren. Die Grundidee der Verordnung lässt sich in einem Satz zusammenfassen: Verantwortung lässt sich auslagern, Haftung nicht.


Ob die betroffene Marketing-Plattform formal als Dienstleistung im Sinne der Verordnung eingestuft ist, wird das Nachspiel zeigen – und parallel stellen sich datenschutzrechtliche Fragen, denn personenbezogene Daten von Vertriebspartnern bleiben personenbezogene Daten, gleich wo sie verarbeitet werden. Aber die aufsichtliche Stoßrichtung ist eindeutig. Die Zeiten, in denen ein Finanzinstitut einen Vorfall mit dem Verweis auf den Dienstleister kommunikativ abschließen konnte, sind vorbei. Die Fragen, die BaFin und EZB-Aufsicht in solchen Fällen stellen, lauten nicht „War Ihr Netzwerk betroffen?", sondern: Welche Daten lagen dort? Wer hat die Sicherheit des Dienstleisters wann zuletzt geprüft? Und warum erfährt die Öffentlichkeit von einer Erpressergruppe davon – nicht vom Institut?


Die Deutsche Bank kennt das Muster aus eigener Erfahrung. Schon 2023 gehörte die Bank zu den Instituten, deren Daten über den kompromittierten Dateitransferdienst MOVEit abflossen – auch damals lag der Einstiegspunkt nicht im eigenen Haus. Die Lektion, dass die eigene Angriffsfläche an der Vertragsgrenze nicht endet, ist für Frankfurt also nicht neu. Umso bemerkenswerter, dass die Kommunikation drei Jahre später demselben Reflex folgt.


Was bis zum 15. Juli spannend wird


Der Fall hat ein eingebautes Verfallsdatum. Läuft die Frist ab, ohne dass gezahlt wird, will Unsafe veröffentlichen – dann lässt sich die Echtheit der 5,5 Gigabyte erstmals unabhängig prüfen. Bis dahin bleiben drei mögliche Szenarien: Die Daten sind echt und aktuell, dann beginnt für die Bank und ihren Dienstleister die eigentliche Arbeit. Die Daten sind recyceltes Altmaterial, dann war die Listung ein Bluff auf Kosten eines prominenten Namens. Oder es verschwindet der Eintrag kommentarlos – was in der Szene üblicherweise bedeutet, dass jemand gezahlt hat.


Für Entscheider außerhalb Frankfurts ist die Lehre unabhängig vom Ausgang dieselbe, und sie zieht sich durch jeden Vorfall dieser Woche: Die eigene Sicherheitslage ist die Summe aller Dienstleister, Plattformen und Partner, die im eigenen Namen Daten verarbeiten. Wer diese Landkarte nicht kennt, verteidigt ein Territorium, dessen Grenzen er nicht gezogen hat. Die Deutsche Bank hat auf diese Karte gerade einen unfreiwilligen Blick gewährt. Der Satz „unsere Systeme waren nicht betroffen" markiert darauf keinen sicheren Ort. Nur einen, an dem die Verantwortung nicht endet.