4EN6_by Tobias Wilke
Zurück zum Blog

15. September 2026

„Cloud Storage“ will neue Kartendaten - verschickt im Namen einer ukrainischen Behörde

Tobias Wilke

Tobias Wilke

@wilketob

„Cloud Storage“ will neue Kartendaten - verschickt im Namen einer ukrainischen Behörde
#phishing#spam#cloud-storage#spf#google-cloud#kmu-security

Mein Cloud-Speicher-Abo ist abgelaufen. Sagt eine Mail mit dem Betreff „Payment Failed Subscription Terminated“. Welcher Speicher? Steht nicht drin. Bei welchem Anbieter? Heißt einfach „Cloud“. Abgeschickt hat sie eine ukrainische Regionalverwaltung. Und der Spamfilter hat bestätigt: Der Absender ist berechtigt.

URLs und IPs sind im Folgenden defangt (hxxps, [.]), damit nichts aus Versehen angeklickt wird.

Die Phishing-Mail im Mailclient: Absender „Cloud Renewal“ mit redigierter Behördenadresse, Betreff „Payment Failed Subscription Terminated“, rote Überschrift „Payment Failure for Cloud Storage Renewal“, eine rosa Warnbox, leere Felder bei Subscription ID und Expiration Date und ein blauer Button „Update Payment Information“. Das externe Logo wird als Platzhalter angezeigt, die Empfängeradresse ist unkenntlich gemacht.

Was in der Mail steht

Rote Überschrift, rosa Warnkasten, alles auf Englisch: „Your Payment Method Has Expired. We're unable to renew your Cloud Storage.“ Man möge bitte die Zahlungsdaten aktualisieren, sonst drohe eine Unterbrechung. Direkt danach, im selben Kasten, das Verkaufsgespräch: Wenn der Speicher voll sei, könne man ja gleich upgraden. Mahnung und Upsell in einem Atemzug. Das schreibt kein Abo-System, das schreibt jemand, der Provision bekommt.

Darunter ein Block „Account Details“ mit drei Feldern. Bei „Product“ steht „Cloud Storage Space“. Bei „Subscription ID“ und „Expiration Date“ steht: nichts.

Das ist kein Darstellungsfehler. Wer F12 drückt und in den Quelltext schaut, findet am Ende der Mail ein Skript:

const subId = "IC-" + Math.floor(1000000000 + Math.random() * 9000000000);

Die Abo-Nummer ist eine Zufallszahl mit dem Präfix IC-, wie iCloud. Das Ablaufdatum ist immer „heute“. Beides soll per JavaScript in die Mail geschrieben werden. Nur führt praktisch kein Mailclient JavaScript aus, aus gutem Grund. Die Felder bleiben leer. Ein Kommentar im Code verrät noch, dass das Skript mal „October 2, 2025“ anzeigen sollte. Die Vorlage ist also fast ein Jahr alt, und im Postfach hat das Skript noch nie funktioniert.

Unten der blaue Button „Update Payment Information“, dann „Cloud Customer Support“ und ein Abmeldelink „To stop messages regarding this offer“. Regarding this offer. Nicht „regarding your account“.

Warum der SPF-Check trotzdem „pass“ sagt

Absender ist support[@]<regionalverwaltung-ua>[.]gov[.]ua, die Domain einer ukrainischen Oblast-Verwaltung. Die hat weder einen Cloud-Speicher zu verkaufen noch wurde sie gehackt. Die Mail kam nicht über ihre Server, sondern direkt von einer Google-Cloud-VM: 104[.]199[.]187[.]131, AS396982 Google LLC, Region Taiwan.

Normalerweise fliegt so etwas bei SPF auf. SPF ist die Liste im DNS, in der eine Domain festlegt, welche Server für sie senden dürfen. Hier sagt der Empfangsserver aber:

spf=pass (sender IP is 104[.]199[.]187[.]131) smtp.mailfrom=support[@]<regionalverwaltung-ua>[.]gov[.]ua

Der Grund steht im DNS-Eintrag der Behörde. Er endet so:

v=spf1 ip4:78.152.160.0/19 ip4:46.252.208.0/20 ... +all

+all heißt: „Alle anderen Server dürfen auch.“ Damit ist die gesamte Liste davor wirkungslos. Jede IP der Welt besteht den SPF-Check für diese Domain. Weil Absender- und Envelope-Domain übereinstimmen, wäre auch DMARC zufrieden. Selbst ein Postfach, das DMARC streng durchsetzt, hätte die Mail an dieser Stelle durchgelassen.

