Разбор заданий CyberCamp 2023: PCAP Analysis, DC и MITRE ATT&CK

Привет, Хабр! CyberCamp — онлайн-кэмп по практической кибербезопасности — давно прошел, а вопросы (по заданиям) еще остались. Помимо командных киберучений, на платформе CyberCamp были представлены практические задания для зрителей по самым разным вопросам ИБ, начиная от поиска фишинговых писем, работы с дампами трафика и журналами аудита, и заканчивая MITRE ATT&CK и мини-Bug Bounty.

Мы получили обратную связь от зрителей и решили разобрать самые интересные и непростые, по их мнению, задачи. Поэтому, если вас до сих пор периодически мучает вопрос «Где же лежал ключ?!», — мы вас спасем.

Давайте разбираться!

Разбор задания: «Как мы дефейс расследовали (PCAP Analysis)»

Дано:

На главной странице портала с CMS Joomla появилась новая «красивая картинка». Администраторы говорят, что ничего не делали, и для доступа в админку используется стойкий пароль! К счастью, в момент атаки на периметре писался трафик.

Требуется:

Изучить копию трафика и найти флаг, который злоумышленник заботливо оставил на нашем портале.

Решение:

Найдем флаг через «Поиск» Wireshark

Где там мой варешарк? Давайте начинать!

В задании намекают на картинку с флагом, которую мы должны найти. Начнем с классического Export Objects, чтобы вытащить все передаваемые данные по различным протоколам:

0d5bb36de604dd96e3cf62d70af7af37.png

В HTTP передавалось множество картинок, но заветного флага на них не видно, зато можно найти коалу.

Поиск строки «флаг» результата тоже не дает:

d5260983f4e2236e18dc7a3a1276cf3f.png

Раз мы ищем картинку, попробуем поискать не слово «flag» и все возможные его вариации, а сигнатуры картинок, например, FF D8 в хексе или JFIF и EXIF в строках:

9ad01209af64018eff4c759fdebe9acf.png

Такой подход, действительно, дает свои плоды! Мы нашли в tcp-потоке картинку, сохраним ее и посмотрим, что же на ней есть. А на ней уже не коала, а самый настоящий флаг в желто-розовых тонах:

66473f1a877ac1af6f9053dc01fcc639.png

Кажется слишком просто? Давайте попробуем найти еще пути решения!

Найдем флаг с помощью статистики и анализа дампа

В Wireshark есть чудесный раздел со статистикой:

581347db0ef013c734bceb66ae72e82a.png

По нему можно посмотреть статистику по эндпоинтам, портам, протоколам и много чему еще:

3d8574577f6253f5fa447d28fc03b07c.png

В нашем случае мы видим три самых активных IP-адреса: 11.0.30.138, 11.1.173.2 (наша Джумла) и 200.200.200.200 (какой красивый…).

Если мы посмотрим статистику IPv4 по портам, то увидим следующее:

0ed669d1990ac12bd4a4350c19626c51.png

Видно, что хост 11.0.30.138 общается с «больших портов», скорее всего, это клиент, который общается с нашим веб-сервером.

А вот на 200.200.200.200 мы видим два интересных порта: 8101 и 4545.

А на 11.1.173.2 порт 9090 (посмотрим его чуть позже).

Сначала отфильтруем порт 8101 и заглянем в сессию:

409adfa50dcaac47af3edfa27cc0cdd1.pngb44dcb610b7502696c1c79aa68f915d9.pngebf71f5c47fc617bb48a0507f968e67a.png

Здесь мы видим очень много всего:

●       и разведку с использованием утилит netstat, ps, crontab и других;

●       и успешное повышение привилегий через мисконфигурацию в Sudoers (после эксплуатации уязвимости в CMS злоумышленник получил привилегии УЗ daemon);

●       и скачивание вредоносного elf-файла, общение с которым, вероятно, происходит далее на порту 4545.

Также отфильтруем tcp-порт 9090 и посмотрим сессию:

2685035b478d24e80b0c594fd797a336.png82a97a38342cc6b390289a29f107963e.png

Это и есть наша сессия с флагом. Для того чтобы его сохранить, необходимо выбрать формат RAW и сохранить как картинку.

Разбор задания «Наш DC в беде (смогем и без секьюрити)»

