Detekcia

Útok SolarWinds, ktorý uspel s využitím malvéru sunburst, šokoval odvetvie kybernetickej bezpečnosti. Tento útok dosiahol vytrvalosť a dokázal sa dostatočne dlho vyhýbať interným systémom, aby získal prístup k zdrojovému kódu obete.

Kvôli ďalekosiahlemu nasadeniu SolarWinds boli páchatelia tiež schopní infiltrovať mnoho ďalších organizácií, hľadajúc duševné vlastníctvo a iné aktíva.

Medzi spoluobeťami: vláda USA, vládni dodávatelia, spoločnosti v oblasti informačných technológií a mimovládne organizácie. Neskutočné množstvo citlivých údajov bolo odcudzených niekoľkým zákazníkom po tom, čo bola do ich interných štruktúr nainštalovaná trojanizovaná verzia aplikácie SolarWinds.

Pri pohľade na technické možnosti malvéru, ako uvidíte, bol tento konkrétny útok celkom pôsobivý. Konkrétny súbor s názvom SolarWinds.Orion.Core.BusinessLayer.dll je SolarWinds digitálne podpísaný komponent softvérového rámca Orion.

Aktéri hrozby nainštalovali zadné vrátka, ktoré komunikujú cez HTTP so servermi tretích strán. Po počiatočnom nečinnom období trvajúcom až dva týždne načíta a vykoná príkazy nazývané „Úlohy“, ktoré zahŕňajú schopnosť prenášať súbory, spúšťať súbory, profilovať systém, reštartovať počítač a deaktivovať systémové služby.

Ako by sa teda dalo chrániť organizáciu pred Sunburstom alebo podobným útokom? Útoky na dodávateľský reťazec majú tú výhodu, že vytvárajú počiatočnú oporu pod zámienkou dôveryhodnej tretej strany. Ale tu sa rozdiel končí; Odtiaľ postupujú ako každý iný útok a možno ich odhaliť, ak vieme, kde hľadať.

Vývoj pravidiel SIEM s použitím útoku SolarWinds ako príkladu

Začnime pravidlami Sigmy; tieto vytvárajú akýsi spoločný jazyk na vytváranie a zdieľanie kvalitných dopytov bez ohľadu na SIEM, ktorý vaša organizácia používa. Platforma Cymulate vytvorí pravidlá Sigma, aby ste si mohli stiahnuť tieto dotazy do svojho SIEM. To umožní tímom bezpečnostných operácií zostaviť prvky potrebné na detekciu budúcich útokov. Ako môžete vidieť nižšie v 3 V príkladoch je pravidlo Sigma rovnaké, no vlastný dotaz je špecificky určený pre daný jazyk SIEM. Kliknutím na tlačidlo môžete prepnúť na preferovaný SIEM.

Príklad 1: Spunk:

Príklad 2: Qradar:

Príklad 3: Azure Sentinel:

Aj keď sú pravidlá Sigma navrhnuté väčšinou pre dopyty, možno ich použiť na vytvorenie úplného pravidla SIEM alebo EDR proti útokom. V prípade útoku SolarWinds Sunburst a mnohých ďalších útokov sú pravidlá Cymulate Sigma dotazy, ktoré hľadajú IOB útoku. Každé sigma pravidlo požiada SIEM o IOB jednej fázy útoku.

Keď sa IOB z pravidiel sigma skombinujú, môže to viesť k špecifickému pravidlu pre cieľový systém – niečomu, čo môže s vysokou mierou istoty poukázať na útok bez toho, aby ste museli znova „vynájsť koleso“. Všetky požadované IOB sú na mieste – v pravidlách Sigmy – stačí natiahnuť ruku a vziať ich.

Pozrime sa na konkrétny prípad obnoveného útoku SolarWinds na Windows platformu a lovte ju spolu.

Lov SolarWinds na Microsoft Windows

Platforma Cymulate nám poskytuje možnosť replikovať útok dodávateľského reťazca, ktorý začína exportom poštovej schránky servera Exchange. Nasledujúce fázy útoku dostupné na platforme Cymulate na simuláciu útoku môžete vidieť na snímke obrazovky.

Prvá udalosť sa nespustí Windows, ale zapíše sa to do rôznych sieťových denníkov. Keďže samotná udalosť nemôže byť veľmi konkrétna, vo všeobecnom pravidle ju ponecháme ako nepovinnú. Pokračujme.

