2. Oktober 2026
DomainFactory-Phishing in Mathe-Schrift: Die Tarnung, die den Spamfilter erst richtig weckt
Tobias Wilke
@wilketob
DomainFactory will, dass ich meine Daten aktualisiere. In 48 Stunden ist sonst das Kundenkonto zu. Die Mail dazu enthält im entscheidenden Absatz keinen einzigen Buchstaben. Das ist kein Scherz, sondern die Tarnung - und genau die hat den Spamfilter aufgeweckt.
URLs und IPs sind im Folgenden defangt (hxxps, [.]), damit nichts aus Versehen angeklickt wird.
Was in der Mail steht
![Die Phishing-Mail im Mailclient: Absender-Anzeige „DomainFactory@ | ( NoReply ) #WVLI “ mit einer redigierten Praxis-Adresse, Betreff „Wichtige Aktualisierung | (#DE25258W9)“, darunter fett gesetzter Text mit der Aufforderung, die hinterlegten Daten zu aktualisieren, ein Link mit dem Text https://sso.df.eu/aktualisieren-sie-ihre-kontoinformationen, die Drohung mit einer Sperre nach 48 Stunden und die englische Signatur der DomainFactory GmbH. Im fetten Text fallen die dünnen Umlaute auf. Die Empfängeradressen und die Absenderdomain sind unkenntlich gemacht.
Betreff: Wichtige Aktualisierung | (#DE25258W9). Absender: "DomainFactory@ | ( NoReply ) #WVLI [" <noreplyDomainfactory[@]<praxisklinik-by>[.]de>. Ein Hoster, der über die Adresse einer Arztpraxis schreibt und seinen Namen mit einer offenen eckigen Klammer beendet. Soweit der erste Eindruck.
Der Text ist kurz:
Bitte aktualisieren Sie zeitnah Ihre hinterlegten Daten, damit Ihr Kundenkonto nicht vorübergehend deaktiviert wird. [...] Ohne Aktualisierung innerhalb von 48 Stunden muss Ihr Konto aus Sicherheitsgründen vorübergehend gesperrt werden.
Dazwischen ein Link, der aussieht wie https://sso.df.eu/aktualisieren-sie-ihre-kontoinformationen. Darunter die komplette Signatur der DomainFactory GmbH mit Anschrift, Handelsregister und Geschäftsführern. Auf Englisch, während der Rest deutsch ist. Die Signatur ist offensichtlich aus einer echten Mail kopiert, samt Umbruchfehler inde x.php.
Kein Logo, kein Bild, keine Anrede mit Namen. Nur "Hallo".
Fettdruck, der keiner ist
Der Köder-Absatz sieht fett aus. Er ist es nicht. Im Quelltext steht kein <b>, sondern das hier:
<p>𝐇𝐚𝐥𝐥𝐨</p>
Das sind fünf Zeichen aus dem Unicode-Block "Mathematical Alphanumeric Symbols": 𝐇𝐚𝐥𝐥𝐨. Gedacht für Formeln, in denen ein fettes H etwas anderes bedeutet als ein normales. Für das Auge steht da "Hallo". Für einen Filter, der nach "Kundenkonto", "gesperrt" oder df.eu sucht, steht da nichts davon. Der Textteil der Mail macht dasselbe mit der Schreibschrift-Variante des Blocks.
Obendrauf ist jedes Zeichen einzeln als Zahlencode geschrieben, sogar die normale Signatur. Der Betreff ist ebenfalls Buchstabe für Buchstabe kodiert, obwohl er nur aus ASCII besteht. Wer die Rohdaten nach Stichwörtern durchsucht, findet kein lesbares Wort.
Die Sache hat einen Haken. Für das ü gibt es kein Mathe-Zeichen. Es bleibt ein normales ü und steht dünn mitten im fetten Wort. Im Screenshot sieht man es dreimal: zweimal in "vorübergehend", einmal in "Sicherheitsgründen". Nebenbei: Ein Screenreader liest den Absatz als "mathematisches fettes großes H" vor. Barrierefrei ist Phishing also auch nicht.
Fünf Links, ein Ziel
Die Mail hat fünf Links: den Aktualisierungs-Link, www.df.eu, die Newsletter-Einstellungen, die Datenschutzerklärung und ein einzelnes verlinktes "your". Alle fünf zeigen auf dieselbe Adresse:
hxxps://ulvis[.]net/e31b2m6653#AKRL...Req
ulvis[.]net ist ein öffentlicher Kurzlink-Dienst, seit 2015 registriert, hinter Cloudflare. Der gehört nicht den Tätern, sie benutzen ihn nur. Wohin der Kurzlink weiterleitet, lässt sich ohne Aufruf nicht sagen. VirusTotal kam beim Scan nur bis zu einer Cloudflare-Warteseite ("Just a moment...") und meldet 1 von 92. Das ist ein Urteil über die Warteseite, nicht über die Phishing-Seite dahinter.
Interessant ist der Teil hinter dem #. Ein solches Fragment schickt der Browser nie an den Server. Der Kurzlink-Dienst sieht es nicht, Scanner in der Regel auch nicht. Auf der Zielseite kann JavaScript es aber auslesen. Dieselbe Zeichenkette steht in der Mail noch einmal: als Cc-Empfänger, verkleidet als T-Online-Adresse. Es ist also keine zweite Person in Kopie, sondern eine Empfänger-Kennung. Wer klickt, wird wiedererkannt.
Absender: alles geliehen, nichts bestanden
Verschickt wurde die Mail von 62[.]10[.]177[.]137. Die IP gehört Microsoft (AS8070), der Hostname lag in der Azure-Zone für US-Behördenkunden. Vorgestellt hat sich der Server als 9ypm.hotmail.com. Den Namen gibt es nicht.
Als technischer Absender dient die Domain eines Handwerksverbands, als sichtbarer die einer Praxisklinik in Bayern. Beide haben mit der Mail nichts zu tun. Beide haben ihre Hausaufgaben gemacht: Der Verband verbietet per SPF fremde Absender (-all), die Praxis hat DMARC auf p=reject. Ergebnis: SPF fail, keine DKIM-Signatur, DMARC durchgefallen. Ein Postfach, das DMARC durchsetzt, nimmt diese Mail gar nicht erst an.
Dazu kommt Kulisse: ein gefälschter LinkedIn-Header, ein gefälschter Mailchimp-Header, eine Mailingliste auf einer .edu-Domain, die nicht existiert. Und ein Fehler. Statt Message-ID: steht in der Mail der Header Message-javascript: ;ID:. Da hat die Vorlage des Mailers einen Platzhalter an der falschen Stelle ersetzt.
Das war teuer. Das Postfach, in dem die Mail landete, lässt SpamAssassin mitlaufen. Ergebnis: 12,1 Punkte bei einer Schwelle von 7. Die höchste Einzelwertung, 4,0 Punkte, gibt es für "viele Sonderzeichen im Text und keine Message-ID". Also für die Unicode-Tarnung plus den Vorlagenfehler. Weitere 3,3 Punkte bringt die Versand-IP mit, die bei Spamhaus gelistet war. Der SPF-Fail zählte in dieser Konfiguration übrigens 0,0 Punkte. Ohne Tippfehler und mit frischer IP wäre die Mail bei 4,3 gelandet und durchgegangen.
Was die eigentlich wollen
Das Kundenkonto beim Hoster. Hinter dem Link wartet aller Erfahrung nach ein Nachbau der Login-Seite, den Aufruf habe ich mir gespart. Wer dort Kundennummer und Passwort eingibt, gibt den Generalschlüssel ab: Domains samt Transfer-Code, DNS-Einträge, Postfächer, hinterlegte Zahlungsdaten.
Was dann passiert, steht in anderen Artikeln hier im Blog. Übernommene DNS-Zonen und Postfächer kleiner Firmen sind die Infrastruktur, über die die nächste Kampagne mit gültigem SPF und DKIM verschickt wird. Aus dem Opfer wird der Absender.
Gezielt ist das nicht. Die Mail ging an eine Domain, die gar nicht bei DomainFactory liegt.
Woran ihr's erkannt hättet
Die Absenderadresse gehört zu einer Arztpraxis, nicht zu df.eu. Der Absendername sieht aus wie eine Katze auf der Tastatur. Die Anrede ist "Hallo". Die Umlaute im fetten Text sind dünn. Der Footer ist englisch. Und wer mit der Maus über den Link fährt, sieht ulvis[.]net statt sso.df.eu. Das gilt auch für den Datenschutz-Link. Wenn in einer Mail alle Links dasselbe Ziel haben, ist es keine Mail vom Hoster.
Was ihr tun könnt
Zum Hoster-Login kommt ihr über ein Lesezeichen oder die getippte Adresse. Nie über einen Link in einer Mail. Der Linktext beweist nichts, hier zeigte er die echte Domain.
Schaltet im Kundenkonto die Zwei-Faktor-Anmeldung ein, wenn euer Hoster sie anbietet. Ein abgefischtes Passwort reicht dann nicht für den Domain-Transfer.
Setzt für wichtige Domains die Transfer-Sperre. Das kostet nichts und bremst, falls das Konto doch fällt.
Fragt euren Mailprovider, ob er DMARC durchsetzt. Diese Mail wäre daran gescheitert. Und bringt eure eigene Domain auf p=reject, damit sie nicht als Absender herhält. Wie SPF, DKIM und DMARC bei euch stehen, zeigt der Mail-Check hier auf der Seite.
Wer selbst einen Mailfilter betreibt: Zeichen aus dem Bereich U+1D400 bis U+1D7FF haben in Geschäftspost nichts verloren. Eine Regel darauf ist schnell gebaut und trifft wenig Falsches.
Fazit
Viel Aufwand an der falschen Stelle. Der Inhalt ist dreifach verschleiert, aber Absenderprüfung, IP-Ruf und ein simpler Header gehen komplett daneben. Am Ende hat die Tarnung dem Filter mehr geholfen als geschadet. Verlassen würde ich mich darauf nicht: Der nächste Versand hat eine Message-ID.
Die beiden gefälschten Absenderdomains sind redigiert (<praxisklinik-by>[.]de und die Domain eines Handwerksverbands). Beide Organisationen sind hier selbst Opfer: Ihre Namen wurden ohne ihr Zutun in den Absender geschrieben, ihre SPF- und DMARC-Einträge sind korrekt gesetzt. Pranger-Wirkung vermeiden. Die vollständigen IOCs liegen intern.