Что делать при ИБ-инциденте: первые 24 часа

Понедельник, 9:15 утра. Дежурный SOC-аналитик фиксирует массовое переименование файлов на файловом сервере бухгалтерии. К 9:40 шифровальщик добрался до трёх из пяти сегментов сети. Бэкапы на месте - компания выстроила процесс год назад. Ситуация управляемая? К 14:00 выяснилось: атакующий сидел в инфраструктуре 11 дней (что совпадает с глобальной медианой по Mandiant M-Trends 2025), успел выгрузить клиентскую базу на 200 тысяч записей и скомпрометировал домен-контроллер. Бэкапы чистые, но восстановление AD заняло 9 суток. За это время компания не уведомила Роскомнадзор в 24-часовой срок по ч. 3.1 ст. 21 152-ФЗ, получила штраф и потеряла двух корпоративных клиентов.

Вот этот разрыв - между "бэкапы есть" и "компания работает" - и закрывает incident response чеклист для первых суток.

По данным Verizon DBIR 2025, рост ransomware-инцидентов в среднем бизнесе составил 18% год к году, а 86% атак в 2024-м были финансово мотивированы (CrowdStrike Global Threat Report 2025). Разница между компанией, которая восстановилась за 3 дня, и компанией, которая тонет месяц, определяется не бюджетом на ИБ, а тем, что произошло при ИБ-инциденте в первые 24 часа.

Час 0-1: реагирование на инцидент ИБ начинается с фиксации​

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

Подтвердить инцидент, а не ложное срабатывание​

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

• Подтверждённое выполнение вредоносного кода или шифровальщика - Data Encrypted for Impact (T1486, Impact)
• Необъяснимая активность привилегированных учёток: новые админ-аккаунты, вход в нерабочее время - Valid Accounts (T1078, Initial Access / Persistence / Privilege Escalation / Defense Evasion)
• Паттерны эксфильтрации: массовые выгрузки, нетипичные DNS-запросы, исходящий трафик на неизвестные IP
• Остановка защитных сервисов: EDR-агент, антивирус, логирование отключились на нескольких машинах одновременно - Service Stop (T1489, Impact)
• Внешний сигнал: уведомление от НКЦКИ, контрагента, появление данных компании на теневых площадках

Если на грани - эскалируйте. Стоимость ложной тревоги - потраченный час. Стоимость пропущенного ИБ-инцидента - недели простоя. По данным Mandiant M-Trends 2025, 57% организаций узнают об инциденте от внешней стороны. Атакующий успевает уйти с данными до того, как внутренний мониторинг вообще сработает.

Назначить роли - даже если команда из трёх человек​

Хаос начинается не из-за нехватки людей, а из-за отсутствия ролей. Даже втроём нужны:


Один человек может совмещать роли, но сами роли должны быть проговорены вслух. Иначе к четвёртому часу никто не помнит, кто и что делал. CISA Incident Response Playbooks прямо говорят: заранее назначенные роли - основа для масштабирования реагирования при ухудшении ситуации.

Зафиксировать момент обнаружения​

Это юридически значимое действие. С момента обнаружения начинается отсчёт:

• 24 часа - первичное уведомление Роскомнадзора при утечке персональных данных (ч. 3.1 ст. 21 152-ФЗ)
• 3 часа - уведомление НКЦКИ для значимых объектов КИИ (приказ ФСБ № 547, 187-ФЗ ст. 5)
• 24 часа - для иных объектов КИИ

Запись в журнале инцидентов: точное время, кто обнаружил, источник сигнала (алерт SIEM, звонок пользователя, внешнее уведомление), затронутые активы. Без этой записи все дальнейшие сроки - неопределённы. При проверке регулятором восстановить хронологию постфактум практически невозможно.

Список "не делать" - распечатать и повесить в war room​

Каждый пункт - реальная ошибка, которую я видел на инцидентах:

• НЕ выключать питание серверов - уничтожите содержимое RAM (ключи шифрования, сетевые сессии, malware в памяти)
• НЕ переустанавливать ОС и не форматировать диски
• НЕ удалять подозрительные файлы и логи
• НЕ менять пароли массово без фиксации активных сессий и токенов
• НЕ комментировать инцидент публично до технической верификации
• НЕ обсуждать детали в корпоративных мессенджерах - они могут быть скомпрометированы

Последний пункт, кстати, игнорируют чаще всего. На одном инциденте вся переписка IR-команды шла в Slack, к которому атакующий имел доступ через скомпрометированную учётку. Он буквально наблюдал за реагированием в реальном времени.

Часы 1-4: сдерживание угрозы и сохранение улик​

Сдерживание - самая рискованная фаза чеклиста реагирования на инцидент. Перереагируете - остановите бизнес. Недореагируете - атакующий продолжит движение по сети.

Изоляция: сеть, а не розетка​

Предпочитайте сетевую изоляцию отключению питания. Если EDR поддерживает команду isolate host - используйте её для подтверждённо скомпрометированных машин. Это сохраняет содержимое RAM и состояние диска при обрыве C2-канала.

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

Учётные записи и токены​

Атакующий, закрепившийся через Valid Accounts (T1078), часто оставляет бэкдоры: запланированные задачи, дополнительные учётки, скомпрометированные сервисные аккаунты. Простой сброс пароля не завершает активные сессии.

Порядок действий:

1. Заблокировать подозрительные учётные записи
2. Отозвать refresh-токены и завершить активные сессии (в Azure AD / Entra ID - через Revoke-AzureADUserAllRefreshToken)
3. Для привилегированных аккаунтов - потребовать повторную MFA-регистрацию
4. Проверить сервисные учётные записи и их активность за последние 30 дней

Вот нюанс, который регулярно стоит компаниям повторного компрометирования: сброс пароля в Active Directory не завершает активные Kerberos-тикеты. Атакующий с украденным TGT продолжает работать ещё 10 часов - это время жизни тикета по умолчанию. Сбросили пароль, выдохнули, а он всё ещё внутри.

Сохранение артефактов - до того, как ротация их перезапишет​

Точка, где расследование либо получает доказательную базу, либо теряет её навсегда:
Если логи SIEM хранятся 7 дней, а атакующий был в сети 11 (медиана по Mandiant M-Trends 2025) - часть картины уже потеряна. Это аргумент для увеличения retention минимум до 90 дней. Вопрос, который нужно поднять на постинцидентном разборе, а не когда горит.

Часы 4-12: управление кризисом ИБ - штаб и коммуникации​

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

Кризисный штаб: действия руководства при кибератаке​

Типичная ошибка на этом этапе - руководство получает либо слишком много технических деталей, либо слишком мало фактов. По рекомендациям NIST SP 800-61, работающий формат сводки - одна страница с чётким разделением:

Факты (подтверждено): что произошло, какие системы затронуты, какие данные могли быть скомпрометированы, какие меры приняты. Гипотезы (требуют проверки): предполагаемый масштаб и источник. Неизвестно: что ещё не установлено и когда будет следующий апдейт. Решения, требующие согласования: уведомление регуляторов, внешние коммуникации, привлечение внешних IR-специалистов.

На практике я видел, как CISO приходит к генеральному с 15-страничным техническим отчётом, а тот спрашивает: "Так мы работаем или нет?" Одна страница - факты/гипотезы/неизвестно - снимает 80% вопросов.

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

Руководству нужно понимать цену бездействия. За утечку персональных данных предусмотрены значительные штрафы (КоАП РФ, ст. 13.11), включая оборотные - по некоторым составам от 1% до 3% выручки за предшествующий год для повторных нарушений. Для компании с выручкой 1 млрд рублей - это 10-30 млн рублей (точные размеры зависят от квалификации нарушения).