Ďalšou udalosťou útoku je sťahovanie obsahu pomocou PowerShell. Takáto udalosť môže byť monitorovaná pomocou Windows ID udalostí 4103 a 4104, ktoré môžu zobrazovať aj skutočný spustený kód, ale nechceme sa obmedzovať na konkrétnu metódu, pretože, priznajme si to: PowerShell nie je jediný nástroj, ktorý môže útočník použiť.

Všetky nástroje majú spoločné to, že pri sťahovaní obsahu sa v systéme vytvára objekt, na ktorý je Windows Udalosť ID 4663 s indikátorom prístupovej masky 0x1 alebo, ak používate Sysmon, Event ID 11.

Nižšie je všeobecná snímka obrazovky s ID udalosti 4663 so zvýraznenými príslušnými poľami. Toto je udalosť, ktorú deteguje pravidlo Cymulate Sigma a zároveň je to prvý IOB v pravidle, ktorý vytvoríme. Viac o tomto ID udalosti nájdete tu.

Ďalšia v poradí je ďalšia fáza útoku: Plánovač úloh: Maskovanie úloh spustených na windows uzamykacia obrazovka pre bočný pohyb. Opäť je irelevantné, ktoré úlohy sú maskované; dôležité je, že existujú Windows Identifikátory udalostí, ktoré nám môžu pomôcť identifikovať tento reťazec udalostí.

Identifikátory udalosti sú:

4698 – úloha vytvorená

4700 – Plánovaná úloha povolená.

4702 – Naplánovaná úloha bola aktualizovaná.

4699 – Naplánovaná úloha bola odstránená.

Čo je pre nás samozrejme relevantné, je, samozrejme, 4698, pretože sa objaví, keď sa vytvorí nová úloha. Udalosti aktualizácie, povolenia a/alebo odstránenia úlohy sú dobrým vylepšením, ale voliteľné. Osobne by som odporučil pridať možnosť 4699, pretože vždy existuje možnosť, že by útočník chcel po dokončení úlohu odstrániť, aby zakryl stopy.

Takže to, čo budeme chcieť pre minimálne požiadavky, je 4698 so sadou špecifických regulárnych výrazov v poli “Príkaz” v prípade, že sa zhodujú so známymi typmi spustiteľných súborov, napríklad:

– ‘.exe’ – ‘.py – ‘.ps1’ – ‘.msi – ‘.msp’ – ‘.mst’ – ‘.ws’ – ‘.wsf’ – ‘.vb’ – ‘.vbs’ – ‘ .jst’ – ‘.cmd’ – ‘.cpl’

V zložitých prípadoch je možné použiť regulárne výrazy, ako napríklad nižšie:

  1. – ‘^([A-Za-z0-9+/]{4})*([A-Za-z0-9+/]{3}=|[A-Za-z0-9+/]{2}==)?$’
  2. -‘^([A-Za-z0-9 /]{4})*([A-Za-z0-9 /]{3}=|[A-Za-z0-9 /]{2}==)?$’

Venujte zvláštnu pozornosť posledným dvom IOB (regexy): tieto zodpovedajú vzoru base64. Hoci „Plánovaná úloha“ prijíma reťazec ako vstup, je možné do neho napísať zahmlenú/šifrovanú formu príkazu. Napríklad „python“ ako príkaz a „base64.b64decode(nejaké užitočné zaťaženie base64)“ ako argument, čím sa vaša úloha efektívne zmení na nástroj „dekódovanie užitočného zaťaženia base64“.

Opäť platí, že všetky ukazovatele možno nájsť v pravidlách Sigma, ktoré dodáva Cymulate. Tento zoznam a ďalšie pripravované zoznamy IOB budeme nazývať len „relevantný zoznam IOB“ pre účely pohodlia. Nižšie je všeobecný pohľad na 4698 ID udalosti pri vytváraní novej úlohy.

Takže teraz sme pokryli dve udalosti v reťazci. Mali by sa vyskytovať na rovnakom počítači a s rovnakým používateľským menom. Potom sa spustí proces vo vašej úlohe, výsledkom čoho bude ID udalosti 4688 s názvom procesu tvorcu: TaskScheduler alebo TaskScheduler.dll alebo taskeng.exe (v závislosti od verzie zostavy, ktorú používate) a Názov nového procesu bude mať jeden z týchto IOB v zozname spustiteľných súborov. Takže v tejto fáze naše pravidlo vyzerá takto:

