Malware assemblato nel browser: SourTrade batte gli hash

Quasi ogni controllo di detection nel vostro stack risponde a una domanda che riguarda un file. Questo hash è noto come malevolo? Questo binario è firmato? Questo artefatto è già stato visto da qualcuno, da qualche parte? Il modello ha retto per trent'anni perché poggiava su un presupposto mai discusso: a un certo punto il malware esiste come file, e a un certo punto quel file attraversa un confine ispezionabile.

Il 23 luglio 2026 la società di ad-security Confiant ha pubblicato l'analisi di un cluster di malvertising che traccia come SourTrade, e quel presupposto non sopravvive. La campagna non consegna mai un eseguibile malevolo. Ne consegna uno pulito, più una ricetta, e lascia che sia il browser della vittima a fare l'assemblaggio. BleepingComputer e The Hacker News l'hanno ripresa il 25 luglio. Michael Steele, del team di threat intelligence di Confiant, riassume la conseguenza in una frase:

"Nessun malware finito esiste mai sulla rete."

Non è una battuta da comunicato stampa. È un'affermazione precisa su dove si trovano i vostri punti di ispezione, e va presa alla lettera.

Come si costruisce il malware assemblato nel browser, fase per fase

La catena di consegna ha quattro fasi, e nessuna di esse, presa singolarmente, somiglia a un attacco.

Fase 1 — il download manager. La landing page (raggiunta tramite un annuncio a pagamento che imita TradingView, Solana o Luno) registra un ServiceWorker su /sw.js. Il compito del worker non è la persistenza in senso malware: serve a intercettare le fetch same-origin e a mantenere in memoria uno stream di download. La pagina istanzia inoltre uno SharedWorker da JavaScript incorporato direttamente nella pagina, evitando una fetch separata che uno scanner potrebbe seguire.

Fase 2 — la ricetta. Lo SharedWorker interroga /config. Il server non restituisce un payload: restituisce istruzioni di build. Un seed casuale specifico per la sessione, un valore di dimensione, uno standaloneUrl e un array template che descrive operazioni di copia byte a byte.

Fase 3 — assemblaggio nel browser della vittima. Il browser scarica e decomprime un runtime Bun legittimo e pulito da standaloneUrl — un secondo dominio, senza relazione con la landing page. Genera poi uno stream pseudocasuale per-vittima con AES-CTR a partire dal seed fornito dal server, e percorre il template combinando quattro ingredienti:

• il motore interprete Bun pulito
• header PE e section table consegnati dal server
• i byte pseudocasuali generati localmente
• una sezione PE .bun controllata dall'attaccante, contenente bytecode JavaScriptCore malevolo

È il design stesso di Bun (--compile incorpora il bytecode in una sezione .bun di un runtime standalone) a rendere possibile tutto questo. L'attaccante non sta aggirando il runtime: lo usa esattamente come documentato, con bytecode proprio.

Fase 4 — consegna same-origin. Lo stream assemblato passa al ServiceWorker e un iframe nascosto naviga verso una URL same-origin, innescando un download con content-type binario generico. Poiché è stato il ServiceWorker a servirlo, il Mark of the Web registrato nell'alternate data stream Zone.Identifier indica come sorgente la landing page. L'host che ha fornito i componenti remoti non compare mai nel record di provenienza. Confiant nota che le varianti precedenti usavano il progetto pubblico StreamSaver su GitHub: il passaggio alla consegna same-origin via ServiceWorker è avvenuto dopo aprile 2026, e serve proprio a ripulire quella traccia.

Perché il malware assemblato nel browser manda in crisi il rilevamento basato su hash

Vale la pena percorrere ciò che ciascun controllo riesce davvero a vedere.

