Cybersicherheit

Eine gängige Test-Domain in Entwicklerdokumentationen wird zur ClickFix-Falle für Windows-Nutzer

Die seit Jahren in Dokumentationen und Programmierbeispielen als Standardadresse verwendete Domain third-party.com zeigt inzwischen eine gefälschte Cloudflare-Seite, die Windows-Nutzer dazu drängt, schädliche PowerShell-Befehle auszuführen. Es gibt keine bestätigten Berichte über erfolgreiche Angriffe, doch die Verbreitung der Domain in öffentlichen Repositories und Projekten macht sie zu einer potenziellen Gefahr für wörtlich kopierten Code.

2026-09-23
4 Min. Lesezeit
91 Aufrufe
certi.news Editorial Team
Eine gängige Test-Domain in Entwicklerdokumentationen wird zur ClickFix-Falle für Windows-Nutzer

Die Domain third-party.com, die häufig in Entwicklerdokumentationen und Codebeispielen als standardmäßige externe Website erscheint, wurde zu einer Plattform für eine gefälschte Cloudflare-Seite, die die ClickFix-Methode zur Attackierung von Windows-Nutzern einsetzt. Manifold Security entdeckte die missbräuchliche Nutzung bei der Untersuchung von Dokumentationen im Zusammenhang mit KI-Fähigkeiten und MCP-Servern. Anschließend bestätigte BleepingComputer das Verhalten der Seite.

Die Seite zeigt eine Verifizierungsnachricht mit dem Titel „Performing security verification“ und enthält ein Feld „Verify you are human“. Nach dem Anklicken kopiert die Seite einen schädlichen Befehl in die Windows-Zwischenablage und fordert den Nutzer auf, Windows+R zu drücken, den Befehl anschließend mit Strg+V einzufügen und auszuführen. Der Befehl setzt eine Payload-Adresse der Domain elxxvvx[.]xyz zusammen, lädt ein PowerShell-Skript herunter und führt es aus.

Wie funktioniert der Trick?

ClickFix beruht darauf, das Opfer davon zu überzeugen, den Befehl selbst auszuführen, anstatt direkt eine schädliche Datei herunterzuladen. Laut einem früheren Analysebericht vom 2. Mai 2026 versuchte das Skript, ein 134 Megabyte großes ZIP-Archiv namens update2.zip herunterzuladen, es lokal unter dem Namen update26.zip zu speichern, anschließend zu entpacken und eine ausführbare Datei namens draw.io.exe zu starten. BleepingComputer konnte die endgültige Payload nicht ermitteln, da das Archiv nicht mehr verfügbar war.

Während des Tests löste die Domain elxxvvx[.]xyz nicht mehr zu einem aktiven Dienst auf, wodurch die Angriffskette zu diesem Zeitpunkt unterbrochen war. Die Seite unterschied jedoch zwischen den Betriebssystemen: Windows-Nutzer sahen den Angriffspfad, während Nutzer von macOS und Linux eine Nachricht erhielten, dass die Website ein Windows-Gerät erfordere. Diese selektive Zielauswahl kann das Verhalten vor Prüfungen verbergen, die Linux-Umgebungen oder Adressen von Rechenzentren verwenden.

Warum ist die Wahl dieser Domain relevant?

Die Gefahr des Vorfalls liegt darin, dass third-party.com keine für Dokumentationszwecke reservierte Domain wie example.com, example.net und example.org ist, sondern eine registrierte Domain, deren Eigentümer den Inhalt kontrollieren kann. Dennoch wurde sie von W3C-Spezifikationen, der Chromium-Dokumentation und anderen Projekten als Standardadresse verwendet. Sie erschien in mehr als 1.500 Dateien in über 1.700 Repositories, darunter Repositories mit Verbindungen zu Namen wie Chromium, Sanity und Vercel.

Wenn Beispiele mit dieser Adresse in Testcode oder eine tatsächliche Anwendung kopiert werden, könnten sich der Browser oder das automatisierte Tool mit der echten Domain verbinden, statt sie als nicht funktionsfähigen Wert zu behandeln. Dadurch könnte schädlicher Inhalt angezeigt werden. Das bedeutet nicht, dass W3C-, Chromium- oder andere Projekte kompromittiert wurden.

Was wissen wir, und was wurde nicht bestätigt?

Der Quelle zufolge ist die Domain seit 1996 registriert. Es gibt keine Belege dafür, dass sie ursprünglich zu einem schädlichen Zweck registriert wurde. Außerdem ist nicht geklärt, wann oder wie die Kontrolle über sie geändert wurde. Bis zur Erstellung des Berichts lagen keine Berichte vor, die eine tatsächliche Ausführung von ClickFix auf Entwicklergeräten oder innerhalb von Anwendungen und Websites belegen, die auf die Domain verweisen. Dass die Website weiterhin aktiv ist, bedeutet jedoch, dass Angreifer sie später mit einer neuen Payload-Domain verknüpfen könnten.

Die praktische Lehre für Entwickler und Sicherheitsteams lautet, nicht jede Testdomain allein deshalb als sicher zu betrachten, weil sie in vertrauenswürdigen Dokumentationen erscheint. Registrierbare Adressen sollten durch für Dokumentationszwecke reservierte Domains ersetzt werden. Außerdem sollten kopierte Beispiele überprüft werden, die tatsächliche Netzwerkanfragen ausführen. Nutzer sollten darüber aufgeklärt werden, dass seriöse Verifizierungsseiten normalerweise nicht dazu auffordern, das Ausführen-Fenster zu öffnen und PowerShell-Befehle manuell einzufügen.

Nachrichtenquelle
BleepingComputer
Originalquelle öffnen ↗
c
Autor

certi.news Editorial Team

Aus derselben Kategorie

Das könnte Sie interessieren

Alle Nachrichten anzeigen