Sysmon в Linux. На что способна система мониторинга Windows в чуждой среде

Мы час­то нас­тра­иваем аудит в Linux (auditd, eBPF) — и сами, и вмес­те с кол­легами. Потом при­ходят джу­ны, и выяс­няет­ся, что им... слож­но. Ну лад­но, подума­ли мы. Нем­ного извра­та — и хотя бы базовое логиро­вание в Linux всег­да мож­но нас­тро­ить, поч­ти без зат­рат.

Ос­новная цель статьи — рас­ска­зать об инс­тру­мен­те, показать его воз­можнос­ти и попол­нить копил­ку зна­ний «Хакера» еще одной занят­ной тех­нологи­ей, о которой в комь­юни­ти безопас­ников пока мало говорят.

Установка

С уста­нов­кой муд­рить не нуж­но: офи­циаль­ная инс­трук­ция прос­та и понят­на — все­го четыре коман­ды, и все готово.

Да и ребуты не нуж­ны. Что­бы запус­тить служ­бу, выпол­няем sysmon -i -n.

Мож­но про­верить, что по умол­чанию уже фик­сиру­ются какие‑то XML‑подоб­ные логи: sudo tail -f /var/log/syslog. В некото­рых дис­три­бути­вах их мож­но уви­деть через journalctl | grep sysmon. Ну и не забудь убе­дить­ся, что служ­ба вооб­ще запус­тилась: systemctl status sysmon.

Окей, health check про­шел. Базовые коман­ды похожи на вин­ду (есть хо­роший гайд по ним). Вве­дем sysmon и уви­дим минималь­ную справ­ку.

В целом на этом обзор мож­но было бы и закон­чить, но мы будем дотош­ны и пос­ледова­тель­ны. Зачем нам инс­тру­мент, который нель­зя пощупать?!

Ожидание: типы событий

Да­вай пос­мотрим, какие события может ловить Sysmon for Linux по срав­нению с его вин­довым соб­ратом. Оче­вид­но, что вин­довый может все.

Да, инс­тру­мент огра­ничен­ный, но иног­да и не нуж­но боль­шего — глав­ное, что­бы быс­тро!

Ес­ли чуть серь­езнее, то боль­шая часть воз­можнос­тей Sysmon завяза­на на проп­риетар­ные вин­довые фичи — WinAPI, WMI, осо­бен­ности NTFS, которых в Linux, оче­вид­но, мало или они вов­се отсутс­тву­ют, как, нап­ример, реестр.

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

Настройка

Что ж, давай нас­тро­им инс­тру­мент, научим его логиро­вать что‑то полез­ное и про­верим Sysmon for Linux в дей­ствии.

Нас­трой­ка дела­ется через заг­рузку кон­фигура­ции. По умол­чанию никаких пра­вил нет — в основном пишут­ся события соз­дания и завер­шения про­цес­са. Испра­вим это. Кон­фигура­цию в общем слу­чае мож­но заг­рузить как вин­довую (обоб­щенную — понят­но, что филь­тры работать не будут), так и соз­данную спе­циаль­но для Linux. Для экспе­римен­та ска­чаем кон­фиг для всех ивен­тов и пос­мотрим, на что он спо­собен.

almost_all_hunt-naked.xml

При­меним этот кон­фиг.

Про­верить, что пра­вила заг­рузились, мож­но коман­дой sysmon -c.

Эксперименты

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

В чис­том XML-пред­став­лении вывод выг­лядел бы вот так:

Но луч­ше почис­тить его:

Эта коман­да оста­вит толь­ко важ­ную информа­цию о событии.

У ути­литы SysmonLogView есть нес­коль­ко полез­ных клю­чей.

Для экспе­римен­тов мы будем исполь­зовать филь­тра­цию такого вида:

Пос­мотрим, как Sysmon себя покажет.

Создание процесса — Event ID 1

За­пус­тим прос­лушку пор­та коман­дой nc -l 9999 и выведем сге­нери­рован­ное событие.

