Cloud-Speicher-Phishing, Runde sechs: Hinter dem Google-Bucket wartet ein Affiliate-Link mit Vornamen und Datum

Am Donnerstag hat mir jemand erklärt, wie man seine Cloud-Speicher-Einstellungen aktualisiert. So stand es zumindest im Betreff: „How to update your cloud storage management settings". Klingt nach Hilfe-Artikel. In der Mail steht in Rot „Payment Failure", und das Abo ist laut Mail seit dem 2. Oktober abgelaufen. Verschickt wurde sie am 5. November.

Das ist die sechste Mail dieser Familie hier im Blog. Die Mail selbst ist ein alter Bekannter. Neu ist, dass wir zum ersten Mal sehen, wohin das „Gate" im Google-Bucket die Klicks weiterreicht.

Die Mail: das September-Template, eingefroren

Wer die erste Folge vom September gelesen hat, kennt den Text Wort für Wort. Gleiche Überschrift, gleicher Warnkasten, gleicher Button „Update Payment Information". Auch das Logo ist dasselbe Bild mit derselben Offer-Nummer 16448 im Pfad. Im Footer steht weiterhin „To stop messages regarding this offer". Eine Rechnung ist kein Angebot. Ein Affiliate-Angebot schon.

Ein Unterschied steckt im Quelltext. Im September stand dort ein Stück JavaScript. Es sollte eine zufällige Abo-Nummer und das heutige Datum einsetzen. Mailclients führen kein JavaScript aus, also blieben beide Felder leer. Jetzt ist das Skript weg, und die Werte stehen fest im HTML: IC-4829103842 und October 2, 2026. Die alten id="sub_id"- und id="exp_date"-Attribute sind noch da, nur hängt kein Code mehr dran. Dazu wurde der CSS-Block in Inline-Styles umgebaut, wie es ein CSS-Inliner macht.

Meine Vermutung: Jemand hat die alte Vorlage einmal im Browser geöffnet und das Ergebnis abgespeichert. Seitdem bleibt das „Ablaufdatum" der 2. Oktober. Beim Versand war das Abo also seit über einem Monat abgelaufen. Trotzdem heißt es „We're unable to renew". Bugfix gelungen, Plausibilität verloren.

Technisch: der bekannte Google-Baukasten

Der Versand läuft wie bei allen Vorgängern. Absender ist eine Compute-Engine-VM bei Google, diesmal 34[.]162[.]30[.]198 in der Region us-east5 (Ohio). Im From steht Account Update Desk <support[@]<architektur-site>[.]com>. Die Domain gehört einer Architektur-Website, die seit 2009 bei IONOS liegt und mit Cloud-Speicher nichts zu tun hat. URLs und Adressen sind defangt, damit nichts aus Versehen angeklickt wird.

Die Domain veröffentlicht SPF mit ~all und DMARC mit p=none ohne Report-Adresse. Das ist der IONOS-Standard. Ergebnis: spf=softfail, keine DKIM-Signatur, und keine Policy, die irgendwen zum Abweisen auffordert. Die Inhaber merken davon nichts.

Interessant ist der Spamfilter. SpamAssassin beim Empfänger gibt 6,6 Punkte, die Schwelle liegt bei 7,0. Der Großteil kommt von BAYES_99 und BAYES_999. In der Vorwoche kam ein neues Template im Apple-Look, und der Score fiel auf 2,7 ohne jeden Bayes-Treffer. Jetzt kommt das alte Template zurück, und Bayes schlägt wieder voll an. Das ist die Gegenprobe: Der Filter erkennt das bekannte Template, nicht die Infrastruktur. Durch ist die Mail trotzdem, um 0,4 Punkte.

Was hinter dem Gate passiert

Der Button zeigt auf hxxps://storage.googleapis[.]com/storagesgdfhjtfukjgkgjkjfdh/lis. Das ist ein Objekt in einem Google-Cloud-Storage-Bucket mit Google-Zertifikat auf einer Google-Domain. VirusTotal hat den Bucket 27 Minuten vor dem Versand zum ersten Mal gesehen. Er liefert dieselbe 9,9-KB-Seite mit dem Titel „Verification Required" wie in den Vorwellen. Ich rufe so etwas nicht selbst auf. Alles Folgende stammt aus den Crawl-Daten von VirusTotal.

Neu ist, dass VT diesmal den ausgehenden Link dieser Seite erfasst hat:

hxxps://www.solidfairhubhost[.]com/5P2W1PG/27KQBZNB/?sub1=youness&sub2=5nov

