De ClickFix techniek laat zien hoe aanvallers beveiliging kunnen omzeilen zonder klassieke kwetsbaarheden. In plaats van een exploit te misbruiken, bijlagen te laten detoneren of een verdacht bestand te downloaden, zetten ze vertrouwde websites om in “reparatietools” waar gebruikers uiteindelijk zelf de kwaadaardige stap uitvoeren.
Een nieuw wereldwijd rapport van CTM360 beschrijft hoe de aanpak groeide van een curiositeit eind 2023 naar een volwassen dienst met schaalbare infrastructuur en een doelbewuste, state-sponsored gebruikersbasis. Het resultaat: een van de meest bepalende vormen van initial access in enterprise-telemetrie.
Wat is de ClickFix techniek precies?
De aanval begint met een pagina die voor de bezoeker klopt: een probleem dat jouw situatie lijkt te beschrijven. Denk aan een “verificatie” die niet voltooit, een pagina die niet goed kan worden geladen of een document dat niet wil openen. Vervolgens biedt de pagina “instructies” die als een normale oplossing voelen.
Daar zit de kern: de website schrijft stilletjes een “fix” naar het klembord en stuurt de gebruiker naar een systeemonderdeel dat doorgaans al vertrouwd is. De bezoeker moet vervolgens plakken en op Enter drukken in een gangbare interface, zoals een interpreteerder of een systeem-venster dat toegang heeft tot commando’s.
Er is daarbij vaak niets voor beveiligingsscanners om op te pikken. Omdat er meestal geen exploit, bijlage of download aan te pas komt, blijven veel traditionele detecties die draaien op payload-indicaties, domeinreputatie of e-mailgedrag buiten bereik.
Waarom domeinblokkering bijna niet helpt
Een veelgebruikte reactie is: “blokkeer de domeinen die de lokpagina’s serveren.” Volgens het rapport werkt dat in deze context maar beperkt, omdat de campagne flexibel is.
De infrastructuur is zo opgezet dat de operator lure-hostnames kan wisselen zonder dat elke geïnfecteerde site opnieuw aangepast hoeft te worden. In de waargenomen keten maakt de malafide pagina bij het laden een uitlezing naar een smart contract op de Polygon-blockchain. Dat contract levert een gecodeerde string terug die decodeert naar de actuele lure-hostname.
Door één waarde op de keten te wijzigen, volgen alle geïnfecteerde sites binnen seconden. Daarbij stuurt de techniek niet op “aanvallersdomeinen” als vaste indicatoren: scripts bevatten geen direct verwijzende aanvallerdomeinen. Bovendien worden de read-only mechanismen gebruikt via legitieme, gedeelde diensten die ook andere echte toepassingen nodig hebben.
Per bezoeker een andere aanval: server-side sturing
Een tweede lastig punt is dat targeting server-side plaatsvindt. De lokpagina rapporteert informatie over het besturingssysteem en de versie terug aan de operator. Vervolgens stuurt de aanvaller een configuratie die aangeeft welke platforms worden aangevallen en welke landingpagina’s daarbij horen.
In de steekproef uit het rapport was Windows ingeschakeld, terwijl macOS en Linux “in reserve” werden klaargezet. Mobile werd onderdrukt, en er werd met cookies voorkomen dat de overlay voor herhaalbezoekers opnieuw getoond werd (in de sample voor een periode van 90 dagen).
Hierdoor kan het beeld dat onderzoekers krijgen afwijken van de echte capaciteit van de campagne. Wat vaak als “Windows-probleem” wordt gezien, kan ook simpelweg een kwestie zijn van server-side flags: de macOS-variant was in de sample functioneel, en de Linux-slot bestond maar was niet gevuld.
Waarom sandbox-resultaten misleidend kunnen zijn
Het rapport benadrukt bovendien dat payloads niet altijd meteen (of überhaupt) beschikbaar zijn. In de dropper die tijdens analyse werd teruggevonden, zit een machine-identiteitsfingerprint verweven in de downloadroute. Denk aan gegevens zoals een hardware- en account-identiteit (GUID), volume serial, computenaam, BIOS-fabrikant, systeemmodel, GPU en gebruikersnaam. Die informatie wordt base64-gecodeerd doorgegeven.
Dat heeft twee gevolgen. Ten eerste kan de command-and-control server per machine een passende payload leveren, of besluiten niets te leveren. Ten tweede betekent dit dat een sandbox-check op “detonatie” structureel onbetrouwbaar kan worden.
Een belangrijk nuancepunt: het ontbreken van een payload in een gecontroleerde omgeving is geen bewijs dat de site schoon is. De techniek is immers juist gebouwd om gebruikers in echte interactie te sturen, terwijl geautomatiseerde analyse vaak “schone” varianten ontvangt.
Waarom WordPress zo vaak terugkomt
WordPress verschijnt volgens CTM360 niet toevallig. De aanpak leunt op de voordelen van bestaande infrastructuur: echte domeinen, geldige certificaten, normale toestroom en in veel organisaties onvoldoende monitoring. Met andere woorden: reputatie is goedkoper en geloofwaardiger dan wanneer er constant nieuwe infrastructuur gebouwd moet worden.
In het onderzochte geval bleek de besmetting bovendien niet beperkt tot één plek zoals een zichtbaar script in een pagina, post of thema. De loader werd via PHP toegevoegd aan elke dynamische response van de server en leverde byte-identieke output voor HTML, RSS en JSON. Het wijst erop dat een must-use plugin gebruikt werd die bij elke request laadt en niet altijd zichtbaar is in het standaard pluginoverzicht.
Daarnaast stonden er circa twee dozijn backdoor-administratoraccounts klaar, aangemaakt via scripts. Alleen de “zichtbare” sporen verwijderen—zoals het script, spam-pagina’s of één duidelijk fout account—herstelt het probleem dan ook niet automatisch.
Wat werkt wél: vier knelpunten en praktische regels
Het rapport structureert remediation rond vier momenten waar elke campagne langs moet: een pagina moet de clipboard kunnen schrijven, een gebruiker moet een interpreter kunnen openen, die interpreter moet internet kunnen bereiken, en er moet iets persist en uitvoeren om informatie te verzamelen en exfiltreren.
1) Beperk clipboard-schrijfacties
Een controle die volgens het rapport te weinig wordt ingezet is het standaard blokkeren van clipboard-write in beheerde browsers. Daarmee sluit je de aanval al af bij de “staging”-fase. De site kan dan nog instructies tonen, maar de gebruiker kan de instructie niet automatisch plakken.
2) Forceer webverkeer en script-utilities via een geauthenticeerde proxy
Een andere rem die breed werkt is het afdwingen dat script interpreters en fetch-utilities via een geauthenticeerde proxy moeten werken. Daarmee breek je de keten bij de eerste hop op Windows, macOS én Linux, zonder dat je afhankelijk bent van één indicator die snel veroudert.
3) Gebruik één duidelijke gebruikersregel
Voor eindgebruikers is er één regel met blijvende waarde:
Geen enkele legitieme website vraagt om een kopie/plak-actie in Run box, PowerShell, Terminal, een command prompt of de adresbalk van File Explorer. Als een pagina wél vraagt om te kopiëren en plakken, dan is de pagina vrijwel zeker de aanval.
Gerelateerd: social engineering en initial access in de zorg
ClickFix techniek past in een breder patroon waarin aanvallen niet draaien om “een exploit vinden”, maar om gebruikersacties veilig te laten lijken. In de zorg zagen we eerder hoe social engineering tot datalekken kan leiden. Lees meer in social engineering en datalekken in de zorgsector.
Tot slot: denk minder aan blokkeren, meer aan ketenbeheersing
De boodschap uit het CTM360-rapport is duidelijk: bij ClickFix techniek is “zoek en blokkeer het domein” vaak een achterhaalde strategie. De lure kan snel rouleren en de echte dreiging zit in de route naar uitvoering: clipboard, interactieve user execution, internettoegang en persistente stappen.
Wie teams en systemen beschermt met controles die de ketenknelpunten beperken—clipboard, proxy-controle, en streng gedrag rond kopiëren/plakken—verkleint de kans dat een vertrouwde website verandert in een malware-trap.
Bron: https://thehackernews.com/2026/09/17000-urls-reveal-how-clickfix-turns.html
