Gefälschte Auskunftsersuchen von Behörden: der Revolut-Fall

Revolut hat sensible Kundendaten an einen unautorisierten Dritten herausgegeben. Die betrügerischen Anfragen kamen von einer legitimen Behörden-E-Mail-Domain. Das britische Fintech bestätigte das am 12. September 2026. Laut Security Affairs wurde dabei kein System kompromittiert, es kam keine Schadsoftware zum Einsatz und auf die Server hat niemand von außen zugegriffen.

Was ist ein Auskunftsersuchen von Behörden?

Ein Auskunftsersuchen ist die Aufforderung einer Behörde an ein Unternehmen, personenbezogene Daten herauszugeben. Die Notfallvariante heißt im Englischen Emergency Data Request. Sie kann nach der Definition des FBI in Notfällen genutzt werden, um Informationen sofort von einem Unternehmen anzufordern und zusätzliche Prüfungen der Rechtmäßigkeit zu umgehen.

Das FBI warnte am 4. November 2024 mit der Private Industry Notification 20241104-001 vor diesem Muster. Kompromittierte E-Mail-Adressen US-amerikanischer und ausländischer Behörden würden demnach für betrügerische Notfall-Datenanfragen an Unternehmen in den USA genutzt.

Das Muster gehört zu Phishing und zum Social Engineering, auch wenn keine Zugangsdaten abgefragt werden. Ziel des Angriffs ist der Freigabeprozess im Unternehmen.

Revolut-Datenleck ohne technischen Einbruch

Die Anfrage kam nach Darstellung von Revolut aus einem unautorisierten E-Mail-Konto, das direkt die offizielle Domain der Behörde nutzte. Weil sie gültige Merkmale der Domain-Authentifizierung trug, wurde sie nach Angaben des Unternehmens in der begründeten Annahme bearbeitet, es handele sich um eine echte Behördenanfrage. Ob der Angreifer dieses Konto neu anlegte oder ein bestehendes übernahm, hält Security Affairs offen.

Revolut spricht gegenüber TechCrunch von einer „begrenzten" Zahl betroffener Kunden und nennt keine absolute Zahl. Die Frage, ob der Vorfall auf einen einzelnen Markt begrenzt war, beantwortete das Unternehmen nicht. Welche Behörde beteiligt war, nannte es ebenfalls nicht. Auch die Zahl der bearbeiteten betrügerischen Anfragen hat es nach Darstellung von Hackread nicht offengelegt. Die Kategorien der abgeflossenen Daten hat das Unternehmen dagegen im Einzelnen aufgeführt:

• Identitätsdaten: vollständiger Name, Geburtsdatum, Beruf
• Kontaktdaten: Postanschrift, E-Mail-Adresse und Telefonnummer
• Dokument- und Verifizierungsdaten: Kopie des Ausweisdokuments, also Reisepass und/oder Führerschein, dazu das Selfie aus der Gesichtsverifikation
• Finanzdaten: Kontoauszüge inklusive IBAN, Kontostatus, Eröffnungsdatum und Wallet-Referenznummer, dazu Auszahlungsdaten und die vollständige Transaktionshistorie einschließlich Bitcoin

Biometrische Gesichtstelemetrie war nach Angaben des Unternehmens nicht betroffen.

Ein Sprecher nannte den Vorfall gegenüber TechCrunch einen ausgeklügelten Betrug mit vorgetäuschter Identität. Ein unautorisierter Dritter habe über eine legitime Behördendomain betrügerische Auskunftsanfragen gestellt, Systeme und Kundengelder seien nicht betroffen. Gegenüber Hackread ergänzte das Unternehmen, die Adresse sei sofort blockiert und Behörde, Strafverfolgung und Aufsicht seien informiert worden. Der Sicherheitsforscher ZachXBT schrieb, der Vorfall scheine auf vermögende Nutzer gezielt zu haben; öffentlich bestätigt hat Revolut das nicht.

Aufgefallen ist der Betrug erst, weil Revolut die Behörde von sich aus kontaktierte und dort erfuhr, dass die Anfrage nie gestellt worden war. Genau diese Rückfrage fehlte vor der Herausgabe.

Warum SPF, DKIM und DMARC keine Identitätsprüfung ersetzen

