Detection ist keine Query, sondern eine Kette: Warum die Korrelation entlang der Prozess-Lineage ClickFix erkennt und Einzelsignale es nicht tun

Eine verbreitete Annahme, die selten geprüft wird

Im Mai 2026 dokumentierte Huntress eine Intrusion, die mit einem einzigen kopierten Befehl begann und in wenigen Stunden über elf Systeme lief (Huntress, 2026a). Der Einstieg war ClickFix: Eine präparierte Website weist den Besucher an, einen scheinbar harmlosen Befehl in die Windows-Ausführen-Box zu kopieren und zu bestätigen. Der Nutzer führt die erste Stufe damit selbst aus.

Der Fall wird hier nicht als Nachricht behandelt, sondern als Anlass, eine Annahme zu prüfen, die im Detection Engineering weithin geteilt und selten belegt wird. Sie lautet in ihrer starken Form: Die Verknüpfung mehrerer schwacher Signale auf einem Host liefert eine deutlich höhere Trefferquote als Regeln auf einzelne Living-off-the-Land-Binaries. Für diesen Beitrag habe ich sie in drei prüfbare Teilhypothesen zerlegt.

Erstens die Untauglichkeitsthese: Regeln auf ein einzelnes LOLBin sind in Produktivumgebungen wegen ihrer Fehlalarmlast praktisch unbrauchbar. Zweitens die Korrelationsthese: Die Verknüpfung mehrerer Signale hebt die Präzision substanziell. Drittens, und das ist die Stelle, an der es unbequem wird, die Zeitfensterthese: Ein enges gemeinsames Zeitfenster genügt als Bindeglied.

Das Ergebnis vorweg. Die ersten beiden Teilhypothesen halten der Prüfung stand, die erste allerdings mit einer anderen Begründung, als sie üblicherweise vorgetragen wird. Die dritte hält nicht. Und die stärkste Gegenposition kommt nicht aus der Detektion, sondern aus der Prävention.

Einordnung des Beitrags, und was er ausdrücklich nicht zeigt

Bevor die Belege kommen, gehört der Geltungsbereich offengelegt. Dieser Beitrag ist keine empirische Studie zur Verbreitung von ClickFix und keine experimentelle Evaluation der weiter unten gezeigten Abfrage. Er verbindet eine dokumentierte Intrusion als Fallstudie mit einer gezielten Auswertung der Fachliteratur und leitet daraus technische Schlussfolgerungen ab. Die Aussagen über die konkrete Kette sind deshalb fallbezogen, die Aussagen über Korrelation und Prävention werden nach der Stärke ihrer jeweiligen Quellen getrennt bewertet.

Beobachtung im Fall. pcalua.exe startet mshta.exe, das HTA lädt eine MSI, msiexec.exe installiert still, danach folgen Persistenz, Credential-Diebstahl, C2 und laterale Bewegung. Grundlage ist ein einzelner Incident-Report eines Anbieters, ergänzt um eine unabhängige Bestätigung des Proxy-Musters.

Übertragbar. Einzelne Kettenglieder aus signierten Windows-Binaries sind für sich mehrdeutig. Kausale Prozess-Lineage kann diese Mehrdeutigkeit reduzieren. Und die Wahl zwischen Prävention und Detektion hängt am einzelnen Kettenglied, nicht an einer Grundsatzentscheidung.

Nicht aus dem Fall ableitbar. Die globale Verbreitung von ClickFix, eine allgemeine Erkennungsrate der gezeigten Abfrage, und eine Überlegenheit gegenüber jeder Einzelsignal-Regel in jeder Umgebung. Wer diese drei Aussagen im Text zu finden meint, liest mehr hinein, als belegt ist.

Was die Quellenlage tatsächlich hergibt, und was nicht

Bevor die Detektionsfrage sinnvoll diskutiert werden kann, muss die Gegenstandsfrage sauber sein, denn hier zirkulieren Zahlen, die einer Prüfung nicht standhalten.

Framework-seitig ist der Befund eindeutig. MITRE führt die Technik seit März 2025 als eigene Sub-Technique T1204.004 unter der Bezeichnung Malicious Copy and Paste (MITRE, 2026b). Bemerkenswert ist die Taktik-Zuordnung: Die Technik gehört zu Execution, nicht zu Initial Access. Die in der Anbieter-Berichterstattung übliche Rede vom verbreiteten Initial-Access-Vektor ist damit eine Konvention, keine Framework-Aussage.

Prävalenzseitig ist die Lage deutlich schlechter, als der Zitationsverlauf vermuten lässt. Die meistzitierte Zahl stammt von ESET und weist für das erste Halbjahr 2025 einen Zuwachs von 517 Prozent aus, verbunden mit Rang zwei und einem Anteil von knapp acht Prozent aller blockierten Angriffe (ESET, 2025a). Diese Zahl beruht auf einer einzigen Signatur. Im Folgehalbjahr verschwand dieselbe Signatur nach ESETs eigener Formulierung nahezu vollständig aus der Telemetrie, und zwar nicht wegen einer Mitigation, sondern weil Lumma Stealer, dessen wichtigster Verteilweg sie war, im Mai 2025 global hochgenommen wurde (ESET, 2025b). Eine Metrik, die so stark an der Aktivität eines Betreibers hängt, misst nicht die Verbreitung einer Technik.

