DFIR: Digital Forensics & Incident Response — от основ до практики расследований

Введение в DFIR: цели, роли, процессы и доказательная база

Что такое DFIR и зачем он нужен

DFIR (Digital Forensics & Incident Response) — это практическая дисциплина на стыке информационной безопасности, ИТ-операций и (иногда) юридической функции, которая объединяет:

Incident Response (IR) — обнаружение, анализ и сдерживание инцидента, устранение причины и восстановление работы.

Digital Forensics (DF) — корректный сбор, сохранение, исследование и оформление цифровых данных так, чтобы выводы были проверяемыми и при необходимости могли использоваться в юридически значимом контексте.

DFIR нужен, когда организации важно одновременно:

Быстро снизить ущерб от атаки.

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

Доказуемо подтвердить выводы данными.

Предотвратить повторение (закрыть первопричину, улучшить контроль).

В реальности IR без форензики часто превращается в “потушили пожар, но не знаем, кто поджег”, а форензика без IR — в “идеально исследовали, но слишком поздно”.

Основные результаты работы DFIR

Типовые выходные артефакты DFIR:

Карта событий (что произошло и в какой последовательности).

Список затронутых систем и учетных записей.

Причина компрометации (например, фишинг, эксплуатация уязвимости, утечка учетных данных).

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

Рекомендации и план исправлений (технические и процессные).

Отчет об инциденте для руководства и/или регуляторов.

Доказательная база (набор данных и документации, которые позволяют воспроизвести ход расследования и проверить выводы).

Роли в DFIR и взаимодействие команд

DFIR почти всегда командная работа. Даже если расследование ведет один специалист, ему необходимы “смежники”: администраторы, владельцы систем, юристы, служба безопасности, иногда PR.

Ключевые роли

Incident Commander / IR Lead — управляет реагированием, приоритизирует действия, координирует команды.

DFIR-аналитик (форензик) — отвечает за корректный сбор данных, анализ артефактов, оформление выводов.

Аналитик SOC — первично обнаруживает, фильтрует ложные срабатывания, собирает контекст.

Threat Hunter — проактивно ищет следы атак в телеметрии (логи, EDR, сеть) по гипотезам.

Malware-аналитик — исследует вредоносные файлы и поведение, помогает понять возможности атакующего.

Системные/сетевые администраторы — выполняют изменения в инфраструктуре (изоляция хостов, блокировки, патчи).

Владелец бизнеса/процесса — принимает решения о допустимом простое и приоритетах.

Юристы/комплаенс — обеспечивают корректность работы с персональными данными, уведомления, юридические риски.

Чем IR отличается от форензики (и где пересечение)

| Область | Основная цель | Главный фокус | Риск при перекосе | |---|---|---|---| | Incident Response | Снизить ущерб и восстановить работу | Скорость, управляемость, изоляция, устранение причины | Можно уничтожить важные следы, если действовать без учета доказательности | | Digital Forensics | Получить проверяемую картину событий на основе данных | Сохранность и воспроизводимость данных, методичность | Можно действовать слишком медленно и дать атаке развиться | | DFIR вместе | И быстро остановить, и доказуемо понять | Баланс скорости и сохранения данных | Требует процессов и дисциплины документации |

Процессы DFIR: “как именно мы работаем”

В DFIR важен не только результат, но и как к нему пришли: это влияет на качество выводов, возможность повторной проверки и юридическую устойчивость.

Жизненный цикл реагирования на инциденты

Один из наиболее распространенных ориентиров — NIST SP 800-61 Rev. 2, где реагирование описывается как цикл:

Подготовка — инструменты, доступы, логирование, плейбуки, обучение, резервное копирование.

Обнаружение и анализ — подтверждение инцидента, определение приоритета, сбор первичных данных.

Сдерживание, устранение и восстановление — изоляция, удаление вредоносного, закрытие первопричины, возврат в нормальный режим.

Действия после инцидента — уроки, улучшения, финальный отчет.

!Цикл реагирования помогает понимать, какие задачи должны быть закрыты до, во время и после инцидента

Форензический процесс (от данных к выводам)

Форензика обычно описывается как последовательность шагов: от идентификации источников данных до отчета. Практичный ориентир — NIST SP 800-86 и принципы ISO/IEC 27037.

Типовой поток работ:

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

Сохранение (preservation) — действия, минимизирующие изменение данных, и фиксация условий.

Сбор (collection) — получение копий данных (например, образ диска, дамп RAM, экспорт логов).

Исследование (examination) — извлечение артефактов (временные метки, записи реестра, файлы, события).

Анализ — интерпретация: что означают артефакты и как они связаны.

Отчетность (reporting) — выводы, допущения, ограничения, воспроизводимые шаги.

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

Доказательная база: что считается “доказательством” в DFIR

Цифровые доказательства и артефакты

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

Источники данных (на верхнем уровне):

Хостовые данные — файлы, журналы ОС и приложений, реестр (Windows), конфиги.

Память (RAM) — процессы, сетевые соединения, инъекции, незаписанные на диск ключи/фрагменты.

Сетевые данные — NetFlow, PCAP, DNS-логи, прокси, firewall.

Телеметрия безопасности — EDR, SIEM, IDS/IPS.

Облачные журналы — аудиты IAM, логи доступа, действия API.

Данные идентификации — журналы аутентификации, MFA, события каталогов.

Волатильность и “порядок волатильности”

Данные бывают волатильными (быстро исчезают) и менее волатильными (сохраняются дольше). Классическая идея order of volatility подсказывает приоритет сбора: сначала то, что пропадет быстрее. Один из известных источников — RFC 3227.

Практический смысл:

Дамп RAM и список активных соединений часто важнее “первого снимка диска”, потому что перезагрузка, изоляция или завершение процессов могут уничтожить эти данные.

С другой стороны, если действия по сбору памяти повышают риск (например, критический сервер), решение может быть иным — это управленческий компромисс.

Цепочка хранения (chain of custody)

Chain of custody — это документированный контроль того, кто, когда и как получал доступ к носителям/копиям данных и что с ними делал. Цель — исключить сомнения, что данные были подменены или изменены без контроля.

Что обычно фиксируется:

Кто собрал данные и на каком основании (тикет/распоряжение/инцидент).

Где, когда и каким методом собраны данные.

Где и как хранятся исходные носители и рабочие копии.

Кто и когда получал доступ.

Целостность данных и хеш-суммы

Чтобы подтвердить, что копия данных не менялась, используют криптографические хеш-функции (например, SHA-256). Идея простая:

Для исходного набора данных вычисляется хеш.

Для копии вычисляется хеш.

Если хеши совпадают, это сильный признак, что данные идентичны.

В DFIR важно записывать хеши в отчет и/или журнал chain of custody.

Время, временные метки и проблема “когда именно это было”

Практически любое расследование упирается во временную линию. Но время в цифровых системах неоднозначно:

Системы могут быть в разных часовых поясах.

Часы могут быть неверно синхронизированы.

Разные логи пишут время по-разному (локальное, UTC, с разной точностью).

