Antivirus-Abo angeblich geplatzt: Dieselbe Masche wie letzte Woche - diesmal am SPF-Record gescheitert

Kurz gesagt: Eine englische Mail behauptet, das Abo einer Antivirus-Software sei dreimal an der Abbuchung gescheitert und das Gerät deshalb ungeschützt. Der Link führt in einen Google-Cloud-Storage-Bucket, VirusTotal sagt 0 von 90. Es ist derselbe Baukasten wie bei der Cloud-Speicher-Welle vor fünf Tagen - nur dass die gespoofte Absenderdomain diesmal einen sauberen SPF-Record hatte. Ergebnis: SPF-Fail statt SPF-Pass, Spamfilter-Score 8,7 statt 4,8, Mail markiert statt durchgewunken. Ein Zeichen Unterschied im DNS.

Vor fünf Tagen habe ich hier eine Mail zerlegt, die ein abgelaufenes Cloud-Speicher-Abo behauptete und dafür die Domain einer ukrainischen Behörde missbraucht hat. Am Samstag lag die nächste im Postfach. Gleicher Baukasten, gleicher Ablauf, anderer Köder - und ein technisch komplett anderes Ergebnis. Genau deshalb ist sie einen eigenen Artikel wert.

Was in der Mail steht

Betreff: „Your device may be exposed because your payment was declined". Absender: Payment Security Team <support[@]<familienverband-es>[.]org>. Die Domain gehört einem spanischen Verband für kinderreiche Familien. URLs und Domains sind in diesem Artikel defangt, damit nichts aus Versehen angeklickt wird.

Der Inhalt ist schnell erzählt. Rote Linie oben, „FINAL ATTEMPT", darunter „Your Payment Was Declined." Das Abo für „antivirus & privacy protection" sei mehr als dreimal an der Abbuchung gescheitert. Dann der Warnkasten:

Warning: Your device is currently exposed to hackers, scammers, data theft, and improper session handling.

Darunter eine Tabelle mit dem Dienst „Privacy Protection Pro" und dem Status „Declined (3 Attempts)", dazu zwei Buttons. Beide zeigen auf dieselbe URL. Der Abmeldelink in der Fußzeile landet in einem zweiten Bucket desselben Angreifers - wer sich abmelden will, klickt also ebenfalls beim Absender an, nur langsamer.

Was komplett fehlt: ein Herstellername. „Privacy Protection Pro" ist kein Produkt, das es gibt. Kein Logo, kein Impressum, kein Betrag, keine Vertragsnummer, keine Anrede. Die Mail weiß über ihren Empfänger exakt nichts und behauptet trotzdem, es habe drei fehlgeschlagene Abbuchungen gegeben.

Der eigentliche Dreh steckt in der Logik: Man soll zahlen, um geschützt zu sein - und gibt dabei genau die Daten heraus, vor deren Diebstahl die Mail warnt.

Warum der Filter diesmal angeschlagen hat

Hier wird es interessant. Die Mail kam von 35[.]245[.]188[.]82, einer Maschine in AS396982 Google LLC, GCP-Region us-east4. Keine Mailinfrastruktur, sondern eine gemietete Compute-Engine-VM. Der Rückwärtsname 82.188.245.35.bc.googleusercontent.com sagt das auch ziemlich deutlich.

Die Absenderdomain hat damit nichts zu tun. Sie nutzt Microsoft 365 als Mailsystem, ihr MX zeigt auf <familienverband-es>-org.mail.protection.outlook.com. Wäre das Postfach übernommen worden, wäre die Mail über Microsoft gelaufen und DKIM-signiert gewesen. Sie kam aber von einer Google-VM und trägt keine Signatur. Die Domain ist gespooft, nicht gehackt. Der Verband hat von alldem nichts gewusst.

Und jetzt der Unterschied zur Vorwoche. Der SPF-Record der Domain:

v=spf1 +a +mx ip4:82.98.172.106 ip4:82.98.155.70 ip4:91.134.230.199
  include:<familienverband-es>.ip-zone.com include:spf.newslettersoft.com
  include:spf.protection.outlook.com -all

Das letzte Feld ist -all. Hardfail. Übersetzt: Wer nicht in dieser Liste steht, darf nicht in meinem Namen senden, Punkt. Eine Google-Cloud-VM steht nicht drin. Der empfangende Server notiert:

spf=fail (sender IP is 35.245.188.82)

