Все, что вы хотели знать о Sigma-правилах. Часть 1

Все, что вы хотели знать о Sigma-правилах. Часть 1
Создавая продукты и развивая экспертизу, мы в первую очередь руководствуемся стремлением повысить безопасность компаний. Однако в своих исследованиях мы движимы не только заботой о клиентах. Уже довольно давно у нас появилось желание проводить исследования для сообщества по информационной безопасности на волонтерских началах и сейчас мы активно делаем это: публикуем в Twitter детекты громких сетевых атак, поставляем правила анализа трафика в сервис ANY.RUN и пополняем набор правил ETOpen . Существует много опенсорсных проектов, в которые можно отослать pull request, но до недавнего времени до хостовых детектов все никак не доходили руки.

И тут мы узнали, что группа энтузиастов решила устроить двухнедельный спринт по написанию правил для проекта Sigma , который создан ради выработки единого формата описания правил для SIEM-систем и поддерживается 110 участниками. Новость о событии нас заинтересовала, поскольку как вендор SIEM мы внимательно следим за развитием комьюнити.

Каково же было наше удивление, когда с нами связались организаторы и предложили команде PT Expert Security Center поучаствовать в спринте! Участники мероприятия образовали Open Security Collaborative Development (OSCD) — международную инициативу специалистов по ИБ, направленную на распространение знаний и улучшение компьютерной безопасности в целом. Мы с радостью согласились принять участие, чтобы применить свой опыт во благо общей безопасности.

Как появилась эта статья


Мы поняли, когда начали писать правила, что исчерпывающего описания синтаксиса Sigma-правил нет, тем более на русском языке. Основные источники знаний — GitHub и личный опыт. Есть несколько хороших статей (на русском и на английском ), но в них фокус смещен с синтаксиса правил на анализ области применимости Sigma-правил или создание конкретного правила. Мы решили облегчить новичкам знакомство с проектом Sigma, поделиться собственным опытом, собрать в одном месте информацию о синтаксисе и особенностях его применения. Ну и конечно, мы надеемся, что это поспособствует расширению инициативы OSCD и позволит в будущем образовать крупное сообщество.

Поскольку материала получилось очень много, мы решили выпустить описание в цикле из трех статей:

  1. Небольшое введение, пример создания простого правила и описание источников событий (и эту статью вы читаете сейчас).
  2. Описание логики детектирования. Это наиболее важная часть синтаксиса, знание которой необходимо для понимания существующих правил и написания собственных.
  3. Описание метаинформации (атрибуты, которые имеют информативный или инфраструктурный характер, такие, например, как описание или идентификатор) и коллекций правил.

Что такое формат Sigma и зачем он нужен


Sigma — это унифицированный формат описания правил детектирования, основанных на данных из логов. Правила хранятся в отдельных YAML-файлах. Sigma позволяет написать правило, используя унифицированный синтаксис, один раз, а затем с помощью специального конвертера получить правило в синтаксисе поддерживаемой SIEM-системы. Помимо синтаксиса запросов различных SIEM-систем, поддерживается создание запросов следующих видов:

  • Elasticsearch Query,
  • строка запуска утилиты grep с нужными параметрами,
  • строка обращения к журналам аудита Windows на языке PowerShell.

Два последних вида примечательны тем, что не требуют дополнительного ПО для анализа логов. Утилита grep и интерпретатор PowerShell поддерживаются «из коробки» в ОС Linux и Windows соответственно.

Существование единого формата описания детектов, основанных на логах, позволяет легче обмениваться знаниями, развивать open-source security и помогать сообществу по ИБ бороться с возникающими угрозами.

Общий синтаксис


Прежде всего стоит сказать, что есть обязательные и опциональные части правила. Это описано в официальной wiki на GitHub. Схема правила представлена ниже:



Практически любое правило можно условно разбить на три части:

  1. атрибуты, описывающие правило (метаинформация);
  2. атрибуты, описывающие источники данных;
  3. атрибуты, описывающие условия срабатывания правила.

Каждой из частей соответствуют обязательные высокоуровневые атрибуты title (помимо title, в последнюю группу входят остальные необязательные высокоуровневые атрибуты), logsource и detection.