Поэтому в DFIR принято:

Явно фиксировать часовой пояс и формат времени в отчете.

Собирать данные о синхронизации времени (например, NTP-настройки) при возможности.

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

Минимальные принципы качественного DFIR

Законность и полномочия — работы выполняются только в рамках разрешений и согласованного scope.

Минимизация изменений — не “лечить” систему до сбора критических данных.

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

Документирование — решения, наблюдения, команды, времена, источники данных.

Разделение оригиналов и рабочих копий — анализ проводится на копиях, оригиналы хранятся.

Прозрачность допущений — что известно точно, а что является гипотезой.

Типовой поток работ в реальном инциденте (в очень упрощенном виде)

Подтверждаем инцидент и определяем приоритет (влияние на бизнес, критичность систем).

Фиксируем полномочия, scope и правила коммуникаций.

Выполняем первичный сбор наиболее волатильных данных там, где это безопасно.

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

Расширяем сбор данных (образы, логи, сетевые следы) и строим временную линию.

Определяем первопричину и масштаб.

Устраняем причину, восстанавливаем сервисы.

Готовим отчет, IOC, рекомендации и улучшения.

!Общая картинка того, как данные превращаются в проверяемые выводы

Что будет дальше в курсе

Дальнейшие темы курса будут опираться на это введение:

Практика сбора данных: логи, диск, память, облако.

Построение таймлайна и корреляция событий.

Базовый и прикладной анализ малвари и артефактов.

Оформление результатов: отчеты, IOC, lessons learned.

Организация процесса DFIR в компании: плейбуки, инструменты, готовность.

Рекомендуемые стандарты и материалы

NIST SP 800-61 Rev. 2: Computer Security Incident Handling Guide

NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response

RFC 3227: Guidelines for Evidence Collection and Archiving

ISO/IEC 27037 (страница стандарта ISO)

MITRE ATT&CK

Подготовка к инцидентам: логирование, инструменты, плейбуки и форензик-гигиена

Зачем готовиться заранее

В предыдущей статье мы разобрали, что DFIR объединяет скорость реагирования (IR) и доказуемость выводов (форензика), а также почему важны волатильность данных, целостность и chain of custody. Подготовка к инцидентам — это практическая реализация этих принципов до того, как случится атака.

Если подготовки нет, то в момент инцидента обычно происходит следующее:

Логов не хватает или они разрознены.

Нет доступа к нужной телеметрии и инструментам.

Неясно, кто принимает решения и что делать первым.

Действия “для лечения” случайно уничтожают следы.

Цель этой статьи — дать вам базовый, но рабочий каркас forensic readiness (форензической готовности): что логировать, какими инструментами пользоваться, как описывать действия плейбуками и как соблюдать форензик-гигиену.

Логирование как фундамент DFIR

Что такое логирование в контексте расследований

Логи — это записи о событиях в системах и приложениях. Для DFIR важны не любые логи, а те, которые помогают ответить на вопросы:

Что произошло (какое событие и на каком активе).

Когда (время и часовой пояс).

Кто инициировал (учетная запись, токен, ключ API).

Каким способом (процесс, команда, сетевое соединение, запрос к API).

Каков масштаб (одиночная активность или массовая).

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

Минимальный набор источников логов

Ниже — “скелет” телеметрии, без которой расследования почти всегда превращаются в догадки.

| Область | Примеры источников | Что дает в расследовании | |---|---|---| | Идентификация и доступ | AD/Azure AD sign-in, VPN, RADIUS, IAM audit | Входы, MFA, подозрительные попытки, эскалации прав | | Хост (Windows/Linux/macOS) | Журналы ОС, аудит процессов, EDR телеметрия | Запуски процессов, persistence, локальные изменения | | Сеть | DNS, proxy, firewall, NetFlow, VPN | C2-коммуникации, эксфильтрация, lateral movement | | Почта и коллаборация | Email audit, антифишинг, журналы доступа | Первичная компрометация через фишинг | | Облако | CloudTrail, Azure Activity Logs, GCP Audit Logs | Действия через API, изменения политик, ключей | | Критичные приложения | Web/WAF, DB audit, приложения бизнеса | Атаки на веб, утечки из БД, злоупотребления |

Если вы выбираете, с чего начать, то чаще всего максимальную ценность дают:

Логи аутентификации и изменения прав.

DNS и прокси.

Хостовая телеметрия (через EDR и/или расширенный аудит).

Качество логов: полнота, точность, сопоставимость

Чтобы логи работали в DFIR, важно управлять их качеством.

Единое время: договоритесь, что храните время в UTC или всегда явно фиксируете часовой пояс.

Синхронизация времени: на серверах и рабочих станциях должен быть корректный NTP.

Единые идентификаторы: хостнеймы, уникальные IDs устройств, user principal name, идентификаторы облачных аккаунтов.

Контекст: событие без полей “кто” и “откуда” часто бесполезно.

!Поток логов от источников до SIEM и использования в мониторинге и расследовании

Централизация и неизменяемость

При подготовке важно решить две задачи:

Централизация: логи должны собираться в место, где их не “потеряет” компрометация одной машины.

Устойчивость к подделке: атакующий часто чистит локальные журналы, поэтому критичные логи лучше хранить отдельно и ограничивать доступ.

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

Раздельные роли доступа (просмотр, администрирование, экспорт).

Отдельный аккаунт для DFIR-доступа.

Дополнительную копию (архив) на период ретенции.

Ретенция: сколько хранить

Ретенция — срок хранения логов. Универсального числа нет, но есть ориентиры.

Для “быстрого реагирования” часто достаточно 30–90 дней.

Для расследований сложных атак полезно 180–365 дней, потому что злоумышленники могут находиться в сети месяцами.

Ретенцию выбирают исходя из:

Типичных сценариев угроз.

Требований регуляторов и контрактов.

Стоимости хранения.

Способности команды реально анализировать эти данные.

Инструменты готовности: что должно быть под рукой

Инструменты в DFIR — это не “список модных утилит”, а заранее проверенный набор для:

Сбора данных.

Быстрого triage (первичной диагностики).

Глубокого анализа.

Документирования.

Категории инструментов

| Категория | Зачем нужна | Примеры | |---|---|---| | SIEM/Log management | Корреляция, поиск, хранение | Splunk, Microsoft Sentinel, Elastic | | EDR | Телеметрия хоста, изоляция, response actions | Microsoft Defender for Endpoint, CrowdStrike, SentinelOne | | Сбор артефактов (endpoint) | Быстрый сбор файлов, логов, реестра, triage | Velociraptor, osquery | | Сбор памяти | Поиск инъекций, ключей, сетевых артефактов | WinPMEM, Volatility | | Анализ дисков/образов | Файловая система, таймлайны, артефакты | Autopsy/Sleuth Kit, FTK Imager | | Пакетный анализ логов/IOC | Массовый поиск по среде | KQL/SQL, Sigma правила | | Кейсы и документация | Chain of custody, заметки, задачник | TheHive, Jira/ServiceNow |

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

