В данном цикле статей мы пытаемся разобрать лаборатории по форензике так, как это делается в реальных «боевых» условиях - без подсказок и наводящих вопросов, только инцидент, триаж и логические цепочки. И в итоге оформляем расследование в нечто подобное настоящему DFIR-отчёту.

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

Введение

А теперь немного подробнее, что вас ждёт далее.

Данная статья в своей сути является прохождением лаборатории Lockdown Lab на платформе CyberDefenders. В стандартном прохождении необходимо отвечать на поставленные наводящие вопросы, тем самым продвигаясь в расследовании.

Мы же в данной статье попробуем провести полноценный анализ «с нуля», не полагаясь на вопросы, чтобы показать принцип расследования атак в условиях, приближенных к реальным.

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

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

Итак, начинаем.

Описание инцидента

TechNova Systems’ SOC has detected suspicious outbound traffic from a public-facing IIS server in its cloud platform-activity suggestive of a web-shell drop and covert connections to an unknown host.
As the forensic examiner, you have three critical artefacts in hand: a PCAP capturing the initial traffic, a full memory image of the server, and a malware sample recovered from disk. Reconstruct the intrusion and all of the attacker’s activities so TechNova can contain the breach and strengthen its defenses.

Центр мониторинга безопасности (SOC) компании TechNova Systems зафиксировал подозрительный исходящий трафик с внешнего IIS-сервера в своей облачной платформе. Данная активность указывает на возможное размещение веб-оболочки (web-shell) и установление скрытых соединений с неизвестным хостом.
Вам, как криминалисту, предоставлены три критически важных артефакта: дамп сетевого трафика (PCAP), фиксирующий первоначальную активность; полный образ памяти (дамп) сервера; и образ вредоносного ПО, извлеченный с диска. Восстановите полную картину вторжения и все действия злоумышленника, чтобы TechNova могла устранить последствия инцидента и усилить защиту.

Часть 1 Анализ дампа сетевого трафика

В качестве инструмента анализа используется Wireshark. Здесь ожидается обнаружение фаз Разведки, Первоначального доступа, Выполнения.

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

В первых 70-и пакетах зафиксирована стандартная легитимная сетевая активность. Из неё подтвердим ip-адрес сервера заказчика: 10.0.2.15.

По информации от SOC, был обнаружен трафик, указывающий на активность веб-шелла. При проверке http-трафика найдено нестандартное обращение к серверу и установление соединения с хостом 10.0.2.4 на порт 4443, что является подозрительной активностью, поэтому далее была проведена дополнительная проверка взаимодействия сервера с хостом 10.0.2.4.

С 74-ого пакета с сервером начал взаимодействовать хост 10.0.2.4. Данный хост с порта 55475 пытался установить tcp-соединение с различными портами сервера (пакеты с флагами SYN), однако сервер почти всегда обрывал соединения (пакеты с флагами RST, ACK).

Данная активность является типичным примером сканирования портов и поиском, какие из них открыты, какие закрыты. Если сервер на SYN отвечает RST, ACK, то это свидетельствует либо о том, что порт закрыт, либо о сбросе соединения файерволом. Факт сканирования портов является подозрительной активностью, поэтому предполагаем хост 10.0.2.4 злоумышленником.

Следующие 2000 пакетов вплоть до 2077-ого пакета являются отображением сканирования портов сервера.

Начиная с 2108 пакета происходили попытки обращения к порту 80 (http). Злоумышленник отправлял различные запросы на 80 порт, чтобы изучить ответы сервера и больше узнать о сервисах, которые работают на этом порту.

Чтобы узнать, какое ПО используется для сканирования, изучили запросы и ответы от сервера по протоколу http. Например, в данном запросе (пакет 2131) в качестве user-агента использовался Nmap Scripting Engine. Следовательно, инструмент разведки – сетевой сканер nmap.

В итоге сканирования порта 80 (пакеты 2108-2349) злоумышленник получил обширную информацию о сервисе. Например, он узнал, какой используется веб-сервер, его версию, стек разработки (Microsoft-IIS/10.0, ASP.NET), что в дальнейшем можно было использовать для поиска актуальных CVE.

Далее, nmap обнаружил и просканировал (пакеты 2352-2584) открытый 445 порт, который используется протоколом SMB для доступа к сетевым ресурсам, например, к папкам, файлам. С пакета 2612 злоумышленник начал работать именно с эти портом.