Есть еще одна особенность строения правила, про которую стоит рассказать. Поскольку правила описываются на языке разметки YAML, разработчики Sigma нашли применение некоторым особенностям этого ело в том, что формат YAML позволяет разместить в одном файле несколько YAML-документов. А для Sigma — несколько правил объединить в одном файле, то есть создавать «коллекции правил» (rule collections). Такой подход удобен, когда есть несколько способов детектирования атаки и не хочется дублировать описательную часть (как будет описано в соответствующем разделе, дублировать можно не только описательную часть правила).

В таком случае правило условно разбивается на две части:

  • часть с общими атрибутами для элементов коллекций (обычно все поля, кроме разделов logsource и detection),
  • одна или несколько частей с описанием детекта (разделы logsource и detection).

Если файл содержит единственное правило, данное утверждение тоже истинно, поскольку мы получаем вырожденную коллекцию из одного правила. Коллекции правил будут подробно рассмотрены в третьей части цикла статей.

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

Описание типового правила



Пример создания Sigma-правила


Прежде чем описывать подробности синтаксиса и рассказывать про возможности Sigma-правил, рассмотрим небольшой пример создания такого правила, для того чтобы было понятно, откуда на практике берутся те или иные значения атрибутов. На эту тему есть хорошая статья на английском языке. Если вы уже пробовали написать свои правила и разобрались, какие данные нужно указывать в атрибуте YAML-файла, можете переходить к следующему разделу с подробным описанием секции источников событий (также будем называть эту секцию источниками логов).

Опишем создание правила, которое выявляет использование SettingSyncHost.exe в качестве Living Off The Land Binary (LOLBin). Создание правила обычно состоит из трех этапов:

  1. проведение атаки и сбор необходимых логов,
  2. описание детекта в виде правила,
  3. проверка созданного правила.

Проведение атаки


Идея для правила хорошо описана в блоге Hexacorn . После внимательного прочтения становится ясно, какие шаги нужно проделать, чтобы повторить описанный в статье результат:

  1. Скопировать программу, которую вы хотите запустить, в любой каталог, доступный для записи. В статье предлагается выбрать %TEMP%, однако вы можете выбрать путь на свое усмотрение. Стоит учесть, что в данном каталоге создастся подкаталог с названием, которое вы укажете в п. 4.
  2. Назовите программу, которую вы хотите запустить, одним из имен, указанных в статье (wevtutil.exe, makecab.exe, reg.exe, ipconfig.exe, settingsynchost.exe, tracelog.exe). В ходе анализа логов выяснилось, что в дополнение к этому списку можно использовать название findstr.exe. Называть файлы нужно именно так, поскольку SettingSyncHost.exe уязвим к атаке Binary Search Order Hijacking (MITRE ATT&CK ID: T1574.008).
  3. Сделать выбранную директорию текущей рабочей директорией для всех процессов, которые вы будете далее запускать (в случае если вы запускаете settingsynchost.exe через cmd или PowerShell, достаточно просто выполнить команду cd <выбранный путь>).
  4. Запустить команду: c:windowssystem32SettingSyncHost.exe -LoadAndRunDiagScript <любое_название_для_подпапки>
  5. Исполняемый файл был запущен легитимной программой SettingSyncHost.exe.



В системе установлен Sysmon с файлом конфигурации из проекта sysmon-modular . Таким образом сбор логов осуществился автоматически. Какие именно логи полезны для написания детекта, будет видно по ходу написания правила.

Описание детекта в виде Sigma-правила


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

Создаем новый файл и стараемся кратко и емко описать его суть в названии. Тут следует придерживаться стиля существующих правил. В нашем случае мы выбрали название win_using_settingsynchost_to_run_hijacked_binary.yml. Далее начинаем заполнять его содержимым. Начнем с заполнения метаинформации в начале правила. Все данные, необходимые для этого, у нас уже есть.
Описываем кратко, какую атаку выявляет правило, в поле title, более подробные пояснения — в поле description, для новых правил принято ставить status: experimental. Уникальный идентификатор можно сгенерировать разными способами, в среде Windows проще всего запустить следующий код в интерпретаторе PowerShell:

PS C:> "id: $(New-Guid)" id: b2ddd389-f676-4ac4-845a-e00781a48e5f

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

Наше правило на данном этапе имеет следующий вид:



Далее необходимо описать источники логов. Как уже было сказано выше, мы будем опираться на логи Sysmon, однако с появлением обобщенных категорий, для создания процессов принято использовать категорию process_creation. Про обобщенные категории подробнее будет рассказано ниже. Отметим, что в поле definition принято писать комментарии и советы по настройке источников, такие как особенности конфигурации Sysmon:



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