Der schärfere Widerspruch liegt woanders. Huntress beziffert den Anteil von ClickFix an der Malware-Loader-Aktivität für 2025 auf 53 Prozent (Huntress, 2026b), während die Executive Edition von M-Trends 2026 ClickFix in ihrer Zusammenfassung der Initial-Infection-Vektoren nicht nennt. Dort stehen Exploits an erster Stelle, gefolgt von interaktivem Voice-Phishing (Mandiant, 2026). Ob ClickFix in der vollständigen Vektorliste des Hauptberichts auftaucht, lässt sich aus der Kurzfassung nicht ableiten. Unit 42 wiederum berichtet aus eigenen IR-Fällen von etwa einem Dutzend Vorfällen mit ClickFix als Einstieg (Unit 42, 2025).

Diese Zahlen sind nicht zusammenführbar, weil jede einen anderen Nenner hat. Die plausibelste Auflösung des Widerspruchs lautet, dass ClickFix im Commodity- und SMB-Segment dominant und im Enterprise-Breach-Segment randständig ist. Das ist die stärkste Aussage, die die Quellenlage trägt. Hinzu kommt eine Offenlegung, die zur Redlichkeit gehört: Der Anbieter, der den hier analysierten Fall dokumentiert hat, ist zugleich derjenige mit der höchsten publizierten Prävalenzzahl und einem unmittelbaren kommerziellen Interesse an deren Prominenz. Eine peer-reviewte Publikation mit eigener Prävalenzmessung existiert nach meiner Recherche nicht.

Legitime Binaries in bösartiger Reihenfolge

Die Kette lief in klar abgrenzbaren Schritten. Der kopierte Befehl nutzt pcalua.exe, den Program Compatibility Assistant, als Proxy für mshta.exe mit einer entfernten HTA-URL. Das HTA lädt per curl eine MSI nach und startet msiexec ohne Oberfläche. Die MSI legt einen reflektierenden Loader ab und verankert ihn über einen Run-Key. Von dort werden ein In-Memory-RAT für den Credential-Diebstahl und ein zweiter Backdoor mit Blockchain-basierter C2-Auflösung nachgezogen. Für den Aussenkanal dient ein umbenanntes Tunnel-Binary, die laterale Bewegung läuft über WMIExec und SMBExec, und zum Schluss wird Defender systematisch abgeschaltet (Huntress, 2026a).

Die Verwendung von pcalua als Proxy ist unabhängig bestätigt. CyberProof dokumentierte im Juli 2026 aus eigener Telemetrie eine ClickFix-Kette, die denselben Program Compatibility Assistant als vertrauenswürdigen Starter nutzt, dann allerdings über PowerShell und WMI weiterläuft und die Payload per Ordinal über WebDAV lädt (CyberProof Research Team, 2026). Zwei Anbieter, verschiedene Opfer, verschiedene zweite Stufen, gleicher Proxy. Das ist die Art von Konvergenz, die eine Einzelquelle nicht liefern kann.

Entscheidend für die Detektionsfrage ist die Beobachtung, dass jedes Kettenglied für sich mehrdeutig bleibt. Ein Silent-Install läuft bei jeder Software-Verteilung. Ein neuer Run-Key entsteht bei jeder legitimen Autostart-Installation. Erst Reihenfolge und kausaler Zusammenhang machen aus mehrdeutigem Rauschen ein eindeutiges Signal.

Der Strohmann, den niemand baut, und das Argument, das trägt

An dieser Stelle wird üblicherweise eine naive Regel als Kontrast aufgebaut, etwa ein Treffer auf mshta.exe mit einer entfernten URL.

Die übliche Begründung dafür, warum diese Regel scheitert, lautet: mshta sei zu laut. Diese Begründung hält der Prüfung nicht stand, und das gleich zweifach.

Erstens stimmt die Basisrate nicht. Barr-Smith et al. (2021) haben die Prävalenz von LOLBins systematisch gemessen und finden mshta in nur 1,09 Prozent und msiexec in 0,55 Prozent der untersuchten Malware. Über alle LOLBins hinweg liegt die Prävalenz bei 9,41 Prozent in Malware gegenüber 2,05 Prozent in benigner Software, also bei einem Verhältnis von rund 4,5. Bei realistischen Angriffs-Basisraten ist dieses Verhältnis für eine Einzelsignal-Entscheidung viel zu schwach, aber „zu laut” ist die falsche Diagnose.

Zweitens baut niemand diese Regel. Eine Auswertung des offenen Sigma-Korpus mit 3.144 Regeln zeigt, dass keine einzige Regel auf die bloße Prozesserzeugung von mshta.exe feuert (SigmaHQ, 2026). Alle 94 Regeln, die das Binary erwähnen, verlangen zusätzlichen Kontext.

Das eigentliche Argument ist stärker und empirisch besser belegt als der Strohmann. Es liegt im dokumentierten Reifegrad-Sprung derselben Regelfamilien. Die Sigma-Regel auf msiexec mit Quiet-Flag benötigt vier Ausschlussfilter für Temp-Pfade, Softwareverteilung und WSL und erreicht dennoch nur den Schweregrad medium, mit dokumentiertem Restfehlalarm. Die generische Run-Key-Regel steht ebenfalls auf medium, mit dem ausdrücklichen Hinweis auf legitime Software während der Installation. Sobald Kontext hinzukommt, etwa ein verdächtiger Zielordner oder eine Download-Herkunft, steigt dieselbe Familie auf high. Und die Regeln, die das ClickFix-Muster im RunMRU-Schlüssel über die Kombination aus Schlüssel, URL und LOLBin-Name erfassen, tragen durchgehend den Schweregrad high; eine davon führt die Fehlalarm-Einschätzung „unlikely”, die andere benennt als einzigen Fehlalarmfall legitime Anwendungen, die URLs über den Ausführen-Dialog öffnen (SigmaHQ, 2026).

