← Torna al blog

Antidetect gratuito da GitHub: come testare la build prima di utilizzare il proxy

Su GitHub ogni settimana escono "anti-detect gratuiti open-source", e nel 2026 i malintenzionati cloneranno i repository di tendenza in poche ore e inseriscono stealer e proxy-bot come GhostSocks. Controllo passo-passo: originale o clone, da dove proviene il binario, quale codice leggere, esecuzione in sandbox, verifica dell'impronta e quali proxy fornire al nuovo strumento.

📅6 ottobre 2026
Antidetect gratuito da GitHub: come testare la build prima di utilizzare il proxy

In autunno 2026, su GitHub appare quasi ogni settimana un nuovo "anti-detect open-source gratuito": un fork di Chromium con sostituzione dell'impronta, un gestore di profili, un wrapper per Playwright per agenti IA. La tentazione è comprensibile: un anti-detect a pagamento per 50-100 profili costa decine di dollari al mese, mentre qui è gratuito. Ma si cede a questo programma la cosa più preziosa: le credenziali dei proxy, i cookie degli account di lavoro, a volte l'accesso ai pannelli pubblicitari e ai portafogli. Di seguito, una verifica passo-passo che vale la pena seguire prima che il primo profilo veda i vostri proxy.

Perché non è paranoia: cosa sta succedendo su GitHub nel 2026

GitHub quest'anno è diventato un canale di distribuzione di malware a tutti gli effetti. Diverse campagne documentate mostrano come appare in pratica:

  • Cloni di progetti popolari. Operazione SmartLoader + StealC: 109 repository falsi su 103 account. I malintenzionati copiavano la struttura e il README dei veri progetti, mentre al posto dei sorgenti mettevano un pulsante "scarica ZIP" con un loader e un infostiler. La campagna è durata più di sette settimane.
  • Velocità di reazione. I repository falsi di DeepSeek TUI sono apparsi entro quattro ore dall'annuncio ufficiale dello strumento. Tutto ciò che è di tendenza viene clonato quasi istantaneamente.
  • Codice nascosto. La campagna GlassWorm (433+ componenti infetti su GitHub, npm, VS Code Marketplace e OpenVSX) nascondeva la logica malevola in caratteri Unicode invisibili, che non sono visibili durante una normale visualizzazione del diff.
  • Proxy-bot incluso. Nella falsa "fuga" di Claude Code e nelle contraffazioni di DeepSeek TUI, insieme allo stiler Vidar, veniva installato GhostSocks: un malware che trasforma il computer della vittima in un proxy SOCKS5.

L'ultimo punto è particolarmente sgradevole per il nostro pubblico. GhostSocks, secondo Infrawatch, si diffonde in combinazione con lo stiler LummaC2 e viene venduto come servizio: crea un tunnel in TLS e fornisce all'affittuario un "IP" domestico "pulito" della macchina infetta. Ciò significa che un anti-detect "gratuito" può non solo rubare i vostri account, ma anche trasformare il vostro stesso IP in un nodo di uscita di un botnet altrui. Dopo un paio di settimane, vi chiederete perché il vostro indirizzo di casa sia finito nelle banche dati di spam.

Come si differenziano gli anti-detect open-source

Prima di controllare una build specifica, è utile capire a quale tipo appartiene: da questo dipende cosa esattamente controllare.

  • Patch a livello di motore. Esempio: Camoufox: una build di Firefox in cui l'impronta (navigator, schermo, WebGL, font, fuso orario, WebRTC) viene sostituita nel codice C++, e non tramite iniezione JS. Il repository ufficiale è daijro/camoufox, il pacchetto su PyPI si chiama camoufox. Dettaglio importante: secondo il progetto stesso, il codice sorgente è diventato completamente aperto solo a partire dalla versione v146; nelle versioni v135.0.1-beta.24 e inferiori c'erano componenti chiusi. Nel 2026, il progetto ha avuto una lunga pausa nel supporto, e gli analisti di Centinel hanno rilevato Camoufox nel benchmark di settembre.
  • Wrapper sopra Chrome normale. undetected-chromedriver, modalità UC in SeleniumBase. Di per sé sono trasparenti, ma contro Cloudflare, DataDome e Kasada funzionano sempre peggio: modificano principalmente il layer JavaScript.
  • Nuovi fork di Chromium con binari pronti. Il gruppo più rischioso: un progetto con alcune decine di stelle, che offre di scaricare un .exe o .dmg di oltre 200 MB. Verificare che il binario sia effettivamente costruito dal codice pubblicato non è possibile per un utente comune.

