Атака шифровальщика: пошаговый план действий для бизнеса в первые часы

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

Отключите Ethernet-кабель, Wi-Fi и другие сетевые подключения. Аналогично стоит поступить с другими устройствами, на которых видны признаки атаки.

При этом без необходимости не следует сразу выключать компьютер.

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

Поэтому базовая последовательность выглядит так:
обнаружили признаки шифрования → изолировали устройство от сети → зафиксировали время и симптомы → передали специалистам.

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

Цена нескольких минут недоступности обычно значительно ниже цены зашифрованных серверов и резервных копий.

Следующая задача – определить, затронут один компьютер или инфраструктура компании.

Необходимо проверить:

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

Особое внимание – файловым ресурсам.

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

Поэтому важен не только зараженный компьютер, но и все ресурсы, к которым он имел доступ.

Один из главных приоритетов – убедиться, что атака не добралась до резервного копирования.

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

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

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

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

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

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

Шифровальщик может оказаться только финальным этапом атаки.

До запуска вредоносного ПО злоумышленник мог получить пароль сотрудника, подключиться через VPN, украсть административную учетную запись или закрепиться в инфраструктуре другим способом.

Поэтому необходимо проверить подозрительные входы и административные действия.

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

Особенно критичны:
администраторы домена → VPN → облачная инфраструктура → резервное копирование → гипервизоры → удаленный доступ.

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

Во время серьезной атаки быстро возникает организационный хаос.

ИТ пытается восстановить серверы. Руководители требуют срочно вернуть CRM. Сотрудники спрашивают, можно ли включать компьютеры. Клиенты звонят менеджерам. Юристы пытаются понять, произошла ли утечка данных.

Поэтому у инцидента должен быть один координатор.

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

Полезно сразу разделить направления:

• техническая команда – локализует атаку и занимается восстановлением;
• руководство – определяет приоритеты бизнес-процессов;
• информационная безопасность – расследует способ проникновения и масштаб компрометации;
• юристы и ответственные за персональные данные – оценивают необходимость предусмотренных законом действий;
• коммуникации – работают с сотрудниками, клиентами и партнерами, если это необходимо.

Серьезная кибератака быстро перестает быть исключительно проблемой системного администратора.

Еще одна распространенная ошибка – пытаться как можно быстрее «почистить» инфраструктуру.

Удаляются файлы, переустанавливаются системы, очищаются журналы событий.

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

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

• Это позволит позднее ответить на ключевые вопросы:
• Как злоумышленник попал внутрь?
• Когда произошло проникновение?
• Какие учетные записи были скомпрометированы?
• Какие системы были затронуты?
• Могли ли данные быть не только зашифрованы, но и похищены?

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

После локализации нельзя просто восстанавливать серверы в произвольном порядке.
Нужно исходить из влияния на бизнес.

Например:
Приоритет 1: Active Directory, сеть, DNS и другая базовая инфраструктура.
Приоритет 2: системы, без которых остановлены продажи или производство.
Приоритет 3: ERP, CRM, файловые ресурсы и другие бизнес-сервисы в зависимости от процессов компании.
Приоритет 4: менее критичные внутренние системы.

Конкретный порядок будет разным для каждого бизнеса.

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

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

Если просто восстановить данные на скомпрометированный сервер, проблема может повториться.

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

В отдельных случаях безопаснее развернуть систему заново, чем пытаться очистить существующую.

В момент остановки бизнеса идея «просто заплатить и вернуть данные» может казаться самым быстрым вариантом.

Но выплата не гарантирует восстановления.

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

Кроме того, существуют юридические и санкционные риски, которые необходимо отдельно оценивать со специалистами.

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

Основной сценарий восстановления бизнеса должен строиться вокруг собственной способности локализовать инцидент и восстановить инфраструктуру.

Несколько действий способны ухудшить ситуацию.

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

Не начинайте массовое восстановление, пока атака не локализована.

Не удаляйте все следы вредоносного ПО до их фиксации специалистами.

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

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

Не считайте восстановление файлов окончанием инцидента. Необходимо определить первоначальную точку проникновения и устранить ее.

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

Поэтому бизнесу заранее стоит проверить четыре вещи.

Резервное копирование. Есть отдельные копии и они действительно восстанавливаются.

Доступы. Административные права ограничены, критичные учетные записи защищены.

Мониторинг. Подозрительные события можно обнаружить достаточно быстро.

План реагирования. Сотрудники понимают, кого уведомлять и кто принимает решения при инциденте.

Полезно периодически проводить учебный сценарий.

Например: «В 10:00 обнаружено массовое шифрование файлов. Файловый сервер частично недоступен. Что мы делаем следующие два часа?»

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