sigma

Введение

Плагин sigma входит в состав YAML-плагинов processors и позволяет проводить предварительную фильтрацию на коллекторах, используя правила Sigma.

Немного о правилах Sigma: это open-source формат правил для SIEM, конвертируемый в различные представления (elasticsearch, splunk и т.д.). Преимуществами этих правил является богатый набор открытых правил и активное сообщество, покрывающее правилами появляющиеся уязвимости. Поэтому данный плагин удобен для своевременного реагирования на тенденции в сфере ИБ, поскольку новые правила достаточно загрузить в плагин, после чего новая уязвимость сразу отслеживается нашей SIEM.

Конфигурация

Не считая поля module, обыкновенного для плагинов processors и позволяющего определить тип плагина, в конфигурацию плагина sigma входит 3 поля:

1. rules - массив правил Sigma. Структура каждого правила полностью соответсвует указанному в документации и спецификации
2. pipeline - конвейер обработки правил Sigma. Более подробно ниже и в документации Sigma
3. case-sensitive - по умолчанию плагин sigma игнорирует регистр в тексте события и его полей. Данное поле позволяет управлять этим поведением, определяя, чувствителен ли плагин к регистру (case-sensitive: true) или нет (case-sensitive: false)
4. deny - отклонять событие, если оно не соответствует ни одному из правил. По умолчанию события не отклоняются

Пример конфигурации:

processors:
  - module: sigma
    case-sensitive: false
    deny: true
    rules:
      # Источник - https://github.com/SigmaHQ/sigma/blob/master/rules/linux/builtin/lnx_buffer_overflows.yml
      - title: Buffer Overflow Attempts
        id: 18b042f0-2ecd-4b6e-9f8d-aa7a7e7de781
        status: stable
        description: Detects buffer overflow attempts in Unix system log files
        references:
          - https://github.com/ossec/ossec-hids/blob/1ecffb1b884607cb12e619f9ab3c04f530801083/etc/rules/attack_rules.xml
        author: Florian Roth (Nextron Systems)
        date: 2017/03/01
        tags:
          - attack.t1068
          - attack.privilege_escalation
        logsource:
          product: linux
        detection:
          keywords:
            - 'attempt to execute code on stack by'
            - 'FTP LOGIN FROM .* 0bin0sh'
            - 'rpc.statd[\d+]: gethostbyname error for'
            - 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'
          condition: keywords
        falsepositives:
          - Unknown
        level: high

В данном примере используется правило, детектирующее попытку переполнения буфера в Linux. Более подробно о том, как плагин обрабатывает блок detection будет рассказано далее. Если событие не будет соответствовать правилу (причем, регистронезависимо, т.к. case-sensitive равен false), то оно не будет отправлено на дальнейшую обработку, поскольку оно будет отклонено — deny равен true.

Обработка события с помощью блока detection правила

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

1. По ключевым словам - идет проверка вхождения заданных ключевых слов в исходный текст события. Если говорить в контексте YAML, то для применения этого способа в блоках selection необходимо указать ключевые слова в виде списка, например:

   detection:
     my_keywords:
       - первое слово
       - второе слово
       - третье слово
     condition: my_keywords

2. По полю - идет проверка соответствия поля заданному значению. Для применения этого способа необходимо реализовать selection как словарь, а для конкретного поля запись словаря должна иметь тип "строка-строка". Например:

   detection:
     field_selection:
       field: value
       second_field: second_value
   condition: field_selection

3. Множественная проверка по полю - идет проверка соответствия поля одному из заданных значений. Для применения этого способа необходимо реализовать selection как словарь, а для конкретного поля запись словаря должна иметь тип "строка-список строк". Например:

   detection:
     field_list_selection:
       field:
         - first_value
         - second_value
         - third_value
   condition: field_list_selection

Реализация плагина sigma в KOMRAD интерпретирует эти способы фильтрации следующим образом:

• Способ фильтрации по ключевым словам представляет собой поиск любого из ключевых слов в исходном тексте события, т.е в поле Raw.
• Способ фильтрации по полю представляет собой соответствие значения поля (нормализованного, например field превратится в Field) заданному.
• Способ множественной фильтрации по полю представляет собой соответствие значения поля (также нормализованного) любому из заданных.

Результатом применения каждого блока selection является логическое значение - подходит событие под этот блок или нет. Чтобы на основе результатов блоков сделать вывод о том, подходит событие под все правило или нет, необходимо использовать поле condition. Более подробно о нем можно прочитать в документации. Если описать его вкратце: можно задать возможные комбинации результатов блоков (с помощью И, ИЛИ и НЕ).

Также полезной фишкой в правилах Sigma являются модификаторы, позволяющие как-либо обработать анализируемый текст либо поменять семантику правил. Например, с их помощью можно использовать регулярные выражения, анализировать текст в base64 и многое другое. Плагин sigma поддерживает модификаторы startswith, endswith, re, contains и all.

Результат применения плагина к событию

После того, как плагин полностью обработал событие, если событие соответствует хотя бы одному правилу, то в это событие будет добавлено новое поле - Sigma.MatchedRules. Это поле будет содержать массив имен правил, под которые подходит событие. Поле можно использовать для дальнейшей фильтрации и корреляции.

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

Модификаторы полей

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

contains

Модификатор contains изменяет смысл условия со строковым значением на "содержит ли поле эту строку" (по умолчанию - "соответствует ли поле этой строке"). Модификатор можно применять только к строковым значением, либо к регулярным выражениям (т.е. после модификатора re).

startswith

Модификатор startswith изменяет смысл условия со строковым значением на "содержит ли поле эту строку в качестве префикса" (по умолчанию - "соответствует ли поле этой строке"). Модификатор можно применять только к строковым значением, либо к регулярным выражениям (т.е. после модификатора re).

endswith

Модификатор endswith изменяет смысл условия со строковым значением на "содержит ли поле эту строку в качестве окончания" (по умолчанию - "соответствует ли поле этой строке"). Модификатор можно применять только к строковым значением, либо к регулярным выражениям (т.е. после модификатора re).

base64 и base64offset

Модификатор base64 заменяет строковое значение на его представление в формате base64. Модификатор нельзя применять к строкам, содержащим wildcard (* или ?).

Модификатор base64offset заменяет строковое значение на 3 его представления в формате base64 с разными сдвигами. Более подробно о причинах его использовать вместо base64 можно прочесть в документации.

wide

Модификатор wide заменяет строковое значение на его представление в кодировке UTF-16LE (под Windows). Более подробно — в документации Sigma.

Внимание: на момент написания статьи в документации Sigma содержится неактуальная информация о названиях модификатора. Реализация правил Sigma в KOMRAD и pySigma версии 0.11.6 поддерживают только одно название — wide.

windash

Аргументы командной строки (флаги) Windows можно писать в двух видах:

• через слэш /
• через дефис -

Модификатор windash заменяет аргументы командной строки в строковом значении сразу на оба вида (/ и -). Более подробно о модификаторе и с примером можно прочесть в документации.

re

Модификатор re представляет строковое значение как регулярное выражение, заменяя смысл условия на "соответствует ли поле заданному регулярному выражению". Внимание: в реализации Комрад регулярные выражения должны описываться в формате re2.

Флаги регулярного выражения (i, ignorecase, m, multiline, s, dotall)

После модификатора re можно применить ряд модификаторов, изменяющих регулярное выражение и добавляющих к нему "флаги". Модификаторы:

• i или ignorecase — сделать регулярное выражение регистронезависимым (соответстует флагу i в синтаксисе re2). Имеет смысл, только если в плагине выставлено case-sensitive: true - иначе регулярное выражение будет регистронезависимым без учета наличия/отсутствия этого флага.
• m или multiline — включить многостроковый режим в регулярном выражении (т.е. заставить ^ и $ соответствовать не только началу/концу текста, но и началу/концу любой строчки). Соответствует флагу m в синтаксисе re2.
• s или dotall — . также соответсвует переносу строки. Соответствует флагу s в синтаксисе re2.