После установления tcp-соединения (SYN, SYN-ACK, ACK) с 445 портом произошло согласование протоколов, в своей сути выбор версии SMB: клиент отправляет Negotiate Protocol Request, сервер отвечает Negotiate Protocol Response. Здесь злоумышленник мог обратить внимание на версию SMB.

Пакет 2398 является примером ответа Negotiate Protocol Response, в котором сообщается об использовании SMB версии 3.1.1, актуальной для современных систем. Интересно подметить, что злоумышленник пытался узнать о возможности использования SMB 1, устаревшего небезопасного протокола, но сервер отрицательно ответил на такие запросы.

Далее следует блок трафика (пакеты 2440-2584), в рамках которого отправлялись запросы NetBIOS Session Service для получения дополнительной информации о конфигурации SMB. Однако, сервер везде отбрасывал соединение (RST, ACK).

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

Первоначальный доступ

С пакета 2612 злоумышленник предпринял попытку пройти аутентификацию по ntlmv2. Напомним теоретический процесс аутентификации по ntlmv2:

В нашем трафике присутствуют следующие пакеты.

1) Клиент отправил запрос Session Setup Request, NTLMSSP_NEGOTIATE.

2) Сервер ответил Session Setup Response, Error: STATUS_MORE_PROCESSING_REQUIRED, NTLMSSP_CHALLENGE. В своей сути отправил challenge – строку из 8 случайных байт, которую клиент использует при формировании ответа.

3) Не будем углубляться в процесс формирования ответа на стороне клиента. Ограничимся тем, что клиент в ответе указал user, под которым хочет пройти аутентификацию: Session Setup Request, NTLMSSP_AUTH, User: WORKGROUP\root. Сервер проверил данные и подтвердил создание сессии.

Важное замечание. Злоумышленник успешно прошёл аутентификацию для пользователя root, не зная секрет и прочие данные для формирования ответа в шаге 3, следующим образом. В пакете 2626 присутствует строка: [Expert Info (Chat/Security): NTLMv2 authenticated using <Global NT Password> (31d6cfe0d16ae931b73c59d7e0c089c0)].
Где NT-Хэш 31d6cfe0d16ae931b73c59d7e0c089c0 – это NT-хэш пустого пароля. Из чего следует, что пароль у root – пустой, что является мисконфигурацией и уязвимостью. Предполагая это, злоумышленник смог составить корректный ответ для сервера и пройти аутентификацию.

Пройдя аутентификацию, злоумышленник получил доступ до сетевой директории: \\10.0.2.15\IPC$. В пакете 2630, Tree Connect Response, видно, что у злоумышленника есть практически все права для взаимодействия с директорией, что также является небезопасной конфигурацией.

Отметим, что IPC$ (Inter-Process Communication) - это скрытая системная папка, которая используется для удалённого вызова процедур (RPC-команды), что фактически даёт удалённое управление.

Пакеты 2629–2642 отражают получение информации о других сетевых ресурсах.

Так, в пакетах 2629-2630 создаётся named pipe для службы srvsvc, которая отвечает за управление общими сетевыми ресурсами.

Пакеты 2631-2632 переданы по протоколу DCERPC - Distributed Computing Environment Remote Procedure Call – который используется для вызова удалённых процедур. Конкретно в 2631 пакете указано, что должна быть использована процедура srvsvc 3.0, передача данных NDR (Network Data Representation).

Итог, в пакете 2636 запрашивается информация о других сетевых ресурсах (NetShareEnumAll request). В ответе присутствует следующее: Users, IPC$, Documents, C$, ADMINS$. После получения информации сессия завершается.

С 2660 пакета начинается новая сессия. Злоумышленник вновь успешно прошёл аутентификацию и получил доступ до IPC$.

В пакете 2674 отправляется ioctl Request (запрос, позволяющий пользовательскому приложению взаимодействовать с драйвером устройства в Windows, обычно используется для выполнения операций, не связанных с чтением/записью) FSCTL_DFS_GET_REFERRALS, Path: \10.0.2.15\Documents. Этим запросом предпринимается попытка запросить у распределённой файловой системы (DFS) информацию о сетевой директории \10.0.2.15\Documents. Интересно, что сервер ответил ошибкой STATUS_FS_DRIVER_REQUIRED, возможно, это связано с некорректной настройкой DFS на сервере.

