Практический чек-лист сбора данных для DFIR-расследования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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