Привет, Хабр! CyberCamp — онлайн-кэмп по практической кибербезопасности — давно прошел, а вопросы (по заданиям) еще остались. Помимо командных киберучений, на платформе CyberCamp были представлены практические задания для зрителей по самым разным вопросам ИБ, начиная от поиска фишинговых писем, работы с дампами трафика и журналами аудита, и заканчивая MITRE ATT&CK и мини-Bug Bounty.
Мы получили обратную связь от зрителей и решили разобрать самые интересные и непростые, по их мнению, задачи. Поэтому, если вас до сих пор периодически мучает вопрос «Где же лежал ключ?!», — мы вас спасем.
Давайте разбираться!
Разбор задания: «Что расскажет дамп трафика»
Дано:
На главной странице портала с CMS Joomla появилась новая «красивая картинка». Администраторы говорят, что ничего не делали, и для доступа в админку используется стойкий пароль! К счастью, в момент атаки на периметре писался трафик.
Требуется:
Тебе нужно расследовать инцидент и понять, как была проведена атака. Изучи копию трафика и найди флаг, который злоумышленник заботливо оставил на портале.
Решение:
Найдем флаг через «Поиск» Wireshark
Где там мой варешарк? Давайте начинать!
В задании намекают на картинку с флагом, которую мы должны найти. Начнем с классического Export Objects, чтобы вытащить все передаваемые данные по различным протоколам:
В HTTP передавалось множество картинок, но заветного флага на них не видно, зато можно найти коалу.
Поиск строки «флаг» результата тоже не дает:
Раз мы ищем картинку, попробуем поискать не слово «flag» и все возможные его вариации, а сигнатуры картинок, например, FF D8 в хексе или JFIF и EXIF в строках:
Такой подход, действительно, дает свои плоды! Мы нашли в tcp-потоке картинку, сохраним ее и посмотрим, что же на ней есть. А на ней уже не коала, а самый настоящий флаг в желто-розовых тонах:
Кажется слишком просто? Давайте попробуем найти еще пути решения!
Найдем флаг с помощью статистики и анализа дампа
В Wireshark есть чудесный раздел со статистикой:
По нему можно посмотреть статистику по эндпоинтам, портам, протоколам и много чему еще:
В нашем случае мы видим три самых активных IP-адреса: 11.0.30.138, 11.1.173.2 (наша Джумла) и 200.200.200.200 (какой красивый…).
Если мы посмотрим статистику IPv4 по портам, то увидим следующее:
Видно, что хост 11.0.30.138 общается с «больших портов», скорее всего, это клиент, который общается с нашим веб-сервером.
А вот на 200.200.200.200 мы видим два интересных порта: 8101 и 4545.
А на 11.1.173.2 порт 9090 (посмотрим его чуть позже).
Сначала отфильтруем порт 8101 и заглянем в сессию:
Здесь мы видим очень много всего:
и разведку с использованием утилит netstat, ps, crontab и других;
и успешное повышение привилегий через мисконфигурацию в Sudoers (после эксплуатации уязвимости в CMS злоумышленник получил привилегии УЗ daemon);
и скачивание вредоносного elf-файла, общение с которым, вероятно, происходит далее на порту 4545.
Также отфильтруем tcp-порт 9090 и посмотрим сессию:
Это и есть наша сессия с флагом. Для того чтобы его сохранить, необходимо выбрать формат RAW и сохранить как картинку.
Разбор задания «Работаем с логами»
Дано:
Контроллер домена (DC) промышленной компании был атакован. Злоумышленник удалил основные журналы, и мы не смогли их восстановить. К счастью, на DC записывались не только логи 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 как сервиса, и следы горизонтального перемещения на хост. Посмотрим, что нам даст данное событие…
А дает оно нам сразу же ответ на второй вопрос:
Мы видим, что в событии 7045 журнала System устанавливается служба PSEXESVC, что говорит о том, что на данный хост удаленно подключались с помощью инструмента PsExec.exe.
Далее обратимся к журналу Directory Service. Данный журнал настраивается через реестр на контроллере домена и позволяет выявлять разведку в домене по протоколу LDAP. Мы будем искать аномалии в событии 1644, в котором содержится адрес клиента и фильтр LDAP-запроса.
В данном журнале 3700 событий, и будет сложно просмотреть каждое из них. Для удобства можно отфильтровать журнал событий по пользователям и не просматривать повторяющиеся легитимные запросы:
Так можно отбросить повторяющиеся события с RID 1156 c хоста 192.168.1.254 и другие легитимные события. При просмотре событий 1644 по пользователю можно найти пользователя с RID 1206 и увидеть одно «маленькое» событие:
В данном событии мы видим адрес клиента и LDAP запрос:
( & sAMAccountType=805306368)(userAccountControl&4194304).
Таким запросом злоумышленник ищет всех пользователей в домене с установленным атрибутом DONT_REQ_PREAUTH для проведения атаки AS-REP Roasting.
Нас можно поздравить — мы нашли ответ на первый вопрос! Адрес хоста, с которого злоумышленник проводил разведку и начало атаки, — это 192.168.1.51.
Третий на очереди — журнал Microsoft-Windows-TaskScheduler Operational, и мы попробуем найти в нем следы создания и запуска задач планировщика.
Событие создания новой задачи или ее регистрации можно найти в событии 106 журнала TaskSheduler. Нам повезло, и в данном журнале есть только одно такое событие:
Посмотрим, запускалась ли данная задача, и если да, то какой процесс она запустила. В этом нам поможет событие 200 — «Действие запущено при старте задачи». И снова удача: мы видим, что запускалось достаточно много задач, но недавно созданная задача UpdatePowerShell запустилась и вызвала powershell.exe, что очень настораживает:
Также обратим внимание на время запуска задачи — 11:50:26 (нам это пригодится далее, да и в принципе всегда полезно фиксировать время для построения таймлайна).
Благодаря данному журналу мы нашли ответы на вопросы 3 и 4:
Какое название задачи планировщика, созданной злоумышленником? — UpdatePowerShell
Какой инструмент Windows запустила задача злоумышленника? — powershell.exe
Нам осталось ответить на последний вопрос: вход какого пользователя на DC запустил задачу злоумышленника? Данный вопрос сам наталкивает на нужные журналы, и мы заглянем в журнал LocalSessionManager Operational. Исходя из вопроса, самым интересным для нас событием будет событие 21 — «Успешный вход в систему».
Таких событий в журнале оказалось немного, и мы сразу находим нужное, соотнеся его по времени с запуском задачи планировщика:
Мы также можем подтвердить найденный нами вход в событии 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. Результат получился следующий:
Как мы видим, зафиксированы и создание задачи планировщика, и запуск задач, и входы по RDP, и горизонтальное перемещение через PsExec, и очистка журналов. Если вывод утилиты просмотреть в Timeline Explorer, то мы увидим удобные и понятные алерты:
Отметим, что с журналом 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. Для разложения атаки на составляющие необходимо пройти следующие шаги:
Первые два шага мы пропустим, так как описание атаки уже есть в нашем кейсе, мы имеем базовые представления о матрице, связях основных объектов (TTPs) между собой и хоть раз открывали сайт проекта. Для определения конечного набора техник необходимо сначала выполнить шаги 3 (Research the behavior) и 4 (Translate the behavior into a tactic), чтобы лучше понять цели злоумышленника и сузить область поиска из более чем 200 различных техник:
Атака, разобранная на три основных блока с выделением глаголов, выглядит так:
Pre-compromise: злоумышленник купил на черном рынке слитые пароли доступа к инфраструктуре.
Initial-compromise: использовал валидные аккаунты, удаленно подключился к серверу по протоколу RDP, на котором опубликована 1С для удаленного доступа бухгалтерии.
Post-compromise: в рассматриваемом кейсе этот этап упущен.
Для такой простой атаки данные шаги могут показаться избыточными, но для сложного кейса такое упражнение значительно упрощает выделение тактик и техник.
При сопоставлении глаголов и структуры нашей атаки с описанием тактик у нас должны получиться следующие тактики: Reconnaissance (находится в PRE Matrix) и Initial Access:
Для перехода на шаг 5 (Figure out what technique applies to the behavior) и определения техник можно воспользоваться одним или сразу несколькими способами:
На выделенных тактических шагах техник не так много, и их можно просмотреть глазами, но проще всего воспользоваться поиском по матрице или искать ключевые слова remote, valid, RDP, dark web с последующей проверкой найденных техник с их описанием:
После всех упражнений у нас должно получится:
Злоумышленник купил на черном рынке (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:
Решение:
Данная задача — пример построения ландшафта угроз или Threat Modeling: сбор информации о группировках, потенциально способных атаковать компанию, с учетом типа компании, географии и других факторов. Упрощенно реализуется путем разработки heat map карты с наложением слоев, используемых различными группировками техник и последующим определением разрыва по возможностям их смягчения или обнаружения. Сами группировки уже даны нам как вводные, задача — составить heat map и найти слепые зоны.
Сначала создадим новый слой в ATT&CK Navigator (Create New Layer – Enterprise). С помощью инструмента «research&multiselect» (1) найдем и выберем первую группировку (2), покрасим выделение (3) и поставим скоринг «1» для нашего первого слоя:
Для остальных APT (BlackOasis, Axiom и Windshift) последовательно повторяем шаги, создавая новый слой и увеличивая скоринг на единичку.
Следующий этап — наложить наши слои. Для этого используем инструмент «Create Layer from Other Layers» (1), после чего вводим формулу сложения для наших слоев: a+b+c+d (2):
На выходе получаем цветную диаграмму наложения:
Внимательно изучив исходную карту покрытия SOC и легенду, мы видим, что ряд техник, например, Exploit Public-Facing Application и OS Credential Dumping, используются группировками, однако в нашем SOC имеют низкую уверенность в обнаружении. С учетом того, что обнаружение действий злоумышленника наиболее эффективно на ранних этапах атаки, правильным ответом является техника Exploit Public-Facing Application (T1190), выполняемая на шаге Initial Access.
Кейс 3
Дано:
Твоя компания решила сфокусироваться на обнаружении и блокировании ТОП-7 техник злоумышленников (отмечены синим):
Требуется:
Определить источник данных (Data Source), который обеспечивает наибольший охват.
Решение:
Решение этой задачи сводится к работе с разделом Detection, доступным в описании каждой из техник. Последовательно перенося (в XLS или просто скриншотами) источники данных, необходимые для обнаружения покрашенных в задании техник, получаем вот такую картину:
Чаще всего упоминается источник Application log, он и является верным ответом.