Verifica passo-passo prima dell'installazione

Passo 1. Assicurati che sia l'originale, non un clone

  1. Trova il progetto dal sito ufficiale o dalla documentazione, non dalla ricerca su GitHub. I cloni spesso hanno lo stesso nome e una copia del README.
  2. Confronta la data di creazione del repository, il numero di commit e autori. Un clone è solitamente stato creato di recente, con 1-3 commit ("Initial commit", "Update README"), e le stelle sono gonfiate in pochi giorni.
  3. Guarda le Issues e le Discussions. Un progetto vivo ha report di bug da diverse persone e risposte del maintainer. Issues chiuse in un progetto "popolare" sono un segnale rosso.
  4. I fork del tipo random-nick/camoufox non sono equivalenti all'originale, anche se nella descrizione è indicato "official".

Passo 2. Controlla da dove proviene il binario

  1. Il link per il download deve portare alla scheda Releases dello stesso repository, non a un file sharing, Google Drive o "mirror" nel README. Il pulsante "Download ZIP" nella descrizione è proprio quel trucco della campagna SmartLoader.
  2. Controlla se il rilascio viene costruito tramite GitHub Actions dal codice pubblico. C'è un workflow di costruzione, i tag coincidono? Se il progetto pubblica attestazioni di costruzione, controllale con il comando gh attestation verify.
  3. Confronta il checksum del file (SHA-256) con quello indicato nel rilascio. Se i checksum non sono indicati, è un motivo per insospettirsi, non per saltare il passo.
  4. Carica il file su VirusTotal. Zero rilevamenti non garantisce nulla: i nuovi stiler sono spesso puliti nei primi giorni. Ma rilevamenti con etichette stealer, Lumma, Vidar o proxy sono un motivo per fermarsi subito.

Passo 3. Leggi il codice dove si nascondono le sorprese

Non è necessario leggere tutto Chromium. È sufficiente controllare i punti attraverso i quali il programma accede alla rete e avvia qualcosa:

  • script di installazione e post-installazione (postinstall in package.json, setup.py, install.sh, script PowerShell);
  • modulo "aggiornamenti" e "telemetria": dove vanno le richieste e cosa viene trasmesso;
  • qualsiasi richiesta a URL esterni, stringhe base64, caricamento di codice da un indirizzo remoto e la sua esecuzione;
  • caratteri invisibili: esegui i sorgenti attraverso una ricerca di caratteri non ASCII. È proprio così che si nascondeva GlassWorm.

Se il progetto è un "launcher" che scarica il motore dal proprio server al primo avvio, i sorgenti del launcher dicono quasi nulla su cosa avrai sul disco.

Passo 4. Primo avvio — solo in sandbox

  1. Avvia il programma in una macchina virtuale separata o su un VPS pulito senza i tuoi dati di lavoro.
  2. Non collegare proxy e account di lavoro. Per il primo test, basta un proxy di prova con un volume di traffico ridotto.
  3. Controlla le connessioni di rete del processo (Little Snitch, Wireshark, netstat/ss). L'anti-detect ha bisogno di connessioni ai siti che apri e al tuo proxy. Connessioni costanti a IP e porte sconosciuti, specialmente connessioni TLS in entrata o "appese" a un unico indirizzo, sono un segnale di un backdoor o di un proxy-bot.
  4. Controlla l'avvio automatico e il pianificatore delle attività dopo l'installazione: sono apparse nuove service, attività cron o LaunchAgents che non hai installato.

Passo 5. Controlla che l'impronta stessa non ti tradisca

