Статья Incident Response расследование кибератаки: пошаговый разбор от triage до отчёта

Понедельник, 9:15 утра. SIEM выбросил high-severity алерт: сервисный аккаунт svc_backup аутентифицировался на трёх серверах за 40 секунд - каждый раз с разных source IP, с каждого хоста пошли LDAP-запросы к контроллеру домена. Компания с выстроенным бэкап-процессом, сегментированной сетью и EDR на эндпоинтах. К 15:00 стало ясно: атакующий сидел в инфраструктуре 11 дней, бэкапы за последнюю неделю содержали следы персистенции, а сервисный аккаунт был скомпрометирован через OS Credential Dumping (T1003, Credential Access). Дальше - пошаговый разбор того, как шло расследование кибератаки: от первого алерта до финального IR-отчёта, ушедшего руководству и юристам.

Минимальный стек для IR-расследования​

Требования к окружению​

Перед тем как разбирать инцидент, убедитесь, что рабочая станция аналитика готова. Звучит банально, но я видел случай, когда дамп памяти с 64 ГБ сервера пытались анализировать на ноутбуке с 8 ГБ RAM. Закончилось предсказуемо.

Компонент	Требование	Комментарий
ОС аналитика	Windows 10/11 или Linux (Ubuntu 22.04+)	Windows - для EZ Tools и KAPE, Linux - для Volatility и Velociraptor
RAM	16 ГБ минимум, 32 ГБ для дампов памяти	Дамп сервера с 64 ГБ RAM потребует соответствующего объёма при анализе
Диск	SSD, свободно от 500 ГБ	Триажные архивы + образы дисков + дампы
Сеть	Изолированный сегмент	Malware-артефакты не должны попасть в production
SIEM	Splunk 9.x / Elastic 8.x / MaxPatrol SIEM	Примеры ниже - на SPL и Sigma

Набор инструментов для сбора и анализа артефактов:

• KAPE (Kroll Artifact Parser and Extractor) - сбор триажных артефактов с Windows-хостов, работает offline, не требует агента. Последний релиз - март 2025, активно поддерживается.
• Velociraptor (0.7+) - удалённый сбор через агент, подходит для инфраструктур от десятков хостов. Если хостов меньше пяти - проще руками через KAPE.
• Eric Zimmerman Tools - парсинг реестра, MFT, ShellBags, Amcache, Prefetch. Бесплатные, документация на LeanPub.
• Volatility 3 - анализ дампов оперативной памяти. Тройка заметно быстрее двойки на больших дампах, но плагинов пока меньше.
• Wireshark 4.x / Zeek - разбор сетевого трафика и PCAP.

Инструмент	Когда использовать	Ограничения
KAPE	Локальный сбор, offline, один хост	Требует физический или RDP-доступ
Velociraptor	Удалённый сбор, десятки-сотни хостов	Нужен предустановленный агент
Ручной сбор (wevtutil, reg save)	Нет инструментов, экстренный triage	Неполнота, легко пропустить артефакты
FTK Imager / dd	Полный образ диска для forensics	Часы на один хост, не масштабируется

Triage: первые 30 минут после алерта​

Первые полчаса определяют исход расследования. Цель triage - ответить на три вопроса: это реальная компрометация или false positive? Какой масштаб? Нужен ли немедленный containment?

Валидация алерта в SIEM​

Начинаем с проверки истории подозрительного аккаунта за 30 дней и сравнения с baseline. Пример на SPL для Splunk:

index=wineventlog EventCode=4624 TargetUserName="svc_backup"
| stats count by src_ip, ComputerName, LogonType
| where count > 5
| sort -count

Если аккаунт штатно логинится с одного-двух серверов бэкапирования, а теперь - с десятка разных IP в рабочем сегменте, это уже не false positive. Тут даже спорить не о чем.

