Il bug in un obfuscator JavaScript ha smascherato un phishing polymorphic

Il 27 agosto 2025, un handler del SANS Internet Storm Center ha raccolto e analizzato circa 56 campioni di una pagina di phishing che generava varianti uniche server-side per ogni singola richiesta. Un errore di scope nella variabile contatore k ha causato loop infiniti nel ~3.6% delle istanze, rendendo la pagina non funzionante e rivelando un meccanismo di obfuscation polymorphic che altrimenti sarebbe passato inosservato.

Come l'errore ha reso visibile l'invisibile

La pagina originale, caricata manualmente dall'analista, non funzionava. "Had the first page loaded normally, I would almost certainly have dismissed it as yet another run-of-the-mill phishing site", ha scritto l'autore nel diary SANS. Il malfunzionamento ha invece attivato un'analisi manuale che ha portato alla raccolta sistematica di 50 campioni aggiuntivi, tutti con SHA-256 distinti.

Il meccanismo di generazione polymorphic si estende oltre il wrapper JavaScript obfuscato. I 50 campioni presentavano 21 titoli di pagina diversi — tra cui "Solution", "Viewer", "Credentials", "Private", "Authenticate" — insieme a nomi di form e input, classi CSS, ID elementi, parametri immagine e zero-width characters variati. La fonte documenta che le trasformazioni sono "quite systematic", indicando un obfuscator convenzionale con random renaming e riordino funzioni, non un sistema basato su modelli linguistici di grandi dimensioni.

L'autore SANS ha esplicitamente escluso il coinvolgimento di LLM, nonostante l'esistenza di un proof-of-concept Unit 42 su phishing polymorphic generato via intelligenza artificiale. Il bug ricorrente di scope, compatibile con un meccanismo di random renaming che ignora la gestione delle variabili locali, è stato considerato prova decisiva di un approccio tradizionale.

Il meccanismo del loop: dalla variabile globale al blocco

Il nucleo del fallimento risiede in una variabile contatore k non dichiarata localmente, condivisa tra la funzione di decodifica esterna e il helper interno _YF. Il loop esterno itera da 0 a 63; quando _YF(47,47) imposta k a 47, l'incremento interno porta il valore a 48, la condizione di uscita fallisce e la funzione ritorna con k=48. Il loop esterno incrementa a 49, ma la successiva chiamata a _ie() reinvoca _YF(47,47), che resetta k a 48. Il ciclo si ripete indefinitamente tra 48 e 49.

Questo comportamento produce un consumo del 100% di un core CPU per circa 30 secondi, seguito dal timeout del browser. La pagina non viene mai renderizzata completamente, frustrando l'obiettivo del credential harvesting. Il tasso di fallimento rilevato è di 2 pagine su ~56 campioni totali, ottenuti combinando le 50 richieste automatizzate con i tentativi manuali originali dell'autore.

Il fenomeno è probabilistico: la pagina originale caricata dall'analista era "rotta", mentre i successivi caricamenti manuali funzionavano. Questa non determinicità, propria del meccanismo polymorphic, rende il malfunzionamento intermittente e quindi più difficile da diagnosticare per le vittime.

"The obfuscation mechanism intended to make the page more difficult to detect was also capable of making it somewhat ineffective at stealing credentials" — SANS Internet Storm Center

Cosa fare adesso

Per i team di sicurezza aziendale, il caso impone tre azioni concrete. Primo: integrare nei playbook di analisi malware la raccolta sistematica di multipli campioni dallo stesso URL, non singoli download. L'autore SANS ha ottenuto 50 hash diversi da 50 richieste consecutive; la detection basata su un solo campione avrebbe registrato 50 firme distinte senza correlarle.

Secondo: configurare i sandbox di analisi dinamica per segnalare loop JavaScript con consumo CPU sostenuto oltre 10 secondi, non solo esecuzioni completate. Il loop infinito tra i valori 48 e 49 della variabile k ha generato un profilo comportamentale riproducibile — 100% core CPU per ~30 secondi — identificabile come anomalia anche senza deobfuscation manuale.

Terzo: verificare che i filtri anti-phishing in ingresso non si affidino esclusivamente a hash statici o pattern di titoli HTML. I 21 titoli diversi e gli SHA-256 unici per ogni richiesta rendono inefficaci le blacklist basate su firme semplici; la detection deve privilegiare struttura DOM, comportamento di rete e analisi dinamica del JavaScript.

Per i ricercatori, il caso conferma che i campioni "rotti" — pagine che non renderizzano o che generano errori — meritano la stessa attenzione di quelli funzionanti. L'errore di scope ha esposto l'intero meccanismo polymorphic che nelle 49 varianti su 50 funzionanti sarebbe rimasto invisibile.

Domande e risposte

Il tasso di fallimento del 3.6% è rappresentativo della popolazione reale di vittime?

No. Il 3.6% si riferisce a ~56 campioni raccolti dall'analista in condizioni controllate (50 richieste automatizzate più tentativi manuali). La fonte non fornisce dati sul tasso di fallimento nella popolazione reale di vittime, che dipende da fattori non documentati come distribuzione geografica, fingerprinting del browser, o eventuali logiche di targeting server-side.

Perché l'autore esclude l'uso di LLM nonostante il proof-of-concept Unit 42?

L'autore SANS sostiene che le trasformazioni osservate sono "quite systematic" e che il bug ricorrente di scope "fit quite nicely with a relatively simple random renaming and reordering mechanism which doesn't properly account for variable scope". Un sistema LLM, secondo la valutazione dell'autore, non avrebbe generato un errore di programmazione così specifico e ripetitivo nella struttura del codice.

Il payload finale della pagina è tecnicamente sofisticato?

La fonte lo descrive esplicitamente come "completely unremarkable credential-stealing page". La sofisticazione risiede interamente nel meccanismo di delivery e obfuscation, non nel payload di harvesting, che rappresenta una forma standard di raccolta credenziali senza elementi distintivi avanzati.

Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.

Fonti

• https://isc.sans.edu/diary/rss/33290
• https://www.akamai.com/blog/security/the-tale-of-double-javascript-obfuscated-scam
• https://unit42.paloaltonetworks.com/real-time-malicious-javascript-through-llms/
• https://link.springer.com/chapter/10.1007/978-3-642-02617-1_28