“Боевой доступ” и безопасное администрирование

Частая проблема: инструмент есть, но в момент инцидента нет доступа.

Рекомендуемые практики:

Отдельные учетные записи для администрирования и для повседневной работы.

MFA на доступ к SIEM/EDR/облаку.

Break-glass аккаунт (аварийный доступ) с жестким контролем использования и журналированием.

Jump host (выделенный хост) для админ-доступа, на котором есть нужные утилиты и ограничен выход в интернет.

Проверка инструментов до инцидента

Инструменты нужно “обкатать”, иначе в кризис выяснится, что:

Агент не развернут на части серверов.

EDR не собирает нужные события.

Экспорт логов не работает или занимает дни.

Нет шаблонов отчетов и форм chain of custody.

Полезная практика — короткие учения, где команда проверяет:

Сбор ключевых логов.

Изоляцию хоста через EDR.

Экспорт артефактов.

Сбор дампа памяти на тестовой машине.

Плейбуки реагирования: как действовать одинаково хорошо

Плейбук — это пошаговая инструкция для типового сценария, где заранее определены роли, входные данные, решения и выходные артефакты.

Плейбуки нужны, чтобы:

Не терять время на “а что делаем?”.

Снижать риск ошибок и уничтожения следов.

Делать действия воспроизводимыми.

Из чего состоит хороший плейбук

Ниже — структура, которая обычно работает.

Триггеры: какие сигналы запускают плейбук (алерт SIEM, письмо от пользователя, уведомление EDR).

Scope: какие системы входят в периметр, какие исключения.

Роли и контакты: кто IR lead, кто админы, кто юристы, кто владелец сервиса.

Первые 15–30 минут: быстрый triage и сбор волатильных данных там, где это безопасно.

Сдерживание: варианты изоляции с учетом риска потери доказательств.

Сбор данных: конкретный список источников и способ выгрузки.

Анализ: какие гипотезы проверяем и по каким артефактам.

Устранение и восстановление: какие изменения считаются “чистыми”, критерии возврата в прод.

Коммуникации: кто и что сообщает руководству, пользователям, регуляторам.

Выходные артефакты: IOC, таймлайн, отчет, lessons learned.

!Как плейбук превращает хаотичные действия в управляемый процесс

Плейбук и доказательность

Плейбук должен помогать не только “лечить”, но и сохранять доказательства. Поэтому в нем полезно явно фиксировать:

Какие действия запрещены до сбора данных (например, переустановка ОС, чистка диска, “антивирусом удалить все”).

Когда допустима перезагрузка и кто это утверждает.

Где и как фиксируются хеши, имена файлов, время сборов.

Примеры плейбуков, с которых обычно начинают

Фишинг с компрометацией учетной записи.

Срабатывание EDR на вредоносный процесс.

Подозрение на утечку данных.

Подозрительная активность в облаке (создание ключей, отключение логов, изменения IAM).

Форензик-гигиена: как не испортить расследование

Форензик-гигиена — это набор привычек и технических правил, которые снижают риск:

Потерять данные.

Изменить артефакты так, что им нельзя доверять.

Не суметь объяснить, откуда взялись выводы.

Главные риски “вредных” действий

На практике чаще всего ломают расследование так:

Перезагружают систему до сбора RAM (теряются процессы, сетевые соединения, ключи).

Запускают “лечилки”, которые удаляют файлы и перетирают артефакты.

Собирают данные без фиксации времени, источника и параметров.

Смешивают оригиналы и рабочие копии.

Минимальные правила форензик-гигиены

Документируйте все: кто сделал, что сделал, когда сделал, на каком хосте, из какого источника получили данные.

Разделяйте оригиналы и копии: анализ делайте на копиях.

Фиксируйте целостность: вычисляйте и сохраняйте хеши (например, SHA-256) для образов и крупных артефактов.

Управляйте доступом: минимальный круг лиц, отдельные учетные записи, журналирование доступа.

Соблюдайте порядок волатильности: по возможности сначала собирайте то, что исчезает быстрее.

Не “чините” до сбора: любые remediation-действия должны быть осознанным решением, а не рефлексом.

Chain of custody в “корпоративном” DFIR

Даже если вы не готовите материалы в суд, chain of custody полезен для качества работы и внутренней проверки.

Обычно достаточно, чтобы на каждый существенный набор данных было:

Уникальное имя/идентификатор (например, INC-2026-001_HOST123_RAM).

Дата и время сбора.

Кто собрал.

Инструмент и версия.

Хеш.

Где хранится оригинал и кто имеет доступ.

Подготовка хранилища доказательств

Чтобы не импровизировать, заранее продумайте:

Где хранить собранные образы, дампы памяти, экспорты логов.

Как разделять “сырые” данные и результаты анализа.

Как обеспечивать резервное копирование и контроль доступа.

Практичный минимум — отдельное защищенное хранилище с:

Ограничением записи.

Раздельными правами на чтение и администрирование.

Регулярной проверкой доступности.

Как связать все вместе: чеклист готовности

Ниже — компактный чеклист, который можно использовать как план работ.

Логирование

Есть централизованный сбор логов с критичных систем.

Есть логи аутентификации и изменения прав.

Есть DNS и прокси (или эквивалент сетевого следа).

Время синхронизировано, часовые пояса понятны.

Ретенция соответствует рискам.

Инструменты

EDR покрывает рабочие станции и серверы (или есть альтернативный сбор артефактов).

Есть инструмент быстрого endpoint triage.

Есть возможность собрать дамп памяти на тестовом стенде.

Есть процесс экспорта данных из SIEM/EDR/облака.

Плейбуки и процесс

Определены роли и контакты (включая владельцев систем).

Есть минимум 2–4 плейбука под типовые сценарии.

Есть форма/шаблон для chain of custody и отчета.

Проводятся учения и проверка доступа.

Что дальше

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

Рекомендуемые источники

NIST SP 800-61 Rev. 2: Computer Security Incident Handling Guide

NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response

RFC 3227: Guidelines for Evidence Collection and Archiving

Sysmon (Sysinternals) documentation

Velociraptor (GitHub)

osquery documentation

Volatility 3 documentation (GitHub)

MITRE ATT&CK

Incident Response: triage, containment, eradication и восстановление

Как эта тема связана с предыдущими статьями

В первой статье мы определили, что DFIR держится на балансе скорости (Incident Response) и доказуемости (Digital Forensics), а во второй — разобрали forensic readiness: логирование, инструменты, плейбуки и форензик-гигиену.

Эта статья — про центральную часть реагирования: что делать во время активного инцидента. Мы разложим IR на практичные этапы:

Triage — быстро понять, что случилось и насколько это критично.

Containment — сдержать угрозу и остановить ущерб.

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

Recovery — безопасно вернуть сервисы в нормальный режим.

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

!Блок-схема показывает, что реагирование — итеративный процесс, а сбор данных и коммуникации идут параллельно всем этапам

Предварительные условия: без чего IR будет хаотичным

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

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

Единый канал управления: есть IR lead (incident commander) и понятный процесс принятия решений.

