Applications and services logs microsoft windows sysmon operational

Время на прочтение7 мин

Количество просмотров62K

Технические специалисты, которые, расследуя ИБ-инциденты или устраняя неполадки при траблшутинге, хоть раз пытались найти в логах операционных систем семейства Microsoft Windows реально важную для них информацию, знают, что в журналы аудита событий попадает далеко не все, что нужно. Можно ли исправить эту ситуацию без дополнительных финансовых вложений с использованием инструментов, гарантированно совместимых с Windows-средой? Разумеется, можно!

Картинка с сайта: habr.com

Примечание: мы продолжаем серию публикаций полных версий статей из журнала Хакер. Орфография и пунктуация автора сохранены.

Сразу оговоримся, что за рамками настоящей статьи останутся вопросы осознанной чистки логов или «кривой» настройки политик аудита в домене (Audit Policy). Здесь мы поговорим только о том, как повысить информативность и расширить возможности функции аудита событий, используя утилиту System Monitor (Sysmon) в Windows-среде (от Windows 7 для клиентских узлов и от Windows Server 2008 R2 для серверов).

Sysmon

Утилиту можно загрузить с веб-сайта Microsoft Docs, из раздела Windows Sysinternals download. В составе Windows Sysinternals от Марка Руссиновича и Со есть еще много полезных утилит, так что найди время и «пощупай» их. Плюс загляни в подборку материалов на GitHub materials.
Но для данной статьи мы возьмем специальную готовую сборку с GitHub download, включающую файл конфигурации Sysmon Threat Intelligence Configuration от ION-STORM. Она ориентирована именно на выявление инцидентов ИБ и может выступить качественной основой для создания твоих собственных файлов конфигурации.

Утилиту можно установить точечно на каждое рабочее место либо с использованием групповых политик (Group Policy) в домене.

В данном файле конфигурации указываются в большинстве своем полные стандартные пути для ряда программного обеспечения:

    <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.

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

    <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-файл. Что это даст?

Картинка с сайта: habr.com

Мы видим, кто, куда и, если очень повезет, то с помощью чего, то есть в данном случае 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.

Картинка с сайта: habr.com

Стоит отметить, что на тех узлах сети, где есть ограничения на установку средств антивирусной защиты (терминалы диспетчеров, технологические АРМ и тому подобное), анализ хешей — в том числе автоматизированный, путем сопоставления данных от сервисов 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.
Нужно сделать следующие шаги на каждом рабочем месте либо с использованием групповых политик в домене:

1. Добавить пользователя, от имени которого будут собираться события «COLLECTOR», в локальную группу «Event log reader».
2. Выполнить от имени администратора (Run as) команду
   winrm quickconfig -quiet
3. Выполнить от имени администратора (Run as) команду
   wevtutil get-log Microsoft-Windows-Sysmon/Operational,
   Получить строку «channelAccess» DATA

Картинка с сайта: habr.com

1. Выполнить от имени администратора (Run as) команду
   wmic useraccount where name=’COLLECTOR’ get sid
   Получить UID_COLLECTOR
2. Выполнить от имени администратора (Run as) команду
   

   Картинка с сайта: habr.com

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

Получить расширенные права доступа к каналу Microsoft-Windows-Sysmon/Operational для учетной записи COLLECTOR.

1. Добавить данный узел в специально созданную подписку (Subscription) для централизованного сбора и хранения событий на выделенном узле с запущенной службой Windows Event Collector.

Заключение

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

Напоминаем, что это полная версия статьи из журнала Хакер. Ее авторы — Александр Кузнецов и Алексей Федоров.

Руслан Рахметов, Security Vision

При организации системы управления ИБ в компании множество задач связаны с обеспечением безопасности конечных точек (рабочих станций и серверов) под управлением ОС Windows и Linux. Выбор средств защиты велик, однако определенные ограничения накладывают и выделяемые на ИБ бюджеты, и вопросы совместимости рассматриваемых СЗИ с конкретными ОС. При этом зачастую от защитных решений требуется реализация функций безопасности, которые присутствуют либо в самих ОС в виде встроенного функционала, либо в свободно распространяемом ПО. Примером такого функционала является ведение детальных журналов событий безопасности и передача их в SIEM-системы, с учетом того, что ИБ-аналитиков как правило интересует запуск и остановка процессов и сервисов, сетевые соединения, изменение конфигураций конечных устройств, а также специфические редкие события, указывающие на вредоносную активность. Анализ подобных событий может способствовать выявлению киберинцидентов, а в рамках расследования кибератаки журналы аудита могут стать источником ценных сведений. Одними из самых полезных инструментов аналитика SOC-центра являются решения для защиты конечных точек (EDR, Endpoint Detection and Response), которые объединяют в себе функционал ведения детальных журналов безопасности, мониторинг и блокирование опасных действий, централизованное управление. Однако СЗИ такого типа недешевы, поэтому в некоторых случаях целесообразно рассмотреть некоторые бесплатные утилиты, хотя бы частично реализующие требуемый функционал. Одной из таких программ является утилита Sysmon (сокращение от System Monitor) из официального пакета Microsoft Sysinternals Suite, которая устанавливается на Windows и Linux и позволяет вести глубокий аудит работы ОС в целях выявления кибератак. Данная утилита хорошо зарекомендовала себя как среди исследователей кибербезопасности, так и в среде аналитиков SOC-центров. В данной статье мы подробно расскажем про Sysmon, дадим рекомендации по её настройке и использованию.

