Использование правил Sigma в Timesketch

Существует множество инструментов, которые позволяют специалистам ИБ отслеживать и детек­тировать сис­темные события. В этой статье я познакомлю вас с одним из них, который называется Sigma.

Еще по теме: Как установить и использовать Timesketch

В наших предыдущих публикациях я рассказывал, как извлечь различные события из компьютера, создавать таймлайн и настроить систему совместного анализа. Если вы разобрались с интерфейсом Timesketch, то наверняка поняли, что это мощный инструмент, который может работать не только с Plaso, но и с другими произвольными CSV, содержащими таймлайн событий. Главное, чтобы в нем присутствовали поля datetime, timestamp_desc и message (клю­чевые поля Timesketch). Это открывает возможность добавить в один тай­млайн данные из раз­ных источни­ков. Большее количество источников — лучший результат и более точная картина.

В резуль­тате этого, зачастую, получа­ется доволь­но большой тай­млайн, ког­да на каждую минуту инци­ден­та при­ходит­ся до 250k событий. Проанализировать такой объем почти невозможно. Для этого существуют инструменты Snort, Yara и Sigma.

Использование Sigma в Timesketch

Sigma появилась в 2016 году, и год спус­тя на GitHub появил­ся пер­вый релиз. Задумы­вал­ся проект в качес­тве уни­вер­саль­ного фор­мата опи­сания пра­вил детек­тирова­ния, осно­ван­ного на дан­ных из логов.

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

На сегодняшний день в репози­тории Sigma хра­нит­ся примерно 1200 пра­вил (что поч­ти на два поряд­ка боль­ше име­ющих­ся по дефол­ту ана­лиза­торов в Timesketch). Эти пра­вила поз­воля­ют найти все что хочешь, начиная от исполь­зования mimikatz и обна­руже­ния сле­дов экс­плу­ата­ции ProxyShell в Exchange до выяв­ления сле­дов работы APT-груп­пиров­ки.

На нашей вир­туал­ке с Timesketch кон­фигура­цион­ный файл для кон­верте­ра хра­нит­ся по пути:

Бла­года­ря этому Sigma и работа­ет с Timesketch. Посмотрим в него.

В раз­деле backends мы можем наб­людать все бэкен­ды, с которы­ми Sigma дол­жна работать, дабы пра­вила завелись на Timesketch:
backends:

А даль­ше идут два самых боль­ших бло­ка logsources и fieldmappings, в которых мап­пятся те самые типы источни­ков логов из бэкен­да на кон­крет­ные типы, исполь­зуемые в пра­вилах (пос­мотрим на них ниже).

В рам­ках интегра­ции Sigma в Timesketch раз­работ­чики напили­ли нам отдель­ный ана­лиза­тор во вклад­ке Analyzer и чуть мень­ше месяца назад сде­лали одно­имен­ную вклад­ку с воз­можностью прос­мотреть и при­менить каж­дое отдель­ное пра­вило пря­мо в веб‑интерфей­се.

Кло­ниру­ем себе про­ект, что­бы даль­ше было про­ще раз­бирать­ся.

Структура Sigma-правила

Все пра­вила лежат в катало­ге rules (а на нашей вир­туал­ке в /opt/timesketch/etc/timesketch/sigma/rules), опи­сыва­ются в фай­лах YAML и сос­тоят из обя­затель­ных и допол­нитель­ных сек­ций. Под­робная спе­цифи­кация есть в до­кумен­тации.

Да­вайте сра­зу пос­мотрим на пра­вило windows/process_creation/win_susp_whoami_anomaly.yml, я на его при­мере пояс­ню некото­рые поля.

А теперь заг­лянем, что за logsource category: process_creation в фай­ле sigma_config.yaml.

Из при­веден­ного фраг­мента вид­но, что пра­вило в качес­тве источни­ка дан­ных исполь­зует логи Sysmon и стан­дар­тные жур­налы Windows, а имен­но eventID 1 или 4688. Это непос­редс­твен­но те источни­ки дан­ных, в которых в пер­вой статье копал­ся Plaso и которые потом были заг­ружены в дан­ном виде в ES.

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

В ито­ге это пра­вило уле­тит на бэкенд Timesketch в сле­дующем виде:

В прин­ципе, ничего слож­ного. Давайте теперь вер­немся к нашему кей­су.

Поиск очистки логов

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

Да­вайте закинем сле­дующее пра­вило в Timesketch:

Сох­раним его, затем перебе­рем­ся в бра­узер, откро­ем наш скетч и перей­дем во вклад­ку Sigma. Как видите, наше толь­ко что добав­ленное пра­вило уже тут.

Пе­рей­дем во вклад­ку Analyze и нат­равим ана­лиза­тор Sigma со все­ми пра­вила­ми, которые в него сей­час добав­лены, на наш тай­млайн. Ждем пару мгно­вений и смот­рим на резуль­тат.

Так и есть, мы успешно обна­ружи­ли, что логи чис­тили.

Ког­да ана­лиза­тор находит в ES под­ходящий документ, он обновля­ет его, добав­ляя новое поле ts_sigma_rule, в котором записы­вает имя сра­ботав­шего пра­вила, а так­же вно­сит в поля tag и ts_ttp дан­ные из раз­дела tags нашего пра­вила. Соот­ветс­твен­но, эти поля ста­новят­ся дос­тупны­ми для поис­ка и агре­гации во вклад­ке Aggregate.

Те­перь мож­но сра­зу пос­мотреть, что же инте­рес­ного наш­лось, с помощью прос­тых зап­росов в стро­ке поис­ка, нап­ример такого:

По­нят­ное дело, ана­лизи­ровать такой объ­ем информа­ции нам­ного ком­фор­тнее, чем смот­реть на сот­ни тысяч ивен­тов, которые пред­ста­ли вашему взо­ру понача­лу.

Кро­ме того, без запус­ка ана­лиза­тора мож­но открыть каж­дое отдель­ное пра­вило во вклад­ке Sigma и нажать кноп­ку Search. Пра­вило авто­мати­чес­ки будет под­став­лено в стро­ку поис­ка и покажет вам под­ходящие события.

Верификация новых правил

Что­бы про­верить, будет ли кор­рек­тно работать най­ден­ное на прос­торах сети или написан­ное вами пра­вило в кон­крет­ной сис­теме, в Sigma пре­дус­мотрен отдель­ный инс­тру­мент, который находит­ся в катало­ге tools и называ­ется sigmac.

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

Дальнейшие инструкции

К сожале­нию, прос­то ско­пиро­вать ско­пом все пра­вила в Timesketch и запус­тить ана­лиза­тор не вый­дет. Дви­жок Sigma весь­ма про­жор­лив, и у некото­рых пра­вил могут воз­никнуть проб­лемы с интегра­цией в Timesketch (обыч­но из‑за отсутс­твия нуж­ных logsource). Поэто­му луч­ше прой­тись по спис­ку пра­вил и целенап­равлен­но выбирать те из них, которые подой­дут к кон­крет­ному кей­су. И уже пос­ле про­вер­ки с исполь­зовани­ем sigmac закиды­вать их в Timesketch. Ведь, нап­ример, если на иссле­дуемой сис­теме не был уста­нов­лен Sysmon, нет нуж­ды тра­тить вре­мя на запуск соот­ветс­тву­ющих пра­вил.

Даль­ше, как и в любом деле, пот­ребу­ется опыт. А его, прос­то читая инте­рес­ные статьи, набирать­ся слож­новато. Что­бы набить руку, вам при­дет­ся неод­нократ­но «воочию уви­деть» те или иные события, их груп­пы и теги.

Есть весь­ма полез­ные ре­пози­тории, где люди спе­циаль­но скла­дыва­ют записи событий, которые про­исхо­дят во вре­мя того или ино­го инци­ден­та. Изу­чать спо­собы их выяв­ления — один из самых прос­тых путей зарабо­тать необ­ходимый опыт. Так что запус­кайте Plaso, заг­ружайте резуль­таты в Timesketch и пишите пра­вила для их детек­та. И не забывайте потом ком­митить их в про­ект.

Кро­ме того, Sigma мож­но при­менить и по пря­мому наз­начению — под­клю­чив к SIEM-сис­теме, которой вы, воз­можно, поль­зуетесь.

Заключение

Я наде­юсь, что пос­ле проч­тения цик­ла дан­ных ста­тей у кого‑то из адми­нов по безопас­ности появит­ся вре­мя на лиш­них две чаш­ки кофе в день. Кому‑то из бра­вых бой­цов с шев­роном DFIR ста­нет нем­ного лег­че жить, а кто‑то, воз­можно, возь­мет и пришь­ет такой шев­рон себе на рукав, и HR-отде­лу оста­нет­ся отыс­кать все­го 249 996 недос­тающих человек.

Еще по теме: Создание лаборатории для анализа вредоносных файлов