В событии есть мет­ка вре­мени (сра­зу в UTC, что нем­ного меша­ет хан­тингу при работе на хос­те), PID про­цес­са, коман­дная стро­ка, дирек­тория, поль­зователь, хеши (чего в auditd не уви­деть) и PID родите­ля. В целом информа­ции не так мно­го (вот бы сра­зу брать имя родитель­ско­го про­цес­са, нап­ример), зато все струк­туриро­вано.

Из инте­рес­ного: коман­да history не залоги­рова­лась, что печаль­но.

Изменение временной метки файла — Event ID 2

Поп­робу­ем изме­нить вре­мен­ную мет­ку фай­ла:

И на вся­кий слу­чай еще так:

Sysmon ничего не зафик­сировал. Пред­ска­зуемо, но по‑сво­ему обид­но.

Сетевое соединение — Event ID 3

Сде­лаем прос­тей­ший зап­рос:

И пос­мотрим резуль­тат:

В логах мно­го сетевых соеди­нений, вклю­чая локаль­ные — их мы поп­робу­ем отфиль­тро­вать на сле­дующем эта­пе экспе­римен­та. Видим бинар­ник, IP-адре­са источни­ка и наз­начения и их пор­ты. Из минусов — коман­дную стро­ку все рав­но при­дет­ся искать в свя­зан­ном событии соз­дания про­цес­са. В auditd, нап­ример, событие запус­ка про­цес­са и сетево­го под­клю­чения фор­миру­ется под одним иден­тифика­тором ауди­та.

Так­же для ряда событий про­цесс (Image) получал имя <unknown process>, что печаль­но для под­систе­мы ауди­та — тол­ку от таких логов мало.

Изменение Sysmon — Event ID 4

За­косим под дурач­ка и поп­робу­ем наг­ло вклю­чить и отклю­чить автостарт служ­бы Sysmon:

Нет реак­ции. Лад­но, поп­робу­ем прос­то менять кон­фигура­цию через sysmon -i.

В ито­ге уста­нов­ка и уда­ление сер­виса через sysmon -i и sysmon -u детек­тиру­ется, но манипу­ляции со служ­бой через systemctl, увы, нет.

Процесс завершен — Event ID 5

Те­перь прер­вем запущен­ный ранее про­цесс — прос­то жмем Ctrl-C в окне с nc -l 9999.

Мы получи­ли имя бинар­ника и PID уби­того про­цес­са. Нем­ного, но чес­тная работа.

Пустышки Event ID 6–8

Эти типы событий в Linux (заг­рузка драй­вера, заг­рузка обра­за и соз­дание уда­лен­ного потока) работа­ют ина­че, чем в род­ной для Sysmon Windows, поэто­му и не детек­тиру­ются. В Linux обыч­но драй­вер — это модуль ядра, который мож­но заг­ружать и выг­ружать. Спи­сок модулей и заг­рузку и выг­рузку любого из них мож­но получить, нап­ример, так:

Образ загружен — Event ID 7

Заг­рузка обра­за в тер­миноло­гии Windows — это под­груз­ка допол­нитель­ных биб­лиотек про­цес­сом.

Создание удаленного потока — Event ID 8

Этот тип события отве­чает за выяв­ление попыток process injection через WinAPI. Во всех трех слу­чаях — пред­ска­зуемо никакой реак­ции от Sysmon.

Прямое чтение с диска — Event ID 9

С этим уже инте­рес­нее. Пря­мое чте­ние с блоч­ных устрой­ств в обход прог­рам­мных изо­ляций — одна из популяр­ных тех­ник зло­умыш­ленни­ков. Пос­мотрим, какие дис­ки у нас есть, через lsblk и поп­робу­ем про­читать пер­вый попав­ший­ся через open /dev/sda.

И куда же без ста­рой доб­рой dd:

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

Получен доступ к процессу — Event ID 10

Са­мый прос­той спо­соб про­верить это — запус­тить трас­сиров­ку, нап­ример так: strace cat /etc/passwd.

В зарегис­три­рован­ных событи­ях вид­но, что про­цесс strace дей­стви­тель­но под­клю­чал­ся к cat: факт есть, но что имен­но про­исхо­дило — неяс­но. Так­же этот тип не детек­тировал соз­дание дам­пов памяти про­цес­сов, нап­ример procdump -w chromium.

Создание файла — Event ID 11

