Стандартом де-факто для самодельного MDR долгое время был sysmon и даже MITRE публикует детекты для него. Есть куча в прошлом SOC-ов, продвинувшихся в сторону MDR, как раз добавив события от sysmon.
Но, с появлением EPP от Elastic ситуация может поменяться! Сегодня рассмотрим его поподробнее, используемая инсталляция описана здесь.
Для экспериментов я подготовил несложную Windows10-машинку, навеянную одним из последних своих упражнений на HTB, со следующим сценарием:
- Первоначальный пробив - уязвимое Web-приложение
- Повышение - ошибка в конфигурации сервисов Windows (специально подстроенная, в Windows по умолчанию все ОК)
Чтобы было понятно что детектим, сначала приведу пошаговое описание атаки, затем - как выглядит расследование.
Глазами Красного
1. Посканировали, нашли Web, зашли, увидели это
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-ом
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
- ... и многое другое...
Вместо заключения
В заметке я более предметно коснулся особенностей работы Фиолетовой команды, которая для целей исследования угроз должна очень хорошо понимать техники и инструменты атакующих, т.е. быть квалификацией не ниже пентестеров, но, вместе с тем, прекрасно разбираться и с технологиями обнаружения, чтобы создавать эффективные корреляционные правила\детекторы\ханты.