N26-Karte gesperrt? Diese Phishing-Mail besteht SPF, DKIM und DMARC - und bringt ihr Spam-Urteil gleich selbst mit

Meine N26-Karte ist gesperrt. Das ist beachtlich, denn ich habe keine. Die Mail dazu ist trotzdem einen Blick wert: Sie besteht jede Absenderprüfung, die es gibt. Und sie hat ihr eigenes Spamfilter-Ergebnis schon dabei, bevor irgendein Filter sie gesehen hat.

URLs und IPs sind im Folgenden defangt (hxxps, [.]), damit nichts aus Versehen angeklickt wird.

Was in der Mail steht

Betreff: Ihre N26-Karte wurde vorübergehend gesperrt. Absender: Support-N26 <support[@]<firma-nl>[.]nl>. Bei einer "routinemäßigen Überprüfung" sei eine Zahlung aufgefallen, die Karte deshalb vorsorglich gesperrt. Dann kommt der Satz, an dem die Mail scheitert:

Bitte prüfen Sie die nachfolgend aufgeführte Transaktion sorgfältig und bestätigen Sie, ob Sie diese Zahlung autorisiert haben:

Nachfolgend aufgeführt ist: nichts. Im Quelltext stehen an der Stelle zwei Leerzeilen. Schritt 1 verweist später auf "die oben aufgeführten Details". Die gibt es genauso wenig. Jemand hat den Transaktionsblock aus der Vorlage genommen und den Text drumherum stehen lassen.

Der Rest ist sauberes Deutsch und optisch ordentlich. Drei Schritte soll ich gehen: Transaktion bestätigen, einen Kontoauszug hochladen und ein "neues 3-D-Secure-Verfahren (Version 2.0)" aktivieren. Der Footer nennt die "N26 Bank AG" in der Klosterstraße. N26 firmiert als Bank SE und sitzt woanders. Die fünf Social-Media-Icons führen alle auf #, also nirgendwohin. Und über dem Button steht im Quelltext der Kommentar . Schön, dass das mal jemand dazuschreibt.

Warum besteht eine Phishing-Mail SPF, DKIM und DMARC?

Die erste N26-Mail hier im Blog hat n26.com direkt gefälscht und ist damit an N26s strenger DMARC-Policy gescheitert. Diese hier versucht das gar nicht erst. Sie kommt von der Domain einer kleinen niederländischen Firma. Und dort stimmt technisch alles: SPF pass, DKIM pass, DMARC pass.

Das liegt nicht an einem gekaperten Postfach. Die Täter haben die DNS-Zone der Firma umgeschrieben, also das Verzeichnis, das festlegt, welche Server für eine Domain sprechen dürfen. Vier Einträge kamen dazu: ein Hostname mta mit der IP eines gemieteten Hetzner-Servers (142[.]132[.]185[.]70), dieselbe IP im SPF-Record, ein zweiter MX-Eintrag und ein DKIM-Schlüssel. Die Website der Firma läuft unverändert weiter. Sie merkt davon nichts.

Der DKIM-Selektor, also der Name des Schlüssels, lautet 1787114241.<firma-nl>. Die Zahl ist ein Unix-Zeitstempel: 19. August, 04:37 Uhr UTC. Die Mail ging um 06:12 Uhr raus. Der Schlüssel war 95 Minuten alt.

Der zweite MX-Eintrag hat einen hässlichen Nebeneffekt. Er hat dieselbe Priorität wie der echte. Ein Teil der Post an die Firma landet seitdem beim Täter-Server. Die Einträge standen bei meiner Prüfung am 1. Oktober noch im DNS.

Thunderbird, das nach Python riecht

Laut Header kommt die Mail aus X-Mailer: Mozilla Thunderbird. Thunderbird setzt dieses Feld gar nicht. Die Message-ID verrät den echten Absender:

Message-ID: <178711997756.3484.14902550772531487725@WIN-V98KM721JAK>

Das ist bis aufs Zeichen das Format, das Pythons Standardbibliothek erzeugt: Zeitstempel, Prozessnummer, Zufallszahl, Rechnername. WIN-V98KM721JAK ist der Name, den Windows Server sich bei der Installation selbst gibt. Niemand hat ihn je geändert. Ein Python-Skript auf einem frisch aufgesetzten Windows-Server, Zeitzone US-Westküste, das sich als Thunderbird ausgibt.

Am besten gefällt mir aber dieser Block, den der Absender selbst in die Mail geschrieben hat:

X-Spam-Status: No, score=0.0 required=5.0
X-Spam-Checker-Version: SpamAssassin (version 3.4.0)
X-Spam-Report: This message is not spam.

Die Mail bescheinigt sich selbst, kein Spam zu sein. Das zielt auf Weiterleitungsregeln und nachgelagerte Filter, die nur auf X-Spam-Status: No schauen. Ein Angeklagter, der seinen Freispruch selbst mitbringt.

Wohin führt der Button?

