Расследование инцидента (Кибер Волга 2025)

Введение

Данная статья представляет собой райтап с отборочного этапа киберучений «Кибер Волга 2025», написанный в продолжение статьи про MDNS/LLMNR/NBT-NS Poisoning и последующий NTLM Relay, чтобы начинающим специалистам с учётом прошлой статьи с новым взглядом разобрать задания соревнований.

Приятного чтения!

Исходные данные

Легенда

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

Задание

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

Укажите название компьютерной атаки, которая произошла первой
Обращение к какому несуществующему в корпоративной сети домену привело к успешности первой компьютерной атаки?
Какой IP-адрес был у СВТ, с которого злоумышленник украл аутентификационную информацию?
Какой IP-адрес был у СВТ хакера?
NTLMv2-SSP-хэш какой учетной записи был скомпрометирован?
Какой узел скомпрометирован в результате атаки NTLM-Relay?
Какое количество директорий находится на скомпрометированном СВТ (вопрос 6) в папке пользователя admin\CYBER?
Укажите IP-адрес второго СВТ злоумышленника
Укажите содержимое украденного файла с СВТ из вопроса 6
При помощи какого протокола злоумышленник скомпрометировал узел file.cyber.local?
Какое имя учетной записи было использовано для проникновения на узел file.cyber.local?
Какое вспомогательное вредоносное программное обеспечение было загружено злоумышленником на узел file.cyber.local?
Какое количество людей изображено на изображении, украденном с узла file.cyber.local?
При помощи какого протокола злоумышленник получил доступ к контроллеру домена?
Каким ведомством разработаны документы, украденные с контроллера домена?

Совет

Очень важно на данном этапе понять схему внутренней инфраструктуры. Обратите внимание на все данные нам IP-адреса и домены, так как атаки, как правило, пытаются быть замаскированными. Если вы будете понимать суть сценария, вам будет легче их заметить.

Решение

Хоть решение я распределил по вопросам, всё равно это единый сценарий, поэтому, чтобы понять всю суть инцидента, лучше изучать с первого вопроса.

Подготовка

Открыв дамп трафика, сразу можно заметить кучу трафика, никак не связанного с нашей внутренней сетью. Чтобы упростить анализ, лучше сразу составить фильтр, который оставит нам только нужное. В данном случае лучше:

Исключить TCP и TLS протоколы, так как никаких полезных для нас данных из них мы извлечь не сможем.
Оставить трафик, связанный с внутренней (192.168.1.0/24) и внешней (10.0.0.0/8, так как мы знаем только то, что IP может начинаться с 10, а остальные октеты могут быть разными) сетями.

В итоге получается следующий фильтр:

!(_ws.col.protocol == "TCP") && !(_ws.col.protocol == "TLSv1.2") && ((ip.src == 192.168.1.0/24 && ip.dst == 192.168.1.0/24) || (ip.src == 192.168.1.0/24 && ip.dst == 10.0.0.0/8) || (ip.src == 10.0.0.0/8 && ip.dst == 192.168.1.0/24))

Он отфильтрует дамп так, что останутся пакеты, которые были только внутри скоупа. Тем не менее это не говорит о том, что лишнего трафика вообще не осталось, он лишь убрал большую часть.

Подсказка: в Wireshark фильтры можно сохранять как кнопки — очень полезный функционал!

Вопрос 1-4

Укажите название компьютерной атаки, которая произошла первой.
Обращение к какому несуществующему в корпоративной сети домену привело к успешности первой компьютерной атаки?
Какой IP-адрес был у СВТ, с которого злоумышленник украл аутентификационную информацию?
Какой IP-адрес был у СВТ хакера?

Теперь можно приступить к изучению. Постепенно спускаемся по дампу (важно, чтобы он был отсортирован по номеру пакета от меньшего к большему) и ищем «аномалии».

В результате находим следующие пакеты:

Это пакеты протоколов DNS, NBNS, MDNS и LLMNR. Насколько вы помните, именно эти пакеты участвуют в атаке MDNS/LLMNR/NBT-NS Poisoning. Но почему мы решили, что они выглядят подозрительно? Внимательно посмотрим на содержимое:

Хост с IP 192.168.1.101 (который предположительно является одним из двух неподписанных ARM на схеме из условия и вместе с этим жертвой) запрашивает ответ из DNS-записей контроллера домена по некоему cloud.cyber.local, который отсутствует как на схеме сети, так и в записях DNS контроллера домена, что мы можем понять по его ответу. Но в следующих пакетах при NBNS-рассылке неожиданно отзывается 192.168.1.105, что вполне может быть подменой от злоумышленника.

В итоге предположим, что:

Укажите название компьютерной атаки, которая произошла первой - NBT-NS-spoofing
Обращение к какому несуществующему в корпоративной сети домену привело к успешности первой компьютерной атаки? - cloud
Какой IP-адрес был у СВТ, с которого злоумышленник украл аутентификационную информацию? - 192.168.1.101
Какой IP-адрес был у СВТ хакера? - 192.168.1.105

Вопрос 5-9

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

Чтобы ещё быстрее найти дальнейший шаг злоумышленника, с помощью фильтра оставим трафик, связанный только с СВТ злоумышленника, куда ушли аутентификационные данные (192.168.1.105):

(!(_ws.col.protocol == "TCP") && !(_ws.col.protocol == "TLSv1.2") && ((ip.src == 192.168.1.0/24 && ip.dst == 192.168.1.0/24) || (ip.src == 192.168.1.0/24 && ip.dst == 10.0.0.0/8) || (ip.src == 10.0.0.0/8 && ip.dst == 192.168.1.0/24))) && ip.addr == 192.168.1.105

Траффика стало намного меньше, и сразу в глаза бросаются несколько первых с начала жёлтых блоков пакетов:

То есть хост последовательно начал соединяться со всеми СВТ в сети, что указывает на проведение сканирования, видимо, с целью проверки подписи SMB и составления списка пригодных для NTLM-Relay атаки хостов.

Подошли только два хоста, это 192.168.1.5 и 192.168.1.100, на которые впоследствии и пошла атака:

В итоге аутентифицироваться получилось только на хосте 192.168.1.100 под доменным пользователем CYBER\admin.

Неудачная аутентификация на 192.168.1.5 (для сравнения):

Далее идёт большой блок пакетов общения злоумышленника с 192.168.1.100 по SMB2, среди которых можно выделить пакеты с File: _output, ответ на которые мы можем без проблем просмотреть, так как он передаётся в открытом виде. Например, просмотрим первый попавшийся ответ:

Злоумышленник ожидаемо воспользовался smbexec для получения терминала Windows, давайте проследим за его действиями:

Проверил терминал, выведя содержимое папки System32:

Вывел содержимое папки пользователей (узнал, какие учётные записи есть на машине):

Начал исследовать папку доменного пользователя admin.CYBER (пригодится для ответа на вопрос 7):

На рабочем столе ничего найдено не было.

А вот в загрузках лежал файл consumers.txt, интересно было бы посмотреть на его содержимое:

Злоумышленнику также это было интересно, поэтому он решил сохранить этот файл себе, используя поднятый HTTP-сервер с возможностью принятия файлов, расположенный на его втором СВТ во внешней сети:

Мы, как специалисты, которые расследуют инцидент, можем воспользоваться этим и восстановить содержимое файла consumers.txt, изучив HTTP-запросы, связанные со вторым IP-адресом злоумышленника (10.0.1.50). Для этого чуть-чуть изменим текущий фильтр:

(!(_ws.col.protocol == "TCP") && !(_ws.col.protocol == "TLSv1.2") && ((ip.src == 192.168.1.0/24 && ip.dst == 192.168.1.0/24) || (ip.src == 192.168.1.0/24 && ip.dst == 10.0.0.0/8) || (ip.src == 10.0.0.0/8 && ip.dst == 192.168.1.0/24))) && ip.addr == 10.0.1.50

