Tuesday, December 1, 2020

SOC Forum 2020 Live: Роботы среди нас!

Вкалывают роботы, 

А не человек!

"До чего дошёл прогресс" Крылатов. Энтин


Сегодня на SOC forum рассказывал о машинном обучении для целей триажа алертов.

Выкладываю презентацию.

Было всего 15 минут, поэтому есть риск, что не успел донести даже то, что планировал. Попробую поправить ситуацию в этой заметке, написав текстом примерно то, что хотел рассказать (заголовок - это название слайда).


FP против FN

Для начала рассмотрим самый известный компромисс между пропусками и ложными срабатываниями.

Поскольку, чем заметнее зло, тем проще его обнаруживать и обезвреживать полностью автоматически, есть непреодолимое желание смещать свою способность обнаруживать автоматизированно (красный пунктир)  в сторону абсолютно невидимого Зла.

Да, это позволит нам снизить Ошибочные пропуски (False negative, FN), но увеличит количество Ложных срабатываний (False Positive, FP), которые, несомненно отразятся на нашей операционной эффективности – нам нужно много людей на первой линии, которые будут заниматься триажем алертов…. 


Типовое применение МашОбуча

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

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


Другое применение МашОбуча

Прекрасно осознавая, как выглядят современные атаки, и понимая, что платой за возможность их обнаружить будет огромное количество алертов для анализа на линии SOC (так как мы хотим их обнаруживать, не хотим качеством обнаружения сервиса оплачивать наши же ресурсные проблемы!), мы задумались как разгрузить аналитиков с помощь того же Машобуча. Как решить проблему эффективного триажа? Как из образовавшегося потока алертов отфильтровать те, что являются ложными срабатываниями, и тем самым подойти к проблеме обнаружения не стороны перечисления зла, а со стороны фильтрации легитимной активности.

Так мы придумали Автоаналитика, чему и посвящен мой доклад.


Этапы пайплайна MDR

Сенсоры поставляют События, которые обрабатываются всевозможной детектирующей логикой, включая машинное обучение для целей обнаружения. В конечном счете на выходе – Алерты, представляющие из себя совокупность Событий, в которых Машина распознала что-либо подозрительное.

Аналитики получают эти алерты в IRP, смотрят на них. Если сразу понятно, что это фолса – закрывают. Если есть ощущение, что надо посмотреть более пристально – импортируют в Кейс. 

Далее, работают по кейсу в IRP (идут в События, смотрят что было до, что было после, подшивают релевантные события, строят Timeline инцидента). Если после расследования понятно, что это не фолса, пишут описание для Заказчика и публикуют в Портал.


Мечты..., превращенные в цели

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


Этапы пайплайна MDR + ML

Модель встраивается в пайплайн таким образом. Будучи автоматом, Автоаналитк является частью пайплайна автообработки.

Прежняя детектирующая логика решает проблему пропусков (FN), а Автоаналитик быстрого триажа (фильтрации FP).


Входные данные 

На слайде представлен пример реального алерта. Это массив JSON-объектов Событий, каждый объект имеет набор признаков со значениями. В качестве значений может быть что угодно: строка, число, дата, список.


Текущая агрегация

Алерт мы представляем вектором значений полей, причем, если какие-то значения встречаются несколько раз, выбирается наиболее популярное. Полученный вектор передаем на вход Модели.


FPR и TPR

У каждого классифицируемого нами алерта есть истинные классы True и False, и есть классы, предсказанные Моделью, тоже True и False. В таблице приведены все пересечения истинной и предсказанной Моделью разметки.

FPR показывает какой % из истинно ложных алертов Модель классифицировала как True инциденты. Идеальная ситуация, чтобы ложных срабатываний не было и FPR=0%.

TPR показывает какой % реальных инцидентов был распознан корректно. Идеальная ситуация, когда TPR = 100%.


ROC-кривая

Рассмотрим как меняются предсказания Модели в зависимости от Порога. На схеме "горбиками" показаны распределения истинных классов True и False, а жирный красный пунктир – наш порог принятия решения Моделью: все что справа от порога модель предсказывает как True, все что слева – False. На горбиках в зависимости от порога я отобразил уже знакомые нам множества ошибок - FP, FN и верных предсказаний - TP, TN. Горизонтально перемещая порог влево и вправо, мы можем получать разные метрики TPR и FPR. 

