Cloud-Speicher voll? Die Phishing-Masche mit Rabattschild und 0,4 Punkten Luft

„Your photos, videos, and contacts will be lost." Wer ein Smartphone hat, hat so einen Satz schon einmal ernsthaft gelesen - iCloud meldet einen vollen Speicher mit ziemlich ähnlichen Worten. Genau darauf setzt diese Mail. Sie ist die dritte Probe eines Baukastens, den ich hier schon zweimal zerlegt habe. Diesmal mit einem neuen Köder, einem Detail, das ich so noch nicht hatte, und einem Spamfilter, der knapp danebenlag.

Was in der Mail steht

Betreff: „Final Notice: Capacity Limit Exceeded". Absender: System Reminder <support[@]<filmmagazin-de>[.]com>. Die Domain gehört einem deutschen Filmmagazin, das es seit 2012 gibt und das mit Cloud-Speicher exakt nichts zu tun hat. URLs und Domains sind in diesem Artikel defangt, damit nichts aus Versehen angeklickt wird.

Der Inhalt: Der Speicher sei voll, Fotos, Videos, Dokumente und Kontakte würden nicht mehr gesichert. Eine Tabelle zeigt „Photos", „Cloud Drive" und „Mail", alle mit „Stopped Updating". Oben ein roter Badge „100% Full", unten ein einziger Button: „Continue". Keine Marke, kein Betrag, keine Frist - obwohl der Betreff „Final Notice" sagt. Die Anrede lautet „Dear user".

Markenlos ist hier Absicht. „Photos, Cloud Drive, Mail" ist die iCloud-Struktur, ohne dass das Wort iCloud fällt. So passt die Mail für Apple-, Google- und Microsoft-Kunden gleichermaßen, und kein Filter auf Markennamen schlägt an.

Das Rabattschild in der Statustabelle

Schaut euch die letzte Zeile im Screenshot an. „Mail: Stopped", daneben ein blaues Badge „Updating". Bei Photos und Cloud Drive steht derselbe Text ganz normal. Warum sieht die dritte Zeile so anders aus?

Ein Blick in den HTML-Quelltext beantwortet das. Die Zeile nutzt die CSS-Klassen price-new und save-chip. Das große fette „Stopped" sitzt im Feld für den neuen Preis. Das blaue „Updating" sitzt in dem Badge, in dem bei einer Tarifmail so etwas wie „Save 50%" stehen würde. Weiter oben gibt es noch eine Klasse plan-devices und unter dem Button einen leeren Container für eine Preisnotiz.

Die Vorlage war also mal eine Tarif- oder Upgrade-Mail mit durchgestrichenem Preis und Rabattschild. Jemand hat die Texte ausgetauscht und das Layout gelassen. Dazu passt, dass vor dem <!DOCTYPE html> ein unsichtbares Byte-Order-Mark steht - die Datei wurde in einem Windows-Editor gespeichert und roh in den Mailbody kopiert. Recycling ist ja grundsätzlich lobenswert. Nur nicht bei Phishing-Vorlagen.

Wo sie herkommt

Die Mail kam von 34[.]125[.]9[.]72, laut ASN-Daten eine Maschine bei Google LLC (AS396982) in Las Vegas. Rückwärtsname 72.9.125.34.bc.googleusercontent.com - eine gemietete Compute-Engine-VM, kein Mailserver. Das ist dieselbe Herkunft wie bei der Cloud-Speicher-Abo-Welle und der Antivirus-Variante, nur eine andere Region. Auch der Rest passt: kein DKIM, Absender immer support@, Message-ID immer 32 Hex-Zeichen vor der gespooften Domain.

Das Filmmagazin selbst wurde nicht gehackt. Sein echter Mailserver steht bei netcup in Nürnberg, und genau den listet sein SPF-Record:

v=spf1 a mx ip4:37.120.x.x ~all

Eine Google-VM steht da nicht drin. Das ~all am Ende heißt „nicht erlaubt, aber bitte nur markieren". Ergebnis beim Empfänger: spf=softfail. Die DMARC-Policy steht auf p=none, ohne Report-Adresse. Das Magazin erfährt also nicht einmal, dass jemand in seinem Namen Cloud-Warnungen verschickt. Bei einer Redaktion ohne eigene IT-Abteilung ist das keine Seltenheit.

In dieser Serie habe ich damit alle drei SPF-Varianten gesehen: +all brachte dem Angreifer ein geschenktes Pass, -all ein Fail, ~all jetzt ein Softfail. Er sucht sich die Domains offensichtlich nicht danach aus. Er nimmt, was da ist.

6,6 von 7,0

Der empfangende Server hat einen echten Spamfilter mit Schwelle 7,0. Die Mail bekam 6,6 Punkte und wurde zugestellt. Die Juli-Probe desselben Baukastens am selben Server: 6,7. Zweimal knapp drunter.

Interessanter ist, was im Header fehlt. Dort stehen RCVD_IN_ZEN_BLOCKED, URIBL_BLOCKED, URIBL_DBL_BLOCKED und URIBL_ZEN_BLOCKED. Das bedeutet: Der Filter hat bei Spamhaus und URIBL nachgefragt und keine Antwort bekommen, weil die Abfrage abgelehnt wurde. Das passiert typischerweise, wenn über einen großen geteilten DNS-Resolver gefragt wird. Die Blocklisten haben also nichts beigetragen. Ob sie etwas gefunden hätten, weiß niemand. Fast der gesamte Score kam aus dem Bayes-Filter.