Dieselbe Community, dieselben Binaries, ein anderer Reifegrad, und der Unterschied liegt nachweisbar in der Korrelation. Elastic liefert die passende Ergänzung aus dem Produktivbetrieb, indem die dortigen Regeln legitime mshta-Nutzer namentlich ausschließen müssen, darunter Configuration Manager, TeamViewer und ein Self-Service-Portal für Identitäten (Elastic, 2026).

Wie schlecht der Ausgangszustand ist, zeigt eine Messung an echtem Datenverkehr. Hassan et al. (2020) beobachteten bei einem kommerziellen EDR-System über eine Woche 58.096 Alerts auf 34 Hosts, von denen 1.104 zutrafen. Das entspricht einer Präzision von etwa 1,9 Prozent. Betriebsblindheit gegenüber solchen Alerts ist unter diesen Bedingungen kein Charakterfehler, sondern die vorhersehbare Folge.

Kausale Lineage statt Zeitfenster

Die Korrelationsthese ist empirisch gut abgesichert, und zwar durch mehrere unabhängige Forschungsgruppen mit konsistenten Effektgrößen. Hassan et al. (2020) entfernten durch die Gruppierung kausal zusammenhängender Alerts 97,8 Prozent der Fehlalarme bei vollständig erhaltener Detektionsrate. Hassan et al. (2019) erreichten mit einem verwandten Verfahren 84 Prozent Fehlalarm-Reduktion bei ebenfalls voller Detektionsrate. Van Ede et al. (2022) zeigten an 10,5 Millionen realen Sicherheitsereignissen aus zwanzig Organisationen eine Reduktion der Bearbeitungslast um 90,5 Prozent bei einer Präzision von 96,4 Prozent. Wang et al. (2020) erreichten auf 306 Produktiv-Hosts einen F1-Wert von 0,974 gegenüber 0,78 für eine Whitelist-Statistik. Han et al. (2020) maßen den Effekt der Kontextgröße direkt und fanden eine Präzision von 0,98 bei erweiterter Nachbarschaftsbetrachtung gegenüber 0,74 bei minimaler.

Nun kommt die Einschränkung, die den ursprünglichen Entwurf dieses Artikels korrigiert hat. Sämtliche dieser Arbeiten korrelieren über kausale Abhängigkeit, also über Prozess-Lineage, Informationsfluss oder Ereignissequenz. Keine von ihnen evaluiert eine reine Zeitfenster-Korrelation. Ich habe für die Zeitfenster-Variante keine peer-reviewte quantitative Evaluation gefunden. Der Unterschied ist nicht akademisch: Kausalität ist immun gegen zufälliges Zusammentreffen und robust gegen ein bewusstes Auseinanderziehen der Schritte, ein Zeitfenster ist beides nicht.

Hassan et al. (2020) liefern dazu einen direkt verwertbaren Messwert. Ihr an der Taktik-Reihenfolge orientiertes Scoring erreichte eine Fläche unter der ROC-Kurve von 0,99, eine naive Verknüpfung der Einzelbewertungen dagegen nur 0,79. Die Ordnung der Schritte trägt also messbar Information, die bloße Ko-Okkurrenz nicht enthält. Auch MITRE formuliert das Prinzip explizit: Verdächtiges Verhalten, das eine gemeinsame Prozess-Lineage mit anderem verdächtigen Verhalten teilt, sei mit höherer Wahrscheinlichkeit relevant (Daszczyszak et al., 2019). Die von MITRE für mshta hinterlegte Detektionsstrategie ist konsequenterweise sequenzbasiert formuliert und nicht als Einzelindikator (MITRE, 2026a).

Die folgende Abfrage setzt das um. Sie verknüpft nicht über ein Zeitfenster, sondern über die Eltern-Kind-Beziehung, identifiziert über die Kombination aus Prozesskennung und Erstellungszeit, weil Prozesskennungen allein wiederverwendet werden.

An einer Stelle bricht die kausale Kette allerdings, und zwar aus einem Grund, der nichts mit dem Angriff zu tun hat. Windows Installer ist ein Mehrprozessmodell. Der vom Angriff gestartete msiexec ist nur der Client; die eigentliche Installationsarbeit, also Dateien, Registry-Einträge und Custom Actions, erledigt ein zweiter msiexec im SYSTEM-Kontext, den der Windows-Installer-Dienst startet (Microsoft, 2016). Dieser Prozess ist kein Kind der Angriffskette, sondern ein Kind von services.exe. Eine passive Auswertung von 30 Tagen Telemetrie einer verwalteten Produktivumgebung über DeviceRegistryEvents bestätigt dieses Modell vollständig: Alle 118 Run-Key-Writes, bei denen msiexec der schreibende Prozess war, liefen im SYSTEM-Kontext, als Kind von services.exe oder als Custom-Action-Host unterhalb dieses Dienstprozesses, kein einziger in der Lineage des auslösenden Prozesses. Das schließt sämtliche Schreibvorgänge unter HKCU ein, die der Dienstprozess per Impersonation ausführt. Der Run-Key-Write und alles, was der Loader danach tut, hängen deshalb nicht mehr an der ursprünglichen Lineage.