Сроки уведомления - юридическое требование, а не рекомендация:


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

Часы 12-24: план реагирования на инцидент - масштаб и восстановление​

Определить масштаб: что атакующий сделал за время присутствия​

К этому моменту форензика должна ответить на ключевые вопросы:

• Каков вектор первоначального доступа (фишинг, уязвимость, украденные учётные данные, подрядчик)?
• Какие техники использовал атакующий для закрепления и горизонтального перемещения?
• Были ли признаки эксфильтрации данных?
• Удалил ли атакующий следы - Clear Windows Event Logs (T1070.001, Defense Evasion), File Deletion (T1070.004, Defense Evasion)?
• Есть ли признаки Inhibit System Recovery (T1490) - удаление теневых копий, отключение бэкап-агентов?
• Были ли попытки Data Destruction (T1485) или Account Access Removal (T1531)?

Группировки, активные прямо сейчас, работают именно по этим TTPs. По данным ransomware.live, группы play и chaos публикуют новых жертв ежедневно - от healthcare до manufacturing, от США и Великобритании до Тайваня. Медианный выкуп по Verizon DBIR 2025 - $46 000, но максимум достигает $75M в единичном инциденте.

Detection-правило: поймать подготовку к шифрованию​

Большинство шифровальщиков перед активацией выполняют предсказуемую последовательность: удаление теневых копий (T1490), остановка сервисов бэкапирования (T1489), отключение восстановления. Базовое правило корреляции для SIEM:
Именно этот тип алертов даёт окно в 15-30 минут до начала шифрования. Если подобных правил в SIEM нет - это первое, что стоит добавить после закрытия инцидента. Серьёзно, прямо сейчас проверьте.

Валидация бэкапов и восстановление​

Первые шаги после взлома в части восстановления начинаются только после закрытия вектора атаки. Иначе - реинфекция в течение часов.

1. Проверить целостность бэкапов (не зашифрованы ли, не содержат ли malware)
2. Восстановить Active Directory / контроллеры домена первыми
3. Восстановить критичные бизнес-системы по заранее определённому приоритету
4. Мониторить восстановленные системы на признаки повторного заражения

Пункт 4 часто забывают. А зря - я видел случай, когда атакующий оставил persistence через scheduled task, который пережил восстановление из бэкапа и через 48 часов запустил второй раунд шифрования.

Чеклист реагирования на инцидент: сводная таблица​

Ошибки, которые превращают ИБ-инцидент в катастрофу​

Позднее подключение юристов. Юрист нужен не для "оформления бумаг", а для принятия решений: подавать ли уведомление при неподтверждённой утечке, как формулировать коммуникации для клиентов, когда привлекать правоохранительные органы. Юрист на 20-м часу вместо 4-го стоит компании штрафов и судебных издержек.

Девять из десяти компаний, с которыми я работал на инцидентах, имели план реагирования на инцидент. У двух из них этот план существовал за пределами PDF-файла на общем диске. Playbook, который не прогоняли на учениях - художественная литература, а не инструмент кризисного управления при кибератаке. Регулятор проверяет не наличие документа, а наличие следов: логи, зафиксированные решения, таймлайн. Компания без нормального журналирования физически не способна выполнить требование о результатах расследования за 72 часа - и обнаруживает это в худший момент.

Весь мой опыт координации кризисных штабов сводится к одному наблюдению: техническая часть реагирования на инцидент ИБ - 30% успеха. Остальные 70% - скорость принятия решений, чёткость ролей и готовность руководства действовать в условиях неполной информации. Компании, которые раз в квартал проводят табличные учения (tabletop exercises) в неудобное время - в пятницу вечером, в выходной - справляются втрое быстрее тех, кто считает план реагирования "документом для проверяющих"=. Если у вас другой стек детекции и нужна помощь с адаптацией Sigma-правил под конкретный SIEM - на форуме codeby.net разбираем подобные кейсы с конфигами и свежими инцидентами.