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
  • ... и многое другое...

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

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