Controllo	Cosa osserva	Verdetto
AV di rete / ispezione TLS	Un runtime Bun legittimo, gzippato, da un host inconsueto	Pulito — perché è pulito
Feed di hash / IOC	Un file mai visto prima, e mai più rivisto dopo	Nessun match
Detonazione in sandbox della landing page	Una pagina bianca, se il cloaker vi profila come scanner	Nulla
Revisione di provenienza (MotW)	Il dominio della landing page come origine	Coerente, e sbagliato
SmartScreen / reputazione	Un binario non firmato con reputazione zero	Scatta
Analisi comportamentale dell'egress	L'intera sequenza multi-host di fetch e assemblaggio	Visibile

Il passaggio AES-CTR è quello portante: garantisce che ogni vittima riceva un eseguibile diverso byte per byte, quindi un hash è un fatto relativo a una sola infezione e a nient'altro. Confiant è esplicita: "Ogni vittima può ricevere un file assemblato diverso, il che limita il valore delle semplici detection basate su hash."

Il kit di cloaking chiude l'altra porta. Analisti, scanner e bot di sicurezza vengono dirottati su pagine vuote; solo le vittime profilate vedono la replica del brand. I due modi più economici per ottenere un verdetto — sottomettere l'hash, detonare l'URL — restituiscono entrambi nulla, e lo fanno in silenzio, che è il modo di fallire peggiore. Un verdetto "pulito" prodotto da un controllo a cui l'artefatto non è mai stato mostrato è indistinguibile da un verdetto vero.

Due cose però continuano a funzionare, e vanno nominate perché il riflesso è pensare che non funzioni più niente. I controlli endpoint basati su reputazione qui mordono di più, non di meno: un PE non firmato e unico per sessione ha reputazione zero per costruzione, ed è esattamente ciò che SmartScreen e gli equivalenti sono progettati per segnalare. E la sequenza di rete — referral pubblicitario, landing page cloakata, /config con seed e size, un grosso runtime gzippato prelevato da un altro dominio, poi un download same-origin — è una forma, e la forma è identica su tutti gli oltre 90 domini presenti nel set di IOC di Confiant.

La linea di sangue: JSCEAL, WeevilProxy e 35.000 annunci

SourTrade è un cluster di distribuzione, non un payload nuovo. Il malware che costruisce si sovrappone a ciò che Check Point traccia come JSCEAL e WithSecure chiama WeevilProxy: una famiglia che installa un proxy locale per intercettare il traffico, raccoglie cookie e password salvate nei browser, registra i tasti premuti, cattura screenshot e svuota i wallet di criptovaluta.

La scala è documentata. Check Point Research fa risalire la campagna a marzo 2024 e ha contato, tra gennaio e giugno 2025, oltre 35.000 annunci malevoli erogati nella sola Unione Europea, per una stima di 3,5 milioni di impression, con l'imitazione di quasi 50 applicazioni di trading di criptovalute. La sintesi pubblicata da Check Point colloca l'esposizione globale probabile sopra i 10 milioni di utenti. L'analisi Bitdefender del 2025 sulla stessa famiglia di payload, citata da BleepingComputer, ha documentato le funzioni di intercettazione via proxy e di furto dei wallet.

Il targeting attuale rilevato da Confiant copre 12 paesi — Giappone, Thailandia, Corea del Sud, Taiwan, Hong Kong, Bolivia, Brasile, Nigeria, Turchia, Sudafrica, Australia e Regno Unito — con creatività pubblicitaria localizzata per ciascuno. Le landing page contengono logica di conversione di Google Ads, pixel Meta e tracciamento eventi di X/Twitter: il che dice una cosa scomoda, ossia che gli operatori fanno A/B testing sull'acquisizione delle vittime attraverso tre grandi ecosistemi pubblicitari, con la stessa strumentazione che userebbe un team di growth marketing.

Oggi è una campagna consumer sul mondo crypto. La tecnica non è specifica del consumer. Nessuna delle quattro fasi dipende dal fatto che l'esca sia un'app di trading, e nessuna dipende dal fatto che il payload sia un infostealer.

Remediation