Если посмотреть на события, которые произошли, можно выстроить следующую цепочку.
Сначала запустили процесс (PID: 4712) со строкой запуска c:windowssystem32SettingSyncHost.exe -LoadAndRunDiagScript join_oscd



Отметим, что текущая рабочая директория процесса — пользовательский каталог TEMP.

Далее запущенный процесс создает пакетный файл и запускает его исполнение.





Процесс выполнения инструкций пакетного файла получил идентификатор 7076. При дальнейшем анализе событий видим запуск файла ipconfig.exe, который не содержит присущую системным файлам метаинформацию и плюс ко всему расположен в папке с временными файлами:



Предлагается считать признаком атаки запуск процессов, исполняемые файлы которых не лежат в системной директории (C:WindowsSystem32), а также если в строке запуска родительского процесса содержатся подстроки «cmd.exe /c», «RoamDiag.cmd» и «-outputpath». Опишем это в синтаксисе Sigma и получим итоговое правило (детальный разбор конструкций, которые можно использовать для описания логики детектирования, будет дан в следующей части нашего цикла статей про Sigma):



Проверка работоспособности правила


Запускаем конвертер в запрос на языке PowerShell:



Для нашего случая этот запрос не даст нужного результата, поскольку исключающий фильтр также находит и путь до образа исполняемого файла родительского процесса. Поэтому просто укажем, что перед словом Image не должно стоять буквы t — окончание слова Parent:



Видим, что наше событие нашлось. Правило работает.

Так на практике создаются Sigma-правила. Далее подробно опишем поля, отвечающие за детект, а именно за описание источников логов.

Описание детекта


Главная часть правила — описание детекта, поскольку именно здесь содержится информация о том, где и как искать признаки атаки. Эта информация содержится в полях атрибутов logsource (где) и detection (как). В данной статье мы подробно рассмотрим секцию logsource, а секцию detection опишем в следующей части нашего цикла.

Описание секции источников событий (атрибут logsource)


Описание источников событий содержится в значении поля logsource. Эта секция описывает источники данных, из которых будут поставляться события для секции детектирования (атрибут detection рассматривается в следующей части). Секция описывает сам источник, платформу и приложение, которые необходимы для детектирования. Тут могут содержаться три атрибута, которые обрабатываются конвертерами автоматически, и произвольное число необязательных элементов. Основные поля:

  • Category — описывает классы продуктов. Примеры значений данного поля: firewall, web, antivirus. Также поле может содержать обобщенные категории, о которых будет рассказано ниже.
  • Product — программный продукт или операционная система, которая создаёт логи.
  • Service — ограничение логов на определенное подмножество сервисов, например «sshd» для Linux или «Security» для Windows.
  • Definition — дополнительное поле для описания особенностей источника, например требования по настройке аудита (используется редко, пример правила с данным полем можно найти на GitHub ). Рекомендуется использовать этот атрибут, если у источника есть какие-либо особенности.


На официальной wiki на GitHub определен набор полей, которые необходимо использовать для того, чтобы правила были кросс-продуктовыми. Эти поля сведены в таблицу ниже.

Category Product Service
windows security
system
sysmon
taskscheduler
wmi
application
dns-server
driver-framework
powershell
powershell-classic
linux auth
auditd
clamav
apache access
error
process_creation windows
proxy
firewall
webserver
dns

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

Поля событий категории Proxy


Category Product/Service Fields Examples
proxy c-uri proxy_ursnif_malware.yml
c-uri-extension proxy_download_susp_tlds_blacklist.yml
c-uri-query proxy_susp_flash_download_loc.yml
c-uri-stem proxy_susp_flash_download_loc.yml
c-useragent proxy_powershell_ua.yml
cs-bytes
cs-cookie proxy_cobalt_amazon.yml
cs-host proxy_cobalt_ocsp.yml
cs-method proxy_downloadcradle_webdav.yml
r-dns proxy_apt40.yml
cs-referrer
cs-version
sc-bytes
sc-status proxy_ursnif_malware.yml
src_ip
dst_ip