Wer das ignoriert, baut eine Abfrage, die nur bis msiexec trägt und danach nichts mehr findet. Die Konsequenz ist eine einzige, bewusst eng gefasste zeitbasierte Naht genau an dieser Dienstgrenze: Der geteilte Dienstprozess zählt nur mit Ereignissen innerhalb eines kurzen Fensters nach dem Client, seine Kinder nur, wenn sie in diesem Fenster entstanden sind. Danach gilt wieder kausale Bindung. Diese Naht ist die schwächste Stelle der Abfrage und wird im Ergebnis pro Signal mit ausgewiesen, damit ein Analyst sieht, worauf ein Treffer beruht.

Die Abfrage ist eine Referenzimplementierung des beschriebenen Korrelationsmodells, keine produktionsfertige Analytic Rule. Ihr Zweck ist, die Bindungsannahmen explizit zu machen.

Die Konfidenz-Abstufung ist bewusst konservativ: Ein Treffer, der die Naht benötigt, erreicht höchstens „hoch”. Für die dokumentierte Kette heißt das, dass die oberste Stufe nie feuert, weil der Run-Key-Write im Installer-Modell strukturell hinter der Dienstgrenze liegt. Das ist kein Defekt, sondern der Preis der Ehrlichkeit: „sehr hoch” bleibt Ketten vorbehalten, deren Signale vollständig kausal gebunden sind. Die Bewertung der Korrelation in Tabelle 2 beschreibt entsprechend die Methode, nicht den Deckel dieses einen Falls.

Die Zeitfenster-Variante behält ihre Berechtigung als Rückfallebene dort, wo die kausale Kette an Grenzen reißt, für die sich keine so eng umrissene Naht setzen lässt wie an der Installer-Dienstgrenze, etwa wenn Prozesse über geplante Aufgaben oder erst nach einer Anmeldung neu aufsetzen. Sie sollte aber als das gekennzeichnet werden, was sie ist: die schwächere, empirisch nicht validierte Variante.

Ich habe die Kette samt Technique-Mapping als nachvollziehbares Szenario aufbereitet. Wer die Abfolge mit den zugehörigen ATT&CK-Techniques nebeneinander sehen will, findet sie im MITRE KQL Explorer, meinem Open-Source-Projekt. Das Szenario ist dort als static-reviewed markiert, also auf Basis der öffentlichen Berichterstattung aufbereitet und nicht im Labor nachgestellt.

Für mshta ist Prävention der bessere Kontrollpunkt, aber nicht der einzige

Ein Beitrag über die Detektion von mshta-Ketten muss eine Frage beantworten, die die Detektionsperspektive gern übergeht. Sie lautet, ob Detektion hier überhaupt die richtige Schicht ist.

Für mshta.exe lautet die Antwort nein, und die Belegkette ist lückenlos aus Herstellerprimärquellen. Microsoft führt das Binary auf der Liste der Anwendungen, die App Control umgehen können, und empfiehlt es ausdrücklich zum Blockieren (Microsoft, 2026a). Und die entscheidende Aussage steht in der Dokumentation zur Skript-Durchsetzung: Sämtliche Codeausführung über MSHTA wird blockiert, sobald eine App-Control-Policy mit Script Enforcement aktiv ist (Microsoft, 2026c).

Das ist ein Kosten-Nutzen-Verhältnis, gegen das keine Detektionsregel für denselben Pfad bestehen kann. Kein Tuning, keine Ausnahmeliste, keine Triage-Kosten, kein Alert. Wer eine mshta-Detektionsregel schreibt, ohne vorher geprüft zu haben, ob eine App-Control-Policy das Problem ersatzlos beseitigt, hat die Reihenfolge falsch gewählt.

Daraus folgt allerdings nicht, dass Detektion auf diesem Pfad entfallen kann. Eine Policy deckt nur die Systeme ab, auf denen sie ausgerollt und durchgesetzt ist, sie kennt Ausnahmen für Fachanwendungen, sie lässt sich umgehen, und sie sagt nichts über Ausführungen, die vor ihrer Einführung stattgefunden haben. Prävention verschiebt die Detektionsaufgabe also, sie hebt sie nicht auf. Die richtige Formulierung lautet deshalb nicht „Detektion ist hier falsch”, sondern: Für diesen Ausführungspfad ist Application Control der primäre Kontrollpunkt, und die Detektion sichert die Lücken dieser Kontrolle ab.

Die australische Signals Directorate rankt Prävention und Detektion auf derselben Skala und kommt zum selben Schluss: Application Control einschließlich HTA-Skripten gilt als essenziell mit mittleren laufenden Kosten, kontinuierliche Detektion und Response als exzellent, aber mit sehr hohen laufenden Kosten (Australian Signals Directorate, 2017).

Damit ist die Gegenposition aber auch ausgereizt, denn sie trägt nur für dieses eine Kettenglied.

