Тази статия е първата част от поредица за анализ на заплахите на Sysmon. Всички останали части от поредицата:
Част 1. Въведение в анализирането на логовете на Sysmon (ние сме тук)
Част 2. Използване на данни от Sysmon събития за откриване на заплахи
Част 3: Дълбок анализ на заплахите на Sysmon с графики
Ако се занимавате с информационна сигурност, вероятно често трябва да разбирате текущите атаки. Ако вече имате тренирано око, можете да потърсите нестандартна дейност в "суровите" необработени регистрационни файлове - да речем, работещ скрипт на PowerShell или VBS скрипт, който се представя за файл на Word само чрез превъртане през най-новата активност в регистрационния файл на събитията на Windows. Но това е наистина голямо главоболие. За щастие Microsoft създаде Sysmon, който прави анализа на атаки много по-лесен.
Искате ли да разберете основните идеи зад заплахите, показани в журнала на Sysmon? Изтеглете нашето ръководство и осъзнавате как вътрешните хора могат тайно да шпионират други служители. Основният проблем при работата с регистъра на събитията на Windows е липсата на информация за родителските процеси, т.е. от него е невъзможно да се разбере йерархията на процесите. Записите в журнала на Sysmon, от друга страна, съдържат идентификатора на родителския процес, неговото име и командния ред, който се изпълнява. Благодаря ви Microsoft.
В първата част от нашата поредица ще видим какво можем да направим с основна информация от Sysmon. Във втора част ще се възползваме напълно от информацията за родителския процес, за да създадем по-сложни структури за съответствие, известни като графики на заплахи. В третата част ще разгледаме прост алгоритъм, който сканира графиката на заплахите за нестандартна активност чрез анализ на „тежестта“ на графиката. И накрая, като награда, ще намерите чист (и разбираем) вероятностен метод за откриване на заплахи.
Част 1: Представяне на Sysmon Log Analysis
Какво ще ви помогне да разберете сложността на регистъра на събитията? В крайна сметка, SIEM. Той нормализира събитията и опростява последващия им анализ. Но не е нужно да отиваме толкова далеч, поне в началото. В началото, за да разберете принципите на SIEM, ще бъде достатъчно да опитате чудесната безплатна помощна програма Sysmon. И е изненадващо лесна за работа. Продължавай все така, Microsoft!
Какви са характеристиките на Sysmon?
Накратко полезна и четивна информация за процесите (вижте снимките по-долу). Ще намерите куп полезни подробности, които не са в регистъра на събитията на Windows, но най-важните са следните полета:
- ID на процеса (в десетичен, а не в шестнадесетичен!)
- ID на родителския процес
- Процес на команден ред
- Команден ред на родителски процес
- Хеш на изображението на файла
- Имена на изображения на файлове
Sysmon се инсталира едновременно като драйвер на устройство и услуга - научете повече Основното му предимство е възможността да анализира регистрационни файлове от няколко източници, корелация на информация и извеждане на получените стойности в една папка на регистъра на събитията, разположена по пътя Microsoft -> Windows -> Sysmon -> Operational. В моите собствени настръхващи коси разследвания на регистрационните файлове на Windows постоянно трябваше да превключвам между, да речем, папката с регистрационни файлове на PowerShell и папката за защита, превъртайки през регистрационните файлове на събитията в героичен опит да картографирам по някакъв начин стойностите между тях. Това никога не е лесна задача и както по-късно разбрах, беше по-добре веднага да се запася с аспирин.
Sysmon, от друга страна, прави качествен скок напред, като предоставя полезна (или, както продавачите обичат да казват, приложима) информация, за да ви помогне да разберете основните процеси. Например стартирах скрита сесия , който симулира движението на интелигентен вътрешен човек в мрежата. Ето какво ще видите в регистъра на събитията на Windows:
Част от информацията за процеса се вижда в регистрационния файл на Windows, но няма голяма полза. Плюс идентификатори на процеси в шестнадесетичен???
За професионален ИТ специалист с разбиране на основите на хакването, командният ред трябва да е подозрителен. Използване на cmd.exe за след това изпълнение на друга команда с изход, пренасочен към файл със странно име - това е очевидно подобно на действията на софтуера за контрол и управление : По този начин се създава псевдо обвивка с помощта на WMI услуги.
Сега нека да разгледаме еквивалента на запис в Sysmon, като отбележим колко допълнителна информация ни дава:
Функции на Sysmon в една екранна снимка: подробна информация за процеса в четима форма
Вие не само виждате командния ред, но и името на файла, пътя до изпълнимото приложение, какво Windows знае за него („Команден процесор на Windows“), идентификатора родителски процес, команден ред родител, който стартира cmd shell, както и истинското име на файла на родителския процес. Всичко на едно място, най-накрая!
От дневника на Sysmon можем да заключим, че с голяма степен на вероятност този подозрителен команден ред, който видяхме в "суровите" дневници, не е резултат от нормалната работа на служителя. По-скоро е генериран от C2-подобен процес - wmiexec, както споменах по-рано - и е директно зароден от WMI процеса на услугата (WmiPrvSe). Сега имаме индикатор, че отдалечен нападател или вътрешен човек опитва корпоративната инфраструктура за зъб.
Представяме ви Get-Sysmonlogs
Разбира се, страхотно е, когато Sysmon има регистрационни файлове на едно място. Но вероятно би било още по-добре, ако можем да осъществяваме достъп до отделни регистрационни полета програмно - например чрез команди на PowerShell. В този случай би било възможно да се напише малък PowerShell скрипт, който да автоматизира търсенето на потенциални заплахи!
Не бях първият, който има тази идея. И е добре, че в някои публикации във форума и GitHub вече беше обяснено как да използвате PowerShell за анализиране на журнала на Sysmon. В моя случай исках да избегна необходимостта да пиша отделни редове от скрипт за анализиране за всяко поле на Sysmon. Така че използвах принципа на мързеливия човек и мисля, че измислих нещо интересно като резултат.
Първият важен момент е способността на командата прочетете регистрационните файлове на Sysmon, филтрирайте необходимите събития и покажете резултата в PS променлива, като това:
$events = Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 -or $_.id -eq 11}
Ако искате сами да тествате командата, като покажете съдържанието в първия елемент на масива $events, $events[0].Message, можете да изведете поредица от текстови низове с много прост формат: името на Sysmon поле, двоеточие и след това самата стойност.
Ура! Извеждане на лог на Sysmon във формат, готов за JSON
Мислиш ли същото като мен? С малко повече усилия можете да конвертирате изхода в JSON-форматиран низ и след това да го заредите директно в PS обект с мощната команда .
Ще покажа кода на PowerShell за преобразуването – той е много прост – в следващата част. Засега нека да разгледаме какво може да прави новата ми команда, наречена get-sysmonlogs, която инсталирах като PS модул.
Вместо да копаем по-дълбоко в анализа на журнала на Sysmon чрез неудобния интерфейс на журнала на събитията, можем безпроблемно да търсим инкрементална активност директно от сесия на PowerShell и също да използваме командата PS (псевдоним - "?"), за да съкратите резултатите от търсенето:
Списък на cmd обвивки, стартирани чрез WMI. Евтин анализ на заплахи с нашия собствен екип Get-Sysmonlogs
чудесно! Създадох инструмент за анкетиране на журнал на Sysmon, сякаш беше база данни. В нашата статия за беше отбелязано, че тази функция ще се изпълнява от страхотната помощна програма, описана в нея, макар и формално чрез истински интерфейс, подобен на SQL. Да, ECL грациозен, но ще го засегнем в третата част.
Sysmon и анализ на графики
Нека се абстрахираме и помислим за това, което току-що създадохме. По същество вече имаме база данни за събития на Windows, достъпна чрез PowerShell. Както отбелязах по-рано, има връзки или релации между записите - чрез ParentProcessId - така че можете да получите пълна йерархия от процеси.
Ако сте чели поредицата тогава знаете, че хакерите обичат да създават сложни многоетапни атаки, в които всеки процес играе своята малка роля и подготвя трамплин за следващата стъпка. Такива неща са изключително трудни за улавяне само от "суровия" дневник.
Но с моята команда Get-Sysmonlogs и допълнителна структура от данни, която ще разгледаме по-късно в текста (графика, разбира се), имаме практичен начин за откриване на заплахи - всичко, което се изисква, е да извършим правилно търсене на върхове .
Както винаги в нашите DYI блог проекти, колкото повече работите върху анализирането на детайлите на заплахите в малък мащаб, толкова повече ще осъзнавате колко трудно е откриването на заплахи на ниво организация. И това осъзнаване е изключително важен момент.
Ще се сблъскаме с първите интересни сложности във втората част на статията, където ще започнем да свързваме събития на Sysmon едно с друго в много по-сложни структури.
Източник: www.habr.com