Описание полей событий данного источника: ---------------------------------------------------------------  c-uri - URI, запрошенный клиентом  c-uri-extension - Расширение URI. Обычно это расширение запрошенного файла  c-uri-query - Часть URI, содержащая путь к запрашиваемому ресурсу  c-uri-stem - Обычно это часть URL от хоста (или хост:порт) и до строки запроса. Чаще всего в URIstem содержится путь до ресурса относительно корневой директории веб-сервера  c-useragent - Заголовок UserAgent в HTTP-запросе клиента  cs-bytes - Количество байтов, отправленных от клиента к серверу  cs-cookie - Значения cookie, которые передает клиент на сервер  cs-host - Заголовок Host в HTTP-запросе клиента  cs-method - Метод HTTP-запроса клиента  r-dns - DNS-имя запрашиваемого сервера  cs-referrer - Заголовок Referrer в HTTP-запросе клиента  cs-version - Версия протокола HTTP, которую использует клиент  sc-bytes - Количество байтов, отправленных от сервера к клиенту  sc-status - Код HTTP-ответа  src_ip - IP-адрес клиента  dst_ip - IP-адрес сервера


Поля событий категории Firewall


Category Product/Service Fields Examples
firewall src_ip
src_port
dst_ip
dst_port net_high_dns_bytes_out.yml
username


Описание полей событий данного источника: --------------------------------------------------------------- src_ip - IP-адрес клиента  src_port - Порт, с которого происходит подключение  dst_ip - IP-адрес сервера  dst_port - Порт, на который происходит подключение  username - Имя пользователя, который осуществляет подключение 


Поля событий категории Web server


Category Product/Service Fields Examples
webserver c-uri web_cve_2020_0688_msexchange.yml
c-uri-extension
c-uri-query
c-uri-stem
c-useragent
cs-bytes
cs-cookie
cs-host
cs-method web_cve_2020_0688_msexchange.yml
r-dns
cs-referrer
cs-version
sc-bytes
sc-status
src_ip
dst_ip

Описание полей событий данного источника: --------------------------------------------------------------- c-uri  - URI, запрошенный клиентом  c-uri-extension - Расширение URI. Обычно это расширение запрошенного файла  c-uri-query - Часть URI, содержащая путь к запрашиваемому ресурсу  c-uri-stem  - Обычно это часть URI от хоста (или хост:порт) и до строки запроса. Чаще всего в URI stem содержится путь до ресурса относительно корневой директории веб-сервера  c-useragent  - Заголовок UserAgent в HTTP-запросе клиента  cs-bytes  - Количество байтов, отправленных от клиента к серверу  cs-cookie - Значения cookie, которые передает клиент на сервер  cs-host - Заголовок Host в HTTP-запросе клиента  cs-method - Метод HTTP-запроса клиента  r-dns  - DNS-имя запрашиваемого сервера  cs-referrer - Заголовок Referrer в HTTP-запросе клиента  cs-version - Версия протокола HTTP, которую использует клиент  sc-bytes - Количество байтов, отправленных от сервера к клиенту  sc-status - Код HTTP-ответа  src_ip - IP-адрес клиента  dst_ip - IP-адрес сервера


Обобщенные категории


Поскольку Sigma — это обобщенный формат описания правил детектирования, основанных на логах, синтаксис таких правил должен уметь описать логику детектирования для разных систем. Некоторые системы используют таблицы с агрегированными данными вместо событий, а для описания одной и той же ситуации могут поступать данные из разных источников. Для унификации синтаксиса и решения подобных проблем был введен механизм обобщенных источников событий (generic logsources). На данный момент создана одна такая категория — process_creation. Подробнее об этом можно почитать в блоге patzke.org . Список полей данной категории можно найти на странице с таксономией (на этой странице также описаны другие поддерживаемые категории).

Поля событий обобщенной категории process_creation


Category Product Fields Examples
process_creation windows UtcTime -
ProcessGuid -
ProcessId sysmon_raw_disk_access_using_illegitimate_tools.yml
Image win_susp_regsvr32_anomalies.yml
FileVersion sysmon_susp_file_characteristics.yml
Description sysmon_susp_file_characteristics.yml
Product sysmon_susp_file_characteristics.yml
Company sysmon_susp_file_characteristics.yml
CommandLine win_meterpreter_or_cobaltstrike_getsystem_service_start.yml
CurrentDirectory win_susp_powershell_parent_combo.yml
User win_susp_schtask_creation.yml
LogonGuid -
LogonId -
TerminalSessionId -
IntegrityLevel -
imphash win_renamed_paexec.yml
md5 -
sha256 -
ParentProcessGuid -
ParentProcessId -
ParentImage win_meterpreter_or_cobaltstrike_getsystem_service_start.yml
ParentCommandLine win_cmstp_com_object_access.yml

