DNS-based ClickFix mit nslookup ist eine neu beobachtete ClickFix-Variante, bei der Angreifer Nutzer über Social Engineering dazu bringen, eine Ausführung über den Windows Run-Dialog anzustoßen, während die nächste Stufe über DNS bereitgestellt wird. Das erhöht die Chance, dass klassische Web-Schutzmechanismen umgangen werden, obwohl die Kette weiterhin stark von Nutzerinteraktion abhängt.

DNS-based ClickFix mit nslookup missbraucht Windows Run-Dialog und DNS-Lookups für Malware-Staging

In aktuellen Berichten wird eine ClickFix-Ausprägung beschrieben, die das bekannte Muster „Nutzer führt einen vermeintlichen Fix aus“ beibehält, den technischen Transport aber verändert. Während ClickFix-Kampagnen häufig auf Web-Downloads als nächsten Schritt setzen, rückt bei DNS-based ClickFix mit nslookup DNS als Staging-Kanal in den Vordergrund. The Hacker News fasst diese Entwicklung als DNS-basierte ClickFix-Technik zusammen, bei der ein DNS-Lookup die Grundlage für die nächste Ausführungsstufe liefert.

Warum ClickFix als Social Engineering so wirksam bleibt

ClickFix ist in erster Linie ein psychologischer Angriffsansatz. Die technische Ausführung wird nicht erzwungen, sondern durch eine glaubwürdig inszenierte Situation ausgelöst. Opfer sehen beispielsweise eine angebliche Verifikation, eine Fehlermeldung oder eine vermeintliche Reparaturanleitung und werden dann aufgefordert, einen Schritt selbst auszuführen. Diese Logik, bei der Nutzerinteraktion den entscheidenden Trigger liefert, erläutert Microsoft im Security Blog zur ClickFix-Technik. Zentral ist dabei, dass die Handlung aus Sicht vieler Sicherheitskontrollen zunächst „legitim“ wirkt, weil sie bewusst durch den Anwender erfolgt und nicht durch einen klassischen Drive-by-Exploit.

Technischer Kern der neuen Variante

Das Neue an DNS-based ClickFix mit nslookup ist die Kombination aus Run-Dialog und DNS-gestütztem Staging. In einem Update beschreibt Microsoft Threat Intelligence, dass Angreifer Opfer dazu bringen, eine Ausführung anzustoßen, die einen DNS-Lookup gegen einen fest kodierten externen DNS-Server durchführt. Anschließend wird die Ausgabe so verarbeitet, dass ein bestimmtes Feld aus der DNS-Antwort extrahiert und als nächste Stufe verwendet wird. Microsoft ordnet DNS dabei als leichtgewichtigen Staging- beziehungsweise Signalisierungskanal ein, der im Vergleich zu klassischen Web-Abrufen weniger abhängig von HTTP/S-Infrastruktur ist und sich in vielen Umgebungen leichter in „normalen“ Traffic einbetten kann.

Für Security-Teams ist an dieser Stelle besonders relevant, dass die beobachtete Variante ausdrücklich nicht zwingend den Standardresolver des Endpoints nutzt. Das schafft ein klares Abgrenzungsmerkmal für Netzwerk- und Endpoint-Detection, weil direkte DNS-Verbindungen zu externen Resolvern in gut gehärteten Enterprise-Umgebungen ohnehin untypisch sind.

Beobachtete Infektionskette bis hin zu ModeloRAT

Laut Microsoft endet die Kette nicht beim DNS-Staging. In der beschriebenen Kampagne folgt nach der zweiten Stufe ein weiterer Download- und Ausführungspfad, der unter anderem eine portable Python-Umgebung und zusätzliche Skripte einschließt. Microsoft nennt als Elemente dieser Kette Reconnaissance- und Discovery-Aktivitäten sowie Persistenzmechanismen im Benutzerkontext. Als finaler Payload wird ein Remote-Access-Trojaner namens ModeloRAT erwähnt. Damit wird deutlich, dass DNS-based ClickFix mit nslookup weniger eine neue Malware-Familie darstellt, sondern eine Liefer- und Staging-Mechanik, die vorhandene Payloads zuverlässiger zum Ziel bringt.

Für die Defensive ist zudem relevant, dass Microsoft in diesem Kontext eine Blockierung durch Microsoft Defender über ein ClickFix-spezifisches ML-Modell angibt. Zusätzlich werden in der Beschreibung beispielhafte Persistenzartefakte genannt, die im Userprofil und im Startup-Kontext auftreten können. Solche Artefakte sind besonders wertvoll, weil sie unabhängig von der konkreten Payload Hinweise auf die Taktik liefern.

