DFIR: цифровая криминалистика и реагирование на инциденты (Windows, macOS, Linux, Cloud, SaaS)

1. Что такое DFIR: цели, роли, процесс, юридические основы и chain of custody

Что такое DFIR: цели, роли, процесс, юридические основы и chain of custody

DFIR (Digital Forensics and Incident Response) — это дисциплина на стыке реагирования на инциденты и цифровой криминалистики. На практике DFIR отвечает на два главных вопроса:

Что произошло и происходит прямо сейчас? (Incident Response)

Что именно произошло, как это доказать и как это корректно задокументировать? (Digital Forensics)

DFIR применяется в корпоративной безопасности, расследованиях нарушений, антифроде, внутреннем контроле, а также при взаимодействии с регуляторами и правоохранительными органами. В контексте этого курса DFIR охватывает Windows, macOS, Linux, а также Cloud и SaaS, потому что реальные инциденты почти всегда затрагивают гибридную инфраструктуру.

Зачем нужен DFIR

DFIR нужен не только “чтобы найти хакера”. Его задачи шире и прагматичнее.

Сокращение ущерба: быстро локализовать атаку, остановить распространение и утечку.

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

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

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

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

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

Важно: DFIR — это не набор инструментов. Это процесс, роль, ответственность и качество доказательств.

IR и Forensics: что общее и чем отличаются

IR и криминалистика часто конфликтуют по приоритетам:

IR стремится быстро остановить инцидент.

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

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

Классическая дилемма:

Перезагрузить сервер, чтобы “помогло”, или сначала снять память и собрать volatile-данные.

> “Collect evidence in order of volatility.” — принцип “собирать доказательства в порядке убывания летучести” из RFC 3227: Guidelines for Evidence Collection and Archiving

Типичные результаты работы DFIR

Результат DFIR — это не только отчёт. Обычно это набор артефактов и решений.

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

Список затронутых активов: системы, учётные записи, ключи, токены, данные.

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

IOCs и TTPs: индикаторы компрометации и тактики/техники атакующего.

Рекомендации: немедленные меры и долгосрочные изменения.

Набор доказательств: образы, дампы, логи, экспорт из облака, chain of custody.

Роли в DFIR и зоны ответственности

В зрелой организации DFIR — командная работа. Ниже — типовые роли (в малых компаниях один человек может совмещать несколько).

| Роль | Основная ответственность | Риск при отсутствии роли | |---|---|---| | Incident Commander / IR-менеджер | Координация, приоритеты, коммуникации, принятие решений | Хаос, противоречивые действия, потеря времени | | DFIR-аналитик (forensic analyst) | Сбор и анализ артефактов, доказательность, отчёт | Потеря следов, недоказуемые выводы | | IR-инженер / SOC аналитик | Детекция, triage, containment, работа с EDR/SIEM | Дольше живёт атакующий, больше ущерб | | Threat hunter | Поиск скрытой активности, расширение области поиска | Пропуск второй точки входа | | Malware analyst | Разбор вредоносного кода, механизмы персистентности | Не удалили истинную причину, повторная компрометация | | Cloud / SaaS security инженер | Сбор и анализ облачных и SaaS-логов, оценка IAM | Потеря данных из-за коротких ретеншн-сроков логов | | IT/Platform/AD администратор | Технические действия: изоляция, восстановление, доступы | Невозможность быстро выполнить меры | | Legal / Compliance | Риски, уведомления, требования регуляторов, удержание данных | Нарушение закона, штрафы, неверные формулировки | | HR | Инциденты с инсайдерами, дисциплинарные процессы | Неверное оформление, трудовые риски | | PR / Communications | Публичные заявления, коммуникация с клиентами | Репутационный ущерб из-за неверных сообщений |

Процесс DFIR: от сигнала до постмортема

Практично мыслить процессом, который объединяет IR и forensics.

!Диаграмма показывает, как IR и криминалистика идут параллельно и где важны сохранение доказательств и документы

Подготовка

Подготовка определяет, будет ли DFIR “управляемым” или превратится в импровизацию.

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

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

Инструменты: EDR, SIEM, сбор артефактов, форензик-набор, безопасное хранилище доказательств.

Доступы: “break glass” учётные записи, процедура экстренного доступа.

Тренировки: tabletop и технические учения.

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

Обнаружение и triage

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

Цели triage:

понять, инцидент это или ложное срабатывание;

оценить масштаб;

определить критичность;

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

Ключевая практика: фиксировать исходные условия.

текущее время и часовой пояс, источник сигнала;

какие системы затронуты;

какие действия уже предприняты.

Сдерживание (containment)

Сдерживание должно быть быстрым, но аккуратным.

Варианты:

изоляция хоста в EDR;

блокировка учётной записи или токена;

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

временный запрет опасного механизма (например, внешние OAuth-приложения).

Риск: сдерживание может “спугнуть” атакующего и привести к удалению следов. Поэтому часто сначала собирают летучие данные, а затем изолируют.

Сбор и сохранение доказательств (preservation + collection)

В DFIR часто разделяют:

preservation — обеспечить неизменность и целостность;

collection — физически/логически собрать данные.

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

Endpoint: память, диск, журналы ОС, артефакты приложений.

Сеть: netflow, прокси, DNS, VPN, firewall.

Identity: AD/AAD, журналы входов, MFA, изменения ролей.

Cloud: audit-логи, события API, конфигурации, снапшоты.

SaaS: журналы админ-действий, почта, файлы, шаринги.

Основные правила:

минимизировать изменения на системе-источнике;

документировать каждый шаг;

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

Исследование и анализ

На этой стадии данные превращаются в ответы.

корреляция событий (кто, что, когда, откуда);

построение таймлайна;

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

поиск расширения компрометации (lateral movement);

проверка гипотез и “опровержение альтернатив”.

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

Устранение и восстановление

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

закрытие уязвимости или отключение опасной конфигурации;

ротация секретов (пароли, ключи, токены, сертификаты);

пересоздание доверенных систем (при необходимости — rebuild);

повышение мониторинга на период наблюдения.

Важно различать:

восстановить работоспособность;

восстановить доверие.

Система может “работать”, но быть всё ещё подконтрольной атакующему.

Пост-инцидент (lessons learned)

На этом этапе формируется эффект “инцидент сделал нас сильнее”, а не “нам просто повезло”.

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

обновление плейбуков;

улучшение логирования и ретеншн-сроков;

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

Рекомендованный базовый стандарт процесса IR: NIST SP 800-61 Revision 2: Computer Security Incident Handling Guide

Для связки IR и криминалистики полезен: NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response

Юридические основы: что важно знать DFIR-специалисту

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

Ниже — практические принципы (они не заменяют консультацию юриста).