Дано:

Команда синих обнаружила, что контроллер домена CyberCamp скомпрометирован. Злоумышленник замел за собой следы и удалил основные журналы событий. Но, помимо журналов Security и PowerShell, при реагировании на инцидент удалось извлечь несколько журналов, которые помогут найти зацепки в расследовании.

Нам даны журналы:

●       System,

●       Directory Service,

●       Microsoft-Windows-TaskScheduler Operational,

●       Microsoft-Windows-TerminalServices-LocalSessionManager Operational,

●       Microsoft-Windows-TerminalServices-RemoteConnectionManager Operational,

●       Microsoft-Windows-WMI-Activity Operational.

Требуется:

Ответить на следующие вопросы:

●       Какой IP-адрес хоста, с которого атакующий проводил разведку и начало атаки?

●       С помощью какого инструмента злоумышленник осуществил горизонтальное перемещение на DC?

●       Какое название задачи планировщика, созданной злоумышленником?

●       Какой инструмент Windows запустила задача злоумышленника?

●       Вход какого пользователя на DC запустил задачу злоумышленника?

Решение:

Ручной анализ событий

Начнем с системного журнала и поищем в нем следы установки сервисов — событие 7045. В данном событии можно найти и следы запуска PowerShell как сервиса, и следы горизонтального перемещения на хост. Посмотрим, что нам даст данное событие…

А дает оно нам сразу же ответ на второй вопрос:

5773369a5a191bf90d7be1fa4d0a8031.png

Мы видим, что в событии 7045 журнала System устанавливается служба PSEXESVC, что говорит о том, что на данный хост удаленно подключались с помощью инструмента PsExec.exe.

Далее обратимся к журналу Directory Service. Данный журнал настраивается через реестр на контроллере домена и позволяет выявлять разведку в домене по протоколу LDAP. Мы будем искать аномалии в событии 1644, в котором содержится адрес клиента и фильтр LDAP-запроса.

В данном журнале 3700 событий, и будет сложно просмотреть каждое из них. Для удобства можно отфильтровать журнал событий по пользователям и не просматривать повторяющиеся легитимные запросы:

ffde6ba412a671d6bbf93c2efb2efc8d.png

Так можно отбросить повторяющиеся события с RID 1156 c хоста 192.168.1.254 и другие легитимные события. При просмотре событий 1644 по пользователю можно найти пользователя с RID 1206 и увидеть одно «маленькое» событие:

22acc9b85855f3c906b05b7feeee83c5.png

В данном событии мы видим адрес клиента и LDAP запрос:
(& sAMAccountType=805306368)(userAccountControl&4194304).

Таким запросом злоумышленник ищет всех пользователей в домене с установленным атрибутом DONT_REQ_PREAUTH для проведения атаки AS-REP Roasting.

Нас можно поздравить — мы нашли ответ на первый вопрос! Адрес хоста, с которого злоумышленник проводил разведку и начало атаки, — это 192.168.1.51.

Третий на очереди — журнал Microsoft-Windows-TaskScheduler Operational, и мы попробуем найти в нем следы создания и запуска задач планировщика.

Событие создания новой задачи или ее регистрации можно найти в событии 106 журнала TaskSheduler. Нам повезло, и в данном журнале есть только одно такое событие:

7ab31bab4fda89cc8cb37fbfcb27bf9c.png

Посмотрим, запускалась ли данная задача, и если да, то какой процесс она запустила. В этом нам поможет событие 200 — «Действие запущено при старте задачи». И снова удача: мы видим, что запускалось достаточно много задач, но недавно созданная задача UpdatePowerShell запустилась и вызвала powershell.exe, что очень настораживает:

1859d4e3ff46d075213d75991b943346.png

Также обратим внимание на время запуска задачи — 11:50:26 (нам это пригодится далее, да и в принципе всегда полезно фиксировать время для построения таймлайна).

Благодаря данному журналу мы нашли ответы на вопросы 3 и 4:

●       Какое название задачи планировщика, созданной злоумышленником? — UpdatePowerShell

●       Какой инструмент Windows запустила задача злоумышленника? — powershell.exe

