28,26 Euro, heute fällig: Die Phishing-Mail, die jeden technischen Test besteht

Kurz gesagt: Eine angebliche Hosting-Rechnung über 28,26 Euro besteht SPF und DKIM, bekommt vom Spamfilter null Punkte (tests=none) und verlinkt auf echtes AWS mit gültigem Amazon-Zertifikat. Möglich wird das ohne eigene Infrastruktur: Der Absender ist ein gekapertes indonesisches Geschäftspostfach (authentifizierte Anmeldung, also nichts gefälscht), das Markenlogo eine Tabelle aus 2.025 Zellen statt einer Bilddatei, und die Landing liegt in einem S3-Bucket. Die VirusTotal-Bewertung von 1 zu 90 ist dabei kein Entwarnungssignal, sondern Cloaking: Scanner werden auf eine harmlose Produktseite umgeleitet. Neun Erkennungsebenen geprüft, keine greift - was bleibt, ist der Text.

Ich schreibe hier sonst über Phishing-Mails mit kaputten Umlauten und Absendern wie service-paypal-sicherheit-2024[.]tk. Diese hier ist anders. Sie hat SPF bestanden. Sie hat DKIM bestanden. Der Spamfilter gab ihr null Punkte - nicht „knapp unter der Schwelle", sondern tests=none, keine einzige Regel hat angeschlagen. Die Absenderdomain gibt es seit 2020. Es gibt keinen Anhang, kein Skript, keinen Tippfehler.

Und trotzdem ist sie Phishing. Das Interessante ist nicht, dass es funktioniert. Das Interessante ist, wie wenig Aufwand dafür nötig war.

Alle bösartigen URLs und Adressen unten sind defangt, damit nichts aus Versehen angeklickt wird.

Die Mail

Im Posteingang steht:

Von:      📑 Michael Neumann | ISPGateway Finanzen
Betreff:  Ihre Rechnung 66296550 ist heute zur Zahlung fällig

Darunter, kurz und sachlich:

Zahlungsaufforderung
Rechnung Nr. 66296550 – heute fällig

Hallo. Zahlung fällig heute, 2026-09-08. Rechnung Nr. 66296550 ·
Managed Web-Hosting (Standard, monatlich) · 28,26 EUR.

[Jetzt begleichen]

Ohne Eingang bis Tagesende: Deaktivierung der Dienste.

Danke — Billing-Team · ISPGateway

Das war's. Ein Button, ein Betrag, eine Frist. Kein Rotdruck, kein Countdown, keine Großbuchstaben. Genau das macht sie gut.

28,26 Euro. Der Betrag ist der eigentliche Trick. Groß genug für eine echte Hosting-Rechnung, zu klein zum Nachrechnen, krumm genug, um nicht erfunden zu wirken. Wer 2.800 Euro liest, greift zum Telefon. Wer 28 Euro liest, erledigt es eben schnell.

Und die Marke stimmt: Der Empfänger ist ISPGateway-Kunde. Kein Glückstreffer.

Wie der Angreifer den richtigen Hoster erwischt

Der MX-Record einer Domain ist öffentlich. Ein dig MX sagt euch, wer die Mail für eine Domain annimmt - und damit meistens, wo das Hosting liegt. Wer eine Empfängerliste hat, sortiert sie damit in einem Durchlauf nach Anbieter und schickt jedem Stapel das passende Template.

Kostet nichts, hinterlässt beim Opfer keine Spur, und die Marke passt bei jedem Empfänger. Spear-Phishing-Wirkung zum Massenkampagnen-Preis. Dieselbe Masche steckte schon in den Rücklastschrift-Wellen von Juni und Juli.

Wer sehen will, was die eigene Domain dabei preisgibt - MX, SPF, DKIM und DMARC auf einen Blick - kann sie durch den Mail-Check hier auf der Seite schicken.

Warum SPF und DKIM hier nichts wert sind

Jetzt der Teil, der wehtut. Die Mail kommt von indrakurniawan[@]<dienstleister-id>[.]net, einem indonesischen Geschäftspostfach. SPF passt, DKIM passt, alles grün.

Der Grund steht in der Received-Kette:

Received: from [5.175.231.200] (helo=172.18.0.5)
	by srv12.<hoster-id>.com with esmtpsa (TLS1.3)
X-Authenticated-Id: indrakurniawan@<dienstleister-id>.net

esmtpsa heißt: authentifizierte Anmeldung. Da hat sich jemand mit gültigen Zugangsdaten am Mailserver angemeldet und eine Mail verschickt. Nichts ist gefälscht. Der indonesische Server hat brav mit DKIM signiert, weil er das bei jeder Kundenmail tut.

SPF und DKIM beantworten die Frage: Darf dieser Server im Namen dieser Domain senden? Antwort: ja. Was sie nicht beantworten: Und weiß der Besitzer des Postfachs davon? Vermutlich nicht. Der indonesische Betrieb ist hier selbst Opfer.