Законность доступа и минимизация

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

собирать нужно только необходимое для цели расследования;

доступ должен быть ограничен кругом лиц (need-to-know).

Персональные данные и приватность

Если вы работаете в юрисдикциях с GDPR, важны принципы:

законное основание обработки;

минимизация и ограничение цели;

контроль доступа;

сроки хранения;

защита данных.

Официальный текст: General Data Protection Regulation (GDPR)

Трудовые и внутренние расследования

Если инцидент связан с инсайдером:

действуйте через утверждённые процедуры HR и безопасности;

избегайте “самодеятельных” обысков личных устройств;

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

Взаимодействие с регуляторами и правоохранительными органами

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

соблюдайте сроки уведомлений (если применимо);

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

Что чаще всего ломает юридическую пригодность материалов

отсутствие chain of custody;

нет фиксации времени и часового пояса;

непонятно, кто и как получил данные;

оригиналы перезаписаны;

логов нет или они “подправлены” без следа;

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

Chain of custody: цепочка хранения доказательств

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

является тем же самым, что был изъят;

не изменялся (или изменения контролируемы и объяснимы);

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

Chain of custody — это не бюрократия ради бюрократии. Это ваша защита, если выводы будут оспариваться.

Что считается доказательством в DFIR

образ диска, раздела, тома;

дамп памяти;

экспорт логов (включая Cloud/SaaS);

копия артефактов (реестр, файлы, базы);

снимки конфигураций;

пакеты сетевого трафика;

скриншоты и фото (хуже по доказательности, но иногда полезны).

Базовые элементы chain of custody

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

| Поле | Пример | Зачем нужно | |---|---|---| | Идентификатор доказательства | EVID-2026-0007 | Однозначная ссылка в отчёте | | Описание | “Дамп памяти с хоста FIN-WS-12” | Понимание содержимого | | Источник | Имя хоста, аккаунт, сервис | Привязка к системе | | Дата и время изъятия | 2026-02-06 10:41 UTC | Таймлайн и воспроизводимость | | Кто изъял | ФИО, роль | Ответственность | | Метод получения | Инструмент, версия, параметры | Проверяемость процедуры | | Хеш-суммы | SHA-256 | Контроль неизменности | | Место хранения | сейф, защищённое хранилище | Контроль доступа | | Передачи | кому, когда, зачем | Непрерывность цепочки |

Примечание по хешам: на практике часто используют SHA-256, потому что он широко принят и удобен как идентификатор неизменности. Вы фиксируете хеш при получении, а затем сверяете при каждой передаче/копировании.

Практическая процедура: как выглядит “правильно”

Зафиксировать контекст: что изымаем, откуда, по какому основанию, кто разрешил.

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

Сразу посчитать и записать хеш-суммы полученного файла/образа.

Поместить оригинал в защищённое хранилище, работать с копией.

Вести журнал всех действий и передач.

В отчёте ссылаться на идентификаторы доказательств и хеши.

Частые ошибки

хранение доказательств “на рабочем ноутбуке” без контроля;

пересылка через мессенджеры или почту без учёта;

отсутствие хеша или пересчёт хеша без записи причины;

смешивание оригиналов и рабочих копий;

отсутствие синхронизации времени (NTP) и указания часового пояса.

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

Эта статья задаёт фундамент: цели DFIR, роли, процесс, юридическую рамку и chain of custody.

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

какие источники данных и артефакты важны в Windows, macOS и Linux;

как собирать и интерпретировать логи и артефакты в Cloud и SaaS;

как строить таймлайны и проверять гипотезы;

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

2. Сбор данных: live response, образы дисков и памяти, triage, удалённая форензика

Сбор данных: live response, образы дисков и памяти, triage, удалённая форензика

В предыдущей статье мы зафиксировали фундамент DFIR: процесс, юридические ограничения и chain of custody. Эта статья переводит теорию в практику: как именно собирать данные во время инцидента так, чтобы одновременно

помочь реагированию (быстро понять масштаб и остановить ущерб),

не разрушить доказательства,

сохранить воспроизводимость (чтобы выводы можно было проверить).

В DFIR сбор данных почти всегда идёт в условиях ограничений: время, доступы, риск уничтожения следов атакующим, короткая ретеншн логов (особенно в Cloud/SaaS), и необходимость не остановить бизнес.

Базовые понятия: live response, triage, образы и удалённая форензика

Live response — сбор летучих (volatile) данных и быстрых артефактов с работающей системы: процессы, сетевые соединения, содержимое памяти, сессии, токены, временные файлы, актуальные логи. Главный риск live response: вы неизбежно меняете систему (запуская команды и инструменты).

Triage — быстрый сбор минимально достаточного набора данных, чтобы:

подтвердить или опровергнуть факт инцидента,

оценить критичность и масштаб,

решить, нужна ли глубокая форензика (полный образ диска/памяти) и какие системы приоритетны.

Образ диска — побайтовая (или максимально близкая) копия носителя/тома, пригодная для повторного анализа. Бывает физический (целый диск) и логический (только файловая система/выбранные каталоги).

Дамп памяти — снимок оперативной памяти, который помогает найти то, чего на диске может не быть: fileless-активность, внедрённые модули, сетевые артефакты, ключи/токены, следы выполнения.

Удалённая форензика — сбор артефактов без физического доступа: через EDR, агенты, SSH/WinRM, оркестрацию (например, osquery/GRR), облачные API. Плюс: скорость и масштаб. Минус: доверие к агенту/каналу и меньшая «судебная» строгость по сравнению с физическим изъятием.

Ключевой принцип, который связывает всё выше: собирать данные в порядке убывания летучести.

> “Collect evidence in order of volatility.” — принцип из RFC 3227: Guidelines for Evidence Collection and Archiving

Выбор стратегии: что собирать и когда

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

| Ситуация | Приоритет | Что собирать в первую очередь | Почему так | |---|---|---|---| | Подозрение на активного атакующего на хосте | Скорость + летучие данные | Live response + дамп памяти, затем изоляция | Иначе потеряете процессы, соединения, следы в RAM | | Расследование “что было вчера” без признаков активности сейчас | Полнота + доказательность | Образ диска + логи, затем точечный live response | RAM уже не содержит нужного, важнее диск и журналы | | Массовый инцидент (много хостов) | Масштабируемость | Triage на множестве хостов, затем full acquisition на приоритетных | Полные образы всех систем часто нереалистичны | | Cloud/SaaS инцидент | Ретеншн и неизменность | Экспорт audit-логов и конфигураций немедленно | Логи могут быстро «выпасть» по срокам хранения |

!Визуальная карта принятия решений: что делать первым при разных сценариях

Подготовка к сбору: то, что спасает доказательства

