Короткий ответ

Подтверждённый шифровальщик на WS-042 или host.example: изолируйте узел от сети, питание и диск не трогайте, записку и расширение не удаляйте. Не платите. Не запускайте «decryptor с форума», chkdsk, полный AV-wipe и очистку карантина как первый шаг. Не монтируйте backup-репозиторий с этого же ПК. Ищите незатронутую копию с чистого jump. Люди — не открывать шары «посмотреть, заражено ли».

Параллельно: массовое переименование если ещё идёт, изоляция, первые 15 минут.

Симптомы и как отличить

Типично:

  • документы не открываются, расширение сменилось пачкой;
  • на рабочем столе текстовая записка с требованием;
  • Microsoft Defender: 1116/1117, имя семейства ransomware (не CVE — имя семейства из карантина);
  • на Linux: массовый mv/rename в домашних и на NFS, load на диске.
СигналНе ransomwareДействие
Один файл «не открывается»битый Office, карантинне объявлять IR на всю фирму
BitLocker recovery на логонеключ TPMне путать с шифрованием файлов
Реплика DFS «конфликт»синхронизациясмотреть версию, не записку
Массовый rename без запискиещё ранний этаппереименование

Возможные причины

  1. Фишинговое вложение/макрос на WS-042вложение.
  2. Украденный RDP/VPN без MFA, ручной запуск.
  3. Троян, который антивирус видел вчера, а persistence осталась — троян.
  4. Заражение через открытую шару с другого ПК (уже lateral).
  5. Скомпрометированная учётка с правами на FS01.
  6. Редко: сбой СХД/снапшоты, который пользователь назвал «шифровальщиком» — отличите по отсутствию записки и по журналу массива.

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

Диагностика

Цель часа — масштаб и направление, не реверс бинарника.

1. Не ходить с заражённого стола

С hop-хоста (или консоли гипервизора, если это VM):

  • сеть: отключить vNIC / физический кабель / порт коммутатора;
  • питание: On;
  • не reboot.

2. Зафиксировать индикаторы без «лечения»

Windows:

New-Item -ItemType Directory -Force C:\IR\ransom | Out-Null
Get-MpThreatDetection | Format-List *
Get-Process | Select-Object Name, Id, Path | Out-File C:\IR\ransom\proc.txt
Get-Volume | Format-Table DriveLetter, FileSystemLabel, SizeRemaining
Get-WinEvent -FilterHashtable @{ LogName='Microsoft-Windows-Windows Defender/Operational'; Id=1116,1117; StartTime=(Get-Date).AddDays(-3) } |
  Format-List TimeCreated, Id, Message

Не копируйте подозрительный .exe на файловый сервер «чтобы коллеги посмотрели». Hash считайте локально, выгрузка — на выделенный IR-носитель.

# только если файл ещё не заблокирован и путь известен из Defender
Get-MpThreat | Format-List

Linux host.example:

sudo mkdir -p /var/ir/ransom
ps aux > /var/ir/ransom/ps.txt
sudo lsof +L1 > /var/ir/ransom/lsof-deleted.txt 2>/dev/null || true
df -h > /var/ir/ransom/df.txt
sudo journalctl --since '3 days ago' > /var/ir/ransom/journal.txt

3. Карта поражения

Какие шары/VM ещё пишутся? Есть ли encryptor на FS01? Идут ли backup job на уже грязные данные? Проверяйте с чистого jump, не с WS-042.

4. Backup жив?

Отдельный контур, отдельные учётки. Если копии уже удалены — backup стёрт. Не запускайте новый backup с зашифрованного тома «на всякий» как замену точке «до».

Решение

Сценарий A. Один ПК, шары не тронуты

  1. Изоляция WS-042.
  2. Сбор журналов/памяти по артефактам.
  3. Остальные ПК: не открывать те же вложения; при необходимости временный блок SMB исходящий с пользовательского VLAN на FS (согласовать с бизнесом).
  4. Восстановление файлов пользователя из копии в чистый профиль, не «decrypt на месте».
  5. Переустановка ОС после снятия улик — штатный исход для рабочей станции. Не обещайте «почистим и оставим».

Сценарий B. Поражены шары / сервер

  1. Отключить SMB для клиентского VLAN или перевести шару в read-only если ещё не поздно (часто уже поздно — тогда стоп сервиса, чтобы не добить остаток).
  2. Не format FS01 в первый час.
  3. Restore в изолированную сеть из точки до времени начала (записка и 1116 задают нижнюю границу).
  4. Ротация учёток, которые имели write на шару — учётки.

Сценарий C. Просят заплатить

Фиксируйте отказ в тикете. Оплата не гарантирует ключ, не снимает отчётность и финансирует следующую волну. Юридический трек — вне этой инструкции; технический путь: изоляция + backup.

Если записка требует связаться с 10.0.10.55 или «оператором» — не отвечайте. Учётка ivan.petrov на этом ПК считается грязной: сессии и пароль по ротации, даже если «шифровались только файлы».

Как проверить, что проблема устранена

  • С WS-042 нет сети до FS/backup/DC (кроме согласованного IR-коллектора, если он вообще нужен).
  • Новые файлы на шарах не меняют расширение.
  • Точка restore выбрана по времени «до», просмотрена в песочнице.
  • Учётки с write на поражённые ресурсы проверены/сменены.
  • Записка и образцы лежат в IR, не уничтожены.
  • Пользователи работают с восстановленных данных, не с «полурасшифрованного» диска.

Если не помогло

  • Шифрование продолжается на FS после изоляции ПК — жив другой хост или серверная сессия. Ищите 4624 Type 3, не выключайте SAN целиком без плана.
  • Backup недоступен — offsite/immutable, иначе честный разговор про потерю, не «ещё один AV-скан».
  • VM выключили до дампа — работайте с диском, память потеряна; не включайте в прод-сеть «на пять минут».
  • Антивирус удалил encryptor и «всё заработало» на трёх файлах — остальной диск может быть мёртв; не объявляйте победу.

Профилактика

  • MFA на VPN/RDP, закрытый 3389.
  • Не Domain Admin на почте и браузере.
  • Immutable + offsite backup, раздельные учётки backup.
  • Ограничение SMB: клиент не пишет на чужие домашние каталоги без нужды.
  • Учения: изоляция ПК за 5 минут, restore папки за согласованный RTO.

FAQ

Можно ли выдернуть кабель и сразу поставить Windows заново?

Кабель — да. Переустановка — после снятия журналов и решения, нужны ли диск/память как улика. Иначе потеряете 4688 и Prefetch.

Нужно ли выключать всю фирму из VPN?

Если идёт распространение по VPN-клиентам — да, по решению IR. Если один изолированный ПК и шары чистые — точечно. Классифицируйте за минуты, не ждите «ещё понаблюдаем».

Антивирус предлагает Repair сейчас

На живом шифровании Repair/карантин может испортить улики и не вернёт данные. Изоляция важнее. Defender оставьте включённым на здоровых машинах.

Пользователь уже заплатил со своего кошелька

Не подключайте «полученный decryptor» к домену. Разбор — отдельно, диск считайте недоверенным.

Linux без записки, но файлы *.locked

Считайте инцидентом шифрования, пока не доказано иное. Тот же порядок: сеть, улики, backup.