Bei der Cloud-Speicher-Welle letzte Woche endete der Record der gespooften Behördendomain auf +all. Das heißt „jede IP der Welt darf für mich senden" und macht die ganze Aufzählung davor zur Dekoration. Derselbe Angreifer bekam damit ein sauberes spf=pass geschenkt.

Zwei Wellen, gleicher Baukasten, gleiche Technik, ein Zeichen Unterschied im DNS:

	Welle 1 (14.09.)	Welle 2 (19.09.)
SPF der gespooften Domain	+all	-all
SPF-Ergebnis	pass	fail
SpamAssassin-Score	4,8 (Schwelle 7,0)	8,7 - markiert

Das ist so nah an einem kontrollierten Experiment, wie man in diesem Geschäft kommt. Wer wissen will, warum ein korrekter SPF-Record etwas bringt: Das da oben ist die Antwort.

Zwei Einschränkungen. Im Score selbst haben die SPF-Regeln 0,0 Punkte beigetragen - gepunktet haben Bayes und eine Regel für Vorschussbetrug. Und die Domain steht bei DMARC auf p=none, also „bitte melden, aber nichts unternehmen". Mit p=reject hätte jeder durchsetzende Empfänger die Mail schon im SMTP-Dialog abgewiesen. Der SPF-Record war richtig gesetzt. Die Konsequenz daraus fehlt noch.

Wo der Link hinführt

Beide Buttons zeigen auf hxxps://storage.googleapis[.]com/testclddte/m, der Abmeldelink auf hxxps://storage.googleapis[.]com/jmmcdlgounsb/m.

Das ist Google Cloud Storage. Echter Google-Host, echtes Google-Zertifikat, saubere Domain-Historie. Der Bucket-Name steht im Pfad und nicht im Hostnamen - für einen Filter, der auf Domains schaut, ist das schlicht Google. Der Objektname ist ein einzelnes m ohne Dateiendung.

Der Angreifer besitzt an dieser Kampagne nichts: nicht die Absenderdomain, nicht den Versandserver, nicht den Webspace. Identität, Versandweg und Hosting sind geliehen, dreimal bei Anbietern mit tadelloser Reputation. Abschalten kann man davon nur die einzelnen Bucket-Pfade, und die sind ohnehin Wegwerfware. Randnotiz zur Sorgfalt: Der Bucket für den Haupt-Link heißt testclddte. Da ist jemand mit seinem Test-Bucket in Produktion gegangen.

VirusTotal sagt zu beiden URLs 0 von 90. Kein einziger Scanner schlägt an, einen Tag nach dem Versand. Die Kategorien lauten „online storage" und „web infrastructure" - die Engines sehen korrekt, dass da ein Objekt in einem Cloud-Speicher liegt. Was drinsteht, sieht keine.

Beide URLs liefern bei VirusTotal denselben Seitentitel: „Verification Required". Exakt derselbe Titel wie beim Bucket der Vorwoche. Das ist der beste Beleg dafür, dass hier derselbe Baukasten läuft, quer über zwei Köder und drei Buckets hinweg. Inhaltlich deutet der Titel auf ein Bot-Gate: Automaten bekommen eine Zwischenseite, echte Browser werden per JavaScript weitergereicht. Deshalb endet die passive Analyse hier - was hinter dem Gate liegt, habe ich nicht aufgerufen.

Was die eigentlich wollen

Kartendaten. Der CTA heißt „Update Billing Info", und am Ende solcher Funnel steht ein Formular mit Karteninhaber, Nummer, Ablaufdatum und CVC. Oft mit einem „Verifizierungsbetrag" von ein, zwei Euro, der die Karte als aktiv bestätigt.

Wenn ihr geklickt hättet: Die Adressleiste hätte storage.googleapis.com gezeigt, mit gültigem Zertifikat und Schloss-Symbol. Alles, was man üblicherweise prüft, hätte gepasst. Dahinter erst die Prüfseite, dann die Weiterleitung in den Funnel, dann das Formular. Und danach entweder eine Abbuchung, die nie aufhört, weil sie unter einem unauffälligen Händlernamen läuft - oder ein vollständiger Kartendatensatz, der weiterzieht.

Der zweite Zweck ist unspektakulärer, aber sicher: Die Mail enthält kein Tracking-Pixel, der Klick ist das einzige Lebenszeichen. Wer klickt, egal auf welchen der drei Links, steht danach auf der Liste der bestätigt aktiven Adressen. Malware ist dagegen nicht im Spiel - kein Anhang, kein Download, keine Makros. Der Schaden entsteht durch Tippen, nicht durch Ausführen.