(4663 + prístupová maska ​​0x1)🡪 (4698 a príslušný zoznam IOB)🡪 (4688+zoznam relevantného názvu procesu tvorcu + zoznam relevantných IOB ako súčasť názvu nového procesu)

ALEBO

4663 + Prístupová maska ​​0x1 alebo Sysmon 11)🡪 [(4698 + relevant IOB list) 🡪(4688+(TaskScheduler.dll or taskeng.exe))]

Znak 🡪 predstavuje operáciu „nasleduje“.

Ďalšou fázou útoku je spustenie súboru DLL s rundll32. Ide o jednoduchý IOB, ktorý je mimochodom možné spustiť aj v predchádzajúcom kroku. V tomto konkrétnom prípade je to 4688+rundll.32

Ďalej je ADFind: Vyčíslenie skupiny AD pomocou ADFind Masqueraded ako csrss.exe. Tento krok je trochu zložitý. Počas tohto kroku útočník maskuje svoj enumeračný nástroj ako legitímny súbor. Avšak skôr, ako sa to stane, musí byť nelegitímny súbor zapísaný niekde na jeden z vašich diskov (najlepšie do systémového priečinka) s legitímnym názvom.

V tomto konkrétnom prípade je to csrss.exe, ale existuje pomerne veľké množstvo názvov súborov, ktoré by sa dali použiť na rovnaký účel, napríklad:

– ‘svchost.exe’. – rundll32.exe. – services.exe. – powershell.exe. – regsvr32.exe. – spoolsv.exe

– lsass.exe. – smss.exe. – csrss.exe. – conhost.exe. – wininit.exe. – winlogon.exe. – explorer.exe

– taskhost.exe. – Taskmgr.exe. – sihost.exe – RuntimeBroker.exe – smartscreen.exe.

Opäť nie je potrebné hľadať všetky, sú už dodané v príslušnom pravidle Sigma.

Nižšie je uvedený príklad jedného možného pravidla Sigma pre tento konkrétny krok, ktorý zisťuje vytvorenie súboru s jedným z vyššie uvedených názvov. Ale s hashom, ktorý je odlišný od originálu. Či už prepíšete systémový súbor alebo vytvoríte novú cestu, výsledkom bude stále ID udalosti 4663 (alebo ID udalosti Sysmon 11) a jeden z nižšie uvedených názvov sa bude nachádzať v užitočnej časti.

Práca so systémovými súbormi tiež vyžaduje privilegovaný prístup, takže nevyhnutne dôjde k eskalácii privilégií, čo je tiež zdokumentované ako 4688 ID udalosti (prístup k súboru) a typ zvýšenia tokenu %%1936 alebo %%1937, čo sú typy pre systémový a správcovský prístup resp.

Nižšie je snímka obrazovky s ID udalosti 4688 so zvýraznenými príslušnými poľami.

Voliteľne môžete vyhľadať 4672 Event ID s ktorýmkoľvek reťazcom eskalácie privilégií, ale udalosť eskalácie privilégií sa môže vyskytnúť v ktoromkoľvek kroku útoku. Na to odporúčame samostatné pravidlo, ktoré by malo korelovať s pravidlom, ktoré budujeme.

Pozrime sa na naše pravidlo v tejto fáze:

(4663 + prístupová maska ​​0x1 alebo Sysmon 11)🡪 [(4698 + relevant IOB list) 🡪(4688+(TaskScheduler.dll or taskeng.exe)) 🡪 (4688 and rundll32) 🡪 (4663 or Sysmon 11 + generic list of system files) 🡪 (4688 and 1 of files in list and Token Elevation Type (%%1936 OR %%1937))]

Ďalší krok je “Spustite PowerShell s kódovaním base64 z Windows RegistratúraČo sa stane, je, že útočník spustí zahmlený kód, ktorý bol predtým zapísaný do hodnoty databázy Registry. Ako viete, skôr ako to bude môcť urobiť, musí vytvoriť novú hodnotu databázy Registry alebo upraviť existujúcu.

