В данной статье мы рассмотрим основные принципы DFIR и подробно расскажем о практических методах реагирования на инциденты.
DFIR, или цифровая криминалистика и реагирование на инциденты, давно перестал быть узкой технической задачей. Хорошая программа помогает понять, как злоумышленник вошёл в среду, где закрепился, какие учётные записи использовал, что успел изменить и как безопасно вернуть сервисы в работу.
DFIR начинается до атаки
Самый дорогой миф в расследовании звучит просто: при серьёзном инциденте команда разберётся по ходу дела. В реальности во время атаки обычно не хватает времени, спокойствия, доступов и полной картины. Рабочий DFIR начинается до первого тревожного сигнала.
Команде нужны роли, порядок эскалации, доступ к журналам, правила сохранения доказательств и понимание, кто принимает решения при ударе по критичным сервисам. Минимальная база включает карту активов, источники телеметрии, список критичных систем, защищённое хранилище артефактов, сценарии на первые часы инцидента и регулярные учения.
Без журналов аутентификации, облачного аудита, телеметрии средств обнаружения и реагирования на конечных устройствах, журналов системы доменных имён и сетевых событий расследование быстро зайдёт в тупик. Лучше найти такие дыры на учениях, чем во время атаки на почту, домен или систему резервного копирования.
Не спрашивайте почему мы в MAX.
Базовые источники телеметрии
- аутентификация, многофакторная аутентификация, виртуальная частная сеть и удалённый доступ;
- административные действия в Active Directory, Entra ID, облаках и облачные сервисы;
- DNS, прокси, сетевые потоки, события сетевых экранов;
- средства обнаружения и реагирования на конечных устройствах, Sysmon, журналы PowerShell, события Windows и Linux;
- почта, правила пересылки, OAuth-приложения, делегирование доступа;
- резервное копирование, удаление копий, изменения политик хранения;
- события непрерывной интеграции и доставки, шлюзов программных интерфейсов, Kubernetes и бессерверных платформ.
Рабочие фазы после сигнала
После тревоги команда не должна сразу «чинить всё подряд». Сначала нужно подтвердить, что перед ней инцидент, а не сбой или ложное срабатывание. Дальше команда оценивает масштаб, сдерживает ущерб, убирает причину, восстанавливает сервисы и разбирает, почему атака стала возможной.
Один сигнал ещё не доказывает инцидент. Подтверждение появляется, когда несколько источников складываются в связную картину: подозрительный вход совпадает с новым устройством, затем появляется нетипичное правило почты, запуск инструмента удалённого доступа или обращение к редкому домену. Чем важнее решение, тем нужнее независимые подтверждения.
Подтверждение
сигнал → факты → первичная гипотеза
Проверяются тревоги, журналы доступа, состояние узлов, действия учётных записей и признаки движения по среде. Ошибка на этом этапе — принять один индикатор за полную картину.
Сдерживание
ущерб → границы → изоляция
Команда ограничивает доступ злоумышленника, блокирует маркеры доступа и учётные записи, изолирует узлы или сегменты. Ошибка — отключить всё подряд и уничтожить важные следы.
Устранение причины
точка входа → закрепление → удаление
Нужно закрыть первичный путь входа, убрать механизмы закрепления, пересмотреть привилегии, ключи, маркеры доступа и политики. Удаление вредоносного файла без закрытия входа проблему не решает.
Восстановление
чистая конфигурация → контроль → возврат
Сервисы возвращаются в работу после проверки образов, резервных копий, учётных данных и защитных правил. Ранний запуск может вернуть злоумышленнику доступ.
Разбор
уроки → владельцы → сроки
Команда фиксирует первопричину, пробелы в телеметрии, задержки, ошибки коммуникации и конкретные улучшения с ответственными.
Криминалистика не должна мешать сдерживанию
Команда собирает данные для восстановления событий, проверки гипотез и передачи материалов юристам, регулятору или внешним расследователям. Ценность доказательств падает, если никто не знает, как данные получили, кто к ним обращался и почему артефактам можно доверять.
Правило «сначала фиксируем, потом лечим» работает как ориентир, но не как догма. При продолжающейся атаке команда может сначала заблокировать маркер доступа, закрыть доступ или изолировать сервис. В такой ситуации нужно зафиксировать хотя бы минимальное состояние, записать причину срочного действия и отдельно указать, какие следы могли быть потеряны.
Порядок сбора лучше строить по убыванию летучести — этот принцип описан в RFC 3227: сначала память, активные соединения, процессы и состояние системы, затем диски, журналы и менее изменчивые данные. В облаке и облачные сервисы порядок адаптируется: там память хоста может быть менее важна, чем журналы аудита и события идентификации, которые исчезнут при деактивации аккаунта или ротации ключей. Перезагрузка подозрительного узла, очистка временных катажурналов или замена виртуальной машины без фиксации состояния одинаково уничтожают контекст атаки.
Практический компромисс
Если сервис прямо сейчас отдаёт данные наружу, команда не ждёт полного образа диска. Команда фиксирует время, владельца решения, доступные артефакты, затем сдерживает ущерб и продолжает сбор по оставшимся источникам. Такой порядок честнее, чем делать вид, будто криминалистика всегда идёт в идеальных лабораторных условиях.
Анализ строится вокруг временной шкалы
Цель анализа — собрать связный рассказ о развитии инцидента. Команда должна понять, через что злоумышленник вошёл, какие действия выполнил, где закрепился, какие следы попытался удалить и какие активы затронул. Пока события не собраны в единую шкалу, расследование остаётся набором разрозненных наблюдений.
Временная шкала помогает увидеть последовательность событий, найти противоречия и обнаружить пустоты, где нужны дополнительные данные. Все события лучше приводить к всемирному координированному времени, отдельно проверяя часовые пояса, синхронизацию времени, рассинхрон часов на хостах и особенности облачных журналов.
След запуска файла сам по себе редко даёт полную картину. В связке со временем входа пользователя, созданием службы, сетевым соединением, PowerShell-командой и новым заданием в планировщике уже появляется сильная версия событий. Выводы нужно разделять по уровню уверенности: подтверждённый факт, вероятная связь, гипотеза.
Windows
EVTX, реестр, Prefetch, ShimCache, AmCache, $MFT, $UsnJrnl, LNK, Jump Lists, Shellbags, SRUM, WMI, RDP и журналы PowerShell помогают подтвердить запуск программ, активность пользователя, изменения конфигурации и следы закрепления.
Linux и UNIX
auth.log, journalctl, auditd, cron, systemd, история командной оболочки, SSH-ключи, журналы sudo и изменения прав показывают входы, команды, запуск служб и попытки закрепиться.
Active Directory и идентификация
Контроллеры домена, Kerberos-события, изменения групп, GPO, сервисные учётные записи, LDAP-запросы и журналы PAM-систем для привилегированного доступа (Privileged Access Management) помогают найти злоупотребление привилегиями.
Почта и облачные сервисы
Правила пересылки, OAuth-приложения, делегирование ящиков, подозрительные входы, сброс многофакторной аутентификации и массовые выгрузки помогают расследовать компрометацию учётных записей.
Сетевые следы помогают только при заранее включённой телеметрии
Сетевой уровень часто спасает расследование, когда локальные следы уже частично уничтожены. Потоки трафика, система доменных имён, прокси, журналы сетевых экранов, Zeek, Suricata, сетевые средства обнаружения и реагирования и средства обнаружения и реагирования на конечных устройствах помогают понять, с кем общался узел, когда началась нетипичная активность и куда мог уходить трафик.
Сетевые данные не появляются сами. При коротком сроке хранения сетевые потоки, отсутствии журналов системы доменных имён, трансляции сетевых адресов без привязки к пользователям или зашифрованном защищённом трафике без имени сервера, прокси-журналов и привязки средств обнаружения и реагирования на конечных устройствах к процессу сетевой слой тоже может оказаться почти пустым: содержимое сессии скрыто, а временны́е паттерны, объём и адреса дадут лишь косвенные зацепки. Поэтому сроки хранения и экспорт телеметрии нужно настроить до инцидента.
Что смотреть в сети
- редкие домены, новые автономные системы, ночную активность и повторяющиеся короткие сессии;
- нестандартные направления трафика от серверов и рабочих станций;
- запросы системы доменных имён перед запуском подозрительных процессов;
- объём исходящего трафика, особенно перед шифрованием или остановкой сервисов;
- связь сетевого события с пользователем, хостом и процессом, если такие данные доступны.
Облако и облачные сервисы
В облаке ключевые следы часто лежат не внутри виртуальной машины, а в журналах управления, событиях доступа, изменениях ролей и настройках ресурсов. В облачных сервисах вроде Microsoft 365 и Google Workspace нужно смотреть не диск, а действия пользователя, приложения и администратора.
AWS
В CloudTrail проверяют вход в консоль, создание ключей доступа, принятие роли, изменения управление доступом-политик, отключение журналырования, создание моментальные снимки, экспорт данных, новые группы безопасности и действия с резервными копиями.
Microsoft 365 и Entra ID
Единый журнал аудита, журналы входов, пользователи с риском, согласие OAuth-приложению, правила почтовых ящиков, eDiscovery export, многофакторная аутентификация reset, субъекты служб и делегированные разрешения помогают расследовать атаки на почту и идентификацию.
Azure и Google Cloud
Журналы действий, Entra ID, журналы аудита облака, управление доступом changes, служебные учётные записи, ключи, моментальные снимки, правила сетевых экранов и отключение мониторинга показывают административные действия и подготовку к закреплению.
Serverless и API
Для функции Lambda, функции Azure, шлюза программных интерфейсов и Kubernetes важны вызовы функций, изменения ролей, секреты, входящий доступ, служебные учётные записи, журналы аудита и события непрерывной интеграции и доставки. Локальные следы могут быть неполными или быстро исчезнуть.
Пример сценария
Компрометация Microsoft 365 может начаться с успешного входа из новой страны, затем перейти в согласие на OAuth-приложение, создание правила пересылки почты и выгрузку сообщений. Если команда смотрит только антивирус на рабочей станции, расследование пропустит главный контур атаки.
Вредоносное ПО
Подозрительные файлы анализируют так, чтобы получить признаки для обнаружения, блокирования и поиска соседних очагов компрометации. Цель не в красивом отчёте, а в ответе на практические вопросы: что запускалось, как закреплялось, куда подключалось, какие данные трогало и как найти похожую активность.
Статика
контрольная сумма → тип файла → признаки
Смотрят контрольные суммы, PE-секции, импортируемые функции, подпись, строки, упаковщики, ресурсы и возможные управляющие серверы-индикаторы. Подходящие инструменты: PEStudio, Detect It Easy, strings, capa, YARA.
Поведение
песочница → процессы → сеть
Файл запускают только в изолированной среде или гибридной песочнице: CAPE, Cuckoo, ANY.RUN, Joe Sandbox. Чувствительные образцы нельзя отправлять в публичные сервисы без согласования — образец может содержать данные жертвы, раскрыть сам факт расследования или попасть в публичные индикаторы компрометации-ленты раньше, чем атака сдержана.
Обратный анализ
код → журналыка → правило обнаружения
Для углублённого анализа используют Ghidra, IDA Free, x64dbg и другие отладчики. На выходе нужны YARA, Sigma, Suricata-правила, индикаторы компрометации и понятные условия поиска по инфраструктуре.
Изолированная среда не гарантирует полной картины. Современные образцы проверяют виртуализацию, задерживают выполнение, ждут пользовательской активности или требуют доступа к конкретному домену. Поэтому результаты песочницы нужно проверять по журналам реальной среды, но без запуска образца в рабочей сети.
Память и данные
Память часто хранит то, что исчезнет после перезагрузки: процессы, сетевые соединения, инъекции, ключи, маркеры доступа, командные строки и следы работы вредоносного кода. Поэтому сбор памяти нужно заранее отработать на типовых системах компании.
Для Windows используют WinPmem, Magnet RAM Capture и FTK Imager. Для Linux применяют LiME и профильные инструменты платформы. Для анализа актуальнее ориентироваться на Volatility 3: в 2025 году проект достиг функционального паритета с Volatility 2, после чего Volatility 2 перестал получать развитие. На практике важно не только иметь инструмент, но и проверить, что команда умеет безопасно снять снимок памяти на нужной версии ОС.
Восстановление начинается с проверки «чистоты»
Возврат к работе — не кнопка «включить обратно». Если точка входа не закрыта, закрепление не удалено, привилегии не пересмотрены, а защитные средства не обновлены, восстановление может закончиться повторным заражением.
Иногда надёжнее перестроить систему с эталонного образа, чем пытаться очистить среду с неизвестной глубиной компрометации. Но такое решение принимается только после завершения сбора доказательств — пересборка до этого момента уничтожает основу расследования. Золотой образ тоже нужно проверять: устаревшие настройки, слабые политики и старые агенты вернут системную проблему вместе с восстановлением.
Резервные копии требуют отдельной проверки. Наличие копии ещё не означает пригодность. Команда должна понимать, не попала ли атака в копию, не удалил ли злоумышленник точки восстановления и не получил ли доступ к консоли резервного копирования.
После возврата сервиса
- усилить мониторинг ключевых узлов и учётных записей;
- отслеживать новые административные действия;
- проверять целостность критичных файлов и конфигураций;
- искать повторные обращения к доменам, IP и инфраструктуре противника;
- держать отдельный канал связи, если корпоративная почта могла быть скомпрометирована.
Юридическая часть должна быть готова заранее
DFIR быстро выходит за рамки техники, когда расследование затрагивает персональные данные, переписку, коммерческую тайну, устройства сотрудников, подрядчиков, клиентов и уведомления регуляторов. Юристы должны подключаться не после публикации утечки, а при подготовке процедур.
Команде нужны правила правового удержания, порядок доступа к пользовательским данным, процедура работы с личными устройствами, шаблоны уведомлений и понятные границы обмена артефактами с подрядчиками.
Для российского контекста критичны сроки уведомлений при инцидентах с персональными данными. Если расследование выявило неправомерную передачу, распространение или несанкционированный доступ к персональным данным, оператор обязан уведомить Роскомнадзор в течение 24 часов после обнаружения, а по итогам внутреннего расследования — в течение 72 часов. DFIR-команда должна немедленно синхронизироваться с юристами: факты ещё неполные, а сроки уже идут. Доступ к переписке и личным устройствам сотрудников требует правовых оснований и заранее утверждённых процедур.
Рабочие инструменты
Инструменты нужно держать на отдельной рабочей станции, проверять версии, документировать параметры запуска и заранее понимать, где каждый инструмент полезен. Во время инцидента уже поздно выяснять, читает ли утилита нужный формат журнала и поддерживает ли текущую версию ОС.
Методика
MITRE ATT&CK помогает сопоставлять действия противника с техниками, а NIST SP 800-61 Rev. 3 связывает реагирование на инциденты с управлением киберрисками и CSF 2.0.
Windows-криминалистика
KAPE, MFTECmd, PECmd, EvtxECmd, RECmd, AppCompatCacheParser, AmcacheParser и другие EZ Tools помогают быстро собрать и разобрать артефакты Windows.
Образы и файловые системы
The Sleuth Kit, Autopsy, FTK Imager и X-Ways подходят для работы с носителями, образами, файловыми системами и восстановлением удалённых следов.
Память
WinPmem, Magnet RAM Capture и LiME помогают снять снимки памяти, а Volatility 3 — анализировать процессы, модули, инъекции, сетевые соединения и артефакты вредоносного кода.
Временные шкалы
Plaso и Timesketch удобны, когда нужно собрать события из разных источников и превратить расследование в проверяемую последовательность.
Журналы и обнаружение
Osquery, Wazuh, Sysmon, Sigma и системы управления событиями и информацией безопасности помогают собирать наблюдения с узлов и превращать выводы расследования в правила обнаружения.
Сеть
Zeek, Suricata, Wireshark, сетевые потоки и прокси-журналы помогают восстановить сетевое поведение и найти похожие обращения в других сегментах.
Удалённый отклик
Velociraptor часто выбирают для удалённого сбора артефактов и поиска угроз в больших средах. GRR Rapid Response остаётся рабочей альтернативой, особенно там, где уже есть экспертиза и инфраструктура под него.
Три коротких сценария
Компрометация почты
Расследование не ограничивается ноутбуком пользователя. Команда проверяет входы, многофакторная аутентификация, согласие OAuth-приложению, правила пересылки, делегирование ящика, массовые выгрузки, создание новых приложений и действия администратора в Microsoft 365 или Google Workspace.
Шифровальщик
Команда смотрит не только заражённые узлы. Нужны доменные администраторы, средства обнаружения и реагирования на конечных устройствах-исключения, GPO, PsExec или анажурналы, доступ к резервным копиям, отключение защитных средств, точки повторного входа и каналы вывода данных.
Инцидент через подрядчика
Фокус смещается на виртуальная частная сеть, промежуточные серверы, контроль привилегированного доступа (PAM), многофакторная аутентификация, временные окна активности, IP-адреса подрядчика, права сервисной учётной записи и подтверждение того, что доступ отключён везде, а не только в одной системе.
Чек-листы на первые часы
Короткие списки помогают не пропустить базовые шаги под давлением. Их стоит хранить рядом с рабочей станцией DFIR и обновлять после учений и реальных инцидентов.
Первые минуты
- Определить критичность инцидента и владельца затронутых сервисов.
- Назначить руководителя работ и единый канал коммуникации.
- Запретить хаотичную «починку руками» без фиксации действий.
- Сдержать ущерб так, чтобы по возможности сохранить следы.
- Начать сбор летучих данных и выгрузку журналов в защищённое хранилище.
Сбор доказательств
- Записывать каждый шаг в журнал расследования.
- Сначала снимать летучие данные, затем образы и журналы.
- Считать контрольные суммы и проверять целостность копий.
- Ограничивать доступ к материалам расследования.
- Разделять подтверждённые факты и гипотезы.
Шаблоны для расследования
Повторяемые формы делают расследование устойчивее. Когда у команды есть шаблон цепочки сохранности и рабочий журнал, меньше соблазна вести записи в личных заметках или оформлять действия по памяти через сутки.
Форма цепочки сохранности
Идентификатор объекта: ______________________ Описание системы, носителя или файлов: ______ Дата и время изъятия: _______________________ Часовой пояс: _______________________________ Место изъятия: ______________________________ Кем изъято: _________________________________ Способ получения и инструмент: ______________ Параметры запуска: __________________________ Контрольная сумма до и после: _______________ Место и способ хранения: ____________________ История передач: ____________________________ Примечания: _________________________________
Журнал расследования
Дата и время Время по всемирному координированному времени: ____________________ Исполнитель: ________________________________ Действие: ___________________________________ Инструмент и параметры: _____________________ Источник данных: ____________________________ Результат, файл или контрольная сумма: ______ Уровень уверенности: факт / гипотеза / требует проверки Следующий шаг: ______________________________
Типичные ошибки
Первая ошибка — перезагрузка подозрительного узла «для надёжности». Вместе с перезагрузкой исчезают память, активные соединения, часть процессов и контекст, который мог показать реальную глубину компрометации.
Вторая ошибка — преждевременная уборка. Администратор удаляет файлы, чистит катажурналы, меняет конфигурацию и закрывает задачи до фиксации исходного состояния. Компания получает ощущение бурной работы, но теряет основу расследования.
Третья ошибка — отсутствие записей. Команда может действовать технически грамотно, но без журнала шагов, контрольных сумм, времени и источников данных уже через несколько часов начинаются споры о том, кто и что сделал.
Четвёртая ошибка — восстановление из слабого образа. Если эталонный образ устарел, содержит прежние исключения средства обнаружения и реагирования на конечных устройствах или слабые политики, восстановление вернёт старую дыру под новым видом.
Как построить программу DFIR
Программа DFIR начинается с ролей и ответственности. Нужно определить, кто руководит расследованием, кто анализирует артефакты, кто общается с владельцами систем, кто отвечает за юридические вопросы и кто принимает решения о сдерживании, если цена ошибки высока.
Следующий шаг — техническая основа. Нужны хранилища журналов, инструменты, лаборатория или безопасный стенд, процедуры доступа, шаблоны документов и отдельные каналы связи на случай компрометации корпоративной почты.
Третий шаг — тренировки под реальные сценарии: шифровальщик, компрометация почты, злоупотребление привилегиями, утечка через облако, инцидент через подрядчика, атака на непрерывной интеграции и доставки или Kubernetes. Учения быстро показывают неработающие журналы, зависимость от одного специалиста, путаницу с доступами и слишком длинные согласования.
Как понять зрелость DFIR
Зрелость DFIR измеряется не числом инструментов, а скоростью и качеством решений. Полезно отслеживать MTTD — среднее время обнаружения, MTTC — среднее время до сдерживания (если организация считает его отдельно), MTTR — среднее время восстановления, долю инцидентов с полной временной шкалой и процент критичных систем с достаточной телеметрией.
Хороший итог расследования отвечает на четыре вопроса: как злоумышленник вошёл, как развивал атаку, почему защита не остановила действия раньше и что изменится после разбора. Если после инцидента не меняются правила мониторинга, доступы, сценарии реагирования, сроки хранения журналов и тренировки команды, организация просто пережила стресс, но не стала сильнее.
Вопросы и ответы
Чем DFIR отличается от SOC?
SOC обычно отвечает за мониторинг, первичную первичную сортировку и эскалацию. DFIR глубже восстанавливает события, собирает доказательства, проверяет гипотезы, помогает сдержать атаку и объясняет первопричину.
Можно ли перезагружать заражённый узел?
Без крайней необходимости — нет. Перезагрузка уничтожает летучие данные. Если перезагрузка нужна для сдерживания ущерба, зафиксируйте причину, время и последствия для расследования.
Когда звать внешних расследователей?
Внешняя команда нужна при атаке на критичные сервисы, подозрении на утечку, шифровальщике, компрометации домена, нехватке своих компетенций, конфликте интересов или вероятных требованиях регуляторов и страховщиков.
Когда нужно уведомлять Роскомнадзор?
Если инцидент затронул персональные данные — немедленно синхронизируйтесь с юристами. По 152-ФЗ оператор обязан уведомить РКН в течение 24 часов с момента обнаружения, а результаты внутреннего расследования передать в течение 72 часов. Сроки идут вне зависимости от полноты технической картины.