Qui non c'è una patch: nessun CVE, nessuna versione corretta. Il componente vulnerabile è il presupposto che un file abbia un'identità stabile. Segue il runbook.

1. Sono impattato?

Si parte dalla provenienza, non dagli hash. Ogni eseguibile scaricato porta con sé un alternate data stream Zone.Identifier che registra da dove il browser crede che arrivi:

Get-ChildItem C:\Users\*\Downloads\*.exe -Force |
  ForEach-Object {
    $z = Get-Content $_.FullName -Stream Zone.Identifier -ErrorAction SilentlyContinue
    if ($z) { [PSCustomObject]@{ File = $_.FullName; Zone = ($z -join '; ') } }
  }

Guardate HostUrl e ReferrerUrl. In questa campagna indicheranno un dominio-replica dall'aspetto plausibile su .digital, .info, .club o .site — e, per via del trucco same-origin, saranno coerenti fra loro. È quella coerenza interna l'indizio, non un'incongruenza.

Poi cercate nei log di proxy e DNS la sequenza, non le destinazioni:

• una GET /config (o equivalente fetch JSON di istruzioni di build) verso un dominio registrato di recente
• nella stessa sessione di navigazione, il download di un grosso binario gzippato da un host diverso
• subito dopo, un download same-origin di application/octet-stream dal primo host

Due elementi su tre nella stessa sessione meritano un'occhiata. Tutti e tre sono un incidente.

2. Non c'è patch: togliete il canale di consegna

• Policy di download del browser. Chrome ed Edge espongono entrambi DownloadRestrictions: impostatelo per bloccare i download eseguibili pericolosi o tutti, per le popolazioni di utenti standard. È il singolo controllo con la resa più alta contro l'intera classe di tecnica.
• Application control. Regole WDAC o AppLocker che bloccano PE non firmati o con firma non valida in esecuzione da %USERPROFILE%\Downloads e %LOCALAPPDATA%\Temp fermano il binario assemblato a prescindere dal suo contenuto: l'assemblaggio invalida qualunque firma il runtime pulito portasse con sé.
• Tenete accesi i controlli di reputazione. SmartScreen e affini sono l'unico controllo endpoint che l'hash unico per sessione rende più forte. Non lasciate che un ticket del tipo "troppi popup" li faccia disattivare.
• Blocco dello strato pubblicitario sul DNS. Non è una panacea, ma il referral iniziale è un annuncio a pagamento. Bloccare la risoluzione dell'ad-tech sugli endpoint gestiti elimina la fase zero.

3. Non potete toccare le policy del browser adesso?

Bloccate sul resolver i pattern di TLD di registrazione recente che la campagna predilige, allertate su qualunque endpoint che scarichi un binario gzippato di diversi megabyte da un dominio senza storia organizzativa, e — specificamente per i team finance, tesoreria e crypto-adiacenti — diffondete un avviso mirato: il software di trading e i wallet si installano solo dai siti dei produttori, mai da un risultato di ricerca sponsorizzato.

4. Caccia al compromesso

Confiant ha pubblicato tre hash SHA-256 dei payload e oltre 90 domini di malvertising. Usateli, ma sapendo cosa sono: gli hash identificano tre assemblaggi specifici e non corrisponderanno a una quarta vittima. I domini invecchiano.

I segnali comportamentali sono quelli durevoli:

Comportamento osservato	ATT&CK
Annuncio a pagamento come vettore di accesso iniziale	T1583.008 Malvertising
Landing page cloakata che consegna la catena	T1189 Drive-by Compromise
Runtime pulito scaricato come componente di build	T1105 Ingress Tool Transfer
Bytecode nella sezione .bun, riempimento AES-CTR	T1027 Obfuscated Files or Information
Assemblaggio client-side del PE finale	T1140 Deobfuscate/Decode Files or Information
Provenienza MotW riscritta come same-origin	T1553.005 (mappatura più vicina)
L'utente esegue l'installer assemblato	T1204.002 User Execution: Malicious File
Proxy locale per intercettazione del traffico	T1090 Proxy
Keylogging, screenshot	T1056.001, T1113
Furto di credenziali e cookie dai browser	T1555.003, T1539
Esfiltrazione verso l'infrastruttura dell'operatore	T1041