Für msiexec.exe existiert kein tragfähiger Präventionsweg. Das Binary steht nicht auf der Blockliste, es gibt keine passende ASR-Regel, und eine generelle Sperre ist ausgeschlossen, weil msiexec die Softwareverteilung selbst ist. Microsoft stellt zudem klar, dass es keine ASR-Regel gibt, die Kindprozesse von mshta.exe unterbindet, und verweist für diesen Zweck auf App Control (Microsoft, 2026b). Für cmd.exe gilt eine ausdrückliche Einschränkung: App Control kontrolliert den Windows-Kommandoprozessor nicht, und ClickFix-Ketten nutzen genau diesen Pfad häufig (Microsoft, 2026c). Und für das Muster selbst, also die Befehlseingabe im Ausführen-Dialog, gibt es kein Präventionsäquivalent ohne prohibitive Nebenwirkungen, weil die Deaktivierung des Dialogs UNC-Pfade und Explorer-Funktionen bricht.

Hinzu kommt ein Einwand, den die Präventionsposition systematisch unterschlägt: Prävention hat ebenfalls ein Fehlalarmproblem, nur mit schlechterer Kostenstruktur. Microsoft bezeichnet ASR-Fehlblockaden in der eigenen Dokumentation selbst als false positives und hält im Produkt eine Kennzahl für die Nutzerauswirkung vor (Microsoft, 2026d). Ein Detektions-Fehlalarm kostet eine Analystenstunde, ein Präventions-Fehlalarm kostet Produktivität aller Nutzer und führt in der Praxis regelmäßig dazu, dass die Kontrolle insgesamt deaktiviert wird.

Weder Microsoft noch MITRE vertreten die Präventionsposition in Reinform. Beide empfehlen Prävention und Detektion nebeneinander. Die tragfähige Schlussfolgerung lautet deshalb nicht „Detektion statt Prävention”, sondern: Die Schicht wird nach dem Kettenglied gewählt, nicht nach der Doktrin, und die eigentliche Entscheidung ist, wer den Fehlalarm bezahlt, der Analyst oder der Nutzer.

Was die Telemetrie-These wirklich hergibt

Im dokumentierten Fall lief der Angriff die ersten rund fünf Stunden ohne Telemetrie, weil der Start-Host kein Monitoring hatte. Der Agent war in der Organisation lizenziert, aber auf genau diesem Gerät nicht ausgerollt (Huntress, 2026a). Die naheliegende Verallgemeinerung lautet, dass die Ausrollungslücke der eigentliche limitierende Faktor sei. Diese Verallgemeinerung ist in ihrer starken Form nicht haltbar, und die Korrektur ist interessanter als die ursprüngliche These.

Die am häufigsten zitierte Stützzahl stammt aus dem Microsoft Digital Defense Report und besagt, dass 80 bis 90 Prozent aller Kompromittierungen von nicht verwalteten Geräten ausgehen (Microsoft, 2023). Diese Zahl trägt weniger, als ihre Verbreitung nahelegt. Sie steht im selben Dokument in zwei nicht deckungsgleichen Fassungen, sie hat weder eine ausgewiesene Methodik noch einen Nenner, und in der Ausgabe 2025 findet sich keine entsprechende Kennzahl mehr; der Bericht rahmt Initial Access dort über Phishing, ungepatchte Web-Assets und exponierte Remote-Dienste (Microsoft, 2025). Wer die alte Zahl heute als aktuellen Beleg verwendet, zitiert eine Kennzahl, die ihr Herausgeber in der laufenden Ausgabe nicht mehr führt.

Die belastbareren Messungen aus echten Incident-Response-Fällen zeichnen ein moderateres Bild. Sophos fand ungeschützte Systeme in 40 Prozent der 2024 untersuchten Fälle und in 29,35 Prozent der 2025 untersuchten, dort auf Rang drei der beitragenden Faktoren, während identitätsbezogene Ursachen mit über 67 Prozent durchgehend deutlich höher liegen, 2025 mehr als doppelt so hoch (Sophos, 2025; Shier et al., 2026). Die Lücke ist real, aber weder dominant noch wachsend.

Die schärfste Gegenevidenz betrifft die Ursachenzuschreibung. Sophos berichtet, dass in den Fällen mit fehlender Telemetrie diese in 82 Prozent aktiv durch die Angreifer deaktiviert oder gelöscht worden war (Sophos, 2023). Umgerechnet auf alle Fälle bedeutet das, dass strukturell fehlende Telemetrie deutlich seltener ist als manipulierte. Microsoft ergänzt einen dritten Pfad: In 30 Prozent der beobachteten Human-operated-Ransomware-Vorfälle nutzten Angreifer vorhandene Antiviren-Ausschlüsse, also Fehlkonfiguration statt fehlender Ausrollung (Microsoft, 2025).

Und selbst dort, wo Werkzeuge vollständig ausgerollt sind, ist die Wirksamkeit begrenzt. Karantzas und Patsakis (2021) prüften elf EDR-Produkte gegen vier realistische Angriffsvektoren und fanden, dass zehn von 44 Kombinationen ohne jeden Alert durchliefen und nur sechs korrekt gemeldet wurden. Eine Messung an Produktivumgebungen mit bereits ausgerollten Werkzeugen ergab, dass nur 14 Prozent der simulierten Angriffe überhaupt einen Alert erzeugten und die Logging-Abdeckung bei 54 Prozent lag (Picus Security, 2025).

