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

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

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