Сбор данных почти всегда «ломается» не на инструментах, а на организационных мелочах.

Минимальный набор правил перед началом

Зафиксируйте контекст: кто инициировал сбор, на каком основании, какие системы, какое текущее время и часовой пояс.

Обеспечьте time hygiene: зафиксируйте смещение времени на хосте (если возможно) и используйте UTC в документации.

Ведите журнал действий: команда, время, результат, куда сохранено.

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

Оригиналы защищайте: работайте на копиях, доступ по need-to-know.

Практические ориентиры по интеграции форензики в IR: NIST SP 800-86.

Live response: сбор летучих данных без разрушения картины

Цели live response

быстро понять, что происходит сейчас;

сохранить то, что исчезнет после перезагрузки/остановки процессов;

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

Что обычно собирают (универсально)

Текущее время, часовой пояс, uptime.

Запущенные процессы и их параметры запуска.

Сетевые соединения, открытые порты, ARP/маршруты.

Текущие пользователи и активные сессии.

Планировщики задач и сервисы (как точки персистентности).

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

Важные логи за короткое окно времени (чтобы быстро «зацепиться» за таймлайн).

Windows: что важно в live response

Ключевые источники в моменте:

Список процессов, parent-child связи, командные строки.

Сетевые соединения и связанные процессы.

Активные интерактивные сессии, RDP, локальные токены.

Критичные журналы событий (Security, System, Microsoft-Windows-Sysmon/Operational при наличии, PowerShell/Operational).

Примеры встроенного экспортирования журналов (с фиксацией пути сохранения и последующим хешированием):

Важно: live response на Windows часто делают через EDR или удалённые средства, потому что запуск «левых» бинарников на хосте может быть запрещён политиками, а ручные действия оператора ухудшают воспроизводимость.

Linux: что важно в live response

Текущие процессы, сокеты, systemd units.

История входов и текущие TTY/SSH сессии.

Временные каталоги, cron и systemd timers.

Сетевые настройки, iptables/nftables.

Примеры команд (как иллюстрация типов данных, а не «единственно правильный способ»):

macOS: что важно в live response

Unified Logging (часто главный источник поведения приложений).

LaunchAgents/LaunchDaemons (персистентность), login items.

Сетевые соединения и процессы.

События безопасности, если включены соответствующие механизмы.

Пример точечного извлечения логов:

Ограничения live response

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

Если атакующий мониторит систему, ваши действия могут его «спугнуть».

Для «судебной» строгости live response почти всегда слабее полноценного образа, но выигрывает по скорости.

Дамп памяти: что он даёт и когда обязателен

Зачем нужен дамп памяти

Память часто содержит то, чего нет на диске или что быстро исчезает:

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

артефакты сетевых соединений и контекст процессов;

командные строки, части скриптов, конфигурации;

незаписанные на диск ключи, токены, сессионные данные;

следы fileless-атак.

Когда память собирать в приоритете

есть признаки активной работы атакующего;

вы видите подозрительные процессы/соединения сейчас;

подозрение на fileless, LOLBins, инъекции, руткиты;

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

Практические ограничения

Объём: дампы могут быть большими, нужно место и канал.

Доверие: сбор через агент/EDR проще, но нужно понимать модель доверия.

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

Для последующего анализа памяти широко используют фреймворки типа Volatility 3, но в этой статье фокус именно на корректном сборе.

Образы дисков: физический, логический, снапшоты

Что такое «правильный» образ

В идеале форензический образ должен:

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

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

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

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

Физический образ vs логический сбор

| Подход | Плюсы | Минусы | Когда выбирать | |---|---|---|---| | Физический образ диска | Максимальная полнота, лучше для доказательности | Долго, большой объём, сложнее удалённо | Высокая критичность, судебные перспективы, сложная персистентность | | Образ тома/раздела | Компромисс объёма и полноты | Можно потерять часть артефактов вне тома | Быстрое углубление по важным разделам | | Логический сбор (каталоги/артефакты) | Быстро, удобно массово | Меньше доказательности и полноты | Массовый triage, ограниченные окна, удалённый сбор |

Windows-особенности при сборе диска

VSS (Volume Shadow Copy) может быть источником «прошлых» версий файлов и реестровых ульев.

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

Linux-особенности при сборе диска

Важны метаданные файловой системы (ctime/mtime/atime) и журналирование.

На серверах критичны логи (journald/текстовые), конфиги сервисов, ключи, задания планировщика.

macOS-особенности при сборе диска

Часть данных лежит в базах (например, unified logs), часть в пользовательских каталогах и системных plist.

В корпоративных средах важно учитывать MDM-профили и артефакты управления.

Облако: снапшоты как аналог «образа диска»

В IaaS вы часто не делаете образ «через флешку», а фиксируете состояние через снапшот диска/тома.

AWS: EBS snapshots.

Azure: Managed Disk snapshots.

GCP: Persistent Disk snapshots.

Смысл для DFIR: вы быстро создаёте неизменяемую точку восстановления для анализа, не выключая VM (хотя консистентность файловой системы зависит от конкретного сценария).

Triage: как быстро получить пользу и не утонуть

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

Типовой triage-набор данных

Минимальная идентификация: хост, ОС/версия, пользователь, роль системы.

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

Критичные журналы за окно времени (например, последние 24–72 часа).

Список «точек входа»: почта/браузер/удалённый доступ/CI-CD/облачные ключи.

Копии ключевых артефактов (а не «всё подряд»), чтобы быстро строить таймлайн.

Практика: triage-пакеты часто собирают стандартизированными наборами, чтобы результаты с разных хостов были сопоставимы.

Удалённая форензика: масштаб, но с оговорками

Удалённая форензика — это компромисс между скоростью и строгостью.

Каналы удалённого сбора

EDR-сбор артефактов и удалённые «response actions».

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

Оркестрация форензики в парке хостов: GRR Rapid Response.

Административные протоколы (SSH/WinRM) при наличии контроля и логирования.

Что важно документировать при удалённом сборе

Через что именно собирали (агент/EDR/скрипт), версии и настройки.

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

Где формировались файлы (на хосте или на сервере сбора).

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

Ограничения и риски

Если хост сильно скомпрометирован, агент может быть обманут или отключён.

Не все удалённые методы дадут «бит-в-бит» эквивалент физического образа.

На нестабильных системах удалённые действия могут ухудшить состояние.

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

Cloud и SaaS: сбор данных, пока они не исчезли

В Cloud/SaaS главная угроза доказательствам — не «перезагрузка», а ретеншн и изменения конфигураций.

Что собирать в приоритете в Cloud

Audit/API логи (кто, что, откуда менял):

- AWS CloudTrail: AWS CloudTrail User Guide - Azure Activity Log: Azure Activity log - GCP Cloud Audit Logs: Cloud Audit Logs documentation