Параллельно на целевых хостах запускаем (от имени администратора): netstat -ano (активные соединения с PID, требует elevated-прав для полного вывода) или netstat -anob (добавляет имя процесса, но заметно тормозит вывод) или предпочтительнее Get-NetTCPConnection | select LocalAddress,LocalPort,RemoteAddress,RemotePort,OwningProcess (Windows Server 2012+), tasklist /svc (сервисы и их аккаунты), wevtutil qe Security /c:50 /rd:true /f:text (последние 50 событий Security-лога). Любые команды triage на живом хосте оставляют собственные артефакты (Prefetch, Security 4688, Amcache) - фиксируйте все действия аналитика в chain of custody. Забудете записать - потом не докажете, что этот Prefetch создали вы, а не атакующий.

Если EDR развёрнут (CrowdStrike Falcon, SentinelOne, Elastic EDR), запрашиваем timeline процессов на затронутых хостах. Ищем запуск cmd.exe - маркер Windows Command Shell (T1059.003, Execution), powershell.exe из-под сервисного аккаунта - маркер PowerShell (T1059.001, Execution), а также wmic.exe - маркер Windows Management Instrumentation (T1047, Execution).

Классификация​

В нашем кейсе за 20 минут определили: алерт реальный - аккаунт использовался для lateral movement. Затронуты минимум три сервера (файловый, терминальный, 1С). Логи EDR показали запуск переименованного mimikatz.exe (svchost32.exe) - OS Credential Dumping (T1003). Критичность: Critical. Решение - немедленный containment файлового сервера.

Сбор артефактов и chain of custody​

После первичного triage запускается параллельный процесс - сбор цифровых доказательств. Порядок критичен: сначала volatile data (RAM, сетевые соединения), потом non-volatile (диск, реестр, логи). Перепутаете - потеряете самое ценное.

Порядок сбора​

1. Дамп оперативной памяти - WinPmem (winpmem_mini_x64.exe output.raw). На сервере с 64 ГБ RAM - 15-20 минут. Дамп делается ДО любых действий на хосте: каждая запущенная команда перезаписывает часть памяти.
2. Триажный сбор - KAPE: kape.exe --tsource C: --tdest \\forensic-share\case001\ --target !SANS_Triage --tflush --vhdx case001. Соберёт $MFT, реестр (SAM, SYSTEM, SOFTWARE, SECURITY), Prefetch, Amcache, ShellBags, $UsnJrnl, журналы событий (evtx). На типичном Windows Server - 20-40 минут.
3. Сетевые артефакты - текущие соединения (volatile data) фиксируются ДО дампа памяти: netstat -anob, Get-NetTCPConnection. Если Zeek уже пишет трафик, забираем логи за период подозрительной активности. Если нет - pktmon start --etw -p 0 -c (Windows 10 1809+/Server 2019+) или netsh trace start capture=yes на живом хосте до изоляции для захвата будущей активности (ретроспективу он не даст). Оба инструмента создают .etl-файлы, которые потребуют конвертации в PCAP через etl2pcapng для анализа в Wireshark.

Chain of custody​

Каждый собранный артефакт документируется: кто, когда, откуда, SHA-256 хеш. Без этого данные не имеют юридической силы. Организации без формализованного chain of custody теряют возможность использовать собранные данные в суде и при взаимодействии с регуляторами. На практике я встречал случаи, когда отличный forensic-анализ оказывался бесполезен - просто потому что никто не записал, кто и когда снимал дамп.

Артефакт	Хост	Время (UTC)	Аналитик	SHA-256	Примечание
memory.raw	SRV-FILE01	2025-01-13 09:47	Иванов А.С.	a3f2c...	RAM 64 ГБ, WinPmem
KAPE_triage.zip	SRV-FILE01	2025-01-13 10:12	Иванов А.С.	7b9d1...	SANS_Triage target

Восстановление timeline атаки по MITRE ATT&CK​

Когда артефакты собраны, начинается самая трудоёмкая часть - реконструкция timeline. Цель: восстановить полную цепочку от initial access до impact и привязать каждый шаг к MITRE ATT&CK.

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Для расследований с подозрением на инсайдера критично анализировать User-Agent, частоту запросов и паттерн взаимодействия (если есть EDR-телеметрия). Без baseline - гадание на кофейной гуще.

