Toate articolele

Noutăți26 octombrie 20265 min de citit

Viermele testmetest: payload de 13 MB în 42 de depozite GitHub

Viermele npm testmetest a armat 42 de depozite GitHub cu hook-uri pentru asistenți IA și payload-uri de 13 MB invizibile pentru căutarea de cod.

Mână care îndreaptă o seringă între tastele unui laptop

Campania npm numită testmetest, care părea un simplu test fără victime, armase de fapt deja 42 de depozite GitHub reale ale unui număr de 11 proprietari. A documentat-o JFrog Security Research într-un raport din 26 octombrie, preluat de The Register și CSO Online. Detaliul care face campania greu de găsit: fișierele cu payload au între 12,9 și 13,7 MB, peste limitele căutării de cod și ale API-ului de conținut al GitHub. Și heise Security a relatat știrea, dar textul său nu a fost disponibil pentru această analiză.

Acum câteva zile am scris despre Gheist, care folosește tokenuri GitHub furate pentru a extrage secretele din jurnalele Actions. testmetest este o campanie diferită: un vierme care se răspândește prin npm, fură credențiale și se ascunde în depozitele victimelor.

De la „test” la victime reale

Potrivit The Register, compania SafeDep a observat prima campania, cu 18 pachete npm publicate de același operator între 19 și 25 octombrie. În analiza din 22 octombrie, care decoda event-bus-lite-testmetest@0.0.1, SafeDep nu găsise pachete compromise ale unor terți: toată activitatea părea să provină din conturile de test ale operatorului. SafeDep lega payload-ul de familia Miasma, semnalând totuși incertitudini privind originea. The Register relatează că codul este comun cu viermele Miasma Phantom Gyp din iunie și adaugă wiper-ul Mini Shai-Hulud, care șterge directorul home al victimei atunci când aceasta revocă tokenul GitHub furat.

JFrog, ale cărui sisteme semnalaseră pe 21 octombrie pachete de tip Shai-Hulud în npm, a găsit în schimb conturi deturnate încă din iulie, cronologii de commit-uri falsificate, branch-uri de publicare de scurtă durată și credențiale npm expuse.

Cum funcționează lanțul

Instalarea pachetului npm. Potrivit raportului citat de CSO Online, versiunile malițioase folosesc o expandare de comandă în binding.gyp pentru a rula index.js în timpul instalării, fără a declara un script de instalare. Loader-ul aplică la fiecare build o transformare Caesar asupra unui tablou de coduri de caractere, decriptează o etapă AES-128-GCM și găsește sau descarcă Bun 1.2.18; payload-ul este transmis către bun run - sau scris într-un director temporar .b-*, șters după execuție. Payload-ul complet colectează credențiale, modifică depozite și configurații CI și se propagă prin registrele de pachete.

Depozite armate. În depozitele deturnate, campania lasă substituenți inofensivi sau payload-uri reale: hook-uri de execuție pentru asistenți IA și medii de dezvoltare (un hook SessionStart pentru Claude Code, setări Gemini, configurație MCP și reguli Cursor, sarcini VS Code la deschiderea folderului) și wrapper-e polimorfe de 12,9 până la 13,7 MB, care se decodează toate în același payload ascuns. Este suficient să deschizi proiectul cu unul dintre aceste instrumente pentru a-l rula. Fișierele ci.js armate conțin publicatori gândiți să ruleze în GitHub Actions și să folosească tokenuri npm sau trusted publishing pentru a publica noi versiuni malițioase: ciclul se închide.

Dimensiunea drept camuflaj. Wrapper-ele depășesc ce indexează căutarea de cod GitHub și ce returnează API-ul de conținut: de aceea, potrivit unui analist citat de CSO Online, primele analize au găsit hook-urile, dar au considerat goale fișierele cu payload.

