Антивирус ничего не находит, но система ведёт себя подозрительно: ищем угрозу через WMI

Вам звонит пользователь: «Компьютер что-то делает сам по себе. Сетевая активность странная. Но Kaspersky / ESET / Defender — всё чисто». Знакомая ситуация? Именно в такие моменты важно не ограничиваться стандартным сканированием, а копнуть туда, куда большинство антивирусов просто не смотрит: в WMI-подписки (Windows Management Instrumentation).

Почему антивирус этого не видит

Большинство антивирусных движков ориентированы на сигнатурный анализ файлов и поведенческий мониторинг запущенных процессов. WMI-подписки хранятся в собственной базе данных WMI — в файле %WINDIR%\System32\wbem\Repository. Там нет исполняемого файла, который можно просканировать. Тело вредоносного скрипта может быть зашито прямо в объект CommandLineEventConsumer, и антивирус просто не имеет повода на него смотреть.

Кроме этого, атакующие нередко используют обфускацию PowerShell или fileless-технику — вредоносный код живёт только в памяти и в WMI-репозитории, не касаясь диска. Именно поэтому классические сканеры молчат, а система продолжает вести себя подозрительно.

Шаг 1. Проверяем WMI-подписки через PowerShell

Откройте PowerShell от имени администратора. WMI-подписки состоят из трёх объектов: EventFilter (что отслеживать), EventConsumer (что делать) и FilterToConsumerBinding (связь между ними). Проверяем каждый.

Get-WmiObject -Namespace "root\subscription" -Class __FilterToConsumerBinding | Select-Object -Property Filter, Consumer

Get-WmiObject -Namespace "root\subscription" -Class __EventFilter | Select-Object Name, Query, QueryLanguage

Get-WmiObject -Namespace "root\subscription" -Class CommandLineEventConsumer | Select-Object Name, CommandLineTemplate

Шаг 2. Полный вывод — ничего не скрывать

Команды выше могут обрезать длинные значения. Чтобы увидеть полный текст команды, которую запускает потребитель:

Get-WmiObject -Namespace "root\subscription" -Class CommandLineEventConsumer | Format-List *

А вот удобный способ сразу вывести всё в один читаемый отчёт — фильтры, потребители и связки — в один проход:

# Полный аудит WMI-подписок
Write-Host "`n=== EventFilters ===" -ForegroundColor Cyan
Get-WmiObject -Namespace "root\subscription" -Class __EventFilter | Format-List Name, Query

Write-Host "`n=== CommandLineEventConsumers ===" -ForegroundColor Cyan
Get-WmiObject -Namespace "root\subscription" -Class CommandLineEventConsumer | Format-List Name, CommandLineTemplate

Write-Host "`n=== ActiveScriptEventConsumers ===" -ForegroundColor Cyan
Get-WmiObject -Namespace "root\subscription" -Class ActiveScriptEventConsumer | Format-List Name, ScriptText

Write-Host "`n=== FilterToConsumerBindings ===" -ForegroundColor Cyan
Get-WmiObject -Namespace "root\subscription" -Class __FilterToConsumerBinding | Format-List Filter, Consumer

Шаг 3. Удаляем вредоносную подписку

Нашли подозрительный объект? Удаляем его. Допустим, вредоносный фильтр называется MaliciousFilter, а потребитель — MaliciousConsumer. Последовательность важна: сначала связка, потом фильтр и потребитель.

# 1. Удаляем связку
$binding = Get-WmiObject -Namespace "root\subscription" -Class __FilterToConsumerBinding | Where-Object { $_.Filter -like "*MaliciousFilter*" }
$binding | Remove-WmiObject

# 2. Удаляем фильтр
$filter = Get-WmiObject -Namespace "root\subscription" -Class __EventFilter -Filter "Name='MaliciousFilter'"
$filter | Remove-WmiObject

# 3. Удаляем потребителя
$consumer = Get-WmiObject -Namespace "root\subscription" -Class CommandLineEventConsumer -Filter "Name='MaliciousConsumer'"
$consumer | Remove-WmiObject

После удаления — перезагрузите машину и повторите аудит, чтобы убедиться, что объекты не восстановились (некоторые дропперы могут пересоздавать их из другого механизма закрепления).

Шаг 4. Включаем логирование WMI-событий

По умолчанию Windows не пишет в журнал создание WMI-подписок. Включите это немедленно — особенно на рабочих станциях с доступом к чувствительным данным.

# Включить расширенный аудит WMI-операций (требует Windows 10 / Server 2016+)
wevtutil sl Microsoft-Windows-WMI-Activity/Operational /e:true

После включения в журнале Microsoft-Windows-WMI-Activity/Operational появятся события:

• Event ID 5861 — регистрация нового постоянного потребителя (крайне важное событие)
• Event ID 5860 — регистрация нового временного потребителя
• Event ID 5858 — ошибки в WMI-запросах (может указывать на перебор)

Шаг 5. Подключаем Sysmon для глубокого мониторинга

Если у вас ещё не установлен Sysmon от Sysinternals — самое время. Он отслеживает WMI-активность значительно детальнее штатных средств.

# Установка Sysmon (предварительно скачайте с sysinternals.com)
sysmon64.exe -accepteula -i sysmonconfig.xml

Ключевые Event ID Sysmon для WMI-угроз:

• Event ID 19 — создание WMI EventFilter
• Event ID 20 — создание WMI EventConsumer
• Event ID 21 — создание FilterToConsumerBinding
• Event ID 1 — создание процесса (с полем ParentCommandLine — увидите, что родителем является WMI)

Дополнительные места для проверки

WMI — не единственное место, где могут прятаться угрозы, невидимые антивирусу. Проверьте параллельно:

• Задания планировщика в нестандартных папках: Get-ScheduledTask | Where-Object {$_.TaskPath -notlike "\Microsoft\*"} | Select-Object TaskName, TaskPath
• Автозагрузка через реестр вне стандартных ключей: проверьте HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon — ключи Userinit и Shell
• Сервисы с подозрительными бинарями: Get-WmiObject Win32_Service | Where-Object {$_.PathName -like "*Temp*" -or $_.PathName -like "*AppData*"}
• DLL Hijacking: проверьте известные уязвимые пути через Process Monitor при запуске подозрительного ПО

Что делать, если угроза подтверждена

Если вы обнаружили активную вредоносную WMI-подписку, действуйте по следующему плану:

1. Изолируйте машину от сети — отключите сетевой кабель или Wi-Fi до завершения расследования.
2. Сделайте снимок WMI-репозитория и экспортируйте всё через Format-List * для последующего анализа.
3. Проверьте другие машины в сети — если атакующий закрепился через WMI на одной машине, вероятно, он уже действовал горизонтально.
4. Удалите подписки командами из Шага 3, перезагрузите, повторите аудит.
5. Проведите полный анализ Event Log за период до обнаружения — найдите точку входа.
6. Смените пароли всех учётных записей, к которым имела доступ скомпрометированная машина.