21. September 2026
openai.ai: Phishing von einer Domain, die es im DNS gar nicht gibt
Tobias Wilke
@wilketob
Kurz gesagt: Eine Mail im Stripe-Layout meldet, die Abbuchung von 20 Dollar fürs
OpenAI-Abo sei gescheitert. Text, Betrag und Firmierung stimmen alle, zwei von drei Links
gehen zu echten Marken-Adressen. Der Absender lautet auf die richtige Marke mit der falschen
Endung - und diese Domain hält seit 2017 jemand in Shenzhen, ohne sie je ins DNS zu stellen.
Damit liefert die Prüfung spf=none statt spf=fail, es gibt keinen DKIM-Selektor und keine
DMARC-Policy, gegen die sich etwas durchsetzen ließe. VirusTotal sagt zur Absenderdomain
0 von 89 - 55 Engines ausdrücklich harmless.
Die meisten Phishing-Mails verraten sich am Absender. Diese hier kommt von billing[@]openai[.]ai, und genau das ist das Problem: Für ein KI-Unternehmen sieht .ai nicht falsch aus, sondern passender als .com. Der Domain-Check, den wir alle empfehlen, liefert hier ein Ergebnis, das den Angreifer bestätigt.
Die Mail lag in einem meiner Analyse-Postfächer. URLs und bösartige Domains sind im Folgenden defangt, damit nichts aus Versehen angeklickt wird.
Was in der Mail steht
Betreff: „Zahlung über $20.00 an OpenAI Ireland Limited fehlgeschlagen". Der Text ist drei Sätze lang:
Wir haben erneut versucht, Ihre Karte für Ihr OpenAI-Abonnement zu belasten, dies war jedoch nicht erfolgreich. Bitte aktualisieren Sie Ihre Zahlungsinformationen, um Ihr Abonnement fortzusetzen. Rechnung #OAI8K4M7-0012.
Darunter ein violetter Button, „Zahlungsmethode aktualisieren". In der Fußzeile steht „Powered by stripe".
Und jetzt der unangenehme Teil: Fast alles daran stimmt. OpenAI Ireland Limited ist wirklich die Gesellschaft, über die OpenAI in der EU abrechnet. 20 Dollar ist wirklich der Preis von ChatGPT Plus. OpenAI rechnet wirklich über Stripe ab. Die Farbwerte - #635BFF für den Button, #32325D für die Überschrift - stammen wirklich aus Stripes Billing-Templates. Die Kontaktzeile verlinkt auf billing@openai.com, die Fußzeile auf stripe.com, und beide gehen tatsächlich dorthin.
Zwei von drei Links in dieser Mail sind echt. Nur der eine, auf den es ankommt, führt nach hxxp://yourhealthrobot[.]com/.
Kein Rechtschreibfehler, keine krude Anrede, kein Countdown, keine Sperrandrohung. Diese Mail droht nicht, sie informiert. Das funktioniert deutlich besser als das übliche Geschrei.
Die Absenderdomain existiert nicht
Hier wird es interessant. openai[.]ai ist kein Tippfehler-Squat. Kein vertauschter Buchstabe, kein kyrillisches „a", keine Subdomain-Trickserei. Der Name ist exakt richtig. Getauscht ist nur die Endung.
Und dann das:
$ dig openai.ai NS
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN
NXDOMAIN. Die Domain existiert im DNS überhaupt nicht. Kein Nameserver, kein A-Record, kein MX, kein TXT. Das WHOIS erklärt warum: Die Domain ist seit dem 16. Dezember 2017 registriert, auf einen Halter in Shenzhen, mit +111.1111111111 als Telefonnummer und einer QQ-Adresse als Kontakt. Der Registry-Status lautet inactive - das ist der offizielle Code für „keine Nameserver hinterlegt". Jemand hält die Domain seit acht Jahren, hat sie bis 2029 bezahlt und nie in Betrieb genommen.
Daraus folgt die gesamte Authentifizierungslage. Der empfangende Mailserver hat sie selbst protokolliert:
X-Received-SPF: none ( domain of openai.ai does not provide an SPF record )
none, nicht fail. Das ist der Kern der Sache. Ein SPF-Hardfail ist ein Befund - Filter können ihn gewichten, DMARC kann ihn durchsetzen. none heißt nur „keine Aussage" und ist der Normalzustand von Millionen harmloser Kleinstabsender. DKIM? Keine Signatur, und ohne Zone wäre auch kein Selektor auflösbar. DMARC? _dmarc.openai.ai ist ebenfalls NXDOMAIN: keine Policy, nichts durchzusetzen, kein Report an irgendwen.
Diese Mail ist nicht schlecht authentifiziert. Sie ist gar nicht authentifizierbar.
Zum Vergleich die echte Domain:
$ dig +short _dmarc.openai.com TXT
"v=DMARC1; p=reject; rua=mailto:...@ag.dmarcian.com; fo=1; aspf=r"
openai.com steht sauber auf p=reject. Der Angreifer hat die geschützte Domain gemieden und sich die ungeschützte Nachbarendung genommen. Das ist keine Nachlässigkeit, das ist Auswahl.
Der Witz an einer undelegierten Domain: Sie lässt sich nicht reparieren. Bei einer gekaperten Domain räumt der Eigentümer irgendwann auf. Bei einer Domain mit kaputtem SPF kann der Halter den Record korrigieren. Hier gibt es niemanden, der etwas tun wird - der Halter betreibt keine Mail, braucht kein SPF und erfährt mangels DMARC-Report nicht einmal, dass unter seinem Namen gespooft wird.
55 Engines sagen: harmlos
Ich habe die Absenderdomain bei VirusTotal nachgeschlagen, mehr aus Gewohnheit als aus Erwartung. Das Ergebnis: 0 von 89. Null bösartig, null verdächtig, 55 Engines stufen openai[.]ai ausdrücklich als harmless ein.
Das ist kein Versagen der Scanner. Reputationssysteme bewerten Inhalt und Verhalten - eine Domain ohne Zone, ohne Host, ohne Website hat beides nicht und ist für sie definitionsgemäß unbedenklich. Wer Absenderdomains gegen Threat-Intel prüft, bekommt hier grünes Licht.
Die Landing-Domain sieht kaum schlechter aus: yourhealthrobot[.]com kommt auf 6 von 91, drei davon mit der Einstufung „phishing". Registriert im Februar 2025, zum Versandzeitpunkt also rund 16 Monate alt. Auch „frisch registrierte Domain" greift als Warnsignal nicht.
Alles auf deutschen Hostern
Versendet wurde aus 87[.]106[.]173[.]222 - AS8560, IONOS, Berlin. Die Landing liegt auf 81[.]169[.]145[.]94 - AS6724, Strato, Frankfurt, die Domain registriert bei Cronon, dem Registrar-Arm von Strato.
Kein Bulletproof-Hoster, kein Cloudflare, kein Osteuropa-VPS. Auf Netzebene sieht diese Kampagne aus wie deutscher Mittelstand, und das ist der Punkt: Geo- und Reputationsheuristiken laufen ins Leere. Spamhaus kennt die Versand-IP bis heute nicht, nur Barracuda führt sie - zehn Wochen nach dem Versand.
Ein Detail bleibt prüfbar: Die Rückwärtsauflösung der Versand-IP nennt den Hostnamen eines deutschen Handwerksbetriebs, dessen Domain aber auf eine ganz andere IP bei einem anderen Anbieter zeigt. Forward-Confirmed Reverse DNS schlägt fehl. Vermutlich ist der Betrieb vor Jahren umgezogen und die alte Rückwärtsauflösung auf der recycelten IP nie zurückgesetzt worden. Mit der Sache hat er aller Wahrscheinlichkeit nach nichts zu tun.
Der vergessene Zettel im Quelltext
Wer sich den HTML-Quelltext ansieht, findet in Zeile zwölf das hier:
<!-- Template 2: legacy font tags -->
Der Angreifer hat seinen eigenen Versionsvermerk im Live-Versand stehen lassen. Es gibt also nummerierte Varianten, mindestens eine „Template 1". Und „legacy font tags" beschreibt exakt, was das Markup tut: Es formatiert durchgehend über <font face size color> statt über CSS - Tags, die seit 1999 abgekündigt sind.
Das ist kein Dilettantismus, sondern eine bewusste Variante. <font>-Markup rendert in jedem noch so alten Client und umgeht Filterregeln, die auf CSS-Eigenschaften anspringen. Da testet jemand Zustellraten gegeneinander und hat vergessen, den Zettel abzumachen.
Passend dazu: Die Mail lädt nichts nach. Kein Logo, keine Grafik, kein Tracking-Pixel - der „OpenAI"-Schriftzug im Kopf ist schlichter Text. Der übliche Schutz „externe Inhalte blockieren" bringt hier also nichts. Der Angreifer verzichtet im Gegenzug auf jede Öffnungsmessung.
Was passiert wäre
Der Button führt per unverschlüsseltem http:// auf die Strato-Domain, ohne Pfad, ohne Parameter, ohne Empfänger-Token. Dort hätte ein Kartenformular im OpenAI-Look gestanden: Name, Kartennummer, Ablaufdatum, CVC.
Ehrlichkeitshalber: Ich habe das Formular nicht gesehen. Die Seite war schon Ende August tot, VirusTotal hat als Seitentitel nur noch 503 Service Unavailable erfasst. Dass es um Kartendaten ging, leite ich aus dem Köder ab, nicht aus einer beobachteten Seite.
Kartendaten mit CVC sind sofort verwertbar: erst ein Kleinstbetrag zum Test, dann größere Abbuchungen oder der Weiterverkauf im Bündel. Für Betriebe ist das besonders unangenehm, weil solche Abos typischerweise auf einer Firmenkreditkarte laufen, um die sich niemand täglich kümmert. Das fällt oft erst bei der Monatsabrechnung auf.
Was hier nicht geholfen hätte
Die Standardratschläge der Reihe nach, weil sie diesmal fast alle durchfallen. „Auf Rechtschreibfehler achten" - es gibt keine. „Auf frisch registrierte Domains achten" - Absender von 2017, Landing von 2025. „Externe Inhalte blockieren" - die Mail lädt nichts nach. „Absenderdomain gegen Threat-Intel prüfen" - 0 von 89, ausdrücklich harmlos. „DMARC schützt vor Markenmissbrauch" - openai.com steht auf p=reject, und es hat exakt nichts genützt, weil DMARC die eigene Domain schützt und nicht den eigenen Namen auf einer fremden.
Auch die Zustellung sagt nichts aus. Mein Analyse-Postfach nimmt absichtlich alles an, sonst hätte ich nichts zu analysieren. Aber selbst ein streng konfiguriertes Postfach hätte aus der Authentifizierung keine Handhabe gehabt: Bei spf=none und fehlender Policy gibt es kein Fail, das man abweisen könnte.
Was tatsächlich hilft
Eine Liste eurer Abos und der zugehörigen Karten. Dienst, Zahlungsmethode, verantwortliche Person - eine Tabelle reicht. Dieser Angriff lebt davon, dass niemand sicher weiß, welche Karte für welches Abo hinterlegt ist. Wer nachschlagen kann, prüft in dreißig Sekunden statt zu klicken. Die einzige Maßnahme hier, die auch beim nächsten Köder mit einer anderen Marke funktioniert.
Zahlungsdaten nur über selbst aufgerufene Adressen ändern. Kein Link aus einer Rechnungsmail, sondern Lesezeichen oder getippte Adresse, dann im Konto nachsehen, ob die Forderung überhaupt existiert. Das bricht die Kette an der einzigen Stelle, an der sie auf eine Handlung angewiesen ist - und greift gerade dann, wenn Absender, Text und Betrag unauffällig sind.
Markenname richtig, Endung falsch - als eigenes Muster lernen. Nicht „sieht die Domain komisch aus?", sondern: Ist das die Endung, die diese Firma benutzt? OpenAI schreibt von openai.com. Wer wissen will, wie eine Domain bei SPF, DKIM und DMARC dasteht, schickt sie durch den Mail-Check hier auf der Seite.
Virtuelle Karten mit Limit für Software-Abos. Greift nach dem Fehler: Wenn die Daten doch abfließen, ist der Schaden gedeckelt, und die Sperrung trifft nicht die Karte, an der zwanzig andere Verträge hängen.
Im Gateway spf=none nicht als neutral durchwinken, wenn im Absender eine bekannte Marke steht. Das ist der Punkt, an dem die Kampagne technisch angreifbar ist. Mit Augenmaß: none ist auch der Normalzustand vieler harmloser Kleinabsender - also moderates Gewicht in Kombination mit dem Markennamen, kein Hardblock.
Fazit
Handwerklich ist das die sauberste Mail, die ich dieses Jahr auf dem Tisch hatte: fehlerfreies Deutsch, korrekte Firmierung, richtiger Betrag, originalgetreues Layout, zwei echte Links als Beleg und kein Zeitdruck. Vier von fünf Prüfungen, die man einem Nutzer beibringt, bestätigen diese Mail.
Der eigentliche Trick liegt aber nicht im Text, sondern in der Domainauswahl: eine seit acht Jahren registrierte Marken-Nachbardomain, die nie ins DNS gestellt wurde und deshalb kein einziges negatives Signal erzeugen kann. Kein Fail, keine Policy, kein Report, keine schlechte Reputation - weil da nichts ist, worüber man urteilen könnte. Der beste Tarnmantel ist derzeit offenbar, gar nicht erst zu existieren.
Der Handwerksbetrieb, dessen Hostname in der Rückwärtsauflösung der Versand-IP auftaucht, ist hier nicht genannt. Nach allem, was passiv erkennbar ist, ist er unbeteiligt: Seine Domain liegt bei einem anderen Anbieter, die Rückwärtsauflösung auf der Angreifer-IP ist schlicht veraltet. Es gäbe nichts zu berichten außer dem Namen, und dafür ist hier kein Platz. Die vollständigen IOCs liegen intern.