Единое время: вы знаете часовой пояс логов и фиксируете его в заметках и выгрузках.

Форензик-гигиена: вы не делаете необратимых действий до сбора критичных данных или до явного решения, что “спасти сервис важнее артефактов”.

Triage: быстрый разбор “что это и насколько плохо”

Что такое triage в IR

Triage — это быстрый отбор и первичный анализ, чтобы:

Подтвердить, что это инцидент (а не ложное срабатывание).

Определить тип инцидента (учетка, малварь, утечка, веб-взлом, облако и т.д.).

Оценить критичность и срочность.

Понять, какие данные нужно срочно собрать (особенно волатильные).

Важно: triage — не глубокая форензика и не “полное расследование”. Его цель — дать управляемость и правильные первые решения.

Входные данные triage

Типовые источники, которые вы используете в первые минуты/часы:

Алерт SIEM/EDR и его поля (процесс, хэш, родитель, командная строка, user, хост, время).

События аутентификации (успешные/неуспешные входы, MFA, suspicious sign-in).

DNS/Proxy/Firewall след (куда ходил хост, какие домены резолвил).

Контекст актива (критичность сервиса, владелец, роль хоста, сегмент сети).

Минимальный набор вопросов triage

Чтобы не “утонуть” в деталях, держите короткий набор вопросов:

Что именно произошло (наблюдаемое событие)?

Где произошло (какой хост, аккаунт, облачный tenant, приложение)?

Когда началось (первое известное событие) и продолжается ли сейчас?

Есть ли признаки распространения (другие хосты, другие аккаунты, другие сегменты)?

Какой потенциальный ущерб (простой, утечка, шифрование, компрометация привилегий)?

Оценка приоритета: простая модель

Удобно оценивать приоритет через комбинацию:

Impact: влияние на бизнес (критичный сервис, данные, простой).

Scope: масштаб (один хост или множество, привилегии пользователя или admin).

Confidence: уверенность, что это реальная атака.

Пример практичной шкалы (которую легко зафиксировать в плейбуке):

| Параметр | Низкий | Средний | Высокий | |---|---|---|---| | Impact | Минимальный | Заметный | Критичный | | Scope | 1 актив | Несколько | Массово/ключевые узлы | | Confidence | Сомнительно | Вероятно | Подтверждено |

На основании этой оценки IR lead выбирает темп и жесткость containment.

Что собирать в triage, чтобы не потерять важное

Приоритет triage — данные, которые легко пропадают или быстро меняются:

Снимок EDR-артефактов (process tree, network connections, file events) по подозрительному процессу.

Выгрузка ключевых журналов (хост, аутентификация, прокси/DNS) за окно времени вокруг алерта.

Если возможно и безопасно: сбор памяти (RAM) на наиболее “горячих” хостах.

Краткая подсказка, что собирать по типам инцидентов:

| Сценарий | Что собрать в первые минуты/часы | Почему это важно | |---|---|---| | Подозрение на малварь на хосте | EDR telemetry, процесс/командная строка, сетевые соединения, RAM (по возможности) | В памяти бывают инъекции, ключи, сессии | | Компрометация учетки | Sign-in логи, события MFA, изменения прав, токены/сессии (если платформа позволяет) | Нужно понять, действовал ли злоумышленник и где | | Веб-инцидент | WAF/веб-логи, логи приложения, доступ к админкам, изменения файлов | Часто важны конкретные запросы и параметры | | Подозрение на утечку | Прокси/DNS/NetFlow, события доступа к хранилищам, аудиты БД/облака | Нужны следы эксфильтрации и обращений к данным |

Containment: сдерживание без саморазрушения доказательств

Цель containment

Containment — остановить рост ущерба. Это может означать:

Прервать активность злоумышленника.

Ограничить lateral movement.

Остановить эксфильтрацию.

Предотвратить шифрование/уничтожение.

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

Виды containment

На практике удобно разделять:

Short-term containment: быстрые меры “прямо сейчас”, чтобы выиграть время.

Long-term containment: более устойчивые изменения, пока идет расследование и подготовка eradication.

Типовые варианты containment и их форензик-последствия

| Действие | Когда применяют | Плюсы | Риски для форензики | |---|---|---|---| | Изоляция хоста через EDR | Активная малварь, C2, lateral movement | Быстро останавливает сеть | Можно потерять связь для удаленного сбора, меняется состояние системы | | Блокировка IOC (домены/IP/хеши) | Ясные индикаторы | Сдерживает массово | IOC могут быть неполными, можно “спугнуть” атакующего | | Отключение учетной записи / сброс пароля | Компрометация учетки | Ломает доступ | Может разрушить следы сессий и затруднить атрибуцию действий | | Отзыв токенов/сессий, принудительный re-auth | Облако/SSO | Быстро гасит доступ | Может усложнить реконструкцию активных сессий | | Сегментация/ACL временно | Распространение по сети | Снижает lateral movement | Требует аккуратности, риск простоя | | “Выдернуть из сети” физически | Критический случай | Максимально быстро | Потеря удаленного сбора, риск потери волатильных данных |

Практические правила containment

Сначала зафиксируйте, потом ломайте: по возможности снимите минимум контекста (время, процесс, подключения, логи) до изоляции/блокировок.

Containment должен быть обратимым: временные правила firewall, отдельная VLAN/quarantine, EDR network containment.

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

Документируйте “почему так”: в отчете важно объяснить, почему выбрали именно эту меру.

Eradication: устранение причины и следов компрометации

Что такое eradication

Eradication — это не “удалили один файл”. Это удаление всего, что обеспечивает присутствие злоумышленника, и закрытие первопричины.

У eradication два результата:

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

Среда становится предсказуемой: вы понимаете, какие изменения внесены и почему.

Типовые компоненты eradication

Набор действий зависит от сценария, но обычно включает:

Удаление или переустановка скомпрометированных компонентов (малварь, webshell, backdoor).

Удаление persistence (службы, scheduled tasks, autoruns, launch agents, crontab).

Исправление первопричины (патч уязвимости, закрытие RDP/VPN, исправление конфигурации, отключение небезопасных протоколов).

Ротация секретов (пароли, ключи API, OAuth apps, сертификаты), если есть риск их компрометации.

Ужесточение прав и политики доступа (least privilege, MFA, Conditional Access).

“Почистили — и что?”: критерии завершения eradication

Eradication можно считать завершенной, когда выполнены условия:

Найден и устранен исходный вектор (или принят формальный риск, что вектор неизвестен, но закрыты наиболее вероятные).

Проверены ключевые гипотезы распространения (по логам/EDR/хантингу) и нет новых подтверждений компрометации.

IOC и TTP злоумышленника отражены в детекциях, а блокировки настроены так, чтобы не мешать восстановлению.

Почему “переустановить сервер” не всегда eradication

Переустановка может убрать следы на конкретном хосте, но не решает проблему, если:

Скомпрометирована учетка администратора.

Украдены ключи доступа к облаку.

Уязвимость в приложении остается.