В соответствии с описанием на официальной странице
Sysmon, данная утилита предназначена для мониторинга и записи системных действий, она устанавливается в виде сервиса и драйвера, а также обладает функционалом предотвращения несанкционированных изменений её работы с помощью технологии защиты процессов Protected Process Light (PPL). Данная технология применяется в ОС старше Windows 8.1 и позволяет защитить критичные системные процессы, подписанные цифровой подписью, от воздействия ВПО или злонамеренных действий пользователей. Установка драйвера утилиты Sysmon позволяет получать более глубокий доступ к данным о работе ОС и начинать сбор событий сразу после включения устройства, что помогает обнаруживать скрытное ВПО, запускаемое до старта основных компонентов ОС. Упрощает централизованный сбор событий аудита в SIEM-систему то, что события Sysmon записываются в стандартный журнал Windows (Applications and Services Logs — Microsoft — Windows — Sysmon / Operational). Принцип сбора данных утилитой Sysmon заключается в выполнении обратных вызовов к ядру ОС Windows (kernel callbacks), использовании трассировки событий Windows (Event Tracing for Windows, сокращенно ETW), а также выполнении API-вызовов поставщиков телеметрии ОС Windows. В ОС Linux работа Sysmon основана на использовании библиотеки
sysinternalsEBPF, которая использует технологию eBPF для сбора информации о работе процессов, системных вызовов и сокетов. События Sysmon в ОС Linux записываются в стандартный файл /var/log/syslog.

Актуальная версия утилиты Sysmon для Windows обладает следующим функционалом:

— Регистрирует события создания процесса с командной строкой запуска и данными родительского процесса;

— Фиксирует значение хэш-суммы исполняемого файла процесса с использованием алгоритмов SHA1, MD5, SHA256, IMPHASH;

— Регистрирует загрузку драйверов и DLL с указанием их цифровых подписей и значений хэш-сумм;

— Регистрирует прямой доступ (raw access) к дискам и томам;

— Регистрирует сетевые соединения с указанием имени процесса-инициатора, IP-адреса назначения, имени хоста и номера порта;

— Выявляет изменения в дате создания файлов;

— Позволяет заблокировать создание файлов форматов EXE, DLL, SYS в определенных каталогах, с определенными хэш-суммами, создаваемые определенными родительскими процессами;

— Позволяет создавать гибкие XML-конфигурации с указанием объектов контроля для учета всех особенностей среды функционирования.

Для установки Sysmon в среде Windows потребуется выполнить следующие действия:

1. Скачать дистрибутив с https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon

2. Опционально: создать XML-файл с конфигурацией Sysmon.

3. Установить sysmon (пример для архитектуры x64):

C:\folder\sysmon64.exe -accepteula -i C:\folder\sysmonconfig-export.xml, где sysmonconfig-export.xml — файл конфигурации, sysmon64.exe — файл-установщик.

Поддерживается запуск установки из сетевой папки. Исполняемый файл сервиса Sysmon после установки находится в каталоге C:\Windows\sysmon64.exe.

Для установки Sysmon в среде Linux (например, на Ubuntu) потребуется выполнить следующие действия:

1. Зарегистрировать в системе ключ и репозиторий Microsoft:

wget -q https://packages.microsoft.com/config/ubuntu/$(lsb_release -rs)/packages-microsoft-prod.deb -O packages-microsoft-prod.deb

sudo dpkg -i packages-microsoft-prod.deb

2. Получить актуальный список пакетов:

sudo apt-get update

3. Установить утилиту:

sudo apt-get install sysmonforlinux

sudo sysmon -accepteula -i /opt/sysmon/config.xml , где config.xml — файл конфигурации

Рассмотрим типы событий, которые фиксирует утилита Sysmon в среде Windows:

1. Event ID 1: Process creation (Создание процесса) — регистрируется событие создания процесса с командной строкой запуска, данными родительского процесса, значением ProcessGUID;

2. Event ID 2: A process changed a file creation time (Процесс изменил дату создания файла) — регистрируются изменения в дате создания файлов, поскольку данный прием часто используется атакующими для сокрытия следов вредоносных действий;

3. Event ID 3: Network connection (Сетевое соединение) — регистрируется сетевая активность процессов с указанием пути к процессу, протокола (TCP или UDP), IP-адреса назначения, имени хоста, номера порта;