Далее, злоумышленник напрямую подключился к \10.0.2.15\Documents. С помощью Create Request, File: <share> открыл директорию share, запросил перечисление находящихся в ней файлов Find Request, File: <share>, SMB2_FIND_ID_BOTH_DIRECTORY_INFO, Pattern: *. В результате злоумышленник узнал о наличии двух файлов: information.txt и web.config.

В пакете 2717 произошёл запрос к файлу: Create Request, File: information.txt, а а пакете 2723 злоумышленник прочитал файл. Содержание файла:

This server setup is under development. We are trying to link the web server with SMB.
Please do not tamper with our work.
Best regards
Dev Team

Финальный этап фазы Первоначального доступа начался с пакета 2783, отражающего создание файла shell.aspx. Из названия файла предположили, что в него будет загружен код веб-шелла.

С 2785 по 3504 пакет произошла запись обфусцированного кода в созданный файл. Помимо обфусцированного блока присутствуют несколько строк команд на C#.

Кратко проанализировали необфусцированный код на C#.

MEM_COMMIT – константа, определяющая размер выделенной памяти.

PAGE_EXECUTE_READWRITE – указатель, позволяющий в дальнейшем выполнять код, чтение, запись.

Далее импортируются функции из DLL kernel32, а именно функция VirtualAlloc, возвращающая указатель на выделенную память и функция CreateThread, создающая новый поток.

Затем идёт обработчик и массив, закодированный в hex-формат. Данный массив копируется в выделенную память.

То есть код на C# является инжектом в оперативную память и последующим выполнением вредоносного кода, чтобы скрыть его от антивирусных СЗИ.

Проверка shell.aspx на VirusTotal показала угрозу объекта и классифицировала его как веб-шелл, сгенерированный через утилиту msfvenom.

Также извлекли и декодировали из hex массив байтов. В результате получили объект, проверка которого через VirusTotal показала высокую угрозу и классифицировала как Meterpreter – бэкдор, дающий злоумышленнику контроль над хостом. Чаще всего Meterpreter внедряется непосредственно в память, что и демонстрируется в данном инциденте.

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

На этом заканчивается фаза Первоначального доступа, и злоумышленник переходит к фазе Выполнения.

Выполнение

После записи кода в файл shell.aspx, который находится в Documents, злоумышленник обратился GET-запросом к Documents/shell.aspx (3573 пакет). Запустился shell.aspx и произошло соединение с 4443 портом на хосте злоумышленника. Так злоумышленник получил шелл и возможность удалённого выполнения команд. Оставшаяся часть трафика зашифрована, и глубокий анализ не представляется возможным.

Краткий итог по анализу дампа сетевого трафика. Используя небезопасную конфигурацию сервера, злоумышленник смог получить соединение с сетевыми ресурсами (/Documents) и загрузить на них шелл shell.aspx. Учитывая, что к ресурсу Documents можно обратиться GET-запросом, злоумышленник обратился к файлу с шеллом и таким образом получил соединение с хостом.

Выявленные в ходе расследования фазы: Разведка, Первоначальный доступ, Выполнение.

Часть 2 Анализ дампа оперативной памяти

В качестве инструмента для анализа используется Volatility3. Здесь ожидается обнаружение продолжения фазы Выполнения, а также фазы Закрепления.

Выполнение

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

w3wp.exe – это рабочий процесс IIS, отвечающий обработку запросов веб-страниц и веб-приложений, запуск веб-приложений на сервере.

В нашем случае процесс w3wp.exe имеет PID 4332.

Обнаружили процесс, для которого w3wp.exe является родительским - updatenow.exe (PID 900, PPID 4332). Данный процесс не является стандартным дочерним процессом для w3wp.exe, поэтому получили дамп бинрника updatenow.exe. Также обратили внимание, что образец ВПО, предоставленный в триаже имеет аналогичное название. Сравнение хэшей показало, что оба файла одинаковы. Исходя из данных фактов утверждаем, что найденный нами процесс является процессом ВПО, которое злоумышленник загрузил через веб-шелл и запустил на сервере.

Закрепление

Проверили расположение исполняемого файла процесса updatenow.exe. Обнаружено, что бинарник находится в директории автозагрузки, что обеспечивает злоумышленнику закрепление на сервере:
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\updatenow.exe

Данное расположение свидетельствует об исполнении фазы Закрепления со стороны злоумышленника.

Более подозрительных процессов выявлено не было. Проверка аргументов запуска процессов также не выявила угроз.

Анализ сетевых соединений подтвердил активность, описанную при анализе дампа сетевого трафика. Обнаружены закрытые соединения с хостом 10.0.2.4 от портов 445 и 4443.

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

