Атаки шифровальщиков останавливают ключевые сервисы и нередко выводят из строя всю виртуальную и физическую инфраструктуру. Часто первым сигналом становится деградация: сервисы начинают подвисать, гипервизоры и хранилища уходят в 100% загрузку. Дальнейший исход зависит от дисциплины и подготовки: ясных норм для центра мониторинга и реагирования на инциденты безопасности (Security Operations Center, далее — SOC), жестких правил доступа и готовности команды с холодной головой действовать по плану.

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

Атаку шифровальщика сложно с чем-то перепутать: документы не открываются, всплывают ошибки прав, общие папки исчезают. Почтовый сервер, ERP (Enterprise Resource Planning — система планирования ресурсов предприятия) и CRM (Customer Relationship Management — система управления взаимоотношениями с клиентами) перестают отвечать. Процедура входа дает сбой без видимых причин. И, в конце концов, в корневых каталогах появляются текстовые файлы с контактами и суммой выкупа.

Инфраструктурный слой реагирует жестче. Гипервизоры и системы хранения данных упираются в 100% загрузки по центральному процессору и вводу-выводу, метрики застывают на пике. Начинается массовая модификация образов виртуальных машин, растут очереди записи, снимки состояния удаляются. Кластеры сообщают о деградации, узлы исключаются из пулов. Десятки рабочих станций одновременно обращаются к одному файловому ресурсу. 

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

В некоторых случаях может появляться нетипичный трафик по SMB (Server Message Block — протокол обмена файлами и принтерами в сетях Windows), WinRM (Windows Remote Management — протокол удаленного управления Windows) или PowerShell Remoting (удаленное выполнение команд через PowerShell) между хостами, которые обычно не взаимодействуют, но чаще это характерно для этапа латерального перемещения, а не самой атаки. Иногда фиксируются исходящие соединения на неизвестные адреса, особенно в ночные часы, но это не обязательный признак: может быть как единичная команда с C2 (Command and Control — сервер управления атакой) на центр управления внутри сети, так и действие через GPO (Group Policy Object — объект групповой политики).

Существует ряд типовых сложностей в мониторинге и выявлении потенциально опасных действий. SOC ищет отклонения от нормы, но сама норма формируется внутри компании. Без контекста от владельцев систем повседневные скрипты, массовое использование Process Execution и нестандартные административные практики могут восприниматься как подозрительная активность. Система задает вопрос — допустимы ли эти действия? — но часто не получает ответа. В результате действительно опасные сигналы теряются в общем потоке.

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

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

Любые участки инфраструктуры, из которых не поступают данные в систему мониторинга, создают слепые зоны. При отсутствии логирования, агентов и централизованного контроля SOC теряет обзор и не может своевременно выявлять инциденты. Чтобы восстановить видимость, проводят инвентаризацию инфраструктуры, подключают источники по унифицированным схемам и обеспечивают стабильную доставку данных в соответствии с SLA (Service Level Agreement — соглашение об уровне обслуживания). Только при достаточном объеме и качестве поступающей информации можно выявить угрозы.

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

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

Слепые зоны нередко возникают из-за тестовых, временных или забытых серверов. Такие узлы остаются без учета и документации, поэтому непонятно, кто и как ими управляет. Они создают неконтролируемые риски, так как содержат ряд невыявленных уязвимостей. Через такие точки злоумышленники легко получают начальный доступ в сеть.

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

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

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

Собранные артефакты следует систематизировать в виде индикаторов компрометации (IoC — Indicators of Compromise): хэши вредоносных файлов, IP-адреса командных серверов, домены, пути размещения вредоносного ПО, ключи реестра, сигнатуры сетевого трафика. Эти данные критически важны не только для внутреннего расследования, но и для обмена с сообществом ИБ через платформы threat intelligence (например, через ФинЦЕРТ для финансового сектора или отраслевые центры ГосСОПКА). Оперативный обмен IoC позволяет другим организациям заранее защититься от аналогичных атак, а вашей компании — получить дополнительную информацию о тактиках злоумышленников. При этом важно соблюдать баланс: делиться техническими индикаторами, но не раскрывать чувствительную информацию о собственной инфраструктуре.

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

1. Восстановление из резервных копий
   Самый быстрый путь возврата к работе, но не всегда надежный. Наличие резервных копий не гарантирует быстрого возврата к работе, если они годами не проверяются, носители и программное обеспечение устаревают. Дополнительный риск заключается в том, что вместе с данными можно перенести закладки, которые оставил злоумышленник. Поэтому резервные копии стоит проверять перед запуском, а развертывание по возможности выполнять в «чистой» зоне под мониторингом ИБ. Пользовательские машины обычно проще перезалить из проверенных образов.

