Phishing trotz echtem Absender: Was der Revolut-Fall zeigt – und wie du dich schützt
Echte Behörde, echte Mail-Domain, technisch plausibler Absender – und trotzdem gelangen sensible Kundendaten an Kriminelle. Genau deshalb ist der Revolut-Fall so lehrreich: Moderne Angriffe müssen eine E-Mail nicht mehr sichtbar fälschen. Wenn Angreifer einen legitimen Kommunikationsweg übernehmen oder missbrauchen, reichen die klassischen Tipps „Absender prüfen“ und „auf Rechtschreibfehler achten“ nicht mehr aus.
Der entscheidende Sicherheitsgedanke lautet heute: Ein echter Absender beweist nur die Herkunft einer Nachricht – nicht automatisch die Identität, Absicht oder Berechtigung der Person dahinter. Dieser Ratgeber erklärt, was beim Revolut-Fall bekannt ist, warum technische E-Mail-Prüfungen allein nicht genügen und wie Unternehmen sowie Privatpersonen sensible Anfragen sicher verifizieren können.
Was beim Revolut-Fall passiert ist
Revolut bestätigte im September 2026, sensible Kundendaten an eine nicht autorisierte dritte Partei herausgegeben zu haben. Nach Angaben des Unternehmens waren betrügerische Auskunftsersuchen über die legitime E-Mail-Domain einer staatlichen Stelle eingegangen. Das Problem lag damit nicht in einer offensichtlich nachgebauten Absenderadresse, sondern darin, dass ein vertrauenswürdiger Kommunikationskanal für unberechtigte Anfragen genutzt wurde.
Reuters berichtete, dass Revolut mit Behörden und Aufsichtsstellen zusammenarbeitet und zusätzliche Schutzmaßnahmen eingeführt habe. Das Unternehmen erklärte zugleich, seine eigenen Systeme seien nicht kompromittiert worden und Kundengelder seien nicht betroffen gewesen.
Eine von TechCrunch eingesehene Benachrichtigung an Betroffene nennt als mögliche offengelegte Informationen unter anderem Namen und Kontaktdaten, Geburtsdaten sowie Kopien von Ausweisdokumenten. Je nach betroffenem Konto konnten demnach auch Verifizierungsfotos, Kontoauszüge oder Transaktionshistorien Teil der herausgegebenen Informationen sein. Revolut sprach gegenüber TechCrunch von einer begrenzten Zahl betroffener Kunden.
Warum dieser Angriff so gefährlich ist
Viele Sicherheitsregeln setzen darauf, eine Fälschung zu erkennen: Stimmt die Domain? Ist die Sprache ungewöhnlich? Führt ein Link auf eine fremde Website? Passt die Signatur? Bei klassischem Phishing ist das weiterhin sinnvoll. Doch der Revolut-Fall zeigt die Grenze dieses Modells: Ist ein echter Account oder ein echter Behördenkanal kompromittiert, können gerade die üblichen Echtheitsmerkmale korrekt aussehen.
Das Bundesamt für Sicherheit in der Informationstechnik beschreibt E-Mail-Authentifizierung mit SPF, DKIM und DMARC als wichtigen Schutz gegen Identitätsmissbrauch und Spoofing. Diese Verfahren können prüfen, ob eine Nachricht tatsächlich über einen für die Domain autorisierten Weg versendet wurde. Sie beantworten aber eine andere Frage als die, die im Revolut-Szenario entscheidend ist: Darf die konkrete Person hinter dieser Nachricht diese konkreten Daten tatsächlich anfordern?
Anders gesagt: Eine technisch authentische Nachricht kann inhaltlich trotzdem bösartig sein. Wer Zugang zu einem legitimen Postfach oder System erlangt, kann die vorhandene Vertrauenskette gegen das Opfer einsetzen.
Die drei Prüfungen, die du auseinanderhalten solltest
| Prüfung | Frage | Warum sie allein nicht reicht |
|---|---|---|
| Herkunft | Kommt die Mail wirklich von der angegebenen Domain? | Ein legitimes Konto oder System kann kompromittiert worden sein. |
| Identität | Ist die Person hinter der Anfrage wirklich die behauptete Person? | Ein gestohlenes Konto kann unter echtem Namen kommunizieren. |
| Berechtigung | Darf diese Person genau diese Daten oder Handlung verlangen? | Selbst echte Beschäftigte können für einen Vorgang nicht zuständig oder nicht ausreichend autorisiert sein. |
Für normale Alltagsmails mag die erste Prüfung oft genügen. Sobald aber Ausweiskopien, Finanzdaten, Kundendaten, Zugangsdaten, Zahlungen oder andere besonders sensible Informationen betroffen sind, müssen alle drei Ebenen geprüft werden.
So prüfst du sensible Anfragen wirklich sicher
- Bei sensiblen Daten bewusst stoppen. Eine plausible Mail darf nicht automatisch zur Freigabe führen. Je größer der mögliche Schaden, desto höher muss die Prüfstufe sein.
- Einen zweiten Kommunikationsweg nutzen. Kontaktiere die angeblich anfragende Stelle über eine unabhängig beschaffte Telefonnummer, ein bekanntes Behördenportal oder einen bereits etablierten Ansprechpartner. Verwende dafür nicht die Kontaktdaten aus der verdächtigen Nachricht. Genau dieses Prinzip empfiehlt auch das BSI bei ungewöhnlichen Nachrichten bekannter Absender.
- Vorgangs- und Aktenzeichen separat bestätigen. Eine Referenznummer in einer Mail ist kein Beweis. Sie kann aus früherer Kommunikation, einem kompromittierten Postfach oder einem Datenleck stammen.
- Vier-Augen-Prinzip für Hochrisiko-Freigaben einsetzen. Ausweisdokumente, vollständige Kontobewegungen oder größere Datensätze sollten nicht von einer einzelnen Person allein freigegeben werden können.
- Nur das Nötigste herausgeben. Auch eine legitime Anfrage rechtfertigt nicht automatisch den größtmöglichen Datensatz. Rechtsgrundlage, Umfang und Zweck sollten nachvollziehbar sein.
- Die Entscheidung dokumentieren. Wer hat angefragt, über welchen Kanal wurde rückbestätigt, wer hat freigegeben und welche Daten wurden übermittelt? Ein sauberer Prüfpfad hilft bei späteren Untersuchungen enorm.
- Dringlichkeit nicht mit Echtheit verwechseln. Zeitdruck, drohende Konsequenzen oder angebliche Geheimhaltung sind typische Hebel des Social Engineering. Gerade dann darf die Verifikation nicht abgekürzt werden.
Das BSI rät bei einer merkwürdigen Nachricht von einem bekannten Absender ausdrücklich dazu, den Absender über einen anderen Weg zu kontaktieren und dafür nicht die in der Mail genannten Kontaktmöglichkeiten zu verwenden. Das ist im Unternehmensumfeld letztlich dasselbe Prinzip – nur als verbindlicher Prozess statt als Bauchentscheidung.
„DKIM ist gültig“ bedeutet nicht „Anfrage ist berechtigt“
SPF, DKIM und DMARC bleiben wichtige Bausteine. Das BSI bündelt entsprechende Anforderungen in der Technischen Richtlinie TR-03182. Diese Verfahren sind besonders wertvoll, um gefälschte Absenderdomains und nicht autorisierte Mailserver zu erkennen.
Doch wenn der Angreifer über ein tatsächlich autorisiertes System sendet, kann eine Nachricht diese Prüfungen bestehen. Das ist kein Versagen von DKIM oder DMARC – die Verfahren erledigen schlicht nicht die Aufgabe einer inhaltlichen und organisatorischen Berechtigungsprüfung.
Merksatz: E-Mail-Authentifizierung kann bestätigen, woher eine Nachricht technisch kommt. Sie kann nicht garantieren, dass der Mensch hinter dem Konto gerade legitim handelt.
Was Unternehmen aus dem Revolut-Fall lernen sollten
Für Banken, Versicherungen, Onlineshops, Behörden, Arztpraxen und andere Organisationen mit sensiblen Daten ist der Fall vor allem ein Prozessproblem. Wer eine E-Mail-Adresse als alleinigen Vertrauensanker verwendet, hat einen einzelnen Ausfallpunkt geschaffen.
| Vertrauenssignal | Typischer Fehlschluss | Besserer Kontrollschritt |
|---|---|---|
| Domain stimmt | „Dann ist die Anfrage echt.“ | Rückruf oder Portalbestätigung über unabhängig bekannte Kontaktdaten |
| DKIM/SPF unauffällig | „Die Mail kann nicht manipuliert sein.“ | Identität und Berechtigung des Anfragenden separat prüfen |
| Aktenzeichen vorhanden | „Der Absender kennt den Vorgang.“ | Aktenzeichen im eigenen bzw. offiziellen System verifizieren |
| Hohe Dringlichkeit | „Wir müssen sofort liefern.“ | Eskalationsweg und zweite Freigabe aktivieren |
| Absender ist bekannt | „Mit dem hatten wir schon Kontakt.“ | Bei ungewöhnlichem Umfang Out-of-Band-Bestätigung verlangen |
Für besonders sensible Behörden- und Strafverfolgungsanfragen ist ein eigener Workflow sinnvoll: zentrale Annahmestelle, Rollen- und Rechteprüfung, dokumentierte Rückbestätigung, Vier-Augen-Freigabe und möglichst ein etabliertes Portal statt freier E-Mail-Kommunikation. Digitale Signaturen können zusätzliche Sicherheit schaffen, ersetzen aber ebenfalls nicht die Prüfung, ob die konkrete Anfrage inhaltlich berechtigt ist.
Dass Angreifer zunehmend mehrere Vertrauenssignale gleichzeitig missbrauchen, passt zu einer breiteren Entwicklung. Auch beim jüngst von Microsoft zerschlagenen Phishingdienst EvilTokens ging es darum, klassische Schutzmechanismen zu umgehen und gestohlene Konten möglichst effizient auszuwerten. Mehr dazu findest du in unserer News „EvilTokens gestoppt: KI-Phishingdienst kompromittierte laut Microsoft 12.000 Postfächer“.
Warum gestohlene Ausweisdaten besonders kritisch sind
Ein kompromittiertes Passwort lässt sich ändern. Eine Kreditkarte lässt sich sperren. Geburtsdatum, Anschrift oder eine Kopie des Reisepasses bleiben dagegen langfristig verwertbar. Solche Daten eignen sich für gezieltes Spear-Phishing, Identitätsmissbrauch und überzeugendere Betrugsversuche.
Besonders gefährlich ist die Kombination verschiedener Datentypen. Wer Name, Telefonnummer, Adresse, Bankbezug und einzelne Transaktionsinformationen kennt, kann bei einem späteren Anruf wesentlich glaubwürdiger auftreten. Dann wird aus einem einzelnen Datenabfluss eine Grundlage für die nächste Angriffsstufe.
Was tun, wenn sensible Daten bereits herausgegeben wurden?
Für Unternehmen zählt zunächst Schadensbegrenzung: weitere Datenübermittlungen stoppen, Beweise und Protokolle sichern, die echte Institution über einen unabhängigen Kanal kontaktieren und IT-Sicherheit, Datenschutz sowie Rechtsabteilung einschalten. Ob Betroffene oder Aufsichtsbehörden informiert werden müssen, hängt vom konkreten Vorfall und den gesetzlichen Pflichten ab.
Betroffene Privatpersonen sollten danach besonders mit zielgerichteten Folgeangriffen rechnen. Verdächtige Anrufe, Mails oder Nachrichten können wesentlich glaubwürdiger wirken, weil die Täter echte persönliche Informationen kennen. Unbekannte Transaktionen sollten sofort beim jeweiligen Finanzdienstleister gemeldet werden. Sind Zugangsdaten betroffen, müssen Passwörter geändert und – wo möglich – starke Mehrfaktor-Authentisierung oder Passkeys aktiviert werden. Bei konkretem Identitätsmissbrauch kommen zusätzlich Polizei und gegebenenfalls die ausstellende Behörde des betroffenen Dokuments infrage.
Was du als Privatperson daraus mitnehmen kannst
Auch außerhalb von Unternehmen gilt: Vertraue einer Nachricht nicht allein deshalb, weil Name, Telefonnummer oder Domain stimmen. Konten können übernommen, Telefonnummern manipuliert und echte Gesprächsfäden missbraucht werden.
Revolut selbst empfiehlt bei verdächtigen Kontakten, keine persönlichen oder finanziellen Informationen zu teilen und die Echtheit über den Support in der App zu prüfen. Für Anrufe zeigt die Revolut-App zudem an, ob tatsächlich ein offizieller Revolut-Kontakt stattfindet. Sicherheitscodes oder Einmalpasswörter gehören niemals in ein Telefonat oder eine Nachricht.
- Öffne Banking- oder Behördenportale lieber selbst über die bekannte App oder eine manuell eingegebene Adresse statt über Links in Nachrichten.
- Rufe bei Zweifel über eine selbst recherchierte offizielle Nummer zurück.
- Teile niemals TANs, Einmalcodes, Passcodes oder Fernzugriff auf dein Gerät.
- Werde misstrauisch, wenn jemand mit Zeitdruck, Geheimhaltung oder drastischen Folgen arbeitet.
- Gehe davon aus, dass ein Betrüger bereits echte Daten über dich kennen kann.
Revolut beschreibt seine aktuellen Schutz- und Meldewege hier. Auch das BSI warnt ausdrücklich davor, Phishing allein anhand leicht erkennbarer Merkmale beurteilen zu wollen.
Fazit: Vertrauen darf nicht an einer einzelnen Mail hängen
Der Revolut-Fall ist kein Argument gegen E-Mail-Authentifizierung – im Gegenteil. SPF, DKIM, DMARC, digitale Signaturen und sichere Transportwege bleiben wichtig. Sie müssen aber Teil eines mehrstufigen Sicherheitsmodells sein.
Der entscheidende Schritt ist die unabhängige Verifikation einer sensiblen Anfrage. Bei wertvollen Daten darf die Frage nicht nur lauten „Ist diese E-Mail technisch echt?“, sondern immer auch: „Wer sitzt gerade wirklich dahinter – und darf diese Person genau das von mir verlangen?“ Genau dort entscheidet sich, ob aus einem glaubwürdigen Kontakt ein erfolgreicher Social-Engineering-Angriff wird.
