Průvodce analýzou hrozeb sysmon, část 1

Průvodce analýzou hrozeb sysmon, část 1

Tento článek je první částí série o analýze hrozeb Sysmon. Všechny další díly seriálu:

Část 1. Úvod do analýzy protokolů Sysmon (Jsme zde)
Část 2: Použití dat událostí systému Sysmon k identifikaci hrozeb
Část 3: Hluboká analýza hrozeb systému s grafy

Pokud pracujete v informační bezpečnosti, pravděpodobně často musíte rozumět probíhajícím útokům. Pokud již máte trénované oko, můžete v „surových“ nezpracovaných protokolech hledat nestandardní aktivitu – řekněme běžící skript PowerShellu pomocí příkazu DownloadString nebo skript VBS vydávající se za soubor aplikace Word pouhým procházením poslední aktivity v protokolu událostí systému Windows. Ale je to opravdu velká bolest hlavy. Naštěstí Microsoft vytvořil Sysmon, díky kterému je analýza útoků mnohem jednodušší.

Chcete porozumět základním myšlenkám za hrozbami zobrazenými v protokolu Sysmon? Stáhněte si našeho průvodce Události WMI jako prostředek špehování a uvědomíte si, jak mohou zasvěcenci tajně pozorovat ostatní zaměstnance. Hlavním problémem práce s protokolem událostí Windows je nedostatek informací o nadřazených procesech, tzn. nelze z něj pochopit hierarchii procesů. Položky protokolu sysmon na druhé straně obsahují ID nadřazeného procesu, jeho název a příkazový řádek, který se má spustit. Děkuji, Microsoft.

V prvním díle našeho seriálu uvidíme, co dokážeme se základními informacemi od Sysmonu. Ve druhé části plně využijeme informace nadřazeného procesu k vytvoření složitějších struktur dodržování předpisů známých jako grafy hrozeb. Ve třetí části se podíváme na jednoduchý algoritmus, který pomocí analýzy „váhy“ grafu skenuje graf hrozeb na nestandardní aktivitu. A nakonec za odměnu najdete úhlednou (a srozumitelnou) pravděpodobnostní metodu pro odhalování hrozeb.

Část 1: Úvod do Sysmon Log Analysis

Co vám může pomoci pochopit složitost protokolu událostí? Nakonec - SIEM. Normalizuje události a zjednodušuje jejich následnou analýzu. Ale nemusíme chodit tak daleko, alespoň ne zpočátku. Na začátku, abyste pochopili principy SIEM, bude stačit vyzkoušet úžasnou bezplatnou utilitu Sysmon. A překvapivě snadno se s ní pracuje. Jen tak dál, Microsoft!

Jaké jsou vlastnosti systému Sysmon?

Zkrátka užitečné a čitelné informace o procesech (viz obrázky níže). Najdete zde spoustu užitečných podrobností, které nejsou v protokolu událostí Windows, ale nejdůležitější jsou následující pole:

  • ID procesu (v desítkové soustavě, nikoli hex!)
  • ID nadřazeného procesu
  • Zpracovat příkazový řádek
  • Příkazový řádek nadřazeného procesu
  • Soubor hash obrázku
  • Názvy obrázků souborů

Sysmon se instaluje jako ovladač zařízení i služba současně – zjistěte více zde. Jeho klíčovou výhodou je schopnost analyzovat logy z několik zdroje, korelace informací a výstup výsledných hodnot v jedné složce protokolu událostí umístěné podél cesty Microsoft -> Windows -> Sysmon -> Provozní. Při mém vlastním přitahujícím zkoumání protokolů Windows jsem zjistil, že neustále musím přepínat mezi, řekněme, složkou protokolů PowerShell a složkou Zabezpečení, listovat protokoly událostí ve statečné snaze nějak korelovat hodnoty mezi těmito dvěma . To není nikdy snadný úkol, a jak jsem si později uvědomil, bylo lepší okamžitě se zásobit aspirinem.

Na druhou stranu Sysmon dělá kvalitativní skok vpřed tím, že poskytuje užitečné (nebo, jak dodavatelé rádi říkají, použitelné) informace, které vám pomohou pochopit základní procesy. Například jsem zahájil skrytou relaci wmiexec, simulující pohyb chytrého zasvěcence v rámci sítě. Toto uvidíte v protokolu událostí systému Windows:

Průvodce analýzou hrozeb sysmon, část 1

Některé informace o procesu jsou viditelné v protokolu Windows, ale jsou málo použitelné. Plus ID procesů v hex???

Pro profesionálního IT profesionála, který rozumí základům hackování, by měl být příkazový řádek podezřelý. Použití cmd.exe k následnému spuštění dalšího příkazu a přesměrování výstupu do souboru s podivným názvem je jasně podobné akcím monitorovacího a ovládacího softwaru příkaz a řízení (C2): Tímto způsobem je pomocí služeb WMI vytvořen pseudo shell.
Nyní se podívejme na ekvivalent položky Sysmon a všimněme si, kolik dalších informací nám poskytuje:

Průvodce analýzou hrozeb sysmon, část 1

Funkce sysmon na jednom snímku obrazovky: podrobné informace o procesu v čitelné podobě