Die tragfähige Fassung der These lautet deshalb nicht „ausgerollt oder nicht”, sondern Reichweite und Integrität der Telemetrie, begrenzt durch drei unterscheidbare Mechanismen: nicht eingebundene Endpoints, architektonisch nicht instrumentierbare Geräteklassen an der Netzwerkperipherie, und nachträgliche Manipulation vorhandener Quellen. Mandiant benennt den zweiten Mechanismus ausdrücklich und stellt fest, dass das Vertrauen auf EDR blinde Flecken schafft, weil Angreifer auf Peripheriegeräte und Authentifizierungsprotokolle ausweichen, die außerhalb der Reichweite von Endpoint-Agenten liegen (Mandiant, 2026).

Peer-reviewt belegt bleibt der Kern der Aussage, allerdings mit einer Pointe gegen die eigene Formulierung. In der bislang einzigen Meta-Review zur Wirksamkeit von Sicherheitskontrollen kommen Woods und Seymour (2024) zu dem Schluss, dass die Wirksamkeit stärker davon abhängt, wie eine Kontrolle implementiert ist, als von der binären Frage, ob sie implementiert ist. Das ist „Available ist nicht Effective” in wissenschaftlicher Sprache, und zugleich ein Einwand gegen die Verkürzung auf die Ausrollung.

Grenzen dieser Argumentation

Fünf Einschränkungen sind offenzulegen, und sie sind nicht kosmetisch.

Erstens die Basisratengrenze. Axelsson (2000) hat gezeigt, dass die Leistungsfähigkeit von Intrusion Detection nicht durch die Erkennungsfähigkeit begrenzt wird, sondern durch die Fehlalarmrate. Bei einer Angriffswahrscheinlichkeit in der Größenordnung von zwei zu hunderttausend liefert selbst perfekte Erkennung bei einer Fehlalarmrate von einem Promille nur eine Trefferwahrscheinlichkeit von etwa zwei Prozent. Korrelation setzt an der richtigen Stellschraube an, hebt die Grenze aber nicht auf.

Zweitens, und das ist die größte ungeschlossene methodische Lücke, die Unabhängigkeitsannahme. Der Präzisionsgewinn aus der Konjunktion mehrerer Signale ist nur dann groß, wenn deren Fehlalarme statistisch unabhängig sind. Genau das ist in Unternehmensumgebungen fraglich, weil Softwareverteilung, Patch-Zyklen und Konfigurationsmanagement typischerweise gleichzeitig Prozessketten-, Persistenz- und Evasionssignale erzeugen. Keine der gesichteten Arbeiten quantifiziert diese Korrelation der Fehlalarme.

Drittens die Umgehbarkeit gegenüber einem adaptiven Angreifer. Goyal et al. (2023) erreichten gegen fünf provenienzbasierte Erkennungssysteme eine vollständige Umgehung, in einem Fall mit lediglich drei Prozent zusätzlicher benigner Aktivität, und zwar ohne das eigentliche Angriffsverhalten zu verändern. Der Mechanismus ist Verdünnung und kausale Entkopplung durch Prozess-Forking. Mukherjee et al. (2023) zeigten mit Prozess-Substitution Detektionsverluste von bis zu 59 Prozent. Die Autoren der erstgenannten Arbeit schließen regelbasierte Verfahren ausdrücklich aus ihrem Untersuchungsbereich aus, was die Übertragbarkeit auf die hier gezeigte Abfrage einschränkt, aber der zugrundeliegende Mechanismus ist verfahrensunabhängig. Insbesondere gilt: Jede endlich parametrisierte Korrelation definiert eine Grenze, jenseits derer der Angreifer frei operiert. Die oben gezeigte Abfrage betrachtet zwei Generationen. Eine dritte Ebene an Prozess-Forks entzieht die Kette dieser Sicht.

Viertens die Übertragbarkeit publizierter Messwerte. Cai et al. (2026) weisen darauf hin, dass die gängigen Benchmark-Datensätze stark skriptgesteuerte und damit vereinfachte gutartige Arbeitslasten enthalten, und maßen auf realistischeren Daten für mehrere provenienzbasierte Systeme eine Präzision von null auf Knotenebene bei nahezu perfekter Erkennungsrate. Die zitierten Werte von 0,96 und 0,98 sind Obergrenzen unter Laborbedingungen, keine Erwartungswerte für den Produktivbetrieb.

Fünftens die Prozessmodell-Grenze, die weiter oben schon aufgetaucht ist. Die kausale Bindung endet an jeder Dienstgrenze, weil ein vom Service Control Manager gestarteter Prozess kein Kind des Auslösers ist. Bei Windows Installer ist das systematisch der Fall, bei geplanten Aufgaben und bei allem, was erst nach einer Anmeldung startet, ebenso. Die Abfrage überbrückt genau eine dieser Grenzen und weist die Überbrückung im Ergebnis aus. Jede weitere Grenze in einer Kette bräuchte eine eigene Naht, und mit jeder Naht sinkt die Aussagekraft.

Hinzu kommt eine Einschränkung, die die Korrelationslogik selbst betrifft. Virkud et al. (2024) untersuchten, wie konsistent Erkennungsprodukte ATT&CK-Techniken zuordnen, und fanden bei 37 von mehreren Herstellern erkannten Entitäten nur eine einzige mit vollständiger Übereinstimmung der Zuordnung. Wer über Taktik-Labels korreliert statt über Prozess-Lineage, erbt diese Instabilität.

Was von der Hypothese übrig bleibt

