Сбор данных (улик) для расследования взлома внешних служб удаленного доступа.

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

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

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

Сбор данных (улик) для расследования взлома внешних служб удаленного доступа

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

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

В анализ злоупотреблений внешними службами удаленного доступа обычно входит анализ журналов. Это могут быть журналы брандмауэра, журналы VPN или чаще всего журналы событий Windows, особенно если речь идет о взломе RDP.

Забавно, что во многих случаях, когда мы почти уверены, что атака начиналась со взлома общедоступного RDP-сервера, ИТ-команда клиента пытается убедить нас, что таких серверов в организации нет, — хотя из правил брандмауэра очевидно, что такой сервер есть или недавно был (правило только что удалено). Иногда ИТ-команда хочет усложнить вам работу и скрыть улики, потому что важную роль во многих инцидентах играет человеческий фактор — те, кто сделал атаку возможной, просто не хотят, чтобы их поймали.

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

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

Рис. 8.1. Сбор журналов событий Windows, связанных с RDP, с помощью KAPE

Как видно на рисунке 8.1, в KAPE есть готовый набор настроек для сбора журналов, связанных с RDP. Рисунок 8.2 показывает, какие именно файлы журналов собирает данный инструмент.

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

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 «Тактики, техники и процедуры групп, занимающихся распространением программ-вымогателей», один из самых популярных методов, используемых вредоносными программами — инъекция в процесс. Давайте начнем