Tento článek je první částí série o analýze hrozeb Sysmon. Všechny ostatní části série:
Část 1. Úvod do analýzy logů Sysmon (jsme zde)
Část 2. Využití dat z událostí Sysmon k odhalení hrozeb
Část 3. Hluboká analýza hrozeb Sysmon pomocí grafů
Pokud se zabýváte kybernetickou bezpečností, pravděpodobně se často zabýváte aktuálními útoky. Pokud již máte trénované oko, můžete hledat neobvyklou aktivitu v "syrových" nezpracovaných logách — řekněme, PowerShell skript s běžící nebo VBS skript předstírající, že je souborem Word, — jednoduše procházením poslední aktivity v událostech Windows. Ale to je opravdu velká bolest hlavy. Naštěstí Microsoft vytvořil Sysmon, který analýzu útoků výrazně usnadňuje.
Chcete porozumět základním myšlenkám, které stojí za hrozbami zobrazovanými v logu Sysmon? Stáhněte si naši příručku a uvědomíte si, jak mohou insidéři nenápadně sledovat ostatní zaměstnance. Hlavním problémem práce s událostmi Windows je nedostatek informací o rodičovských procesech, tedy není možné pochopit hierarchii procesů. V záznamech logu Sysmon se naopak nachází identifikátor rodičovského procesu, jeho název a spouštěcí příkaz. Děkujeme ti, Microsoft.
V první části naší série se podíváme, co lze udělat se základními informacemi ze Sysmon. Ve druhé části plně využijeme informace o rodičovských procesech k vytvoření komplexnějších struktur shody, které jsou známé jako grafy hrozeb. Ve třetí části se podíváme na jednoduchý algoritmus, který prohledává graf hrozeb s cílem hledat neobvyklou aktivitu prostřednictvím analýzy "váhy" grafu. A na závěr vás čeká pěkná (a srozumitelná) pravděpodobnostní metoda detekce hrozeb.
Část 1: Úvod do analýzy logů Sysmon
Co pomůže pochopit složitosti protokolu událostí? Nakonec – SIEM. Ta provádí normalizaci událostí a usnadňuje jejich následnou analýzu. Ale nemusíme jít tak daleko, alespoň na začátku. Na úvod k pochopení principů SIEM bude stačit vyzkoušet vynikající bezplatnou utilitu Sysmon. S ní se překvapivě snadno pracuje. Tak dále, Microsoft!
Jaké má Sysmon možnosti?
Pokud to shrneme – užitečné a čitelné informace o procesech (viz obrázky níže). Objevíte spoustu užitečných detailů, které v protokolu událostí Windows nejsou, ale to nejdůležitější – následující pole:
- ID procesu (v desítkové formě, nikoli hex!)
- ID nadřazeného procesu
- Příkazový řádek procesu
- Příkazový řádek nadřazeného procesu
- Hash obrazu souboru
- Názvy obrazů souboru
Sysmon se instaluje současně jako ovladač zařízení a jako služba – podrobněji Jeho klíčovou výhodou je možnost analýzy logů z více než zdrojů, korelace informací a výstup výsledných hodnot do jedné složky protokolu událostí, nacházející se na cestě Microsoft -> Windows -> Sysmon -> Operativní. Při mých vlastních vyšetřováních logů Windows, kvůli kterým mi stávaly vlasy na hlavě, jsem stále musel přepínat mezi, řekněme, složkou s logy PowerShell a složkou „Bezpečnost“, projíždějíc protokoly událostí v hrdinské snaze jak nějakým způsobem porovnat hodnoty mezi nimi. To rozhodně není snadný úkol a jak jsem později pochopil, bylo by lepší si rovnou pořídit aspirin.
Sysmon však dělá kvalitní skok vpřed, poskytující užitečné (nebo jak to často nazývají prodejci – účinné) informace k pochopení základních procesů. Například jsem spustil skrytou relaci , simulující pohyb inteligentního insidera v síti. Zde je to, co uvidíte v protokolu událostí Windows:
V protokolu Windows je vidět nějaké informace o procesu, ale jsou málo užitečné. Navíc identifikátory procesů v šestnáctkové formě???
U profesionálního IT specialisty s pochopením podstaty hackingu by měla vyvolat podezření příkazový řádek. Použití cmd.exe k následnému spuštění jiného příkazu s přesměrováním výstupu do souboru s podivným názvem vypadá zjevně jako činnost softwaru pro sledování a řízení. : tímto způsobem se vytváří pseudo-shell pomocí služeb WMI.
Nyní se podívejme na ekvivalentní zápis ze Sysmonu, s důrazem na to, kolik dodatečných informací nám poskytuje:
Možnosti Sysmonu na jednom snímku obrazovky: detailní informace o procesu ve čitelné formě
Nejenže vidíte příkazový řádek, ale také název souboru, cestu k spouštěné aplikaci, co o tom Windows ví (“Windows Command Processor”), identifikátor rodičovského procesu, příkazový řádek rodiče, který spustil cmd-shell, a také skutečný název souboru rodičovského procesu. Vše na jednom místě, konečně!
Z logu Sysmon můžeme usoudit, že s vysokou pravděpodobností tento podezřelý příkazový řádek, který jsme viděli v „surových“ logách, není výsledkem normální činnosti zaměstnance. Spíše naopak, byl generován procesem podobným C2 — wmiexec, jak jsem zmínil dříve — a byl přímo vytvořen procesem služby WMI (WmiPrvSe). Nyní máme indikátor toho, že vzdálený útočník nebo insidér zkoumá firemní infrastrukturu.
Představujeme Get-Sysmonlogs
Samozřejmě je skvělé, když Sysmon shromažďuje logy na jednom místě. Ale bylo by také lepší, kdybychom měli přístup k jednotlivým políčkům logu programově – například prostřednictvím příkazů PowerShell. V takovém případě by bylo možné napsat malý PowerShell skript, který by automatizoval hledání potenciálních hrozeb!
Nejsem první, kdo na to přišel. A je dobře, že v některých příspěvcích na fórech a GitHub už bylo vysvětleno, jak používat PowerShell pro parsování Sysmon logu. V mém případě jsem chtěl vyhnout se nutnosti psát jednotlivé řádky parsovacího skriptu pro každé pole Sysmonu. Proto jsem použil princip lenochoda a, jak se domnívám, nakonec vymyslel něco zajímavého.
Prvním důležitým bodem je schopnost příkazu číst Sysmon logy, filtrovat potřebné události a výstup do PS proměnné, jako zde:
$events = Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 -or $_.id -eq 11}
Pokud chcete sami zkontrolovat činnost týmu, můžete pomocí zobrazení obsahu v prvním prvku pole $events, $events[0].Message, získat řadu textových řetězců v jednoduchém formátu: jméno pole Sysmon, dvojtečka a poté samotná hodnota.
Hurá! Výstup Sysmon logu připravený k formátu JSON.
Myslíte na to samé, co já? Pokusíme-li se o trochu více úsilí, můžeme převést výstup na formátovaný JSON řetězec a následně ho přímo načíst do PS-objektu pomocí mocného příkazu. .
Ukážu PowerShell kód pro konverzi — je velmi jednoduchý — v další části. Zatím se podívejme, co může dělat můj nový příkaz s názvem get-sysmonlogs, který jsem nainstaloval jako PS modul.
Místo hloubkového analýzy logů Sysmon prostřednictvím nepohodlného rozhraní protokolu událostí můžeme snadno vyhledávat inkrementální aktivitu přímo z PowerShell relace a také použít PS příkaz. (alias – „?“) pro zkrácení výsledků:
Seznam cmd shellů spuštěných přes WMI. Analýza hrozeb levně pomocí našeho vlastního příkazu Get-Sysmonlogs.
Úžasné! Vytvořil jsem nástroj pro dotazování Sysmon logu, jako by to byla databáze. V našem článku o bylo zmíněno, že tuto funkci vykoná popsaný skvělý nástroj, i když oficiálně za skutečného SQL-podobného rozhraní. Ano, EQL je elegantní, ale k tomu se vrátíme ve třetí části.
Sysmon a analýza grafů
Pojďme se abstrahovat a zamyslet nad tím, co jsme právě vytvořili. V podstatě nyní máme databázi událostí Windows, dostupnou prostřednictvím PowerShell. Jak jsem již dříve uvedl, mezi záznamy existují spojení nebo vazby — prostřednictvím ParentProcessId — takže můžeme získat úplnou hierarchii procesů.
Pokud jste četli sérii víte, že hackeři rádi vytvářejí složité vícestupňové útoky, kde každý proces plní svou malou roli a připravuje půdu pro další krok. Tyto věci jsou velmi těžké zachytit pouze z „syrového“ logu.
Ale s mým příkazem Get-Sysmonlogs a dodatečnou datovou strukturou, kterou prozkoumáme dále (pochopitelně, to bude graf), budeme mít praktický způsob, jak odhalit hrozby – k čemuž stačí provést správné hledání v oblastech.
Jak je obvyklé v našich DYI blogových projektech, čím více pracujete na analýze drobných hrozeb, tím jasněji si uvědomujete, jak složité je detekování hrozeb na úrovni organizace. Tento pocit je zásadní. důležitým bodem.
První zajímavé komplikace se setkáme ve druhé části článku, kde začneme spojovat Sysmon události do mnohem složitějších struktur.
Zdroj: habr.com