A Windows udalosť ID 4657 a hodnota zodpovedajúca vzoru base64 (ktorý možno identifikovať pomocou regulárnych výrazov, ktoré sme už videli v predchádzajúcom kroku) môžu pomôcť identifikovať tento krok. Udalosť môže zahŕňať „Upravená existujúca hodnota databázy Registry“ alebo „Vytváranie novej hodnoty databázy Registry“. Typ operácie. Všetky IOB, ako už bolo spomenuté, je možné získať z dodaných pravidiel Sigma.

Táto udalosť vám môže ukázať ďalšie cenné informácie, ako napríklad:

1) O aký kľúč išlo.

Formát je: REGISTRYHIVEPATH kde:

ÚĽ:

  • HKEY_LOCAL_MACHINE = REGISTRYSTROJ
  • HKEY_CURRENT_USER = REGISTRYUSER[USER_SID], kde [USER_SID] je SID aktuálneho používateľa.
  • HKEY_CLASSES_ROOT = REGISTRYMACHINESOFTWAREClasses
  • HKEY_USERS = REGISTRYUSER
  • HKEY_CURRENT_CONFIG = REGISTRYMACHINESYSTEMControlSet001Hardware ProfilesCurrent

2) Aký je pôvodný proces.
3) Čo je stará hodnota a nová hodnota.

Nižšie si môžete pozrieť všeobecnú reprezentáciu 4657 Event ID.

Berúc do úvahy možné časové rámce, keďže celá operácia bude pravdepodobne naskriptovaná, môžeme s istotou povedať, že ak bude úspešná, kroky 2-6 nezaberie viac ako 5 sekúnd. Celý reťazec až do vykonania kódu uloženého v registri nemôže trvať dlhšie ako 10 minút.

Po pridaní týchto premenných máme reťazec udalostí, ktoré možno korelovať:

  1. Všetko vznikne na jednom stroji.
  2. Spustí sa ako rovnaký používateľ.
  3. Prevádzkové pravidlo bude vyzerať takto:

{

(4663 + prístupová maska ​​0x1 alebo Sysmon 11)🡪

[ (4698 + relevant IOB list) 🡪

(4688+(TaskScheduler.dll or taskeng.exe)) 🡪

(4688 and rundll32) 🡪

(4663 or Sysmon 11 + generic list of system files) 🡪

(4688 and 1 of files in list and Token Elevation Type(%%1936 OR %%1937))🡪 (4657 +New value created OR existing value modified+ base64 matching pattern in value in time frame up to 5s)]

v časovom rámci 10 minút

}

Takže teraz, ak ste vytvorili toto pravidlo SIEM alebo EDR pomocou pravidiel Sigma poskytovaných Cymulate a uvidíte z toho upozornenie – je veľká šanca, že práve teraz zažívate útok SolarWinds.

Ak máte stále pochybnosti, vždy môžete pridať nejaké voliteľné fázy a ešte viac ich vylepšiť pridaním dvoch ďalších fáz k pravidlu. Toto sú Čistenie exportu poštovej schránky servera Exchange a Exchange Exfiltration pomocou základnej požiadavky HTTP, resp.

Aj keď Windows nemá vstavané ID udalosti pre požiadavky HTTP/S, v poštovej schránke bude vždy {4660🡪 (požiadavka HTTP + 4663 súboru.zip/rar/tar/other)}. Na získanie udalosti HTTP/S požiadaviek tu môžu pomôcť ďalšie systémy, napríklad systém analýzy sieťovej prevádzky.

Optimalizujte svoje bezpečnostné operácie pomocou pravidiel Cymulate a Sigma

Ako ste videli v rozpise tohto konkrétneho útoku, môžete použiť IOB v pravidlách Sigma. To pomôže vašim bezpečnostným operáciám spochybňovať, hodnotiť, merať a optimalizovať. To sa dá jednoducho dosiahnuť pomocou platformy Cymulate vo všetkých oblastiach. Kroky uvedené v tomto článku sú určené na pomoc s optimalizáciou a sprievodcom, ako zabrániť útoku typu SolarWinds. Ako ste videli na platforme Cymulate, jednoduchý alebo zložitý scenár vám môže pomôcť s optimalizáciou vašich pravidiel SIEM alebo EDR. To zvýši bezpečnosť vašej organizácie proti najsofistikovanejším hrozbám s malým úsilím.

Pekný lov!

A ako sa hovorí v Hunger Games, “nech sú šance niekedy vo váš prospech.”

Tento článok napísal Michael Ioffe, hlavný bezpečnostný výskumník v Cymulate.