Un singur cont, un întreg ecosistem cloud
Un singur cont compromis poate fi suficient pentru a deschide accesul către platforma de dezvoltare a unei organizații, infrastructura sa cloud și tot ce este conectat între ele. O intruziune documentată recent arată exact cât de departe poate ajunge acest acces atunci când repository-uri, pipeline-uri automate și credențiale de deployment se află în spatele unei singure identități.
Ce s-a întâmplat
După ce a preluat controlul unui cont valid, actorul de amenințare — urmărit sub numele Storm-3068 — nu a avut nevoie de malware personalizat pentru a acționa. Folosind instrumente administrative legitime și scripturi automatizate, intrusul a cartografiat sistematic proiectele, repository-urile, pipeline-urile și mediile de deployment Azure DevOps ale organizației, construind o imagine a sistemelor conectate și a locurilor unde erau probabil disponibile credențiale valoroase.
Azure DevOps a fost o țintă eficientă tocmai pentru că reunește dezvoltarea software și operațiunile cloud într-un singur loc. Atacatorul a creat un pipeline malițios autorizat să acceseze peste 50 de resurse, a implementat prin acesta un agent kube și a rulat o serie de joburi menite să colecteze la scară largă fișiere de configurare pentru clustere Kubernetes — fișiere care conțin atât detalii de conectare, cât și materialul de autentificare necesar pentru a accesa clustere active. Investigatorii au descoperit ulterior că șapte fișiere kubeconfig furate fuseseră adăugate într-un repository, fiecare reprezentând un set de credențiale utilizabil pentru un cluster Kubernetes vizat.
Actorul a mers și mai departe, modificând scripturile pipeline-ului pentru a instala agentul de administrare la distanță Atera și pentru a descărca utilitarul de tunelare Chisel. Scopul aparent a fost construirea unui canal de acces la distanță de rezervă și expunerea API-ului serverului Kubernetes pentru o posibilă interacțiune, Chisel fiind folosit pentru a stabili un tunel invers către o adresă externă. Jurnalele de audit și istoricul versiunilor Git din Azure DevOps au oferit, în cele din urmă, echipei de răspuns traseul necesar pentru a reconstitui intruziunea și a identifica exact unde fuseseră plasate credențialele furate.
Răspunsul a combinat înregistrări de identitate, de platformă DevOps și de infrastructură cloud pentru a urmări cât de departe ajunsese atacatorul, alături de briefinguri zilnice de limitare a impactului și coordonare cu o echipă mai amplă de threat intelligence pentru a menține investigația concentrată pe măsură ce apăreau noi detalii.
De ce contează
Aceasta nu a fost o poveste despre furtul de cod sursă — a fost o poveste despre mișcare laterală care a pornit, întâmplător, dintr-un repository de cod. O platformă de dezvoltare nu conține doar cod sursă; conține harta a tot ce acea platformă are voie să atingă. Repository-urile, conexiunile de servicii și setările de deployment au oferit unei singure identități compromise o cale către infrastructura de producție, prin relații de încredere pe care organizația le acordase deja. Iar pentru că atacatorul s-a bazat pe instrumente administrative legitime și permisiuni de pipeline autorizate, nu pe exploit-uri, activitatea s-a confundat cu operațiunile normale de DevOps până când traseul credențialelor a dat-o de gol.
Ce este de făcut
- Monitorizați activitatea de resetare a parolelor pentru tipare — încercări repetate sau activitate care traversează mai multe conturi merită triate, nu ignorate.
- Scoateți conturile privilegiate din fluxurile de resetare self-service și impuneți autentificare multi-factor rezistentă la phishing pentru acestea.
- Impuneți revizuire și protecție a branch-urilor pentru modificările de cod și limitați cine poate face commit direct pe branch-urile critice.
- Limitați cine poate crea, modifica sau executa pipeline-uri de build și deployment — permisiunile de pipeline sunt, de fapt, permisiuni de producție.
- Aplicați consecvent principiul privilegiului minim la nivel de identități, platforme de dezvoltare și resurse cloud, nu doar la marginea infrastructurii.
- Auditați periodic configurațiile de identitate, DevOps și cloud — obiectivul este identificarea relațiilor de încredere pe care un atacator le-ar putea exploata înainte ca acestea să fie testate.
Tratați credențialele CI/CD și permisiunile de pipeline cu aceeași rigoare ca și secretele de producție — pentru că, într-un ecosistem DevOps conectat, chiar asta sunt.