Снимки конфигураций и IAM-состояния: роли, политики, ключи, токены, доверенные приложения.

Журналы доступа к данным (например, object storage access logs, если включены).

Снапшоты дисков/VM/контейнерных узлов при необходимости.

Что собирать в приоритете в SaaS

Логи админ-действий и входов.

Историю изменений правил (например, почтовые правила/форварды, политики шаринга).

Артефакты доступа к данным: скачивания, внешние шаринги, OAuth-приложения.

Примеры документации:

Microsoft 365 аудит: Search the audit log

Google Workspace аудит: Audit and investigation tool

Okta системный лог (часто критичен для identity-расследований): Okta System Log API

Практическая рекомендация: если инцидент затрагивает идентификацию (учётки/токены), сбор Cloud/SaaS логов часто должен идти параллельно со сбором с endpoint, а не «после того, как разберёмся с ноутбуком».

Целостность и воспроизводимость: хеши, упаковка, хранение

Что именно хешировать

Любые экспортированные файлы: .evtx, .pcap, *.zip с артефактами, дампы памяти, образы дисков.

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

Что фиксировать рядом с хешем

Алгоритм (например, SHA-256).

Время вычисления и среду.

Путь/имя файла и размер.

Это напрямую поддерживает требования chain of custody из предыдущей статьи: вы должны уметь доказать, что «файл не менялся» между точками передачи.

Частые ошибки при сборе данных

Начать «лечить» систему до фиксации: перезагрузки, удаление файлов, переустановка агента.

Не зафиксировать время/часовой пояс и получить «сломанный» таймлайн.

Собрать слишком много нерелевантного и утонуть в объёмах, не закрыв ключевые гипотезы.

Забыть про Cloud/SaaS ретеншн и потерять audit-логи.

Не разделять оригиналы и рабочие копии.

Не документировать команды и инструменты, из-за чего выводы становятся невоспроизводимыми.

Итог

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

Live response сохраняет летучие следы и помогает действовать быстро.

Дамп памяти критичен при активной атаке и fileless-техниках.

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

Triage и удалённая форензика позволяют масштабироваться и быстро выделять приоритеты.

Cloud/SaaS сбор нужно начинать рано из-за ретеншна и динамики конфигураций.

В следующих материалах курса мы углубимся в конкретные артефакты и методику анализа по платформам (Windows, macOS, Linux) и по доменам (Identity, Cloud, SaaS), чтобы собранные данные превращались в доказуемые выводы и качественный таймлайн.

3. Windows DFIR: артефакты, проверки, Persistence, EDR-следы и скрытые источники

Windows DFIR: артефакты, проверки, Persistence, EDR-следы и скрытые источники

Windows в DFIR встречается чаще всего: рабочие станции, серверы, VDI, терминальные фермы, иногда “jump host” в облаке. Поэтому умение быстро и доказуемо отвечать на вопросы кто/что/когда/как на Windows — базовый навык.

Эта статья логически продолжает предыдущие:

из статьи про процесс, юридические основы и chain of custody берём дисциплину фиксации действий, времени, хешей и прав доступа;

из статьи про сбор данных (live response, triage, образы) берём правильный порядок действий и понимание компромисса между скоростью и строгостью.

Фокус здесь — какие именно Windows-артефакты смотреть, какие проверки делать в triage, где обычно живёт persistence, какие следы оставляют средства защиты/EDR и какие источники часто забывают, хотя они очень информативны.

Карта Windows-артефактов: от вопроса к источнику

В реальном расследовании полезнее мыслить не “списком файлов”, а “вопросом → какие артефакты способны ответить”.

!Карта соответствия типовых вопросов DFIR и ключевых Windows-артефактов

Ниже — практичная таблица соответствий.

| Вопрос расследования | Наиболее полезные артефакты в Windows | Что именно подтверждают | |---|---|---| | Что запускалось на хосте? | Prefetch, Amcache, Shimcache, BAM/DAM, журналы PowerShell, Sysmon (если есть) | Факт выполнения, путь, время, иногда параметры/контекст | | Какая учётка входила и откуда? | Security.evtx (аудит входов), RDP-артефакты, терминальные логи, EDR-аудит | Тип входа, источник, время, иногда целевой хост | | Как закрепились (persistence)? | Scheduled Tasks, Services, Run/RunOnce, WMI subscription, Startup folders, Winlogon, IFEO, COM hijack | Механизм автозапуска и “точка возвращения” атакующего | | Что было скачано/перенесено? | Browser/URL кэши, MOTW (Mark-of-the-Web), BITS, Prefetch/Amcache, архиваторы, логи прокси (вне хоста) | Доставка полезной нагрузки, первичная “точка входа” | | Куда подключались по сети? | Windows Firewall log, DNS Client events, SRUM, Sysmon network events (если есть) | Направления соединений, порты, частота | | Что удалили/почистили? | USN Journal, MFT и MFT (Master File Table) — метаданные файловой системы.

MFT/MFT/$LogFile/BITS/WER) часто спасают расследование при антифорензике.

В следующих материалах курса логично продолжить:

углублением в macOS и Linux артефакты (аналогичные классы, но другие источники);

связкой Windows-хостовых артефактов с Identity (AD/Azure AD), Cloud и SaaS-логами, чтобы строить сквозной таймлайн атаки.

4. macOS и Linux DFIR: артефакты, логи, plist и systemd, нестандартные места следов

macOS и Linux DFIR: артефакты, логи, plist и systemd, нестандартные места следов
После Windows-фокуса из предыдущей статьи важно закрыть вторую половину «endpoint-реальности»: macOS (рабочие станции, иногда build-машины) и Linux (серверы, контейнерные хосты, bastion/jump). Логика та же, что мы закрепили ранее:
процесс и доказательность: фиксируем время, контекст, действия, хеши и chain of custody;

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