Zwei Details verraten den Fremdzugriff trotzdem. Als HELO-Name meldet der einliefernde Rechner 172.18.0.5 - eine private Adresse aus dem Docker-Standardnetz. Und er sitzt auf 5[.]175[.]231[.]200, einem deutschen VPS, nicht in Indonesien. Der User-Agent sagt „Roundcube Webmail", und das Message-ID-Format passt dazu: Der Angreifer betreibt offenbar seine eigene Roundcube-Instanz im Container und trägt das geklaute Postfach als Identität ein.

Wer die Rücklastschrift-Artikel gelesen hat, dem kommt das bekannt vor. Juni: 5[.]175[.]242[.]116, HELO 172.18.0.6. Juli: 5[.]175[.]231[.]177, HELO 172.18.0.6. Jetzt: 5[.]175[.]231[.]200, HELO 172.18.0.5. Gleicher Provider, dasselbe /24 wie im Juli, dasselbe Docker-Artefakt. Der Payload ist ausgetauscht - der Versandapparat ist derselbe.

Das Logo, das kein Bild ist

Die Mail ist 138 KB groß. Bei einer Nachricht mit fünf Sätzen und ohne Anhang ist das merkwürdig. Wenn ihr F12 drückt und in den Quelltext schaut, seht ihr, warum:

98,2 Prozent der Mail sind eine einzige HTML-Tabelle mit 2.025 Zellen. 65 Zeilen, 130 Pixel breit, jede Zelle 1×1 Pixel mit einer eigenen background-Farbe in Graustufen.

Das ist das Logo. Kein <img>, keine Bilddatei - ein Rasterbild, gemalt aus Tabellenzellen.

Und zwar, wenn man genau hinsieht, das DomainFactory-Logo: ISPGateway ist deren Hosting-Oberfläche, die Marken gehören zusammen. Im Screenshot oben wirkt es leicht ausgefranst, und das ist kein Rendering-Fehler - so sieht ein Logo aus, das jemand Pixel für Pixel in Graustufen-Tabellenzellen nachgebaut hat. Das Original ist gestochen scharf.

Der Nutzen ist doppelt. „Externe Bilder nicht laden" hilft nicht, weil es nichts zu laden gibt. Und Scanner, die Markenlogos per Bildhash erkennen, finden kein Bild, sondern Markup.

Der Preis: keinerlei Telemetrie. Kein Tracking-Pixel, kein Shortener, keine Klickstatistik - der Angreifer weiß nicht mal, wer die Mail öffnet. Bewusste Entscheidung: Alles, was messen würde, würde auch auffallen. 2.025 Tabellenzellen für ein Logo. Das nenn ich Commitment.

Der Link geht zu Amazon. Wirklich.

Ein einziger Link steckt in der Mail:

https://s3.eu-west-1.amazonaws.com/quilt-exact-holly-lx-591c11dd/ppDSCvS4hY

Das ist echtes AWS. Echtes Amazon-Zertifikat, echtes HTTPS, echte Domain. Der Angreifer besitzt in dieser Kampagne keine einzige eigene Domain - es gibt nichts, worauf man WHOIS-Alter, frische Zertifikate oder Domain-Reputation anwenden könnte. Und weil die URL im Path-Style aufgebaut ist, steht der Bucket-Name im Pfad statt im Hostnamen: Ein Filter, der nur den Host prüft, sieht amazonaws.com und winkt durch.

Ich habe die URL nicht aufgerufen, sondern über die VirusTotal-API prüfen lassen. Ergebnis: 1 von 90 Engines schlägt an. Und die Final-URL, auf der der VT-Crawler landete:

https://chatlyai.app/chat?utm_model=vgpt-cl1-5&utm_source=google

Eine AI-Chat-Produktseite. Eine gefälschte Hosting-Rechnung, die auf ein KI-Startup verlinkt - das ergibt als Angriff keinen Sinn. Und genau das ist der Punkt.

Das S3-Objekt ist kein Redirect, sondern eine Weiche. Es schaut sich an, wer da klopft: Rechenzentrums-IP, Headless-Browser, falsches Land? Dann geht's zum harmlosen AI-Produkt. Echter deutscher Anschluss, echter Browser? Dann zur Phishing-Seite. Nennt sich Cloaking, und VirusTotal crawlt nun mal aus dem Rechenzentrum.

Die 1/90 sind also kein Entwarnungssignal. VirusTotal hat die Phishing-Seite nicht geprüft und für harmlos befunden - VirusTotal hat sie nie zu Gesicht bekommen. Das utm_source=google im Ausweichziel ist übrigens Affiliate-Tracking: Der unbrauchbare Scanner-Traffic wird weiterverkauft. Der Angreifer verdient an den Leuten, die ihn prüfen.