Wo die Links hinführen

Der Button zeigt auf hxxps://storage.googleapis[.]com/ghshghgfhghjghsgh/lis. Google Cloud Storage, echter Google-Host, echtes Zertifikat. Der Bucket-Name ist Tastatur-Geklimper auf der mittleren Buchstabenreihe. Das Objekt heißt lis - genau wie bei der Juli-Probe, nur in einem anderen Bucket. Kit-Konstante.

VirusTotal kennt die URL und meldet 1 von 91, eine einzige Community-Liste. Damit ist es zwar der erste Bucket dieser Serie mit überhaupt einem Treffer, aber auch erst drei Wochen nach dem Versand. Der Seitentitel dort lautet wieder „Verification Required" - derselbe Titel wie bei allen Vorgängern. Das deutet auf ein Bot-Gate: Scanner sehen eine Zwischenseite, echte Browser werden weitergereicht. Aufgerufen habe ich das nicht.

Neu ist der Abmeldelink. Er führt auf hxxps://www.coredatafye[.]com/o-vskv-d21-… mit einem 32-stelligen Token pro Mail. Die Domain wurde am 11. Juni 2026 registriert, Registrant in der Ukraine, gehostet bei HostPapa. VirusTotal: 3 von 92, Seitentitel „We are sorry to see you go". Das ist die erste Domain in dieser Serie, die dem Angreifer tatsächlich selbst gehört. Und es ist der einzige Link in der Mail, der weiß, wer ihr seid.

Was die eigentlich wollen

Kartendaten oder ein Abo. „Continue" klingt harmlos, kein „Bezahlen", kein „Login". Am Ende solcher Funnel steht aber ein Formular für „mehr Speicher" gegen einen kleinen Betrag. Wer dort Karte und CVC eingibt, hat danach ein wiederkehrendes Abo unter einem unauffälligen Händlernamen am Hals, oder die Kartendaten ziehen weiter.

Und wer stattdessen brav auf „unsubscribe" klickt, bestätigt per Token: Diese Adresse lebt und liest. Mehr Spam, nicht weniger.

Woran ihr's erkannt hättet

Ein Filmmagazin verwaltet nicht euren Cloud-Speicher. Das reicht eigentlich schon.

Es gibt keinen Anbieternamen. Apple, Google und Microsoft schreiben ihren Namen auf ihre Mails, und zwar groß.

„Final Notice" ohne Frist, Betrag oder Konto ist keine letzte Mahnung, sondern ein Stimmungsmacher.

Und das Wichtigste: Ein voller Speicher steht immer auch auf dem Gerät. iPhone, Einstellungen, euer Name, iCloud. Steht da nichts Rotes, ist die Mail erledigt. Auf die URL zu schauen hilft hier übrigens nicht. Die gehört wirklich Google.

Was ihr tun könnt

Speicherstand nur auf dem Gerät prüfen. Eine einzige Regel für alle im Betrieb: Speicher-, Abo- und Kontowarnungen werden in der App oder den Einstellungen geprüft, nie über einen Mail-Link.

Nicht auf „Abmelden" klicken, wenn die Mail Spam ist. Als Spam melden und löschen. Der Abmeldelink ist hier der einzige personalisierte Link der ganzen Mail.

Die eigene Domain absichern. SPF auf -all, DMARC mindestens mit Report-Adresse und dann schrittweise auf quarantine und reject. Das schützt nicht euer Postfach, sondern verhindert, dass eure Domain wie hier das Filmmagazin als Absender herhält. Wo ihr steht, zeigt der Mail-Check hier auf der Seite.

Beim Provider nachfragen, ob die Blocklisten antworten. Taucht URIBL_BLOCKED oder ZEN_BLOCKED in euren Mail-Headern auf, laufen die Spamhaus-Abfragen ins Leere. Ein eigener Resolver oder ein Spamhaus-DQS-Zugang behebt das.

Firmenkarten mit Limit und Push-Benachrichtigung, und keine Firmenkarte in privaten Cloud-Konten. Das begrenzt genau den Schaden, auf den der Funnel zielt.

Fazit

Technisch ist das dieselbe Nummer wie im September: geliehene Absenderdomain, Google-VM, Google-Bucket, Bot-Gate. Neu sind der fiesere Köder - Urlaubsfotos ziehen besser als Rechnungen - und eine eigene Abmelde-Domain, die zum ersten Mal einen echten Ansatzpunkt liefert. Handwerklich bleibt es Resteverwertung: Wer seine Speicherwarnung aus einer Rabatt-Mail zusammenschneidet und dabei das Rabattschild vergisst, hat die Vorlage nicht einmal ganz gelesen.

Die Domain des gespooften Absenders ist redigiert (<filmmagazin-de>[.]com). Das Magazin ist hier selbst Opfer - seine Domain wurde ohne sein Zutun als Absender missbraucht, sein Mailserver war nicht beteiligt. Pranger-Wirkung vermeiden. Die vollständigen IOCs liegen intern.