Fotos werden nicht mehr gesichert: iCloud-Look, Google-Bucket und ein Spamfilter, der plötzlich nichts mehr erkennt

„Your photos are no longer being saved." Wer ein iPhone mit Gratis-iCloud hat, kennt diese Sorte Meldung. Echt ist sie oft genug. Diese hier nicht. Sie ist die fünfte Probe eines Baukastens, den ich hier schon mehrfach zerlegt habe, und die erste, die richtig gut aussieht. Interessanter als die Optik ist aber, was sie mit dem Spamfilter gemacht hat.

Was in der Mail steht

Absender: Backup Alerts <support[@]<gebetsportal-it>[.]it>. Die Domain gehört einer italienischen Seite mit Gebeten für die Familie, registriert 2009. Cloud-Speicher verkauft sie nicht. URLs und Domains sind in diesem Artikel defangt, damit nichts aus Versehen angeklickt wird.

Der Inhalt ist kurz. Speicher voll, Fotos, Videos und Dateien werden nicht mehr gesichert. Ein roter Balken, „0 GB available". Darunter eine Statustabelle: Plan „Free 5 GB", Backup „Paused", nächste Stufe „50 GB", Account #2125568. Ein blauer Button „Upgrade Storage". Keine Frist, keine Löschdrohung, keine Rechnung.

