30. August 2026
Der Absender war meine eigene Domain, der Link ging über ein Gesundheitsportal in Brasilien
Tobias Wilke
@wilketob
Am 12. August lag eine Mail im Postfach payment@, die eine Adobe-Dokumentenfreigabe sein wollte. Absender: adobepdf-payment@ - auf meiner eigenen Domain. Betreff: "Payment Statement Review", gefolgt von meiner eigenen Adresse.
Das Interessante an dieser Mail ist nicht der Trick. Es ist die Einkaufsliste. Der Angreifer besitzt in dieser Kampagne genau eine Sache selbst, und die hat zehn Euro gekostet. Alles andere - Absenderidentität, Layout, Logo, die Reputation des Links - hat er sich von anderen geborgt. (IOCs sind defangt, damit hier niemand aus Versehen klickt.)
Geliehen: die Absenderidentität
From, Return-Path, die Domain in der Message-ID und To liegen alle auf derselben Domain. Meiner. Das ist der klassische Selbstspoof, und er zielt nicht auf Technik, sondern auf die Faustregel im Kopf: Unbekannter Absender heißt Vorsicht, die eigene Firma nicht.
Technisch war die Mail dabei nicht besonders geschickt. SPF sagt softfail, ein DKIM-Header fehlt komplett, und eingeliefert wurde sie in einem einzigen Hop von 200[.]123[.]9[.]174 - einem Anschluss bei GTD Perú in Lima, der sich mit seiner eigenen IP als HELO-Namen vorstellte. Nichts davon sieht nach einem legitimen Mailserver aus.
Es hat trotzdem gereicht, und zwar wegen einer Zeile im DNS meiner eigenen Domain:
v=DMARC1; p=none; rua=mailto:dmarc@...
p=none heißt wörtlich: Prüft die Ausrichtung, meldet mir das Ergebnis, aber unternehmt nichts. Genau daran hat sich der empfangende Server gehalten. p=none ist die Beobachtungsstufe für die Einführungsphase, in der man seine Reports liest und den eigenen legitimen Versand einsammelt. Als Dauerzustand ist es eine offene Tür - und sie war bei mir offen. Das ist der Teil dieser Analyse, der auf meiner Seite eine Aufgabe hinterlassen hat.
Geliehen: das Layout
Die Mail sieht nicht nachgebaut aus, weil sie nicht nachgebaut ist. Der HTML-Quelltext ist der DOM einer echten Microsoft-365-Freigabemail, herauskopiert aus einem Browser. Man sieht es an Attributen, die nur Outlook Web erzeugt: data-ogsc und data-ogsb für die Dark-Mode-Umfärbung, data-linkindex, data-imagetype="AttachmentByCid", der Anker x_customMessage mit dem x_-Präfix, das Outlook beim Rendern setzt, dazu generierte CSS-Klassen wie Do8Zj.
Am schönsten ist aber das hier. Jeder Button trägt ein title-Attribut:
title="Original URL: https://tresrios.<gesundheitsportal-br>.com.br/c/blogs/
find_entry?p_l_%20id=0&noSuchEntryRedirect=...
Click or tap if you trust this link."
Dieses Tooltip setzt Microsoft Defender for Office 365, wenn Safe Links einen Link umschreibt. Der Tooltip ist noch da - der href daneben zeigt aber wieder auf das unumgeschriebene Original. Diese Mail hat also irgendwann in einem Defender-geschützten Postfach gelegen, wurde dort gerendert, kopiert und mit zurückgesetztem Link erneut verschickt. Vermutlich ein Testpostfach des Absenders. Der Angreifer trägt eine Schutzfunktion in seiner eigenen Mail spazieren, ohne es zu merken.
Und dann ist da noch der Dateiname. Sichtbar steht auf der Kachel "payment-LR Payment Scan9032842743563854 - 2026 Statement Review 2026". Das aria-label desselben Elements sagt etwas anderes:
aria-label="7.17.26 Customers Stock Products Report AKA Grower Outlet"
Ein Dokumentname aus einer fremden Mail, datiert auf den 17. Juli. Der sichtbare Text wird pro Empfänger ersetzt, das aria-label nicht. Wer die Mail mit einem Screenreader liest, bekommt den Namen des vorigen Opfers vorgelesen.
Geliehen: das Logo
Das Adobe-Logo oben und das Datei-Icon in der Kachel sind dasselbe Bild, und es liegt bei encrypted-tbn0.gstatic.com. Das ist der Thumbnail-Cache der Google-Bildersuche. Der Angreifer hostet kein einziges eigenes Asset, sondern verlinkt ein Vorschaubild aus Google.
Das hat für ihn zwei Vorteile: Es gibt keinen zweiten verdächtigen Host im Body, an dem eine URL-Blockliste greifen könnte, und der Abruf verrät ihm, dass die Mail gelesen wurde. Es hat aber auch einen Nachteil, und den sieht man im Screenshot oben: Mein Client hat Fernbilder blockiert, und übrig blieben drei graue Platzhalter. Von der Adobe-Fassade bleibt dann nicht viel.
Geliehen: die Reputation des Links
Alle drei Klickflächen - "Open", "Share" und die Dateikachel - zeigen auf dieselbe URL:
hxxps://tresrios[.]<gesundheitsportal-br>[.]com[.]br/c/blogs/find_entry
?p_l_%20id=0
&noSuchEntryRedirect=hxxps://_wildcard_[.]vzrtezo[.]vu/adobe
Der Host gehört einer brasilianischen Gesundheitsgenossenschaft. Die Domain ist Jahre alt, hat echte Inhalte, hängt an Proofpoint-MX-Servern und wird von Reputationsdiensten als "health and medicines" geführt. VirusTotal: null von 91 als bösartig. Wer den Link vor dem Klick prüft, sieht ein Krankenkassenportal.
Der Pfad verrät, was da läuft. /c/blogs/find_entry mit den Parametern p_l_id und noSuchEntryRedirect ist Liferay. Die Funktion schlägt einen Blogeintrag nach, und wenn sie keinen findet, leitet sie dorthin weiter, was in noSuchEntryRedirect steht. Ohne Whitelist ist das ein Open Redirect.
Und jetzt der Teil, den ich beim ersten Lesen für einen Tippfehler gehalten habe: Der Parameter heißt nicht p_l_id, sondern p_l_%20id. Ein URL-kodiertes Leerzeichen mitten im Parameternamen. Damit kennt Liferay den Parameter nicht, die Suche schlägt garantiert fehl, und der Redirect-Zweig greift in jedem Fall. Das Leerzeichen ist kein Fehler, es ist der Auslöser.
Das Ziel dahinter ist _wildcard_[.]vzrtezo[.]vu. Auch das sah für mich zuerst nach einem vergessenen Platzhalter aus. War es nicht: VirusTotal hat als Final-URL genau https://_wildcard_.vzrtezo.vu/adobe erreicht. Der Betreiber hatte einen Wildcard-DNS-Eintrag gesetzt, unter dem jede beliebige Subdomain auflöst. Er kann damit pro Welle oder pro Empfänger einen neuen Hostnamen benutzen, ohne DNS anzufassen, und Blocklisten, die auf exakten Hostnamen arbeiten, laufen ins Leere.
Die Domain selbst ist das einzige Eigentum in dieser Kampagne. Registriert am 21. Juli 2026 bei Dynadot, hinter Privacy-Shield, auf einer Südsee-TLD. Zum Zeitpunkt des Versands war sie 22 Tage alt.
Ein Detail zur Zielseite, das ich nicht auflösen kann: VirusTotal hat der Landing am Versandtag den Seitentitel "Wikipedia" entlockt. Eine Phishing-Seite, die sich gegenüber einem Scanner als Wikipedia ausgibt, spricht für Cloaking - echte Opfer bekommen etwas anderes zu sehen als Analysewerkzeuge. Was ein normaler Browser bekommen hätte, weiß ich nicht: Die URL habe ich nicht aufgerufen, und inzwischen ist sie tot. Dynadot hat die Domain am 28. August auf clientHold gesetzt, sie löst heute nicht mehr auf.
Sechzehn Tage nach dem Versand. Für eine Kampagne, deren Klicks in den ersten Stunden passieren, ist dieser Takedown folgenlos. Dasselbe gilt für die Erkennungsraten: Die Redirect-URL stand am Versandtag bei 2 von 92, die .vu-Domain steht heute bei 9 von 91. Richtig, aber zu spät. Gegen Wegwerfdomains verliert reaktive Verteidigung strukturell.
Warum sie überhaupt ankam
Der Spamfilter hat die Mail durchgewinkt, und der Grund steht im Header:
X-Spam-Status: No, score=4.1 required=7.0
tests=BAYES_80, FROMSPACE, HTML_MESSAGE, MIME_HTML_ONLY,
RCVD_IN_MSPIKE_BL, RCVD_IN_MSPIKE_L5,
RCVD_IN_ZEN_BLOCKED, SPF_HELO_NONE, SPF_SOFTFAIL,
TO_EQ_FM_DOM_HTML_ONLY, T_REMOTE_IMAGE,
URIBL_DBL_BLOCKED, URIBL_ZEN_BLOCKED
4,1 von 7,0. Entscheidend sind die drei Regeln, die auf _BLOCKED enden. Die heißen nicht "nicht gelistet". Sie heißen: Spamhaus hat die Anfrage überhaupt nicht beantwortet. Das passiert, wenn der fragende Resolver gegen die Nutzungsbedingungen verstößt - typischerweise, weil er ein öffentlicher Resolver ist oder das Freikontingent überschreitet. Spamhaus antwortet dann mit dem Sentinel 127.255.255.254.
Damit sind drei Prüfungen ausgefallen: die für die Versand-IP und zwei für die Domains im Body. Alle drei haben null Punkte beigesteuert. Übrig blieb Heuristik - Bayes, SPF-Softfail, HTML-only, Fernbild, die Leerzeichen im Display-Namen " Invoicing Via Adobe ". Das ergab 4,1 und damit nicht genug.
Das lässt sich in zwei Zeilen selbst prüfen. Spamhaus hat dafür feste Testadressen:
dig +short 2.0.0.127.zen.spamhaus.org A # erwartet: 127.0.0.x (Testtreffer)
dig +short 1.0.0.127.zen.spamhaus.org A # erwartet: leer
Kommt stattdessen bei beiden 127.255.255.254, laufen die Abfragen ins Leere. Genau das bekomme ich hier über den Standard-Resolver auch:
$ dig +short 2.0.0.127.zen.spamhaus.org A
127.255.255.254
Wer seinen eigenen Mailserver betreibt, sollte das einmal prüfen. Es ist ein stiller Ausfall: Nichts bricht, nichts loggt einen Fehler, die stärkste Filterstufe ist einfach weg. Abhilfe ist ein eigener rekursiver Resolver oder ein Spamhaus-DQS-Key.
Eine Blockliste hat übrigens funktioniert. Mailspike hat die peruanische Versand-IP als schlecht eingestuft (RCVD_IN_MSPIKE_BL). Auf VirusTotal steht dieselbe IP bei 0 von 91. Reputationsquellen sind sich seltener einig, als man denkt.
Was ihr tun könnt
DMARC von p=none hochziehen. Das ist die Maßnahme, die diese Mailklasse komplett wegnimmt, und sie kostet einen DNS-Record. Vorher die rua-Reports auswerten und sicherstellen, dass aller legitime Versand - Newsletter-Tools, Ticketsysteme, das Kopiergerät - über SPF oder DKIM ausgerichtet ist. Dann auf p=quarantine, später auf p=reject.
Externe Mails mit der eigenen Absenderdomain blocken. Legitime interne Post läuft über den eigenen Mailserver. Eine Mail mit From: @eigene-domain, die von einer fremden IP eingeliefert wird und weder SPF noch DKIM erfüllt, hat keinen gültigen Anwendungsfall. In den meisten Gateways ist das eine Regel, und sie greift auch dann, wenn DMARC-Enforcement noch nicht steht.
Die Blocklisten-Abfragen des eigenen Servers prüfen. Siehe oben, zwei dig-Zeilen. Ich habe das jahrelang nicht kontrolliert und würde ohne diese Mail immer noch nicht wissen, dass die Prüfungen ins Leere gehen.
Links bis zum Ende lesen. Der sichtbare Host sagt hier gar nichts, das echte Ziel steht als Parameter dahinter. Alles nach redirect=, url=, next=, continue= oder noSuchEntryRedirect= ist der eigentliche Zielort. Für Gateways lohnt eine Regel, die Links markiert, in deren Query-String ein zweites https:// steckt.
Und wer selbst ein Portal betreibt: Weiterleitungsziele auf eine Whitelist. Die brasilianische Genossenschaft hat in dieser Geschichte nichts falsch gemacht außer einer Funktion, die beliebige Ziele akzeptiert. Jede solche Funktion wird irgendwann für so etwas benutzt. Erlaubt sein sollten nur relative Pfade oder eine Liste eigener Hosts.
Fazit
Diese Kampagne ist kein technisches Kunststück. Sie ist eine Übung im Schnorren: fremdes Layout, fremdes Logo, fremde Domain-Reputation, fremder Versandhost, und als Absender die Identität des Opfers selbst. Der einzige Eigenanteil ist eine Wegwerfdomain für ein paar Euro, die nach 38 Tagen abgeschaltet wurde.
Genau deshalb ist sie schwer zu blocken. Es gibt keinen Anhang, kein Skript, keine eigene Grafik, keinen zweiten bösartigen Host - fast nichts, woran eine Signatur greifen könnte. Was hilft, sind die zwei unspektakulären Dinge, die man auf der eigenen Seite in Ordnung bringen kann: ein DMARC-Record, der nicht p=none sagt, und Blocklisten-Abfragen, die tatsächlich beantwortet werden.
Die Domain des missbrauchten Redirect-Portals ist redigiert (<gesundheitsportal-br>[.]com[.]br). Die Genossenschaft ist hier selbst betroffen: Ihr Portal wurde nicht kompromittiert, sondern eine ungefilterte Weiterleitungsfunktion als Sprungbrett benutzt - das soll kein Pranger werden. Die Empfängerdomain ist ebenfalls redigiert und im Screenshot unkenntlich gemacht. Die Infrastruktur des Angreifers ist bewusst nicht redigiert. Die vollständigen IOCs liegen intern.