WMI Persist, который Sysmon не видит

В Windows есть довольно старая техника закрепления через подписчики WMI. Суть в том, что злоумышленник обращается к классам пространства имен ROOT\Subscription (Скриншот 1) и создает три сущности:

1️⃣ EventFilter — фильтр, который по указанной логике отрабатывает на события, например запуск процесса с характерными параметрами.

2️⃣ EventConsumer — сущность, которая описывает, что произойдет, когда срабатывает фильтр.

3️⃣ FilterConsumerBinding — отвечает за создание связи между определенными EventFilter и EventConsumer.

Таким образом, злоумышленник в ответ на определенные события в системе (например, SystemStartup) может прописать запуск своего пэйлоада и закрепиться. У Sysmon есть отдельные события на эту активность:

🫡 EventId 19 — WmiEventFilter activity detected, срабатывает на регистрацию WMI-фильтра.

🫡 EventId 20 — WmiEventConsumer activity detected, срабатывает на регистрацию WMI Consumer.

🫡 EventId 21 — WmiEventConsumerToFilter activity detected срабатывает на регистрацию связи между WMI Consumer и WMI Filter.

Этот тип закрепления видно, к примеру, в утилите Autoruns (скриншот 2).

Но у принципа сбора WMI-событий в Sysmon существует недостаток, который заключается в том, что события собираются только из пространства имен ROOT\Subscription.

Дело в том, что в пространстве имен ROOT\Default есть аналогичные классы (скриншот 3), которые можно использовать для этого типа закрепления.

📍 Если Filter, Consumer и Binding будут созданы через это пространство имен, то Sysmon не сгенерирует никаких событий, а закрепление пройдет успешно.

Если хотите более подробно ознакомиться с тем как Sysmon собирает WMI-события, читайте в нашей статье.