Strategiile atacatorilor:

Infractorii cibernetici se bazează pe o combinație de tehnici diferite pentru a-și atinge obiectivele. Principalele strategii includ

• Mail bombing: o avalanșă de e-mailuri pentru a copleși victima și a ocoli mecanismele de securitate.
• Impersonarea personalului IT: Identități înșelător de reale pentru a convinge angajații să instaleze software malițios.
• Instalarea unui patch fals: O presupusă actualizare pentru problema existentă de tip mail-bombing, care în realitate a declanșat o infecție cu malware.

Odată ce accesul este obținut, sunt executate o serie de instrumente malware. Acestea erau necunoscute la momentul analizei pe baza semnăturilor și fiecare incident avea caracteristici suplimentare și nerecunoscute anterior. După compromiterea primului sistem, atacatorii au încercat să obțină acces la controlerul de domeniu pentru a prelua controlul asupra întregului domeniu al companiei. Metodele de atac au variat în funcție de măsurile de securitate existente ale organizațiilor afectate. În ciuda acestor strategii de atac sofisticate, în niciunul dintre cazurile investigate de CDC infractorii cibernetici nu au reușit să preia controlul complet asupra sistemului informatic al întreprinderii. Acest lucru s-a datorat, printre altele, contramăsurilor automate care au încetinit sau limitat atacatorii, răspunsurilor rapide (de exemplu, carantina sistemului) ale modulelor de securitate (EDR, SIEM...), intervențiilor manuale ale departamentului IT al întreprinderii sau inițierii răspunsului la incidente, care au limitat atacatorii.
Din cauza contramăsurilor luate, nu au putut fi trase concluzii definitive cu privire la intențiile atacatorilor. Cu toate acestea, mai multe surse publice și concluzii ale Serviciului de informații privind amenințările al CDC indică faptul că a fost vorba de un grup cunoscut de ransomware.

Secvență de atac simplificată grafic

Etapele prezentate în diagrama de mai jos sunt menționate și descrise mai detaliat în analiza următoare.

_{Fig.: Reprezentarea grafică a secvenței de atac}

Infecția inițială:

Atacatorii își lansează atacul printr-o combinație de e-mailuri spam (1) și contact direct prin Microsoft Teams. Aceștia au pretins că sunt suport IT și au oferit un presupus ajutor pentru a rezolva "problema e-mailului" (e-mailuri spam).

A fost vizibil faptul că atacatorii au folosit propriii lor chiriași Microsoft, inclusiv:

• Fastsecurity.onmicrosoft.com
• securepointsupport.onmicrosoft.com
• supporthelpdeesk.onmicrosoft.com

Numele de utilizator alese de atacatori au reflectat, de asemenea, nume specifice țării în care se află compania victimă.

Ingineria socială și persistența:

Aceste încercări de comunicare (2) pot fi urmărite cu ușurință prin intermediul SIEM central (CDC LOG Module) folosind O365 Unified Audit Logs. În imaginea de mai jos, se poate observa că au fost deschise mai multe chat-uri între atacator și victimă.

_{Fig.: Analiza ingineriei sociale a echipelor prin intermediul jurnalelor UAL}

Modelele de comportament ale atacatorilor au variat ușor între cazurile investigate. În unele scenarii, aceștia au inițiat apeluri Teams între atacator și victimă și au furnizat linkuri pentru descărcarea unui instrument de monitorizare și gestionare la distanță (RMM). În alte cazuri, aceștia au efectuat sesiuni la distanță cu victimele în care au căutat în mod activ instrumente RMM interne ale companiei prin intermediul sistemului utilizatorului. În unele cazuri, acestea au fost chiar identificate și instalate prin intermediul sistemelor sharepoint interne ale companiei pentru a ocoli orice reguli firewall/proxy. În toate cazurile, atacul s-a încheiat cu executarea sau instalarea unuia sau a mai multor instrumente RMM, care au permis atacatorilor accesul la sistemul victimei.

Descărcări multiple de programe malware executabile

În unele scenarii, angajații au fost trimiși într-o "pauză de cafea" deoarece "angajatul IT" (atacatorul) avea nevoie de timp pentru a rezolva presupusa problemă a mesajelor spam. În funcție de RMM-ul utilizat (Teamviewer, Anydesk), atacatorul a descărcat alte instrumente malware (3) pe sistemul victimei și le-a executat pentru a crea o persistență suplimentară pe sistem.