Persistence находится в другом месте (например, GPO, CI/CD, OAuth приложение).

Recovery: безопасное восстановление и возврат в прод

Цель recovery

Recovery — вернуть системы в рабочее состояние так, чтобы:

Не вернуть злоумышленника вместе с сервисом.

Сохранить возможность расследования (по копиям данных и экспортам).

Зафиксировать изменения и контрольные точки.

План восстановления: что должно быть определено заранее

Хороший recovery опирается на подготовку:

Какие бэкапы считаются доверенными.

Кто утверждает возврат сервиса.

Какие проверки безопасности обязательны перед включением.

Checklist восстановления

| Шаг | Что делаем | Какой результат ожидаем | |---|---|---| | Подтвердить “чистую базу” | Доверенный образ/бэкап, проверка целостности | Понимаем, от чего восстанавливаемся | | Верифицировать учетные записи | Ротация паролей, MFA, ревизия привилегий | Нет старых ключей у атакующего | | Верифицировать конфигурацию | Патчи, закрытие эксплуатируемых портов, baseline hardening | Первопричина закрыта | | Контроль включения в сеть | Постепенное подключение, мониторинг | Если проблема повторится — увидим быстро | | Усиленный мониторинг | Повышенные алерты, охота по IOC/TTP | Раннее обнаружение повторной атаки |

“Готово к прод” (exit criteria)

Установите критерии, при которых сервис можно возвращать:

Нет активных алертов по связанным IOC/TTP.

Закрыта первопричина и подтверждено изменениями (тикеты, конфиги, патчи).

Проведена ротация секретов там, где это необходимо.

Владельцы бизнеса приняли риск остаточной неопределенности (если она есть) и это зафиксировано.

Коммуникации и документация: то, что держит инцидент управляемым

Единый журнал инцидента

С первого часа ведите “боевой лог” (incident log):

Время (с часовым поясом или в UTC).

Действие.

Кто выполнил.

На каком активе.

Результат.

Ссылки на артефакты (выгрузки логов, хеши файлов, кейсы EDR).

Это одновременно основа для отчета, chain of custody (в корпоративном смысле) и разборов полетов.

Кому и что сообщать

Коммуникации в IR — это управление ожиданиями и рисками. Минимально разделяйте:

Технический статус: что подтверждено фактами, что гипотеза, что сделано.

Бизнес-статус: влияние, простой, сроки восстановления, риски утечки.

Юридический/регуляторный контур: когда подключать юристов, нужно ли уведомление.

Практическое правило: не обещайте того, что не подтверждено данными. Лучше говорить “на текущий момент подтверждено…” и “проверяем гипотезу…”.

Частые ошибки и как их избегать

Слишком ранняя “чистка”: удаление файлов и перезагрузки до сбора контекста лишают вас доказательств и понимания.

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

Eradication без root cause: устранение симптомов приводит к повторной компрометации.

Recovery без усиленного мониторинга: вы возвращаете сервис и “закрываете глаза”, хотя повтор может случиться сразу.

Недооценка учетных записей и секретов: компрометация identity часто важнее компрометации одного хоста.

Практичный “скелет” плейбука на эти этапы

Если вам нужно быстро оформить процесс, используйте каркас:

Подтверждение сигнала и первичная классификация.

Сбор минимального набора данных triage.

Решение о containment с фиксацией рисков и обоснованием.

Расширенный сбор данных (по необходимости: хост, сеть, облако).

Eradication: закрытие первопричины, удаление persistence, ротация секретов.

Recovery: восстановление из доверенной базы, проверки, включение под мониторинг.

Финализация: IOC/TTP в детекции, отчет, lessons learned.

Рекомендуемые источники

NIST SP 800-61 Rev. 2: Computer Security Incident Handling Guide

NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response

CISA: Incident Response Playbook

MITRE ATT&CK

Цифровая криминалистика: сбор артефактов с диска, памяти и сети

Как эта тема связана с предыдущими статьями

В прошлых материалах мы закрепили две опоры DFIR:

процесс реагирования (triage, containment, eradication, recovery);

форензическую готовность (логирование, инструменты, плейбуки, форензик-гигиена, chain of custody).

Эта статья переводит принципы в практику: что именно собирать и как собирать корректно в трех ключевых плоскостях:

диск (персистентные артефакты);

память (волатильные артефакты);

сеть (следы коммуникаций и эксфильтрации).

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

!Карта источников артефактов и их роли в расследовании

Базовые понятия: артефакт, источник данных, сбор и образ

Что такое артефакт

Артефакт — это конкретный след действия в цифровой системе, который можно извлечь и интерпретировать. Примеры:

запись в журнале аутентификации;

файл вредоносного загрузчика;

запись о запуске процесса и его командная строка;

DNS-запрос к домену управления (C2, command-and-control).

Источник данных

Источник данных — место, откуда артефакт берется:

хост (диск, журналы ОС, конфиги);

память (RAM);

сеть (PCAP, NetFlow, логи DNS/Proxy/Firewall);

телеметрия EDR/SIEM;

облачные аудиты.

Сбор данных и создание образа

В DFIR важно различать два подхода:

сбор артефактов (collection): точечное изъятие выбранных файлов, логов и записей;

создание образа (imaging): побитовое копирование диска или раздела для полного последующего анализа.

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

Общие правила корректного сбора

Порядок волатильности

Данные исчезают с разной скоростью. Типовая практическая приоритизация:

память и активные соединения;

временные файлы и текущие журналы;

данные на диске и долгоживущие журналы;

централизованные логи (SIEM/EDR/облако), которые обычно живут дольше локальных.

Ориентир по принципам сбора и хранения доказательств: RFC 3227: Guidelines for Evidence Collection and Archiving.

Минимизация изменений

Любой сбор с живой системы меняет ее состояние. Задача не в том, чтобы «не изменить ничего» (это часто невозможно), а в том, чтобы:

минимизировать изменения;

фиксировать, что именно вы делали и какими инструментами;

избегать необратимых действий до сбора критичных данных.

Целостность: хеши

Для крупных артефактов и образов используйте криптографические хеш-суммы (например, SHA-256):

хеш фиксируется сразу после получения данных;

хеш повторно проверяется при копировании/передаче;

хеши попадают в рабочий журнал инцидента и в итоговый отчет.

Документирование и chain of custody

Даже в «корпоративном» расследовании полезно вести учет:

кто собрал данные;

когда (с часовым поясом);

с какого актива;

каким инструментом и версией;

где хранится оригинал и где рабочая копия;

какие хеши у полученных файлов.

Ориентир по интеграции форензики в IR: NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response.

Диск: что собирать и как подходить к изъятию

Когда нужен образ диска, а когда достаточно точечного сбора

Практичное правило:

точечный сбор подходит для быстрого подтверждения компрометации и расширения охвата на множество хостов;

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

Типовые ситуации, когда образ особенно полезен:

подозрение на persistence (закрепление) неясным способом;

расследование инсайдера и файловых действий;

сложная малварь, которая прячет следы;

требования доказательности и повторной проверки.

Основные категории дисковых артефактов