4. Event ID 4: Sysmon service state changed (Изменение статуса сервиса Sysmon) — регистрируется запуск и остановка сервиса Sysmon;

5. Event ID 5: Process terminated (Процесс завершен) — регистрируется завершение процессов с указанием времени, GUID и ID процесса;

6. Event ID 6: Driver loaded (Драйвер загружен) — регистрируется загрузка драйверов в ОС с указанием их цифровых подписей и значений хэш-сумм;

7. Event ID 7: Image loaded (Образ загружен) — регистрируется загрузка модулей (DLL-библиотек) в память процессов с указанием имени процесса, цифровых подписей и значений хэш-сумм загружаемых модулей;

8. Event ID 8: CreateRemoteThread (Создание удаленного потока) — регистрируется создание потока одного процесса в адресном пространстве другого процесса, т.е. инъекция кода и миграция одного процесса в другой, что часто используется как метод сокрытия вредоносной активности;

9. Event ID 9: RawAccessRead (Прямой доступ на чтение) — регистрируется прямой доступ к дискам и томам (с указанием процесса, получившего доступ, и имени диска/тома), что часто используется атакующими для сокрытия несанкционированного доступа к данным;

10. Event ID 10: ProcessAccess (Доступ к процессу) — регистрируется доступ одного процесса к памяти другого процесса, что используется атакующими для получения чувствительной информации, обрабатываемой критичными системными процессами (например, процессом Lsass.exe, который обрабатывает учетные данные пользователей ОС);

11. Event ID 11: FileCreate (Создание файла) — регистрируется создание и перезапись файлов, что позволяет выявлять создание файлов ВПО в распространенных каталогах (временные папки, папки сетевых загрузок, каталоги автозапуска);

12. Event ID 12: RegistryEvent (Object create and delete) (Создание и удаление объекта реестра) — регистрируется создание и удаление ключей и значений реестра, что позволяет контролировать состояние определенных веток реестра, часто используемых ВПО;

13. Event ID 13: RegistryEvent (Value Set) (Установка значения в реестре) — регистрируется изменение значений в реестре;

14. Event ID 14: RegistryEvent (Key and Value Rename) (Переименование ключей и значений в реестре) — регистрируется внесение изменений в названия ключей и значений в реестре;

15. Event ID 15: FileCreateStreamHash (Создание файлового потока) — регистрируется создание альтернативного потока данных, например, при скачивании файлов из Интернет и установке MOTW-меток браузерами с указанием хэш-суммы файла;

16. Event ID 16: ServiceConfigurationChange (Изменение конфигурации сервиса Sysmon) — регистрируется изменение конфигурации Sysmon;

17. Event ID 17: PipeEvent (Pipe Created) (Создание именованного канала) — регистрируется создание именованного канала, что часто используется ВПО для обмена данными между процессами;

18. Event ID 18: PipeEvent (Pipe Connected) (Подключение к именованному каналу) — регистрируется соединение по именованному каналу между клиентом и сервером;

19. Event ID 19: WmiEvent (WmiEventFilter activity detected) (Выявлена активность создания фильтра событий WMI) — регистрируется создание фильтра событий WMI, что часто используется ВПО для запуска;

20. Event ID 20: WmiEvent (WmiEventConsumer activity detected) (Выявлена активность создания потребителя событий WMI) — регистрируется создание потребителя событий WMI, что часто используется ВПО как метод закрепления в скомпрометированной системе;

21. Event ID 21: WmiEvent (WmiEventConsumerToFilter activity detected) (Выявлена активность подключения потребителя событий WMI к фильтру событий) — регистрируется подключение потребителя событий к фильтру событий WMI;

22. Event ID 22: DNSEvent (DNS query) (Запрос DNS) — регистрируется DNS-запрос от какого-либо процесса вне зависимости от полученного ответа от DNS-сервера;

23. Event ID 23: FileDelete (File Delete archived) (Удаление файла с сохранением его копии) — регистрируется удаление файла с сохранением его копии с каталоге-архиве Sysmon (по умолчанию, используется папка C:\Sysmon);

24. Event ID 24: ClipboardChange (New content in the clipboard) (Изменение содержимого буфера обмена) — регистрируется изменение содержимого буфера обмена;

25. Event ID 25: ProcessTampering (Process image change) (Изменение образа процесса) — регистрируются попытки сокрытия процессов с использованием техник «Herpaderping» и «Hollowing»;

26. Event ID 26: FileDeleteDetected (File Delete logged) (Удаление файла) — регистрируется удаление файла;

27. Event ID 27: FileBlockExecutable (Создание исполняемого файла заблокировано) — регистрируется обнаружение и блокирование создания исполняемых файлов;

28. Event ID 28: FileBlockShredding (Удаление файла заблокировано) — регистрируется обнаружение и блокирование удаления файлов с использованием специальных утилит (например, с помощью утилиты SDelete из состава пакета Sysinternals);

29. Event ID 29: FileExecutableDetected (Обнаружено создание исполняемого файла) — регистрируется обнаружение создания исполняемых файлов.