Описание полей событий данного источника: --------------------------------------------------------------- UtcTime -Время события в формате UTC  ProcessGuid - GUID созданного процесса  ProcessId - PID созданного процесса  Image - Путь к запущенному исполняемому файлу  FileVersion - Версия программы, взятая из ресурсов исполняемого файла  Description - Описание программы, взятое из ресурсов исполняемого файла  Product - Название программы, взятое из ресурсов исполняемого файла  Company - Название компании — разработчика программы, взятое из ресурсов исполняемого файла  CommandLine - Строка запуска создаваемого процесса  CurrentDirectory - Текущая директория созданного процесса  User - Пользователь, от имени которого запускается процесс  LogonGuid - GUID текущей пользовательской сессии  LogonId - Идентификатор текущей пользовательской сессии  TerminalSessionId - Идентификатор текущей терминальной сессии  IntegrityLevel - Уровень целостности, с которым запускается процесс  imphash - Хеш-сумма на основе данных из таблицы импорта исполняемого файла  md5 - MD5-хеш исполняемого файла, на основе которого создается процесс  sha256 - SHA256-хеш исполняемого файла, на основе которого создается процесс  ParentProcessGuid - GUID родительского процесса  ParentProcessId - PID родительского процесса  ParentImage - Путь к исполняемому файлу родительского процесса  ParentCommandLine - Строка запуска родительского процесс


Статистика использования источников событий в существующих правилах


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

Статистика по использованию комбинации полей описания некоторых наиболее распространенных источников (прочерк означает отсутствие данного поля):
Кол-во правил Category Product Service Пример синтаксиса Комментарий
197 process_creation windows logsource:
       category: process_creation
       product: windows
Обобщенная категория логов создания процессов на Windows-системах. Включает события Sysmon
EventID=1
и события Windows Security Event Log
EventID=4688
68 windows sysmon logsource:
     product: windows
     service: sysmon
События sysmon
48
windows security logsource:
    product: windows
    service: security
События из журнала Windows Security Event Log
24 proxy logsource:
category: proxy
События из логов прокси-сервера
15 windows system logsource:
    product: windows
service: system
События из журнала Windows System Event Log
12 accounting cisco aaa logsource:
    category: accounting
product: cisco
service: aaa
События из журнала Cisco AAA Security Services
10 windows powershell logsource:
    product: windows
service: powershell
События из журнала
Microsoft Windows PowerShell
Event Log
9 linux logsource:
product: linux
События аудита в Linux
8 linux auditd logsource:
product: linux
service: auditd
События Linux, уточнение до логов конкретного сервиса (подсистема AuditD)

Советы по написанию правил


При написании нового правила возможны такие ситуации:

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

Если вы столкнулись с первым случаем, то используйте одно из существующих правил в качестве шаблона. Возможно, нужный источник логов уже используется в других правилах, тогда это значит, что авторы плагинов (бэкенд-конвертеры) под разные SIEM-системы, скорее всего, учли его в своем маппинге и ваше правило должно сразу корректно обрабатываться.

Во второй ситуации необходимо на примере существующих правил понять, как правильно использовать идентификаторы category, product и service. При создании своего источника логов рекомендуется добавить его во все маппинги существующих бэкендов. Это могут сделать и другие контрибьюторы или даже разработчики, главное сообщить о такой необходимости.

Мы создали визуализацию сочетания полей описания источников логов в существующих правилах:

Распределение источников логов




Статистика использования комбинаций подполей атрибута logsource




В этом материале мы привели пример создания простого правила и рассказали про описание источников событий. Теперь вы можете применить полученные знания, посмотреть на правила в репозитории Sigma и разобраться, какие источники используются в том или ином правиле. Следите за нашими публикациями: в следующей части мы рассмотрим наиболее сложную часть Sigma-правил — секцию описания логики детектирования.

Автор: Антон Кутепов, специалист отдела экспертных сервисов и развития Positive Technologies (PT Expert Security Center)
Alt text

Если вам нравится играть в опасную игру, присоединитесь к нам - мы научим вас правилам!

Подписаться