Neu ist die Masche nicht. Im Juli kam bei mir eine fast identische Mail an: gleiche Aufmachung, gleiche Google-Cloud-Herkunft, gleiches Format der Message-ID. Damals wurde eine andere Fremddomain gespooft, deren SPF mit ~all endet. Ergebnis: softfail. Diesmal gab es ein sauberes pass. Ob der Versender gezielt nach solchen Einträgen sucht, geben zwei Mails nicht her. Die Absenderdomains wechseln jedenfalls, und mit +all hat er diesmal den Hauptgewinn gezogen.

Wohin der Button führt

Das Ziel ist hxxps://storage.googleapis[.]com/cloudstorage-kizi/index. Das ist Google Cloud Storage, ein ganz normaler Dateispeicher. cloudstorage-kizi ist der Name des Speicherbereichs (Bucket), index eine Datei ohne Endung. Das Zertifikat ist echt, die Domain gehört Google, und in der Statusleiste steht beruhigend „cloudstorage“.

Aufgerufen habe ich den Link nicht. VirusTotal kennt ihn: 0 von 90 Scannern schlagen an. Die Schwester-URL aus der Juli-Mail steht nach vier Wochen bei 1 von 91. Die Reputation leiht sich der Angreifer bei Google. Interessant ist der Seitentitel, den VirusTotal gespeichert hat: „Verification Required“. Das passt nicht zu „Zahlungsdaten aktualisieren“. Wahrscheinlich sitzt dort eine „Bestätige, dass du ein Mensch bist“-Seite, die Scanner aussortiert und Menschen weiterleitet.

Was die eigentlich wollen

Eine statische Datei in einem Bucket kann keine Kartendaten verarbeiten. Hinter dem Einstieg wartet also eine weitere Seite, und dort das eigentliche Formular. Das Logo der Mail kommt von ni03hfph[.]com, registriert im Februar 2026, Pfad /686/offers/16448/thumb/logo.png. Das ist das Schema eines Affiliate-Netzwerks: Die Offer-Nummer 16448 hat ein Logo, und wer Klicks liefert, wird bezahlt.

Hättet ihr geklickt, wärt ihr vermutlich auf einer „Cloud Storage“-Bestellseite gelandet. Speicher voll, nur ein kleiner Betrag für die Verlängerung, bitte Kartendaten eingeben. Danach gibt es wiederkehrende Abbuchungen, Kartenmissbrauch oder beides. An eure echten Fotos in iCloud oder Google One kommt dabei niemand. Die Mail braucht das auch nicht.

Woran ihr's erkannt hättet

Die Mail nennt keinen Anbieter. Kein echter Dienst verschickt Rechnungen als „Cloud“. Abo-Nummer und Ablaufdatum sind leer, obwohl sie das Einzige wären, was ein echtes Abo-System garantiert kennt. Der Absender ist eine .gov.ua-Adresse. Und der Button führt nicht zu Apple, Google oder Dropbox, sondern in einen anonymen Speicher-Bucket.

Was ihr tun könnt

Abos nur direkt beim Anbieter prüfen. Einstellungen am Handy, App oder eigenes Lesezeichen. Eine Mail über eine fehlgeschlagene Zahlung ist nie der Weg dorthin.

Den eigenen SPF-Eintrag anschauen. dig +short TXT eure-domain.de oder, ohne Terminal, mein Mail-Check hier auf der Seite: Domain eintippen, und ihr seht MX, SPF, DKIM und DMARC samt Einschätzung. Endet der SPF-Eintrag auf +all oder ?all, darf jeder in eurem Namen senden. ~all ist das Minimum, -all besser, dazu DMARC mindestens mit p=quarantine.

Direktlinks auf Cloud-Speicher markieren lassen. Links auf storage.googleapis.com, blob.core.windows.net oder s3.amazonaws.com in Mails von Externen verdienen einen Warnhinweis. Nicht sperren, dafür nutzen sie zu viele legitime Dienste.

Externe Bilder im Mailclient standardmäßig blockieren. Dann erfährt auch der Logo-Host nicht, dass die Mail geöffnet wurde.

Firmenkarten für Online-Abos begrenzen. Virtuelle Karten mit Limit und eine Push-Nachricht bei jeder Belastung machen aus einem Fehlklick einen kleinen Schaden.

Fazit

Die Mail selbst ist Massenware mit einem Skript, das im Mailclient nie läuft. Die Zustellung dagegen ist durchdacht: Google-VM, Google-Speicher, und eine Absenderdomain, die jedem Server der Welt eine Sendeerlaubnis ausstellt. Wer seinen SPF-Eintrag noch nie angeschaut hat, sollte das heute tun.

Die gespoofte Absender-Domain ist redigiert (<regionalverwaltung-ua>[.]gov[.]ua). Die betroffene Behörde ist hier selbst Opfer: Ihre Domain wurde ohne Zugriff auf ihre Systeme als Absender missbraucht, weil der SPF-Eintrag jedem Server das Senden erlaubt. Pranger-Wirkung vermeiden. Die vollständigen IOCs liegen intern.