Un extras din jurnalele de conexiune Teamviewer a confirmat sesiunile la distanță dintre atacator (de exemplu, numele: Lily Fox) și sistemul victimei:

Lily Fox 08:29:48 08:34:48 <VictimUserName> RemoteControl{redacted}
Lily Fox 08:36:33 08:41:32 <VictimUserName> RemoteControl {redacted}

_{Fig.: Jurnalul conexiunii Teamviewer / conexiunea la distanță a atacatorului}

Eșantioanele malware descărcate pentru fiecare caz au variat în funcție de semnătură și nume, însă funcționalitatea și sensul denumirii acestora au fost similare. Mai jos este prezentat un exemplu de instrument utilizat de atacatori (EDR):

În cazurile detectate ulterior, atacatorul a renunțat din ce în ce mai mult la AntiSpam.exe și s-a bazat în schimb pe fișiere DLL (de exemplu, AntispamModule.dll), care aveau aceeași funcționalitate, dar erau executate cu rundll32.exe pentru a face detectarea de către soluțiile de securitate mai dificilă (evaziune).

În plus, diverse comenzi de enumerare au fost executate prin intermediul cmd.exe, inclusiv

• ipconfig /all
• route print
• systeminfo

Instrumentele malware menționate au fost în mare parte recunoscute de sistemele EDR, chiar dacă semnăturile lor erau inițial necunoscute. A fost necesară o analiză mai detaliată și o monitorizare continuă, deoarece în fiecare caz cel puțin unul dintre aceste instrumente nu a fost recunoscut ca fiind rău intenționat. S-a observat, de asemenea, că majoritatea acestor instrumente au fost lansate prin Explorer.exe - un indiciu de interacțiune manuală din partea atacatorului sau a victimei, care a fost, de asemenea, confirmat în analiză.

O corelare a sistemului infectat cu jurnalele sau SIEM (jurnalele controlerului de domeniu) a arătat rapid că amploarea atacului a fost mai mare decât se presupunea inițial. Atacatorul a încercat să creeze un cont de mașină în Active Directory (EventID 4741) utilizând executabilele menționate și utilizatorul infectat (SubjectUserName) -(6).
Monitorizarea creării de conturi de mașină care nu sunt create de personalul IT poate fi ușor implementată cu un SIEM și este o măsură eficientă pentru detectarea unor astfel de atacuri.

_{Fig.: Un cont de mașină (SRVVSSKL) a fost creat de atacator}

Acest cont de mașină a fost identic în toate modelele de atac și, astfel, a furnizat un indicator ușor de recunoscut (SRVVSSKL) pentru detectarea acestor atacuri. În funcție de configurația și de nivelul de patch-uri ale controlerului de domeniu, atacul a avut succes în diferite grade. Cu toate acestea, valorile implicite sunt frecvent întâlnite, unde, pe scurt, utilizatorii autentificați ai domeniului sunt autorizați să creeze până la zece conturi de mașină. În cazul în care atacatorul reușește să creeze un astfel de cont, el poate continua să îl utilizeze - chiar dacă contul de utilizator infectat inițial a fost pus în carantină sau blocat. Dacă acest pas în mișcarea atacatorului este trecut cu vederea, el poate avea consecințe grave și poate lăsa organizația într-o stare necurată sau poate lăsa atacatorul în organizație.

În cazurile în care atacatorul a reușit să creeze cu succes un cont de mașină, s-a efectuat apoi kerberoasting (7). Această tehnică este utilizată, printre altele, pentru a extinde drepturile unui utilizator cu privilegii reduse la nivelul serviciilor. Cu toate acestea, succesul său depinde în mare măsură de complexitatea parolelor SPN-urilor (Service Principal Names) atacate.

Cheia de execuție creată se referea la AntiSpamUpdate.exe, care acționa, de asemenea, ca un serviciu de comandă și control.

Comandă și control (C&C):

_{Fig.: Comunicarea C&C prin tuneluri DNS}

Este demn de remarcat faptul că comunicarea C&C a avut loc parțial direct prin portul 443 și parțial prin tunelarea DNS (SystemBC/Socks5) -(5). Prin tunelarea DNS, atacatorul ascunde comunicarea C&C în cadrul protocolului DNS (de exemplu, datele sunt împachetate ca un subdomeniu). Acest lucru face dificilă detectarea automată a traficului de rețea rău intenționat cu ajutorul firewall-urilor, de exemplu.

