cPanel-Webmail-Phishing: Dem Angreifer gehört an dieser Mail exakt nichts

Kurz gesagt: Eine angebliche Quarantäne-Meldung des eigenen Webmail-Systems führt auf ein PHP-Skript, das auf der gekaperten Website einer US-Anwaltskanzlei liegt. Verschickt wurde sie aus einem übernommenen Hosting-Postfach, deshalb bestehen SPF und DKIM sauber. Ziel ist das Postfach selbst. Erkennbar war die Mail nur am Text und am Link-Ziel, technisch an nichts.

Das Interessante an dieser Phishing-Mail ist, was der Angreifer alles nicht besitzt. Keine Domain. Keinen Server. Kein Bild. Nicht mal ein eigenes Postfach. Er hat eine Adressliste, ein HTML-Template und einen Internetanschluss in Bukarest. Alles andere in dieser Mail gehört anderen Leuten.

Was in der Mail steht

Betreff: „Please review your quarantined messages". Absender: Webmail, im Header dazu Organization: Cpanel. Der Text ist kurz, englisch und sauber formuliert:

You have new encrypted messages waiting in your webmail box. Unread items require your attention — they will be archived in 7 days.

Darunter ein oranger Button „ACCESS WEBMAIL" und drei Häkchen-Zeilen über aktive Roundcube-Sessions, Filter und Weiterleitungen und einen IT-Support-Desk rund um die Uhr. Die Fußzeile schließt mit „delivered via reference [AFTVSWADSWFAUO]", vierzehn zufälligen Großbuchstaben, die nach Ticketsystem aussehen sollen. Die Anrede ist die E-Mail-Adresse des Empfängers. Kein Name, keine Kundennummer. Der eigene Hoster weiß, wie man heißt.

Warum keiner der Filter angeschlagen hat

Der Absender ist info[@]<hosting-kunde>[.]online, eine im Februar registrierte Domain auf einem Shared-Hosting-Server in Helsinki. Auf derselben IP fand ich über vierzig weitere Domains, überwiegend spanischsprachige Kleinbetriebe mit dem üblichen mail./smtp./pop.-Zubehör. Ein ganz normaler Mandantenserver also. URLs und Domains sind in diesem Artikel defangt, damit nichts aus Versehen angeklickt wird.

Und genau von dort kam die Mail. SPF: pass. DKIM: pass, gültig signiert mit dem Schlüssel der Absenderdomain. SpamAssassin landet bei 2,4 von 7,0, rspamd bei minus 3,18 mit einem Bayes-Score von 99,95 Prozent Ham. Kein Spoofing, nichts zu beanstanden.

Der Grund steht im Header: X-Authenticated-Id: info[@]<hosting-kunde>[.]online, eingeliefert per authentifiziertem SMTP von 46[.]97[.]176[.]116. Das ist ein Consumer-Anschluss von Vodafone Romania in Bukarest, ohne Rückwärtsauflösung, mit dem Zufalls-HELO ivjc. Wer sich mit gültigen Zugangsdaten anmeldet, muss nichts fälschen. Das Postfach ist übernommen, sein Inhaber ist hier Opfer und nicht Täter.

Ein Detail am Rande: Die Absenderdomain hat gar keine DMARC-Policy, und zwar aus einem sehr menschlichen Grund. Unter _dmarc stehen keine DMARC-Einträge, sondern zwei SPF-Records. Da hat jemand die falsche Syntax ins falsche Feld kopiert. Der Empfängerserver meldet folgerichtig no valid DMARC record.

Und dann der Teil, der beim Header-Lesen wirklich weh tut: Der einzige harte Negativ-Indikator dieser Mail war vorhanden. Die einliefernde Adresse in Bukarest steht bei Spamhaus auf der XBL und zusätzlich bei SpamCop. Nur wurden empfangsseitig vier Spamhaus-Abfragen mit BLOCKED_OPENRESOLVER abgewiesen, weil sie über einen öffentlichen Resolver liefen. Ausgerechnet eine davon galt dieser IP. Die Information war da. Sie kam nur nicht an.

Was die eigentlich wollen

Das Kopfbild der Mail ist echt. Es wird direkt von cpanel.net geladen, aus dem WordPress-Upload-Ordner des Herstellers, wo es seit 2015 als Marketingbild liegt. Der Angreifer hostet kein einziges Byte selbst. Ein Gateway, das die einzige Bild-Domain dieser Mail sperren wollte, müsste cpanel.net sperren. Der Preis dafür: kein Tracking-Pixel, keine Öffnungsmessung. Die einzigen Logs über geöffnete Mails dieser Kampagne liegen bei cPanel.

