GhostAction evoluează: un fișier „font” fals fură credențialele dezvoltatorilor din 94 de repository-uri GitHub

Grupul din spatele campaniei de supply chain GhostAction și-a schimbat tactica. Nu se mai bazează doar pe workflow-uri GitHub Actions malițioase. Acum îi atacă direct pe maintainerii open-source prin phishing și plantează un credential stealer, deghizat în font web, care rămâne activ pe calculatoarele dezvoltatorilor chiar și după ce workflow-ul inițial este șters.

Ce s-a întâmplat

Un domeniu-sosie și o alertă credibilă. Pe 9 octombrie 2026, atacatorul a înregistrat my-github[.]com și l-a direcționat către 193.32.204[.]199. Este același IP care primește deja datele furate de workflow-urile GhostAction mai vechi. În aceeași zi, un maintainer a primit de la noreply@my-github[.]com o falsă alertă de securitate GitHub despre o „autentificare nouă din Moscova”, care îl îndemna să își „securizeze” contul.

Un domeniu similar, my-gitlab[.]com, a apărut cu câteva săptămâni înainte. Până acum, nimic din infrastructura lui nu îl leagă de același atacator, deci legătura rămâne neconfirmată.

Phishing care aprobă în tăcere o aplicație OAuth. Pagina de phishing funcționează ca reverse proxy în fața GitHub-ului real. Captează parola victimei și codul 2FA. În fundal, un JavaScript injectat finalizează o autorizare GitHub OAuth device flow cu scope-urile repo, workflow și read:org. Victima nu vede și nu tastează niciun cod de dispozitiv și nu aprobă nimic în mod conștient. Scriptul face întregul pas de consimțământ în sesiunea intermediată. Tokenul obținut este trimis către my-github[.]com pe TCP/8443.

Acel token este o credențială API reutilizabilă. Poate citi și scrie în repository-uri, poate modifica workflow-urile Actions și poate lista membrii organizațiilor. Sunt exact permisiunile de care GhostAction are nevoie ca să împingă și mai multe workflow-uri malițioase.

O a doua etapă care nu are nevoie de GitHub ca să ruleze. Repository-urile compromise primesc acum trei fișiere:

un fișier VS Code .vscode/tasks.json cu runOn: folderOpen, care rulează automat când dezvoltatorul deschide folderul proiectului;
public/fonts/fa-solid-400.woff2, care nu este un font. Este un stealer care colectează chei AWS, tokenuri PyPI și npm, credențiale Git, configurații Kubernetes, chei SSH private și chei API pentru furnizori AI precum Anthropic Claude și Google Gemini. Același nume de fișier a fost folosit în campania PolinRider, asociată Coreei de Nord, la începutul anului. Suprapunerea sugerează tehnici împrumutate, nu o atribuire confirmată;
un workflow GitHub Actions de rezervă, pentru cazul în care stealerul nu rulează. Este o versiune extinsă a workflow-ului original, cu mai multe tipare de secrete și o rezervă care urcă rezultatele într-un gist secret dacă trimiterea HTTP eșuează. Nume observate: lint.yml, ci-check.yml, build-check.yml, repo-health.yml, audit.yml, code-review.yml, test-suite.yml, cache-cleanup.yml.

Odată pornit, stealerul instalează un cron job care descarcă și rulează cod al atacatorului la fiecare cinci minute. Datele furate sunt trimise prin HTTP necriptat, pe portul 8080, către același server.

Amploarea. 94 de repository-uri ale 66 de proprietari conțin a doua etapă. Cincisprezece au fost între timp șterse, redenumite sau făcute private. Majoritatea celor rămase par abandonate: 65 din cele 79 încă accesibile nu au avut niciun commit de peste un an, iar unul nu fusese atins de mai bine de nouă ani. Proiectele vechi, nemonitorizate, sunt cel mai ușor loc de ascuns.

GitHub a început să blocheze rularea workflow-ului malițios pe 9 octombrie, iar valurile următoare nu au mai produs secrete. Etapa care nu are nevoie de runner a apărut cam o săptămână mai târziu. Cercetătorii spun că nu pot demonstra că blocarea a provocat schimbarea, dar atacatorul s-a mutat clar acolo unde controalele GitHub nu ajung: pe laptopul dezvoltatorului.

De ce contează

Este suficient să deschizi un folder. Dezvoltatorii se așteaptă la risc când rulează npm install sau cod, nu când deschid un proiect în editor. Task-urile cu rulare automată elimină și ultimul moment de judecată.
2FA singur nu ajunge. Un kit de phishing cu reverse proxy transmite codul unic în timp real. Apoi autorizarea OAuth silențioasă lasă în urmă un token care rezistă și după schimbarea parolei.
Impactul ajunge la tot ce depinde de victimă. Tokenul unui singur maintainer poate ajunge la organizațiile lui, la registrele de pachete și la fiecare utilizator care îi clonează sau folosește codul.
Atacatorul e neglijent, dar insistent. Cercetătorii spun că stealerul ratează multe chei API și chiar o parte din propriile rezultate. Folosirea aceluiași IP pentru phishing, exfiltrare și scanări zgomotoase este și motivul pentru care acel IP încă dezvăluie infecții. E o oportunitate pentru apărători, nu un motiv de relaxare.

Ce este de făcut

Căutați indicatorii. Căutați în cod și în logurile de proxy și DNS my-github[.]com, 193.32.204[.]199 și trafic de ieșire către porturile 8443 și 8080 ale acestui host. În repository-uri, căutați fișiere .vscode/tasks.json neașteptate cu runOn: folderOpen, fișiere „font” din public/fonts/ care nu sunt fonturi valide și workflow-uri adăugate recent cu numele de mai sus.
Dacă ați putea fi afectați, rotiți totul de pe un dispozitiv curat. Revocați sesiunile GitHub, tokenurile personale și aplicațiile OAuth autorizate (Settings → Applications). Schimbați parola și rotiți fiecare secret la care workflow-urile sau stația voastră aveau acces: chei cloud, tokenuri de registry, configurații kube, chei SSH, chei API AI. Ștergeți orice intrare cron necunoscută.
Anunțați utilizatorii din aval. Dacă un repository pe care îl întrețineți a fost compromis, anunțați pe oricine l-a clonat. Este posibil să fi rulat stealerul doar deschizând folderul.
Întăriți setările implicite. Lăsați activat Workspace Trust în VS Code și nu acordați încredere folderelor tocmai clonate. Folosiți MFA rezistent la phishing (passkeys sau chei hardware), pe care un reverse proxy nu îl poate transmite mai departe. Restricționați aplicațiile OAuth la nivel de organizație sau cereți aprobare pentru ele, și setați implicit GITHUB_TOKEN doar pe citire.
Nu lăsați repository-urile vechi în paragină. Arhivați proiectele pe care nu le mai întrețineți și verificați cine mai are drept de scriere în ele.

Această campanie se ascunde în locurile pe care majoritatea verificărilor le sar: YAML-ul workflow-urilor, configurația editorului și fișierele care par binare. Serviciul nostru de code review asistat de AI se uită exact acolo. Semnalează task-urile cu rulare automată, modificările suspecte de workflow și fișierele care nu sunt ce pretinde extensia lor, astfel încât o etapă plantată ca aceasta să fie prinsă în repository înainte să ajungă pe calculatorul unui dezvoltator.

Sursă: articol original publicat de The Hacker News, pe baza cercetării OpenSourceMalware.