Gli hacker crypto vengono spesso discussi come se svolgessero tutti lo stesso lavoro, distinguendosi solo per le motivazioni. In pratica, il confine tra un ricercatore di sicurezza whitehat e un aggressore blackhat è definito tanto dall'autorizzazione, dall'ambito e da ciò che accade infine ai fondi quanto dalle competenze tecniche. Entrambi possono comprendere a livello esperto smart contract, bridge, wallet, validatori, chiavi private e logica di protocollo. Ciò che li separa è il modo in cui tale competenza viene applicata.

Gli hacker whitehat cercano vulnerabilità affinché possano essere corrette prima che gli utenti perdano denaro. I blackhat sfruttano le debolezze per furto, estorsione, manipolazione del mercato, accesso a informazioni private o controllo sull'infrastruttura. Il crypto complica questa distinzione perché un whitehat in situazioni di emergenza può talvolta spostare fondi vulnerabili durante un attacco in corso, mentre un blackhat può in seguito restituire gli asset rubati e chiedere di trattenere parte del bottino come ricompensa.

Quella zona grigia è diventata sempre più visibile man mano che i protocolli DeFi detengono grandi pool di asset in codice che chiunque può ispezionare. Monitoraggi di settore come i rapporti annuali sul crimine crypto di Chainalysis hanno registrato ben oltre un miliardo di dollari rubati dalle piattaforme crypto in ciascuno degli ultimi anni, mantenendo al centro dei dibattiti sulla sicurezza la questione di chi testa un protocollo — e a quali condizioni. Comprendere la differenza richiede di guardare oltre l'etichetta che un hacker si attribuisce e chiedersi se l'attività fosse autorizzata, se gli utenti siano stati messi a rischio e se esistessero termini di bounty prima che i fondi venissero spostati.

Cos'è un hacker crypto whitehat?

Un hacker crypto whitehat è un ricercatore di sicurezza che trova debolezze e opera nell'ambito di un processo autorizzato di divulgazione o recupero. I loro obiettivi possono includere smart contract, bridge, wallet, infrastrutture di exchange, frontend, API, sistemi di validatori, configurazioni multisig e altri componenti in grado di esporre asset digitali.

La maggior parte del lavoro whitehat avviene prima di un exploit. Un progetto pubblica un bug bounty crypto con obiettivi, esclusioni, livelli di gravità, regole di segnalazione e limiti di pagamento definiti. I ricercatori ispezionano il codice, riproducono una vulnerabilità in sicurezza, inviano le prove privatamente e concedono al team il tempo di correggerla.

Il ricercatore non deve impossessarsi di denaro reale per dimostrare l'esistenza del bug. Le principali piattaforme di bounty Web3 richiedono generalmente proof of concept, vietando al contempo test che mettano a rischio contratti attivi, reti pubbliche, utenti o sistemi di terze parti. Le attuali regole whitehat di Immunefi, ad esempio, vietano i test sui contratti mainnet e testnet pubblici secondo il proprio framework predefinito. Piattaforme come Immunefi, Sherlock, Code4rena e Hats Finance hanno reso questo processo una componente standard della preparazione al lancio dei protocolli, gestendo audit competitivi e bounty continui accanto alle tradizionali revisioni di sicurezza.

La caccia tecnica ai bounty è quindi più vicina a un'assicurazione di qualità avversaria che a un furto autorizzato. I ricercatori pensano come aggressori, ma il lavoro rimane entro i confini stabiliti dal progetto. Chi è interessato a questo percorso può passare dai bounty generali alla ricerca di sicurezza attraverso un percorso strutturato di crypto bounty hunter basato su test sicuri, prove e divulgazione responsabile.

Cos'è un hacker crypto blackhat?

Un hacker blackhat sfrutta un sistema senza permesso e per uno scopo che danneggia il proprietario o gli utenti. Nel crypto, l'obiettivo è spesso il diretto guadagno finanziario, perché smart contract, bridge, exchange e wallet possono detenere asset trasferibili entro pochi minuti da una compromissione riuscita.

Gli attacchi blackhat non seguono un unico schema tecnico. Un aggressore di smart contract può sfruttare una contabilità difettosa, controlli di accesso, presupposti sugli oracoli, reentrancy o un errore logico. Altri gruppi compromettono chiavi private, manipolano dipendenti tramite social engineering, prendono il controllo dell'infrastruttura di sviluppo, avvelenano dipendenze software o attaccano i sistemi operativi attorno a un protocollo anziché i suoi contratti.