2. Развертывание параллельного «чистого» контура
   Сначала поднимается базовая инфраструктура в отдельном сегменте, затем туда переносятся проверенные данные и сервисы из скомпрометированной зоны. Такой подход снижает вероятность повторного входа через старые закладки и позволяет постепенно запускать ключевые функции. В реальных кейсах так восстанавливали, например, почтовые системы: новая площадка запускалась сразу, а старую приводили в порядок позже.

3. Полный подъем с нуля
   Установка базовых служб, запуск прикладных систем и восстановление данных из безопасных источников. Этот путь тяжелый по срокам и ресурсам, но иногда другого пути нет. Например, в ритейле встречались сценарии, когда точкам продаж оказывалось быстрее перезалить данные на местах, чтобы продолжить работу, а центральную инфраструктуру приводить в рабочее состояние параллельно.

Критически важным элементом первичного реагирования является своевременное уведомление регуляторов. Для субъектов КИИ это означает незамедлительное информирование НКЦКИ ФСБ России (на практике — в течение 2 часов) и ГосСОПКА в течение 24 часов с момента обнаружения инцидента. При компрометации персональных данных необходимо уведомить Роскомнадзор в течение суток, а финансовым организациям — ФинЦЕРТ Банка России в течение 3 часов для критичных инцидентов. 

Несвоевременное уведомление влечет административную ответственность и штрафы до 500 тысяч рублей для организаций. Поэтому в план реагирования следует заранее включить шаблоны уведомлений, контакты ответственных лиц в регулирующих органах и четкую процедуру фиксации временных меток — от первых признаков инцидента до момента отправки уведомления. Допускается предоставление предварительной информации с последующим уточнением деталей в течение 48–72 часов, что позволяет не затягивать с первичным информированием даже при неполной картине происходящего.

Главный риск при дешифровке и восстановлении из бэкапов — случайно перенести закладки от злоумышленника и оставить ему пути возврата. Вместе с необходимыми системами в инфраструктуру легко принести дополнительные учетные записи, легальные VPN-клиенты, задания планировщика, измененные групповые политики и службы, которые использовались для закрепления. Чтобы снизить эти риски, стоит разворачивать базовые службы заново в отдельной «чистой» зоне и переносить туда только проверенные данные и образы рабочих станций. 

Права доступа нужно привести к минимально необходимым. Следует разделить учетные записи для повседневной работы и администрирования, обновить пароли у локальных администраторов и сервисных учетных записей, проверить состав групп с повышенными привилегиями и включить флаг Protected Users для административных записей. Там, где это допустимо, стоит ограничить SMB-доступ с клиента на сервер. Эти шаги затрудняют латеральное перемещение после восстановления.

Системы централизованного управления требуют отдельной ревизии. Следует заново поднять центры управления и обновлений, проверить GPO, скрипты входа и задания планировщика, удалить неизвестные службы и утилиты удаленного доступа. Пакеты, которые распространяются централизованно, должны иметь понятное происхождение и быть получены из доверенного источника. Это снижает риск повторного проникновения.

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

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

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

Внешние сообщения должны быть конкретными. Следует коротко описать, что произошло, какие данные могли утечь, какие меры уже приняты и что компания планирует делать дальше. Обещания нужно давать только те, которые можно выполнить. Если есть риск публикаций на сторонних ресурсах, полезно подключить услугу Brand Protection для отслеживания упоминаний и распространяемых файлов и оперативно обновлять публичную позицию с опорой на новые факты.

Следует также объяснить сотрудникам, что известно на текущий момент, какие действия обязательны прямо сейчас, какие каналы использовать для вопросов и куда передавать потенциально важные артефакты для расследования. Важно выдать понятные инструкции по паролям, доступам, работе с почтой и осторожности в отношении фишинга в период восстановления. Это помогает избежать самодеятельности и утечки непроверенной информации.

В спокойный период аудит снизит вероятность успешной атаки, а если взлом уже произошел — ускорит восстановление и позволит убрать закладки.

Базовую проверку следует повторять раз в три–шесть месяцев и после значимых изменений: например, при запуске новых площадок, открытии сервисов в DMZ (Demilitarized Zone — изолированная демилитаризованная зона сети, отделяющая внутренний контур от внешнего), замене решений для бэкапов или центров управления и обновлений.

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

Далее оценивается работа мониторинга. Имеет смысл провести как инвентаризационный, так и функциональный аудит. В инвентаризационном — понять, с каких источников собираются журналы и события, оценить полноту покрытия. В функциональном — увидеть, все ли события корректно обрабатываются, как работают правила корреляции и дальнейшей обработки инцидентов. С этой задачей хорошо справляются системы типа BAS (Breach and Attack Simulation — симуляция атак и нарушений для проверки защиты), или можно заказать услугу у внешних специалистов (pentest).

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

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

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

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

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