Нам осталось ответить на последний вопрос: вход какого пользователя на DC запустил задачу злоумышленника? Данный вопрос сам наталкивает на нужные журналы, и мы заглянем в журнал LocalSessionManager Operational. Исходя из вопроса, самым интересным для нас событием будет событие 21 — «Успешный вход в систему».

Таких событий в журнале оказалось немного, и мы сразу находим нужное, соотнеся его по времени с запуском задачи планировщика:

e38a279ab731a3e1b6552e0b3f72fb52.png

Мы также можем подтвердить найденный нами вход в событии 1149 журнала RemoteConnectionManager Operational. Видимо, злоумышленник создал задачу планировщика с параметром /sc onlogon, поэтому она запустилась при входе пользователя RND\camp_user по RDP.

Мы нашли ответы на все вопросы, и, исходя из последовательности событий, можно сделать вывод, что злоумышленник начал свою атаку с разведки, затем с использованием техники AS–REP Roasting получил учетную запись в домене, с которой затем переместился на контроллер домена с использованием PsExec.exe и создал задачу планировщика для закрепления.

Используем автоматизацию

Из любопытства посмотрим, поможет ли в решении данного кейса автоматизация. Для этого воспользуемся инструментами Hayabusa (он же Сапсан) от команды Yamato Security и Timeline Explorer от Eric Zimmerman.

В составе Hayabusa более 2500 тысяч правил, которые включают в себя как Sigma Rules, так и собственные правила Hayabusa. Результат получился следующий:

edf900ad9a5087a82ba0b53ebcaf62fa.png

Как мы видим, зафиксированы и создание задачи планировщика, и запуск задач, и входы по RDP, и горизонтальное перемещение через PsExec, и очистка журналов. Если вывод утилиты просмотреть в Timeline Explorer, то мы увидим удобные и понятные алерты:

a002c862185890f9b38c6f641a85ab91.png

Отметим, что с журналом Directory Services Сапсану не удалось справиться, но он в разы уменьшил бы скорость расследования данного инцидента.

Разбор заданий: «Магия MITRE ATT&CK» и «Это база. Работа с MITRE ATT&CK»

Большинство вопросов и мини-кейсов были направлены на отработку базовых навыков работы с интерфейсом матрицы, инструментами поиска и панелью навигации веб-сайта ATT&CK с разделами Groups, Software, Data Sources и являются примерами простых экзаменационных заданий для получения сертификаций MITRE ATT&CK DEFENDER™ (MAD). Мы рассмотрим несколько заданий, для решения которых необходимо было выделить правильные техники и/или воспользоваться возможностями ATT&CK Navigator. При понимании алгоритма остальные задания решаются аналогично.

ATT&CK Navigator — веб-приложение с открытым исходным кодом, предоставляющее базовую навигацию и расширяющее возможности работы с проектом путем создания отдельных слоев и их наложения друг на друга, составления heat map карт и многого другого. ATT&CK Navigator доступен по ссылке, работа с ключевым функционалом хорошо описана на сайте MITRE ATT&CK вот здесь.

Кейс 1

Дано:

Ты расследуешь инцидент, который произошел в компании. Злоумышленник купил на черном рынке слитые пароли доступа к инфраструктуре, использовал валидные аккаунты, удаленно подключился к серверу по протоколу RDP, на котором опубликована 1С для удаленного доступа бухгалтерии.

Требуется:

Необходимо определить, какие техники использовал злоумышленник.

Решение:

Методически разберем данный кейс с использованием алгоритма, который предлагает нам Best Practices for MITRE ATT&CK® Mapping от CISA. Для разложения атаки на составляющие необходимо пройти следующие шаги:

80371079b4b93eed68c87512d2db03ee.png

Первые два шага мы пропустим, так как описание атаки уже есть в нашем кейсе, мы имеем базовые представления о матрице, связях основных объектов (TTPs) между собой и хоть раз открывали сайт проекта. Для определения конечного набора техник необходимо сначала выполнить шаги 3 (Research the behavior) и 4 (Translate the behavior into a tactic), чтобы лучше понять цели злоумышленника и сузить область поиска из более чем 200 различных техник:

566a93f4af9890b97c2e881c6322cf82.png

Атака, разобранная на три основных блока с выделением глаголов, выглядит так:

●       Pre-compromise: злоумышленник купил на черном рынке слитые пароли доступа к инфраструктуре.