Ниже — категории, которые почти всегда дают результат в реальных инцидентах.

артефакты запуска программ (что и чем запускалось);

артефакты закрепления (службы, автозагрузка, планировщики);

следы выполнения команд и сценариев;

журналы ОС и приложений;

скачанные файлы и временные каталоги;

следы подключения внешних носителей;

конфигурации безопасности и учетные записи.

Windows: типовые артефакты (концептуально)

Важно: конкретные файлы/ключи зависят от версии Windows и настроек аудита, но смысл артефактов стабилен.

журналы событий (входы, создание процессов, изменения служб, задачи планировщика);

артефакты автозапуска (папки автозагрузки, записи конфигурации);

планировщик задач (созданные и измененные задания);

службы и драйверы (установки и изменения);

артефакты использования PowerShell (если включено логирование);

артефакты выполнения программ и открытия файлов (для таймлайна).

Для улучшения видимости до инцидента часто используют Sysmon: Sysmon documentation.

Linux: типовые артефакты (концептуально)

системные журналы (аутентификация, sudo, службы);

cron и systemd-юниты (закрепление и автоматизация);

bash history и аналогичные истории оболочек (с ограничениями);

изменения пользователей, ключей SSH и прав доступа;

артефакты пакетов и установок.

Точечный сбор: практичная стратегия

Чтобы точечный сбор был воспроизводимым и масштабируемым, используйте один подход на всех хостах:

фиксируете окно времени (например, 24 часа вокруг первого подтвержденного события) и явно записываете часовой пояс;

собираете «скелет» (аутентификация, события запуска, сетевые следы, изменения сервисов);

добавляете «мышцы» под гипотезу (например, webshell, RDP, вредоносный архив);

сохраняете структуру каталогов и метаданные файлов там, где это возможно.

Для массового и повторяемого сбора часто применяют агенты сбора артефактов и запросов к хостам:

Velociraptor

osquery

Создание образа: базовые требования

При создании образа диска важны:

работа с копией (оригинал защищается от изменений);

фиксация хешей для полученного образа;

запись параметров (какой диск/раздел, какой метод, какой инструмент);

безопасное хранение (ограничение доступа, резервирование).

Инструменты и подходы различаются по средам, но методологический ориентир по идентификации, сбору и сохранению цифровых доказательств: ISO/IEC 27037 (страница стандарта).

Память: зачем собирать RAM и что в ней искать

Почему память критична

RAM часто содержит то, чего уже нет на диске или в логах:

активные процессы и их параметры запуска;

сетевые соединения и сессии;

внедрения в процессы (process injection);

расшифрованные данные, временные буферы;

следы безфайловой техники (когда вредоносное почти не оставляет файлов).

Главный риск: данные исчезают при перезагрузке, завершении процесса, изоляции или действиях злоумышленника.

Когда память собирать нельзя или опасно

Сбор RAM — это live response (работа на живой системе), и он может:

увеличить нагрузку на сервер;

повлиять на стабильность;

изменить состояние системы.

Поэтому решение должно быть управляемым:

если риск для бизнеса критичен, можно выбрать приоритет восстановления и собрать меньше;

если есть возможность, используйте тестовый прогон на аналогичной системе и заранее проверенный инструмент.

Практика: как организовать сбор памяти

Организационные принципы:

используйте заранее утвержденный инструмент и фиксируйте его версию;

сохраняйте дамп на внешний или сетевой ресурс, который не принадлежит компрометированному хосту;

сразу фиксируйте хеш дампа;

документируйте время начала и окончания сбора.

Два распространенных инструмента для анализа памяти:

Volatility 3

WinPmem (страница проекта)

Что обычно извлекают из дампа памяти

В зависимости от ОС и ситуации, типовые задачи анализа:

перечисление процессов и построение дерева (поиск аномалий в родителях и командных строках);

поиск скрытых или «необычных» модулей/библиотек;

восстановление сетевых соединений и привязка к процессам;

поиск артефактов внедрения и подозрительных областей памяти;

извлечение IOC (домены, IP, строки, пути), с осторожностью к ложным совпадениям.

Важно: выводы по памяти почти всегда требуют корреляции с диском и логами, иначе легко перепутать «шум» и реальную активность.

Сеть: какие данные собирать и как они помогают

Зачем сетевые артефакты

Сетевая плоскость отвечает на ключевые вопросы:

куда и когда ходил хост;

был ли C2;

были ли признаки lateral movement;

есть ли эксфильтрация и ее объем;

какие протоколы и направления были задействованы.

Виды сетевых источников

Полезно понимать различия, потому что «сеть» — это не один тип данных.

| Источник | Что это | Сильная сторона | Ограничение | |---|---|---|---| | DNS-логи | Запросы имен и ответы | Быстро показывает домены и частоту | Не показывает содержимое соединения | | Proxy-логи | HTTP(S) запросы через прокси | URL, user-agent, объемы | Не видит трафик мимо прокси | | Firewall-логи | Разрешения/блокировки | Направления и порты | Мало контекста уровня приложения | | NetFlow/IPFIX | Метаданные потоков | Масштабируемость и объемы | Нет полезной нагрузки | | PCAP | Пакеты (содержимое) | Максимум деталей | Тяжело хранить и анализировать |

PCAP: когда он нужен

PCAP полезен, когда нужно доказательно ответить «что именно передавалось», например:

подтверждение эксфильтрации;

анализ команды и ответов C2;

разбор эксплуатации уязвимости на сетевом уровне.

Но PCAP редко бывает доступен «за весь период». Поэтому практически важнее заранее обеспечить хотя бы DNS/Proxy/Firewall/Flow и уметь быстро включать точечный захват в момент инцидента.

Ориентир по инструменту захвата и анализа пакетов: Wireshark documentation.

Как связывать сеть с хостом

Чтобы сетевые данные превращались в выводы, нужны точки привязки:

IP-адрес к конкретному хосту в конкретный момент времени (учитывайте DHCP);

user/устройство из прокси и VPN;

сопоставление времени событий с учетом часовых поясов и дрейфа;

привязка соединения к процессу (через EDR или анализ памяти).

Типовая ошибка: делать вывод «хост X общался с доменом Y», не проверив, что в этот момент IP действительно принадлежал этому хосту.

Практичный сквозной поток: что собирать в первые часы

Ниже — универсальный шаблон, который хорошо ложится на triage и не ломает доказательность.

Зафиксируйте исходную точку: алерт, время, актив, user, краткое описание.

Снимите «минимум контекста» до containment: процесс/дерево, текущие соединения, ключевые логи вокруг времени события.

Примите решение по containment и задокументируйте причину.

Выполните точечный сбор артефактов с диска по гипотезе.

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

Соберите сетевой след: DNS/Proxy/Firewall/Flow за выбранное окно времени.

Нормализуйте время: сведите источники к единому часовому поясу в рабочем журнале.

Зафиксируйте хеши крупных файлов/дампов/образов и расположение в хранилище.

Частые ошибки при сборе артефактов

