Шифровальщики. Как реагировать на атаки с использованием программ-вымогателей

Таким образом, мы можем получить следующие файлы:

System.evtx

Security.evtx

Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx

Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx

Рис. 8.2. Файлы журналов событий Windows, собираемые для набора EventLogs-RDP

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

Расследование атаки на RDP методом грубой силы

Итак, мы получили с помощью KAPE несколько файлов журналов событий Windows для дальнейшего анализа с сервера, который предположительно был взломан в результате атаки методом перебора паролей. Давайте сосредоточимся на файле Security.evtx, так как он содержит много записей, подходящих для таких расследований. Ниже приведены два основных идентификатора событий, полезных для анализа атаки на RDP методом грубой силы.

4624 — произведен вход в систему.

4625 — неудачная попытка входа в систему.

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

Возможно, вам стоит обзавестись справочником по идентификаторам событий, чтобы знать, на что обращать внимание при расследовании инцидента того или иного типа.

Давайте посмотрим на собранные журналы событий. Для начала проверим, имеются ли события с ID 4625. Здесь я хочу познакомить вас с еще одним инструментом из коллекции Эрика Циммермана — EvtxExplorer. Вы можете использовать его для анализа файлов журналов событий и сохранения данных в формате, пригодном для чтения, например CSV. Сгенерированные файлы удобно анализировать с помощью Timeline Explorer.

Рис. 8.3. События с ID 4625, извлеченные с помощью EvtxExplorer

Мы получили 196 378 событий с идентификатором 4625 — это означает, что на данный сервер была произведена атака путем полного перебора паролей. Но была ли она успешной? Чтобы разобраться, нужно изучить события с идентификатором 4624 (рис. 8.4).

Рис. 8.4. События с ID 4624, извлеченные с помощью EvtxExplorer

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

Если применить фильтр по типу 10, останется только два события. Оба соединения осуществлены с одного и того же IP-адреса — 185.191.32.164. Попробуем узнать о нем больше.

Рис. 8.5. Информация об IP-адресе из графа Group-IB

Исходя из собранной информации, мы можем точно идентифицировать вредоносное подключение — источник находится в России, а такие подключения абсолютно не характерны для данной жертвы.

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

Теперь давайте поищем источники данных для исследования следующего метода первоначального доступа — фишинга.

Сбор улик для расследования фишинговой атаки

Мы уже знаем, что такие боты, как Emotet, Trickbot и IcedID, — весьма распространенные предвестники атак программ-вымогателей, управляемых человеком. Обычно они доставляются по электронной почте с помощью вредоносных документов Office. В большинстве случаев для того, чтобы троян был загружен и запущен, жертва должна включить макросы. Кроме того, злоумышленники могут использовать для этого уязвимости в программном обеспечении.

Боты обычно применяются для проведения базовой разведки и подготовки к постэксплуатации — например, для доставки дополнительных инструментов, таких как Cobalt Strike Beacon.

Мы уже немного поработали с KAPE, поэтому теперь воспользуемся другим инструментом — Live Response Collection.

Это средство еще проще в использовании: нужно всего лишь запустить его с внешнего или сетевого диска и выбрать режим работы.

Рис. 8.6. Запуск Live Response Collection

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

Собранные данные попадают в две папки — ForensicImages и LiveResponseData. Образ памяти находится в папке ForensicImages. Теперь мы готовы приступить к этапу анализа.

Расследование фишинговой атаки

Для изучения образа памяти, полученного с помощью Live Response Collection, мы воспользуемся Volatility 3. Как мы помним из главы 5 «Тактики, техники и процедуры групп, занимающихся распространением программ-вымогателей», один из самых популярных методов, используемых вредоносными программами — инъекция в процесс. Давайте начнем с самого простого, запустив плагин malfind для анализа образа памяти.

Рис. 8.7. Часть вывода malfind

Этот плагин помогает найти скрытый код, внедренный код и код в форме библиотек DLL, поэтому он очень полезен для обнаружения инъекций в процессы.