не верим одному источнику: подтверждаем гипотезы разными артефактами.
Цель статьи: дать практическую карту артефактов и проверок на macOS и Linux, включая неочевидные места следов, которые часто упускают.
Ментальная модель: вопрос расследования → артефакты
!Карта «вопрос → источники» для macOS и Linux
Ниже — компактная таблица, которая помогает не «тонуть» в файлах, а идти от вопроса.
| Вопрос | macOS: основные источники | Linux: основные источники | |---|---|---| | Кто и как входил? | Unified Logs, сведения о пользователях, SSH/VPN-клиенты, артефакты MDM (если есть) | journalctl, /var/log/auth.log или /var/log/secure, wtmp/btmp, last, sshd логи | | Что выполнялось? | Unified Logs, LaunchServices, Quarantine/Gatekeeper, историю оболочек (если включена), метаданные файлов | journalctl, auditd (если есть), shell history, sudo, package manager logs | | Как закрепились? | launchd (LaunchAgents/LaunchDaemons), Login Items, cron (редко, но встречается), профили конфигурации | systemd units/timers, cron, rc.local/init-скрипты, authorized_keys, LD_PRELOAD, PAM | | Куда ходили по сети? | Unified Logs, артефакты браузеров, DNS-кэш в логах, сетевые конфиги | journalctl, ss, DNS-resolver логи (если включены), firewall логи | | Что удаляли/чистили? | FSEvents, Unified Logs, Spotlight/metadata, таймлайны по файловой системе | journalctl (следы очистки), auditd, метаданные ФС, package logs, следы ротации логов |
Важно: на macOS и Linux часть артефактов сильнее зависит от конфигурации (включён ли audit, как настроен journald, есть ли централизованный сбор). Поэтому triage должен начинаться с вопроса: какие источники в этой среде реально пишутся и сколько хранятся.
Базовая гигиена macOS и Linux DFIR
Перед углублением в артефакты удерживайте три «опоры доказательности».
Время и часовой пояс
1. Фиксируйте текущее время расследователя в UTC. 2. Фиксируйте время на системе и часовой пояс. 3. Отмечайте, какие источники пишут время в локальном формате, а какие в UTC.
Минимальное вмешательство
1. Не «чините» систему до фиксации ключевых артефактов. 2. Если возможно, собирайте удалённо через управляемые средства (EDR/MDM/SSH) с протоколированием действий.
Целостность
1. Экспортированные файлы логов и артефактов сопровождайте SHA-256. 2. Оригиналы отделяйте от рабочих копий.
Ссылки-ориентиры по инструментам логов, которые реально используются в расследованиях:
macOS Unified Logging: Apple Developer Documentation: log

systemd journal: man7.org: journalctl(1)
macOS DFIR: Unified Logs, plist, пользовательские артефакты и персистентность
macOS отличается тем, что многие действия «склеиваются» в Unified Logging и в экосистему артефактов вокруг запуска приложений и политик безопасности.
Unified Logging: главный источник поведения системы
Unified Logs — централизованная система логирования macOS. Для DFIR она полезна тем, что фиксирует широкий спектр событий: запуск процессов, ошибки, сетевые компоненты, безопасность, работу демонов.
Практический принцип: при triage чаще всего нужно быстро вытащить логи за окно времени и затем уточнять запросами.
Примеры команд (как иллюстрация подхода):
Что важно помнить:
объём логов может быть большим, фильтрация по времени и предикатам критична;

часть данных может быть недоступна без повышенных прав;

сбор логов тоже оставляет след, поэтому фиксируйте свои действия.
plist как «язык конфигурации» и следов
plist (Property List) — формат, в котором macOS хранит множество настроек и описаний автозапуска. В DFIR plist важны в двух случаях:
вы ищете персистентность (что запускается само);

вы ищете контекст пользователя и приложений (что настроено и как работало).
Рабочие утилиты:
plutil для проверки/конвертации plist;

чтение через defaults (не всегда идеально для форензики, но удобно в triage).
Примеры:
Персистентность на macOS: launchd и окружение пользователя
Основной механизм автозапуска в macOS — launchd.
Где искать:
системные LaunchDaemons: /Library/LaunchDaemons/

системные LaunchAgents: /Library/LaunchAgents/

пользовательские LaunchAgents: ~/Library/LaunchAgents/
На что смотреть в plist:
Program и ProgramArguments

нестандартные пути

запуск интерпретаторов и «живущих за счёт легитимности» бинарников
Примеры подозрительных паттернов:
запуск из ~/Library/, ~/Public/, ~/Downloads/;

скрытые каталоги и имена, похожие на системные;

запуск bash, zsh, python, perl с непонятным скриптом;

частые перезапуски (аналог watchdog-поведения).
Дополнительные точки автозапуска, которые часто встречаются в инцидентах:
Login Items и фоновые элементы пользователя
1. атакующие любят закрепляться «в профиле», чтобы не трогать системные каталоги.
Конфигурационные профили (в корпоративной среде)
1. профили могут навязать прокси, сертификаты, ограничения и даже «разрешения».
Артефакты загрузки и обходов защиты: Quarantine, Gatekeeper, XProtect
Если initial access был через скачанный файл, один из самых полезных следов — Quarantine (часто связывают с Mark-of-the-Web в Windows по смыслу).
Практический смысл:
подтверждает, что файл пришёл из интернета или внешнего приложения;

даёт контекст происхождения.
Также в macOS есть встроенные механизмы защиты, которые могут оставлять события:
Gatekeeper

XProtect
Официальный обзор встроенных защитных технологий Apple: Apple Platform Security
Пользовательская активность: браузеры, документы, метаданные
На рабочих станциях macOS часто критично восстановить цепочку действий пользователя.
Типовые направления:
Браузеры (Safari/Chrome/Firefox)
1. история, загрузки, кэши, базы SQLite.
Метаданные и индексация
1. Spotlight и связанные метаданные могут помочь найти следы файлов, даже если их перемещали.
Документы и «последние»
1. список недавно открытых документов может подтвердить интерактивное действие.
Ограничение: структура артефактов зависит от версии macOS и настроек приватности, поэтому вместо «одного пути к файлу» полезнее фиксировать принцип: ищем SQLite/кэши/истории в профилях приложений и подтверждаем временем из других источников.
Нестандартные места следов на macOS
Эти источники часто дают прорыв, когда «очевидного» мало.
FSEvents
1. журнал событий файловой системы, полезен для подтверждения массовых изменений (создание/переименование/удаление) в окне времени.
TCC (Transparency, Consent, and Control)
1. система разрешений macOS: кто и когда получал доступ к чувствительным ресурсам (например, к камере/микрофону/контактам/папкам).
Keychain (цепочка ключей)
1. может быть критичным в инцидентах с похищением секретов, но требует особенно строгого доступа и юридической аккуратности.
Важная практическая оговорка: доступ к таким артефактам почти всегда связан с приватностью и политиками компании, поэтому любые действия должны быть заранее легализованы процессом (как мы обсуждали в статье про юридические основы и chain of custody).
macOS triage-чеклист
Зафиксировать контекст
1. версия macOS, роль устройства, пользователь, окно времени.
Быстрое live-состояние
1. активные пользователи и сессии. 2. процессы и родительские связи. 3. сетевые соединения.
Unified Logs
1. экспорт логов за окно времени. 2. точечные фильтры по ключевым процессам и событиям.
Персистентность
1. LaunchAgents/LaunchDaemons (системные и пользовательские). 2. Login Items и фоновые компоненты. 3. профили конфигурации (если применимо).
Следы доставки
1. Quarantine/Gatekeeper-сигналы. 2. артефакты браузера: загрузки и запуск.
Linux DFIR: journald, auth, systemd и «скрытые» точки закрепления
Linux-среды очень неоднородны: разные дистрибутивы, разные лог-стэки, разные политики. Но на практике почти всегда встречаются три «якоря»:
журналы systemd-journald или текстовые логи в /var/log/;