сбор «всего подряд» без гипотез и окна времени, после чего анализ тонет в шуме;

перезагрузка до сбора RAM при подозрении на активную малварь;

отсутствие привязки времени и часового пояса в заметках и выгрузках;

отсутствие хешей и понятного учета версий инструментов;

смешивание «сырых данных» и результатов анализа в одном каталоге;

попытка делать окончательные выводы по одному источнику (например, только по диску или только по сети).

Что дальше по курсу

Следующий логичный шаг после правильного сбора — анализ и корреляция:

построение таймлайна из дисковых, хостовых и сетевых артефактов;

выделение TTP злоумышленника и привязка к MITRE ATT&CK;

упаковка результатов в отчет, IOC и улучшения детекций.

Рекомендуемые материалы

NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response

RFC 3227: Guidelines for Evidence Collection and Archiving

ISO/IEC 27037 (страница стандарта)

Sysmon documentation

Velociraptor

osquery

Volatility 3

Wireshark documentation

Аналитика и отчётность: таймлайны, IOC, малвар-анализ и финальный отчет

Как эта тема связана с предыдущими статьями

В предыдущих материалах курса мы выстроили фундамент:

Мы определили цели DFIR, роли, жизненный цикл и требования к доказательной базе.

Мы разобрали подготовку: логирование, инструменты, плейбуки и форензик-гигиену.

Мы прошли практику реагирования: triage, containment, eradication, recovery.

Мы научились корректно собирать артефакты с диска, из памяти и из сети.

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

Ключевые выходные продукты аналитики DFIR:

таймлайн (временная линия событий)

IOC и связанные с ними детекции

результаты малвар-анализа (если есть вредоносные объекты)

финальный отчет и пакет артефактов, который можно передать внутри компании или внешним сторонам

!Общий конвейер: от артефактов к таймлайну, IOC и финальному отчету

От артефактов к выводам: базовый принцип

Артефакты сами по себе еще не являются выводами. Один и тот же артефакт может иметь несколько интерпретаций.

Практичное правило качества:

Факт: то, что напрямую подтверждается конкретными данными (лог, файл, запись EDR) и воспроизводимо.

Интерпретация: объяснение смысла факта (что это означает).

Гипотеза: версия, которая пока не подтверждена достаточным количеством фактов.

Чтобы выводы были устойчивыми, вам нужно:

Нормализовать время и идентификаторы.

Связать события между источниками (корреляция).

Построить таймлайн.

Выделить IOC и техники злоумышленника.

Если есть вредоносные объекты, понять их функциональность (малвар-анализ) и как она связана с таймлайном.

Оформить результаты в отчет под нужные аудитории.

Таймлайны: как собрать последовательность событий

Зачем нужен таймлайн

Таймлайн нужен для того, чтобы ответить на вопросы:

когда началась компрометация (самая ранняя подтвержденная активность)

как злоумышленник вошел (первичный вектор)

что он делал дальше (эскалация, закрепление, lateral movement, эксфильтрация)

когда и почему вы могли это увидеть (пробелы в логировании, детекциях)

Таймлайн в DFIR полезен одновременно для:

технической команды (помогает находить первопричину и масштаб)

руководства (дает ясную историю и оценку ущерба)

улучшения детекций (показывает, где сигналы были, но не сработали)

Нормализация времени и полей

Перед построением таймлайна договоритесь о стандарте:

какое время используете в рабочей аналитике и отчетах: UTC или локальное с обязательным указанием часового пояса

как учитываете расхождения часов (дрейф, неверный NTP)

какие поля являются ключевыми идентификаторами: hostname, user, asset_id, ip, process_guid (если есть в EDR), cloud_account_id

Практика, которая снижает ошибки:

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

Отдельно пометить источники, где время может быть недостоверным.

При корреляции использовать не только время, но и связки полей (например, user + src_ip + device_id).

Минимальная модель события для таймлайна

Чтобы таймлайн был единообразным, используйте общий шаблон строки события.

Рекомендуемые поля:

timestamp (с часовым поясом или уже в UTC)

source (EDR, Windows Event Log, VPN, DNS, proxy, cloud audit)

asset (хост или облачный объект)

actor (учетка, сервисный аккаунт, токен)

action (что произошло: вход, запуск процесса, создание задачи, DNS-запрос)

object (файл, ключ реестра, URL, домен, политика IAM)

evidence_ref (ссылка на конкретный артефакт: имя файла выгрузки, ID события, скрин/экспорт)

confidence (подтверждено или требует проверки)

Пример таймлайна в виде таблицы:

| Время (UTC) | Источник | Актив | Событие | Артефакт | |---|---|---|---|---| | 2026-02-01 08:12:33 | VPN | user: j.ivanov | Успешный вход с нового IP | vpn_logs_2026-02-01.csv:row2141 | | 2026-02-01 08:15:10 | EDR | host: WS-101 | Запуск powershell.exe с подозрительной командной строкой | edr_case_1234:event7781 | | 2026-02-01 08:15:42 | DNS | WS-101 | Запрос домена example-c2.tld | dns_logs.json:line9921 |

Источники для таймлайна и как их связывать

Обычно вы комбинируете:

хостовую телеметрию (EDR, аудит процессов)

логи аутентификации (AD/Azure AD, VPN, SSO)

сетевые логи (DNS/proxy/firewall/flow)

форензические артефакты диска и памяти (если делали сбор)

облачные аудиты (например, действия IAM, создание ключей)

Смысл корреляции:

Начать с точки входа или точки детекта (первый подтвержденный сигнал).

Расширяться в обе стороны по времени.

Делать pivot по сущностям: хост, учетная запись, IP, хэш, домен.

Технический прием: таймлайн как инструмент проверки гипотез

Не пытайтесь сразу написать «красивую историю». Делайте итерации:

Выпишите гипотезу (например, компрометация через фишинг и токен).

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

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

Если данных нет, это отдельный результат: пробел телеметрии.

IOC: как выделять, проверять и превращать в детекции

Что такое IOC и чем он отличается от TTP

IOC (Indicators of Compromise): конкретные наблюдаемые индикаторы, по которым можно находить следы атаки.

TTP (Tactics, Techniques, Procedures): техники и приемы злоумышленника, более устойчивые, чем отдельные хеши или домены.

На практике качественный результат DFIR включает и IOC, и TTP.

Ориентир для классификации техник: MITRE ATT&CK.

Типы IOC

Удобная классификация для работы:

атомарные IOC: хеши файлов, домены, IP, URL, имена файлов

поведенческие IOC: комбинации событий (например, rundll32 с загрузкой из профиля пользователя)

контекстные IOC: user-agent, JA3, имена mutex, шаблоны путей, параметры командной строки

Практическое правило полезности:

атомарные IOC проще блокировать, но они быстро меняются

поведенческие IOC сложнее, но они устойчивее и лучше для детекций

Качество IOC: как не навредить блокировками

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

Проверяйте:

специфичность: IOC точно связан с атакой или он общий (например, публичный CDN)

временные границы: IOC мог быть активен только в конкретный период