Для Linux-систем регистрируются события типов Event ID 1, 3, 4, 5, 9, 11, 16, 23, описания которых соответствуют приведенным выше.

Отметим, что XML-конфигурации для Sysmon могут быть глубоко кастомизированы для соответствия особенностям любой инфраструктуры. Для примера можно воспользоваться конфигурациями, приведенными ниже, которые сопровождены комментариями авторов, а также учитывают данные проекта MITRE ATT&CK для сопоставления регистрируемых событий с техниками атакующих:

https://github.com/olafhartong/sysmon-modular

https://github.com/ion-storm/sysmon-config

https://github.com/SwiftOnSecurity/sysmon-config

https://github.com/microsoft/MSTIC-Sysmon/tree/main/linux/configs

A log-file is a file that records events that occur in an operating system or software. [1]

These can be anything – ranging from network connections, login events, and application crashes, to accessing a file, changing the system time, and inserting a USB stick.

— With all these possibilities, how can you tell which events are important or not?

Servers, Workstations, Firewalls, Switches, Applications, Databases, Windows, Linux and Unix are all different in where they log to, how the log message is structured, what format the log file is saved in, and which events are included in the log.

— This lack of standardization results in inefficient log parsing.

Since Windows is the primary operating system of most corporate environments, it’s crucial to understand how Windows Event Logs work, how they’re unique but limited, and how they can be improved with Sysmon.

Windows Event Logs – Overview

Windows events are typically divided into one of 3 categories, called channels:

— Application

— System

— Security

There are more channels, but these are the main 3 that are normally collected.

Application logs are used for logging information generated by applications installed on the system.

System logs are used for logging information about the Windows operating system itself.

Security logs are used for logging information relating to the security of the system.

Windows logs are also classified into Event ID’s, which specify the event type:

— Example: Event ID 1001 in the Application channel is for Windows Error Reporting.

— Example: Event ID 158 in the System channel is for disk errors.

— Example: Event ID 4624 in the Security channel is for successful login attempts.

Each event is classified further to describe the severity of the event: [2]

— “Information” describes when an operation is successful.

— “Warning” may indicate a future problem.

— “Error” indicates that there is a problem now.

— “Critical” indicates there is a major problem now.

Windows Event Logs – Unique but Limited

Windows is unique in how it logs events, for a few reasons:

— Logs are stored in a binary format with the extension “.evtx”.

This means that the logs are not stored in plaintext and require a specific application to read them.

Typically, this is done with the Windows Event Viewer, but could also be done with a 3rd party agent.

— Logs are XML formatted

This means that the logs are structured, and can be parsed easily vs other unstructured log formats such as Syslog.

Unfortunately, the default Windows Event logs lack the telemetry needed in a modern environment.

With advanced attack methods such as Process Injection and Process Hollowing, additional logging capabilities are needed to detect these more modern attacks.

Endpoint Detection and Response (EDR) products tend to generate the amount of telemetry needed to detect these attacks, but these products are generally expensive.

— How do we log telemetry without purchasing an EDR solution?

— How can we apply filters to only log important events?

— How can we organize the logs into a structured format that is easy to parse?

The answer to these questions is – Sysmon, a free tool from Microsoft.[3]

What is Sysmon?

“System Monitor (Sysmon) is a Windows system service and device driver that, once installed on a system, remains resident across system reboots to monitor and log system activity to the Windows event log. It provides detailed information about process creations, network connections, and changes to file creation time.” [4]

Sysmon provides granular logging capabilities that are just not possible by default.

There are 26 Event Types that Sysmon generates

From the table above, we can tell immediately that Sysmon brings powers to the Windows Event logs that weren’t possible before.

Sysmon logs its events to:

Application and Services Logs -> Microsoft -> Windows -> Sysmon -> Operational

Benefits to using Sysmon are:

— Built-in filtering capabilities using Sysmon configuration files

— XML formatted log format, great for efficient parsing

— Built for Endpoints and Servers

— Free from Microsoft (although not officially supported)

— Flexible and allow customization via configuration files

How do I get started?

Here are some helpful resources:

I hope this article helped give some insight into how Windows logging works, its limitations, and how it can be improved with Sysmon from Microsoft.

About the Author: Kevin Kipp is a Cyber Security Analyst II at Tokio Marine HCC. He currently holds multiple industry certifications, serves on the GIAC Advisory Board, volunteers for CSNP, and is a lifelong learner.

Sysmon logs are event logs generated by Microsoft System Monitor (Sysmon) that provide detailed information about system-level operations on Windows and record activities such as process initiation, network connections, file and registry modifications, driver and service activity, and WMI actions. Sysmon logs are stored in the Windows Event Log, specifically within the Microsoft-Windows-Sysmon/Operational event log channel.

To read Sysmon logs, one can open the Sysmon event log channel under “Applications and Services Logs” in the Windows Event Viewer. Sysmon logs can be analyzed to detect potential risks, spot anomalies, and respond to security incidents to enhance overall system monitoring and security.