Das Wort Apple steht nirgends. Aber wer mit F12 in den Quelltext schaut, findet Apples Hausfarben (#0071E3, #1D1D1F), die Schrift -apple-system und für die ID sogar „SF Mono". 5 GB gratis, dann 50 GB: Das sind exakt die iCloud-Stufen. Google One startet bei 15 GB. Hier wird also gezielt das iPhone-Publikum angesprochen, ohne dass ein Markenfilter anschlagen kann.

Der bekannte Unterbau

Die Mail kam von 34[.]123[.]90[.]110, laut ASN-Daten Google LLC (AS396982) in Iowa. Der Rückwärtsname 110.90.123.34.bc.googleusercontent.com verrät eine gemietete Compute-Engine-VM. Die Vorwelle von letzter Woche kam aus derselben Region. Auch der Rest ist Serie: kein DKIM, Absender immer support@, Message-ID immer 32 Hex-Zeichen vor der gespooften Domain, Einlieferung mit nacktem SMTP statt ESMTP.

Die Gebetsseite wurde nicht gehackt. Ihr SPF-Record erlaubt nur die Server ihres Hosters und endet auf ~all. Eine Google-VM steht da nicht drin, also spf=softfail. DMARC steht auf p=none ohne Report-Adresse. Die Betreiber erfahren also nicht, dass jemand in ihrem Namen Speicherwarnungen verschickt. Das ist bei einer privaten Seite ohne IT-Abteilung völlig normal.

Der eigentliche Befund: Bayes sieht nichts mehr

Der empfangende Server bei netcup filtert mit SpamAssassin und Rspamd. Die beiden Vorwellen kamen bei SpamAssassin auf 6,6 von 7,0 Punkten. Knapp durch, und fast alle Punkte stammten aus dem Bayes-Filter. Der hatte die Masche gelernt.

Diese Mail bekommt 2,7. Kein einziger BAYES-Treffer im Header. Übrig bleiben SPF-Softfail, dynamischer Rückwärtsname und „nur HTML". Die Spamhaus-Abfragen liefen wieder ins Leere (URIBL_DBL_BLOCKED). Rspamd sieht dasselbe Bild: 7,75 statt 12,85 Punkte. Die Differenz ist ziemlich genau der Bayes-Anteil der Vorwelle.

Neues Template, null Lernhistorie, Score halbiert. Jede Welle dieser Serie hatte ein eigenes Layout. Ob die Täter das bewusst gegen Bayes einsetzen oder einfach ständig neue Vorlagen generieren lassen, weiß ich nicht. Die Wirkung ist dieselbe. Inhaltsbasierte Filter laufen dieser Kampagne immer eine Welle hinterher.

Rspamd hat trotzdem X-Spam: Yes gesetzt, allein wegen SPF und schlechter Sender-Reputation. Ob die Mail im Posteingang oder im Spam-Ordner landet, hängt also an einer Postfach-Regel für diesen Header.

Wo die Links hinführen

Die Mail hat fünf Links. Vier davon, „Upgrade Storage", „Manage Storage", „Privacy Policy" und „Help Center", zeigen auf hxxps://storage.googleapis[.]com/jjumsgost/li. Google Cloud Storage, echter Google-Host, echtes Zertifikat. Der fünfte, „Unsubscribe", geht auf hxxps://storage.googleapis[.]com/jjumsgostunsb/li. Gleicher Bucket-Name plus unsb, das dritte Mal in dieser Familie.

VirusTotal hat den Button-Bucket eine gute Stunde vor dem Versand zum ersten Mal gesehen und meldet 1 von 93. Den Abmelde-Bucket auch, ebenfalls 1 von 93. Beide Seiten heißen „Verification Required", beide sind knapp 9,9 KB groß. Das ist dieselbe Seite: ein Bot-Gate, das Scanner abfängt und echte Browser weiterreicht. 59 Engines halten sie für harmlos. Aufgerufen habe ich sie nicht.

Die seriös klingenden Bucket-Namen der Vorwelle (cloud-storage-plans) waren übrigens nur eine Episode. Jetzt ist es wieder Buchstabensalat.

Was die eigentlich wollen

Kartendaten oder ein Abo. Hinter dem Gate steht nach allem, was die Vorwellen zeigen, ein Formular für „mehr Speicher" gegen einen kleinen Betrag. Wer dort Karte und CVC eingibt, hat danach eine wiederkehrende Abbuchung unter unauffälligem Händlernamen, oder die Kartendaten wandern weiter.

Der Upsell-Köder ist dabei klüger als die Drohungen der Vorwellen. Wer „Upgrade" klickt, erwartet ein Zahlformular. Es gibt nichts, was misstrauisch macht, wenn es kommt.

Woran ihr's erkannt hättet

Eine italienische Gebetsseite verwaltet nicht euren Cloud-Speicher. Ein Blick auf die Absenderadresse reicht.

Apple schreibt seinen Namen auf seine Mails, nennt euren Namen und schickt sie von apple.com. Hier fehlt alles drei.

Account-Nummer und „Cloud ID" sind identisch. Und sie stehen bei jedem Empfänger gleich im Template.

Auch „Privacy Policy" und „Help Center" führen zum Upgrade-Link. Echte Anbieter haben dafür echte Seiten.

Und das Wichtigste: Ein voller iCloud-Speicher steht auch auf dem iPhone. Einstellungen, euer Name, iCloud. Upgrades laufen dort, nicht über einen Mail-Button. Die URL zu prüfen hilft nicht. Die gehört wirklich Google.

Was ihr tun könnt

Speicherwarnungen nur auf dem Gerät prüfen. Eine Regel für alle im Betrieb: Cloud-Abos nie über einen Mail-Link anfassen. Damit ist diese Serie erledigt, egal wie hübsch das nächste Template wird.

X-Spam: Yes auch wirklich aussortieren. Viele Hoster setzen den Header, sortieren aber nicht automatisch. Eine Filterregel im Webmailer reicht. Bei dieser Mail war das der einzige Filter, der angeschlagen hat.

Bei Spam keinen Footer-Link klicken. Auch nicht „Abmelden". Hier führten alle Links ins selbe Gate.

Die eigene Domain absichern. SPF auf -all, DMARC mit Report-Adresse, dann schrittweise auf quarantine und reject. Das verhindert, dass eure Domain als Absender herhält. Wo ihr steht, zeigt der Mail-Check hier auf der Seite.

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

Fazit

Die fünfte Aufführung desselben Stücks, und die erste mit gutem Kostüm: Apple-Farben, ruhiger Ton, plausibles Angebot. Der Unterbau ist unverändert billig. Geliehene Domain, Google-VM, Google-Bucket. Lehrreich ist der Spamfilter. Ein neues Template, und der Bayes-Filter fängt wieder bei null an.

---

Die Domain des gespooften Absenders ist redigiert (<gebetsportal-it>[.]it). 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.