Toate articolele

Noutăți26 octombrie 20265 min de citit

Gheist: tokenuri GitHub furate, secrete scurse prin logurile Actions

Cu tokenuri GitHub furate, Gheist plantează workflow-uri în depozite private și scrie secretele în logurile Actions: cum funcționează și ce trebuie să faci.

Persoană cu glugă, în întuneric, în fața unui laptop, cu fața în umbră

📌 Evoluții ulterioare: Viermele testmetest: payload de 13 MB în 42 de depozite GitHub (26 octombrie 2026)

O campanie numită Gheist folosește tokenuri de acces GitHub furate pentru a face depozitele victimelor să ruleze un workflow GitHub Actions care scrie secretele în loguri, de unde atacatorul le descarcă. Descrierea tehnică provine din analiza Wiz Research, preluată de Help Net Security; au mai scris despre ea The Hacker News, Dark Reading, care vorbește despre un atac asupra lanțului de aprovizionare încă în desfășurare împotriva a mii de depozite ale dezvoltatorilor, și Infosecurity Magazine, care confirmă amploarea: peste 13.500 de branch-uri și depozite vizate.

Ce s-a întâmplat

Potrivit Wiz, cercetătorii au recuperat peste 13.500 de branch-uri create de atacator în depozite care aparțin a peste 850 de conturi GitHub compromise. Numele campaniei vine de la user agent-ul pe care instrumentul îl trimite în cererile către API-ul GitHub. Wiz nu precizează cum au fost furate tokenurile.

Punctul critic sunt depozitele private. Din 28 iulie, GitHub reține în depozitele publice rulările de workflow potențial malițioase până când un colaborator le aprobă, iar acolo atacul este blocat. Acest control nu se aplică însă depozitelor private și nici GitHub Enterprise Server: potrivit Wiz, jurnalele de audit GitHub arată rulări pe branch-urile atacatorului finalizate și apoi șterse de user agent-ul Gheist. Printre secretele expuse se află cele ale environment-urilor, care sunt adesea credențiale de producție.

Cum funcționează atacul

Lanțul descris de Wiz este scurt și rămâne în întregime în interiorul GitHub:

  1. instrumentul ia un token furat și enumeră toate depozitele la care acel token are acces;
  2. în fiecare creează un branch numit ci-sync- urmat de șase caractere aleatorii și adaugă un mic workflow numit sync-check;
  3. push-ul branch-ului pornește automat workflow-ul, care are o singură sarcină: să scrie secretele depozitului în logul rulării;
  4. pentru a ocoli mascarea secretelor din GitHub, care recunoaște un secret doar dacă apare exact așa cum a fost salvat, fiecare valoare este codificată în base32 și ajunge integral în log;
  5. instrumentul descarcă logul prin API-ul GitHub și șterge rularea după câteva secunde.

Nu există un server al atacatorului: secretele ies prin API-ul GitHub, deci nu există un domeniu extern sau o conexiune de blocat. Ștergerea rulării și a branch-ului nu anulează însă expunerea.

Wiz a observat două variante ale instrumentului. Din 19 octombrie, una dintre ele adaugă un al doilea job îndreptat spre runner-ele self-hosted: caută tokenuri și chei pe mașină și folosește Docker pentru a ajunge la fișierele gazdei.

În organizațiile enterprise, instrumentul a trecut în câteva minute prin tokenurile mai multor utilizatori și conturi de automatizare și a clonat depozitele private înainte de a planta workflow-ul. Câteva ore mai târziu, credențiale cloud ale aceleiași organizații au fost folosite pentru a enumera AWS Secrets Manager; Wiz nu spune cum au fost obținute. În jurnalele CloudTrail ale victimelor apar workflow-urile propriilor organizații rulând pe branch-uri ci-sync- în timp ce asumau roluri AWS: dovada că Actions a rulat fără nicio aprobare.

Aceleași conturi sunt folosite și de alte grupuri: pe 6 octombrie, 391 de conturi au redenumit aproximativ 1.461 de depozite ca momeli cu software piratat (166 dintre aceste conturi nu apar niciodată în activitatea Gheist), iar pe 18 octombrie 25 de conturi Gheist au creat fiecare câte un depozit „Windows RDP Runner” în decurs de nouă minute.

În lectura noastră, tehnicile MITRE ATT&CK relevante sunt T1078 (Valid Accounts), T1213.003 (Code Repositories), T1027 (Obfuscated Files or Information) pentru codificarea base32, T1567 (Exfiltration Over Web Service), T1070 (Indicator Removal) pentru ștergerea rulărilor și T1555.006 (Cloud Secrets Management Stores) pentru enumerarea AWS Secrets Manager.

Impactul pentru companiile europene și italiene

Multe companii europene își țin codul și pipeline-urile de lansare pe GitHub, adesea în depozite private cu secrete de environment care dau acces la cloud, la registre de containere și la baze de date de producție. Un singur token al unui dezvoltator sau al unui cont de automatizare este suficient pentru a expune secretele tuturor depozitelor la care ajunge. Pentru entitățile NIS2, securitatea dezvoltării și a lanțului de aprovizionare este una dintre măsurile cerute: folosirea unor credențiale de producție exfiltrate trebuie evaluată și ca posibil incident de notificat.

Ce trebuie să faci acum

  1. Caută urme în jurnalele de audit GitHub: user agent-ul Gheist, crearea de branch-uri ci-sync-*, workflow-uri sync-check și rulări șterse imediat după încheiere.
  2. Verifică jurnalele cloud: dacă workflow-urile tale se autentifică prin OIDC, caută asumări de rol al căror subject conține un branch ci-sync-. Potrivit Wiz, aceasta este dovada că Actions a rulat pe un branch al atacatorului, chiar dacă nu colectezi jurnalele GitHub.
  3. Rotește toate secretele disponibile unui depozit afectat: de depozit, de organizație și de environment. Revocă tokenurile care au făcut push-urile, așa cum recomandă Wiz.
  4. Verifică runner-ele self-hosted: porniri de containere cu acces la sistemul de fișiere al gazdei și credențiale prezente pe mașină începând cu 19 octombrie.
  5. Redu suprafața de atac (recomandările noastre): limitează politicile de încredere OIDC la branch-uri sau environment-uri precise, protejează environment-urile cu reguli privind branch-urile de lansare și revizori obligatorii, folosește tokenuri cu permisiuni minime și expirare scurtă și ia în calcul reguli care împiedică modificarea fișierelor de workflow de către cine nu are acest drept.

Cum ajută ARXDOME

Agentul ARX Sentry colectează loguri, evenimente și inventarul proceselor de pe servere Linux, Windows și macOS, inclusiv cele folosite ca runner-e self-hosted: ajută la observarea pornirilor neobișnuite de containere și procese pe mașină. Cu ARX Trace, analiștii noștri pot lansa colectări și căutări pe mai multe mașini pentru a verifica ce a fost atins, iar ARX Shield permite izolarea din rețea a unui runner suspect până la rotirea secretelor.

Ultima actualizare:

Ai întrebări?

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

Contactează-ne

Articole similare