Nach Darstellung von Börse Express passierte die Anfrage die gängigen Sicherheitsmechanismen zur Domain-Authentifizierung, woraufhin Revolut sie als legitim einstufte. Die Kundenmitteilung selbst spricht nur von gültigen Merkmalen der Domain-Authentifizierung. SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) und DMARC (Domain-based Message Authentication, Reporting and Conformance) nennt erst die Berichterstattung.

CryptoTicker benennt die Grenze dieser Verfahren: Sie beantworten eine einzige Frage, nämlich ob die Nachricht wirklich von dieser Domain kommt. Zur Frage, ob die Person hinter dem Postfach dazu berechtigt ist, sagen sie nichts.

Notwendig bleiben SPF, DKIM und DMARC trotzdem.

Gefälschte Auskunftsersuchen als Social Engineering

Das FBI führt die Zunahme auf mehr Forenbeiträge zum Ablauf von Notfall-Datenanfragen und auf den Handel mit kompromittierten Zugangsdaten zurück. Als früheren Anwender nennt das FBI Lapsus$.

Wie niedrig die Einstiegshürde liegt, dokumentierte KrebsOnSecurity im März 2022. Am 5. April 2021 warb ein Anbieter in einem Untergrundforum für einen Warrant- und Subpoena-Dienst, Preis 100 bis 250 US-Dollar je Anfrage. Hinter dem Angebot stand nach Darstellung von KrebsOnSecurity der damals 14 Jahre alte Gründer des Recursion Team aus dem Vereinigten Königreich. Derselbe Akteur bot ein Behördenpostfach für 150 US-Dollar an, laut Anzeige nutzbar für Subpoena-Anfragen bei Unternehmen wie Apple, Uber und Instagram.

Den Ansatzpunkt im Unternehmensprozess zeigte 2019 eine akademische Studie. Erstautor von „GDPiRated: Stealing Personal Information On- and Offline" (ESORICS 2019) ist Matteo Große-Kampmann, Mitgründer der AWARE7 GmbH. Er publizierte damals unter dem Namen Cagnazzo, Koautoren sind Thorsten Holz und Norbert Pohlmann.

Von 14 gespooften DSGVO-Auskunftsanfragen waren 10 erfolgreich, rund 71 Prozent. In der Hälfte der Fälle erhielten die Forscher sensible Daten wie Finanz- oder Gesundheitsinformationen. Die Ursache benennen die Autoren ausdrücklich als organisatorischen und menschlichen Protokollfehler. Details stehen im Beitrag zum GDPiRate-Angriff auf das DSGVO-Auskunftsrecht.

Dasselbe Grundmuster beschreibt der Beitrag zu CEO-Fraud und Business Email Compromise: vorgetäuschte Autorität und Dringlichkeit führen an der üblichen Freigabe vorbei.

Auskunftsersuchen beantworten: fünf Prüfschritte vor der Herausgabe

Die folgenden Schritte stützen sich auf Empfehlungen des FBI und auf Controls, die ein Managementsystem für Informationssicherheit (ISMS) verlangt.

1. Rechtsgrundlage lesen. Das FBI empfiehlt, die im Ersuchen zitierten Rechtsnormen zu prüfen. Die Normen sollten zu dem passen, was von der ausstellenden Behörde zu erwarten ist.
2. Über einen eigenen Kanal zurückfragen. Bei Zweifeln empfiehlt das FBI, Absender und ausstellende Behörde zu kontaktieren. Die Kontaktdaten dafür stammen aus dem eigenen Verzeichnis, nicht aus der Anfrage. ISO/IEC 27001:2022 verlangt in A.5.5 (Contact with authorities) festzulegen, wann, wie und durch wen Kontakte zu Strafverfolgungs- und Aufsichtsbehörden hergestellt und aufrechterhalten werden.
3. Den Transferweg regeln. A.5.14 (Information transfer) fordert Regeln, Verfahren und Vereinbarungen für den Transfer von Informationen zwischen der Organisation und externen Parteien. Die Herausgabe an eine Behörde ist ein solcher Transfer.
4. Die Freigabe trennen. A.5.3 (Segregation of duties) verlangt, miteinander in Konflikt stehende Aufgaben und Verantwortlichkeiten zu trennen, um Betrugs- und Umgehungsrisiken zu senken.
5. Die Offenlegung protokollieren. ISO/IEC 27701 verlangt Aufzeichnungen über die Offenlegung personenbezogener Daten an Dritte. Ohne dieses Protokoll lässt sich der Umfang der Herausgabe später nicht rekonstruieren.

