Ghost CMS e ClickFix: il watering hole con il certificato di Harvard

L'articolo che hai letto la settimana scorsa su harvard.edu non era l'articolo che Harvard aveva pubblicato. In fondo alla pagina era stato accodato un loader JavaScript, uno script offuscato che faceva il fingerprint del tuo browser e — se passavi il filtro — un overlay che ti chiedeva di dimostrare di essere umano incollando un comando nella finestra Esegui di Windows. Lo stesso valeva per oxford.ac.uk, per auburn.edu, per una property di DuckDuckGo e per oltre 700 altri domini identificati da XLab tra il 7 e il 17 maggio 2026. Il CMS dietro tutti loro era Ghost. La vulnerabilità dietro il JavaScript era la CVE-2026-26980, una SQL injection nella Content API di Ghost patchata a febbraio.

Tre mesi di installazioni non aggiornate sono bastati a invertire il segnale di fiducia. L'hostname che la tua URL allow-list considerava attendibile, il certificato che il browser considerava valido, la cache CDN che fronteggiava la richiesta — hanno tutti dato il via libera a un payload mai visto, perché era servito direttamente dal publisher.

Il perimetro Ghost CMS che non era un perimetro

La CVE-2026-26980 è stata divulgata il 19 febbraio 2026. Il vettore CVSS è AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L — non autenticata, di rete, complessità bassa, lettura completa del database e scrittura sull'integrità. Il CNA GitHub l'ha classificata 9.4. NIST l'ha valutata 7.5 in una lettura più conservativa, focalizzata sulla sola confidenzialità. Le versioni affette vanno dalla 3.24.0 alla 6.19.0; la fix è la 6.19.1. L'advisory ufficiale di Ghost è esplicito: poiché la chiave Content API è pubblicamente accessibile per design, l'unico workaround a livello applicativo è una regola WAF che blocchi letteralmente la substring slug:[ nei parametri di query, regola che rischia di rompere funzionalità legittime.

SentinelOne ha riportato la prima sfruttamento in-the-wild il 27 febbraio — otto giorni dopo la patch. La campagna massiva documentata da XLab è arrivata oltre due mesi più tardi, il 7 maggio, contro un parco installato che chiaramente non si era aggiornato tutto. La catena d'attacco non è sottile:

1. Colpire la Content API col payload SQLi, leggere la chiave admin dal database.
2. Autenticarsi alla Admin API di Ghost con la chiave rubata.
3. Usare l'endpoint di modifica articoli per accodare un tag <script> — riconoscibile come ghost_once_footer_* — a ogni post del sito.
4. Lo script carica un cloaker a due stadi derivato dal kit commerciale Adspect. Crawler, scanner di sicurezza, IP di ASN cloud e visitatori che falliscono il fingerprint del browser ricevono l'articolo originale invariato.
5. I visitatori che passano il filtro ricevono un overlay iframe che imita l'interstitial "verify you are human" di Cloudflare — l'esca ClickFix.

La distribuzione dei siti compromessi non è una long-tail di rumore. Secondo la telemetria XLab: blog personali 48,1%, SaaS/tech 14,8%, AI/ML 4,6%, crypto/Web3 2,9%. Il bias è verso pubblici i cui laptop tengono credenziali CI, checkout di codice sorgente, sessioni AWS e chiavi wallet. Gli attaccanti hanno scelto Ghost non perché sia popolare ma perché l'audience delle pubblicazioni Ghost ha alto valore per click.

Cosa consegna davvero ClickFix nel 2026

ClickFix non è una vulnerabilità. È un exploit UX contro la finestra Esegui di Windows e gli appunti utente. Il finto captcha copia una one-liner PowerShell negli appunti, poi istruisce l'utente a premere Win+R e a incollarla per "completare la verifica". Il comando incollato tipicamente risolve un dominio, scarica uno stager e passa il controllo a un loader di secondo stadio. La catena è invisibile al filtro email, alla memory protection EDR sul processo padre e alla maggior parte dei controlli di egress di rete — perché il processo padre è cmd.exe o powershell.exe lanciato dall'umano.

Nella campagna Ghost, XLab ha tracciato la catena attraverso questi domini C2 / staging usati dai due cluster operatori identificati:

Operatore	Domini usati
Threat Actor A	clo4shara[.]xyz, cloud-verification[.]com, jalwat[.]com, com-apps[.]cc, web-telegram[.]ug
Threat Actor B	staticcloudflare[.]pro, script-dev[.]digital, script-dev[.]buzz, cdnupdatenews[.]top

