План реагирования на инцидент с шифровальщиком: первые 24 часа

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

Мы разберём план действий на первые 24 часа, основанный на реальном кейсе: производственная компания, домен itpages.lab.local, сеть 192.168.10.0/24, ключевые серверы srv-dc01 (контроллер домена), srv-fs01 (файловый сервер), srv-backup01 (бэкап), инфраструктура на esxi-host01. У компании уже был план реагирования — именно поэтому инцидент, который у конкурента превратился в недельный простой, здесь обошёлся в несколько часов вынужденного даунтайма.

Важная оговорка: план реагирования не заменяет здравый смысл и не работает как строгий алгоритм «шаг за шагом без права на импровизацию». Реальные инциденты почти всегда преподносят сюрпризы — заражённым оказывается не тот сервер, который ты подозревал первым, или резервные копии частично повреждены. План даёт структуру и последовательность приоритетов, а не готовые ответы на все случаи. Именно поэтому важно заранее определить роли: кто принимает решение об изоляции целых сегментов сети, кто общается с руководством, кто фиксирует улики, а кто занимается непосредственно восстановлением. Если эти роли не распределены заранее, первые часы инцидента уходят на выяснение, кто вообще должен что делать.

Час 0-1: обнаружение и первичная изоляция

Первая и самая важная задача — остановить распространение, не разрушив при этом улики и не потеряв возможность понять масштаб происшествия. Паническое отключение всего подряд или, наоборот, попытка «сначала разобраться, а потом действовать» — обе крайности вредны.

• Изолируй заражённый хост от сети физически (выдернуть кабель) или логически (отключить порт коммутатора / поместить в карантинный VLAN), но не выключай его — оперативная память и открытые сессии содержат критичные улики.
• Немедленно проверь статус ключевых серверов: srv-dc01, srv-fs01, srv-backup01. Если backup-сервер ещё не тронут — это самое время физически отключить его от сети или как минимум заблокировать на firewall все входящие соединения из боевого сегмента.
• Не удаляй файлы записки с требованием выкупа — они содержат идентификатор атаки, который поможет определить семейство шифровальщика и иногда найти публичный дешифратор.

Чек-лист первого часа:
[ ] Заражённый хост отключён от сети (не выключен)
[ ] srv-backup01 изолирован / отключён от боевой сети
[ ] Определён предварительный периметр поражения (какие сегменты, какие хосты)
[ ] Зафиксировано точное время обнаружения
[ ] Собрана команда реагирования (ИТ, руководство, при необходимости внешние эксперты)

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

Час 1-3: оценка масштаба и остановка распространения

Дальше нужно понять, насколько широко разошлась атака, и перекрыть пути дальнейшего распространения. Шифровальщики часто используют легитимные инструменты администрирования (PsExec, WMI, RDP, groupware-скрипты) для бокового перемещения, поэтому изоляция одного хоста редко останавливает атаку целиком.

• Смени пароли всех привилегированных учёток домена (Domain Admin, Enterprise Admin), начиная с тех, что могли быть скомпрометированы. Делай это только с чистого, заведомо не заражённого устройства.
• Проверь список активных сессий и запланированных задач на srv-dc01 и других серверах — новые задачи планировщика являются частым способом закрепления атакующего.
• Временно отключи или ограничь протоколы, которыми чаще всего пользуются шифровальщики для распространения: SMBv1, RDP на боевых серверах без MFA, административные общие ресурсы (C$, ADMIN$).
• Проверь и при необходимости отключи VPN-доступ извне — многие атаки начинаются именно с скомпрометированной учётки удалённого доступа.

Команды для быстрой проверки на срочный узел (пример, PowerShell на срв-dc01):
Get-ADUser -Filter {AdminCount -eq 1} | Select Name, LastLogonDate
Get-ScheduledTask | Where-Object {$_.Date -gt (Get-Date).AddDays(-3)}
Get-NetTCPConnection -State Established | Sort-Object RemoteAddress -Unique

Отдельно стоит проверить контроллеры домена. Если srv-dc01 показывает признаки компрометации (неизвестные учётки в группе Domain Admins, изменённые групповые политики, необычные объекты в Active Directory), считать домен доверенным больше нельзя. В таком случае восстановление часто требует полного пересоздания домена или, как минимум, глубокой чистки и смены всех паролей и Kerberos-билетов (сброс KRBTGT дважды с интервалом).

