Руководство по инструментарию управления Windows (WMI): основные сведения о WMI-атаках

[maledog]

То что wmi можно вызвать из PowerShell не делает его подсистемой последнего. Это надстройка над winapi. Его можно вызвать почти из любого современного языка программирования, но проще уже winapi дернуть, чем разбираться почему не сработал WMI.
Не знаю как сейчас, а раньше его можно было выключить без последствий. Все равно и вирусы и инструменты администрирования использовали RPC. Отвалиться могли максимум такие вот самописные скрипты завязанные на WMI. И что это за «злостный хакир» который протащил и смог запустить целый netcat(учитывая что половина антивирусов его блокируют как hack tool), но не смог написать себе нормальный «все в одном» вирус. Или хотя бы не установил соединение при помощи того же powershell. Например:

$routerAddress = "192.168.10.126"
$port = "23"
$tcp = New-Object System.Net.Sockets.TcpClient($routerAddress,$Port)
$tcpstream = $tcp.GetStream()
$reader = New-Object System.IO.StreamReader($tcpStream)
$writer = New-Object System.IO.StreamWriter($tcpStream)
$writer.AutoFlush = $true

[drdead]

WMI сейчас не отключить без последствий, ибо, как вы сами заметили, WMI хоть и не является подсистемой PS, но приличное кол-во командлетов и функций дёргают под капотом WMI и старый добрый COM. Что не удивительно, учитывая что команда, разрабатывающая PS является же И product owner'ом WMI.

Учитывая количество софта, который используется в энтерпрайзе — множество вещей просто отвалится и не будет нормально работать. Взять те же Dell сервера — без рабочего WMI нэймспэйса для железа работать не будет практически ничего для мониторинга и менеджмента со стороны OS.

[ol_x]

wmi зло… ему место на помойке