Gli aggressori rivolti agli utenti scelgono spesso una strada più semplice. I drainer di wallet crypto possono imitare mint legittimi, airdrop, pagine di staking o portali di supporto e convincere una vittima a firmare una transazione pericolosa. Alcuni attacchi si basano su approvazioni malevole di token che danno a un aggressore il permesso di spostare asset in un secondo momento senza mai conoscere la seed phrase.

Una volta che gli asset sono sotto il controllo dell'aggressore, inizia la seconda fase. I fondi possono essere suddivisi tra wallet, convertiti in asset più liquidi, trasferiti tra chain tramite bridge, instradati tramite exchange decentralizzati o inviati verso servizi che rendono più difficile l'attribuzione. Le blockchain pubbliche espongono gran parte di questi movimenti, ma le transazioni on-chain visibili non rivelano automaticamente chi controlla un indirizzo. Le società di analisi blockchain e i team di sicurezza tracciano regolarmente questi flussi e hanno permesso sequestri da parte delle forze dell'ordine in casi importanti, motivo per cui i rientri negoziati sono diventati una caratteristica ricorrente dei grandi incidenti.

Whitehat vs blackhat: hacker crypto a confronto

I metodi tecnici possono sovrapporsi quasi completamente. Un whitehat e un blackhat possono notare lo stesso difetto contabile e costruire una proof of concept quasi identica. La differenza emerge in ciò che sono autorizzati a fare con quella conoscenza e in come si comportano una volta confermata la vulnerabilità.

Per questo un progetto con una solida sicurezza degli smart contract ha comunque bisogno di canali di divulgazione chiari e procedure per gli incidenti. Gli audit possono tralasciare bug, le integrazioni possono cambiare e nuove condizioni economiche possono esporre presupposti innocui al momento del lancio del sistema.

Come operano gli hacker whitehat

La ricerca whitehat di solito inizia dall'ambito. Il ricercatore identifica quali contratti, domini, app o infrastrutture sono idonei, poi studia come asset e permessi si muovono nel sistema. In DeFi ciò può significare tracciare depositi, prelievi, logica di liquidazione, dipendenze dagli oracoli, percorsi di aggiornamento, privilegi di amministrazione e chiamate tra contratti.

Un bug promettente viene riprodotto in un ambiente controllato. Il ricercatore documenta le condizioni necessarie per attivarlo, l'impatto probabile, gli asset interessati e una proof of concept sicura. Un buon invio fornisce agli ingegneri informazioni sufficienti per riprodurre il problema senza costringere il ricercatore a dimostrarlo contro utenti reali.

Dopo la valutazione, il progetto decide se la segnalazione è valida, quanto è grave e rientra nei termini del bounty. Il pagamento dipende dal programma. Una vulnerabilità critica in grado di svuotare un protocollo può fruttare molto più di un problema frontend a basso impatto, mentre segnalazioni duplicate o fuori ambito possono non ricevere nulla. Le segnalazioni critiche di livello più alto sulle principali piattaforme hanno storicamente pagato milioni di dollari, a riflettere la scala delle perdite che un singolo bug può causare.

Come operano gli hacker blackhat

Anche i blackhat iniziano con ricognizione, ma non esiste un confine contrattuale attorno a ciò che possono esplorare. Possono ispezionare codice pubblico, osservare aggiornamenti di governance, studiare i partecipanti a multisig, cercare credenziali trapelate, monitorare wallet privilegiati, mappare identità di dipendenti e testare dipendenze esterne finché non trovano il punto più debole.

Alcuni dei più grandi hack crypto della storia non derivano da fallimenti di crittografia esotica. La compromissione di chiavi private, debolezze dei bridge, il controllo dei validatori, errori negli smart contract e fallimenti nella sicurezza operativa hanno tutti prodotto perdite dell'ordine di centinaia di milioni di dollari. Casi come gli episodi del Ronin Bridge e di Cross River (Euler Finance) hanno seguito percorsi tecnici molto diversi, a sottolineare che la superficie d'attacco comprende persone e infrastruttura tanto quanto il codice.

L'esecuzione è normalmente progettata attorno alla velocità. Una volta sfruttata una debolezza, un aggressore potrebbe dover svuotare diversi contratti, impossessarsi di collateral, alterare un price feed, mintare asset privi di copertura o spostare fondi prima che i manutentori possano mettere in pausa il sistema. L'aggressore affronta poi un problema diverso: trasformare transazioni on-chain trasparenti in asset che possano essere detenuti o spesi senza essere recuperati o congelati.

Perché alcuni whitehat attaccano prima e trattengono un bounty?

Due situazioni molto diverse vengono spesso confuse sotto questa domanda.

