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

Мой первый таймлайн инцидента занял четыре часа. 38 000 строк из Sysmon, Windows Security Log и proxy-логов, три пересобранных Excel-таблицы — и ноль уверенности, что ничего не упущено. Двадцатый таймлайн — те же типы источников, похожий сценарий — уложился в 47 минут. Разница не в инструментах. Разница в наработанной механике: знать, какие поля вытаскивать первыми, где врут таймстемпы, как быстро отсекать шум. Эту механику я нарабатывал на открытых датасетах — чужих логах из CyberDefenders, LetsDefend и Splunk Boss of the SOC — пока не вышел на стабильную скорость. Ниже — алгоритм, инструменты и ошибки, которые стоили мне тех четырёх часов на старте.

Зачем SOC-аналитику отдельно тренировать построение таймлайна атаки

Таймлайн инцидента — хронологическая реконструкция событий: что произошло, когда, на каком хосте, под какой учётной записью. Это рабочий документ, по которому принимают решения об изоляции хостов, отзыве сессий и эскалации руководству. Не отчёт «для галочки».

По данным Mandiant M-Trends 2025, медианное время нахождения злоумышленника в сети до обнаружения (dwell time) — 11 дней, исторический минимум. Но 57% организаций узнали об инциденте не сами, а от внешней стороны. Расследование начинается в условиях дефицита информации: что-то уже случилось, масштаб неясен, бизнес ждёт ответов. Качественный таймлайн — единственный способ за разумное время определить, какие системы затронуты, какие учётные данные скомпрометированы и куда атакующий двинулся дальше.

OWASP относит недостатки логирования и мониторинга к десятке критических рисков веб-приложений (A09:2021 — Security Logging and Monitoring Failures): без логирования нарушение невозможно обнаружить. Но логи без умения собрать их в связный таймлайн — пазл из тысячи кусочков без картинки на коробке.

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

Анатомия таймлайна: поля и источники логов при расследовании инцидента

Минимальный набор полей для таймлайна инцидента

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

Опционально добавляют: Process (имя процесса), Parent Process (родительский процесс — помогает отследить цепочку запуска), Hash (хеш исполняемого файла) и MITRE ATT&CK TTP.

MITRE ATT&CK — открытая база тактик и техник, которыми пользуются реальные атакующие. Каждая техника имеет идентификатор — T-код. Например, T1078 (Valid Accounts) описывает использование легитимных учётных записей для первоначального доступа или закрепления. Привязка события к T-коду в таймлайне позволяет сразу понять, на каком этапе атаки находишься. Когда я начинал, казалось, что маппинг на ATT&CK — лишняя бюрократия. На третьем challenge’е стало ясно: без T-кодов через час забываешь, зачем вообще выделил это событие.

Источники логов для разбора инцидента

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

Endpoint-логи — события с конечных хостов. Windows Security Log: Event ID 4624/4625 (входы), 4688 (создание процессов), 4720 (создание учётных записей). Sysmon (System Monitor) — расширенный аудит: создание процессов с полной командной строкой, сетевые подключения, изменения реестра. Если Sysmon установлен на хосте — это самый ценный источник. Linux: auth.log / secure — аутентификация, sudo, SSH-сессии.

Сетевые логи. Firewall — разрешённые и отклонённые подключения, IP-адреса, порты. Proxy / Web-фильтр — HTTP-запросы, URL, User-Agent. IDS/IPS (системы обнаружения и предотвращения вторжений — анализируют трафик и блокируют известные атаки по сигнатурам) — срабатывания на известные паттерны.

Логи приложений. Web-сервер (Apache/Nginx access log) — запросы к веб-приложениям. Базы данных — выполненные запросы и подключения. Почтовый сервер — входящие и исходящие сообщения, критично для фишинговых сценариев.

Как отмечает Cyber Triage в руководстве по timeline analysis, полезны не только прямые события, но и косвенные признаки: жалобы пользователей на деградацию производительности, несостоявшиеся cron-задачи, неотправленные штатные уведомления. Отсутствие ожидаемого события иногда говорит больше, чем его наличие — атакующий мог очистить логи. В MITRE ATT&CK это описано как T1070.001 (Clear Windows Event Logs) и T1070.002 (Clear Linux or Mac System Logs) — заметание следов.

Инструменты для самостоятельной отработки DFIR

Для тренировки хватает бесплатных инструментов. Необязательно начинать с enterprise-платформ.

Plaso / log2timeline — open-source движок, который парсит десятки форматов (EVTX, registry hives, MFT, browser history, syslog) и выдаёт единый поток событий с нормализованными таймстемпами. Де-факто стандарт для DFIR-таймлайнов. Работает на Linux; на Windows проще через Docker или WSL.

Timeline Explorer (Eric Zimmerman) — Windows-утилита для просмотра CSV-файлов с таймлайн-данными. Быстрая фильтрация и сортировка больших объёмов. Часто используется в связке с другими инструментами Zimmerman: EvtxECmd для конвертации EVTX в CSV, MFTECmd для парсинга MFT.