Was hier alles nicht hilft

Der übliche Ratgeber-Block versagt bei dieser Mail vollständig. Auf SPF und DKIM achten? Beide bestanden. Auf Rechtschreibfehler achten? Gibt keine. Bilder nicht laden? Gibt keine. Auf das Schloss in der Adresszeile achten? Das Zertifikat ist von Amazon. Die Domain im Link prüfen? Die ist echt - sie gehört nur nicht eurem Hoster. Anhänge nicht öffnen? Gibt keinen. Dem Spamfilter vertrauen? Null Punkte.

Neun Erkennungsebenen habe ich geprüft. Keine greift. Was bleibt, ist der Text - und da wird es dann doch dünn:

„Hallo." Punkt. Kein Name, keine Kundennummer. Kein Hoster schreibt so eine Rechnung.

2026-09-08. ISO-Datum in einer deutschen Rechnung - die schreibt 08.09.2026. Da hat ein Skript stumpf das Systemdatum eingesetzt. Dazu passt: Die Mail kam am 9. September um 01:36 Uhr an und behauptete, „heute" sei der 8. Die Frist war beim Eintreffen schon abgelaufen.

Kein Impressum, kein Abmeldelink, keine Rechnungsanschrift, keine USt-ID - eine Zahlungsaufforderung ohne eine einzige Pflichtangabe. Und ein Hoster, der zum Bezahlen auf einen anonymen Cloud-Speicher verlinkt. Das tut keiner.

Was ihr tun könnt

Rechnungen nie über den Mail-Link öffnen. Browser auf, Lesezeichen oder Adresse tippen, im Kundenkonto einloggen. Ist die Rechnung offen, steht sie da. Steht sie nicht da, gibt es sie nicht. Das ist die einzige Regel, die unabhängig von der Qualität der Fälschung funktioniert: Diese Mail hat neun technische Prüfungen bestanden, aber sie kann keine Rechnung in euer echtes Kundenkonto schreiben. Zwanzig Sekunden - und es muss eine Regel sein, keine Empfehlung, sonst wird sie bei der dringenden Mail ignoriert.

2FA aufs Hosting- und Domain-Konto. Wenn genau ein Konto Zwei-Faktor bekommt, dann dieses: Da hängen DNS, Mail, Website und der Domain-Transfer dran. Ein geklautes Passwort ist damit wertlos. Fünfzehn Minuten, einmalig. Recovery-Codes ausdrucken, nicht ins Postfach legen.

Absenderadresse einblenden, nicht nur den Anzeigenamen. Der komplette Markenbezug steckt im Anzeigenamen. Steht daneben indrakurniawan[@]<dienstleister-id>[.]net, kippt der Eindruck sofort - auch ohne technisches Wissen. Eine Einstellung im Mailclient.

Support-Nummern aus dem Vertrag notieren, nicht aus der Mail - und die Rückfrage-Regel an die Frist hängen, nicht an den Betrag. 28,26 Euro rechtfertigen in niemandes Kopf einen Anruf. Deswegen steht der Betrag ja da.

Wenn ihr ein Web-Gateway habt: Direkte Browser-Abrufe von Roh-Objekten auf s3.*.amazonaws.com, storage.googleapis.com und blob.core.windows.net protokollieren. Keine Pauschalsperre, das bricht halb Internet. Derselbe Trick lief im Juni schon über Google Cloud Storage. Ohne Gateway: Die ersten beiden Punkte sind wichtiger und kosten nichts.

Fazit

Das hier ist kein Zeichen von Genie, sondern von Sparsamkeit. Der Angreifer hat keine Domain gekauft, kein Zertifikat besorgt, keinen Server betrieben und kein Kit programmiert. Er hat sich ein fremdes Postfach genommen, einen S3-Bucket angelegt und ein Logo aus Tabellenzellen gemalt. Der ganze Aufwand steckt darin, nichts zu tun, was auffällt - bis hin zum Verzicht auf die eigene Klickstatistik.

Deshalb funktioniert die alte Prüfliste nicht mehr. „Absender kontrollieren, Link ansehen, auf Fehler achten" setzt voraus, dass der Angreifer irgendwo schlampt. Dieser tut es nicht. Übrig bleibt ein Prozess: Rechnungen im Kundenkonto prüfen, 2FA drauf, fertig. Weniger spannend als Header-Forensik, aber es hält.

Die kompromittierte Absender-Domain und der indonesische Hoster sind redigiert (<dienstleister-id>[.]net, <hoster-id>[.]com). Der betroffene Betrieb ist hier selbst Opfer - sein Postfach wurde mit gestohlenen Zugangsdaten benutzt, ohne dass er etwas davon mitbekommt. Die vollständigen IOCs liegen intern. Die Angreifer-Infrastruktur (VPS-IP, S3-Bucket) ist bewusst unredigiert.