●       Initial-compromise: использовал валидные аккаунты, удаленно подключился к серверу по протоколу RDP, на котором опубликована 1С для удаленного доступа бухгалтерии.

●       Post-compromise: в рассматриваемом кейсе этот этап упущен.

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

При сопоставлении глаголов и структуры нашей атаки с описанием тактик у нас должны получиться следующие тактики: Reconnaissance (находится в PRE Matrix) и Initial Access:

0ec395e1450d03f2e2d633f9ed3917a9.png

Для перехода на шаг 5 (Figure out what technique applies to the behavior) и определения техник можно воспользоваться одним или сразу несколькими способами:

3662879585b852e2a6cdcac88f63d7c6.png

На выделенных тактических шагах техник не так много, и их можно просмотреть глазами, но проще всего воспользоваться поиском по матрице или искать ключевые слова remote, valid, RDP, dark web с последующей проверкой найденных техник с их описанием:

a2586a271c6e2dc72f4d1820e33dc49a.png

После всех упражнений у нас должно получится:

Злоумышленник купил на черном рынке (Reconnaissance: Gather Victim Identity Information: Credentials, T1589.001) слитые пароли доступа к инфраструктуре, использовал валидные аккаунты (Initial Access: Valid Accounts, T1078) и удаленно подключился (Initial Access: External Remote Services, T1133) к серверу по протоколу RDP, на котором опубликована 1С для удаленного доступа бухгалтерии.

Кейс 2

Дано:

Формируя свою модель угроз, команда SOC решила сделать фокус на противодействии группировкам APT33, BlackOasis, Axiom и Windshift. Ниже дана тепловая карта с текущими возможностями SOC по обнаружению техник.

Требуется:

Определить, обнаружению какой дополнительной техники стоит уделить внимание с учетом тепловой карты возможностей SOC:

a73716d116077a35197d8d217e714274.png

Решение:

Данная задача — пример построения ландшафта угроз или Threat Modeling: сбор информации о группировках, потенциально способных атаковать компанию, с учетом типа компании, географии и других факторов. Упрощенно реализуется путем разработки heat map карты с наложением слоев, используемых различными группировками техник и последующим определением разрыва по возможностям их смягчения или обнаружения. Сами группировки уже даны нам как вводные, задача — составить heat map и найти слепые зоны.

Сначала создадим новый слой в ATT&CK Navigator (Create New Layer — Enterprise). С помощью инструмента «research&multiselect» (1) найдем и выберем первую группировку (2), покрасим выделение (3) и поставим скоринг »1» для нашего первого слоя:

d3f4b849f42f53bab77c6010f1e49e98.png

Для остальных APT (BlackOasis, Axiom и Windshift) последовательно повторяем шаги, создавая новый слой и увеличивая скоринг на единичку.

Следующий этап — наложить наши слои. Для этого используем инструмент «Create Layer from Other Layers» (1), после чего вводим формулу сложения для наших слоев: a+b+c+d (2):

19ad0e1ff475e56bb9e78fb4cb0b7f7a.png

На выходе получаем цветную диаграмму наложения:

9e0d4e9bd5481112df07e086f911c888.png

Внимательно изучив исходную карту покрытия SOC и легенду, мы видим, что ряд техник, например, Exploit Public-Facing Application и OS Credential Dumping, используются группировками, однако в нашем SOC имеют низкую уверенность в обнаружении. С учетом того, что обнаружение действий злоумышленника наиболее эффективно на ранних этапах атаки, правильным ответом является техника Exploit Public-Facing Application (T1190), выполняемая на шаге Initial Access.

Кейс 3

Дано:

Твоя компания решила сфокусироваться на обнаружении и блокировании ТОП-7 техник злоумышленников (отмечены синим):

bccdfb37fd1a4be49850fe118b7760e6.png

Требуется:

Определить источник данных (Data Source), который обеспечивает наибольший охват.

Решение:

Решение этой задачи сводится к работе с разделом Detection, доступным в описании каждой из техник. Последовательно перенося (в XLS или просто скриншотами) источники данных, необходимые для обнаружения покрашенных в задании техник, получаем вот такую картину:

d4e4eaace228fc5bd3c28a70518ce6d9.png

Чаще всего упоминается источник Application log, он и является верным ответом.

© Habrahabr.ru