уверенность источника: получен ли IOC из вашего расследования или из внешнего фида

наблюдаемость: можете ли вы реально искать этот IOC в ваших логах и инструментах

Превращение IOC в практику: поиск, детекции, блокировки

Три уровня применения IOC:

ретроспективный поиск (threat hunting)

детекция (правила в SIEM/EDR)

превентивная блокировка (proxy, DNS, firewall, EDR)

Не делайте блокировку единственным шагом. Если вы только блокируете, вы часто:

не понимаете масштаб

не находите первопричину

не выявляете, где атакующий уже закрепился

Форматы, которые часто используют для обмена

Выбирайте формат под задачу:

для правил корреляции по логам: Sigma

для поиска вредоносных файлов по сигнатурам: YARA

Пример очень упрощенного Sigma-правила как идеи (его нужно адаптировать под вашу схему логов):

Пример упрощенного YARA-правила как идеи (в реальности требуется тщательная проверка на ложные совпадения):

Малвар-анализ: что именно анализировать и какой глубины достаточно

Когда нужен малвар-анализ

Малвар-анализ нужен, когда у вас есть хотя бы один из объектов:

подозрительный файл (EXE/DLL/script/document)

подозрительная командная строка или загрузка полезной нагрузки

признаки инъекций или безфайловой активности (часто подтверждается памятью или EDR)

Цели малвар-анализа в DFIR обычно практичные:

извлечь IOC (домены, IP, URL, пути, имена задач)

понять функциональность (эксфильтрация, шифрование, удаленное управление)

понять техники закрепления и распространения

связать наблюдения с таймлайном

Уровни анализа: от triage до глубокого разбора

Не всегда нужен реверсинг.

Практичная лестница глубины:

Triage файла

Базовый статический анализ

Динамический анализ в изоляции

Углубленный анализ (дизассемблирование, расшифровка конфигов, протоколов)

Остановиться можно там, где вы уже ответили на ваши вопросы расследования.

Triage и базовый статический анализ

Задачи, которые обычно дают быстрый эффект:

Зафиксировать криптографические хеши SHA-256 и размер файла.

Определить тип файла и упаковку (упакован ли он).

Извлечь строки, домены, пути, имена мьютексов (с осторожностью).

Посмотреть метаданные, подпись, дату компиляции (помня, что их легко подделать).

Инструменты, которые часто используют на этом уровне:

Detect It Easy (DIE)

Ghidra

capa

Динамический анализ

Динамический анализ отвечает на вопрос: что делает объект при запуске.

Правила безопасности:

только изолированная среда

контроль сети или эмуляция

сбор артефактов исполнения (процессы, файловые операции, реестр, сеть)

Типовые результаты:

домены и адреса C2

создаваемые файлы и ключи автозапуска

запускаемые команды

попытки отключить защиту или стереть логи

Связь с MITRE ATT&CK

После того как вы поняли поведение, привяжите его к техникам.

Это полезно, потому что:

техники устойчивее хешей

на техники легче строить детекции и хантинг

руководство лучше понимает картину, если описывать действия как сценарий

Ориентир: MITRE ATT&CK.

Корреляция: как связывать таймлайн, IOC и малварь

Типовой цикл корреляции выглядит так:

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

Для каждого узла формируете список подтверждающих артефактов.

Из артефактов извлекаете IOC.

Проверяете IOC ретроспективно по среде, чтобы оценить масштаб.

Если найден вредоносный объект, проверяете, как его поведение объясняет события таймлайна.

Ключевой принцип качества:

не делайте финальный вывод по одному источнику, если есть возможность подтвердить вторым

Пример:

EDR показал запуск powershell.exe с подозрительной строкой

DNS логи подтвердили резолв домена в то же окно времени

proxy показал объем скачанного ответа

Вместе это сильнее, чем любой источник отдельно.

Финальный отчет: как оформить результаты так, чтобы ими можно было пользоваться

Для кого пишется отчет

Отчет почти всегда читают разные аудитории:

техническая команда (нужны детали, артефакты, шаги)

владельцы систем и ИТ-операции (нужны изменения, план восстановления)

руководство (нужна короткая ясная картина, ущерб, риски)

юристы и комплаенс (нужны факты, даты, объем затронутых данных, аккуратная формулировка)

Это означает, что отчет должен иметь слои: короткое резюме и технические приложения.

Структура отчета, которая обычно работает

Ниже практичный каркас.

Резюме для руководства

Контекст инцидента

Что подтверждено фактами

Таймлайн

Масштаб и затронутые активы

Первопричина и сценарий атаки

Containment, eradication, recovery: что сделано

Оценка воздействия

IOC, TTP и детекции

Рекомендации и план улучшений

Приложения

!Рекомендуемая структура финального DFIR-отчета

Факты, допущения и ограничения

В отчете всегда разделяйте:

факты: подтвержденные события с ссылками на артефакты

допущения: что вы предполагаете из-за отсутствия телеметрии

ограничения: какие источники недоступны, какая ретенция логов, какие системы не вошли в scope

Это повышает доверие к отчету и снижает риск неверных управленческих решений.

IOC-пакет как отдельный артефакт

Не прячьте IOC только внутри отчета. Практичнее делать отдельный пакет:

таблица IOC с полями: тип, значение, где найден, время, уверенность, рекомендации по применению

готовые запросы для SIEM (если это принято в вашей организации)

предложения по правилам детекции (например, Sigma) и по поисковым запросам

Приложения и воспроизводимость

В приложениях обычно размещают:

список экспортов и образов, их хеши, где хранятся

ключевые выгрузки логов (или ссылки на них)

список выполненных команд и действий (из incident log)

ссылки на кейсы EDR/тикеты

Ориентир по тому, как интегрировать форензические техники в IR и оформлять результаты: NIST SP 800-86.

Ориентир по общему процессу реагирования и коммуникациям: NIST SP 800-61 Rev. 2.

Практический результат после отчета: закрыть цикл

Отчет завершает инцидент формально, но DFIR-цикл закрывается, когда сделаны улучшения.

Минимальный набор действий после финализации:

Превратить находки в изменения

Проверить, что изменения внедрены

Убедиться, что детекции покрывают выявленные техники

Примеры типовых улучшений:

включить или расширить аудит (например, создание процессов, PowerShell логирование)

увеличить ретенцию критичных логов

добавить детекции в SIEM по поведенческим признакам

пересмотреть права привилегированных учетных записей

обновить плейбуки и чеклисты сбора

Частые ошибки в аналитике и отчетности

смешивание фактов и гипотез, из-за чего отчет становится спорным

таймлайн без указания часового пояса и без ссылок на источники

IOC без контекста, что приводит к ложным блокировкам

попытка компенсировать отсутствие телеметрии уверенными формулировками

отсутствие пакета приложений, из-за чего выводы трудно проверить

Что дальше

Если предыдущие статьи учили вас правильно действовать и правильно собирать данные, то эта статья дала модель, как превращать данные в результаты.

В практической работе DFIR эти навыки используются в каждом инциденте: от первичного triage до финального отчета и improvements.