Un pachet npm malițios, deghizat în utilitar obișnuit de indexare de tip B-tree, a fost surprins rulând întregul lanț de atac direct din codul aplicației, nu din scripturile de instalare pe care se bazează încă majoritatea malware-ului npm. Pachetul — „indexed-btree” — a fost urmărit până la un singur cont de publicare, între timp eliminat, care a strâns milioane de descărcări în doar câteva săptămâni înainte ca pachetul și repository-ul GitHub asociat să fie retrase.
Ce s-a întâmplat
„indexed-btree” imita suficient de bine o bibliotecă B-tree legitimă încât să treacă neobservat la o privire superficială. În loc să ascundă comportamentul malițios într-un script preinstall sau postinstall — trucul clasic la momentul instalării — payload-ul era îngropat într-o metodă cu aspect normal, BTree.prototype.set(). Apelarea acestei metode încărca un fișier secundar care dezambala un loader obfuscat, de prim stagiu.
De acolo, malware-ul amprenta gazda, transmitea detalii către un canal Slack și un bot Telegram codificate direct în cod, și extrăgea fragmente criptate ale payload-ului următor dintr-un smart contract implementat pe rețeaua de test Sepolia — o tehnică numită EtherHiding, care folosește stocarea pe blockchain pentru a evita eliminarea. Etapele erau combinate local pentru a asambla payload-ul final, iar pachetul își ștergea apoi propriile artefacte malițioase pentru a elimina urmele declanșatorului.
Cercetătorii au identificat cel puțin zece pachete conexe, legate de aceeași operațiune de publicare, toate retrase între timp din registry: ordered-kv-index, btree-leaderboard, priority-slot-queue, btree-range-store, btree-core, btree-time-index, btree-lru-cache, neighbor-key-map, sliding-score-window și mutes-forge.
De ce contează
Această campanie se aliniază unei schimbări mai ample în ecosistemul npm. Modificările recente ale registry-ului blochează implicit execuția automată a scripturilor la momentul instalării — închizând astfel una dintre cele mai simple căi prin care malware-ul a călătorit istoric odată cu un npm install. „indexed-btree” arată că atacatorii nu au deloc nevoie de acest hook: dacă respectivul cod malițios arată pur și simplu ca logică obișnuită de bibliotecă, acesta rulează în momentul în care o funcție legitimă este apelată.
Tiparul nu este izolat. O campanie conexă, care vizează npm și alte registry-uri de pachete, urmărită separat, compromite conturi de maintainer și inserează payload-uri obfuscate direct în fișierele sursă — inclusiv puncte de intrare în alte limbaje — în loc să se bazeze pe un mecanism fix de livrare. În ambele campanii, firul comun este același: apărările la nivel de registry cresc costul atacului „ușor”, iar operatorii răspund adaptându-se, nu dispărând.
Ce e de făcut
- Auditați înainte de a face upgrade, nu după. Fixați versiunile dependențelor și analizați diferențele la actualizarea versiunilor pentru pachete cu creșteri bruște de descărcări sau date de publicare foarte recente — ambele au fost semnale de alarmă în acest caz.
- Nu vă bazați exclusiv pe blocarea scripturilor de instalare. Aceasta închide o singură cale; este nevoie și de monitorizarea comportamentului la runtime și de inspecția traficului de rețea ieșit în timpul CI/build pentru a detecta payload-uri declanșate de apeluri de funcții obișnuite.
- Fiți atenți la trafic ieșit neobișnuit, în special beacon-uri către platforme de mesagerie (Slack, Telegram) sau apeluri RPC blockchain neașteptate din procese de build sau aplicație — ambele sunt folosite tot mai des pentru a găzdui și retransmite etapele malware-ului tocmai pentru că sunt greu de eliminat.
- Tratați compromiterea conturilor de maintainer ca pe un risc de lanț de aprovizionare, nu doar ca pe o problemă de securitate a contului — conturile de publicare compromise reprezintă acum o cale principală de livrare pentru această clasă de atacuri.
Detectarea pe mai multe niveluri — înainte de instalare, în timpul execuției și după implementare — este singura abordare care ține pasul cu atacatori care își reorientează activ tactica în jurul fiecărui control nou.