Sysmon logs can be configured via an XML configuration file that allows for granular logging of specific events. Sysmon generates various event IDs corresponding to the logs generated by Sysmon’s service, such as process creation, network connection, driver loaded, and image loaded.

To collect Sysmon logs on Windows, one can use tools such as NXLog, which can be configured to capture and process audit logs generated by Sysmon.Here is a table summarizing the key information about Sysmon logs:

Introduction to Sysmon Logs

If you’ve stumbled into the world of computer security, you might have heard about Sysmon logs. Let’s dive into what these are, why they’re such a big deal, and how they stand out from the sea of other logs we often wade through in the world of tech.

What are Sysmon Logs?

Sysmon logs are like the diligent sentinels of your Windows operating system, keeping a keen eye on system activities that could whisper hints of malicious happenings or operational issues. Created by Microsoft, Sysmon, or System Monitor, is not just a tool but a powerhouse that extends beyond what the standard Windows Event Log offers. It’s a system service and device driver that reboots to monitor and log system activity persistently to the Windows event log, making sure nothing slips past unnoticed.

Why are Sysmon Logs Important?

The importance of Sysmon logs lies in their depth and detail. Imagine you’re a detective in a vast city. The Windows Event Log is like a local newspaper—it gives you the gist of what’s happening around. But Sysmon logs? They’re your informants on the ground, providing the detailed intel you need—like file creation times, process IDs, and network connections. This makes them invaluable for threat hunting and log analysis, providing clues that help unwrap the story behind a security incident or system anomaly.

How are Sysmon Logs Different from Other Logs?

Sysmon logs are the elite agents in the world of logs. While the standard Windows event log can tell you when a service starts or stops, Sysmon tells you about the under-the-hood operations—like the exact moment a file’s creation time changes or when a network connection is established. It’s like having a high-resolution camera in a world of sketch artists. For example, a Sysmon event log can detail when a file stream is attached to a named file, something which traditional logs might not record.

How to Enable Sysmon Logs on Windows

Enabling Sysmon logs on a Windows system is a proactive move for enhancing security. Here’s how you set up Sysmon:

1. Download the Sysmon Binary: You can get the tool Sysmon directly from Microsoft’s website. It’s not installed with the operating system, so you’ll need to manually download it.
2. Install Sysmon: After downloading, you can install Sysmon using the command prompt with administrative privileges. The command will look something like sysmon.exe -accepteula -i.
3. Sysmon Service: Once installed on the system, the Sysmon service starts to monitor and log system activity right away, adding valuable information to your event logging arsenal.

Sysmon is available on Windows 7 and newer versions, so compatibility shouldn’t be an issue for most modern Windows setups.

Картинка с сайта: ruatelo.com

How to Configure Sysmon Logs

To tap into the full potential of Sysmon capabilities, you must whisper the right commands into its ear through a configuration file. Here’s the magic spell:

• ✅ Sysmon Configuration File: This is the rulebook that tells Sysmon what to keep an eye on. You can customize it to monitor specific system activity, event IDs, or even ignore certain events to reduce noise.
• ✅ Tailor Sysmon to Your Needs: Whether you want to catch every file creation time event, map specific operations to this event type, or focus on process creation events, it’s all in the config. You can write your own or download templates that are based on the Sysmon tag system, crafted by the community or security experts.
• ✅ Deploying Sysmon Config: After tailoring your sysmon configuration file, deploy it using a command like sysmon.exe -c yourconfigfile.xml. This updates the sysmon service to start filtering events based on your specifications.

Remember, the goal is to create a configuration that allows you to monitor and log the right data without getting overwhelmed by the sheer volume of information. The charm of Sysmon lies in its ability to be as broad or as precise as you need it to be.

In the upcoming sections, we’ll explore each of these steps in greater detail. Stay tuned to learn how to transform your Sysmon from a watchful guardian to a forensic expert.

Understanding Sysmon Log Entries

Sysmon, or System Monitor, is a potent Windows system service and device driver that monitors and logs system activity to the Windows event log. It’s a sophisticated tool that provides detailed information about process creations, network connections, and changes to file creation time, to name a few. Understanding Sysmon logs can be crucial for system administrators and cybersecurity professionals in detecting and investigating suspicious activities on Windows systems. So let’s get started and decode the treasures buried in Sysmon log entries.

What Information is Included in Sysmon Logs?

Sysmon logs are a goldmine of information. When Sysmon detects an event, it meticulously records it in the log file. Here’s a table that breaks down the kind of information you’ll typically find in these logs:

Each of these logs includes a wealth of log data that helps in painting a complete picture of the event. Sysmon also provides a unique sysmon event ID for each log entry, which can be used to filter and analyze specific event types.

How to Read Sysmon Log Entries

Reading Sysmon log entries can feel like deciphering an ancient language at first, but once you get the hang of it, it becomes second nature. Here’s how to approach it:

