GhostAction a compromis 790 de depozite GitHub pentru a fura chei cloud și chei API de AI

O campanie de furt de credențiale, cunoscută sub numele GhostAction, a introdus workflow-uri GitHub Actions malițioase în aproximativ 790 de depozite de cod. Acestea colectează credențiale cloud, token-uri de publicare a pachetelor și chei API pentru servicii de AI, apoi le trimit către o infrastructură controlată de atacatori. Atacatorii nu au avut nevoie de un zero-day: au preluat conturi de dezvoltatori de încredere și au folosit pipeline-ul CI exact așa cum a fost gândit să funcționeze.

Ce s-a întâmplat

Odată ce un atacator poate face push în depozitele unui maintainer, adaugă un workflow care rulează la fiecare push sau la pornire manuală. Workflow-ul rulează apoi cu toate secretele pe care proiectul le pune la dispoziția CI-ului.

Cea mai recentă versiune a workflow-ului face mai mult decât să citească anumite secrete din Actions:

• Caută în depozit șiruri care seamănă cu credențiale. Printre ele: chei de acces AWS și token-uri pentru GitHub, GitLab, Google, Slack, SendGrid, OpenAI, Anthropic și OpenRouter.
• Scotocește istoricul Git. Clonează cu fetch-depth: 0, așa că o cheie ștearsă din codul actual, dar rămasă într-un commit vechi, poate fi găsită.
• Adună și contextul. Lângă ID-urile de chei AWS colectează și liniile din jur, care pot expune cheia secretă pereche sau detalii despre cont, nu doar un singur șir.
• Trimite datele prin HTTP simplu. Traficul pleacă de pe un runner CI, așa că poate trece drept un pas obișnuit de build dacă nimeni nu verifică modificările de workflow și traficul de ieșire.

Cifra de 790 reprezintă depozitele validate care puteau fi încă recuperate public la 9 octombrie 2026. Nu înseamnă că fiecare a scurs secrete sau că fiecare scurgere a fost exploatată. Alți cercetători au publicat cifre diferite pentru perioade diferite: circa 772 de depozite între sfârșitul lui august și sfârșitul lui septembrie și aproximativ 346 de depozite legate de două conturi compromise, într-un val din 8 octombrie. Pentru că aceste cifre se suprapun, nu trebuie adunate. Depozitele afectate au variat de la proiecte active și fork-uri până la depozite inactive de ani de zile. Tiparul sugerează descoperirea automată a tot ce poate modifica un cont compromis.

Investigatorii spun că unele dintre workflow-urile malițioase au rulat cu succes. Până la 9 octombrie nu au găsit versiuni malițioase pe PyPI sau crates.io legate de acest ultim val.

De ce contează

Secretele din CI/CD sunt printre cele mai valoroase credențiale ale unei organizații. O singură cheie cloud sau un singur token de publicare poate deschide drumul către infrastructura de producție, către registre de pachete în care au încredere utilizatorii din aval sau către conturi de AI plătite, care pot fi golite ori abuzate. Pasul care scanează istoricul Git contează cel mai mult: multe echipe cred că ștergerea unei chei scrise direct în cod rezolvă problema. Nu o rezolvă. Dacă nu a fost revocată, cheia poate fi folosită de oricine are acces la istoric.

Ștergerea workflow-ului malițios nu înseamnă remediere. Un workflow care a rulat o singură dată poate să fi trimis deja secretele, iar eliminarea fișierului nu revocă un token GitHub, o cheie cloud sau o cheie de publicare furate.

Ce trebuie făcut

1. Căutați workflow-uri neașteptate. Verificați .github/workflows/ în toată organizația pentru fișiere pe care nu le-ați scris voi, mai ales cele adăugate recent, cu nume generice de „security” sau „CI”. Urmăriți workflow-urile care fac POST-uri HTTP brute sau folosesc curl ca să trimită date către gazde necunoscute.
2. Păstrați dovezile înainte de curățenie. Salvați fișierele de workflow, log-urile de rulare, commit-urile și înregistrările din audit log pentru perioada afectată.
3. Revocați și rotiți. Revocați accesul prin care atacatorul a făcut modificările, apoi rotiți fiecare secret la care workflow-ul a avut acces, inclusiv cheile care apar doar în commit-uri vechi.
4. Verificați ce puteau atinge secretele. Analizați versiunile de pachete, deployment-urile și activitatea din cloud din perioada afectată.
5. Întăriți GitHub Actions. Dați workflow-urilor token-uri cu privilegii minime, cereți review pentru modificările de workflow, adăugați aprobări pentru job-urile sensibile și restricționați, unde se poate, traficul de ieșire al runner-elor.
6. Blocați și monitorizați indicatorii raportați (dezactivați): infrastructura de colectare și scanare 193.32.204[.]199 și domeniul suspect my-github[.]com. Cercetătorii au marcat domeniul ca prioritar, dar nu au dovedit că a fost înregistrat de operatorii GhostAction. Domeniile GitLab asemănătoare din listele publicate sunt doar elemente de urmărit. Nu sunt infrastructură confirmată a campaniei.

Secretele îngropate în depozite și în istoricul lor sunt materia primă pentru campanii ca aceasta. Analiza de cod asistată de AI oferită de echipa noastră scanează codul sursă și întregul istoric Git după credențiale expuse, configurații CI/CD riscante și dependențe vulnerabile, astfel încât cheile scurse să fie găsite și rotite înainte să le găsească un atacator.

Sursă: acest articol rezumă informațiile publicate de Cyber Security News, pe baza cercetării OpenSourceMalware, cu cifre suplimentare de la GitGuardian, Socket și StepSecurity.