Das ist ein Tracking-Link im Stil gängiger Affiliate-Software. Die beiden Pfadteile kennzeichnen Angebot und Vermittler. sub1 und sub2 sind freie Felder für die eigene Auswertung. In sub2 steht der Versandtag, der 5. November. In sub1 steht ein Vorname bzw. Handle, unter dem der Vermittler seine Klicks abrechnet. Wer dahintersteckt, verrät das Feld nicht, denn Sub-IDs kann jeder frei vergeben. Was er macht, ist dagegen eindeutig.

Die Domain solidfairhubhost[.]com wurde am 15. Juni 2026 bei Network Solutions registriert, mit Registrant in der Ukraine. Sie läuft mit eigenen Nameservern auf 144[.]31[.]63[.]120 (AS213520 Senko Digital, Deutschland). VirusTotal führt sie bei 15 von 92 Engines als bösartig.

Auch der Abmeldelink führt in einen eigenen Bucket. Dieser leitet laut VT auf hxxps://www.coredatafye[.]com/o-vskv-d21-… mit dem Seitentitel „We are sorry to see you go". Die Domain kennen wir aus der Speicher-voll-Welle, mit demselben Pfad-Präfix. Sie wurde am 11. Juni registriert, ebenfalls bei Network Solutions und mit ukrainischem Registrant. Das sind vier Tage Abstand zum Tracker. Ein Beweis für denselben Betreiber ist das nicht. Zufall halte ich aber für die schwächere Erklärung.

Was die eigentlich wollen

Ein Passwort wollen sie nicht. Es gibt keinen Login, keine Marke und kein Konto, das man übernehmen könnte. Wer klickt, landet nach dem Gate über den Tracker auf einer Angebotsseite. Dort soll man für „Cloud Storage" eine Karte hinterlegen. Bei solchen CPA-Angeboten heißt das meist: kleines Test-Abo, danach wiederkehrende Abbuchungen, die schwer zu kündigen sind. Der Vermittler bekommt pro Abschluss Provision.

Die Arbeitsteilung ist sauber. Ein Versand-Dienstleister liefert Google-VM, Spoof-Liste und Bucket. Der Vermittler „youness" schickt seinen Traffic durch. Das Netzwerk betreibt Tracker, Abmelde-Attrappe und Logo-Server. Einen einzelnen „Phisher" gibt es hier nicht. Es ist eine Lieferkette.

Woran ihr es erkannt hättet

Das Ablaufdatum liegt in der Vergangenheit. Am 5. November ein Abo „vom 2. Oktober" nicht verlängern zu können, ist kein Zahlungsproblem.
Keine Marke, keine Anrede. Welcher Cloud-Speicher denn? Apple, Google und Dropbox nennen ihren Namen.
Betreff und Inhalt passen nicht. „How to update … settings" oben, „Payment Failure" unten.
Absender ist eine Architektur-Website. „Account Update Desk" von einer Fremddomain.
„This offer" im Footer. Euer Speicheranbieter schickt euch keine Angebote zum Abbestellen, sondern Rechnungen.
Der Link führt auf storage.googleapis.com/<Zeichensalat>/lis. Kein Anbieter-Portal würde so aussehen.

Was ihr tun könnt

Abos nie über Mail-Links verwalten. Einstellungen am Gerät oder die App des Anbieters öffnen. Ist dort alles grün, ist die Mail Müll.
Rohe storage.googleapis.com-Links im Mailfilter markieren, wenn der Absender nicht Google selbst ist. Legitime Rechnungsmails nutzen so etwas praktisch nie.
Externe Bilder standardmäßig blockieren. Schon das Öffnen lädt hier das Logo vom Affiliate-Server und meldet: Mail angekommen.
Eigene Domain nicht zur nächsten Absender-Attrappe machen. DMARC mit Report-Adresse setzen und schrittweise auf quarantine oder reject gehen. Wo ihr steht, zeigt der Mail-Check hier auf der Seite.
Firmenkarten für Online-Abos begrenzen (virtuelle Karte, Limit) und Abbuchungen monatlich ansehen.

Fazit

Handwerklich ist die sechste Runde ein Rückschritt: altes Template, abgelaufenes Datum und ein Spamfilter, der das Muster längst gelernt hat. Interessant ist sie trotzdem, weil erstmals das Ende der Kette sichtbar wird. Ein Affiliate-Link mit Vornamen und Versanddatum, daneben eine Abmelde-Attrappe vom selben Registrar. Das ist kein Hacker im Keller. Das ist Performance-Marketing für Abo-Fallen, und Google stellt die Bühne.

Die Domain des gespooften Absenders ist redigiert (<architektur-site>[.]com). Die Seitenbetreiber sind hier selbst Opfer: Ihre Domain wurde ohne ihr Zutun als Absender missbraucht, ihr Mailserver war nicht beteiligt. Pranger-Wirkung vermeiden. Die vollständigen IOCs liegen intern.