• ✅ Accessing Logs: Start by opening the Event Viewer. This is where all your Sysmon logs live, cohabiting peacefully with other Windows event logs.
• ✅ Navigating to Sysmon Logs: In the Event Viewer, you’ll find Sysmon logs under the “Applications and Services Logs” section. Look for a log channel named “Microsoft-Windows-Sysmon/Operational”.
• ✅ Inspecting the Details: When you click on a log entry, the bottom pane will show you the details. These details are split between the “General” tab, which is user-friendly, and the “Details” tab, which shows the XML view for in-depth analysis.
• ✅ Understanding the Format: Each log entry will have a consistent format with key-value pairs. For instance, event id 3 logs network events and will show source and destination IPs, something crucial for network monitoring.

How to Interpret Sysmon Log Entries

Interpreting these logs is an art. You are looking for anomalies or patterns that suggest suspicious behavior. For example:

• ✅ Process Anomalies: If event id 1 (process creation) shows a process starting from an unusual location, that’s a red flag.
• ✅ Network Oddities: An event id 3 entry with odd network traffic, such as unusual ports or foreign IP addresses, might indicate command and control activity.
• ✅ File Shenanigans: Event id 11 can reveal when a file was stealthily placed on the system without your knowledge.

How to Identify Suspicious Activity in Sysmon Logs

Spotting the nefarious needle in the haystack of Sysmon logs involves keen observation:

• ✅ Baseline Behavior: Know what’s normal to spot the abnormal. If an event is generated that doesn’t fit the pattern, investigate it.
• ✅ Event Correlation: Look for a series of events that map to this event type, like multiple failed logins followed by a successful one (possible brute force attack).
• ✅ Forensic Clues: Changes in file creation times (event id 2) or events that log the hash (event id 11) of recently modified files can be forensic evidence of tampering.

How to Correlate Sysmon Logs with Other Logs

Correlation is key in painting the full picture:

• ✅ Combine with Other Logs: Correlate Sysmon logs with other logs like Security, Application, and Setup logs from the Windows Event Viewer.
• ✅Temporal Analysis: Look for events logged around the same time across different logs. If a wmi event occurs simultaneously with a network anomaly, you may be onto something.
• ✅ Cross-reference with External Data: Use threat intelligence feeds to cross-reference IP addresses and hashes found in Sysmon log data.

Now that you’ve got a grasp on the basics, remember, like any tool, Sysmon is as effective as the person wielding it. So, wield it wisely, and happy log hunting!

Картинка с сайта: ruatelo.com

Advanced Techniques for Analyzing Sysmon Logs

Sysmon, a potent system monitoring tool, becomes truly invaluable when you know how to harness its capabilities fully. It’s like having a telescope that can peer into the vast cosmos of your system’s events — but only if you know where to point it and how to interpret what you see. Let’s dive into the advanced techniques for analyzing Sysmon logs, so you can uncover the hidden tales of your system’s operations.

How to filter Sysmon logs to focus on specific events

Filtering Sysmon logs is akin to tuning into your favorite radio station; you want to cut through the noise and hear only what interests you. Let’s say you’re only interested in monitoring file creation — this is where Sysmon shines. The tool generates events that log each time a file is created, which is essential for tracking down how a piece of malware might be spreading or where sensitive data is being written to disk.

• ✅ Identifying the Relevant Event IDs:
  • Use the overview of Sysmon provided in its documentation to identify which event IDs correspond to the activity you’re monitoring. For instance, an event is aimed at capturing file creation (Event ID 11).
• ✅ Utilize Event Viewer or Third-party Tools:
  • Open Event Viewer and navigate to the “Applications and Services Logs” section, then to the “Sysmon” log.
  • Employ advanced filters using the GUI or XML queries to pinpoint the events. For example, you could filter by the event logs when a named pipe is created to catch inter-process communication which might be indicative of lateral movement.
• ✅ Leverage Custom Views:
  • Within Event Viewer, create a Custom View and specify the event IDs that you’re interested in. This way, you’re not sifting through an overwhelming amount of data.
• ✅ Use Sysmon Configurations:
  • Edit the Sysmon configuration file to include or exclude specific events. If you’re after network connections, ensure that event detects when a process makes a connection to an IP address is enabled.

By filtering Sysmon logs, you’re essentially curating the telemetry for this event that matters most to your investigative or monitoring efforts.

How to use PowerShell to parse Sysmon logs

Parsing Sysmon logs with PowerShell is like being a detective with a magnifying glass, examining the fingerprints left behind on the scene. PowerShell, with its powerful cmdlets and scripting capabilities, allows you to dissect Sysmon logs efficiently.

• Get-WinEvent Cmdlet:
  • Utilize Get-WinEvent to pull Sysmon logs. This cmdlet allows you to query the event log channel and filter based on various criteria such as ID, level, and keywords.