аутентификация и привилегии (SSH, sudo, PAM);

персистентность через systemd и cron.
Логи в Linux: journald и классические файлы
Если используется systemd, базовый вход в расследование — journalctl.
Примеры:
Документация: man7.org: systemd-journald.service(8)
Классические файлы логов зависят от дистрибутива:
Debian/Ubuntu часто: /var/log/auth.log

RHEL/CentOS часто: /var/log/secure
Что искать в контексте доступа:
успешные и неуспешные SSH-логины;

использование sudo;

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

изменения ключей SSH.
Артефакты интерактивной активности
На Linux важна честная оговорка: shell history ненадёжна как единственный источник.
Причины:
историю можно отключить, чистить, не записывать через неинтерактивные оболочки;

команды могли выполняться через скрипты или удалённые оркестраторы.
Но она полезна как подсказка, если подтверждать другими источниками.
Типовые места:
~/.bash_history

~/.zsh_history
Сопутствующие следы:
sudo логи (часто лучше истории);

journalctl по sshd и по сервисам.
Персистентность на Linux: systemd, cron и неочевидные механизмы
В современных дистрибутивах ключевой механизм автозапуска — systemd.
!Карта основных точек закрепления на Linux
Что проверять в systemd:
System-wide units
1. новые или изменённые файлы в /etc/systemd/system/. 2. подозрительные ExecStart.
Drop-in overrides
1. каталоги вида имя.service.d/ с override.conf. 2. это популярный «тихий» способ изменить поведение легитимного сервиса.
Timers
1. регулярный запуск полезной нагрузки по расписанию.
User units
1. автозапуск в контексте пользователя, часто упускается при серверных расследованиях.
Cron как классика:
/etc/crontab

/etc/cron.d/

/etc/cron.hourly/, /etc/cron.daily/ и другие

пользовательские crontab (часто в /var/spool/cron/)
Неочевидные, но очень важные механизмы закрепления:
~/.ssh/authorized_keys
1. добавленные ключи дают стабильный доступ без пароля.
/etc/ld.so.preload
1. позволяет подгружать библиотеку в процессы и использоваться для скрытого перехвата.
PAM-конфигурация
1. изменения в /etc/pam.d/ могут дать бэкдор или перехват аутентификации.
Модули ядра и автозагрузка
1. каталоги /etc/modules-load.d/ и связанные настройки.
Пакетный менеджер и следы установки
Для Linux-серверов часто критично понять: что устанавливали и когда.
Источники зависят от дистрибутива:
Debian/Ubuntu: /var/log/dpkg.log, /var/log/apt/history.log

RHEL-подобные: yum/dnf логи (пути зависят от версии и настроек)
Это помогает подтвердить:
появление новых утилит (например, туннелирование, сканеры, компиляторы);

обновления, совпавшие по времени с инцидентом.
Нестандартные места следов на Linux
Временные каталоги и in-memory исполнение
1. /tmp, /var/tmp, /dev/shm часто используются для «быстрых» дропов и fileless-подходов.
Логи ротации и «дыры» во времени
1. следы logrotate, пустые окна, неожиданные обнуления.
Скрытые изменения конфигов
1. маленькие правки в существующих сервисах и конфигурациях часто опаснее, чем новые файлы.
Linux triage-чеклист
Контекст
1. дистрибутив, роль сервера, окно времени, кто имеет доступ.
Live-состояние
1. текущие пользователи и сессии. 2. процессы. 3. сетевые соединения.
Логи
1. journalctl за окно времени. 2. auth.log или secure. 3. sudo события.
Персистентность
1. новые systemd units и overrides. 2. timers. 3. cron. 4. authorized_keys. 5. ld.so.preload и PAM.
Установка и изменения
1. логи пакетного менеджера. 2. изменения конфигов ключевых сервисов (SSH, веб-сервер, агенты).
Как связывать endpoint-артефакты с дальнейшими доменами курса
Эта статья закрывает endpoint-плоскость для macOS и Linux так же, как предыдущая закрывала Windows. Но в реальных инцидентах ответы часто находятся на стыке:
endpoint артефакты показывают что происходило на машине;

identity (AD/Azure AD/Okta) показывает чья это была сессия и откуда она пришла;

cloud и SaaS показывают какие данные и через какие API были затронуты.
Поэтому практическая цель triage на macOS/Linux — быстро получить:
признаки initial access,

механизм выполнения,

точки персистентности,

временную опору для расширения поиска в централизованных логах.
Итог
На macOS ключевой источник поведения — Unified Logs, а ключевой язык конфигурации и автозапуска — plist и launchd.

На Linux расследование обычно держится на journalctl и логах аутентификации, а персистентность чаще всего реализуется через systemd units/timers, cron, SSH-ключи и «неочевидные» механизмы вроде LD_PRELOAD и PAM.

«Малоизвестные» и недооценённые источники (FSEvents, TCC, overrides systemd, ld.so.preload) часто дают решающие подтверждения, особенно если атакующий чистил очевидные следы.
Дальше по плану курса логично связывать endpoint-картину с расследованием по Identity, Cloud и SaaS и строить сквозные таймлайны атаки на гибридной инфраструктуре.

5. Cloud и SaaS DFIR: журналы, IAM, форензика API, M365/Google/AWS/Azure и отчётность

Cloud и SaaS DFIR: журналы, IAM, форензика API, M365/Google/AWS/Azure и отчётность
В предыдущих статьях курса мы разобрали фундамент DFIR (процесс, юридические основы, chain of custody) и практику сбора данных на endpoint (Windows/macOS/Linux). В гибридных инцидентах этого недостаточно: атакующий всё чаще действует через облачные API, учётные записи, токены и SaaS-конфигурации, оставляя следы не на диске, а в аудит-журналах облака и SaaS.
Цель этой статьи: дать рабочую карту Cloud/SaaS DFIR, чтобы вы могли быстро и доказуемо ответить на вопросы:
Кто (какая идентичность) совершал действия?

Что именно делали (какие API/админ-операции/доступ к данным)?

Откуда (IP, приложение, устройство, география)?

Когда (корректное время, часовой пояс, корреляция с endpoint)?

