Супертаймлайн: единая хронология

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

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

Этот урок — про то, как из разрозненных следов собрать связную картину. Мы по-прежнему смотрим глазами защитника: цель таймлайна — понять, что и в каком порядке делал атакующий в нашей системе, чтобы оценить ущерб, найти точку входа и закрыть её. Анализ проводится по образам и журналам систем, к которым у команды есть законный доступ. Реконструкция чужих атак на собственную инфраструктуру — это защита; несанкционированный доступ к чужим системам наказуем (ст. 272 УК РФ).

Зачем это знать защитнику

Отдельные артефакты обманчивы. Изменённый файл, странная запись в реестре, всплеск трафика — каждый сам по себе может быть и атакой, и нормой. Смысл рождается в последовательности: «в 14:02 пришло письмо -> в 14:05 открыт вложенный документ -> в 14:05 запустился процесс -> в 14:06 он создал задачу в планировщике -> в 14:10 пошло исходящее соединение». Такую цепочку невозможно увидеть, глядя на источники по отдельности, в разных программах и с разными форматами времени. Супертаймлайн сводит их в один поток и отвечает на главные вопросы расследования: когда началось, как проникли, что успели сделать, докуда дотянулись.

Какие источники объединяет таймлайн

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

ИсточникКакие времена даёт
Файловая система (MFT, inode)создание, изменение, доступ, изменение метаданных файлов
Журналы ОС (Windows Event Log, syslog)входы, запуск служб, ошибки, аудит
Реестр Windowsвремя записи ключей: автозапуск, недавние документы
История браузерапосещения, загрузки
Журналы приложений и антивирусасрабатывания, действия пользователя
Сетевые логи, NetFlowсоединения, сессии

Ключевое понятие файловой системы здесь — MAC-времена: Modified (изменён контент), Accessed (был доступ), Changed/Created (изменены метаданные / создан). На разных ФС набор и смысл слегка отличаются, но именно эти метки дают «скелет» хронологии файловой активности.

Plaso и log2timeline: идея инструмента

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

# Шаг 1: log2timeline проходит по образу, набор парсеров вытаскивает
# события из десятков источников в промежуточную базу .plaso
log2timeline.py --storage-file timeline.plaso disk_image.raw

# Шаг 2: psort превращает базу в плоскую таблицу, отсортированную по времени,
# с фильтром по нужному окну (например, день инцидента)
psort.py -o l2tcsv -w supertimeline.csv timeline.plaso \
  "date > '2026-01-15 00:00:00' AND date < '2026-01-16 00:00:00'"

Под капотом Plaso — это набор парсеров (каждый понимает свой формат: журнал событий, реестр, SQLite-историю браузера) и единая модель события с полями «время», «источник», «тип», «описание». Все события приводятся к одной шкале (обычно UTC) и сортируются. Результат — гигантская таблица, где соседние строки могут быть из совершенно разных подсистем, но идут в реальном хронологическом порядке.

Почему это и сила, и проблема

Сила — полнота: ничего не теряется, видна вся активность. Проблема — объём: супертаймлайн на одну машину легко содержит сотни тысяч строк, и в этом шуме нужно найти сигнал. Поэтому за сбором всегда следует фильтрация: сужение временного окна, поиск по ключевым артефактам, отсев заведомо фонового. Аналитик не читает таймлайн целиком — он задаёт ему вопросы.

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

Имея таблицу событий, расследование разворачивают вокруг «опорной точки» — момента, который точно связан с инцидентом (срабатывание антивируса, время подозрительного соединения). От неё движутся в обе стороны.

Окно вокруг опорной точки (фрагмент супертаймлайна):

14:02:11  EMAIL    получено письмо с вложением invoice.docm
14:05:40  FILE     создан %TEMP%\invoice.docm        (Created)
14:05:41  EVTLOG   Word запустил дочерний процесс (Office -> wscript)
14:05:42  FILE     создан %APPDATA%\update.js         (Created)
14:06:03  REGISTRY запись в ключ автозапуска (Run)    <- закрепление
14:06:05  EVTLOG   создана задача планировщика "SysUpdate"
14:10:22  NETWORK  исходящее соединение на 203.0.113.10:443  <- C2?