Get-WinEvent -LogName 'Microsoft-Windows-Sysmon/Operational' | Where-Object { $_.Id -eq 1 }

• Scripting:
  • Write scripts that automate the parsing and extraction of information. For example, if you want to trace network connections, script the extraction of fields from events where event indicates the source and destination IPs.
• Object Conversion:
  • Convert event logs to objects using | Select-Object or | ConvertTo-Json for easier manipulation or to integrate with other systems.

By using PowerShell, you can systematically parse through the Sysmon logs, translating the raw data into actionable insights.

How to use EQL to query Sysmon logs

EQL, or Event Query Language, is the scalpel in the toolkit for log analysis. It’s designed for chronological correlation and pattern detection, which is perfect for making sense of Sysmon logs.

• Understanding EQL Syntax:
  • EQL follows a SQL-like syntax that allows for intricate querying, like joining related events or detecting sequences of actions indicative of malicious behavior.
• EQL Queries:
  • Formulate queries that reflect the behaviors you’re interested in. For example, to find a malware signature, you might query Sysmon logs using EQL for sequences of process creations that resemble a known attack pattern.
• Elasticsearch Integration:
  • If you’re using an Elasticsearch stack, you can utilize EQL to perform complex searches against your Sysmon data, taking advantage of the powerful analytical capabilities.

Querying Sysmon logs with EQL can feel like putting together a jigsaw puzzle, finding the pieces that fit together to reveal the bigger picture.

How to use Sysmon with graph analysis tools

Graph analysis tools can take the connections between Sysmon events and turn them into a visual web, a bit like a map of the stars, where each event is a point of light, and their relationships are the constellations.

• ✅ Exporting Data:
  • First, you need to export your Sysmon log data in a format that your graph tool can understand, such as CSV or JSON.
• ✅ Choosing the Right Tool:
  • There are several graph analysis tools out there, such as Neo4j or Gephi. They can help you visualize the network of events and make it easier to spot anomalies or patterns.
• ✅ Graph Queries:
  • With the right tool, you can perform graph-specific queries to, for example, identify unusual patterns like a process that’s suddenly making connections to multiple external IP addresses.

Graph analysis of Sysmon logs is not just about making pretty pictures; it’s about turning data into a story that you can follow, leading you to the insights hidden within.

How to use Sysmon with SIEMs

SIEMs (Security Information and Event Management systems) are like the command centers for cybersecurity, consolidating various event logs and providing real-time analysis. Incorporating Sysmon logs into your SIEM can significantly enhance its ability to detect and respond to threats.

• ✅ Integration:
  • Ensure that your SIEM platform supports Sysmon data or can ingest custom log formats. You may need to configure the Sysmon driver to forward logs to your SIEM.
• ✅ Normalization:
  • SIEMs often require data normalization. This means translating Sysmon log data into a format that your SIEM can understand and correlate with other data sources.
• ✅ Correlation Rules:
  • Develop correlation rules within your SIEM for Sysmon events. For instance, if an event is generated when process execution happens from a temporary directory, it might warrant a closer look.
• ✅ Alerting:
  • Set up alerts for specific patterns of events that Sysmon logs. For instance, if a state change event occurs in conjunction with a known indicator of compromise, your team can be alerted immediately.

By integrating Sysmon logs with your SIEM, you’re bringing a high-definition lens to your security monitoring efforts, allowing you to see more clearly and react more quickly to potential threats.

As we’ve explored these advanced techniques, remember, each piece of data you glean from Sysmon is a thread in a larger tapestry. Learning to filter, parse, query, visualize, and integrate these logs is how you’ll weave those threads into a coherent picture of your system’s security landscape.

Картинка с сайта: ruatelo.com

Best Practices for Working with Sysmon Logs

System Monitor (Sysmon) is a powerful tool that provides detailed information about Windows system activities in real-time, capturing data like network connections, changes to the file system, and alterations in processes. However, the wealth of data Sysmon provides can be overwhelming, particularly in larger environments. Let’s dive into some best practices to effectively manage and leverage Sysmon logs.

How to Manage Sysmon Logs at Scale

Managing Sysmon logs at scale requires a strategic approach that ensures the logs are not only collected efficiently but also that the valuable data they contain can be analyzed effectively. Here’s a structured method:

• ✅ Event Triage and Filtering:
  • Identify critical events that require logging. Not all events in Sysmon need to be logged, as some can generate a vast amount of data that may not be useful.
  • Establish filters to exclude normal activity and reduce noise. By focusing on the anomalies, you can streamline the amount of data to process.
• ✅ Centralized Logging:
  • Utilize a centralized log management solution to aggregate logs from various sources. This aids in correlation and analysis across different systems and applications.
  • Implement a naming convention that includes the consumer name to easily identify the source of logs.
• ✅ Load Balancing:
  • Distribute the logging workload across multiple servers or processes. This can prevent any single system from becoming overwhelmed with log data.
