🛡️ Executive Summary
- third-party.com, usato per anni come placeholder in documentazione e codice, serve oggi una pagina ClickFix malevola agli utenti Windows.
- Il dominio compare in documentazione, test, skill AI e materiali MCP: i file restano invariati, ma il contenuto raggiunto dall’URL può cambiare proprietario e comportamento.
- Gli attaccanti applicano cloaking per mostrare il payload solo a Windows, rendendo inefficaci controlli statici e scanner eseguiti da sistemi Linux o datacenter.
Un dominio apparentemente innocuo utilizzato per anni come placeholder nella documentazione tecnica è diventato un’infrastruttura ClickFix attiva. third-party.com compare in esempi, test, AI Skills e documentazione associata a progetti conosciuti perché il nome sembra l’equivalente generico di example.com. La differenza è sostanziale: example.com è riservato da IANA proprio per poter essere utilizzato negli esempi senza diventare proprietà di terzi, mentre third-party.com è un normale dominio registrabile. Oggi agli utenti Windows mostra un falso controllo Cloudflare, modifica gli appunti e tenta di convincerli a eseguire PowerShell. Il codice nei repository non è stato compromesso: è cambiato ciò che esiste dall’altra parte di un URL considerato innocuo.
Cosa leggere
Il placeholder resta identico ma il server dietro può cambiare completamente
La ricerca pubblicata da Manifold Security nasce durante l’analisi di skill pubbliche e server MCP. Un riferimento a third-party.com, apparentemente utilizzato come semplice endpoint dimostrativo, era stato classificato dai sistemi di monitoraggio come indicatore di phishing. L’approfondimento ha mostrato che il dominio veniva citato come placeholder in documentazione tecnica, esempi OAuth, test cross-origin e persino snippet che simulavano il caricamento di script di terze parti. Nessuno di questi materiali era necessariamente malevolo quando venne scritto. Il problema è architetturale: un URL incorporato staticamente in un README, una skill o una configurazione continua a puntare allo stesso nome anche quando il controllo del dominio o la sua infrastruttura cambia. È una variante del rischio già evidente nelle supply chain costruite intorno ad AI Skills e server MCP apparentemente affidabili, ma senza necessità di modificare il repository originale.
Leggi anche: AgentJacking mostra come documentazione e configurazioni possano diventare input ostili per i coding agent
Agli utenti Windows compare ClickFix, agli scanner può apparire una pagina innocua
Il dominio applica content cloaking basato sul sistema operativo dichiarato dal browser. Un user-agent Windows riceve una falsa pagina “Performing security verification” costruita per imitare Cloudflare, completa di checkbox, animazioni e Ray ID. Il JavaScript intercetta la copia negli appunti e inserisce un comando PowerShell offuscato; la vittima viene quindi guidata attraverso la sequenza ormai tipica di ClickFix: Windows+R, Ctrl+V, Invio. Il comando recupera una seconda fase da elxxvvx[.]xyz/f utilizzando Invoke-RestMethod e la esegue in memoria con Invoke-Expression, sopprimendo gli errori per ridurre gli indizi visibili. Il sito aggiunge inoltre al contenuto copiato un testo che ricorda un token di verifica, così da far apparire il comando meno anomalo quando raggiunge la finestra Esegui. La tecnica segue il principio già osservato in TerminalFix, dove un falso controllo Cloudflare trasforma l’utente nel primo esecutore della catena.
La parte più interessante riguarda però ciò che ricevono gli altri sistemi. Visitando la stessa pagina con un user-agent macOS o Linux, Manifold ha osservato una falsa comunicazione secondo cui il sito richiede Windows, senza il codice ClickFix destinato a manipolare gli appunti. Uno scanner eseguito da Linux, da un’infrastruttura cloud o con un profilo non corrispondente alla vittima può quindi classificare il dominio come innocuo proprio perché l’attaccante decide di non mostrargli il payload.
Repository e skill possono ereditare un rischio senza ricevere una singola modifica
Il problema è particolarmente significativo per l’ecosistema degli agenti AI. La ricerca individua riferimenti a third-party.com in documentazione e test appartenenti a progetti come Chromium, Sanity e Vercel, oltre che in skill e materiali relativi a MCP. In molti casi si tratta semplicemente di esempi: una skill mostra come caricare uno script di terze parti, una guida illustra un gateway OAuth, un test verifica il comportamento cross-origin. Il riferimento statico può però essere letto da una persona, copiato in un progetto reale oppure interpretato da un agente dotato della capacità di seguire URL e trasformare la documentazione in azioni.
Non occorre che l’agente venga compromesso direttamente. È sufficiente che consideri quel riferimento parte di una fonte affidabile e decida di raggiungerlo durante un’attività. Il rischio estende il problema già emerso nel tool poisoning dei server MCP: la trust boundary non coincide più con il file locale o con il repository analizzato, ma comprende tutte le risorse esterne che quel materiale indica. Una documentazione perfettamente legittima può diventare pericolosa anni dopo senza cambiare un carattere.
example.com è sicuro proprio perché nessuno può comprarlo
La distinzione tecnica più semplice è anche quella più importante. Domini come example.com, example.org ed example.net sono riservati per la documentazione e non possono essere acquistati da un operatore che successivamente ne modifica il contenuto. third-party.com, nonostante il nome sembri descrivere un placeholder altrettanto generico, non gode della stessa protezione. Il problema riguarda quindi un’intera classe di stringhe utilizzate abitualmente negli esempi: yourcompany.com, mycompany.com, your-api.com e nomi simili possono sembrare simbolici ma restano domini reali, registrabili e trasferibili.
La mitigazione non consiste soltanto nell’aggiungere third-party.com a una blocklist. Gli sviluppatori devono eliminare dai test, README, skill e configurazioni i placeholder non riservati, mentre le organizzazioni che mantengono cataloghi di agenti o server MCP devono verificare quali domini esterni siano realmente controllati dai soggetti citati. Una allowlist basata sulla reputazione storica è particolarmente pericolosa: il fatto che un dominio sia stato innocuo per anni non garantisce ciò che servirà domani. È lo stesso problema che rende insidiose le campagne ClickFix basate su infrastrutture considerate affidabili e servizi legittimi.
Continua con:
- FakeGit sfrutta migliaia di repository e AI Skills per consegnare malware
- 292 repository GitHub falsi diffondono BoryptGrab attraverso progetti contraffatti
La sicurezza deve verificare ciò che un URL serve a runtime, non ciò che significava ieri
Il caso third-party.com espone un limite profondo dei controlli statici applicati alle nuove supply chain agentiche: analizzare il testo di una skill non basta se quella skill contiene puntatori verso risorse che possono cambiare indipendentemente dal file. Anche risolvere il dominio una sola volta non è sufficiente quando il server applica cloaking e restituisce contenuti diversi in base al sistema operativo, alla rete o al profilo del visitatore. La verifica deve quindi spostarsi verso il runtime, osservando quali URL vengono realmente raggiunti, quali processi vengono avviati dopo la navigazione, se il browser modifica gli appunti e se da una pagina apparentemente informativa nasce improvvisamente powershell.exe. Per gli agenti AI il principio è ancora più importante: documentazione, skill e configurazioni non sono semplicemente testo da leggere, ma potenziali istruzioni operative che collegano il modello a risorse esterne mutevoli. Il fallimento non nasce da una dipendenza aggiornata male: nasce da una dipendenza che nessuno aveva mai riconosciuto come tale.
Iscriviti alla Newsletter
Non perdere le analisi settimanali: Entra nella Matrice Digitale.
Matrice Digitale partecipa al Programma Affiliazione Amazon EU. In qualità di Affiliato Amazon, ricevo un guadagno dagli acquisti idonei. Questo non influenza i prezzi per te.
