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

Массовый rename — часто ранняя фаза шифровальщика или wiper, иногда кривой скрипт бэкапа. Пока имена сыплются, цель — остановить источник (хост/учётка/процесс) и снять индикаторы: путь процесса, SHA-256, родитель, сеть, расширение. Не делайте массовый rollback rename на живой шаре и не «лечите» карантином весь FS01 в первый час. Не удаляйте подозрительный бинарник до копии/хеша.

Если записка уже есть — переходите к шифровальщику. Изоляция — без уничтожения данных.

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

  • На WS-042 пользователь видит, как Договор.docx становится Договор.docx.xyz пачками.
  • На файловом сервере диск 100%, очередь SMB.
  • Linux host.example: lsof показывает один PID, который пишет тысячи файлов в /srv/data.
  • Defender ещё молчит или только 1116 на dropper.
КартинаИноеЧто делать
OneDrive/синхронизация «Conflict»клиент облакане IR ransomware, пока нет массового расширения
Архиватор распаковал 10k файловлегитимный unzipпроцесс 7z/tar, известный пользователь
Ротация логов *.1.gzlogrotateтолько /var/log, не пользовательские документы
Скрипт миграции ИТзаявленный changeсверка с окном работ

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

  1. Ransomware/wiper на WS-042, пишет на локальный диск и на \\fs01\share.
  2. Скомпрометированная учётка ivan.petrov с mapped drive, процесс на другом ПК.
  3. Легитимный, но опасный скрипт (перенос архива, «навести порядок в именах»).
  4. Троян-загрузчик ещё без шифрования — троян.
  5. Ошибочный mv /data /data.bak админом на Linux.
  6. Редко: сбой СХД, отображающий «странные» имена — смотрите массив, не только ОС.

Диагностика

Параллельно изоляции источника.

1. Кто пишет

Windows:

Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 20 Name, Id, Path
Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4688; StartTime=(Get-Date).AddHours(-6) } -MaxEvents 50 |
  Select-Object TimeCreated, Message
Get-SmbOpenFile -ErrorAction SilentlyContinue

На файловом сервере (не с заражённого ПК):

Get-SmbOpenFile | Group-Object ClientComputerName | Sort-Object Count -Descending | Select-Object -First 10
Get-SmbSession | Format-Table ClientComputerName, ClientUserName, NumOpens

Linux:

sudo lsof /srv/data 2>/dev/null | head
sudo pidstat -d 1 5
sudo auditctl -l
# если auditd уже пишет:
sudo ausearch -f /srv/data --start recent | tail

2. Индикаторы (без реверса эксплойта)

  • Расширение/префикс новых имён.
  • SHA-256 процесса:
Get-FileHash -Algorithm SHA256 -Path 'C:\Users\ivan.petrov\AppData\Local\Temp\sample.exe'
sha256sum /tmp/sample
ls -l --time-style=full-iso /tmp/sample
  • Сеть процесса: Get-NetTCPConnection -OwningProcess <pid>, ss -p.
  • Учётка: кто открыл шару.

Не разбирайте макрос «как запустить payload». Для IR достаточно: файл вложения сохранили, hash, откуда пришёл — фишинг.

3. Масштаб

Список томов и UNC, где уже новые расширения. Есть ли backup job, который сейчас снимает это дерево.

Решение

Сценарий A. Источник — один WS-042

  1. Снять с сети (кабель/vNIC/порт). Питание оставить.
  2. На FS01: закрыть сессию этого клиента (Close-SmbSession), при необходимости шару в offline/read-only.
  3. Скопировать IOC в тикет, журналы — в IR.
  4. Не «лечить» шару тем же антивирусом с write с заражённого стола.
Get-SmbSession | Where-Object { $_.ClientComputerName -match 'WS-042' -or $_.ClientUserName -match 'ivan.petrov' }
# Close-SmbSession -SessionId <id>  — только после фиксации ClientComputerName в тикете

Сценарий B. Источник — сервер host.example

Изолируйте сервер так же. Не kill -9 до ps, lsof, hash. После фиксации остановите конкретный PID/unit, не shutdown now.

Сценарий C. Это свой скрипт

Остановите задание, восстановите из backup/снимка, разбор change — после. Факт «мы сами» всё равно пишите в IR: массовый rename без окна — инцидент доступности.

На 10.0.10.55, если это адрес файлового NIC или клиента, сверьте Get-SmbSession и DHCP lease: иногда «массовый rename» рисуют два хоста, а в тикете фигурирует только WS-042. Зафиксируйте оба.

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

  • Счётчик новых расширений на шаре перестал расти (выборочный Get-ChildItem с чистого jump, не полный crawl 10 ТБ в пике).
  • Сессия WS-042/ivan.petrov на SMB закрыта.
  • Исходный хост без сети.
  • IOC (hash, имя, расширение, PID, время) в заявке.
  • Backup не снимает грязное дерево поверх последней good-точки без решения.

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

  • Rename идёт с другого ClientComputerName — второй хост, ищите по Get-SmbSession снова.
  • Учётка сервисная, сессий много — стоп службы на сервере приложений, не только ПК.
  • Расширения разные — несколько волн или архиватор + malware; не склеивайте в один hash.
  • После стопа файлы «вернулись» сами — это не победа, это синхронизатор (OneDrive/DFS) размазал порчу; остановите sync.

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

  • Ограничить who has write на широкие шары.
  • Алерт по всплеску SMB create/rename (если есть аудит/мониторинг).
  • FSRM file screens как сигнал, не как серебряная пуля.
  • Запрет макросов из интернета, ASR где это уже принято организацией.
  • Отдельные учётки для массовых файловых job.

FAQ

Можно ли вернуть имена через Previous Versions сразу?

Только выборочно, с чистого ПК, после стопа источника. Массовый restore на живую шару, куда ещё пишет malware, бесполезен.

Нужно ли сразу объявлять ransomware?

Если есть массовый rename бизнес-файлов неизвестным процессом — действуйте как при шифровальщике. Классификацию допишите, когда будет записка или 1116.

Антивирус хочет удалить файл, который мы хешируем

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

Linux: остановить NFS всем клиентам?

Если rename идёт по NFS и источник неясен — да, это стоп вреда. Держать NFS «чтобы бухгалтерия дописала» во время wiper — потерять том целиком.

Хеш не находится в VirusTotal

Это ничего не доказывает. Не загружайте туда внутренние документы. Для IR достаточно своего SHA-256 и стопа.