Это сообщение в блоге является первым из многих статей, посвященных WMI, и предназначено для довольно новой аудитории. Базовое понимание Powershell определенно поможет читателю при просмотре статей, однако это не является обязательным требованием. Вот и все, давайте перейдем к делу.
Введение
Почему именно WMI?
WMI - это набор спецификаций от Microsoft, разработанный для быстрого и эффективного администрирования систем Windows. И, как вы, возможно, знаете, правило безопасности гласит, что "все, что полезно для администрации, отлично подходит для злоупотреблений со стороны злоумышленников". WMI действительно может многое - от сбора статусов компьютеров и настройки параметров до запуска приложений и выполнения кода. Более того, WMI присутствует во всех доступных версиях ОС Windows, поэтому целевая область здесь довольно широка.
Что такое WMI?
Давайте быстро рассмотрим несколько важных терминов. WMI расшифровывается как Windows Management Instrumentation, которая представляет собой реализацию Microsoft CIM (Common Information Model) и WBEM (Web-Based Enterprise Management ), которые в целом являются стандартами DMTF (Distributed Management Task Force). WMI дает нам аккуратный и единообразный интерфейс для приложений/скриптов для управления компьютером (возможно, удаленным и локальным), в т.ч. процессы, услуги и т. д.
Архитектура WMI
Понимание архитектуры очень важно для понимания того, как работает вся экосистема WMI. Ниже представлен общий обзор архитектуры WMI (взят из выступления Грэбера из BHUSA 15 https://www.blackhat.com/docs/us-15...ent Asynchronous-And-Fileless-Backdoor-wp.pdf):
Давайте разберем основные компоненты один за другим:
- Клиенты/Потребители: По сути, это конечные потребители, которые взаимодействуют с классами WMI для запроса данных, выполнения методов и т. д. Немногие известные клиенты включают wmic.exe, wbemtest.exe, winrm.exe, VBScript/JScript и ofc командлеты Powershell.
- Языки запросов: Подобно тому, как SQL предоставляет вам способ запроса к базе данных, WMI также имеет WQL (язык запросов WMI)/CQL для запросов к службе WMI. Когда дело доходит до управления удаленными ящиками, вступает в действие стандарт WBEM, который включает DCOM и WS-Man (не волнуйтесь, если вы не понимаете эти термины, читайте дальше). WQL - это в основном синтаксис SQL для WMI, поэтому регистр не учитывается.
Простой запрос может выглядеть так:
select * from win32_bios
который дает нам информацию о нашем BIOS.
- Хранилища:Это базы данных, о которых мы говорили ранее, в которых хранятся все статические данные (определения) классов. Репозитории определяются файлами MOF (формат управляемого объекта), которые определяют структуру, классы, пространства имен и т. д. Файлы базы данных можно найти в каталоге% WINDIR% \ System32 \ Wbem \ Repository.
- MOF файлы: Файлы MOF в основном используются для определения пространств имен WMI, классов, поставщиков и т. д. Обычно вы найдете их в каталоге %WINDIR%\System32\Wbem с расширением .mof. В более поздней части этой серии мы рассмотрим, как мы можем писать наши собственные файлы MOF для расширения набора функций WMI.
-Провайдеры: Все, что определено в репозиториях, можно получить с помощью поставщиков WMI. Обычно они представляют собой файлы DLL и связаны с файлом MOF - cimwin32.dll, stdprov.dll и т. д., чтобы назвать несколько, однако они также могут принимать форму других типов (класс, событие, потребитель события, метод и т. д.) . Провайдеры важны для экосистемы, потому что они отслеживают события и данные от определенных объектов. Подумайте о поставщиках как о драйверах, которые обеспечивают мост между управляемыми объектами и WMI.
На снимке экрана ниже файлы DLL являются поставщиками связанных файлов MOF:
- Управление объектами: Это псевдонимы ресурсов в контексте, то есть управляемый объект может быть службой, процессом или ОС, управляемыми WMI.
- Пространства имен: Проще говоря, пространства имен - это логические подразделения классов, предназначенные для легкого обнаружения и использования. Они делятся на 3 группы:
- система
- ядро
- расширение
и 3 вида:
- абстрактный
- статический
- динамичный
По умолчанию используются следующие известные пространства имен: root\cimv2, root\default, root\security, root\subscription и т. д.
Вот и все с архитектурой.
Теперь давайте узнаем немного об использовании WMI с Powershell.
Использование WMI с Powershell
Теперь, когда мы закончили с теоретической частью, давайте быстро создадим терминал PS. Важно помнить, что до версии Powershell версии 2 было всего несколько командлетов для взаимодействия с WMI. Мы быстро проверим нашу версию Powershell и изменим версию на 2:
Теперь давайте запустим командлет Get-Command -CommandType * wmi * в командной строке Powershell. Это приводит нас к следующему:
СОВЕТ: Имена команд говорят сами за себя (и мы еще поговорим об этом позже). В любой момент вы можете использовать стандартный синтаксис Powershell: help <command>, чтобы получить дополнительную информацию о том, что делает конкретная команда. Например вы можете попробовать help Invoke-WmiMethod для просмотра того, что делает команда - очень похоже на справочные страницы Linux.
Начиная с Powershell v3, MS представила командлеты CIM, которые используют стандарты WS-MAN и CIM для управления объектами. Доступ к командлетам CIM имеет преимущества в двух контекстах:
- На машинах, где сам WMI/DCOM заблокирован для работы (возможно, из-за правила брандмауэра на основе хоста), но включен WinRM/WS-MAN (удаленное управление Windows), мы все равно можем использовать CIM, чтобы делать именно то, что мы можем сделать с WMI.
- CIM сам по себе является отраслевым стандартом и реализован кроссплатформенным, что означает, что его можно использовать также для работы с устройствами, отличными от Windows.
Уф! Давайте разберемся, что означают здесь новые термины:
DCOM: Псевдоним для объектной модели распределенных компонентов, DCOM - это проприетарный протокол Microsoft для связи между программными компонентами на сетевых компьютерах. WMI использует распределенный COM (DCOM) для подключения к удаленному компьютеру. Однако DCOM не поддерживает брандмауэр.
WS-MAN: WS-MAN или WS-Management - это стандарт DMTF, который предоставляет системам общий способ доступа к управляющей информации через ИТ-инфраструктуру. WS-MAN, с другой стороны, использует HTTP, поэтому он определенно дружественен к брандмауэрам.
Мы повторим то, что делали выше, но после изменения версии Powershell на значение по умолчанию (в моем случае это Powershell v5):
Повторяя сказанное выше, командлеты CIM могут делать все, что могут командлеты WMI. Если мы хотим сопоставить функциональные возможности командлетов WMI и CIM, вот табличное представление сравнения функциональных возможностей обоих типов:
Выполнение запросов WMI с помощью Powershell
Теперь, когда мы знаем о различных доступных для использования командлетах, мы можем попробовать выполнить приведенный выше образец WQL-запроса. Мы уже знаем, что Get-WmiObject можно использовать для получения информации о классах. Итак, давайте запустим командлет с параметром -Query:
Get-WmiObject -Query 'select * from win32_bios'
Заключение
Это сообщение в блоге было предназначено для обзора того, чем мы будем заниматься в следующих частях этой серии. Здесь много технических модных словечек, но понимать их необходимо. Надеюсь, вам понравилось читать, и я с нетерпением жду нашего совместного путешествия по изучению WMI.
Введение
Почему именно WMI?
WMI - это набор спецификаций от Microsoft, разработанный для быстрого и эффективного администрирования систем Windows. И, как вы, возможно, знаете, правило безопасности гласит, что "все, что полезно для администрации, отлично подходит для злоупотреблений со стороны злоумышленников". WMI действительно может многое - от сбора статусов компьютеров и настройки параметров до запуска приложений и выполнения кода. Более того, WMI присутствует во всех доступных версиях ОС Windows, поэтому целевая область здесь довольно широка.
Что такое WMI?
Давайте быстро рассмотрим несколько важных терминов. WMI расшифровывается как Windows Management Instrumentation, которая представляет собой реализацию Microsoft CIM (Common Information Model) и WBEM (Web-Based Enterprise Management ), которые в целом являются стандартами DMTF (Distributed Management Task Force). WMI дает нам аккуратный и единообразный интерфейс для приложений/скриптов для управления компьютером (возможно, удаленным и локальным), в т.ч. процессы, услуги и т. д.
Архитектура WMI
Понимание архитектуры очень важно для понимания того, как работает вся экосистема WMI. Ниже представлен общий обзор архитектуры WMI (взят из выступления Грэбера из BHUSA 15 https://www.blackhat.com/docs/us-15...ent Asynchronous-And-Fileless-Backdoor-wp.pdf):
Давайте разберем основные компоненты один за другим:
- Клиенты/Потребители: По сути, это конечные потребители, которые взаимодействуют с классами WMI для запроса данных, выполнения методов и т. д. Немногие известные клиенты включают wmic.exe, wbemtest.exe, winrm.exe, VBScript/JScript и ofc командлеты Powershell.
- Языки запросов: Подобно тому, как SQL предоставляет вам способ запроса к базе данных, WMI также имеет WQL (язык запросов WMI)/CQL для запросов к службе WMI. Когда дело доходит до управления удаленными ящиками, вступает в действие стандарт WBEM, который включает DCOM и WS-Man (не волнуйтесь, если вы не понимаете эти термины, читайте дальше). WQL - это в основном синтаксис SQL для WMI, поэтому регистр не учитывается.
Простой запрос может выглядеть так:
select * from win32_bios
который дает нам информацию о нашем BIOS.
- Хранилища:Это базы данных, о которых мы говорили ранее, в которых хранятся все статические данные (определения) классов. Репозитории определяются файлами MOF (формат управляемого объекта), которые определяют структуру, классы, пространства имен и т. д. Файлы базы данных можно найти в каталоге% WINDIR% \ System32 \ Wbem \ Repository.
- MOF файлы: Файлы MOF в основном используются для определения пространств имен WMI, классов, поставщиков и т. д. Обычно вы найдете их в каталоге %WINDIR%\System32\Wbem с расширением .mof. В более поздней части этой серии мы рассмотрим, как мы можем писать наши собственные файлы MOF для расширения набора функций WMI.
-Провайдеры: Все, что определено в репозиториях, можно получить с помощью поставщиков WMI. Обычно они представляют собой файлы DLL и связаны с файлом MOF - cimwin32.dll, stdprov.dll и т. д., чтобы назвать несколько, однако они также могут принимать форму других типов (класс, событие, потребитель события, метод и т. д.) . Провайдеры важны для экосистемы, потому что они отслеживают события и данные от определенных объектов. Подумайте о поставщиках как о драйверах, которые обеспечивают мост между управляемыми объектами и WMI.
На снимке экрана ниже файлы DLL являются поставщиками связанных файлов MOF:
- Управление объектами: Это псевдонимы ресурсов в контексте, то есть управляемый объект может быть службой, процессом или ОС, управляемыми WMI.
- Пространства имен: Проще говоря, пространства имен - это логические подразделения классов, предназначенные для легкого обнаружения и использования. Они делятся на 3 группы:
- система
- ядро
- расширение
и 3 вида:
- абстрактный
- статический
- динамичный
По умолчанию используются следующие известные пространства имен: root\cimv2, root\default, root\security, root\subscription и т. д.
Вот и все с архитектурой.
Теперь давайте узнаем немного об использовании WMI с Powershell.
Использование WMI с Powershell
Теперь, когда мы закончили с теоретической частью, давайте быстро создадим терминал PS. Важно помнить, что до версии Powershell версии 2 было всего несколько командлетов для взаимодействия с WMI. Мы быстро проверим нашу версию Powershell и изменим версию на 2:
Теперь давайте запустим командлет Get-Command -CommandType * wmi * в командной строке Powershell. Это приводит нас к следующему:
СОВЕТ: Имена команд говорят сами за себя (и мы еще поговорим об этом позже). В любой момент вы можете использовать стандартный синтаксис Powershell: help <command>, чтобы получить дополнительную информацию о том, что делает конкретная команда. Например вы можете попробовать help Invoke-WmiMethod для просмотра того, что делает команда - очень похоже на справочные страницы Linux.
Начиная с Powershell v3, MS представила командлеты CIM, которые используют стандарты WS-MAN и CIM для управления объектами. Доступ к командлетам CIM имеет преимущества в двух контекстах:
- На машинах, где сам WMI/DCOM заблокирован для работы (возможно, из-за правила брандмауэра на основе хоста), но включен WinRM/WS-MAN (удаленное управление Windows), мы все равно можем использовать CIM, чтобы делать именно то, что мы можем сделать с WMI.
- CIM сам по себе является отраслевым стандартом и реализован кроссплатформенным, что означает, что его можно использовать также для работы с устройствами, отличными от Windows.
Уф! Давайте разберемся, что означают здесь новые термины:
DCOM: Псевдоним для объектной модели распределенных компонентов, DCOM - это проприетарный протокол Microsoft для связи между программными компонентами на сетевых компьютерах. WMI использует распределенный COM (DCOM) для подключения к удаленному компьютеру. Однако DCOM не поддерживает брандмауэр.
WS-MAN: WS-MAN или WS-Management - это стандарт DMTF, который предоставляет системам общий способ доступа к управляющей информации через ИТ-инфраструктуру. WS-MAN, с другой стороны, использует HTTP, поэтому он определенно дружественен к брандмауэрам.
Мы повторим то, что делали выше, но после изменения версии Powershell на значение по умолчанию (в моем случае это Powershell v5):
Повторяя сказанное выше, командлеты CIM могут делать все, что могут командлеты WMI. Если мы хотим сопоставить функциональные возможности командлетов WMI и CIM, вот табличное представление сравнения функциональных возможностей обоих типов:
| Use \ Types | WMI Cmdlets | CIM Cmdlets |
|---|---|---|
| Get information about classes | Get-WmiObject | Get-CimInstance |
| Invoking a method | Invoke-WmiMethod | Invoke-CimMethod |
| Subscribing to an event | Register-WmiEvent | Register-CimIndicationEvent |
| Creating/updating instances of a class | Set-WmiInstance | Set-CimInstance |
| Deleting instances of a class | Remove-WmiObject | Remove-CimInstance |
Выполнение запросов WMI с помощью Powershell
Теперь, когда мы знаем о различных доступных для использования командлетах, мы можем попробовать выполнить приведенный выше образец WQL-запроса. Мы уже знаем, что Get-WmiObject можно использовать для получения информации о классах. Итак, давайте запустим командлет с параметром -Query:
Get-WmiObject -Query 'select * from win32_bios'
Заключение
Это сообщение в блоге было предназначено для обзора того, чем мы будем заниматься в следующих частях этой серии. Здесь много технических модных словечек, но понимать их необходимо. Надеюсь, вам понравилось читать, и я с нетерпением жду нашего совместного путешествия по изучению WMI.