Containment и eradication: когда изолировать, когда вайпить​

Решение о containment зависит от текущего статуса атаки. Универсального ответа нет - вот decision tree:

Ситуация	Действие	Приоритет
Активная эксфильтрация	Немедленная сетевая изоляция (VLAN, не питание)	Остановить утечку, сохранить RAM
Ransomware шифрует	Сетевая изоляция + при необходимости отключение питания	Минимизировать объём зашифрованных данных
Lateral movement без ущерба	Изоляция сегмента, усиленный мониторинг	Собрать IOC, определить масштаб
Скомпрометированные учётки	Отзыв credentials + аудит Kerberos-тикетов	Зафиксировать масштаб до containment
Подозрение на инсайдера	Изоляция хоста + юридическое сопровождение	Доказательная база для HR/юристов

В нашем кейсе containment прошёл в два этапа. Немедленно (09:35): изоляция файлового сервера через EDR-консоль (network containment, не отключение питания - RAM нужна для дампа). В течение часа (10:15): отзыв сессий и пароля svc_backup, инвалидация всех существующих Kerberos TGT через двойной сброс пароля krbtgt с интервалом не менее Maximum ticket lifetime (по умолчанию 10 часов) + время полной репликации AD между DC. Тут важный нюанс: klist purge - локальная очистка кэша на конкретном хосте, не глобальная инвалидация. Путать эти вещи - частая ошибка.

Eradication после определения масштаба (3 сервера + 1 рабочая станция): переустановка ОС на скомпрометированных хостах (wipe & reimage), сброс паролей всех привилегированных аккаунтов, аудит GPO на отсутствие персистенции (Scheduled Tasks, Run/RunOnce в реестре). Восстановление - из бэкапов, датированных ДО дня 0. Бэкапы за 3-13 января были скомпрометированы. Вот почему «бэкапы есть» и «бэкапы чистые» - это два разных утверждения.

IR-отчёт: структура документа и правовой контекст​

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

Структура​

1. Executive Summary (1 страница) - что произошло, ущерб, принятые меры. Без техники. Для C-level и юристов.
2. Timeline - хронология с точностью до минуты. Каждое событие привязано к артефакту (номер лога, хеш файла, запись SIEM). Для IR-команды.
3. Анализ TTPs - маппинг на MITRE ATT&CK. В нашем кейсе: T1566 → T1059 → T1003 → T1078 → T1070/T1562 → T1486/T1041.
4. IOC-лист - хеши, IP C2-серверов, домены, пути. Формат: STIX или CSV для импорта в SIEM.
5. Рекомендации - конкретные действия, не абстракции. «Внедрить правило корреляции на аутентификацию сервисных аккаунтов вне расписания» - правило прилагается.
6. Приложения - chain of custody, дампы конфигураций, выводы инструментов.

Правовой контекст​

Если в результате инцидента произошла утечка персональных данных, вступает ФЗ-152 «О персональных данных». Приказ ФСТЭК №21 требует наличия мер по обнаружению и реагированию (группа ОПС). Отсутствие таких мер - отягчающий фактор при проверке.

С введением оборотных штрафов за утечки ПДн финансовые последствия инцидента могут кратно превысить технический ущерб. IR-отчёт становится ключевым документом: доказывает, что компания имела план реагирования на инциденты, действовала по нему и минимизировала последствия. Согласно NIST CSF v2.0, категория RC.CO-01 (Incident Recovery Communication) также предписывает управление публичными коммуникациями - уведомление субъектов ПДн и Роскомнадзора в установленные сроки.

Практический вывод: юрист подключается к IR-процессу с момента подтверждения утечки ПДн. Не «когда найдём время» - сразу. Формулировки в отчёте, порядок уведомлений, сроки - всё это напрямую влияет на размер санкций. Видел ситуации, когда грамотный IR-отчёт снижал штраф в разы, а его отсутствие - превращало инцидент в катастрофу.

Detection-чеклист: корреляционные правила после инцидента​

