Klarna-Phishing mit gültigem DKIM - versendet von einem Uhrmacher

Die meisten Phishing-Mails verraten sich beim ersten Blick in die Header. Diese hier besteht SPF, DKIM und DMARC - gegen eine p=reject-Policy. Der Bayes-Filter hielt sie zu 99,99 Prozent für Ham. Und der Grund dafür ist ein deutscher Uhrmacher, der von alldem nichts wusste.

Betreff: „Neue Nachricht in Ihrer Klarna-App #1006914". Absender: KlarnaAB - ohne Leerzeichen, das ist tatsächlich der einzige sprachliche Patzer in der ganzen Mail. Dahinter steht keine Klarna-Adresse, sondern eine Buchstabensuppe bei einer deutschen Uhrmacher-Domain. Ich nenne sie im Folgenden <uhrmacher-de>[.]de; warum sie hier nicht ausgeschrieben steht, kommt am Ende. URLs und Domains sind defangt, damit nichts aus Versehen angeklickt wird.

Die Mail

Inhaltlich ist sie erschreckend unauffällig. Kein gesperrtes Konto, keine Frist von 24 Stunden, keine roten Warnkästen:

vielen Dank, dass Sie Klarna für Ihre Zahlungen nutzen. Damit Ihr Konto
uneingeschränkt verfügbar bleibt, möchten wir Sie freundlich daran erinnern,
Ihre hinterlegten Angaben zu überprüfen.

Fehlerfreies Deutsch, durchgehend Sie, korrekte Kommasetzung. Im Footer steht Klarna Bank AB (publ) · Sveavägen 46 · 111 34 Stockholm · Schweden - die echte Adresse, richtig geschrieben. Die Klarna-Optik entsteht komplett ohne Bilder: Kopfleiste in Klarna-Schwarz #0B051D, Trennstreifen im Klarna-Pink #FFA8CD. Kein Logo, kein Tracking-Pixel. Bilder blockieren hilft hier nichts.

Ein einziger Button: „Jetzt in der App prüfen". Genau das ist die schlechteste Idee der gesamten Kampagne - dazu gleich.

Verraten hat sich die Sache nur am Template. Im sichtbaren Text steht die Frist „bis zum 5. August 2026". Im unsichtbaren Preheader - dem Text, den Gmail und Outlook in der Vorschauzeile anzeigen - steht „bis zum 28. Juli 2026". Zwei Fristen in einer Mail. Zugestellt wurde sie am 6. August, beide waren bei Ankunft also schon abgelaufen. Dazu ein doppeltes </html> am Ende und ein <title>DE</title> als Sprachmarker des Baukastens. Wer immer dieses Template pflegt: Er pflegt es nicht.

Warum die Mail durchkam

Jetzt der interessante Teil. Die Header sind sauber. Nicht „unauffällig" - sauber: spf=pass, zweimal dkim=pass, DMARC bestanden. Und zwar gegen eine Domain, die auf p=reject stand. Die Mail ist kryptografisch echt.

Das geht, weil der Angreifer die Domain nicht gefälscht, sondern übernommen hat. Der Zeitstempel dazu steht in den DKIM-Selektoren: v1-rsa-20260805 und v1-ed25519-20260805. Frisch erzeugte Schlüssel, das Datum im Namen. Ein Blick in die Passive-DNS-Daten zu der Versand-IP 103[.]195[.]188[.]160 (eine VPS in Singapur) zeigt, was am 5. August um 03:54 UTC passiert ist - innerhalb von 28 Sekunden:

03:54:50   autodiscover.<uhrmacher-de>.de
03:55:00   ua-auto-config.<uhrmacher-de>.de
03:55:04   mta-sts.<uhrmacher-de>.de
03:55:06   autoconfig.<uhrmacher-de>.de
03:55:18   app-dev.<uhrmacher-de>.de

Das ist kein Spoofing. Das ist eine Inbetriebnahme. autodiscover, autoconfig und mta-sts sind Mail-Provisioning-Records - wer die setzt, hat vollen Schreibzugriff auf die DNS-Zone und rollt einen kompletten Mailserver aus. Inklusive MX auf die eigene IP, weshalb SPF anstandslos passt. Um 23:53 Uhr wurden die Mails signiert, am nächsten Morgen um 07:08 lagen sie im Postfach. Vom ersten DNS-Record bis zur Phishing-Welle: 25 Stunden.

Ed25519-DKIM baut man nicht aus Versehen. Da hat jemand einen modernen Mailstack bewusst konfiguriert.

Wo der Klick hingeht

Der Button zeigt auf hxxps://t[.]co/CoE8Lb0Jxm. t.co ist der Kurzlink-Dienst von X/Twitter. Legitim, seit 2011 in Betrieb, makellose Reputation, in praktisch jeder Allowlist. Mouse-Over hilft dem Empfänger also exakt gar nichts - er sieht eine Domain, die er kennt.