Положения нашего Порога и получившиеся TPR и FPR удобно смотреть на ROC-кривой. ROC-кривая также характеризует качество модели – чем больше площадь под ней, тем модель работает лучше.


Схема потока алертов

Мы считаем, что все, что можно алгоритмизировать, должно быть автоматизировано! Поэтому у нас нет понятия "Первой линии SOC, отрабатывающей плейбук".

Весь поток алертов летит в Автоаналитика и чуть более трети он классифицирует как ложное срабатывание, а то, что превышает Порог и заданную Долю фильтрации – отправляет уже на разбор Человеку. 

Маленькие ручейки в виде 3% и 5% - это потоки перепроверки, необходимых для постоянного контроля качества аналитиков.


Послесловие

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


Важной ссылкой о теме является доклад Даниила Удимова по этой же теме на профильной конференции.


Благодарности

Автоаналитик был придуман в 2017, а с 2018 уже использовался в сервисе. С тех пор он значительно изменился, и процесс его совершенствования не стоит на месте. Он - продукт труда целой команды выдающихся экспертов, которым спешу выразить безмерную благодарность, и надежду на долгое плодотворное сотрудничество как в данной, так и во многих других областях применения машинного обучения в нашем нелегком Security Operations. Ребята, спасибо Вам!












Saturday, October 10, 2020

Elastic Endpoint + SIEM - простая инфраструктура для Threat Hunting-а

В статье расскажу как быстро развернуть инфраструктуру для Threat hunting-а, бесплатно.
А здесь уже рассказано, как этим можно пользоваться.



2. Обязательно Security и SSL (уже в бесплатной версии): 

3. Обязательно Security и SSL в Kibana (раз, два)

4. Сертификаты для SSL Elastic и Kibana – использовал OpenSSL. Лучше не самоподписанный.
4.1. Делаем УЦ на OpenSSL (статей полно в Интернет, например, эта)
4.2. От этого УЦ создаем сертификты для  kibana и elastic (использовал один сертификат для обоих). Важно: Сертификат должен содержать SAN, содержащие IP
Для SAN нужен конфиг запроса, мой пример (важное выделил):
[req]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn
[ dn ]
C=RU
L=Moscow
O=Kaspersky Test
OU=SOC Test
CN=kibana
[ req_ext ]
subjectAltName = @alt_names
[ alt_names ]
DNS.1 = kibana
DNS.2 = elastic
IP.1 = 192.168.56.1
IP.2 = 192.168.220.1
Создаем запрос с созданным конфигом: openssl req -new -key kibana.key -out kibana.req -config req.conf 
Создаем сертификат подписанный ключом УЦ, с тем же конфигом: openssl x509 -req -in kibana.req -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out kibana.crt -days 5000 -extensions 'req_ext' -extfile req.conf
Полезные коммандочки:
    • Посмотреть запрос: openssl req -text -noout -verify -in kibana.req
    • Аналогично, посмотреть сертификат: openssl x509 -in kibana.crt -text -noout
5. Чтобы данные лились, в конфиге elasticsearch обязательно должен быть включен ingest node (node.ingest: true):


7. Агент – Windows, поэтому создал политику для него (“Windows”), "Default config" была.
8. Подправим URL-ы в конфигурации Ingest manager-а (IP-адреса, и https)


Правильно везде использовать HTTPS, иначе могут быть загадочные ошибки, которые сложно чинить

9. Для энроллмента агента надо создать Enrollment token

10. Энтроллим агента, удобнее использовать Fleet

Агента надо просто скачать, положить в новую папку и в ней выполнить команды, которые написаны в интерфейсе Kibana при энроллменте

Если выскакивает ошибка, надо потрастить использованный rootCA, помогает.

У агента есть несложное CLI, полный перечень команд здесь.

После энроллмента агент появляется во Fleet


В операционной системе появится два сервиса: агент и Endpoint Security

11. Можно посмотреть логи агента:

12. Детали конфигурации

13. Агенту можно назначить другу политику ли отключить от управления
14. В моем случае «Windows» - название политики для агента, посмотрим внутрь
Elastic Endpoint Security – политика EDR
System-1 – политика сервера, как обычной системы (метрики железа, дефолтные логи)

15. Посмотрим политику EDR

16. Также Elastic поставляет бесплатно «ханты», их можно включать и отключать