ClickFix ist deshalb schwer zu erkennen, weil der Angriff keine bösartigen Werkzeuge braucht, sondern legitime Windows-Binaries in bösartiger Reihenfolge nutzt. Die Prüfung der eingangs formulierten Hypothese ergibt ein differenziertes Bild. Die Grenzen kontextloser Einzelsignal-Regeln sind belegt, aber nicht über eine hohe Basisrate der Binaries, sondern über den dokumentierten Reifegradunterschied zwischen kontextlosen und korrelierten Regeln im offenen Regelkorpus. Daraus folgt nicht, dass jedes Einzelsignal unbrauchbar wäre: Die Eltern-Kind-Beziehung pcalua zu mshta ist bereits für sich hochspezifisch und trägt als Hunting-Einstieg, wie die Bewertung in Tabelle 2 zeigt. Der Korrelationsgewinn ist durch mehrere unabhängige Forschungsgruppen mit großen und konsistenten Effekten belegt. Die Annahme, ein enges Zeitfenster genüge als Bindeglied, ist dagegen empirisch nicht abgesichert; belegt ist die Korrelation entlang kausaler Prozess-Lineage, und genau so sollte sie implementiert werden.

Die Coverage-Frage verschiebt sich von der Ausrollung zur Reichweite und Integrität der Telemetrie, mit drei unterscheidbaren Ursachen, von denen die nachträgliche Manipulation die häufigste und die Ausrollungslücke die seltenere ist. Und die Schichtfrage entscheidet sich pro Kettenglied: Wo Application Control greift, ist es der Detektion als primärer Kontrollpunkt überlegen, und für mshta greift es vollständig. Die Detektion bleibt daneben nötig, um Policy-Lücken, Ausnahmen, unverwaltete Systeme und bereits erfolgte Ausführung abzudecken. Wo Prävention gar nicht greifen kann, bei msiexec, beim Kommandoprozessor und beim Muster der Befehlseingabe selbst, ist Korrelation die einzige verfügbare Schicht.

Literaturverzeichnis

Australian Signals Directorate. (2017). Strategies to mitigate cyber security incidents. Australian Cyber Security Centre. https://www.cyber.gov.au/business-government/asds-cyber-security-frameworks/mitigating-cyber-security-incidents/strategies-to-mitigate-cybersecurity-incidents

Axelsson, S. (2000). The base-rate fallacy and the difficulty of intrusion detection. ACM Transactions on Information and System Security, 3(3), 186–205. https://doi.org/10.1145/357830.357849

Barr-Smith, F., Ugarte-Pedrero, X., Graziano, M., Spolaor, R., & Martinovic, I. (2021). Survivalism: Systematic analysis of Windows malware living-off-the-land. In 2021 IEEE Symposium on Security and Privacy (SP) (S. 1557–1574). IEEE. https://doi.org/10.1109/SP40001.2021.00047

Cai, Q., Wang, L., Zhu, Y., Chen, Z., Shen, X., & Li, Z. (2026). Building next-generation datasets for provenance-based intrusion detection. In Workshop on Attack Provenance, Reasoning, and Investigation for Security in the Monitored Environment. Internet Society. https://doi.org/10.14722/prism.2026.23021

CyberProof Research Team. (2026, 28. Juli). ClickFix keeps evolving: Rundll32 ordinal execution over WebDAV. https://www.cyberproof.com/blog/clickfix-keeps-evolving-rundll32-ordinal-execution-over-webdav/

Daszczyszak, R., Ellis, D., Luke, S., & Whitley, S. (2019). TTP-based hunting (MTR 18 0158). The MITRE Corporation. https://www.mitre.org/sites/default/files/publications/pr-19-3892-ttp-based-hunting.pdf

Elastic. (2026, 4. Mai). Mshta making network connections (defense_evasion_mshta_beacon.toml) [Detection rule]. GitHub. https://github.com/elastic/detection-rules/blob/main/rules/windows/defense_evasion_mshta_beacon.toml

ESET. (2025a). ESET threat report H1 2025. https://web-assets.esetstatic.com/wls/en/papers/threat-reports/eset-threat-report-h12025.pdf

ESET. (2025b, 16. Dezember). ESET threat report H2 2025. WeLiveSecurity. https://www.welivesecurity.com/en/eset-research/eset-threat-report-h2-2025/

Goyal, A., Han, X., Wang, G., & Bates, A. (2023). Sometimes, you aren’t what you do: Mimicry attacks against provenance graph host intrusion detection systems. In Proceedings 2023 Network and Distributed System Security Symposium. Internet Society. https://doi.org/10.14722/ndss.2023.23207

Han, X., Pasquier, T., Bates, A., Mickens, J., & Seltzer, M. (2020). UNICORN: Runtime provenance-based detector for advanced persistent threats. In Proceedings 2020 Network and Distributed System Security Symposium. Internet Society. https://doi.org/10.14722/ndss.2020.24046

Hassan, W. U., Bates, A., & Marino, D. (2020). Tactical provenance analysis for endpoint detection and response systems. In 2020 IEEE Symposium on Security and Privacy (SP) (S. 1172–1189). IEEE. https://doi.org/10.1109/SP40000.2020.00096

Hassan, W. U., Guo, S., Li, D., Chen, Z., Jee, K., Li, Z., & Bates, A. (2019). NoDoze: Combatting threat alert fatigue with automated provenance triage. In Proceedings 2019 Network and Distributed System Security Symposium. Internet Society. https://doi.org/10.14722/ndss.2019.23349