Видно, что за всю историю было отправлено 3 файла (3 POST запроса). Не будем рассматривать сразу все, чтобы не терять нить происходящего, просто, так как это была первая эксфильтрация (передача файлов с машины жертвы на свою), обратимся к первому же POST запросу и выведем байты раздела DATA:

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

5. NTLMv2-SSP-хэш какой учетной записи был скомпрометирован? - admin

6. Какой узел скомпрометирован в результате атаки NTLM-Relay? - 192.168.1.100

7. Какое количество директорий находится на скомпрометированном СВТ (вопрос 6) в папке пользователя admin\CYBER? - 11

8. Укажите IP-адрес второго СВТ злоумышленника - 10.0.1.50

9. Укажите содержимое украденного файла с СВТ из вопроса 6 - Michael_ScottDundermifflin1

Вопрос 10-13

Вернёмся к фильтру по первой СВТ злоумышленника:

(!(_ws.col.protocol == "TCP") && !(_ws.col.protocol == "TLSv1.2") && ((ip.src == 192.168.1.0/24 && ip.dst == 192.168.1.0/24) || (ip.src == 192.168.1.0/24 && ip.dst == 10.0.0.0/8) || (ip.src == 10.0.0.0/8 && ip.dst == 192.168.1.0/24))) && ip.addr == 192.168.1.105

Дальнейший трафик представляет собой кучу лишних DNS-запросов, но среди них главное не упустить два интересных пакета:

С хоста злоумышленника произошло подключение к 192.168.1.5 (он же fileserver.cyber.local), при этом в cookie мы отчётливо видим имя пользователя Michael_Scott, которое ранее было найдено в файле . Теперь, с учётом того что у злоумышленника появился полноценный доступ к рабочему столу файлового сервера, стоит проверить весь трафик, связанный с ним, соответственно модифицируем фильтр:

(!(_ws.col.protocol == "TCP") && !(_ws.col.protocol == "TLSv1.2") && ((ip.src == 192.168.1.0/24 && ip.dst == 192.168.1.0/24) || (ip.src == 192.168.1.0/24 && ip.dst == 10.0.0.0/8) || (ip.src == 10.0.0.0/8 && ip.dst == 192.168.1.0/24))) && ip.addr == 192.168.1.5

Смотрим, естественно, начиная с RDP:

Ниже снова видим взаимодействие по HTTP с хостом злоумышленника с очень подозрительным запросом файла, который именуется как некий Windows_update.zip:

Восстановим его и посмотрим, что внутри:

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

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

10. При помощи какого протокола злоумышленник скомпрометировал узел file.cyber.local? - RDP

11. Какое имя учетной записи было использовано для проникновения на узел file.cyber.local? - Michael_Scott

12. Какое вспомогательное вредоносное программное обеспечение было загружено злоумышленником на узел file.cyber.local? - Mimikatz

13. Какое количество людей изображено на изображении, украденном с узла file.cyber.local? - 16

Вопрос 14-15

Последним шагом злоумышленника стал захват контроллера домена. Судя по дальнейшему трафику, сделал он это через протокол WinRM с учётными данными из Mimikatz. Понять это можно по HTTP-запросам к /wsman:

Теперь можно сказать точно, что весь путь злоумышленника определён. Остаётся узнать, какие документы он украл? Сделать это можно, переключившись в фильтре на трафик контроллера домена, или же, при условии того, что злоумышленник так или иначе крадёт эти файлы на определённый хост, можно вернуться к нему и просто посмотреть последний POST-запрос.

Архив восстанавливаем, как и в случае с Mimikatz (у названий файлов внутри чуть поломана кодировка):

При открытии первого же документа сразу понятно, кто разрабатывал документы:

На этом расследование данного инцидента можно назвать законченным.