Dopo un attacco informatico o una compromissione di wallet, il tempo è decisivo. Un’analisi on-chain strutturata consente di mappare rapidamente flussi sospetti, capire l’esposizione personale e impostare allarmi tempestivi. Servono strumenti affidabili, un metodo ripetibile e la disciplina di documentare ogni passaggio.
Questa guida pratica illustra un workflow passo-passo con blockchain explorer per Bitcoin (BTC), Ethereum (ETH) e BNB Smart Chain (BNB), affiancati da tool open-source per l’estrazione e la correlazione dei dati. Il risultato è una procedura che chiunque può adottare per verificare se e quanto i propri fondi siano stati toccati, dove si stiano muovendo e come impostare monitoraggi automatici.
Setup minimo: explorer pubblici e tool open-source
Per un’indagine rapida servono due livelli: consultazione pubblica e analisi locale. Per la consultazione, usare mempool.space (BTC), Etherscan o Blockscout (ETH, chain EVM) e BscScan o istanze Blockscout (BNB). Per l’analisi locale: BTC RPC Explorer (Bitcoin, open-source), Blockscout self-hosted (EVM), e piattaforme come GraphSense o BlockSci per arricchimento e clustering sperimentale. Laddove possibile, collegare un nodo (es. Bitcoin Core, Erigon/Geth, BSC node) migliora affidabilità e latenza.
Mantenere un foglio di lavoro con tre colonne: indirizzo, tag/nota, fonte. Ogni dato inserito deve riportare da dove proviene (screenshot/URL/API). Questa disciplina riduce errori di attribuzione e rende l’indagine auditabile se occorre condividerla con un exchange o un legale.
Concetti chiave: tag, cluster, bridge e mixer
I tag sono etichette associate a indirizzi o contratti (es. exchange, bridge). Sono utili ma non infallibili; trattarli come indicazioni, non come prove definitive. I cluster collegano più indirizzi a un singolo soggetto con euristiche (es. common-input ownership su BTC). Funzionano ma possono generare falsi positivi, specie dopo CoinJoin o tecniche di offuscamento.
I bridge spostano asset tra catene (es. hop tra ETH e BNB). Osservarli è cruciale: i fondi rubati spesso cambiano rete per confondere il tracciamento. I mixer (es. Tornado Cash su ETH; CoinJoin/Whirlpool su BTC) aumentano l’anonimato spezzando la tracciabilità. Rilevare un invio verso un mixer non prova l’identità dell’attaccante, ma segnala un rischio di recupero elevato e va marcato con priorità.
Workflow replicabile: dal primo indirizzo alla mappa dei flussi
-
Raccogli gli entry point. Elenca tutti gli indirizzi controllati (wallet personali/aziendali) e quelli sospetti visti in transazioni anomale. Aggiungi TXID e timestamp.
-
Verifica i saldi e gli ultimi movimenti su mempool.space (BTC), Blockscout/Etherscan (ETH), BscScan/Blockscout (BNB). Esporta CSV delle transactions dove possibile.
-
Arricchisci con tag. Cerca etichette pubbliche: contratti noti, exchange custodial, bridge, mixer. Segna il livello di confidenza (alto/medio/basso).
-
Individua cluster con GraphSense/BlockSci o euristiche visive (riuso di change su BTC, destinatari ripetuti su EVM). Segna le ipotesi come tali.
-
Mappa i passaggi critici: verso exchange KYC, ponte cross-chain, o mixer. Questi nodi determinano le prossime azioni (es. segnalazione a un exchange).
-
Imposta alert su indirizzi/contratti sensibili e soglie di importo, per reagire in tempo reale a nuovi movimenti.
Esempi pratici di query: BTC, ETH e BNB
Su Bitcoin, con Bitcoin Core e BTC RPC Explorer, è possibile interrogare TX e UTXO localmente. Esempio rapido via RPC: getrawtransaction <txid> true per decodificare input/output e annotare possibili change. Per cercare uscita verso un servizio noto, confrontare l’address con liste di tag interne al team o pubbliche mantenute su repository open-source.
Su Ethereum e BNB, un’istanza Blockscout espone API REST. Esempi: /api?module=account&action=txlist&address=<addr> per la cronologia; /api?module=account&action=tokentx&address=<addr> per i token transfers. Per riconoscere un mixer su ETH, verificare se il destinatario coincide con un pool di Tornado Cash; per un bridge su BNB/ETH, controllare eventi Deposit/Bridge nel contract log.
Alert automatici: script minimi e soglie intelligenti
Per BTC con nodo locale, uno script cron può interrogare periodicamente listtransactions sugli watch-only e inviare una notifica quando compaiono output verso indirizzi marcati. Su EVM, chiamate periodiche all’API Blockscout con txlist e tokentx possono cercare to corrispondenti a contratti di mixer/bridge. Usa soglie: avvisa per movimenti >= X, o per eventi Approval anomali su token sensibili.
Esempio di logica: se to ∈ {contratti mixer noti} allora livello alert = alto; se to ∈ {exchange KYC} allora generare anche il pacchetto prove (TXID, orario UTC, importi, hash di screenshot) da inviare al supporto. Gli alert vanno testati su un indirizzo sandbox prima della produzione.
Verificare l’esposizione personale post-incident
La domanda centrale è: quanto dei fondi compromessi tocca asset o controparti personali? Calcolare una matrice di esposizione in tre righe: 1) diretta (indirizzi propri compromessi), 2) indiretta (contratti dove si hanno posizioni: LP, staking), 3) terze parti (depositi su exchange/bridge). Incrociare i flussi sospetti con queste righe: se un TXID attraversa un pool dove si fornisce liquidità, segnare l’evento e stimare l’impatto su quota parte e slippage.
Per asset EVM, controllare approvazioni con Allowance checker su Blockscout: revocare Approval e impostare alert su nuovi Permit. Su BTC, passare gli indirizzi a watch-only e ridistribuire UTXO puliti in wallet isolati. Se i fondi toccano un exchange, aprire subito un ticket con i dati strutturati richiesti nei moduli AML.
L’ultimo passo ottimizza il tempo: creare un playbook riutilizzabile con i propri indirizzi, i contratti critici e le query API precompilate. Allegare un modello di segnalazione a exchange/bridge con campi già pronti (TXID, orari, indirizzi coinvolti, importi netti, link agli explorer). Questo riduce i minuti tra un nuovo movimento e l’azione concreta, aumentando la probabilità di blocco o tracciamento efficace.