17. Можно и свои создавать

По хантам поставляется простенькая, но неплохая документация, некоторые сопоставлены с MITRE ATT&CK, ссылки ведут на сайт MITRE.

18. Данные от сенсоров можно обрабатывать перед индексированием
Конфигурирование можно выполняться из интерфейса Kibana, удобно.


19. Может потребоваться отредактировать продвинутые настройки

20. Конфигурация алертинга и EDR

21. Чтобы в Kibana увидеть данные сенсоров, надо завести новую роль (я дал полные права, но в реальной жизни надо следовать принципу минимума привилегий):


И своего пользователя включить в эту роль. Пользователь Elastic не имеет прав на данные, хоть и суперадмин
22. Для сбора Windows-логов поставил Winlogbeat

23. Установленного агента просто отключить (unenroll)
После Unenrollment-а пропадает сервис Elastic Endpoint


24. Когда события польются на Dashboard будет наглядно видно какой телеметрии сколько








Тестируем Elastic Endpoint Agent с Elasitc SIEM

Стандартом де-факто для самодельного MDR долгое время был sysmon и даже MITRE публикует детекты для него. Есть куча в прошлом SOC-ов, продвинувшихся в сторону MDR, как раз добавив события от sysmon. 

Но, с появлением EPP от Elastic ситуация может поменяться! Сегодня рассмотрим его поподробнее, используемая инсталляция описана здесь.

Для экспериментов я подготовил несложную Windows10-машинку, навеянную одним из последних своих упражнений на HTB, со следующим сценарием:

  • Первоначальный пробив - уязвимое Web-приложение
  • Повышение - ошибка в конфигурации сервисов Windows (специально подстроенная, в Windows по умолчанию все ОК)

Чтобы было понятно что детектим, сначала приведу пошаговое описание атаки, затем - как выглядит расследование.

Глазами Красного

1. Посканировали, нашли Web, зашли, увидели это


2. Несложное исследование помогло понять что это за приложение.

3. Под это приложение есть готовый эксплоит, 
копируем его локально

4. В самом последнем Kali не поддерживается perl2, поэтому надо творчески поправить, но, в целом, шелл забрасывается и работает

5. Будем делать шелл с помощью nc, он есть в Kali, скопируем его локально и поднимем Web-сервер

6. Скопируем на подломанную машинку nc с помощью certutil и проверим, что все получилось

7. Получим реверсивный шелл на подломанную машинку

8. Загрузим accesschk 


9. Посмотрим есть ли сервисы с уязвимой конфигурацией и найдем его


10. Заменим бинарник сервиса на nc


11. Поменяем учетную запись запуска сервиса на system (нам надо повыситься до system-а)


12. Перезапустим сервис и получим шелл от system


На этом Красный достиг своей цели, перейдем к работе Синего.


Глазами Синего. Web-shell

1. Непосредственно из первого же дашборада SIEM видно события по категориям


2. Предположим, что что-то у нас нехорошо на Endpoint

View hosts приведет на соответствующую вкладку

3. На вкладке можно анализировать события


4. Но лучше начать с алертов. Elastic считает nc чуть ли не ВПО, вероятно, в этом есть смысл. Из алерта сразу видно, что nc  подозрительно запускается из директории htdocs


5. Тут же, нажатием на кружок, можно посмотреть цепочку запуска, она достаточно длинная и очень подозрительная: httpd -> cmd -> nc -> cmd -> whoami




6. Тут же из графа можно увидеть, что nc имеет одно сетевое событие - TCP-соединение на 192.168.56.105:9001, вероятно, это и есть атакующий

7. Добавляем nc в Timeline и это покажет связанные события (фактически, можно относиться к timeline как к быстрому фильтру, который с тем же успехом можно было бы писать в поисковой строке Kibana)


Таймлайн можно сворачивать (она сохраняется автоматически) и открывать в любое время

Из таймлайна можно создавать кейс
8. Связанный с nc IoC (это как раз pivoting) IP атакующего, добавим через OR на таймлайн и найдем связанные события

Находим новую информацию здесь: HTTP-запрос от certutil (на картинке ниже добавил колонку process.name)

9. Снова посмотрим цепочку и непосредственно из нее обнаружим, что certutil выполнял файловые операции - он создал nc в C:\xampp\htdocs\upload\