Der Button führt auf hxxp://<anwaltskanzlei-us>[.]org/redirect/index.php?email= plus die eigene Adresse. Die Domain gehört einer amerikanischen Anwaltskanzlei für Verbraucherrecht, registriert 2006, aktiv verlängert, mit vollständigem Mail-Setup. Das ist keine Wegwerf-Infrastruktur, das ist eine gekaperte Website mit einem untergeschobenen PHP-Skript. Auch hier: Drittopfer, deshalb redigiert.

Der Parameter ?email= ist der eigentliche Mechanismus. Er reicht die Adresse an die nächste Stufe durch, wo sie im nachgebauten Login-Formular bereits eingetragen erscheint. Die Seite kennt euch also schon, es fehlt scheinbar nur noch das Passwort. Das ist psychologisch etwas ganz anderes als ein leeres Loginfeld. Und allein der Klick bestätigt, dass die Adresse gelesen wird.

Wie es weitergeht, konnte ich nicht beobachten: Beim VirusTotal-Scan rund 24 Stunden nach Zustellung antwortete das Skript bereits mit „File Not Found", Erkennungsrate 2 von 90. Was auf der Landing-Page stand, ist rekonstruiert und nicht bestätigt.

Ein Postfach ist dabei kein kleines Ziel. Es ist der Generalschlüssel für jedes „Passwort vergessen" im Betrieb. Dazu kommt der Dauerzugang, den niemand sucht: eine stille Weiterleitungsregel, die jeden Passwortwechsel überlebt. Die Mail bewirbt die Funktion sogar selbst. Und am Ende wird das übernommene Postfach zur Versandbasis der nächsten Welle. Genau so ist diese Mail entstanden.

Woran ihr es erkannt hättet

Am Absender. Eine .online-Domain, die mit eurem Hoster nichts zu tun hat, verschickt keine Quarantäne-Meldungen für euer Postfach. Am Link-Ziel: Der Button für euer Webmail zeigt auf eine amerikanische Anwaltskanzlei, noch dazu über unverschlüsseltes http. Einmal mit der Maus über den Button, ohne zu klicken, hätte gereicht. Und an der Anrede, denn wer eure Mailadresse als Namen benutzt, hat nur eure Mailadresse.

Im Quelltext dann zwei Stellen, die schlicht peinlich sind. Die Mail enthält <meta name=GENERATOR content="-[OUTLOOK_VER]-">, also einen Platzhalter, den der Generator nie ersetzt hat. Dazu eine Media-Query, in der statt einer Bedingung das Wort Unknown steht, wodurch der ganze Block wirkungslos ist. Und der orange Button trägt die CSS-Klasse blue-rounded-btn.

Was ihr tun könnt

Zwei-Faktor für Webmail und Hoster-Panel einschalten. Das entwertet die komplette Kampagne, weil das abgegriffene Passwort allein dann nichts mehr wert ist. Fast jeder Hoster kann das inzwischen, nur eingeschaltet ist es selten.

Weiterleitungen und Filterregeln einmal komplett durchsehen. Danach quartalsweise. Der Schaden nach einem Postfach-Diebstahl entsteht nicht am Tag des Klicks, sondern Wochen später über eine Regel, die keiner angelegt hat.

Nie über einen Link aus einer Mail einloggen. Webmail als Lesezeichen anlegen und ausschließlich darüber einsteigen. Kostet nichts und funktioniert auch bei der nächsten Welle mit anderem Template.

Die eigene Domain prüfen. Der Absender dieser Kampagne hatte SPF-Records im DMARC-Feld stehen und damit gar keine Policy. So etwas fällt ohne Prüfung nie auf: Mail-Check hier auf der Seite.

Einen Meldeweg benennen. info@ und sales@ lesen mehrere Leute, und jeder nimmt an, dass jemand anderes die Mail schon geprüft hat. Eine Adresse, an die man Verdächtiges ohne Diskussion weiterleitet, schließt genau diese Lücke.

Nichts gebracht hätten dagegen: Domain-Reputation, denn alle beteiligten Domains sind praktisch sauber. Anhang-Sandboxing, denn es gibt keinen Anhang. Externe Bilder blockieren, denn das einzige Bild kommt vom Hersteller.

Das Ergebnis ist eine Kampagne, die technisch fast nicht zu greifen ist, weil sie ausschließlich fremdes Eigentum benutzt. Und die trotzdem an einem unaufgelösten Platzhalter im Quelltext scheitert, den ein einziger Blick auf die fertige Mail gefunden hätte. Wer schon alles von anderen nimmt, könnte sich wenigstens die zwei Minuten Korrekturlesen leisten.

---

Die Absender-Domain und die Domain der weiterleitenden Website sind redigiert (<hosting-kunde>[.]online, <anwaltskanzlei-us>[.]org). Beide gehören Dritten, die hier selbst Opfer sind: ein gekapertes Hosting-Postfach und eine kompromittierte Website. Die vollständigen IOCs liegen intern.