С отсле­жива­нием соз­дания фай­лов Sysmon справ­ляет­ся. Дела­ем touch xakep, резуль­тат:

В целом — при­емле­мо. Но почему не отме­чает­ся root-поль­зователь, непонят­но. При работе от любого дру­гого поль­зовате­ля юзер опре­деля­ется кор­рек­тно.

Пустышки — Event ID 12–15

Для событий 12–15 (соз­дание или уда­ление объ­екта в реес­тре — 12, изме­нение зна­чения парамет­ра реес­тра — 13, пере­име­нова­ние объ­екта реес­тра — 14 и соз­дание фай­лового потока — 15) Sysmon в Linux ничего не задетек­тит: в сис­теме нет реес­тра, а исполь­зует­ся фай­ловая сис­тема (ext, XFS и про­чие), отличная от жур­налиру­емой NTFS.

По­это­му едем даль­ше.

Изменение конфигурации Sysmon — Event ID 16

Поп­робу­ем очис­тить нас­трой­ки через sysmon -c --:

И уста­новить новые.

Sysmon -i /home/alex/almost_all_hunt-naked.xml

Хо­тя сброс на парамет­ры по умол­чанию и не был явно отме­чен, по событи­ям соз­дания про­цес­сов мы все еще можем понять при­мер­ный кон­текст изме­нений.

Пустышки — Event ID 17–22

Здесь у нас оче­ред­ной набор пус­тышек. Соз­дание име­нован­ного канала (Event ID 17) мож­но вос­про­извести коман­дами mknod xakep_named_pipe p или mkfifo test_pipe. Поп­робу­ем к ним под­клю­чить­ся (Event ID 18):

Шум леса, свер­чки, шелест тра­вы.

Для событий, свя­зан­ных с WMI (Event ID 19, 20, 21), пред­ска­зуемо ничего не будет из‑за проп­риетар­ности тех­нологии (ну нет WMI в Linux).

Боль­шие надеж­ды мы воз­лагали на Event ID 22 — DNS-зап­росы: такие арте­фак­ты очень полез­ны при рас­сле­дова­нии киберин­циден­тов. Но реаль­ность пол­на разоча­рова­ний: вмес­то это­го в логе — лишь nslookup opera.com, ping mail.ru, curl -v https://yandex.ru.

Зве­нящая пус­тота, но мы про­дол­жаем дви­гать­ся даль­ше.

Файл удален с сохранением копии — Event ID 23

Прос­то уда­лим файл: rm file.

Что инте­рес­но, событие 26, которое называ­ется «Уда­ление фай­ла», как раз не регис­три­рует­ся. Но факт уда­ления зафик­сирован — это обна­дежи­вает.

Финальные пустоты — Event ID 24–29, 255

Поп­робу­ем обра­тить­ся к буферу обме­на (Event ID 24) — пред­ска­зуемо не фик­сиру­ется (clip, echo lalka | xclip -sel clip).

Из­менение обра­за про­цес­са (Event ID 25). В Linux у нас не получи­лось это вос­про­извести (поп­робуй заменить запущен­ный про­цесс на лету, ага).

И уда­ление фай­ла (Event ID 26) — через touch supahaker && rm supahaker — фик­сиру­ется в событии 23, но почему‑то не в 26.

В акту­аль­ных сбор­ках для Windows у Sysmon есть события 27 (бло­киров­ка исполня­емо­го фай­ла), 28 (бло­киров­ка поб­лочно­го уда­ления фай­ла), 29 (исполня­емый файл уда­лен). Но это каса­ется толь­ко PE-фай­лов в Windows.

Оши­бок (код 255) мы тоже не получа­ли во вре­мя испы­таний.

Воз­можнос­ти оце­нили. Уста­нов­ка и пер­вичная нас­трой­ка выг­лядят прос­то, но, может, есть что‑то пок­руче? Давай поп­робу­ем под­сунуть кон­фигура­ции с наворо­тами — филь­тра­цией событий и обо­гаще­нием, хотя бы по тех­никам мат­рицы ATT&CK.

Эксперименты с обогащением конфигов