Woran ihr's erkannt hättet

Ohne jedes technische Wissen, in dieser Reihenfolge:

Der Absender ist ein spanischer Familienverband. Der schickt keine englischen Antivirus-Rechnungen. Schon das allein reicht.

Es gibt keinen Herstellernamen und keinen Betrag. Echte Abrechnungen kommen von Norton, Bitdefender oder wem auch immer, mit Logo, Summe, Datum und Vertragsnummer. Diese Mail behauptet drei fehlgeschlagene Abbuchungen und kann keine einzige beziffern.

Es gibt keine Anrede. Der Anbieter, bei dem ihr seit Jahren ein Abo habt, kennt euren Namen.

Und die Drohung ist zu laut. „Your device is currently exposed to hackers, scammers, data theft" - kein Abrechnungssystem der Welt formuliert so. Panik ist ein Verkaufsargument, kein Buchhaltungsstil.

Was hier ausdrücklich nicht geholfen hätte: auf die URL zu schauen. Die ist echt. Das Zertifikat ist echt. Der Server gehört Google. Bei Links in Cloud-Speicher ist die Adressleiste kein Prüfmittel mehr.

Was ihr tun könnt

Den eigenen SPF-Record auf -all prüfen. Diese Kampagne liefert den Beweis frei Haus: Die Domain mit +all schenkte dem Angreifer ein spf=pass, die mit -all brachte ihm ein fail und den doppelten Spam-Score ein. Wer +all, ?all oder gar keinen Record hat, unterschreibt Fremden einen Blankoscheck auf den eigenen Namen. Das schützt nicht euer Postfach, sondern alle anderen vor Mails in eurem Namen. Ein DNS-Eintrag, Wirkung sofort - Mail-Check hier auf der Seite zeigt euch in zehn Sekunden, wo ihr steht.

DMARC von p=none hochziehen. Der Verband hier hat SPF richtig gesetzt und bleibt trotzdem bei „bitte melden, aber nichts unternehmen" stehen. Erst p=quarantine und später p=reject sorgen dafür, dass gefälschte Mails abgewiesen statt nur registriert werden. Zwei bis vier Wochen Reports lesen, dann schrittweise anziehen.

Limit und Push-Benachrichtigung auf die Firmenkreditkarte. Das verhindert den Angriff nicht, begrenzt aber genau den Schaden, auf den er zielt: stille Dauerbelastung. Die erste unbekannte Buchung fällt sofort auf statt beim Jahresabschluss.

Eine Liste, wer welches Abo hat. Dienst, Vertragsinhaber, Zahlungsweg, Verlängerungsdatum. Diese Mail funktioniert nur, solange jemand unsicher ist, ob er so ein Abo überhaupt besitzt. Eine Tabelle beantwortet das in zehn Sekunden - das macht den Köder wirkungslos, statt ihn nur zu erkennen.

Rechnungen über das eigene Lesezeichen öffnen, nie über den Mail-Link. Das ist die einzige Regel, die auch dann noch trägt, wenn die URL echt aussieht. Und hier sieht sie nicht nur echt aus, sie ist es.

Fazit

Technisch ist die Kampagne ordentlich gebaut: geliehene Reputation auf drei Ebenen, rotierende Wegwerf-Buckets, ein Bot-Gate gegen Scanner, 0 von 90 bei VirusTotal. Die Mail selbst ist dagegen erstaunlich lieblos - kein Markenname, kein Betrag, keine Anrede, und ein Bucket, der wörtlich „test" heißt. Wer sich die Mühe macht, Scanner auszutricksen, könnte auch eine Zahl in die Rechnung schreiben.

Der Grund, warum diese Welle trotzdem hier steht, ist ein anderer. Zwei Mails, fünf Tage auseinander, gleicher Angreifer, gleiche Technik - und der einzige nennenswerte Unterschied im Ergebnis kam aus dem DNS-Eintrag eines Dritten, der mit dem Angriff nichts zu tun hatte. Plus statt Minus vor dem all. Sonst nichts.

---

Die Domain der gespooften Absenderorganisation ist redigiert (<familienverband-es>[.]org). Der Verband ist hier selbst Opfer - seine Domain wurde ohne sein Zutun als Absender missbraucht, obwohl der SPF-Record korrekt gesetzt war. Pranger-Wirkung vermeiden. Die vollständigen IOCs liegen intern.