Шифровальщик добрался до сервера: первые полчаса решают всё

MAATRIX

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

Первые пять минут: изолировать, а не выключать

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

Правильное первое действие — разорвать сетевую связность, оставив систему включённой:

• физический сервер: выдерните сетевой кабель или отключите порт на коммутаторе, но не трогайте питание;
• VPS/облако: заблокируйте весь трафик на уровне security group или файрвола провайдера, либо отключите виртуальный сетевой интерфейс через панель управления — машина продолжает работать изолированно;
• если под рукой гипервизор (Proxmox, VMware): снимите виртуальную сетевую карту с моста (vmbr) или переведите её в изолированный vNIC без выхода наружу.

Для Linux-сервера, к которому у вас ещё есть локальный доступ (консоль хостинга, IPMI, KVM), интерфейс можно погасить командой:

ip link set eth0 down

Это надёжнее, чем полагаться на iptables — правило файрвола шифровальщик или его вторая стадия теоретически может переписать, а поднятый интерфейс без правил всё равно продолжает пытаться резолвить DNS и стучаться наружу. Физическое (или гипервизорное) отключение интерфейса такого риска не оставляет.

Если платформа поддерживает живой снапшот диска без остановки машины (Proxmox qm snapshot, снапшот тома у облачного провайдera) — сделайте его сразу после изоляции. Это фиксирует состояние диска для расследования и даёт возможность откатиться к «моменту после атаки», не потеряв улики, если что-то пойдёт не так при дальнейших действиях.

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

Не платите выкуп сгоряча

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

Причины не платить немедленно:

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

Практический подход — не принимать решение о выкупе как о первом шаге, а вынести его в конец списка, после того как вы:

1. изолировали и зафиксировали систему;
2. проверили, есть ли рабочий чистый бэкап (см. ниже) — если да, вопрос о выкупе часто снимается сам собой;
3. проверили публичные базы бесплатных дешифраторов — иногда ключи для конкретного семейства шифровальщиков публикуются правоохранительными органами или исследователями через месяцы или годы после волны атак, и то, что нерасшифровываемо сегодня, может стать расшифровываемым позже;
4. по возможности проконсультировались со специалистом по реагированию на инциденты — профессиональные переговорщики знают репутацию конкретных групп по возврату данных после оплаты, у вас такой статистики нет.

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

Сохраните зашифрованные файлы — они ещё могут пригодиться

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

Причины хранить копии:

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

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

Проверьте, куда шифровальщик успел дотянуться

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

Что стоит проверить в первую очередь, до полного расследования:

• другие серверы и рабочие станции в той же сети — особенно те, что используют общие учётные записи или доверенные SSH/RDP-подключения к заражённой машине;
• сервер бэкапов — это частая вторая цель, потому что доступ к нему часто настроен через ту же учётную запись, что и к основным серверам;
• журналы подключений — неожиданные входы, новые сессии в нерабочее время:

last -a
w
journalctl -u sshd --since "-2 days"

• новые или изменённые задания по расписанию — частый способ закрепления:

crontab -l
ls -la /etc/cron.d/

в Windows — Get-ScheduledTask в PowerShell;

• новые SSH-ключи и учётные записи:

cat ~/.ssh/authorized_keys
cat /etc/passwd | tail -20

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

Бэкапы: убедитесь, что они действительно чистые

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

Проверьте по порядку:

Ключевая ошибка, которая встречается почти в каждом разборе подобных инцидентов, — бэкап лежал на том же сервере или в той же сети без изоляции, поэтому шифровальщик добрался и до него. Если у вас пока нет отдельного, недоступного из рабочей сети хранилища копий — это первое, что стоит исправить после того, как текущий инцидент закрыт. Практическая схема — правило 3-2-1 (минимум три копии, на двух разных носителях, одна вне основной площадки) плюс хотя бы одна копия в режиме, недоступном для перезаписи из заражённой сети: офлайн-копия, отдельный сервер с ограниченным доступом или бэкап с append-only режимом хранения. Если система бэкапов ещё не настроена или настроена без такой изоляции, у вас в блоге есть пошаговые инструкции по BorgBackup и UrBackup — оба поддерживают режимы, устойчивые именно к такому сценарию.

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

План реагирования, который работает, только если готов заранее

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

Минимальный рабочий план должен отвечать на вопросы:

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

Такой план стоит не просто написать, а хотя бы раз в год проверить учениями — попробовать восстановиться из бэкапа на тестовом стенде и засечь, сколько это реально занимает времени. Число, полученное на учениях, обычно расходится с тем, что казалось «на бумаге», и лучше узнать это не во время настоящей атаки. Более подробный разбор структуры такого плана и его отличий от плана восстановления после обычного сбоя — в статье «Incident response plan: что делать при взломе».

Частые вопросы