Охота на призраков. Как работает закрепление в Windows через WMI-подписки

Тех­ника MITRE ATT&CK T1546.003 поз­воля­ет зло­умыш­ленни­ку соз­дать скры­тую «зак­ладку» в сис­теме. Такая под­писка может не тре­бовать отдель­ного исполня­емо­го или сце­нар­ного фай­ла, одна­ко ее объ­екты сох­раня­ются в репози­тории WMI. Пос­тоян­ная WMI-под­писка может пережи­вать завер­шение поль­зователь­ской сес­сии и перезаг­рузку сис­темы, а в зависи­мос­ти от пот­ребите­ля и кон­тек­ста выпол­нения — запус­кать дей­ствия с повышен­ными при­виле­гиями. Соз­дание пос­тоян­ных объ­ектов в root\subscription обыч­но тре­бует адми­нис­тра­тив­ных прав.

В этой статье мы:

1. Соз­дадим WMI-под­писку сво­ими руками.
2. Про­ана­лизи­руем ее на трех уров­нях: логи, арте­фак­ты на дис­ке и память.
3. Раз­берем, как детек­тировать такие ата­ки в SOC.
4. Нас­тро­им защиту от WMI-пер­сист.

Временные и постоянные WMI-подписки

В Windows сущес­тву­ют два похожих, но прин­ципи­аль­но раз­ных механиз­ма под­писки на события WMI.

Вре­мен­ная под­писка сущес­тву­ет толь­ко внут­ри про­цес­са, который ее соз­дал. Нап­ример, коман­да Register-WmiEvent регис­три­рует обра­бот­чик в текущем про­цес­се PowerShell. Такая под­писка перес­тает работать пос­ле завер­шения это­го про­цес­са или уда­ления под­писчи­ка коман­дой Unregister-Event. Она не соз­дает пос­тоян­ных объ­ектов в прос­транс­тве имен root\subscription, не пережи­вает переза­пуск PowerShell или перезаг­рузку сис­темы и не соз­дает события Sysmon 19, 20 и 21, отно­сящи­еся к регис­тра­ции пос­тоян­ной под­писки.

Пос­тоян­ная под­писка сос­тоит из трех объ­ектов WMI:

• __EventFilter — опи­сыва­ет событие‑триг­гер;
• CommandLineEventConsumer — опре­деля­ет выпол­няемое дей­ствие;
• __FilterToConsumerBinding — свя­зыва­ет филь­тр с пот­ребите­лем.

Эти объ­екты сох­раня­ются в WMI Repository, могут пережи­вать перезаг­рузку сис­темы, и имен­но они соот­ветс­тву­ют механиз­му зак­репле­ния MITRE ATT&CK T1546.003.

В пер­вой час­ти статьи мы исполь­зуем вре­мен­ную под­писку как прос­той спо­соб про­демонс­три­ровать сам прин­цип: событие WMI вызыва­ет задан­ное дей­ствие. Далее при раз­боре Sysmon и OBJECTS.DATA рас­смат­рива­ем уже арте­фак­ты пос­тоян­ной под­писки. Поэто­му наборы логов и сле­дов у этих двух вари­антов раз­лича­ются.

Механика срабатывания временной подписки

Сна­чала раз­берем упро­щен­ный вари­ант — вре­мен­ную под­писку через Register-WmiEvent. Она покажет, как событие WMI может запус­кать дей­ствие, но сама по себе не может быть пол­ноцен­ным механиз­мом пос­тоян­ного зак­репле­ния: под­писка сущес­тву­ет, толь­ко пока работа­ет соз­давший ее про­цесс PowerShell, и не пережи­вает перезаг­рузку.

Она будет сра­баты­вать при запус­ке «Блок­нота» (notepad.exe) и откры­вать кар­тинку с котом из интерне­та. Это безопас­ная демонс­тра­ция событий­ного выпол­нения: в реаль­ной ата­ке вмес­то откры­тия кар­тинки мог­ло бы выпол­нять­ся дру­гое дей­ствие. В нашем слу­чае обра­щение к уда­лен­ному URL ими­тиру­ет сетевое дей­ствие.

Для демонс­тра­ции исполь­зует­ся обыч­ная ссыл­ка на изоб­ражение. Обфуска­ция здесь не нуж­на, пос­коль­ку задача экспе­римен­та — показать механизм сра­баты­вания WMI-события.

На этом эта­пе мы соз­дали имен­но вре­мен­ную, при­вязан­ную к PowerShell-сес­сии под­писку. Ее сле­ды сле­дует искать преж­де все­го в PowerShell-телемет­рии и памяти про­цес­са, а не сре­ди пос­тоян­ных объ­ектов репози­тория WMI.

Код для создания подписки

Соз­даем вре­мен­ную под­писку через PowerShell:

За­пус­каем «Блок­нот»:

В течение пяти секунд пос­ле запус­ка «Блок­нота» откры­вает­ся кар­тинка. Это доказы­вает, что под­писка сра­бота­ла.

Постоянная подписка

В рам­ках вто­рого экспе­римен­та я соз­дал пос­тоян­ную под­писку в прос­транс­тве имен root\subscription. Пос­ле регис­тра­ции я про­верил наличие филь­тра MaliciousFilter, пот­ребите­ля MaliciousConsumer и свя­зыва­юще­го объ­екта __FilterToConsumerBinding. Далее мы пос­мотрим телемет­рию и арте­фак­ты этих пос­тоян­ных объ­ектов. PowerShell Event ID 4104 отно­сит­ся к вре­мен­ному экспе­римен­ту, а Sysmon 19–21 и ана­лиз OBJECTS.DATA — к пос­тоян­ному.

Детект по логам Sysmon и PowerShell

Что мы ищем в Sysmon

Sysmon — это клю­чевой инс­тру­мент для монито­рин­га WMI-активнос­ти. Он логиру­ет три важ­ных события:

• Event ID 19 — WmiEventFilter: соз­дание WMI-филь­тра, то есть триг­гера;
• Event ID 20 — WmiEventConsumer: соз­дание WMI-пот­ребите­ля, то есть выпол­няемо­го дей­ствия;
• Event ID 21 — WmiEventConsumerToFilter: свя­зыва­ние филь­тра с пот­ребите­лем.

При регис­тра­ции пос­тоян­ной под­писки Sysmon может сфор­мировать сле­дующую телемет­рию.

В моем экспе­римен­те событие Event ID 21 не зафик­сирова­лось. Воз­можно, это свя­зано с кон­фигура­цией Sysmon или непол­ным сбо­ром событий. Событие 21 пред­назна­чено для отра­жения регис­тра­ции свя­зи меж­ду филь­тром и пот­ребите­лем. Вре­мен­ные под­писки Register-WmiEvent такие события не соз­дают.

PowerShell Script Block Logging (Event ID 4104)

Один из наибо­лее пря­мых спо­собов обна­ружить соз­дание вре­мен­ной под­писки через PowerShell — исполь­зовать Script Block Logging и ана­лизи­ровать событие 4104. Пока соз­давшая под­писку PowerShell-сес­сия про­дол­жает работать, под­писчи­ка так­же мож­но про­верить коман­дой Get-EventSubscriber.