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

Злоумышленник удалил backup: прекратите доступ прод-админов к репозиторию, изолируйте backup-сеть, не входите на Repo/VBR/PBS учёткой Domain Admin с WS-042. Ищите immutable (object lock, hardened repo, PBS prune lock) и offsite. Онлайн-копия, которую видит тот же DA, считайте мёртвой, пока не доказано иное. Не отключайте immutability «чтобы почистить мусор». Не format тома репозитория в первый час.

Параллельно шифровальщик на данных — ransomware. Логи backup стерты — журналы.

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

  • Консоль Veeam: backups отсутствуют, jobs Disabled.
  • \\backup\Repo01 пуст или файлы с чужим расширением.
  • PBS: datastore prune, namespace пуст.
  • Windows Server Backup: каталог теней пуст.
  • Совпадает с 4728/компрометацией админа.
КартинаНе атакаКуда
Retention съела точки по политикекалендарьвсё равно проверьте last good
Диск Repo заполнен, job failёмкостьне delete chain вручную
Immutable не даёт удалить — Access Deniedзащита сработалаэто хорошо
Админ сам удалил «тест»changeвсё равно IR, если прод

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

  1. Украден DA / учётка backup с правом delete.
  2. Ransomware добрался до SMB-репозитория.
  3. Скомпрометированная консоль VBR/PBS root.
  4. Облачный ключ object storage с s3:DeleteObject без lock.
  5. Ошибочный скрипт prune.
  6. Сбой СХД, похожий на удаление (смотрите массив до обвинения).

Диагностика

Только с чистого jump, отдельные учётки.

1. Не ходить с заражённых ПК

Сеть: ACL, запрет SMB с users VLAN на backup. Изоляция VBR если консоль открывали грязной сессией.

2. Что осталось

Документируйте: локальные диски, object lock, второй ЦОД, лента, PBS remote, облачный immutable.

Linux PBS/host.example как репозиторий:

df -h
sudo ls -la /mnt/datastore | head
sudo journalctl -u proxmox-backup --since '7 days ago' | tee /var/ir/pbs.log | tail

Windows repo:

Get-ChildItem D:\Backups -ErrorAction SilentlyContinue | Select-Object -First 20
Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=1102,4720,4728; StartTime=(Get-Date).AddDays(-7) }

Veeam: откройте консоль не под DA продакшена, если есть отдельный backup admin.

3. Кто удалил

Логи VBR, Windows Security 4663 если был аудит объектов, Linux auditd, облачный CloudTrail-аналог. Если логи стёрты — сам факт 1102 = продолжение инцидента.

Решение

Сценарий A. Immutable/offsite живы

  1. Оставить их в покое, не монтировать к прод-VLAN.
  2. Restore в изолированную сеть из этой точки.
  3. Ротация всех учёток, которые видели Repo — секреты.
  4. Онлайн-Repo не использовать как источник, пока не проверен.

Сценарий B. Всё онлайн удалено, offsite нет

Это потеря точек. Честно эскалируйте бизнесу. Дальше — что осталось на прод-дисках и теневые копии томов если ransomware их не вычистил. Не обещайте чудо. Фокус: стоп атаки, чтобы не добить прод.

Сценарий C. Удаление идёт прямо сейчас

Shutdown access к Repo, остановить job delete, отозвать сессии консоли. Питание дисков backup оставить. Не reboot ради «может отпустит».

Каталог, лента и кто имел Delete

Пустой каталог Veeam не равен пустому диску: сделайте rescan с backup-admin, не с ivan.petrov из Domain Admins. Если файлы на Repo есть, а консоль пуста — это каталог, не атака удаления. Если файлов нет — ищите object lock, второй ЦОД, ленту, PBS remote. Пароль root host.example (PBS) и SMB Repo с write у DA — одна причина «удалили за минуту».

Не подключайте найденный USB с «спасительными vbk» к прод-гипервизору: сначала изолированная сеть, антивирус на копии, не original overwrite. Логи удаления могли стереть (1102) — сам факт очистки журнала backup-сервера усиливает версию атаки. IP 10.0.10.55 в логах SMB/консоли — плацдарм, изолируйте его как хост, не как «ещё один клиент Veeam».

Онлайн-Repo после компрометации DA считайте недоверенным даже если «папка на месте»: могли подменить точки. Offsite/immutable — источник restore.

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

  • С прод-учёток нет write/delete на Repo.
  • Найдена хотя бы одна непроверенная? проверенная точка offsite/immutable.
  • Атака на backup-контур не продолжается (нет новых delete).
  • Restore test в изоляции (не original overwrite).
  • Учётки backup сменены, MFA на консоль.
  • Постинцидент: почему DA дотягивался — в разборе.

Не монтируйте offsite к тому же VLAN, откуда удаляли. Смена пароля ivan.petrov и DA — параллельно поиску ленты, не после «найдём точки». IP 10.0.10.55 с Delete — изоляция плацдарма.

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

  • Object lock был 0 дней — это не immutable. Считайте хранилище как обычный диск.
  • PBS prune под root с jump атакующего — ключи root скомпрометированы, смотрите весь host.example.
  • Вторая копия в том же домене/том же VLAN — сгорит той же волной.
  • Админ уже format D: — останавливайтесь, forensic диска если нужно, не второй format.

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

  • 3-2-1, offsite, immutability с сроком > окна обнаружения.
  • Backup admin ≠ Domain Admin продакшена.
  • MFA на VBR/PBS.
  • Алерт на delete job / пустой datastore.
  • Регулярный restore test.

FAQ

Запустить backup сейчас на другой USB?

Только если источник ещё не зашифрован и USB не подключите к грязному ПК. Не вместо поиска offsite.

Veeam «Forgot» точки после переустановки БД каталога

Каталог не есть файлы. Ищите файлы на Repo и rescan. Если файлов нет — это удаление, не каталог.

Нужно ли платить выкуп за ключ к .vbk?

Нет как стратегия IR. Даже при ключе цепочка может быть битой. Offsite важнее.

WSB на том же DC

Это не offsite. Если DC скомпрометирован, тени локального тома часто тоже.

Кто принимает решение «данных нет»?

Владелец данных + ИТ показывают оставшиеся носители. Не один админ в чате в 3 часа ночи.