Il payload finale analizzato in reverse è UtilifySetup.exe (MD5 18a7251ddde77ed24bc54700d84d9be1), un installer Inno Setup che impacchetta una build Electron modificata derivata dal progetto open-source Grape. Persistenza via setLoginItemSettings, beacon al C2 ogni 30 secondi in attesa di istruzioni che possono eseguire JavaScript arbitrario o lanciare binari aggiuntivi.

La campagna Ghost è una fra molte. Microsoft Threat Intelligence identifica Lumma Stealer come il payload ClickFix più prolifico e traccia campagne che colpiscono "migliaia di device enterprise e end-user a livello globale ogni giorno". Sekoia ha documentato un singolo framework che colpisce WordPress, IClickFix, compromettendo oltre 3.800 siti in 82 paesi da dicembre 2024. I kit ClickFix si vendono in abbonamento mensile a 200–1.500 dollari. Huntress ha identificato a gennaio 2026 una variante chiamata CrashFix che fa crashare Chrome di proposito e poi presenta un finto prompt di recovery. Microsoft ha documentato a febbraio 2026 una variante DNS-tunnelled in cui il comando incollato estrae l'URL di secondo stadio da una risposta nslookup, bypassando del tutto le blocklist URL-based.

Perché allow-list, reputation feed e edge CDN sono ciechi

Gli strati difensivi che bloccano il traffico cattivo in entrata guardano dalla parte sbagliata per questa classe d'attacco. Considera cosa succede quando il laptop di un analista scarica un articolo da harvard.edu:

• Il resolver DNS risponde con un IP di Harvard. Il tier di reputation classifica il dominio "permit".
• L'handshake TLS si chiude contro un edge Cloudflare con un wildcard valido di Harvard. Il log di certificate transparency non segnala nulla.
• Il proxy aziendale logga una GET HTTPS con Referer: <Slack interno>, status 200, 184 KB di response. Categoria Education.
• Il SIEM non correla nulla di tutto questo con nient'altro perché niente di tutto questo è anomalo.

Quaranta secondi dopo, lo stesso laptop apre una connessione verso script-dev[.]digital in TLS 1.3, scarica un blob JavaScript da 12 KB, e prosegue con una HTTPS verso com-apps[.]cc/11z77u3.php. Otto minuti dopo, un powershell.exe appena lanciato contatta cdnupdatenews[.]top sulla 443 ogni trenta secondi, con una distribuzione di dimensione payload che combacia con un beacon Electron.

Quasi ogni strato nella prima sequenza diceva fidati. La seconda sequenza è il breach vero. La domanda che ogni difensore dovrebbe porsi adesso è: quale strato del tuo stack vede il legame tra la prima e la seconda, in tempo per interrompere il beacon?

"Avevamo log puliti dal filtro URL, log puliti dall'EDR, log puliti dal CASB. La prima cosa che ci ha detto che qualcosa non andava è stato un flusso outbound che il nostro NDR ha etichettato come beacon Electron mai visto, verso un dominio registrato sei giorni prima. La visita all'articolo poisonato era avvenuta dodici minuti prima. Nessun controllo a monte l'aveva visto perché tutti guardavano la sorgente."

È più o meno la conversazione che facciamo ogni settimana con i team di security. La sorgente è reputata. La destinazione non lo è. La finestra tra le due è corta. Nessuno dei layer di reputation-e-categoria convenzionali è stato architettato per chiuderla.

La superficie di rilevamento è la rete, finché il beacon è vivo

L'unico sensore che cattura questa classe d'attacco in modo affidabile è quello che guarda al traffico, non alla categoria URL o all'hash del file. Tre firme comportamentali sono visibili a un modello deep-learning wire-speed nei secondi successivi al primo beacon:

• Novità del dominio rispetto al profilo della sessione. Un laptop il cui baseline a 30 giorni non contiene zero connessioni verso un dominio la cui registrazione è più recente della finestra di baseline, contattato entro pochi minuti da una sessione browser che ha appena finito una fetch a un host reputato non correlato, in cadenza sostenuta a 30 secondi.
• Mismatch del fingerprint applicativo. Firme TLS JA4/JA4S e distribuzioni di dimensione pacchetto che dicono Electron, non Chrome — emergenti da un host il cui profilo normale è browser-only.
• Cadenza C2 vs cadenza umana. Outbound periodico su orari fuori-business, con entropia del payload e tempi inter-arrival che combaciano con un beacon, non con un'app di polling.