Nevidíte pouze příkazový řádek, ale také název souboru, cestu ke spustitelné aplikaci, co o ní Windows ví („Windows Command Processor“), identifikátor rodičovský proces, příkazový řádek rodič, který spustil shell cmd, a také skutečný název souboru nadřazeného procesu. Konečně vše na jednom místě!
Ze Sysmon logu můžeme usoudit, že s vysokou mírou pravděpodobnosti tento podezřelý příkazový řádek, který jsme viděli v „surových“ logech, není výsledkem běžné práce zaměstnance. Spíše byl generován procesem podobným C2 - wmiexec, jak jsem již zmínil - a byl přímo vytvořen procesem WMI služby (WmiPrvSe). Nyní máme indikátor, že vzdálený útočník nebo zasvěcenec zkouší firemní infrastrukturu na zub.

Představujeme Get-Sysmonlogs

Samozřejmě je skvělé, když Sysmon ukládá protokoly na jedno místo. Ještě lepší by ale asi bylo, kdybychom mohli k jednotlivým polím logu přistupovat programově – například přes příkazy PowerShellu. V tomto případě byste mohli napsat malý skript PowerShell, který by automatizoval vyhledávání potenciálních hrozeb!
Nebyl jsem první, kdo měl tento nápad. A je dobře, že v některých příspěvcích na fóru a GitHubu projekty Již bylo vysvětleno, jak použít PowerShell k analýze protokolu Sysmon. V mém případě jsem se chtěl vyhnout nutnosti psát samostatné řádky skriptu analýzy pro každé pole Sysmon. Použil jsem tedy princip lenocha a myslím, že jsem ve výsledku přišel s něčím zajímavým.
Prvním důležitým bodem je schopnost příkazu Získejte-WinEvent čtěte protokoly Sysmon, filtrujte potřebné události a zobrazte výsledek v proměnné PS, jako je tato:

$events = Get-WinEvent  -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 -or $_.id -eq 11}

Pokud chcete příkaz sami otestovat, zobrazením obsahu v prvním prvku pole $events, $events[0]. Zpráva, výstupem může být řada textových řetězců ve velmi jednoduchém formátu: název Pole sysmon, dvojtečka a pak samotná hodnota.

Průvodce analýzou hrozeb sysmon, část 1

Hurá! Výstup protokolu sysmon ve formátu připraveném na JSON

Myslíš na to samé co já? S trochou většího úsilí můžete výstup převést na řetězec ve formátu JSON a poté jej načíst přímo do objektu PS pomocí výkonného příkazu Převést z-Json .
Kód PowerShellu pro převod – je to velmi jednoduché – ukážu v příštím díle. Prozatím se podívejme, co umí můj nový příkaz s názvem get-sysmonlogs, který jsem nainstaloval jako modul PS.
Namísto toho, abychom se hlouběji zabývali analýzou protokolů Sysmon prostřednictvím nepohodlného rozhraní protokolu událostí, můžeme bez námahy vyhledávat přírůstkovou aktivitu přímo z relace PowerShellu a také použít příkaz PS. kde (alias - "?"), chcete-li zkrátit výsledky vyhledávání:

Průvodce analýzou hrozeb sysmon, část 1

Seznam shellů cmd spuštěných přes WMI. Analýza hrozeb levně s naším vlastním týmem Get-Sysmonlogs

Úžasné! Vytvořil jsem nástroj pro dotazování protokolu Sysmon, jako by to byla databáze. V našem článku o EQL bylo poznamenáno, že tuto funkci bude provádět cool utilita v ní popsaná, i když formálně přes skutečné rozhraní podobné SQL. Ano, ECL elegantní, ale toho se dotkneme až ve třetím díle.

Systémová a grafová analýza

Udělejme krok zpět a zamysleme se nad tím, co jsme právě vytvořili. V podstatě máme nyní databázi událostí Windows přístupnou prostřednictvím PowerShellu. Jak jsem již dříve poznamenal, mezi záznamy existují spojení nebo vztahy – prostřednictvím ParentProcessId – takže lze získat kompletní hierarchii procesů.

Pokud jste četli sérii „Dobrodružství nepolapitelného malwaru“ pak víte, že hackeři rádi vytvářejí složité vícefázové útoky, ve kterých každý proces hraje svou malou roli a připravuje odrazový můstek pro další krok. Takové věci se jen ze „syrové“ klády chytají extrémně těžko.
Ale s mým příkazem Get-Sysmonlogs a další datovou strukturou, na kterou se podíváme později v textu (samozřejmě graf), máme praktický způsob, jak detekovat hrozby – vše, co je potřeba, je provést řádné vyhledávání vrcholů. .
Jako vždy u našich blogových projektů DYI, čím více budete pracovat na analýze detailů hrozeb v malém měřítku, tím více si uvědomíte, jak složitá je detekce hrozeb na podnikové úrovni. A toto vědomí je extrémně důležitý bod.

Na první zajímavé složitosti narazíme v druhé části článku, kde začneme Sysmon události vzájemně propojovat do mnohem složitějších struktur.

Zdroj: www.habr.com

Přidat komentář