cidr

Модификатор cidr используется к строковому значению, содержащему сетевой префикс CIDR. Этот модификатор заменяет смысл условия на "содержится ли в сети IP-адрес, заданный в поле".

all

По умолчанию, если в условии для поля указано несколько значений, то они связываются логическим оператором ИЛИ (т.е. поле должно соответствовать одному из значений). Модификатор all позволяет заменить ИЛИ на И, меняя значение условия на "соответсвует ли поле всем значениям". Пример можно увидеть в документации.

gt, gte, lt, lte

Данные модификаторы применяются к числовому значению и меняют его смысл с "соответсвует ли поле значению" на какое-либо сравнение.

Модификатор	Смысл условия
gt	Значение поля больше, чем заданное
gte	Значение поля больше, либо равно заданному
lt	Значение поля меньше, чем заданное
lte	Значение поля меньше, либо равно заданному

expand

Модификатор expand должен использоваться вместе с конвейрами (pipeline). Данный модификатор при применении к строковому значению позволяет заменить в нем заполнители на значения, определяемые конвейером. Пример можно найти в документации.

Конвейеры (pipeline)

Поскольку формат правил Sigma представлен, как некоторое обобщение правил обнаружения, то он, конечно, не учитывает специфики различных систем (SIEM и прочих), в нативные правила которых конвертируются правила Sigma. Чтобы исправить эту ситуацию, Sigma поддерживает два механизма:

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

Механизм конвейера реализован в блоке pipeline конфигурации правила и описывается аналогично конвейерам Sigma.

На верхнем уровне конвейер состоит из 2 полей (вообще, четырех, но имя и приоритет в плагине роли не играют):

• vars — словарь переменных, используемых в трансформациях. В качестве ключа указывается имя переменной, а в качестве значения — строка либо список строк.
• transformations — список трансформаций, применяемых к правилу.

В свою очередь, каждая трансформация состоит из следующих полей:

• id — строковый идентификатор трансформации, который может быть использован при дальнейших трансформациях для ссылки на эту
• rule_conditions — условия, применяемые ко всему правилу
• detection_item_conditions — условия, применяемые к отдельным элементам detections в правиле (к каждой паре "поле-значения" в случае фильтрации "по полю" либо ко всему блоку в случае фильтрации "по ключевым словам")
• field_name_conditions — условия, применяемые к названию полей
• rule_cond_op — оператор объединений условий rule_conditions. Может иметь значения and (к условиям применяется логическое И), либо any (к условиям применяется логическое ИЛИ). Если не указано, то принимает значение and
• detection_item_cond_op — аналогично rule_cond_op, но по отношению к detection_item_conditions
• field_name_cond_op — аналогично rule_cond_op, но по отношению к field_name_conditions
• rule_cond_not — инвертировать ли результат объединения условий rule_conditions. Если не указан, принимает значение false
• detection_item_cond_not — аналогично rule_cond_not, но по отношению к detection_item_conditions
• field_name_cond_not — аналогично rule_cond_not, но по отношению к field_name_conditions
• type — тип трансформации
• специфические поля для конкретного типа трансформации

В каждом элементе условий указывается тип в поле type, а также специфические поля для конкретного типа.

Условия для правил (rule_conditions)

logsource

Условие logsource позволяет проверить, соответствует ли блок правил logsource определенным условиям. В качестве полей для условия можно указать category, product и service. Для каждого непустого поля в условии проверяется равенство значения условия значению в правиле. Пример:

type: logsource
product: windows
category: process_creation

contains_detection_item

Условие contains_detection_item проверяет, есть ли в правиле элемент detections с заданным полем и значением. Если в элементе несколько значений, проверяет, соответствует ли заданному значению хотя бы одно из них.

В качестве полей для этого условия указываются field — имя поля, а также value — значение поля.

Пример:

type: contains_detection_item
field: EventID
value: 7

processing_item_applied

Не путать с аналогичными условиям в блоках detection_item_conditions и field_name_conditions.