Sull'endpoint, cercate registrazioni di ServiceWorker su domini che nessun processo aziendale dovrebbe toccare, e processi derivati da Bun in esecuzione da percorsi scrivibili dall'utente dove non è previsto alcun tooling di sviluppo.

5. Bonifica e verifica

Rimuovere il binario è la metà facile. Il prodotto del payload sono credenziali e sessioni vive, quindi la bonifica non è completa finché non:

• revocate sessioni attive e refresh token per ogni identità usata sull'host — in Entra ID la revoca delle sessioni è un'azione distinta dal reset password, quindi fate entrambe
• resettate ogni credenziale salvata nei profili browser interessati, comprese quelle personali: chi raccoglie non rispetta il confine aziendale
• trattate come compromesso qualunque wallet di criptovaluta usato da quell'host e spostate i fondi su una chiave generata altrove
• verificate configurazioni di proxy locale e certificati root installati, lasciati dal componente di intercettazione
• controllate regole di posta, consensi OAuth e registrazioni MFA create durante e dopo la finestra di intrusione

Verificate dopo la revoca, non prima: i tentativi di riautenticazione con i vecchi token da reti inconsuete sono la conferma che le sessioni rubate erano vive e adesso sono morte.

Rilevare ciò che non ha identità stabile

La lettura onesta di SourTrade è che la primitiva di detection predefinita del settore — l'hash — è stata aggirata per costruzione, a costo bassissimo, usando API del browser documentate e un runtime legittimo. Ogni IOC del report Confiant è accurato, utile e usa e getta. Gli operatori possono ruotare tutti e novanta e passa i domini questa settimana senza cambiare nulla di come funziona la tecnica.

Ciò che non possono ruotare è la forma del traffico. La catena deve scaricare la ricetta, deve prelevare un runtime pesante da un secondo host, deve consegnare same-origin e — una volta in esecuzione — deve fare proxy, beacon ed esfiltrazione. È lo scenario per cui è costruita l'AI Traffic Analysis di Zero Hunt: un modello di deep learning proprietario addestrato su miliardi di sequenze PCAP, con quattro teste di inferenza parallele — traffico sospetto, classificazione malware, identificazione del tipo di attacco e fingerprinting applicativo — che gira sulla GPU dell'appliance, on-premise, senza alcuna callback verso il cloud. Qui la testa rilevante è il fingerprinting applicativo: non chiede se una destinazione sia in una blocklist, chiede che cosa sia quella sessione. Una workstation gestita che scarica un runtime JavaScript compresso da un dominio senza storia organizzativa, pochi istanti dopo un referral pubblicitario, è un evento riconoscibile che quel trasferimento sia malevolo o no — ed è lo stesso evento su ognuno di quegli oltre 90 domini.

La seconda metà è dimostrare che i vostri controlli reggono davvero. Molti team hanno DownloadRestrictions in un documento di policy e l'application control in un anello di pilot, e nessuna evidenza su cosa accada oggi su un endpoint reale. Lo swarm di pentest generativo a 10 agenti di Zero Hunt risponde su base empirica: gli agenti Web, Exploit e Post-Exploit eseguono una catena costruita per quell'ambiente dentro un container effimero e irrobustito con gVisor, e riportano se il percorso ha funzionato lì, con ogni finding firmato ECDSA e campagne change-triggered che rieseguono i test quando l'ambiente cambia.

Non si può fare l'hash di un file che è diverso per ogni vittima. Si può benissimo riconoscere la sequenza che lo costruisce.

Se volete vedere che aspetto ha tutto questo sul vostro egress, scriveteci — oppure leggete come è fatta la piattaforma.