Un anti-detect onesto, ma scadente è comunque pericoloso — semplicemente in modo diverso: gli account vengono bannati a causa di incongruenze. Esegui il profilo attraverso diversi checker e controlla assolutamente le perdite di rete. L'ordine dettagliato l'abbiamo trattato nel materiale "Perdite WebRTC e DNS: 7 controlli prima di accedere al profilo". Il minimo per qualsiasi nuova build:

  • WebRTC non restituisce l'IP locale e quello esterno reale, solo l'IP del proxy;
  • Le richieste DNS passano attraverso il proxy, non attraverso il provider;
  • Il fuso orario, la lingua e la geolocalizzazione coincidono con il paese del proxy;
  • User-Agent e Client Hints corrispondono alla reale versione del motore (un fork di Chromium 151 che si presenta come Chrome 153 viene catturato subito).

Insidie che si dimenticano

  • Licenza. "Codice aperto" non significa sempre "può essere usato per affari". Ad esempio, Damru ha una licenza PolyForm Noncommercial: l'uso commerciale non è consentito.
  • Progetti abbandonati. Un anti-detect senza aggiornamenti invecchia in pochi mesi: la versione base del browser è obsoleta, i detector imparano dai suoi artefatti. La storia di Camoufox mostra che anche un progetto forte può uscire dalla corsa per un anno.
  • Sincronizzazione dei profili "in cloud". Se una build gratuita offre archiviazione cloud dei profili, i vostri cookie e password dei proxy sono su un server di terzi. Scopri di chi si tratta.
  • Chiavi e password dei proxy in chiaro. Molti gestori fai-da-te memorizzano le credenziali dei proxy in JSON non crittografato accanto al profilo. Lo stiler li prenderà per primi.
  • Anti-detect a pagamento hackerati. "Craccati" Multilogin, Dolphin e simili sono una classica trappola per stiler. È peggio di qualsiasi open-source: il codice non esiste affatto, e il distributore sa in anticipo che la vittima lavora con account.

Quali proxy dare a un nuovo anti-detect

Dividi il test e il lavoro. Nella fase di verifica, utilizza un proxy separato con un volume minimo di traffico residuo: se la build risulta malevola, perderai pochi centesimi, non un pool di lavoro. Per profili di produzione, sono necessari proxy che non rovinino l'impronta: i proxy residenziali forniscono IP di provider domestici e sono adatti per la maggior parte degli scenari di multi-accounting, mentre per i social e i pannelli pubblicitari con un forte anti-frode funzionano meglio i proxy mobili con indirizzi degli operatori di telecomunicazioni.

Regola separata: per ogni nuovo strumento — il proprio sub-account o il proprio login proxy. Se il programma si rivela "con sorpresa", cambierai solo una password e non dovrai ricordare dove hai inserito quella comune. Lo stesso principio di isolamento dei segreti ha salvato i team da campagne come Flooding Dropper in npm, che cacciavano proprio le credenziali dei proxy delle squadre di scraping.

Breve checklist

  1. Ho trovato il progetto attraverso il sito ufficiale, non tramite ricerca; non è un clone né un fork casuale.
  2. Il binario è presente in Releases, costruito in CI, il checksum coincide.
  3. Ho controllato gli script di installazione, aggiornamenti e telemetria, cercato caratteri invisibili.
  4. Primo avvio — in una macchina virtuale, con un proxy di prova, sotto osservazione della rete e dell'avvio automatico.
  5. L'impronta ha superato i controlli WebRTC, DNS, fuso orario e Client Hints.
  6. La licenza consente il mio utilizzo, il progetto è stato aggiornato negli ultimi mesi.
  7. Per il nuovo strumento — login proxy separati.

Conclusione

Un anti-detect gratuito da GitHub può essere uno strumento eccellente, ma solo dopo una verifica. Nel 2026, gli aggressori clonano repository di tendenza in poche ore, nascondono codice in caratteri invisibili e inseriscono proxy-bot nei stiler, che trasformano il vostro computer in un nodo di uscita altrui. Mezz'ora per una verifica secondo la checklist costa meno di un set di cookie rubati da un pannello pubblicitario. E un proxy di test separato con un volume di traffico ridotto rende tale verifica quasi gratuita.