Аудит событий в Windows с помощью Sysmon

Наша практика показала, что для полноценного анализа подозрительных событий в сети зачастую штатных средств ведения логов не хватает, особенно если мы говорим о целевых атаках на организации. Сегодня мы поговорим об аудите событий в Windows с помощью утилиты Sysmon.

Еще по теме: Утилиты аудита безопасности Windows

Утилита Sysmon может выступать высоко перспективным решением, возможности применения которого, на наш взгляд, будут ограничиваться только фантазией конечного специалиста по защите информации.

Аудит событий в Windows с помощью Sysmon

Утилиту Sysmon можно загрузить с сайта Microsoft из раздела Windows Sysinternals. В составе инструментов Windows Sysinternals автором которых является всеми известный Марк Руссинович и Со есть еще много очень полезных утилит, так что найдите время и ознакомьтесь с ними получше. Плюс загляните в подборку материалов на GitHub.

Но для этой инструкции мы будем использовать специальную готовую сборку с GitHub, включающую конфигурационный файл Sysmon Threat Intelligence Configuration от ION-STORM. Она ориентирована именно на выявление инцидентов информационной безопасности и может выступить хорошей базой для создания своих собственных файлов конфигурации.

Утилиту Sysmon вы можете установить вручную на каждое рабочее место или с использовав групповую политику (Group Policy) в домене. В данном конфигурационном файле указываются в большинстве своем полные стандартные пути для ряда программного обеспечения:

1 2	<Image condition="is">C:\Program Files\OpenVPN\bin\openvpn-gui.exe</Image> <ImageLoaded condition="contains">C:\Program Files (x86)\Notepad++</ImageLoaded>

Таким образом, в конкретной ИТ-инфраструктуре это может потребовать определенного тюнинга, так как, например, согласно корпоративной политике программы могут устанавливаться на диск D:\, а не на C:\. Инструментарий настолько гибкий, что можно задавать любые конструкции, нацеленные на то, чтобы отслеживать определенные действия или исключать их из вашего поля зрения.

После установки вы получите новый журнал (Channel) Microsoft-Windows-Sysmon/Operational, в котором Sysmon выделяет 18 категорий задач (Task Category), среди них: Process Create, Network Connect, Driver Load, ProcessAccess, File Create.

Аудит сетевого взаимодействия

Перейдем к использованию Sysmon. Представьте сетевое взаимодействие между двумя узлами сети: узел А обращается к узлу Б, и это обращение не является легальным, то есть возникает подозрение на ИБ-инцидент. Искать следы данного сетевого взаимодействия в операционной системе начнут последний момент, а начнут именно с активного сетевого оборудования. Что нам скажет межсетевой экран или маршрутизатор, если он контролирует это сетевое взаимодействие?

1	<190>%ASA-6-302014: Teardown TCP connection 2047052539 for outside:IP_1/60307 (DOMAIN\USER_NAME) to dmz-0:IP_2/22 duration 0:00:16 bytes 5675 TCP FINs (USER_NAME)

Видим только, кто IP_1 и куда IP_2. По большому счету тут потребуются дополнительные усилия: придется в полуавтоматическом или ручном режиме анализировать узел А (IP_1), чтобы найти реальный источник сетевой активности.

Нужно помнить, что если сетевая активность не выходит за пределы сегмента сети, контролируемого межсетевым экраном, или на данном межсетевом экране на регистрируются соответствующие события, что зачастую и бывает, то ничего найти в логах не получится.

Предположим, вам удалось применить в этот момент еще и сниффер или заблаговременно ответвить трафик через SPAN-порт и сформировать PCAP-файл. Что это даст?

Мы видим, кто, куда и, если очень повезет, с помощью чего, то есть в данном случае PuTTY. Но здесь нет ни места установки приложения, ни имени исполняемого файла, ни когда он был создан. В случае PuTTY это может показаться надуманными атрибутами, но если вы ищете следы несанкционированных действий и/или вредоноса, то это уже очень важные вещи. Плюс вредонос может «представиться» легальным приложением и подтолкнуть вас закрыть данный ИБ-инцидент как ложное срабатывание (false positive), приняв решение только на основании полученного из дампа сетевого трафика имени приложения.

Теперь посмотрим в канал Microsoft-Windows-Sysmon/Operational. В нем есть следующее событие:

Network connection detected:

UtcTime: 2018-02-08 11:33:49.672

ProcessGuid: {4e1a728b-358a-5a7c-0000-00108901d000}

ProcessId: 4636

Image: C:\Users\USER_NAME\Desktop\putty.exe

User: DOMAIN\USER_NAME

Protocol: tcp

Initiated: true

SourceIsIpv6: false

SourceIp: IP_1

SourceHostname: COMP_NAME.DOMAIN

SourcePort: 60307

SourcePortName:

DestinationIsIpv6: false

DestinationIp: IP_2

DestinationHostname:

DestinationPort: 22

DestinationPortName: ssh

Видим, кто, куда, с помощью чего, а также дополнительные параметры сетевого взаимодействия (протокол, порт). Теперь в этом же канале по значению поля ProcessGuid найдем событие категории Process Create, чтобы получить больше информации непосредственно об источнике данной сетевой активности:

Process Create:

UtcTime: 2018-02-08 11:33:30.583

ProcessGuid: {4e1a728b-358a-5a7c-0000-00108901d000}

ProcessId: 4636

Image: C:\Users\USER_NAME\Desktop\putty.exe

CommandLine: "C:\Users\USER_NAME\Desktop\putty.exe"

CurrentDirectory: C:\Users\USER_NAME\Desktop\

User: DOMAIN\USER_NAME

LogonGuid: {4e1a728b-268c-5a7c-0000-0020d3a20600}

LogonId: 0x6A2D3

TerminalSessionId: 1

IntegrityLevel: Medium

Hashes: SHA256=7AFB56DD48565C3C9804F683C80EF47E5333F847F2D3211EC11ED13AD36061E1,IMPHASH=EFE162FD3D51DED9DD66FA4AC219BF53

ParentProcessGuid: {4e1a728b-268d-5a7c-0000-001023de0600}

ParentProcessId: 3632

ParentImage: C:\Windows\explorer.exe

ParentCommandLine: C:\Windows\Explorer.EXE

Видим, что создан процесс, в том числе определено хеш-значение файла-прародителя данного процесса. Теперь вы можете проверить по хешу этот файл:

по корпоративным «белым спискам» разрешенного программного обеспечения;
на соответствие эталону на веб-сайте производителя данного программного обеспечения;
в рейтингах сервиса Threat Intelligence;
на ресурсах типа VirusTotal.

Стоит отметить, что на тех узлах сети, где есть ограничения на установку средств антивирусной защиты (терминалы диспетчеров, технологические АРМ и тому подобное), анализ хешей — в том числе автоматизированный, путем сопоставления данных от сервисов Threat Intelligence, к примеру в системе класса Security Information and Event Management (SIEM), — может выступать вполне действенной компенсирующей мерой для борьбы с вредоносным программным обеспечением.

Развивая тематику отслеживания действий, связанных с файлами, нужно отметить, что по умолчанию указанный файл конфигурации позволяет отслеживать создание в операционной системе файлов, которые могут быть потенциальным источником ИБ-инцидентов, например цифровых сертификатов, исполняемых файлов, файлов библиотек, PowerShell-файлов, RDP-файлов, файлов MS Office с поддержкой макросов, а также файлов, создаваемых в определенных каталогах файловой системы:

File created:

UtcTime: 2018-02-08 11:50:39.893

ProcessGuid: {4e1a728b-283b-5a7c-0000-00107b384a00}

ProcessId: 2780

Image: C:\Program Files\Microsoft Office\Office15\WINWORD.EXE

TargetFilename: C:\Users\USER_NAME\Desktop\Doc1.docm

CreationUtcTime: 2018-02-08 11:50:39.893

Файлы или действия, которые ведут к изменению параметров реестра, также подлежат протоколированию. Например, ассоциация типа файла DOCM, который был впервые использован в операционной системе при создании файла Doc1.docm (см. пример выше), с приложением MS Word:

Registry value set:

EventType: SetValue

UtcTime: 2018-02-08 11:50:40.550

ProcessGuid: {4e1a728b-268d-5a7c-0000-001023de0600}

ProcessId: 3632

Image: C:\Windows\Explorer.EXE

TargetObject: \REGISTRY\USER\S-1-5-21-1626002472-1445367128-3583509536-1113\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.docm\OpenWithList\a

Details: WINWORD.EXE

Для безопасника это может представлять интерес, когда вредоносный файл производит переассоциацию легально закрепленных корпоративных приложений для определенных типов файлов и тем самым «навязывает» использование уязвимого приложения.

Еще пример: изменение ключей реестра операционной системы, влияющих на параметры загрузки операционной системы, чтобы снизить уровень ее защищенности после очередной перезагрузки (отключение средств антивирусной защиты или других средств защиты информации).

Централизация сбора и хранения событий

Чтобы обеспечить централизованный сбор и хранение событий из логов всех узлов сети, в том числе сократить злоумышленнику возможности очищать логи на атакуемом узле, практикуется консолидация данных на выделенном узле. На этом узле должна быть запущена служба Windows Event Collector. В итоге события будут отображаться в журнале Forwarded Events.

Нужно сделать следующие шаги на каждом рабочем месте либо с использованием групповых политик в домене:

Добавить пользователя, от имени которого будут собираться события «COLLECTOR», в локальную группу «Event log reader».
Выполнить от имени администратора (Run as) команду

1

winrm quickconfig -quiet
Выполнить от имени администратора (Run as) команду

1

wevtutil get-log Microsoft-Windows-Sysmon/Operational

и получить строку channelAccess: DATA.
Выполнить от имени администратора (Run as) команду

1

wmic useraccount where name='COLLECTOR' get sid

и получить UID_COLLECTOR.
Выполнить от имени администратора (Run as) команду

1

wevtutil set-log Microsoft-Windows-Sysmon/Operational /ca: DATA(A;;0x1;;;UID_COLLECTOR)

и получить расширенные права доступа к каналу Microsoft-Windows-Sysmon/Operational для учетной записи COLLECTOR.
Добавить данный узел в специально созданную подписку (Subscription) для централизованного сбора и хранения событий на выделенном узле с запущенной службой Windows Event Collector.