Timesketch — веб-интерфейс поверх Plaso. Загружаешь файл формата .plaso и работаешь с таймлайном в браузере: фильтрация, разметка тегами, визуальная хронология. Разворачивается через Docker Compose.

Autopsy — open-source платформа для цифровой криминалистики. Парсит образы дисков, строит таймлайн из файловых метаданных и реестра. В списке awesome-incident-response на GitHub упоминается как базовый инструмент наряду с The Sleuth Kit.

CyberChef — «швейцарский нож» для трансформации данных: декодирование Base64, конвертация таймстемпов между форматами, парсинг hex-строк. Сам таймлайн не строит, но незаменим при подготовке данных.

SIEM (Splunk / ELK / OpenSearch) — если логи загружены в SIEM, анализ логов incident response выполняется через поисковые запросы. На тренировочных датасетах Boss of the SOC данные заранее загружены в Splunk — максимально приближено к ежедневной работе L1–L2 аналитика.

Для старта хватает связки Plaso + Timeline Explorer + CyberChef. Timesketch и SIEM подключаются по мере роста объёма данных.

Где брать чужие логи: тренажёры для SOC-аналитика

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

CyberDefenders (cyberdefenders.org) — платформа с challenge’ами по цифровой криминалистике. Каждый challenge — архив с артефактами (EVTX, PCAP, образы памяти, registry hives) и набор вопросов, которые направляют расследование. Уровни от начального до продвинутого. Для тренировки таймлайнов подходят категории Incident Response и Threat Hunting.

LetsDefend (letsdefend.io) — симулятор SOC с интерфейсом, похожим на реальный SIEM-дашборд. Приходят алерты, нужно расследовать, классифицировать и закрыть тикет. Тренирует полный workflow: алерт → триаж → построение таймлайна атаки → эскалация.

Boss of the SOC (BOTS) — датасеты от Splunk, доступные бесплатно. Содержат логи из нескольких источников (Sysmon, WinEventLog, Suricata, proxy) для сценариев с APT-атаками. Загружаются в Splunk (бесплатная версия достаточна) и разбираются через SPL-запросы.

Malware Traffic Analysis (malware-traffic-analysis.net) — коллекция PCAP-файлов с реальным вредоносным трафиком. Подходит для сетевой части таймлайна: определение момента C2-коммуникации (Command and Control — связь вредоносного ПО с управляющим сервером, T1071.001), загрузки payload, эксфильтрации данных.

Рекомендация: начинайте с CyberDefenders — задачи структурированы, есть вопросы-подсказки и writeup’ы для самопроверки. После 5–7 challenge’ей переходите на BOTS, где формулировать гипотезы нужно самостоятельно.

Практика: строим таймлайн инцидента шаг за шагом

Ниже — алгоритм, который я обкатал на двадцати тренировочных сценариях. Он не привязан к конкретной платформе: работает и на EVTX-файлах в Timeline Explorer, и на логах в Splunk.

Делай раз — нормализуй и загрузи логи

Предусловие: набор лог-файлов (EVTX, CSV, JSON, PCAP) из тренировочного датасета. Для EVTX нужен Windows-хост или WSL с установленным EvtxECmd (входит в набор Eric Zimmerman tools) или Plaso.

1. Определите часовые пояса логов. Windows Security Log хранит время в UTC, Sysmon — зависит от конфигурации, proxy-логи часто в локальном времени. Всё приводится к UTC — это первый шаг, который новички пропускают и потом тратят час на исправление.

2. Если работаете с EVTX, сконвертируйте в CSV: EvtxECmd.exe -f Security.evtx --csv . --csvf security_parsed.csv. На выходе — табличный файл, который открывается в Timeline Explorer.

3. Если работаете в Splunk, проверьте загрузку базовым запросом:

index=botsv2 sourcetype=WinEventLog:Security
| stats count by EventCode

В результате — таблица Event ID и их количества. Если пусто — проблема с индексом или sourcetype.

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

Делай два — отфильтруй шум и выдели аномалии

Основная трата времени у новичка — чтение всех записей подряд. В реальном инциденте это невозможно: 38 000 строк за сутки — норма для одного хоста с включённым Sysmon.

Фильтрация строится от гипотезы. Пример: «Подозреваю lateral movement через RDP» (T1021.001 — Remote Desktop Protocol, тактика lateral movement, то есть перемещение атакующего между машинами внутри сети).

Что искать: — Event ID 4624 с LogonType=10 (удалённый интерактивный вход, то есть RDP) — покажет, кто и когда подключился — Event ID 4648 (вход с явным указанием учётных данных) — может означать использование украденных кредов — Sysmon Event ID 1 (создание процесса) на целевом хосте сразу после RDP-сессии — что атакующий запускал после входа

В Splunk фильтрация выглядит так:

index=botsv2 EventCode=4624 LogonType=10
| table _time, ComputerName, Account_Name, Source_Network_Address
| sort _time