Vier-Augen-Prinzip bei der Freigabe von Kundendaten

Das Vier-Augen-Prinzip ist die praktische Form der Funktionstrennung: Wer eine Anfrage bearbeitet, gibt die Herausgabe nicht allein frei.

ISO/IEC 27701 geht für Auftragsverarbeiter und verantwortliche Stellen weiter. Anträge auf Offenlegung personenbezogener Daten, die nicht rechtlich verbindlich oder nicht ordnungsgemäß verifiziert sind, sind abzulehnen. Ein ISMS nach ISO/IEC 27001 hält dafür ein dokumentiertes Verfahren vor.

Meldepflichten nach einem Datenschutzvorfall

Eine unbefugte Offenlegung personenbezogener Daten ist eine Verletzung des Schutzes personenbezogener Daten. Art. 33 DSGVO verlangt die Meldung an die zuständige Aufsichtsbehörde unverzüglich und möglichst binnen 72 Stunden, nachdem dem Verantwortlichen die Verletzung bekannt wurde. Die Meldung entfällt, wenn die Verletzung voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen führt. Art. 34 verlangt die Benachrichtigung der betroffenen Personen, wenn die Verletzung voraussichtlich ein hohes Risiko für ihre Rechte und Freiheiten zur Folge hat.

Für Revolut ist nach den eigenen Datenschutzhinweisen die litauische Datenschutzaufsicht federführende Behörde.

Art. 32 Abs. 1 lit. d DSGVO fordert zusätzlich „ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der technischen und organisatorischen Maßnahmen zur Gewährleistung der Sicherheit der Verarbeitung". Gefordert ist das Verfahren, nicht der einzelne bestandene Durchlauf. Eine bestandene E-Mail-Authentifizierung ist eine technische Maßnahme, der Freigabeprozess die organisatorische. Nachweisbar wird beides nur über dokumentierte Verfahren.

Für Finanzunternehmen in der EU kommen die DORA-Anforderungen hinzu. Art. 18 der Verordnung (EU) 2022/2554 verlangt die Klassifizierung von IKT-bezogenen Vorfällen, Art. 19 die Meldung schwerwiegender Vorfälle an die zuständige Behörde. Für Einrichtungen im Anwendungsbereich der NIS2-Richtlinie verlangt Art. 21 Risikomanagementmaßnahmen im Bereich der Cybersicherheit.

Einordnung

Die Studie von 2019 und die FBI-Warnung von 2024 beschreiben dieselbe Lücke im Freigabeprozess. Der Revolut-Fall zeigt sie 2026 bei einem regulierten Finanzunternehmen. Die Domain war echt und die Merkmale der Authentifizierung waren gültig; offen blieb, wer das Postfach benutzte. Geschlossen wird diese Lücke vor der Herausgabe, durch die Rückfrage über einen eigenen Kanal und die getrennte Freigabe.

Quellen

• TechCrunch: Revolut confirms customer data breach through fake government requests (12.09.2026)
• Security Affairs: Revolut exposed KYC data after fraudulent government email passed security checks (12.09.2026)
• Hackread: Revolut gave customer data to scammers after fake requests (12.09.2026)
• Börse Express: Revolut-Datenleck, Behörden-E-Mail täuscht Sicherheitsfilter (12.09.2026)
• CryptoTicker: Revolut-Datenleck, was Betroffene prüfen sollten (12.09.2026)
• FBI: Easy Access to Information for Conducting Fraudulent Emergency Data Requests Impacts US-Based Companies and Law Enforcement Agencies, Private Industry Notification 20241104-001 (04.11.2024)
• KrebsOnSecurity: Hackers Gaining Power of Subpoena Via Fake „Emergency Data Requests" (03/2022)
• Cagnazzo, Holz, Pohlmann: GDPiRated, Stealing Personal Information On- and Offline, ESORICS 2019
• Verordnung (EU) 2016/679 (DSGVO), Art. 32 Abs. 1 lit. d, Art. 33 und Art. 34
• Verordnung (EU) 2022/2554 (DORA), Art. 18 und Art. 19
• Richtlinie (EU) 2022/2555 (NIS2), Art. 21, Risikomanagementmaßnahmen im Bereich der Cybersicherheit