Ця стаття є першою частиною серії з аналізу Sysmon-загроз. Всі інші частини серії:
Частина 1. Ознайомлення з аналізом логів Sysmon (ми тут)
Частина 2. Використання даних із Sysmon подій для виявлення загроз
Частина 3. Поглиблений аналіз Sysmon-загроз за допомогою графів
Якщо ви займаєтеся інформаційною безпекою, напевно вам часто доводиться розбиратися в атаках, що відбуваються. Якщо у вас вже наметане око, ви можете пошукати нестандартну активність у «сирих» необроблених логах — скажімо, PowerShell-скрипт із запущеною або VBS-скрипт, що прикидається Word-файлом, просто прогортаючи останню активність в журналі подій Windows. Але це реально великий головний біль. На щастя, Microsoft створив Sysmon, що робить аналіз атак набагато простішим.
Бажаєте розібратися в базових ідеях, що стоять за погрозами, що відображаються в лозі Sysmon? Завантажте наше керівництво і ви розумієте, як інсайдери можуть непомітно спостерігати за іншими співробітниками. Основною проблемою роботи з журналом подій Windows відсутність інформації про батьківські процеси, тобто. з нього не можна зрозуміти ієрархію процесів. У записах лога Sysmon навпаки, містяться ідентифікатор процесу батька, його ім'я і командний рядок, що запускається. Дякую тобі, Microsoft.
У першій частині нашої серії ми подивимося, що можна зробити з базовою інформацією із Sysmon. У другій частині ми повністю скористаємося інформацією про батьківські процеси для створення більш комплексних структур відповідності, які відомі як графи загроз. У третій частині ми розглянемо простий алгоритм, який сканує граф загроз для пошуку нестандартної активності через аналіз ваги графа. А наприкінці як винагорода на вас чекає акуратний (і зрозумілий) ймовірнісний метод виявлення загроз.
Частина 1: Ознайомлення з аналізом логів Sysmon
Що допоможе розібратися у складностях журналу подій? Зрештою – SIEM. Вона здійснює нормалізацію подій і полегшує їх подальший аналіз. Але нам не обов'язково заходити так далеко, принаймні спочатку. На початку для розуміння принципів SIEM достатньо спробувати чудову безкоштовну утиліту Sysmon. І з нею напрочуд легко працювати. Так тримати Microsoft!
Які можливості у Sysmon?
Якщо коротко – корисна та читальна інформація про процеси (див. малюнки нижче). Ви виявите купу корисних деталей, яких немає в журналі подій Windows, але найголовніше – такі поля:
- ID процесу (у десятковій формі, а не hex!)
- ID батьківського процесу
- Командний рядок процесу
- Командний рядок батьківського процесу
- Хеш образу файлу
- Імена образів файлу
Sysmon встановлюється одночасно і як драйвер пристрою, і як служба – докладніше Її ключовою перевагою є можливість аналізу логів з декількох джерел, кореляція інформації та виведення результуючих значень в одну папку журналу подій, що знаходиться по дорозі Microsoft -> Windows -> Sysmon -> Operational. У моїх власних розслідуваннях логів Windows, від яких волосся стає дибки, мені постійно доводилося перемикатися між, скажімо, папкою з логами PowerShell, і папкою «Безпека», прогортаючи журнали подій у героїчній спробі якось зіставити значення між ними. Це ніколи не легке завдання, і як я потім зрозумів, краще було відразу запастися аспірином.
Sysmon робить якісний стрибок вперед, надаючи корисну (або як люблять говорити вендори – дієву) інформацію для допомоги в розумінні основних процесів. Наприклад, я запустив потайну сесію , що симулює рух розумного інсайдера всередині мережі. Ось що ви побачите в журналі подій Windows:
У журналі Windows видно якусь інформацію про процес, але вона малокорисна. Плюс ідентифікатори процесів у шістнадцятковій формі???
У професійного ІТ-фахівця з розумінням основ хакінгу має викликати підозру командний рядок. Використання cmd.exe для подальшого запуску іншої команди з перенаправленням виведення у файл з дивною назвою – це явно схоже на дії софту з контролю та управління : у такий спосіб створюється псевдо-шелл за допомогою служб WMI.
Тепер давайте поглянемо на еквівалент запису із Sysmon, звернувши увагу на те, скільки додаткової інформації вона нам дає:
Можливості Sysmon на одному скріншоті: детальна інформація про процес у читабельній формі
Ви не тільки бачите командний рядок, але й ім'я файлу, шлях до програми, що виконується, що Windows знає про це (“Windows Command Processor”), ідентифікатор батьківського процесу, командний рядок батька, що запустив cmd-шелл, а також реальне ім'я батьківського процесу файлу. Все в одному місці, нарешті!
З лога 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-подібний інтерфейс. Так, EQL витонченийале ми торкнемося його в третій частині.
Sysmon та аналіз графів
Давайте абстрагуємося і подумаємо, що ми щойно створили. По суті, у нас є база даних подій Windows, доступна через PowerShell. Як я зазначив раніше, між записами існують з'єднання або зв'язки через ParentProcessId, тому можна отримати повну ієрархію процесів.
Якщо ви читали серію то знаєте, що хакери люблять створювати складні багатоетапні атаки, у яких кожен процес виконує свою маленьку роль і готує плацдарм для наступного кроку. Такі речі дуже складно відловити просто з «сирого» лога.
Але з моєю командою Get-Sysmonlogs та додатковою структурою даних, яку ми розглянемо далі за текстом (звичайно ж, це граф), у нас з'явиться практичний спосіб виявити погрози – для чого потрібно лише виконати правильний пошук по вершинах.
Як завжди у наших DYI блог-проектах, чим більше ви працюєте над аналізом деталей загроз у невеликому масштабі, тим краще ви усвідомлюєте, наскільки складним є детектування загроз на рівні організації. І це усвідомлення є вкрай важливим моментом.
Ми зустрінемо перші цікаві складнощі в другій частині статті, де почнемо пов'язувати один з одним Sysmon-події в більш складні структури.
Джерело: habr.com