Назад от опорной точки ищут первопричину (root cause): как всё началось — фишинговое вложение, эксплуатация сервиса, украденные учётные данные. Вперёд — что атакующий успел: закрепление в автозапуске и планировщике, боковое перемещение, обращение к управляющему серверу, обращение к данным. Так таймлайн превращается в нарратив инцидента с точными временами, на который потом опирается отчёт. Важная оговорка: метки времени могут быть подделаны или искажены (об этом — отдельный урок про антикриминалистику), поэтому опорные точки берут из наиболее надёжных, перекрёстно подтверждаемых источников.

Как это работает под капотом

Главная техническая трудность таймлайна — привести разные представления времени к одной шкале. Источники хранят время по-разному: журналы Windows — в UTC, история браузера — в Unix-времени, файловая система — иногда в локальном поясе, иногда в UTC, в зависимости от ФС. Если не нормализовать, события «разъедутся» на часы и хронология станет ложной. Поэтому Plaso переводит всё в UTC и хранит таймзону образа явно. Вторая тонкость — гранулярность: у одних меток точность до секунды, у других до миллисекунды, а некоторые события вообще не имеют точного времени (например, «время последнего использования» в реестре округлено). Аналитик это учитывает и не делает выводов из различий, лежащих в пределах погрешности. Наконец, один файл порождает сразу несколько событий (по каждой MAC-метке), поэтому в таймлайне строк всегда больше, чем «вещей», — это нормально.

Как защититься

1. Логируйте заранее и централизованно. Таймлайн настолько полон, насколько полны источники. Включённый аудит, журналы приложений и пересылка логов в SIEM до инцидента — то, что делает реконструкцию возможной.

2. Синхронизируйте время (NTP). Если часы на серверах разъехались, сводный таймлайн врёт. Единый источник времени по всей инфраструктуре — основа корректной хронологии.

3. Работайте по образу и нормализуйте к UTC. Таймлайн строят с копии, а все времена приводят к одной шкале с явно указанной таймзоной — иначе события не сопоставить.

4. Идите от надёжной опорной точки. Начинайте от события, в достоверности которого уверены, и подтверждайте ключевые моменты несколькими независимыми источниками — метки можно подделать.

5. Фильтруйте, а не читайте всё подряд. Сужайте окно и ищите по артефактам закрепления и сетевой активности; супертаймлайн — это инструмент для вопросов, а не для сплошного чтения.

Итоги

  • Супертаймлайн объединяет разнородные источники (ФС, журналы, реестр, браузер, сеть) в одну хронологию по времени.
  • Plaso/log2timeline концептуально: парсеры собирают события в базу .plaso, затем psort выдаёт отсортированную таблицу с фильтром.
  • Смысл рождается в последовательности событий, а не в отдельном артефакте; от опорной точки идут назад к первопричине и вперёд к действиям атакующего.
  • Критично привести все времена к единой шкале (UTC) и синхронизировать часы (NTP) заранее.
  • Метки времени можно подделать, поэтому опираются на перекрёстно подтверждаемые источники; анализ — только по своим/разрешённым системам (ст. 272 УК РФ).
Проверьте себя
1. В чём главное преимущество супертаймлайна перед просмотром артефактов по отдельности?
AОн показывает события из разных подсистем в едином хронологическом порядке, раскрывая последовательность действий атакующего
BОн удаляет из системы все следы вредоносной активности
CОн работает только с одним источником данных, что упрощает анализ
DОн автоматически блокирует управляющий сервер атакующего
2. Почему при построении сводного таймлайна обязательно приводить все метки времени к единой шкале (UTC) и синхронизировать часы?
AИсточники хранят время по-разному; без нормализации события «разъедутся» и хронология станет ложной
BUTC ускоряет работу парсеров log2timeline в несколько раз
CЭто требуется, чтобы вредонос не смог изменить системные часы
DБез UTC инструмент psort не сможет открыть базу .plaso