Auf hxxps://ecdylink[.]com/Yhqfaf. Das sieht aus wie ein Kurzlink-Dienst und ist auch einer, nur gehört er den Tätern. Die Domain wurde am 19. August um 05:09 Uhr UTC registriert. 63 Minuten vor dem Versand. Schlüssel erzeugen, Domain kaufen, Zertifikat holen, verschicken: 96 Minuten für alles.

Die Domain liegt auf einem gemieteten Server bei GoDaddy (37[.]148[.]205[.]56). Dort wohnt ein ganzer Fuhrpark: ty-link[.]net, ty-linx[.]com, nlinky[.]com, gpylinx[.]com, dazu vivid-moeny[.]com, ein Buchstabendreher auf die Neobank Vivid Money. Außerdem zeigen Subdomains von drei weiteren niederländischen Firmendomains auf diesen Server. Alle vier Domains liegen beim selben Webhoster. Ob dort einzelne Kundenkonten übernommen wurden oder mehr dahintersteckt, lässt sich von außen nicht sagen.

VirusTotal hat den Link 88 Minuten nach dem Versand gescannt: 3 von 92, alle drei nur "spam", keiner "Phishing". Seitentitel: "Love your bank | Spend, save, and invest in one app". Das ist der Titel der echten N26-Startseite, ausgeliefert unter der Täter-Adresse und ohne Weiterleitung. Entweder bekommen Scanner eine Kopie der echten Seite zu sehen oder der Server reicht die echte Seite durch und liest mit. Google hat die URL jedenfalls als Finanzdienstleister einsortiert. Aufgerufen habe ich sie nicht.

Was die eigentlich wollen

Die drei Schritte aus der Mail sind der Bauplan. Erst der Login, damit haben die Täter die Zugangsdaten. Dann der Kontoauszug: IBAN, Name, Anschrift, Umsätze. Damit klingt der spätere Anruf vom "Bankberater" sehr überzeugend. Zum Schluss "3-D-Secure 2.0": Kartennummer, Prüfziffer und eine Bestätigung in der App. Die gibt in Wahrheit etwas ganz anderes frei, etwa ein neues Gerät oder eine Zahlung. Weil das Opfer selbst bestätigt hat, wird die Erstattung mühsam.

Woran hättet ihr es erkannt?

Am Absender. "Support-N26" ist nur der Anzeigename, dahinter steht eine .nl-Adresse ohne jeden Bezug zur Bank. Dann die Transaktion, die geprüft werden soll und nicht da ist. Der Button führt zu einer Domain, die weder N26 noch sonst etwas heißt. Und keine Bank will per Mail-Link einen Kontoauszug hochgeladen bekommen. Den hat sie schon.

Was diesmal nicht hilft: der Blick auf SPF, DKIM und DMARC. Alles grün. Die Prüfungen sagen nur, dass die Mail wirklich von dieser Domain kommt. Ob die Domain etwas mit N26 zu tun hat, sagen sie nicht.

Was ihr tun könnt

Bank nur über App oder Lesezeichen öffnen. Eine echte Kartensperre steht in der App. Steht dort nichts, ist die Mail erledigt.
Freigaben lesen, bevor ihr bestätigt. Die App zeigt an, was ihr freigebt. "Gerät koppeln" oder ein Betrag ist kein Sicherheitsupdate.
Hoster-Konto absichern. Die niederländische Firma ist hier das zweite Opfer. Eigenes Passwort und Zwei-Faktor-Anmeldung fürs Kundenmenü eures Hosters. Schaut gelegentlich in eure DNS-Zone: unbekannte MX-Einträge, fremde IPs im SPF oder neue _domainkey-Einträge gehören da nicht hin. Von außen geht das mit dem Mail-Check hier auf der Seite.
DMARC-Berichte einschalten. Ein rua-Eintrag kostet nichts. Dann meldet euch die Welt, wenn ein fremder Server in eurem Namen versendet. Die betroffene Domain steht auf p=none ohne Berichtsadresse und erfährt deshalb nichts.
Im Mailgateway junge Linkdomains bremsen. Wer Links auf Domains unter 30 Tagen in Quarantäne schickt, hätte diese Mail gefangen. Dazu eine Regel: Bankname im Anzeigenamen, aber fremde Absenderdomain.

Fazit

Die Infrastruktur ist besser als der Text. DNS-Zone übernommen, Schlüssel frisch, Domain 63 Minuten alt, alle Prüfungen bestanden. Und dann vergisst jemand die Transaktion, um die es angeblich geht. Grüne Haken bei SPF und DKIM heißen eben nur "kommt wirklich von dort" - nicht "ist wirklich N26".

Die Absenderdomain ist redigiert (<firma-nl>[.]nl), ebenso die weiteren betroffenen niederländischen Domains und ihr Hoster. Die Firma ist hier selbst Opfer: Ihre DNS-Zone wurde ohne ihr Wissen verändert. Pranger-Wirkung vermeiden. Die vollständigen IOCs liegen intern.