La prima è un autentico salvataggio di emergenza. Un exploit è già in corso, il protocollo ha pre-autorizzato l'intervento e un altro ricercatore di sicurezza sposta gli asset vulnerabili prima che il blackhat possa impossessarsene. Il framework SEAL Whitehat Safe Harbor esiste proprio per questo scenario. I protocolli partecipanti definiscono asset protetti, indirizzi di recupero, requisiti di identità e termini di bounty prima che si verifichi un incidente. Un whitehat può quindi intervenire durante un exploit attivo e restituire i fondi salvati secondo quelle condizioni pubblicate.

Alcune configurazioni Safe Harbor permettono persino al whitehat di trattenere direttamente il bounty consentito prima di restituire il saldo. Non è la stessa cosa che prendere il denaro prima e inventarsi una ricompensa dopo: l'autorità e la formula di pagamento esistono già.

La seconda situazione inizia con un exploit non autorizzato. L'aggressore sottrae asset, in seguito dichiara di essere un whitehat, si offre di restituire la maggior parte dei fondi e chiede di trattenere una percentuale. Un progetto può accettare l'accordo perché recuperare il 90% è meglio che non recuperare nulla, ma un accordo post-exploit non rende retroattivamente autorizzato l'attacco originale come bug bounty.

Il recente recupero della Liquid Network mostra quanto possa diventare sottile quella linea. Whitehat autoproclamati hanno prelevato quasi 4.000 BTC, hanno chiesto a Blockstream di correggere la falla e in seguito hanno restituito 3.400 BTC dopo negoziazioni on-chain. Circa 598,5 BTC sono rimasti sotto il loro controllo all'8 settembre. Nessun accordo reso pubblico aveva stabilito quel residuo come bounty approvato, quindi descriverlo come ricompensa whitehat confermata andrebbe oltre ciò che i fatti disponibili supportano.

Definirsi whitehat è quindi privo di significato senza l'autorizzazione circostante. Un autentico framework di salvataggio richiede l'indipendenza dall'aggressore originale, una minaccia attiva, il rispetto delle regole del protocollo e la restituzione dei fondi secondo il processo concordato. Iniziare personalmente l'exploit esce da quella protezione.

Un blackhat può diventare whitehat restituendo il denaro?

Restituire i fondi rubati può ridurre le perdite e portare a un accordo negoziato, ma non cambia automaticamente la natura dell'accesso originale. Un progetto può decidere di offrire un bounty dopo un exploit perché il recupero pratico è più prezioso di una lunga caccia, eppure l'accordo resta diverso dalla divulgazione responsabile o da un salvataggio pre-autorizzato.

I ricercatori che vogliono entrate legittime dai bounty non hanno bisogno di creare quell'ambiguità. I programmi formali offrono un percorso per segnalare vulnerabilità, stabilire la gravità e ricevere il pagamento senza prendere in custodia i fondi degli utenti. Il ricercatore viene pagato per la scoperta e le prove, non per tenere in ostaggio gli asset.

Perché il crypto ha bisogno degli hacker whitehat

I sistemi crypto sono bersagli attraenti perché il codice può controllare direttamente asset liquidi. Una vulnerabilità in un software ordinario può esporre dati o interrompere un servizio. Una vulnerabilità in un bridge, un mercato di lending o un wallet può trasformarsi nel trasferimento di milioni di dollari prima che un operatore umano possa reagire.

I whitehat aggiungono un livello avversario permanente attorno agli audit e ai team di sicurezza interni. Continuano a testare i presupposti dopo il lancio, esaminano nuove integrazioni e portano ricercatori indipendenti in sistemi i cui incentivi economici cambiano costantemente. I bug bounty da soli non rendono sicuro un protocollo, ma rendono più proficuo segnalare alcune vulnerabilità piuttosto che sfruttarle.

Verdetto finale

Gli hacker crypto whitehat e blackhat possono possedere le stesse capacità tecniche, studiare lo stesso codice e scoprire la stessa vulnerabilità. Li separano autorizzazione e condotta. I whitehat operano entro regole di divulgazione, bounty, audit o salvataggio pensate per proteggere gli utenti. I blackhat sfruttano i sistemi senza permesso e decidono poi se tenere, spostare, esigere un riscatto o restituire ciò che hanno preso.

I salvataggi whitehat di emergenza sono il caso insolito in cui spostare fondi attivi può essere legittimo, ma solo quando l'autorità e i termini di recupero esistono già. Un hacker che attacca prima e negozia poi un bounty può contribuire al recupero degli asset, ma non è la stessa cosa della ricerca whitehat responsabile.