Выявленные в ходе расследования фазы: Выполнение, Закрепление.

Часть 3 Анализ ВПО

В изначальном триаже имеется образец ВПО, которое использовалось злоумышленником на сервере после закрепления – updatenow.exe. В рамках данной статьи не будет анализа данного объекта с помощью методов и инструментов обратного инжиниринга, так как хэш ВПО был обнаружен в базе VirusTotal. Поэтому ограничимся анализом через VirusTotal.

Проверка updatenow.exe на VirusTotal (1)

Категория ВПО: троян.

Изучив вкладку Details можем утверждать, что ВПО было упаковано с помощью UPX, с целью сокрытия объекта от антивируса.

Проверка updatenow.exe на VirusTotal (2)

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

Во вкладке Relations найден C2 сервер злоумышленника - cp8nl[].hyperhost[.]ua

Проверка updatenow.exe на VirusTotal (3)

На этапе проверки С2 домена появляются признаки истинного названия ВПО, которые скрывается за updatenow.exe – AgentTesla. Об этом также свидетельствуют комментарии на странице анализа updatenow.exe, отсылающие на сторонние отчёты.

Таким образом приходим к выводу, что в качестве основного ВПО использовался RAT AgentTesla, обладающий широким сектором возможностей. Например, сбор конфиденциальной информации, создание скриншотов, кейлогинг, загрузка/выгрузка файлов с хоста. По имеющейся информации, AgentTesla проявляет особый интерес к учётным данным, которые хранятся в браузерах, VPN-приложениях, клиентах удалённого доступа, почтовых клиентах, базах данных и т.п.

При анализе ВПО обнаружено, что злоумышленник прошёл следующие фазы: Предотвращение обнаружения, Сбор данных.

Фаз Организация управления и Эксфильтрация данных замечено не было, что свидетельствует о том, что ВПО ещё не начало свою работу (прим. автора – “Это обусловлено лабораторной работой”).

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

Разбор атаки по матрице MITRE ATT&CK

В качестве подведения результатов расследования разберём атаку по этапам, используя матрицу MITRE ATT&CK.

Разведка (Т1595 – Активное сканирование): сканирование портов с помощью nmap, обнаружение открытых 80 (http) и 445 портов (SMB).
Первоначальный доступ (Т1190 – Недостатки в общедоступном приложении): эксплуатация небезопасной конфигурации открытого 445 порта (SMB) для загрузки веб-шелла shell.aspx.
Выполнение (Т1059 - Интерпретаторы командной строки и сценариев): выполнение файла shell.aspx, вследствие чего злоумышленник получил шелл до сервера.
Закрепление (T1547 - Автозапуск при загрузке или входе в систему): добавление файла updatenow.exe в автозагрузку
Предотвращение обнаружения (T1027.002 - Упаковка ПО): использование упаковщика upx для файла updatenow.exe, загрузка кода веб-шелла в оперативную память.
Организация управления (T1071.001 - Веб-протоколы): установление соединения с C2 сервером cp8nl[.]hyperhost[.]ua
Сбор данных: работа updatenow.exe, который является RAT AgentTesla для сбора конфиденциальной информации.

IOC

Хэши:

c25a6673a24d169de1bb399d226c12cdc666e0fa534149fc9fa7896ee61d406f – хэш ВПО updatenow.exe (AgentTesla)
1c4dcdf9269666d7ee98b03353df987ab1af26802a24b8648a98ffb88a51a6e2 – хэш файла shell.aspx
94bf1fafad9c0b1b3570922da19ed68f4930ea855c54fbf844fe4d9be8d6a133 – хэш Meterpreter

IP-адреса:

10.0.2.4 – хост злоумышленника

Домены:

cp8nl[.]hyperhost[.]ua – С2 сервер для взаимодействия с TelsaAgent

Заключение

Итак, расследование закончено, отчёт написан. Надеимся, что вам было интересно. Если есть желание дать обратную связь, например указать на возможные ошибки в статье, милости просим в комментарии.

До скорых встреч!

Введение

Описание инцидента

Часть 1 Анализ дампа сетевого трафика

Первоначальный доступ

Выполнение

Часть 2 Анализ дампа оперативной памяти

Выполнение

Закрепление

Часть 3 Анализ ВПО

Разбор атаки по матрице MITRE ATT&CK

Рекомендации

IOC

Заключение

DFIR на практике. Часть 1: Lockdown Lab