Nessuna di queste richiede un IOC noto. Nessuna richiede una firma per UtilifySetup.exe. Sono segnali comportamentali che un modello traffic ML wire-speed coglie la prima volta che il beacon parte — che è anche la prima opportunità di interromperlo prima che lateral movement o exfil di credenziali siano avvenuti. Per la stessa ragione il ransomware in fase di cifratura e l'exfiltrazione dati in corso vengono presi da questa classe di sensore: la rete vede la conseguenza del breach prima del disco o del SIEM.

Per chi gestisce il CMS: il perimetro che serve davvero validare

Se gestisci un'installazione Ghost, o un sito WordPress, o uno stack Drupal — e gli ultimi 30 giorni hanno dimostrato che puoi gestirli tutti e tre contemporaneamente — la domanda operativa non è "siamo patchati?". È: una validazione adversarial continua coglierebbe la catena d'exploit end-to-end sulla nostra deployment specifica, questa settimana, contro la versione che stiamo davvero facendo girare, incluse le regole WAF che avrebbero dovuto mitigare la finestra non patchata?

È il delta tra un pentest trimestrale e uno continuo. La CVE-2026-26980 è stata patchata il 19 febbraio. La campagna massiva è arrivata il 7 maggio. I 77 giorni tra le due date sono esattamente la cadenza a cui i cicli di assessment annuali o trimestrali falliscono: il report sulla scrivania dice "Ghost aggiornato all'ultimo audit" mentre l'istanza live è due minor versions indietro perché qualcuno aveva rimandato l'upgrade. La validazione continua chiude quella finestra perché ri-esegue la catena — recon → exploit → estrazione chiave API → modifica articolo — su ogni cadenza, contro la deployment com'è davvero, non com'era all'ultimo audit.

Come Zero Hunt chiude entrambe le metà

Questo articolo riguarda una classe d'attacco con due superfici difensive distinte, e l'appliance Zero Hunt è una delle poche piattaforme che le indirizza entrambe da un singolo sensore.

Lato visitatore — la superficie su cui questo articolo è centrato — il pillar AI Traffic Analysis fa girare un modello deep-learning proprietario con quattro teste di inferenza parallele (traffico sospetto, classificazione malware, identificazione tipo attacco, fingerprinting applicativo) a 2,7+ Gbit/s sulla GPU dell'appliance. È il sensore che segnala il beacon Electron mai visto verso script-dev[.]digital trenta secondi dopo che il laptop ha visitato un articolo poisonato su harvard.edu, mentre il canale C2 è ancora vivo e prima che il credential stealer abbia finito la sua prima passata sulla ~/.aws/. Lo fa col modello che gira localmente sull'appliance, senza callback cloud e senza telemetria che lascia la rete.

Lato operatore CMS, lo swarm di 10 agenti generative pentest (Recon → Web → Exploit → Credential → Post-Exploit → Pivot → Tactic → Report, coordinato dall'AI Controller) ri-esegue la catena CVE-2026-26980 end-to-end contro la deployment live a ogni campagna schedulata o triggerata dal change — con ogni exploit scritto per-target dall'LLM locale, backtestato in AI Gym contro il corpus Vulhub da 316 esercizi prima della promozione, e l'evidenza finale firmata ECDSA per il bundle Trust Center. Se il patch state regredisce, se un asset nuovo compare sul perimetro, o se una regola WAF a valle si rivela non mitigare ciò che diceva di mitigare, la catena gira e il risultato finisce nell'audit trail entro l'ora.

Entrambi i pillar girano sulla stessa appliance on-prem. Nessun exploit e nessuna cattura traffico esce mai dalla rete del cliente.

Il publisher era Harvard. Il distributore era Ghost. Il difensore adesso deve essere la rete.

---

Fonti per questo articolo — Analisi tecnica XLab/Qianxin, 7–24 maggio 2026; BleepingComputer, 24 maggio 2026; NVD CVE-2026-26980; GitHub advisory GHSA-w52v-v783-gw97; Microsoft Threat Intelligence su ClickFix; database vulnerabilità SentinelOne.

Letture correlate: Mandiant dice che il dwell time è 14 giorni. UNMC erano 858. — stesso blind spot difensivo, settore sanitario. Ransomware solo-esfiltrazione: perché il traffic ML wire-speed è ora l'ultima linea di difesa. Parla con noi se il tuo stack difensivo ancora non vede la rete tra la visita e il beacon.