10. Здесь же, из цепочки, видно, что certutil загружал файл nc с 192.168.56.105:8080

Это можно также удобно видеть из событий на таймлайне (кому как удобнее)

Что у нас есть на сейчас:
  • certutil загрузил nc с 192.168.56.105:8080
  • nc запустил реверсивный шелл на 192.168.56.105:9001 

Последовательность событий на таймлайне

Надо понять почему наш Апачи (httpd) решил запустить certutil (это наглядно видно на цепочке)


И почему httpd запустил nc

Что также можно удобно посмотреть на таймлайне

11. Предположим, что 192.168.56.105 - атакующий, посмотрим, что он делал с httpd. Известно, что httpd - сервер Апачи, посмотрим его HTTP-события

Обратим внимание на подозрительное
http.request.body.content: "GET /upload/kamehameha.php?telepathy=echo+%25CD%25 HTTP/1.1
Host: 192.168.220.99
User-Agent: python-requests/2.23.0
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Cookie: sec_session_id=aojo31cnoo6j0gufvv7idk99pv

"

В 23:45:27.468 заметен подозрительный POST, посмотрим ближе и увидим, что он сделан от Python

http.request.body.content: "POST /upload.php?id=kamehameha HTTP/1.1
Host: 192.168.220.99
User-Agent: python-requests/2.23.0
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Cookie: sec_session_id=aojo31cnoo6j0gufvv7idk99pv
Content-Length: 325
Content-Type: multipart/form-data; boundary=abfd0f202812e7186c51e3207977ffad

"

Если посмотреть что делал этот конкретный процесс httpd, то тоже ничего хорошего: запускал whoami, certutil, и т.п. , что едва ли можно считать штатной работой сервера Апачи

А еще этот httpd выполнял файловые операции

13. Предположим, что httpd записал Web-шелл, и чтобы это проверить посмотрим все файлы, записанные httpd

httpd создал странный файл Kamehameha.php в 23:45:27.468 непосредственно в момент подозрительного POST-запроса, следовательно, логично предположить, что файл был создан этим POST,  тем более его вид выше подтверждает эту гипотезу.

14. После подозрительного POST, наблюдаются запросы странного Kamehameha.php с весьма красноречивыми URL

15. С этого момента уже очевидно, что нам залили Web-shell, поэтому сделаем кейс, прямо из таймлайна, удобно



Глазами Синего. Повышение

1. На первом шаге мы расследовали реверсивный шелл на 192.168.56.105:9001


Последний cmd в этой цепочке


2. Посмотрим на этот cmd (pid 9840) более внимательно
3. Обращаем внимание на ac и обнаруживаем, что он создан certutil-ом

4. Характер команд п.2 демонстрирует повышение привилегий через ошибку конфигурации сервиса SSDPSRV,  поэтому поищем подозрительные команды, запущенные как сервис (с родителем services) и легко их находим

5. На цепочке также можно заметить и сетевые соединения на 192.168.56.105:9002

6. Недвусмысленное whoami от System

Для интересных событий можно создавать заметки

7. Все просматриваемые цепочки и таймлайны можно аттачить в кейс, в кейсе он будут ссылками



Глазами Синего. Автоматизируем Threat hunting

Очень хорошо, что мы умеем делать гипотезы и искать им подтверждение в данных. Но важная особенность Threat hunting-а - все, что однажды найдено вручную, впредь надо искать быстрее и проще. 
Elastic SIEM, как и любой SIEM позволяет сделать правила, по которым будут создаваться алерты.
Посмотрим, как это работает.

1. Первый хант, котрый мы сделаем - whoami от system. Для начала отладим соответсвующий поисковый запрос: process.command_line:*whoami* AND user.name:"SYSTEM"


2. В приложении SIEM создадим правило

3. Заполнив все поля (можно и не все), сохраним правило. Его можно посмотреть

4. Проведем атаку, убедимся, что наше правило работает, соответствующие алерты появляются



Для проведенной атаки можно придумать еще множество других правил, предлагаю читателю это сделать самостоятельно

  • запуск nc как сервиса
  • изменение binpath у сервиса с помощь sc
  • создание .php файла httpd
  • использование certutil для загрузки файлов по http
  • создание файлов certutil-ом
  • запуск cmd из httpd
  • ... и многое другое...

Вместо заключения

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