• ✅ Performance Monitoring:
  • Regularly monitor the performance impact of Sysmon on your systems. It’s crucial to ensure that logging does not adversely affect system performance.
• ✅ Retention Policies:
  • Define clear log retention policies. Determine how long you need to keep the logs for compliance and operational purposes and implement automated processes to delete old logs.

By applying these management techniques, you can keep your Sysmon logging at scale organized, accessible, and functional.

How to Store and Archive Sysmon Logs

Storing and archiving Sysmon logs properly is crucial for both operational effectiveness and compliance with various regulatory frameworks. Consider the following strategy:

• ✅ Storage Solutions:
  • Employ robust storage solutions that can handle high ingestion rates and large volumes of data.
  • Ensure the storage system allows for easy retrieval and searching of logs.
• ✅ Data Compression:
  • Implement data compression techniques to reduce the storage footprint of your Sysmon logs.
• ✅ Archiving Policies:
  • Establish archiving policies based on the criticality and relevance of the data. For instance, logs related to security incidents may need to be retained longer than other data.
• ✅ Redundancy:
  • Maintain redundant copies of logs to prevent data loss. This can be achieved through replication or by utilizing cloud storage solutions with built-in redundancy.
• ✅ Secure Storage:
  • Protect your logs with encryption both at rest and in transit to ensure that sensitive information is secured.

By adopting these storage and archiving methods, you can ensure that your Sysmon logs are not just stored safely but are also optimized for long-term accessibility and integrity.

How to Monitor Sysmon Logs for Anomalies

Monitoring Sysmon logs for anomalies is a continuous process of vigilance and pattern recognition. Here’s how you can stay on top of any suspicious activities:

• ✅ Anomaly Detection Tools:
  • Use advanced analytics and anomaly detection tools that can sift through large volumes of log data to identify patterns indicative of security incidents or system misconfigurations.
• ✅ Real-Time Alerts:
  • Set up real-time alerts for specific events or indicators of compromise. For example, an “event was added for Windows” that signifies a new service installation could be critical if it occurs unexpectedly.
• ✅ Baseline Behavior:
  • Establish a baseline of normal behavior to better identify deviations. This involves understanding what an operations map to this event looks like under regular conditions.
• ✅ Correlation Analysis:
  • Employ correlation analysis to link related events. If an “event records the value written” to the registry and shortly after a “logged when a file” is executed, this sequence might suggest malicious activity.
• ✅ Threat Intelligence Feeds:
  • Integrate threat intelligence feeds to enhance anomaly detection with up-to-date information on known threats and vulnerabilities.

By monitoring your Sysmon logs with a keen eye for anomalies and utilizing the right tools, you can quickly identify and respond to potential threats.

How to Automate Analysis of Sysmon Logs

The vast amount of data that Sysmon can generate makes manual analysis impractical. Automation is key. Here’s how to implement it:

• ✅ Scripting and Automation Tools:
  • Leverage scripting languages like PowerShell when using Windows or other automation tools to parse and analyze Sysmon log data.
• ✅ Scheduled Tasks:
  • Set up scheduled tasks to automatically run analysis scripts at regular intervals, ensuring continuous monitoring without manual intervention.
• ✅ Machine Learning:
  • Incorporate machine learning algorithms to detect unusual patterns and anomalies that a human analyst might miss.
• ✅ Integration with SIEM:
  • Integrate Sysmon with Security Information and Event Management (SIEM) systems to leverage their powerful analysis engines and dashboard capabilities.
• ✅ Custom Detection Rules:
  • Develop custom detection rules tailored to your environment’s specific needs and potential threat scenarios.

Automation not only enhances the efficiency of log analysis but also significantly increases the chances of detecting sophisticated threats.

How to Keep Sysmon Logs Up to Date

Keeping Sysmon logs up to date is crucial for ensuring the accuracy and reliability of your monitoring efforts. Here’s what to focus on:

• ✅ Regular Updates:
  • Stay informed about new Sysmon releases and features. New versions can introduce additional logging capabilities, such as “added for Windows 8.1” and improvements for “Windows 7 and earlier”.
• ✅ Configuration Management:
  • Regularly review and update your Sysmon configuration to capture relevant data. As new threats emerge, you may need to log different types of activities.
• ✅ Testing and Validation:
  • Test your Sysmon deployment after updates to validate that it’s capturing the correct data and that tools that read the memory contents are still compatible.
• ✅ Change Management:
  • Implement a change management process for updates to your Sysmon configuration to avoid disruptions to your logging pipeline.
• ✅ Documentation:
  • Keep thorough documentation of your Sysmon version history and configuration changes. This can be crucial for troubleshooting and understanding the context of past events.

By keeping your Sysmon logs and configurations up to date, you ensure that you’re always prepared to log the latest activities that could indicate a security threat or system issue. Remember, a tool is only as good as its most recent update. Keep your eyes peeled for updates that include phrases like an “event is useful” to ensure you’re capturing all the necessary data to protect and analyze your systems effectively.