Условие processing_item_applied проверяет, было ли правило обработано трансформацией с заданным идентификатором. Имеет единственное поле processing_item_id — идентификатор трансформации.

Пример:

type: processing_item_applied
id: previous_transformation

tag

Условие tag проверяет, есть ли в правиле заданный тег. Имеет единственное поле tag — значение тега.

Пример:

type: tag
tag: attack.persistence

Условия для элементов detections (detection_item_conditions)

match_string

Условие match_string проверяет, есть ли в элементе строковые значения, соответствующие регулярному выражению.

Поля:

• pattern — строка с регулярным выражением
• cond — условие объединения результатов для каждого значения (and, any). По умолчанию — and
• negate — инвертировать ли результат объединения. По умолчанию — false

Пример:

type: match_string
cond: any
pattern: "^\\*\\\\?[^\\\\]+$"
negate: true

is_null

Условие is_null проверяет, есть ли в элементе значения null. Имеет единственное поле cond — условие объединения результатов для каждого значения (and, any). По умолчанию — and.

Пример:

type: is_null
cond: any

processing_item_applied

Не путать с аналогичными условиям в блоках rule_conditions и field_name_conditions.

Условие processing_item_applied проверяет, был ли элемент обработан трансформацией с заданным идентификатором. Имеет единственное поле processing_item_id — идентификатор трансформации.

Пример:

type: processing_item_applied
id: previous_transformation

Условия для названий полей (field_name_conditions)

include_fields

Условие include_fields проверяет, есть ли название поля в заданном списке. Содержит единственное поле fields — список допустимых полей.

Пример:

type: include_fields
fields:
  - Hashes

exclude_fields

Условие exclude_fields проверяет, что название поле не содержится в заданном списке. Содержит единственное поле field — список недопустимых полей.

Пример:

type: exclude_fields
fields: [Hashes, EventID]

processing_item_applied

Не путать с аналогичными условиям в блоках rule_conditions и detection_item_conditions.

Условие processing_item_applied проверяет, было ли название поля обработано трансформацией с заданным идентификатором. Имеет единственное поле processing_item_id — идентификатор трансформации.

Пример:

type: processing_item_applied
id: previous_transformation

Трансформации

Условия применения транформации

Чтобы трансформация применилась к правилу, необходимо, чтобы правило соответствовало условиям для правил rule_conditions.

Дополнительно, если трансформация как-то изменяет отдельные элементы detections (внимание: не блоки, а именно отдельные элементы — пары "поле-значение", либо блок keywords), то этот элемент должен соответствовать условиям detection_item_conditions, а также хотя бы одно поле (полей может быть больше одного, если до этого применялась трансформация изменения названия поля) в этом элементе должно соответствовать условиям field_name_conditions.

Если трансформация изменяет названия полей, то изменяемое поле должно соответствовать условиям field_name_conditions.

Заполнители (placeholders)

Некоторые трансформации работают с так называемыми заполнителями - аналогами переменных окружения или шаблонами. Заполнители можно добавлять в строковые значения в виде %имя%. Чтобы "активировать" заполнители и заменить их какими-то значениями, необходимо добавить к полю модификатор expand, а затем добавить в конвейер нужные трансформации.

field_name_mapping

Трансформация field_name_mapping заменяет поля в detections, используя заданный словарь mapping. В словаре в качестве ключей указывается старое имя поля, а в качестве значения — строка или список строк, на которые заменится поле.

Пример:

id: useragent_mapping
type: field_name_mapping
mapping:
  EventID:
    - event_id
    - evtid
  c-useragent: useragent
  cs-host: hostname
  c-ip: ip

field_name_prefix_mapping

Трансформация field_name_prefix_mapping похожа на трансформацию field_name_mapping, однако, вместо полной замены поля на новые, происходит замена префиксов. Если поле начинается с какого-либо ключа словаря mapping — заменяет этот префикс на новые префиксы.

Пример:

id: integritylevel_prefix_mapping
type: field_name_prefix_mapping
mapping:
  win.: proc.
  old.:
    - new.
    - nuevo.