Dazu ein Detail, das gern übersehen wird: t.co-Links kann man nicht einfach generieren. Sie entstehen nur, wenn ein Link auf der Plattform gepostet wird. Der Angreifer musste seine Phishing-URL also erst auf X veröffentlichen oder per DM verschicken. Ein X-Account ist Teil der Angriffsinfrastruktur.

VirusTotal kennt die URL: 1 von 91 Engines schlägt an. Eine. Dafür verrät der Report das Redirect-Ziel:

klarna7e672-812e-4809-a245-52c151f7d040.centroeducacionalprimavera[.]site

Markenwort vorne, damit auf dem Handy nur noch „klarna7e672…" in der Adresszeile steht. Und jetzt nochmal der Local-Part der Absenderadresse ansehen: one8abf-4028-40ff-bd8b-…. Beides sind UUIDs, deren Anfang durch ein Wort überschrieben wurde. Derselbe Generator auf beiden Seiten - Versandstack und Landing-Seite gehören zusammen. Die Landing-Domain wurde am 29. Mai registriert und steht seit dem 24. August auf serverHold, also gesperrt durch die Registry. Sieben Minuten nach dem letzten VirusTotal-Scan. Immerhin.

Was passiert wäre

Ein übernommenes Klarna-Konto ist kein Konto, das man leerräumt. Es ist ein Kreditrahmen. Wer reinkommt, bestellt auf Rechnung oder in Raten - auf Namen und Bonität des Opfers. Die Ware geht an eine neue Lieferadresse, die Zahlungsaufforderung ans Opfer, gemerkt wird das bei der ersten Mahnung. Der Köder „hinterlegte Angaben prüfen" rechtfertigt dabei sehr elegant, dass das Formular nach Kartendaten, IBAN und Geburtsdatum fragt.

Wie die Seite genau aussah, kann ich nicht sagen - sie war schon offline, und aufgerufen habe ich sie ohnehin nicht.

Was ihr tun könnt

Kurzlinks am Gateway beim Klick auflösen lassen. Dieser Angriff lebt davon, dass die Reputationsprüfung bei t.co aufhört. Microsoft 365 nennt das Safe Links, Google Workspace Link-Schutz - in den Business-Plänen enthalten, eine Richtlinie entfernt.

Zahlungsdienste über die App öffnen, nie über den Mail-Link. Die Mail sagt das selbst: „in der App prüfen". Wer das wörtlich nimmt, ist fertig. Steht in der App kein Vorgang, war die Mail Phishing. Funktioniert auch bei perfekt gemachten Fälschungen.

Die eigene DNS-Zone absichern. Zwei-Faktor-Authentifizierung am Registrar- und Hosting-Konto, Transfer-Sperre setzen, und einmal im Quartal die eigenen Records anschauen: Steht da ein MX, ein autodiscover oder ein DKIM-Selektor, den niemand bestellt hat? DMARC-Reports (rua=) an ein Postfach schicken, das auch jemand liest - sie hätten diesen Versand am ersten Tag gemeldet.

DNSBL-Prüfung bei der SMTP-Annahme, nicht erst im Spamfilter. Die Versand-IP stand auf Spamhaus SBL-CSS. SpamAssassin hat den Treffer gesehen und gegen fünf bestandene Authentifizierungsregeln verrechnet: 5,1 von 7,0 nötigen Punkten, zugestellt. Eine Zen-Abfrage vor dem DATA-Kommando hätte die Mail abgewiesen, bevor irgendein Score-Modell anfängt zu rechnen.

Und im Kopf behalten: „DKIM bestanden" heißt nur, dass die Mail wirklich von der Domain kommt, die im Absender steht. Nicht, dass diese Domain noch ihrem Eigentümer gehört.

Diese Kampagne hat 25 Stunden in eine makellose Absender-Identität investiert, einen Ed25519-Schlüssel erzeugt und den Link über X gewaschen - und dann ein Template verschickt, in dem zwei verschiedene, längst abgelaufene Fristen stehen. Die Infrastruktur war die Arbeit eines Profis. Der Text war Resteverwertung. Erwischt hat sie sich am Text.

Die Absender-Domain ist redigiert (<uhrmacher-de>[.]de). Der Betrieb dahinter ist hier selbst Opfer - seine DNS-Zone wurde übernommen, seine Domain hat tagelang Phishing versendet und landete dafür auf Spamhaus. Zehn Tage später war die Zone bereinigt und die Domain zurück beim regulären Hoster. Wie der Zugriff zustande kam, ist von außen nicht feststellbar. Die vollständigen IOCs liegen intern; die Angreifer-Infrastruktur ist oben ungekürzt benannt.