Ссыл­ки на некото­рые кон­фиги для Linux мож­но най­ти в статье «При­мене­ние ути­литы Sysmon для повыше­ния уров­ня кибер­безопас­ности» Рус­лана Рах­метова.

Не­кото­рые при­емы и фраг­менты кон­фигура­ции можешь под­смот­реть в статье Hunting for Persistence in Linux и шпар­галке.

Для раз­вле­чения уста­новим «прод­винутую кон­фигу» из MSTIC и пос­мотрим, как изме­нит­ся фор­мат вывода.

Пос­ле это­го количес­тво генери­руемых ивен­тов рез­ко упа­ло — из‑за кучи филь­тров. А коман­да crontab отве­чает так:

Те­перь у нас есть поле RuleName, которое поз­воля­ет быс­трее атри­бути­ровать активность. Но все же, хоть прош­лая кон­фигура­ция и была избы­точ­ной (логиро­вала все и писала в гро­моз­дком Windows-фор­мате), там сох­ранялось мно­го полез­ных событий для рас­сле­дова­ния. Отка­тим нас­трой­ки на дефол­тные: sysmon -c --.

Что­бы не зас­памить событи­ями сетево­го вза­имо­дей­ствия, мож­но отфиль­тро­вать локаль­ные обра­щения — для это­го дос­таточ­но вста­вить в кон­фиг такой блок:

Хо­тя потен­циаль­но это может при­вес­ти к потере час­ти локаль­ных соеди­нений (при­вет, Docker и тун­нели!), в типич­ных слу­чаях это­го дос­таточ­но, что­бы не засорять аудит. В качес­тве домаш­него задания можешь по ана­логии отфиль­тро­вать локаль­ные IPv6-адре­са (но мы читеры и прос­то вста­вили в код выше строч­ку вида <SourceIsIpv6>trueSourceIsIpv6>).

Немного про eBPF

Как ты понял, Sysmon for Linux осно­ван на eBPF. Если тебе инте­рес­ны детали реали­зации eBPF в Sysmon, мож­но взгля­нуть на ис­ходный код — там перечис­лены, нап­ример, основные сис­темные вызовы, которые исполь­зуют­ся для фор­мирова­ния записи события в Sysmon. В час­тнос­ти, для соз­дания про­цес­са — execve, execveat; соз­дания фай­ла — creat; откры­тия фай­ла — open, openat; уда­ления фай­ла — unlink, unlinkat; TCP‑соеди­нений — accept, accept4; дос­тупа к про­цес­су — ptrace; UDP‑соеди­нений — recvfrom, recvmsg, recvmmsg, read; зак­рытия фай­лового дес­крип­тора — close.

Этот спи­сок сис­темных вызовов ты можешь взять за осно­ву, что­бы реали­зовы­вать пра­вила для auditd или Tetragon.

Выводы

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

Что­бы выжать из Sysmon мак­симум, в кон­фиге нуж­но най­ти баланс: либо тонуть в куче мусор­ных событий, либо отфиль­тро­вать поч­ти всю активность, соз­давая пра­вила для поч­ти каж­дой извес­тной ути­литы — и сис­темной, и той, что может при­годить­ся в качес­тве GTFOBins. Супер­конфи­га (как для Windows) в Linux пока не вид­но, да и вряд ли он появит­ся. Дадим еще пару ссы­лок на раз­ные кон­фиги для Sysmon под Linux:

• Sysmon Modular — набор модуль­ных кон­фигов Sysmon;
• Sysmon Config от ion-storm — рас­ширен­ные пра­вила;
• Sysmon Config от SwiftOnSecurity — клас­сичес­кий базовый набор;
• MSTIC Sysmon для Linux — офи­циаль­ные кон­фиги Microsoft.

В ито­ге фик­сиру­ется доволь­но мало информа­ции, и качес­тво тоже не очень; из плю­сов — все в понят­ном виде, минималь­ный набор при­год­ных для рас­сле­дова­ния событий, есть хеши. Но на этом, пожалуй, и все. Так что как игрушка и потен­циаль­ная жер­тва фор­ков — почему нет. Но мы никог­да не видели, что­бы кто‑то исполь­зовал Sysmon for Linux ина­че, чем как упражне­ние. Но кто зна­ет, это может и изме­нить­ся.