drop_detection_item

Трансформация drop_detection_item удаляет элементы в detections. Рекомендуется использовать данную трансформацию вместе с какими-либо условиями.

Пример:

id: hashes_drop_sysmon-specific-field
type: drop_detection_item
field_name_conditions:
  - type: include_fields
    fields:
      - Hashes
rule_conditions:
  - type: logsource
    product: windows
    category: process_creation

field_name_suffix

Трансформация field_name_suffix добавляет заданное в поле suffix значение в конец названий полей.

Пример:

id: suffix_transformation
type: field_name_suffix
suffix: .end

field_name_prefix

Трансформация field_name_prefix добавляет заданное в поле prefix значение в начало названий полей.

Пример:

id: prefix_transformation
type: field_name_prefix
suffix: start.

wildcard_placeholders

Трансформация wildcard_placeholders применяется к строкам под модификатором expand и заменяет заполнители на символ *, соответствующий любым символам.

Трансформация содержит следующие поля:

• include — список включенных имен заполнителей
• exclude — список исключенных имен заполнителей

Внимание!

Трансформация не поддерживает одновременное использовать списков include и exclude. Если ни одно из двух полей не указано — трансформация применяется ко всем заполнителям

Пример:

name: transformation_demo
priority: 100
transformations:
  - id: wildcard_placeholders_transformation
    type: wildcard_placeholders

value_placeholders

Трансформация value_placeholders применяется к строкам под модификатором expand и заменяет заполнители на соответствующие переменные из поля vars всего конвейера.

Трансформация содержит следующие поля:

• include — список включенных имен заполнителей
• exclude — список исключенных имен заполнителей

Внимание!

Трансформация не поддерживает одновременное использовать списков include и exclude. Если ни одно из двух полей не указано - трансформация применяется ко всем заполнителям

Пример (всего конвейера):

name: value_placeholder_pipeline
vars:
  administrator_name:
    - "Administrator"
    - "Admin"
    - "SysAdmin"
transformations:
  - type: value_placeholders
    include:
      - "administrator_name"

add_condition

Трансформация add_condition позволяет добавить новый блок условий в detections.

Поля:

• conditions — словарь условий: ключ — название поля; значение — строка/список строк
• template — рассматривать строки в значениях словаря conditions как шаблоны или нет. Под шаблонами подразумевается то, что подобно переменным окружения ($name, ${name}) будут заменены псевдопеременные category, product и service на соответствующие поля logsource правила
• negated — инвертируется ли результат нового блока или нет

Рассмотрим подробнее, как работает трансформация. Она делает две вещи:

1. Добавляет новый блок в detection со случайно сгенерированным именем.

2. Изменяет условие в detection.condition на логическое "И" сгенерированного блока и старого выражения detection.condition. Если результат инвертируется, то перед первым слагаемым (т.е. для сгенерированного блока) будет выставлено логическое "НЕ".

Пример:

id: logsource_conds
type: add_condition
template: true
negated: true
conditions:
  field1:
    - "category: ${category}"
    - "value"
  field2: "${product} is nice"

Тогда для правила (некоторые блоки убраны)

logsource:
  product: windows
  category: file_event
detection:
  selection:
    TargetFilename|contains:
      - '\Microsoft\Teams\Cookies'
      - '\Microsoft\Teams\Local Storage\leveldb'
  filter:
    Image|contains: '\Microsoft\Teams\current\Teams.exe'
  condition: selection and not filter

получим

logsource:
  product: windows
  category: file_event
detection:
  GENERATED_NAME:
    field1:
      - "category: file_event"
      - "value"
    field2: "windows is nice"
  selection:
    TargetFilename|contains:
      - '\Microsoft\Teams\Cookies'
      - '\Microsoft\Teams\Local Storage\leveldb'
  filter:
    Image|contains: '\Microsoft\Teams\current\Teams.exe'
  condition: not GENERATED_NAME and (selection and not filter)

change_logsource

