Атака шифровальщика: что делать? Пошаговый план реагирования на инцидент ИБ

Атаки с шифрованием инфраструктуры давно перестали быть редкими инцидентами. Злоумышленники атакуют серверы, рабочие станции, системы виртуализации, учётные записи администраторов и резервные копии, после чего компания может одновременно потерять доступ к данным и ключевым бизнес-системам.

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

Чем раньше компания начинает действовать по понятному плану, тем больше шансов ограничить масштаб поражения.

Главное правило при атаке шифровальщика: не путать восстановление с устранением инцидента.

Рабочая резервная копия позволяет восстановить данные, но не отвечает на вопрос, остался ли у злоумышленника доступ к инфраструктуре. Если атакующий сохранил учётную запись, закладку или другой способ доступа, восстановленные системы могут быть повторно скомпрометированы.

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

Также не удаляйте записку с требованием выкупа и зашифрованные файлы, не запускайте случайно найденные дешифраторы, не подключайте резервные копии обратно к заражённой сети и не начинайте массовое восстановление, пока не перекрыт доступ злоумышленника, и, естественно, не подключайте к инфраструктуре личные устройства.

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

1. Остановить хаос и назначить одного ответственного.
Зафиксируйте время обнаружения атаки, какие системы уже затронуты, что перестало работать и какие действия сотрудники успели выполнить.

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

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

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

2. Изолировать заражённые системы.
Первая задача — не дать атаке распространиться дальше. Отключайте заражённые сегменты, межсетевые соединения, VPN и другие каналы, через которые компрометация может распространяться по инфраструктуре.

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

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

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

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

Смотрите историю не только за последние часы. Злоумышленник мог находиться внутри инфраструктуры несколько дней или недель до начала шифрования. Если журналы хранятся локально, скопируйте их на отдельную систему или носитель, который не находится в заражённой сети. Делать это нужно как можно раньше: старые записи могут автоматически перезаписываться.

4. Защитить резервные копии.
Проверьте, какие резервные копии сохранились и за какую дату есть рабочая версия данных. Если резервная инфраструктура ещё доступна, изолируйте её от рабочей сети.

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

5. Определить масштаб поражения.
Составьте простой перечень систем и отметьте их состояние: работает, зашифрована, недоступна, подозрительная. Отдельно укажите, какие системы критичны для бизнеса.

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

6. Проверить Active Directory.
Посмотрите, не появились ли новые учётные записи, изменения в группах администраторов и групповых политиках. Проверьте активные контроллеры домена и учётные записи с повышенными привилегиями.

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

7. Закрыть внешние точки доступа.
Проверьте VPN, RDP, SSH, AnyDesk, TeamViewer, RMM-системы и другие средства удалённого доступа. На время расследования отключите ненужные внешние сервисы и доступ подрядчиков.

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

Если подозрительный файл или программа, связанная с атакой, сохранились, не запускайте их самостоятельно. Сам образ вредоносной программы может понадобиться для анализа.

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

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

10. Менять пароли после изоляции.
Не начинайте инцидент с массовой смены всех паролей. Сначала перекройте внешние каналы доступа и определите, какие учётные записи могли быть скомпрометированы.

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

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

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

На этом этапе задача не в том, чтобы немедленно восстановить всю ИТ-инфраструктуру. Нужно сохранить способность компании работать, пока основная среда исследуется и восстанавливается.

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

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

Ниже небольшой чек-лист, в чем нужно убедиться перед возвращением восстановленных систем в рабочую сеть:

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

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

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

Если после атаки нет уверенности, какие системы и учётные записи были скомпрометированы, имеет смысл провести проверку инфраструктуры до начала масштабного восстановления.

И в обязательном порядке следует провести проверку, в идеале, в формате пентеста (моделирования кибератаки) и аудита информационной безопасности, после восстановления. Это важно, чтобы убедиться, что у злоумышленника не осталось доступа, а причина инцидента устранена.

Мы в АБП2Б можем с этим помочь, смело связывайтесь с нашими специалистами.

А если вы читаете эту статью превентивно на случай возможной атаки, то, помимо проработки плана реагирования, пожалуйста, заранее проверьте, насколько ваша инфраструктура подготовлена к атаки вируса-шифровальщика (ransomware attack): сегментирована ли сеть, защищены ли резервные копии, корректно ли восстанавливаются резервные копии, соблюдены ли базовые меры безопасности, о которых мы подробно писали ранее.

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