Час 3-6: сохранение улик

Даже если хочется как можно быстрее перейти к восстановлению, пропуск этого этапа обычно аукается позже — расследование причин без улик превращается в гадание, а без понимания вектора атаки высок риск повторного заражения сразу после восстановления.

• Сделай образы дисков (или хотя бы снимки VSS / снапшоты виртуальных машин на esxi-host01) заражённых систем до любых изменений.
• Сохрани копии журналов событий (Event Log), особенно Security, System и журналов антивируса/EDR, с заражённых хостов и с srv-dc01.
• Зафиксируй записку с требованием выкупа, зашифрованные файлы-образцы (2-3 штуки достаточно) и любые IOC (индикаторы компрометации) — необычные процессы, файлы, сетевые соединения.
• Задокументируй временную шкалу событий по мере их обнаружения — кто, что и когда заметил. Это пригодится и для расследования, и для отчётности регуляторам, если применимо.

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

Час 6-12: уведомление и привлечение нужных людей

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

• Уведоми руководство компании о факте инцидента, предварительном масштабе и ожидаемых сроках восстановления, даже если точных цифр пока нет.
• Свяжись с внешними специалистами по реагированию на инциденты, если внутренней экспертизы недостаточно — во многих случаях именно они помогают быстро определить семейство шифровальщика и наличие публичного дешифратора.
• Проверь требования законодательства и договорных обязательств по уведомлению об утечке данных, если есть основания полагать, что данные клиентов или партнёров были не только зашифрованы, но и похищены (двойное вымогательство — сейчас стандартная тактика).
• Согласуй единый канал коммуникации внутри компании — слухи и противоречивые сообщения в такой ситуации только мешают.

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

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

Час 12-24: подготовка к восстановлению

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

• Проверь целостность и доступность резервных копий на srv-backup01 или в облаке — на изолированном стенде, не в боевой сети (подробнее об этом мы говорим в статье про тестирование восстановления).
• Составь приоритетный список систем для восстановления: как правило, первым делом поднимается инфраструктура идентификации (srv-dc01), затем критичные бизнес-системы, затем файловые ресурсы и рабочие станции.
• Определи точку восстановления (RPO) — на какой момент времени у тебя есть чистые, недоверенные атакующим копии, и сверь это со временем предположительного начала присутствия атакующего в сети.
• Не подключай резервные копии к возможно всё ещё заражённой сети до завершения базовой очистки скомпрометированных систем — иначе есть риск повторного шифрования восстановленных данных.

Чек-лист конца первых суток:
[ ] Улики сохранены (образы дисков, логи, записка с требованием выкупа)
[ ] Пароли привилегированных учёток изменены
[ ] Периметр поражения оценён и задокументирован
[ ] Руководство и при необходимости регуляторы/партнёры уведомлены
[ ] Резервные копии проверены на изолированном стенде
[ ] Составлен приоритетный список восстановления систем

Важно понимать, что первые 24 часа — это не финиш, а только стабилизация ситуации. Полное восстановление инфраструктуры вроде описанной здесь сети с srv-dc01, srv-fs01, srv-backup01 и виртуализацией на esxi-host01 обычно занимает от нескольких дней до пары недель, в зависимости от масштаба поражения и качества подготовки заранее. Но именно от того, насколько дисциплинированно пройдены первые сутки, зависит, будет ли это восстановление управляемым процессом по плану или хаотичным тушением пожара без гарантии результата.

Частые ошибки и как их избежать

• Выключение заражённых хостов вместо изоляции. Полное выключение уничтожает данные оперативной памяти, которые часто содержат ключи шифрования сессии или следы инструментов атакующего. Отключай от сети, но не выключай питание, пока это не станет необходимым.
• Слишком раннее подключение бэкапа к боевой сети. Если источник заражения не локализован, подключение backup-хранилища для восстановления может привести к повторному шифрованию — и на этот раз без резервной копии.
• Замалчивание инцидента внутри компании. Попытки «тихо разобраться самим» без привлечения руководства и внешней экспертизы почти всегда увеличивают итоговое время простоя и финансовые потери.
• Отсутствие заранее распределённых ролей. Если в момент инцидента приходится решать, кто отвечает за коммуникацию, а кто за техническую часть, драгоценные часы уходят на организационную неразбериху вместо реальных действий.

Автор — Команда IT-Pages