Трансформация change_logsource заменяет поля в блоке logsource правила. Поля данной трансформации: category, product, service. При применении трансформация заменяет соответствующие поля в logsource, если новое значение не пустое.

Пример:

id: change_logsource
type: change_logsource
category: security

replace_string

Трансформация replace_string заменяет совпавшие с регулярным выражениям части строк на заданную строку.

Поля:

• regex — регулярное выражение для поиска совпадений
• replacement — строка-заменитель

ВАЖНО!

В отличие от оригинальной реализации, реализация KOMRAD использует регулярные выражения re2. Поэтому, например, для обращения к захваченным группам (captured groups) нужно использовать синтаксис "$1" вместо "\1"

Пример:

id: image_file_only
type: replace_string
regex: "^\\*\\\\([^\\\\]+)$"
replacement: "$1"

map_string

Трансформация map_string заменяет строковые значения на соответствующие им значения из словаря mapping.

Пример:

id: replace_fruits
type: map_string
mapping:
  apple: manzana
  orange: naranja
  banana:
    - banana
    - plátano

set_value

Трансформация set_value заменяет все значения на заданное.

Поля:

• value — значение-заменитель
• force_type — приведение к типу. Возможные значения: str - приведение к строке, num - приведение к числу. Если не указано, то привидения нет.

Пример:

id: replace_null
type: set_value
value: ""
force_type: str
detection_item_conditions:
  - type: is_null
    cond: all

rule_failure

Трансформация rule_failure приводит к ошибке с заданным текстом message. Данную трансформацию имеет смысл использовать вместе с условиями rule_conditions, чтобы вызывать ошибку при неподходящих правилах (например, конвейер выстроен под linux, а передается правило windows).

Пример:

id: cs_drop_unsupported_logsource_sysmon_status
type: rule_failure
message: CrowdStrike logs do not support sysmon_status logs at this time.
rule_conditions:
  - type: logsource
    product: windows
    category: sysmon_status

detection_item_failure

Трансформация detection_item_failure приводит к ошибке с заданным текстом message. Данную трансформацию имеет смысл использовать вместе с условиями *conditions, чтобы вызывать ошибку при неподходящих элементах условий.

Пример:

id: cs_drop_eventid
type: detection_item_failure
message: CrowdStrike logs do not support the field EventID at this time.
field_name_conditions:
  - type: include_fields
    fields:
      - EventID
rule_conditions:
  - type: logsource
    product: windows

Примеры использования плагина

Анализ логов аудита организации в GitHub

В репозитории правил Sigma есть правило для анализа логов аудита GitHub на предмет удаления сущностей (окружений, репозиториев, проектов и т.д.). Попробуем адаптировать это правило под KOMRAD и плагин Sigma в частности. Для этого я создал свою организацию на GitHub, затем создал и удалил репозиторий в ней. После (с помощью этой статьи) я экспортировал логи аудита в формате JSON. Там много записей, но нас интересует одна конкретная:

{"@timestamp":1715693058818,"_document_id":"ouNIxhZhxGrFPavsK0IMzA","action":"repo.destroy","actor":"KSpaceer","actor_id":101411067,"actor_is_bot":false,"actor_location":{"country_code":"RU"},"created_at":1715693058818,"operation_type":"remove","org":"KSpaceerTestOrganization","org_id":169812859,"public_repo":false,"repo":"KSpaceerTestOrganization/KSpaceerTestRepoToDelete","repo_id":800510383,"request_category":"other","user_agent":"Mozilla/5.0 (X11 Ubuntu Linux x86_64 rv:125.0) Gecko/20100101 Firefox/125.0","visibility":"private"}

Это событие можно распарсить с помощью, например, плагина json. Попробуем объединить два плагина в блоке processors:

processors:
  - module: json
    patterns:
      - expr: "@timestamp"
        to: ECS.Event.Start
      - expr: "action"
        to: ECS.Event.Action
  - module: sigma
    pipeline:
      name: rename_action_field
      transformations:
        - id: field_mapping
          type: field_name_mapping
          mapping:
            action: ECS.Event.Action
    rules:
      - title: Github Delete Action Invoked
        id: 16a71777-0b2e-4db7-9888-9d59cb75200b
        status: test
        description: Detects delete action in the Github audit logs for codespaces, environment, project and repo.
        author: Muhammad Faisal (@faisalusuf)
        date: 2023/01/19
        references:
          - https://docs.github.com/en/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/ reviewing-the-audit-log-for-your-organization#audit-log-actions
        tags:
          - attack.impact
          - attack.collection
          - attack.t1213.003
        logsource:
          product: github
          service: audit
          definition: 'Requirements: The audit log streaming feature must be enabled to be able to receive such logs. You can enable following the documentation here: https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/streaming-the-audit-log-for-your-enterprise#setting-up-audit-log-streaming'
        detection:
          selection:
            action:
              - 'codespaces.delete'
              - 'environment.delete'
              - 'project.delete'
              - 'repo.destroy'
          condition: selection
        falsepositives:
          - Validate the deletion activity is permitted. The "actor" field need to be validated.
        level: medium

Можете попробовать применить этот плагин на коллекторе с приведенным выше событием. В результате добавится еще одно поле Sigma.MatchedRules с единственным элементом Github Delete Action Invoked.

Поиск подозрительных запросов SQL

Используем правило, помогающее обнаружить подозрительные запросы SQL. Для проверки этого правила я использую Clickhouse, а более конкретно - запись из лога /var/log/clickhouse-server/clickhouse-server.log:

2024.05.14 13:44:12.695795 [ 1371 ] {173428c2-1a4e-4e2b-8c89-6c5574951251} <Debug> executeQuery: (from 172.18.0.1:52248, user: komrad) DROP TABLE test_table (stage: Complete)

Поскольку правило работает на основе способа Keywords, плагин sigma можно использовать сам по себе без предварительного парсинга события:

processors:
  - module: sigma
    rules:
      - title: Suspicious SQL Query
        id: d84c0ded-edd7-4123-80ed-348bb3ccc4d5
        status: test
        description: Detects suspicious SQL query keywrods that are often used during recon, exfiltration or destructive activities. Such as dropping tables and selecting wildcard fields
        author: '@juju4'
        date: 2022/12/27
        references:
          - https://github.com/sqlmapproject/sqlmap
        tags:
          - attack.exfiltration
          - attack.initial_access
          - attack.privilege_escalation
          - attack.t1190
          - attack.t1505.001
        logsource:
          category: database
          definition: 'Requirements: Must be able to log the SQL queries'
        detection:
          keywords:
            - 'drop'
            - 'truncate'
            - 'dump'
            - 'select \*'
          condition: keywords
        falsepositives:
          - Inventory and monitoring activity
          - Vulnerability scanners
          - Legitimate applications
        level: medium

Поскольку по умолчанию плагин sigma регистронезависимый, то наш лог подойдет под правило (DROP TABLE соотносится с ключевым словом drop) и в поле Sigma.MatchedRules будет элемент Suspicious SQL Query. Если сделать плагин регистрозависимым (case-sensitive: true), то событие не подойдет под правило, и поля Sigma.MatchedRules не будет.

Обработка событий Windows

Для обработки событий Windows с помощью правил Sigma, поступающих от WMI-агента, нужно использовать достаточно обширный конвейер для корректного изменения полей и значений. Для создания конвейера под WMI-агента в качестве источника вдохновения использовался конвейер ecs_windows. Поскольку полный конвейер очень объемен (около 600 строк), в примере будет использоваться его укороченная версия под конкретное правило.

Для примера используем правило для определения установки сервисов удаленного доступа:

processors:
  - module: sigma
    rules:
      - title: Remote Access Tool Services Have Been Installed - Security
        id: c8b00925-926c-47e3-beea-298fd563728e
        related:
          - id: 1a31b18a-f00c-4061-9900-f735b96c99fc
            type: similar
        status: experimental
        description: Detects service installation of different remote access tools software. These software are often abused by threat actors to perform
        references:
          - https://redcanary.com/blog/misbehaving-rats/
        author: Connor Martin, Nasreddine Bencherchali (Nextron Systems)
        date: 2022/12/23
        modified: 2023/11/15
        tags:
          - attack.persistence
          - attack.t1543.003
          - attack.t1569.002
        logsource:
          product: windows
          service: security
          definition: The 'System Security Extension' audit subcategory need to be enabled to log the EID 4697
        detection:
          selection:
            EventID: 4697
            ServiceName|contains:
              # Based on https://github.com/SigmaHQ/sigma/pull/2841
              - 'AmmyyAdmin' # https://www.ammyy.com/en/
              - 'Atera'
              - 'BASupportExpressSrvcUpdater' # https://www.systemlookup.com/O23/6837-BASupSrvcUpdater_exe.html
              - 'BASupportExpressStandaloneService' # https://www.systemlookup.com/O23/6839-BASupSrvc_exe.html
              - 'chromoting'
              - 'GoToAssist' # https://www.goto.com/it-management/resolve
              - 'GoToMyPC' # https://get.gotomypc.com/
              - 'jumpcloud'
              - 'LMIGuardianSvc' # https://www.logmein.com/
              - 'LogMeIn' # https://www.logmein.com/
              - 'monblanking'
              - 'Parsec'
              - 'RManService' # https://www.systemlookup.com/O23/7855-rutserv_exe.html
              - 'RPCPerformanceService' # https://www.remotepc.com/
              - 'RPCService' # https://www.remotepc.com/
              - 'SplashtopRemoteService' # https://www.splashtop.com/
              - 'SSUService'
              - 'TeamViewer'
              - 'TightVNC' # https://www.tightvnc.com/
              - 'vncserver'
              - 'Zoho'
          condition: selection
        falsepositives:
          - The rule doesn't look for anything suspicious so false positives are expected. If you use one of the tools mentioned, comment it out
        level: medium
    pipeline:
      name: WMI agent reduced pipeline
      transformations:
        - id: windows_logsource_security
          type: add_condition
          conditions:
            WMI.Channel: Security
          rule_conditions:
            - type: logsource
              product: windows
              service: security
        - id: wmi_agent-ServiceName-service-security
          type: field_name_mapping
          mapping:
            ServiceName: ECS.Service.Name
          rule_conditions:
            - type: logsource
              product: windows
              service: security
        - id: wmi_agent_field_mapping
          type: field_name_mapping
          mapping:
            EventID: ECS.Event.Code
          rule_conditions:
            - type: logsource
              product: windows

Для проверки можно добавить парсер событий журналов Windows evtx перед sigma:

module: evtx

Пример подходящего события (создано вручную, не из журнала):

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
    <EventID>4697</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>13824</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords>
    <TimeCreated SystemTime="2024-06-26T07:34:07.9997865Z" />
    <EventRecordID>88479011</EventRecordID>
    <Correlation ActivityID="{160c69ad-bc31-0001-0d6a-0c1631bcda01}" />
    <Execution ProcessID="1008" ThreadID="1552" />
    <Channel>Security</Channel>
    <Computer>test-win10-scan.scanner.lan</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="ServiceName">Atera</Data>
    <Data Name="SubjectUserSid">S-1-5-21-1404950420-2770417354-2175048974-1001</Data>
    <Data Name="SubjectUserName">Windows10</Data>
    <Data Name="SubjectDomainName">TEST-WIN10-SCAN</Data>
    <Data Name="SubjectLogonId">0x62ba919</Data>
    <Data Name="TargetName">MicrosoftAccount:user=02dxrugsqivmgdvo</Data>
    <Data Name="Type">0</Data>
    <Data Name="CountOfCredentialsReturned">0</Data>
    <Data Name="ReadOperation">%%8100</Data>
    <Data Name="ReturnCode">3221226021</Data>
    <Data Name="ProcessCreationTime">2024-06-26T07:34:07.1877374Z</Data>
    <Data Name="ClientProcessId">14684</Data>
  </EventData>
</Event>