Удаление WMI persistence в Windows

Что такое WMI persistence и почему это опасно

WMI (Windows Management Instrumentation) — встроенный механизм Windows для управления и мониторинга ОС. Под «WMI persistence» понимают ситуацию, когда злоумышленник создаёт постоянную подписку на события WMI (event subscription), которая при наступлении условия автоматически запускает полезную нагрузку.

Ключевые понятия в одной строке:

• __EventFilter — условие/триггер события;
• __EventConsumer — выполняемая «потребляющая» часть (скрипт, команда, скриптовый процесс);
• __FilterToConsumerBinding — привязка фильтра к потребителю.

Опасность в том, что подписки работают «тихо», могут запускаться при загрузке системы или при действии пользователя и оставляют мало следов в привычных журналах аудита. Это делает их привлекательным инструментом для доступа с сохранением присутствия (persistence).

Факт-блок: что обычно используется при WMI persistence

• Пространство имён: root/subscription и иногда root\cimv2.
• Классы: EventFilter, EventConsumer, __FilterToConsumerBinding.
• Частые триггеры: запуск системы, создание процесса, изменение файлов, таймеры.

Как обнаружить WMI подписки (обзор шагов)

1. Просмотрите подписки через PowerShell.
2. Сравните найденное со штатными поставщиками и политиками компании.
3. Отключите сетевой доступ к WMI (DCOM) или ограничьте его
4. Удалите подозрительные объекты и проверьте журналы.

Команды для обнаружения (PowerShell)

Используйте современные команды CME/ CIM, они более надёжны и работают с WinRM:

# Просмотр фильтров, потребителей и привязок
Get-CimInstance -Namespace root/subscription -ClassName __EventFilter
Get-CimInstance -Namespace root/subscription -ClassName __EventConsumer
Get-CimInstance -Namespace root/subscription -ClassName __FilterToConsumerBinding

Если у вас старые системы с WMI-only инструментами, замените Get-CimInstance на Get-WmiObject с тем же Namespace.

На что обращать внимание

• Имя (Name) и текстовые поля (Query) в __EventFilter — неожиданные WQL-запросы;
• Команды или скрипты в потребителях — unusual paths (временные папки, пользовательские каталоги);
• Пользовательские GUID или имена подписок, которых нет в документации или в стандартных поставщиках.

Как безопасно удалить WMI persistence (пошагово)

Внимание: выполните эти действия с правами администратора и только после резервной копии/проверки, особенно в продакшне.

1. Сначала задокументируйте подозрительные объекты: экспорт их свойств в файл.

# Экспорт свойств подозрительной подписки
Get-CimInstance -Namespace root/subscription -ClassName __EventFilter | Select-Object * | Out-File C:\temp\wmi_eventfilters.txt

2. Остановите связанные процессы, если они активны, и поставьте систему в режим мониторинга.

3. Удалите привязку, затем consumer и filter. Пример удаления:

# Пример: удалить конкретный объект
$binding = Get-CimInstance -Namespace root/subscription -ClassName __FilterToConsumerBinding | Where-Object { $_.Filter -match 'подозрительное_имя' }
if ($binding) { Remove-CimInstance -InputObject $binding }

$consumer = Get-CimInstance -Namespace root/subscription -ClassName __EventConsumer | Where-Object { $_.Name -match 'подозрительное_имя' }
if ($consumer) { Remove-CimInstance -InputObject $consumer }

$filter = Get-CimInstance -Namespace root/subscription -ClassName __EventFilter | Where-Object { $_.Name -match 'подозрительное_имя' }
if ($filter) { Remove-CimInstance -InputObject $filter }

4. Проверьте, что объекты удалены, и перезапустите соответствующие службы для проверки устойчивости среды.

5. Соберите артефакты и логи для криминалистики и SOC.

Альтернативные и дополняющие подходы

• Отключение службы WMI (Winmgmt) — самый радикальный способ: снижает функциональность мониторинга и управления, но исключает WMI persistence.
• Блокировка DCOM/Remote WMI: назначьте статический порт для DCOM и закройте его в межсетевом экране, чтобы запретить удалённый доступ.
• Мониторинг подписок: настроить сбор метрик и оповещений по изменению классов в root/subscription.

Ментальная модель: зачем злоумышленнику WMI

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

Когда отключение WMI не подходит (контрпример)

• У вас централизованная система мониторинга и деплоймента, которая использует WMI для инвентаризации и управления. Отключение приведёт к потере функциональности. В таких случаях разумнее ограничить удалённый доступ и усиливать мониторинг.

Чек‑лист по ролям

Администратор:

• Просмотреть подписки в root/subscription;
• Зарезервировать вывод и логи;
• Удалить подтверждённые злонамеренные объекты;
• Применить firewall‑правила для DCOM.

SOC/инцидент‑команда:

• Собрать артефакты (экспорт WMI объектов и журналов);
• Проверить наличие схожих индикаторов в других хостах;
• Инициировать карантин машины при необходимости.

Обычный пользователь:

• Сообщать о необычном поведении ПК (самопроизвольные запуски, повышенная активность диска);
• Не запускать неизвестные скрипты и вложения.

Инцидентный план (runbook) — кратко

1. Изолировать хост от сети.
2. Сделать полную копию памяти/диска для расследования.
3. Описанные выше шаги обнаружения и удаления WMI подписок.
4. Проверить сопутствующие артефакты: планировщик задач, автозагрузки, службы, реестр.
5. Восстановить хост из известной чистой резервной копии при сомнениях.

Жёсткая защита и конфигурация

• Минимизируйте права у учётных записей; используйте принцип наименьших привилегий.
• Разрешайте доступ к WMI только через защищённый WinRM и целевые политики.
• Логируйте изменения в пространствах имён WMI и создавайте оповещения.

Приватность и соответствие требованиям

WMI persistence может привести к незаметному сбору и утечке данных. При расследовании инцидентов сохраняйте цепочку ответственности и учитывайте требования о защите персональных данных (например, регламенты организации и GDPR), минимизируя правовой и репутационный риск.

Краткое резюме

WMI — мощный инструмент администрирования, но в руках злоумышленника он превращается в надёжный механизм сохранения присутствия. Регулярно проверяйте root/subscription, задокументируйте и удаляйте подозрительные EventFilter, EventConsumer и __FilterToConsumerBinding, ограничьте удалённый доступ к WMI и применяйте мониторинг. Это даёт высокий уровень защиты при умеренных издержках.

Важно: работайте аккуратно и всегда сохраняйте доказательства для последующего расследования.

flowchart TD
  A{Нужен WMI для управления?} -->|Да| B[Ограничить удалённый доступ и мониторить]
  A -->|Нет| C[Отключить службу WMI]
  B --> D{Найдены подозрительные подписки?}
  C --> E[Проверить работоспособность систем]
  D -->|Да| F[Изолировать хост и удалить подписки]
  D -->|Нет| G[Поддерживать мониторинг]
  F --> H[Собрать артефакты для SOC]