Какие артефакты сохранить, пока не истёк срок хранения?
Базовые понятия Cloud/SaaS DFIR
Чтобы не возникало неизвестных терминов, зафиксируем минимальный словарь.
IAM (Identity and Access Management) — система управления идентичностями и правами доступа: пользователи, группы, роли, политики, сервисные учётные записи.

Audit log (журнал аудита) — записи о действиях в админ-плоскости: кто менял конфигурации, создавал ключи, назначал роли, выполнял операции через API.

Sign-in log (журналы входов) — события аутентификации: успешные/неуспешные входы, MFA, условный доступ, IP, клиент.

API forensics (форензика API) — восстановление действий атакующего по событиям управления и доступа, которые фиксируются при вызовах API.

Токен — строка, представляющая право доступа (например, OAuth access token). Важно: токен может давать доступ без повторного ввода пароля.

OAuth/OIDC/SAML — протоколы, через которые приложения получают доступ к ресурсам от имени пользователя или сервиса.
Практическая разница, важная для DFIR:
компрометация пароля решается сменой пароля;

компрометация токена/ключа/приложения OAuth может сохранять доступ даже после смены пароля, пока токены не отозваны и приложение не отключено.
Что ломает Cloud/SaaS расследования чаще всего
Ретеншн логов
1. многие журналы хранятся ограниченное время по умолчанию; 2. если вы не выгрузили их сразу, вы теряете доказательства.
Отсутствие нужного класса логов
1. в AWS, например, CloudTrail может писать только management events, но не data events (доступ к объектам); 2. в SaaS аудит может быть отключён или ограничен лицензией.
Смена плоскости атаки
1. атакующий может действовать через OAuth-приложение, сервисную учётку или временные STS-сессии; 2. на endpoint это может почти не отражаться.
Плохая временная гигиена
1. разные источники пишут время в разных форматах; 2. без нормализации в UTC таймлайн будет противоречивым.
Карта источников: где искать ответы в Cloud и SaaS
!Карта, связывающая облачные и SaaS-логи с вопросами расследования и доказательностью
Ниже — практичная таблица вопрос → источники, применимая почти в любой платформе.
| Вопрос расследования | Наиболее полезные источники | Что подтверждают | |---|---|---| | Кто получил доступ? | Sign-in logs, MFA/Conditional Access события, IAM changes | Учётка, метод входа, IP, устройство/клиент, риск-события | | Какие права получили? | Audit logs по IAM: роли, политики, привилегии, consent | Эскалация привилегий, выдача ролей, создание ключей | | Какие действия делали через API? | Control plane audit (CloudTrail/Activity Log/GCP Audit), SaaS admin audit | Создание/изменение ресурсов, отключение логирования, изменение сетей | | Был ли доступ к данным? | Data plane логи (S3 data events, M365 file access, Google Drive audit) | Чтение/скачивание/экспорт данных | | Чем закрепились? | OAuth apps, ключи API, refresh tokens, service principals, новые федерации | Долгий доступ без пароля, обход MFA | | Пытались ли скрыться? | События удаления логов, изменения ретеншна, отключение CloudTrail/audit | Антифорензика в облаке |
Сбор доказательств в Cloud/SaaS: как делать “правильно”
Связь с предыдущими статьями курса прямая: здесь те же принципы chain of custody, только “носителем” часто выступает экспорт JSON/CSV или снимок конфигурации.
Что сохранять в первую очередь
Журналы входов и IAM-изменений за окно инцидента

Журналы админ-действий (control plane)

Журналы доступа к данным (data plane), если они включены

Снимки конфигураций
1. текущие роли/права; 2. список приложений OAuth и выданных разрешений; 3. активные ключи, токены, федерации; 4. правила почты/форвардинга, настройки шаринга.
Как упаковывать и документировать
Экспортируйте логи в исходном формате, который предоставляет платформа

Зафиксируйте контекст
1. кто экспортировал; 2. из какого интерфейса или API; 3. какой фильтр по времени; 4. какая учётка и права использовались.
Посчитайте SHA-256 для каждого файла и для архива-контейнера

Внесите файлы в реестр доказательств (идентификатор, время, хеш, место хранения)
Примечание: в cloud-расследованиях особенно важно фиксировать точные параметры выборки, иначе позже нельзя доказать, что вы не “вырезали неудобные события”.
IAM DFIR: что проверять при компрометации учёток и ролей
IAM — это “нервная система” облака и SaaS. В большинстве серьёзных инцидентов первопричина или закрепление связаны с идентичностью.
Типовые сценарии атак и их следы
Компрометация пользователя
1. аномальные входы (новая география, новый клиент, необычное время); 2. серия неуспешных попыток, затем успех; 3. отключение или обход MFA.
Эскалация привилегий
1. назначение админ-ролей; 2. изменение политик/ролей; 3. добавление доверия (federation) или сервисных принципалов.
Закрепление через токены и приложения
1. выдача consent OAuth-приложению с широкими правами; 2. создание/ротация API-ключей; 3. выпуск долгоживущих refresh tokens.
Часто забываемые проверки (то, что многие называют “малоизвестным”, но на практике критично)
Проверка OAuth-приложений и выданных разрешений
1. особенно опасны разрешения уровня чтения почты/файлов и управление пользователями; 2. закрепление через OAuth часто переживает смену пароля.
Проверка временных ролей и “assume role”
1. в облаках распространены временные сессии, которые выглядят “как будто это не пользователь”, а роль.
Проверка изменений логирования
1. отключение аудита, сокращение ретеншна, удаление trail или workspace audit.
Форензика API: как мыслить “действиями”, а не “ресурсами”
API forensics в облаке строится вокруг трёх осей.
Идентичность
1. пользователь, сервисная учётка, роль, приложение OAuth.
Действие
1. какое API/операция выполнены: создание ключа, изменение правил, экспорт данных.
Контекст
1. источник: IP, user-agent/клиент, region, device, authentication context.
Практический подход к анализу:
Выделить “верхнюю точку” по сигналу
1. конкретный пользователь, IP, приложение, ресурс.
Построить цепочку действий вокруг неё
1. что было за 1–24 часа до события; 2. какие IAM-изменения произошли сразу после.
Проверить антифорензику
1. изменения настроек аудита; 2. удаление логов или отключение источников.
Сопоставить с endpoint и сетью
1. IP-адреса и временные окна коррелировать с VPN/Proxy/EDR.
AWS DFIR: CloudTrail, IAM и data plane
Ключевые источники в AWS
AWS CloudTrail
1. основной аудит API для management events; 2. умеет писать в S3 и/или CloudWatch Logs.
CloudTrail Data Events
1. события доступа к данным (например, объектам S3); 2. часто не включены из-за стоимости, но при утечках становятся решающими.
AWS Config
1. история конфигураций ресурсов и изменений; 2. удобен для доказуемого “что и когда изменили”.
VPC Flow Logs
1. сетевые потоки на уровне VPC/ENI; 2. полезно для подтверждения сетевой активности.
GuardDuty
1. детекты и находки по подозрительной активности.
Документация:
AWS CloudTrail User Guide