Addon nativ și evitarea analizei. Un addon compilat nu conține un payload propriu: decriptează la rulare un fișier .napi_cache. Înainte de a porni, loader-ul caută runnere CI, containere, sandbox-uri și debuggere și, dacă le găsește, iese fără să facă nimic. Un al doilea build sare peste fișierul criptat și descarcă un loader dintr-un depozit al contului GitHub al operatorului, CementBeetleSteeple, care găzduia 17 depozite ale campaniei; potrivit JFrog, un depozit al atacatorului este și un punct activ de colectare a datelor criptate.

Legătura cu cPanel. JFrog leagă același cont de un scanner „shellpanel”, descris deja de Socket într-o campanie care folosea GitHub Actions în depozite compromise pentru a exploata CVE-2026-41940, un bypass de autentificare în cPanel și WHM (în catalogul KEV al CISA din aprilie, cu versiuni corectate disponibile), și pentru a fura credențialele serverelor. JFrog precizează că nu a confirmat compromiteri ulterioare ale unor servere cPanel.

În lectura noastră, tehnicile MITRE ATT&CK relevante sunt T1195.002 (Compromise Software Supply Chain), T1078 (Valid Accounts), T1027 (Obfuscated Files or Information), T1497 (Virtualization/Sandbox Evasion), T1552.001 (Credentials In Files) și T1485 (Data Destruction) pentru wiper.

Impactul pentru companiile europene și italiene

Riscul îi privește pe toți cei care dezvoltă cu pachete npm sau lucrează cu depozite GitHub ale unor terți: laptopul unui dezvoltator conține tokenuri GitHub și npm, chei cloud și chei ale furnizorilor de IA. Cu hook-urile asistenților IA, momentul periculos nu mai este doar instalarea, ci și simpla deschidere a unui proiect. Pentru entitățile NIS2, securitatea lanțului de aprovizionare software este o măsură obligatorie, iar folosirea unor credențiale furate pe sisteme de producție trebuie evaluată ca posibil incident de notificat.

Ce să faci imediat

Recomandările JFrog preluate de CSO Online, cu excepția celor marcate altfel:

  1. Tratează drept compromisă orice mașină pe care a fost instalată o versiune completă a viermelui.
  2. Înainte să revoci tokenurile (recomandarea noastră): wiper-ul descris de The Register se activează la revocarea tokenului GitHub. Izolează mașina și pune la adăpost datele din directorul home, apoi continuă.
  3. Revocă și rotește credențialele GitHub, GitLab, npm, PyPI, RubyGems, cloud, SSH, Vault, Kubernetes și ale furnizorilor de IA.
  4. Verifică toate depozitele accesibile identităților afectate: .github/init.js, .claude/settings.json, .gemini/settings.json, .cursor/mcp.json, .cursor/rules/setup.mdc, .vscode/tasks.json, hook-uri neașteptate în composer.json sau Makefile, commit-uri cu skip-checks:true. Parcurge direct arborele de fișiere: nu te baza pe căutarea de cod sau pe API-ul de conținut.
  5. Curăță: șterge branch-urile neautorizate chore/ci-* și deps/upd-*, dezactivează workflow-urile malițioase și elimină artefactele CodeQL false numite scan-output.
  6. Blochează hxxp[:]//43[.]228[.]157[.]68:80 și infrastructura asociată.
  7. Caută în jurnalele și pe runnerele GitHub Actions /tmp/.svc, ipscan, referințe la CVE-2026-41940, cereri /api/dl/<arch> și scanări neobișnuit de ample; pe mașini, fișiere .napi_cache.
  8. Actualizează cPanel și WHM la versiunile corectate pentru CVE-2026-41940, dacă le folosești.

Cum ajută ARXDOME

ARX Sentry colectează prin agentul său jurnale, evenimente, inventarul proceselor și controlul integrității fișierelor în folderele stabilite, inclusiv pe stațiile dezvoltatorilor și pe runnerele self-hosted. Cu ARX Trace, analiștii noștri pot porni colectări și căutări pe mai multe mașini pentru a găsi indicatorii enumerați, iar ARX Shield permite izolarea de rețea a unei mașini suspecte înainte de revocarea tokenurilor.

Ultima actualizare:

Ai întrebări?

Hai să vorbim despre nevoile companiei tale, fără obligații.

Contactează-ne

Articole similare