Warum DNS-based ClickFix mit nslookup in Unternehmen schwerer auffällt

Viele Organisationen haben HTTP/S in den letzten Jahren stark zentralisiert und abgesichert, etwa über Proxy-Architekturen, URL-Filtering, TLS-Inspection oder Security-Service-Edge-Kontrollen. DNS hingegen bleibt in der Praxis häufig ein Bereich mit weniger strikter Governance, weniger Telemetrie oder geringerer Korrelation mit Endpoint-Ereignissen. Genau diese Asymmetrie kann DNS-based ClickFix mit nslookup ausnutzen, weil das Staging nicht mehr zwingend über Web-Requests erfolgt. BleepingComputer beschreibt die beobachtete Ausprägung als besonders tückisch, weil DNS-Antworten als Träger für die nächste Stufe dienen können und sich Inhalte dadurch flexibel austauschen lassen, ohne dass klassische Web-Indikatoren im Vordergrund stehen.

Wichtig ist dabei eine nüchterne Einordnung. DNS-basierte Techniken sind nicht per se unsichtbar, sie verschieben die Detektionsaufgabe jedoch in eine Telemetrieebene, die in vielen SOC-Workflows nicht dieselbe Priorität wie Web- oder EDR-Signale hat. Dadurch steigt das Risiko, dass eine Kampagne zunächst nur als „komische DNS-Anomalie“ erscheint, obwohl sie in Wahrheit bereits eine Ausführungskette auslöst.

Praktische Detection-Ansätze für SOC und Threat Hunting

Eine belastbare Detektion für DNS-based ClickFix mit nslookup entsteht durch Korrelation. Ein einzelner DNS-Lookup ist selten aussagekräftig, die Kombination mehrerer Signale hingegen schon. Besonders nützlich sind Prozessketten, die auf einen interaktiven Kontext hindeuten, etwa wenn Shell- und DNS-Utilities in engem zeitlichen Zusammenhang mit Nutzerhandlungen auftreten. Ein starkes Signal kann auch sein, wenn DNS nicht über die autorisierten Resolver läuft, sondern direkt zu einem externen Server abgesetzt wird.

Auf Endpoint-Seite lohnt sich die Kombination aus Commandline-Telemetrie und Dateisystem-Events. Auffällig sind neue, kurz zuvor geschaffene Persistenzartefakte im Benutzerprofil oder Startup-Kontext, wenn sie zeitnah auf verdächtige DNS-Aktivität folgen. Ergänzend bleibt das ClickFix-Grundmuster ein wichtiger Indikator, weil viele Kampagnen über Copy-Paste in Run-Dialog oder Terminal laufen. Die im Microsoft-Beitrag beschriebene ClickFix-Mechanik eignet sich deshalb weiterhin als Grundlage für Awareness, Use-Case-Design und Detection Engineering.

Hardening, das diese Variante direkt adressiert

Die wirksamste technische Gegenmaßnahme ist eine konsequente DNS-Egress-Policy. Wenn Endpoints ausschließlich autorisierte Resolver nutzen dürfen und direkte DNS-Verbindungen ins Internet blockiert werden, reduziert das die Angriffsfläche für DNS-based ClickFix mit nslookup erheblich oder macht Versuche zumindest sehr sichtbar. Zusätzlich sollte DNS-Telemetrie so erfasst werden, dass Abweichungen von Resolver-Standards, ungewöhnliche Query-Muster und zeitnahe Ausführungsereignisse korrelierbar sind.

Da ClickFix weiterhin von Nutzerinteraktion abhängt, bleibt Awareness ein zentraler Baustein. Schulungen sind besonders effektiv, wenn sie konkrete Handlungsmuster adressieren, beispielsweise dass seriöse Anbieter typischerweise keine „Fix“-Anleitungen liefern, die das Einfügen fremder Befehle in den Run-Dialog verlangen.

Fazit

DNS-based ClickFix mit nslookup zeigt, wie schnell sich etablierte Social-Engineering-Techniken an technische Kontrolllandschaften anpassen. Die Variante kombiniert ein vertrautes ClickFix-Narrativ mit DNS-Staging und verschiebt dadurch die Sichtbarkeit weg von klassischen Web-Indikatoren hin zu DNS- und Prozesskorrelation. Wer DNS-Egress kontrolliert, Endpoint-Telemetrie sauber korreliert und ClickFix-typische Nutzerhandlungen in Awareness und Detection verankert, reduziert das Risiko dieser Kampagnen deutlich, auch wenn sich Payloads und Infrastruktur weiter verändern.