CloudTrail data events

AWS Config Developer Guide

VPC Flow Logs

Amazon GuardDuty User Guide
AWS IAM: что проверять
CreateAccessKey, UpdateAccessKey, DeleteAccessKey

CreateUser, CreateLoginProfile, AttachUserPolicy, PutUserPolicy

AssumeRole и изменения trust policy (частый путь закрепления)

Изменения в CloudTrail и S3 bucket policy (антифорензика и эксфиль)
Типовые “красные флаги” в CloudTrail
API-вызовы из нетипичных регионов или IP

Серии “enumeration” действий
1. List, Describe, Get* по множеству сервисов
Массовое отключение защит
1. изменения security groups, выключение логов, изменение KMS/ключей
Azure DFIR: Activity Log, Entra ID и диагностические логи
В Azure важно разделять:
Azure control plane (управление ресурсами подписки) → Activity Log

Entra ID (Azure AD) identity plane → sign-in и audit logs

Data plane конкретных сервисов → diagnostic settings и ресурсные логи
Azure Activity Log
фиксирует операции управления ресурсами в подписке.
Документация:
Azure Activity log
Entra ID (Azure AD): sign-in logs и audit logs
Sign-in logs
1. кто входил, откуда, через какой клиент; 2. MFA и условный доступ (Conditional Access), если настроены.
Audit logs
1. изменения пользователей, групп, приложений, ролей; 2. действия администраторов.
Документация:
Sign-in logs in Microsoft Entra ID

Audit logs in Microsoft Entra ID
Часто упускаемые проверки в Entra ID
Изменения в App registrations и Service principals
1. добавление секретов/сертификатов; 2. назначение приложению ролей и API permissions.
События consent OAuth-приложениям
1. особенно dangerous: широкие разрешения к почте, файлам, каталогу.
Изменения Conditional Access
1. отключение требований MFA или исключения для конкретных пользователей.
Microsoft 365 DFIR: Unified Audit Log, Exchange, SharePoint/OneDrive
M365 часто является центральной точкой инцидента: почта как initial access, OneDrive/SharePoint как канал утечки, Teams как канал коммуникации.
Базовые источники в M365
Microsoft Purview Audit (Unified Audit Log)
1. единый аудит по множеству сервисов M365.
Exchange Online
1. правила почты (inbox rules), форвардинг, делегаты; 2. mailbox audit (если включён в вашем тенанте и для нужных действий).
SharePoint/OneDrive
1. доступ к файлам, скачивания, внешние шаринги (в зависимости от настроек аудита).
Документация:
Search the audit log

Set up mailbox auditing
M365: что проверять в первую очередь
Initial access через почту
1. входы в Entra ID пользователя (в связке с M365); 2. подозрительные операции MailboxLogin и связанные события аудита (если доступны); 3. открытие/скачивание вложений на endpoint (связка с предыдущими статьями курса).
Закрепление в почте
1. правила форвардинга и скрытые inbox rules; 2. добавление новых делегатов и прав доступа к ящику.
Закрепление через OAuth
1. приложения с разрешениями Mail.Read, Mail.ReadWrite, доступ к файлам; 2. новый или редкий consent в момент инцидента.
Утечка данных
1. массовые скачивания из OneDrive/SharePoint; 2. создание внешних ссылок; 3. изменения политик шаринга.
“Нестандартные” места следов в M365
Изменения настроек аудита и удержания
1. попытки сократить окно видимости.
История изменений политик доступа (например, условного доступа и исключений)

Взаимосвязь “почта → OAuth → файлы”
1. атакующий может почти не трогать пароль, а получить доступ через приложение.
Google Workspace DFIR: Admin audit, Gmail и Drive
Google Workspace расследуется похожим образом: входы, админ-действия, доступ к данным, приложения OAuth.
Ключевые источники
Reports API и журналы Admin console
1. события входов, админ-действий, активности сервисов.
Gmail
1. правила пересылки/маршрутизации, делегаты; 2. подозрительные логины.
Google Drive
1. внешние шаринги, скачивания, массовые изменения.
Документация:
Google Workspace Admin: Audit and investigation

Admin SDK Reports API
Часто упускаемые проверки в Google Workspace
OAuth-приложения и сторонние доступы
1. кто выдал доступ приложению; 2. какие scopes получены.
Изменения настроек шаринга Drive
1. расширение внешнего доступа ради эксфиля.
Правила Gmail
1. скрытая пересылка и авто-архивирование писем.
Как связать Cloud/SaaS и endpoint в один таймлайн
В предыдущих статьях мы разбирали, как на endpoint искать execution, persistence и user activity. В гибридном расследовании типовой “сквозной” таймлайн выглядит так.
Событие входа в IAM (Entra ID / Google / AWS federation)

Изменение прав или выдача OAuth-consent

Действия в SaaS (почта, файлы, админ-панель)

При необходимости — действие на endpoint
1. запуск вложения; 2. токен-краже (иногда признаки видны только на устройстве); 3. установке агента/скрипта.
Практическое правило корреляции: выбирайте один “якорь времени” (обычно UTC), а затем приводите к нему времена из всех источников.
Отчётность по Cloud/SaaS инциденту: что должно быть в результате
Хороший DFIR-отчёт по облаку и SaaS должен быть полезен одновременно:
инженерам (что исправлять),

менеджменту (масштаб и риск),

юристам/комплаенсу (доказуемость).
Рекомендуемая структура отчёта
Executive summary
1. что произошло; 2. бизнес-эффект; 3. текущий статус.
Scope и ограничения
1. какие тенанты/подписки/домены; 2. какой период; 3. какие логи недоступны и почему.
Таймлайн
1. таблица событий с источником (лог), временем (UTC), субъектом (identity), действием (API/операция).
Доказательства и методика
1. какие журналы экспортированы; 2. как обеспечивалась целостность; 3. реестр доказательств (ID, хеш, место хранения).
Технические выводы
1. initial access; 2. privilege escalation; 3. persistence; 4. data access/exfil.
Рекомендации
1. немедленные меры; 2. долгосрочные улучшения (логирование, ретеншн, контроль OAuth, алерты).
Итог
Cloud/SaaS DFIR почти всегда упирается в ретеншн, IAM и аудит API.

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

Доказуемость строится так же, как на endpoint: контекст, минимальное вмешательство, экспорт в исходном виде, хеши, chain of custody.

Практическая цель — построить единый таймлайн, связав identity-события, control plane, data plane и действия пользователя/endpoint.