Post-incident - момент, когда есть реальные IOC и TTP для создания detection-правил. Согласно NIST CSF v2.0, категория DE.AE-01 предписывает поддерживать baseline сетевых операций и потоков данных - без baseline нет аномалии, без аномалии нет детекции. А RS.AN-01 требует, чтобы уведомления от систем обнаружения расследовались, а не закрывались как «ну так бывает».

Sigma-правило: аномальная аутентификация сервисного аккаунта​

title: Service Account Auth Outside Scheduled Window
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4624
    TargetUserName|startswith: 'svc_'
    LogonType:
      - 3
      - 10
  # NOTE: Sigma не поддерживает фильтрацию по часам суток нативно.
  # Реализуйте на backend: Splunk - where date_hour>=6 AND date_hour<=22;
  # Elastic - range query по @timestamp.
  filter_baseline:
    SourceIp:
      - '10.0.1.50'  # замените на IP ваших backup-серверов
      - '10.0.1.51'
  condition: selection and not filter_baseline
level: high
tags:
  - attack.t1078
  - attack.persistence

Правило сработает при аутентификации любого сервисного аккаунта (префикс svc_) с сетевым или RDP-входом, за исключением известных IP бэкап-серверов (секция filter_baseline - замените IP-адреса на актуальные). LogonType 5 (Service) намеренно исключён: он генерируется при штатном запуске Windows-служб и даёт неприемлемый уровень false positive. Фильтрацию по рабочим часам (когда штатные задачи не выполняются) реализуйте на уровне backend-запроса (SPL/KQL/EQL) - Sigma не поддерживает нативную фильтрацию по времени суток.

Чеклист: что внедрить после расследования​

1. Аутентификация привилегированных и сервисных аккаунтов вне baseline (время, source IP, LogonType)
2. Запуск powershell.exe / cmd.exe из процессов Microsoft Office - маркер T1059 через T1566
3. Обращения к lsass.exe с нетипичных процессов - маркер T1003
4. Очистка журналов событий (Event ID 1102) - маркер T1070, Critical без исключений
5. Отключение Defender через PowerShell (Set-MpPreference -DisableRealtimeMonitoring) - маркер T1562
6. Аномальный объём исходящего HTTPS на нетипичные внешние IP - маркер T1041
7. Массовое переименование/шифрование файлов на файловых шарах - маркер T1486

Каждое правило привязывается к конкретной технике ATT&CK и проходит тюнинг: baseline минимум 2 недели до перевода в production. Без тюнинга - тысячи false positive и alert fatigue. Аналитики начнут закрывать алерты не глядя - как произошло с первым алертом EDR в нашем кейсе, когда запуск PowerShell из Word был закрыт как FP.

В реальных IR-расследованиях прослеживается одна общая черта: detection-правила существовали, но были мертвы. Sigma-правило написано под одну технику, атакующий сместил TTP на полшага - алерт не сработал. Или сработал, но L1 закрыл, потому что «с этим аккаунтом так всегда».

Проблема не в инструментах и не в количестве правил. Проблема в том, что IR-процесс воспринимается как проект с финальной точкой, а не как цикл. NIST IR-1 и SANS формализуют фазу lessons learned, но на практике она сводится к отчёту, который кладётся на полку.

Настоящий post-incident - это когда через месяц после инцидента вы проверяете: сработало бы новое правило на аналогичной TTP-цепочке? Провели ли purple team сессию, воспроизвели ли атаку? Если ответ «нет» - incident response не завершён, остановлена конкретная атака. Следующая будет дешевле для атакующего и дороже для организации, особенно с учётом оборотных штрафов, когда повторная утечка ПДн бьёт уже не разовым штрафом, а процентом от годовой выручки.

Попробуйте прогнать Sigma-правило из этой статьи на своих логах за последний месяц. Если оно сработало - у вас есть что расследовать. Если в вашем SIEM нет готовых правил под описанные здесь TTP - на форуме codeby.net лежит набор Sigma-правил с обсуждением адаптации под конкретные стеки.