Blocarea conexiunilor de ieșire de la client în perimetru nu este suficientă în acest caz, deoarece tunelarea DNS funcționează și prin intermediul serverelor DNS interne, care transmit interogările DNS - și, prin urmare, comunicarea C&C - în numele clientului. Cu toate acestea, detectarea fiabilă este posibilă dacă jurnalele serverelor DNS sunt salvate și monitorizate. În acest caz, modulul jurnal CDC (date DNS) poate fi utilizat pentru a alerta și a răspunde la tunelarea DNS.

Izolarea și scanarea:

Analiza a inclus o verificare la nivelul întregii companii (sweeping) a tehnicilor atacatorului și a indicatorilor de compromis (IOC) pentru a identifica dacă alți utilizatori au fost atacați. Acesta a fost cazul în unele analize cu privire la Teams communication și e-mail bombing. Cu toate acestea, acești utilizatori nu au început o sesiune cu atacatorul, ci au recunoscut de la început că este vorba de un atac, au ignorat presupusul suport IT sau erau în vacanță în momentul atacului. Au fost luate măsuri de contracarare și de educare a acestor utilizatori pentru a preveni reinfectarea.

În niciunul dintre cazurile investigate de CDC nu a avut loc o încălcare a domeniului sau a întreprinderii, datorită contramăsurilor rapide. Cu toate acestea, analizele publice și informațiile privind amenințările (modulul TI) au dezvăluit amploarea potențială a atacului (încălcare completă a companiei / ransomware la nivelul întregii companii).

Contramăsurile luate pe termen scurt au depins de evoluția atacatorului și de progresul analizelor și au inclus, printre altele

• Punerea în carantină a sistemului utilizatorului
• Blocarea utilizatorului inițial
• Precum și schimbarea parolelor de terță parte ale utilizatorului
• Ștergerea / blocarea contului de mașină creat de atacator
• Schimbarea parolelor SPN (Kerberoasting)
• Lista neagră a chiriașilor atacatori (alternativ lista albă a chiriașilor legitimi)
• Restricționarea temporară a opțiunilor de partajare la distanță O365
• Restricționarea la nivelul întregii companii a instrumentelor RMM (dacă este posibil)
• Blocarea domeniilor C&C
• Implementarea unui EDR
• Personalizarea valorilor implicite pentru generarea contului mașinii
• Monitorizare extinsă / logare extinsă
• Restricționarea utilizării instrumentelor RMM.

Măsuri organizaționale și pe termen lung recomandate

Detectarea și răspunsul:

• Atacatorii acționează extrem de rapid (< 1 oră pentru infectarea inițială, escaladarea privilegiilor și deplasarea laterală).
• Detectarea și răspunsul rapid sunt esențiale.
• Recomandate:
  ✅ Monitorizare proactivă de către un centru de operațiuni de securitate (SOC) sau module de securitate.
  ✅ Măsuri automatizate de prevenire pentru a bloca atacurile într-un stadiu incipient.
  ✅ Răspuns rapid la incidente pentru a limita eficient amenințările.

Detectarea și răspunsul la punctele terminale (EDR)

• Majoritatea instrumentelor atacatorilor au fost recunoscute de soluțiile EDR comune, chiar dacă erau necunoscute pe baza semnăturilor.
• DAR: Nu toate instrumentele au fost detectate → analiza rămâne esențială.
• Recomandat:
  ✅ Monitorizarea continuă a EDR pentru a detecta activitățile atacatorilor într-un stadiu incipient.
  ✅ Analize avansate pentru a identifica activitățile nedetectate (escaladarea privilegiilor, persistența, mișcarea laterală).

Gestionarea informațiilor și evenimentelor de securitate (SIEM)

• În cazul în care a fost instalat un SIEM cu detectare adecvată, acesta a permis:
  Detectarea mișcării laterale, a escaladării privilegiilor de domeniu, a persistenței și a comunicării C&C (tunelare DNS).
• Constatare importantă:
  Curățarea sistemului angajaților ar fi fost insuficientă în multe cazuri.
  ➡ Adesea, atacatorii își creaseră deja propriile conturi de mașină pe controlerul de domeniu sau compromiseseră acreditările utilizatorilor de servicii (de exemplu, prin Kerberoasting).
• Recomandări:
  ✅ Corelați jurnalele controlerului de domeniu cu SIEM pentru a detecta activitățile suspecte.
  ✅ Monitorizați crearea conturilor de mașină și numele principalilor de servicii (SPN).