Windows IR: изоляция хоста, анализ процессов и служб

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

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

Шаг 4. Изоляция

Процедуру изоляции инфицированного хоста необходимо выполнять сразу после сбора сетевых артефактов и при наличии веских оснований. Я считаю, что при серьезных подозрениях на компрометацию затягивать с отключением машины от сети нельзя. Единственной причиной для временной отсрочки может стать углубленный анализ активных сетевых соединений, поскольку после обрыва связи утилита netstat перестанет фиксировать новые данные. Тем не менее, опираться исключительно на локальный вывод сетевой статистики рискованно, ведь кратковременные соединения с командным сервером (C2) могут ускользнуть от глаз. Намного эффективнее полагаться на периметровые логи и журналы межсетевого экрана.

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

Сравнение способов изоляции

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

Шаг 5. Процессы

Имея на руках данные о подозрительной сетевой активности неизвестного процесса, я перехожу к полной инвентаризации запущенных в системе задач. Для этого я выгружаю детальный список процессов с указанием идентификаторов PID, PPID, учетных записей владельцев и путей к исполняемым файлам в CSV-формате.

Полный список процессов

Полученный массив данных содержит сотни записей, особенно на загруженных терминальных серверах, где браузеры порождают множество дочерних процессов. Чтобы отсечь информационный шум на первичном этапе расследования, я использую фильтрацию по путям исполняемых файлов, исключая стандартные системные каталоги Windows и Program Files.

Список процессов без шума

Каталоги с ослабленными правами доступа внутри системной директории, такие как Temp, возвращаются в выборку с помощью специальной переменной. В ходе такого анализа я обнаруживаю подозрительный файл WindowsHealthMonitor.exe, запущенный из каталога C:\ProgramData\WindowsHealthMonitor\. Его имя мимикрирует под легитимный системный компонент, хотя в Windows ничего подобного не существует. Параметр родительского процесса указывает на services.exe, что выдает запуск в виде системной службы, созданной спустя десять минут после входа пользователя в систему.

Фильтрация по каталогам — не панацея

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

Фильтрация по цифровой подписи

Проверка цифровых подписей выступает отличным независимым инструментом для поиска аномалий. Большинство вредоносных утилит не имеют валидных подписей, хотя продвинутые группировки могут использовать украденные сертификаты. Ложные срабатывания здесь неизбежны из-за наличия старого неподписанного софта, но на серверных ОС их объем обычно минимален.

Дерево процессов

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

Содержимое каталога

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

Загруженные модули

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

Хэндлы

Анализ открытых дескрипторов (хэндлов) позволяет понять, с какими системными объектами взаимодействует процесс. Несмотря на активную запись логов, прямых открытых хэндлов на сетевые сокеты в момент проверки обнаружить не удалось, что говорит о кратковременном характере сетевых соединений.

Строки

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

Что уже установлено

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

Шаг 6. Службы

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

Просмотр всех служб

Для извлечения исчерпывающей информации я использую запросы к репозиторию CIM и прямое чтение веток системного реестра. Параметры автоматического запуска до авторизации пользователей и максимальные привилегии учетной записи LocalSystem подтверждают высокий уровень опасности обнаруженного компонента.

Фильтр по директориям

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

Проверка подписи файла

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

Извлечение хэша

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

Просмотр информации о службе

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

Просмотр каталога службы

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

Время создания служб

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

Итог по службам

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

Заключение второй части

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