В Timeline Explorer: отсортируйте столбец Timestamp, отфильтруйте по столбцу EventCode значение 4624, далее ищите записи с LogonType=10.

Ожидаемый результат: из тысяч записей остаются десятки, релевантных гипотезе. Если ничего не нашли — гипотеза неверна, переходите к следующей (например, PowerShell-выполнение — T1059.001, тактика execution).

Делай три — выстрой хронологию и свяжи события по цепочке

Из отфильтрованных записей собирается таймлайн. Каждая строка — одно подтверждённое событие. Ниже — пример из тренировочного сценария. Мотивация атакующего: проникнуть через скомпрометированную сервисную учётную запись, закрепиться и переместиться на контроллер домена для доступа к критическим данным.

Цепочка читается слева направо: вход через легитимную учётную запись (T1078) → запуск PowerShell (T1059.001) → C2-подключение (T1071.001) → закрепление через сервис (T1543.003) → перемещение на контроллер домена (T1021.001) → заметание следов (T1070.001). Каждое событие подтверждено конкретным источником и привязано к технике MITRE ATT&CK.

Обратите внимание на зазор между 02:51 и 03:12 — двадцать минут тишины. На реальном инциденте это место, где стоит копнуть глубже: атакующий мог делать разведку (whoami, net group «Domain Admins»), а логи этих команд оказались в другом источнике или были удалены.

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

Как измерить прогресс: от MTTR к привычке

MTTR (Mean Time to Respond) — среднее время реагирования на инцидент, метрика SOC-команд. Для тренировки подходит упрощённый аналог: время от момента открытия датасета до готового таймлайна.

Мой подход к трекингу: 1. Засекайте время на каждом challenge’е. Записывайте в таблицу: дата, название, количество источников, время в минутах, количество событий в итоговом таймлайне. 2. После каждого разбора фиксируйте узкое место. Нормализация? Поиск нужных Event ID? Корреляция между хостами? 3. Следите за трендом. После 7–10 сценариев время начинает снижаться — формируется автоматизм.

Второй критерий — полнота: сколько ключевых событий вы нашли по сравнению с эталонным writeup’ом. CyberDefenders публикует ответы для большинства challenge’ей. Если стабильно находите 80%+ событий — навык DFIR-аналитика формируется.

Ошибки, которые замедляют разбор логов при расследовании инцидента

За двадцать тренировочных и несколько реальных инцидентов собрался характерный список ловушек.

Игнорирование часовых поясов. Два источника в разных timezone — и вся хронология рассыпается. Proxy пишет в MSK, Sysmon в UTC, firewall в локальном времени хоста. Первым шагом всегда приводить к UTC. Не «потом разберусь» — сразу. Я один раз потерял на этом полтора часа, собирая таймлайн, где события шли в невозможном порядке, пока не догадался проверить offset.

Чтение логов подряд вместо фильтрации по гипотезе. Начинающий аналитик открывает Security.evtx и читает с первой строки. Через 200 записей теряет контекст. Рабочий подход — от гипотезы: «подозреваю RDP lateral movement» → фильтрую по EventCode=4624, LogonType=10 → нашёл или не нашёл → следующая гипотеза.

Фокус на одном источнике. Только Sysmon или только proxy. Атака пересекает несколько слоёв: endpoint, сеть, приложения. Видите PowerShell-подключение к внешнему IP — проверьте proxy-лог: что за домен? Есть ли он в threat intelligence? Без корреляции между источниками в таймлайне будут дыры.

Отсутствие журнала действий аналитика. На реальном инциденте действия документируются — это часть chain of custody. На тренировке ведите такой же журнал: какой фильтр применили, что нашли, какой вывод сделали. Это экономит время при возврате к задаче и формирует дисциплину для продакшена.

Пропуск «негативных» событий. Атакующий мог очистить логи (T1070.001) или удалить артефакты (T1070.004 — File Deletion). Если в Security.evtx внезапно пропал интервал записей или появился Event ID 1102 (журнал очищен) — это само по себе событие для таймлайна и маркер заметания следов.

Большинство материалов по тренировке реагирования на инциденты описывают шестифазный цикл (Preparation → Detection → Containment → Eradication → Recovery → Lessons Learned) так, будто достаточно его понять один раз и можно идти работать. Формально — верно. Но между «знаю фазы» и «за 40 минут собрал таймлайн, по которому команда принимает решение об изоляции» — пропасть, которая заполняется только повторением. Не чтением writeup’ов, а собственными руками: открыть логи, промахнуться с гипотезой, вернуться, найти пропущенный Event ID, пересобрать хронологию. Я видел аналитиков, которые прочитали три книги по DFIR и не могли за час собрать таймлайн из готового датасета — и видел тех, кто после десяти challenge’ей на CyberDefenders делал это быстрее «книжных» коллег. Разница — в количестве повторений на безопасных данных. Если хочется не собирать навыки кусочками из разрозненных датасетов, а пройти базу системно — трек IB Basics на codeby.school закрывает этот путь за пару месяцев, от первых задач в SOC до осмысленной работы с логами.