Huntress. (2026a). Potemkin loader & RMMProject: The anatomy of a ClickFix attack. https://www.huntress.com/blog/potemkin-loader-rmmproject-clickfix-attack

Huntress. (2026b, 17. Februar). Huntress cyber threat report exposes the playbook for organized cybercrime [Pressemitteilung]. https://www.huntress.com/press-release/huntress-cyber-threat-report-exposes-the-playbook-for-organized-cybercrime

Karantzas, G., & Patsakis, C. (2021). An empirical assessment of endpoint detection and response systems against advanced persistent threats attack vectors. Journal of Cybersecurity and Privacy, 1(3), 387–421. https://doi.org/10.3390/jcp1030021

Mandiant. (2026). M-Trends 2026: Executive edition. Google Cloud. https://services.google.com/fh/files/misc/m-trends-2026-executive-edition-en.pdf

Microsoft. (2016, 5. Oktober). The Windows Installer service. Visual Studio Setup Blog. https://devblogs.microsoft.com/setup/the-windows-installer-service/

Microsoft. (2023). Microsoft digital defense report 2023. https://www.microsoft.com/content/dam/microsoft/final/en-us/microsoft-brand/documents/MDDR_FINAL_2023_1004.pdf

Microsoft. (2025). Microsoft digital defense report 2025: Lighting the path to a secure future. https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/microsoft/msc/documents/presentations/CSR/Microsoft-Digital-Defense-Report-2025.pdf

Microsoft. (2026a). Applications that can bypass App Control and how to block them. Microsoft Learn. https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/design/applications-that-can-bypass-appcontrol

Microsoft. (2026b). Migrating from a non-Microsoft HIPS to attack surface reduction rules. Microsoft Learn. https://learn.microsoft.com/en-us/defender-endpoint/migrating-asr-rules

Microsoft. (2026c). Script enforcement with App Control for Business. Microsoft Learn. https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/design/script-enforcement

Microsoft. (2026d). Test your attack surface reduction (ASR) rules deployment. Microsoft Learn. https://learn.microsoft.com/en-us/defender-endpoint/attack-surface-reduction-rules-deployment-test

MITRE. (2026a). System binary proxy execution: Mshta (T1218.005). MITRE ATT&CK. https://attack.mitre.org/techniques/T1218/005/

MITRE. (2026b). User execution: Malicious copy and paste (T1204.004). MITRE ATT&CK. https://attack.mitre.org/techniques/T1204/004/

Mukherjee, K., Wiedemeier, J., Wang, T., Wei, J., Chen, F., Kim, M., Kantarcioglu, M., & Jee, K. (2023). Evading provenance-based ML detectors with adversarial system actions. In Proceedings of the 32nd USENIX Security Symposium (S. 1199–1216). USENIX Association. https://www.usenix.org/conference/usenixsecurity23/presentation/mukherjee

Picus Security. (2025). The blue report 2025. https://www.picussecurity.com/blue-report

Shier, J., Wood, H., & Gunn, A. (2026, 24. Februar). Nowhere, man: The 2026 active adversary report. Sophos. https://www.sophos.com/en-us/blog/2026-sophos-active-adversary-report

SigmaHQ. (2026). Sigma detection rules repository [Software]. GitHub. Abgerufen am 2. September 2026 von https://github.com/SigmaHQ/sigma

Sophos. (2023, 14. November). Cybercriminals disabled or wiped out logs in 82 % of attacks with missing telemetry [Pressemitteilung]. https://www.sophos.com/en-us/press/press-releases/2023/11/cybercriminals-disabled-or-wiped-out-logs-82-attacks-missing-telemetry

Sophos. (2025, 2. April). It takes two: The 2025 active adversary report. https://www.sophos.com/en-us/blog/2025-sophos-active-adversary-report

Unit 42. (2025, 10. Juli). Fix the click: Preventing the ClickFix attack vector. Palo Alto Networks. https://unit42.paloaltonetworks.com/preventing-clickfix-attack-vector/

van Ede, T., Aghakhani, H., Spahn, N., Bortolameotti, R., Cova, M., Continella, A., van Steen, M., Peter, A., Kruegel, C., & Vigna, G. (2022). DEEPCASE: Semi-supervised contextual analysis of security events. In 2022 IEEE Symposium on Security and Privacy (SP) (S. 41–58). IEEE. https://doi.org/10.1109/SP46214.2022.9833671

Virkud, A., Inam, M. A., Riddle, A., Liu, J., Wang, G., & Bates, A. (2024). How does endpoint detection use the MITRE ATT&CK framework? In Proceedings of the 33rd USENIX Security Symposium. USENIX Association. https://www.usenix.org/conference/usenixsecurity24/presentation/virkud

Wang, Q., Hassan, W. U., Li, D., Jee, K., Yu, X., Zou, K., Rhee, J., Chen, Z., Cheng, W., Gunter, C. A., & Chen, H. (2020). You are what you do: Hunting stealthy malware via data provenance analysis. In Proceedings 2020 Network and Distributed System Security Symposium. Internet Society. https://doi.org/10.14722/ndss.2020.24167

Woods, D. W., & Seymour, S. (2024). Evidence-based cybersecurity policy? A meta-review of security control effectiveness. Journal of Cyber Policy, 8(3), 365–383. https://doi.org/10.1080/23738871.2024.2335461