PayPal-Phishing, dritte Runde: gleicher Text, neue Frist, alte Phishing-Seite

Vor zwei Wochen habe ich hier eine PayPal-Phishing-Mail mit FATCA-Vorwand zerlegt, die jede technische Prüfung bestanden hat. Jetzt ist sie wieder da. Gleicher Text, Wort für Wort. Nur die Frist ist drei Tage nach hinten gerutscht, und unter der Haube ist fast alles anders. Das Interessanteste daran: Diese Welle verrät, dass hinter allen drei PayPal-Kampagnen, die ich seit Juli gesehen habe, derselbe Betreiber steckt.

Vorab: Alle bösartigen URLs sind defangt (hxxps, [.]), damit hier nichts aus Versehen angeklickt wird.

Was im Postfach lag

Betreff: „Wir benötigen einige Informationen zu Ihrem PayPal-Konto. (Referenznummer: PP-L-422087871544)". Diesen Betreff kenne ich. Er stand exakt so, samt derselben Referenznummer, schon auf der PayPal-Mail aus dem Juli. Eine „Referenznummer", die in drei Monaten identisch bleibt, ist keine Referenz. Sie ist Deko.

Der Text darunter ist die FATCA-Mail vom 10. September. „Um die neuesten Finanzvorschriften einzuhalten…", dann der gelbe Kasten mit der Frist, der blaue Button „Zur Kontoverifizierung →", die Erklärung zum US-Steuergesetz. Einzige Änderung: „bis zum 21. September 2026" statt bis zum 18. Die Mail kam am 18. an. Aus acht Tagen Frist wurden drei. Der Druck steigt, die Arbeit blieb aus.

Im Footer steht weiterhin „PayPal Pte. Ltd.", die Gesellschaft in Singapur. Für deutsche Kunden ist PayPal (Europe) in Luxemburg zuständig. Der Fehler zieht sich durch alle drei Wellen. Eine Signatur wie ein Fingerabdruck.

Was sich geändert hat: der Versand

Der Absender zeigt wieder PayPaI mit großem I statt kleinem L, in normalen Schriften nicht zu unterscheiden. Die Adresse dahinter lautet support[@]pos[.]<pos-anbieter-in>[.]shop. Das ist die Domain eines indischen Anbieters von Kassensoftware. Mit PayPal hat die nichts zu tun.

Die Vorwelle kam noch über Amazon SES mit gültigem DKIM und bestandenem DMARC. Davon ist nichts übrig:

Received: from <hosting-user> by server1.<pos-anbieter-in>.shop with local (Exim 4.95)
X-PHP-Originating-Script: 1010:n.php
spf=none

Die erste Zeile sagt: Die Mail wurde nicht per SMTP eingeliefert, sondern auf dem Server selbst erzeugt. Die zweite verrät von wo: aus einem PHP-Skript namens n.php. Das ist das klassische Bild eines hochgeladenen Mailer-Skripts auf einem gekaperten Webserver. Der Server steht in der Oracle Cloud in Mumbai und ist gleichzeitig der Webserver der Firma. Die Firma ist hier selbst Opfer.

Kein DKIM, und SPF liefert none. Das ist kein Zufall. Die Hauptdomain der Firma hat einen SPF-Eintrag, und der würde diesen Server nicht abdecken. Das Ergebnis wäre fail. Die Subdomain pos. hat gar keinen Eintrag, also kein Urteil. Einen DMARC-Eintrag gibt es für keine der beiden. Der Inhaber bekommt deshalb nie einen Report über den Missbrauch.

SpamAssassin kam auf 5.8 bei einer Schwelle von 7.0. Zugestellt. Spannend ist, was diesmal fehlt: Die Regel FUZZY_PAYPAL, die in der Vorwelle anschlug, greift nur bei verfremdeten Schreibweisen im Betreff. Im Betreff steht jetzt aber korrektes „PayPal". Das große I sitzt nur noch im Anzeigenamen. Ob Absicht oder Zufall: Der Markenfilter blieb stumm.

Wo der Button hinführt

Alle drei Links der Mail, also Button, FATCA-Info und „Sicherheits- und Hilfecenter", zeigen auf hxxps://getresolution[.]link/6dG5Ss6. Die Domain wurde am 18. September um 11:02 Uhr UTC registriert. Die Mail ging um 12:58 Uhr UTC raus. Knapp zwei Stunden. Gehostet wird sie bei Vercel, einer legitimen Plattform für Web-Deployments, die dem Angreifer auch gleich TLS und ein schnelles Edge-Netz mitliefert.

Wohin es von dort weitergeht, weiß VirusTotal. Der Dienst hat die URL 42 Minuten vor der Zustellung bei mir gescannt und landete auf:

hxxps://paypal[.]center-resolve[.]eu[.]cc/DUVzTTavlOw/?redirection=login

Und jetzt wird es interessant. Die Phishing-Seite der Juli-Welle lag unter hxxps://log[.]ppl-case-center[.]eu[.]cc/DUVzTTavlOw/?redirection=login. Gleiche Gratis-Zone .eu.cc. Und exakt derselbe Pfad mit demselben elfstelligen Token. Das ist eine Kit- oder Betreiber-ID, und sie hat sich in zweieinhalb Monaten nicht geändert.

Bisher hatte ich die Juli- und die September-Mails nur über weiche Indizien verbunden: das große I, den Singapur-Footer, den Behördenton. Jetzt gibt es einen harten Beleg. Es ist dasselbe Phishing-Kit, betrieben von derselben Truppe.

VirusTotal zeigt für die Phishing-Seite am Versandtag den Originaltitel der PayPal-Startseite. Fünf Tage später wird der Scanner auf eine echte PayPal-Ressource umgeleitet. Cloaking wie im Juli: Wer nach Scanner aussieht, bekommt echtes PayPal zu sehen. Drei von 91 Engines schlagen inzwischen an, beim Kurzlink ist es einer.

Was die eigentlich wollen

Wer klickt, landet auf einem PayPal-Klon und gibt dort E-Mail und Passwort ein, vermutlich gefolgt von Identitätsdaten und dem SMS-Code. Damit loggt sich der Angreifer ins echte Geschäftskonto ein. Er zieht Guthaben ab, nutzt das Konto als Durchlaufstation für fremde Zahlungen und ändert die Kontaktdaten, bevor ihr es merkt. Für einen kleinen Betrieb, der über PayPal Umsätze einnimmt, ist das ein direkter Geldverlust plus Ärger mit Rückbuchungen.

Woran ihr's erkannt hättet

Die Absenderadresse: Eine indische Kassensoftware ist nicht PayPal. Das Linkziel: Maus über den Button, unten steht getresolution.link. Die fehlende Anrede bei einer angeblich kontobezogenen Compliance-Anfrage. Und wer genau hinschaut, findet Singapur im Footer.

Bemerkenswert finde ich, wie wenig Eigenleistung hier drinsteckt. Der Text ist zwei Wochen alt, der Betreff drei Monate, die Phishing-Seite läuft auf demselben Kit wie im Juli. Neu sind nur eine Domain für ein paar Euro und ein fremder Webserver. Das ist kein Angreifer, der sich weiterentwickelt. Das ist einer, der seinen Baukasten neu mischt, sobald ein Teil verbrannt ist. Der vollständig authentifizierte SES-Versand der Vorwelle war offenbar nicht wiederholbar.

Was ihr tun könnt

PayPal nur über Lesezeichen oder App öffnen. Braucht PayPal wirklich Daten, steht das nach dem Login im Konto. Damit ist die ganze Kette wirkungslos.
Passkey für PayPal aktivieren. Ein Passkey ist an die echte Domain gebunden und funktioniert auf .eu.cc schlicht nicht. Einen SMS-Code dagegen kann die Phishing-Seite in Echtzeit weiterreichen.
Absenderadresse im Mail-Client dauerhaft einblenden. Der Anzeigename ist das gefälschte Feld, die Adresse dahinter verrät den Fake.
Filterregel einrichten: Anzeigename enthält „PayPa", Absenderdomain ist aber nicht paypal.com, dann ab in die Quarantäne. Das geht in Microsoft 365, Google Workspace und bei den meisten Hostern per Sieve.
Eure eigene Domain absichern. SPF nicht nur für die Hauptdomain setzen, dazu DMARC. Mit p=reject hätte ein durchsetzendes Postfach diese Mail abgewiesen, und die Reports hätten den Missbrauch sichtbar gemacht. Wie eure Domain dasteht, zeigt der Mail-Check hier auf der Seite.

Die dritte PayPal-Welle ist technisch die schwächste: kein DKIM, kein SPF-Pass, eine zwei Stunden alte Domain. Durchgekommen ist sie trotzdem. Und sie hat mehr verraten als die beiden davor zusammen: ein Token im Pfad, das drei Kampagnen an einen Betreiber bindet.

Die missbrauchte Absender-Domain ist redigiert (<pos-anbieter-in>[.]shop). Der Anbieter dahinter ist hier selbst Opfer: Auf seinem Webserver lief ein fremdes Mailer-Skript, und für die genutzte Subdomain waren weder SPF noch DMARC gesetzt - bei einem kleinen Betrieb ohne eigene IT-Security keine Seltenheit. Die vollständigen IOCs liegen intern in der Analyse.