Инвентаризация компьютеров по сети windows

First published on TechNet on Feb 04, 2010
Hi, Ned here again. Have you ever had to figure out what operating systems are running in your domain environment so that you can plan for upgrades, service pack updates, or support lifecycle transitions? Did you know that you don’t have to connect to any of the computers to find out? It’s easier than you might think, and all possible once you start using AD PowerShell in Windows Server 2008 R2 or Windows 7 with RSAT.

Get-ADComputer

Get-Help Get-ADComputer -Full 

Getting OS information

Get-ADComputer -Filter * -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion -Wrap –Auto

Another important note (thanks dloder): I am going for simplicity and introduction here, so the -Filter and -Property switches are not designed for perfect efficiency. As you get comfortable with AD PowerShell, I highly recommend that you start tuning for less data to be returned — the «filter left, format right» model described here by Don Jones.

Servers

Now I start breaking down the results with filters. I run:

Get-ADComputer -Filter {OperatingSystem -Like "Windows Server*"} -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack -Wrap -Auto 

Get-ADComputer -Filter {OperatingSystem -Like "Windows *Server*"} -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack -Wrap -Auto 

Get-ADComputer -Filter {OperatingSystem -Like "Windows Server*2008*"} -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack -Wrap -Auto 
Get-ADComputer -Filter {OperatingSystem -Like "Windows Server*r2*"} -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack -Wrap -Auto 



  


                       
  

Workstations

Okeydokey, I think I’ve got all I need to know about servers – now what about all those workstations? I will simply switch from — Like to -Notlike with my previous server query:

Get-ADComputer -Filter {OperatingSystem -NotLike "*server*"} -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack -Wrap -Auto 

OS Family

By now these filters should be making more sense and PowerShell is looking less scary. Let’s say I want to filter by the “family” of operating system. This can be useful when trying to identify computers that started having a special capability in one OS release and all subsequent releases, and where I don’t care about it being server or workstation. An example of that would be BitLocker – it only works on Windows Vista, Windows Server 2008, and later. I run:

Get-ADComputer -Filter {OperatingSystemVersion -ge "6"} -Property * | Format-Table Name,OperatingSystem,OperatingSystemVersion -Wrap -Auto 

Get-ADComputer -Filter {OperatingSystemVersion -ge "6.1"} -Property * | Format-Table Name,OperatingSystem,OperatingSystemVersion -Wrap -Auto 

Getting it all into a file

Get-ADComputer -Filter * -Property * | Select-Object Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion | Export-CSV AllWindows.csv -NoTypeInformation -Encoding UTF8 

What about the whole forest?

You may be tempted to take some of the commands above and tack on the necessary arguments to search the entire forest. This means adding:

-searchbase “” –server  <domain FQDN>  :3268

That way you wouldn’t have to connect to a DC in every domain for the info – instead you’d just ask a single GC. Unfortunately, this won’t work ; none of the operating system attributes are replicated by global catalog servers. Oh well, that’s not PowerShell’s fault. All the data must be pulled from domains individually, but that can be automated – I leave that to you as a learning exercise.

Conclusion

• Windows XP SP2 support ends July 13, 2010 (mainstream support for the whole OS ended in 2009 and you must be running SP3 after July 13)
• Windows 2000 Professional extended support ends July 13, 2010
• Windows 2000 Server extended support ends July 13, 2010
• Windows Server 2003 and Windows Server 2003 R2 mainstream support ends July 13, 2010 (SP1 support ended in 2009, you must be running SP2 now)
• Windows Vista RTM (no service pack) support ends April 13, 2010 (You are running Vista with no service pack? Really?)
• For more info on what “support” really means, head over to the Lifecycle page.

Коллеги, в предыдущей статье мы обсудили принципы эффективной работы с событиями аудита ОС Windows. Однако, для построения целостной системы управления ИБ важно не только своевременно реагировать на киберинциденты — необходимо прежде всего понимать, что именно мы защищаем. Для построения корректной модели угроз и нарушителя, выстраивания системы управления киберрисками, управления уязвимостями и для многих других процессов ИБ требуется фундаментальная основа — управление ИТ-активами. Четкое видение инфраструктуры, учет программного и аппаратного обеспечения, их взаимодействия и зависимостей будет ключом к построению грамотной системы киберзащиты. В настоящей технической статье мы расскажем, как провести инвентаризацию ИТ активов, при этом реализуя принцип наименьших привилегий, с использованием функционала удаленного реестра, WMI и WinRM.

Введение

Для начала определимся с терминами. Актив в контексте ИБ – это сущность, имеющая ценность для организации, использующаяся для достижения целей организации, являющаяся объектом защиты и атаки с целью нарушения свойств безопасности. Активы бывают материальные (например, программное и аппаратное обеспечение, платформа, устройство) и нематериальные (например, информация, данные, торговая марка, лицензия, патент, интеллектуальная собственность, репутация). Управление активами (англ. Asset Management) — это систематический процесс, включающий в себя экономически эффективное создание, использование, поддержку, обновление и вывод из эксплуатации активов (т.е. стадии жизненного цикла ИТ-актива). Важность управления активами подчеркивается в российских и зарубежных законах и стандартах. Так, в методическом документе ФСТЭК России «Методика оценки угроз безопасности информации» в п. 2.2 пп. «б)» указано, что одна из основных задач, решаемых в ходе оценки угроз безопасности информации — это инвентаризация систем и сетей и определение возможных объектов воздействия угроз безопасности информации. Методический документ ФСТЭК России «Меры защиты информации в государственных информационных системах» в качестве способа обеспечения информационной безопасности указывает контроль состава технических средств, программного обеспечения и средств защиты информации, применяемых в информационной системе (мера АНЗ.4). Приказ ФСТЭК России №239 «Об утверждении требований по обеспечению безопасности значимых объектов КИИ РФ» предписывает осуществлять инвентаризацию информационных ресурсов (мера АУД.1). В зарубежных стандартах и рекомендациях также подчеркивается важность проведения инвентаризации. Так, в стандарте ISO 27001:2013 присутствует контроль A.8.1.1 ”Inventory of assets”. Публикация NIST SP 800-53 включает нормы CM-8 ”System component inventory” и PM-5 ”System inventory”. Кроме того, NIST “Cybersecurity Framework” содержит контроли ID.AM-1 и ID.AM-2, посвященные инвентаризации соответственно физических устройств и систем, программных платформ и приложений, а в публикации NIST SP 1800-5 ”IT Asset Management” («Управление ИТ-активами») перечислены требования к эффективной системе управления ИТ-активами.

Среди специализированных систем для управления ИТ-активами стоит отметить системы класса CMDB (Configuration Management Database, база данных управления конфигурацией), которые предназначены для хранения, обработки, поддержания в актуальном состоянии информации об активах и их взаимосвязях. Программные (например, ОС, ПО, файлы) и аппаратные (например, серверы, ПК, сетевые устройства) активы в терминологии CMDB называются CI (Configuration Items, конфигурационные единицы). Системы CMDB постепенно эволюционировали в многофункциональные решения для управления активами (ITAM, IT Asset Management), которые включают в себя такие функции, как первоначальное наполнение информацией об активах, обогащение и поддержание сведений в актуальном состоянии и автоматизация данного  процесса, интеграция с разнообразными системами, содержащими ценную информацию об ИТ-активах. При этом некоторые решения по управлению активами дополнительно поддерживают получение актуальных данных о новых активах в сети компании, а также взаимодействуют с СЗИ в целях реагирования на несанкционированное появление нового устройства в сети.

Инвентаризация

Компаниям из сегментов среднего и малого бизнеса применение полноценных масштабных CMDB/ITAM-решений может показаться избыточным, поэтому мы приведем далее некоторые практические рекомендации по получению инвентаризационных данных «своими силами» без дополнительных финансовых затрат. Сфокусируемся на использовании штатного функционала ОС (возьмем доменную инфраструктуру на базе ОС Windows как наиболее часто встречающуюся) с использованием минимальных привилегий в инфраструктуре, руководствуясь принципом «least privilege». Сразу оговоримся, что некоторые из приведенных ниже способов могут использоваться и злоумышленниками, производящими рекогносцировку, закрепление и дальнейшее продвижение в сети атакованной компании, поэтому следует контролировать выполнение подобных запросов в защищаемой инфраструктуре (практические рекомендации по такому мониторингу мы дадим по тексту).

При инвентаризации целесообразно будет получать информацию о конфигурации устройств (версия ОС и установленные обновления, настройки ОС и ПО, установленное программное и аппаратное обеспечение, характеристики сетевых адаптеров), а также данные о залогиненном пользователе. Принципиально существуют два способа получения инвентаризационных данных с устройств: агентный и безагентный. В случае агентного способа на устройства устанавливается агент — клиент инвентаризации, который собирает информацию об устройстве и передает на сервер инвентаризации, и этот подход имеет свои особенности: требуется контролировать работоспособность самого агента, его нагрузку (footprint) на конечное устройство, обновлять агенты и обслуживать сервер управления агентами и т.д.. В случае же безагентного варианта сам сервер инвентаризации подключается к интересующему хосту и получает от него информацию, однако, для данного способа необходимы соответствующие полномочия доступа. К сожалению, многие ИТ/ИБ-решения для инвентаризации Windows-устройств в домене рекомендуют использовать учетные записи, обладающие административными привилегиями, однако в рамках данного материала мы сосредоточимся на проведении инвентаризации Windows-устройств с использованием ограниченных полномочий для сканирующей учетной записи. Главная причина использования ограниченных учетных записей — это опасность реализации т.н. replay-атак (атак повторного воспроизведения), примерами которых являются атаки Pass-the-Hash и Pass-the-Ticket. Обе атаки используют сохраненные в памяти удаленного процесса lsass.exe соответственно NTLM-хэши и Kerberos-билеты сканирущей учетной записи. Теперь представим, что один из инвентаризируемых ПК заражен вредоносом, который обладает административными правами на зараженном ПК и может прочитать память процесса lsass.exe для того, чтобы сдампить NTLM-хэши и/или Kerberos-билеты. Подключаясь к такому инфицированному ПК с учетной записью, обладающей админскими полномочиями на всех ПК в домене, мы рискуем значительно облегчить задачу атакующему и обеспечить его беспрепятственное горизонтальное продвижение по сети и заражение других устройств. Поэтому, руководствуясь принципом наименьших привилегий (least privilege), мы рекомендуем использовать именно ограниченные учетные записи, которые, даже в случае их «угона», не позволят атакующему существенно развить атаку.

Опишем далее основные способы инвентаризации Windows-устройств без административных полномочий. В рассматриваемых примерах мы будем использовать доменную учетную запись domain.local\Scan, выделенную для инвентаризации оборудования, и будем сканировать условный доменный ПК с именем pcname.domain.local, работающий на ОС Windows. В реальной инфраструктуре рекомендуем включить выбранную для сканирования УЗ в доменную группу Protected Users, для которой применяется только Kerberos-протокол аутентификации с TGT-билетом, выдающимся на 4 часа (а не на дефолтные 10 часов), а также будет использоваться криптографический стандарт AES при аутентификации. Кроме того, разумно будет проводить регулярную ротацию паролей данной УЗ и отключать её на время, когда сканирование не производится. Следует также учесть, что обращение к удаленному устройству по IP-адресу в Windows предполагает использование аутентификации по NTLM, а не Kerberos, поэтому рекомендуем выгрузить список устройств например из Active Directory и опрашивать их именно по DNS-именам.

Далее мы рассмотрим два не самых современных, но универсальных способа получения инвентаризационных данных с удаленных устройств под управлением ОС Windows: удаленный реестр и WMI. Разумеется, есть большое количество встроенных в ОС Windows более совершенных и удобных инструментов получения информации с удаленных устройств, которые могут быть также настроены на работу по принципу наименьших привилегий, например PowerShell Remoting с настроенными Constrained Endpoints или опции Just Enough Administration. Однако, к сожалению, даже в крупных компаниях до сих пор нередки случаи использования устаревших ОС, вплоть до Windows Server 2003 и Windows XP, поэтому сначала мы рассмотрим такие казалось бы устаревшие, но универсальные и мощные инструменты сбора инвентаризационной информации, как удаленный реестр и WMI, а во второй части статьи перейдем к сбору информации через более современный механизм WinRM.

1. Удаленный реестр

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

1) Необходимые настройки

1. Сетевые настройки: доступ к устройству с помощью удаленного реестра осуществляется по портам TCP: 135 (MS RPC), 445 (SMB, подключения к удаленному реестру будут видны на сканируемом устройстве в оснастке compmgmt.msc — «Общие папки» — «Сеансы» и «Открытые файлы»).

2. Подключение к удаленному реестру требует включение службы «Удаленный реестр» (RemoteRegistry).

3. Потребуется предоставить сканирующей учетной записи права чтения на ветки реестра, которые будут опрашиваться удаленно.

4. Потребуется предоставить сканирующей учетной записи права чтения на ветку HKLM\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg . Права на чтение этой ветки дают сканирующей УЗ принципиальное право подключаться удаленно к тем веткам реестра, которые прописываются в следующем шаге.

5. В ветке реестра HKLM\CurrentControlSet\Control\SecurePipeServers\Winreg\AllowedPaths в значении ключа Machine прописываются пути к тем веткам реестра, которые будут доступны удаленно и доступ к которым предоставлен сканирующей учетной записи в шаге 3. В данном ключе реестра можно указать определенную верхнеуровневую ветку, а доступ к вложенным путям (подветкам) будет предоставлен автоматически. Данный параметр реестра соответствует настройкам политики Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options — Network access: Remotely accessible registry paths and sub-paths (Конфигурация компьютера \ Конфигурация Windows \ Параметры безопасности \ Локальные политики \  Параметры безопасности \  Сетевой доступ: удаленно доступные пути и вложенные пути реестра). Если требуется указать точные ветки реестра, без вложенных путей, то они прописываются в соседнем параметре  AllowedExactPaths, который соответствует настройкам политики Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options \ Network access: Remotely accessible registry paths ( Конфигурация компьютера \ Конфигурация Windows \ Параметры безопасности \ Локальные политики \  Параметры безопасности —  Сетевой доступ: удаленно доступные пути реестра. ). При этом, разумеется, не следует предоставлять удаленный доступ к таким критичным веткам реестра, как HKLM\Security\Cache (хранит закешированные хэши паролей доменных пользователей), HKLM\SAM\SAM (хранит хэши паролей локальных пользователей), HKLM\Security\Policy\Secrets (хранит LSA secrets).

6. После выполнения всех настроек и для применения новых ACL на ветки реестра надо перезапустить службу «Удаленный реестр» (RemoteRegistry).

2) Реализация

Для целей инвентаризации будет полезно, например, получать список установленного на удаленном устройстве ПО с указанием версии и каталога установки: 

$list=@()

$pcname = 'pcname.domain.local'

$InstalledSoftwareKey="SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall"

$InstalledSoftware=[microsoft.win32.registrykey]::OpenRemoteBaseKey('LocalMachine',$pcname)

$RegistryKey=$InstalledSoftware.OpenSubKey($InstalledSoftwareKey) 

$SubKeys=$RegistryKey.GetSubKeyNames()

Foreach ($key in $SubKeys){

$thisKey=$InstalledSoftwareKey+"\\"+$key

$thisSubKey=$InstalledSoftware.OpenSubKey($thisKey)

$obj = New-Object PSObject

$obj | Add-Member -MemberType NoteProperty -Name "DisplayName" -Value $($thisSubKey.GetValue("DisplayName"))

$obj | Add-Member -MemberType NoteProperty -Name "DisplayVersion" -Value $($thisSubKey.GetValue("DisplayVersion"))

$obj | Add-Member -MemberType NoteProperty -Name "DisplayIcon" -Value $($thisSubKey.GetValue("DisplayIcon"))

$obj | Add-Member -MemberType NoteProperty -Name "InstallLocation" -Value $($thisSubKey.GetValue("InstallLocation"))

$list += $obj

}

$list | FL *

 Отметим, что метод опроса установленного ПО именно через реестр является более предпочтительным, нежели WMI-запрос класса Win32_Product (например, с помощью Get-WmiObject -Class Win32_Product), который будет отрабатывать достаточно долго, начнет выполнять проверку корректности установленного ПО и может привести к автоматическому запуску процедуры переустановки ПО. При этом некоторые инвентаризационные данные получать из реестра нецелесообразно по причине трудности их интерпретации (например, сведения об установленных обновлениях ОС), поэтому далее мы расскажем об инвентаризации через WMI и WinRM.

3) Мониторинг удаленного доступа к реестру

Для аудита действий с ветками реестра следует включить политику  Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration \ Audit Policies \ Object Access \ Audit Registry — Enable ( Конфигурация компьютера \ Конфигурация Windows \ Параметры безопасности \ Конфигурация расширенной политики аудита \ Политики аудита системы \ Доступ к объектам \ Аудит реестра — Включить). Далее нужно настроить SACL (разрешения аудита) на те ветки реестра, доступ к которым следует контролировать.

Выполненные настройки аудита определенных веток реестра можно распространить в домене через соответствующие объекты GPO. После перезапуска службы «Удаленный реестр» (RemoteRegistry) в случае доступа (и локального, и удаленного) к контролируемым веткам реестра в журнале «Безопасность» (Security) будут создаваться события EventID=4663 с указанием имени УЗ, получившей доступ, имени процесса и ветки реестра.

2. WMI-запросы через DCOM

Среди преимуществ инвентаризации с использованием WMI-запросов можно выделить нативную поддержку WMI во всех ОС семейства Microsoft Windows начиная с Windows 98 и до самых актуальных версий данной ОС. К числу минусов отнесем относительную нетривиальность корректной настройки WMI для удаленного подключения с минимально необходимыми правами, а также небезопасность некоторых настроек WMI по умолчанию. Доступ к WMI через WinRM лучше защищен, но не столь универсален и не будет по умолчанию работать на ОС Windows XP и 2003/2008 — мы обсудим данный метод подключения далее. 

1) Необходимые настройки

 1. Сетевые настройки: WMI – это протокол прикладного уровня, работающий поверх протокола прикладного уровня DCOM, который в свою очередь работает поверх протокола сессионного уровня MS RPC. Первоначальное соединение устанавливается по TCP:135, затем по согласованию между клиентом и сервером выбирается динамический TCP-порт. Для выбора какого-либо конкретного диапазона портов для DCOM-взаимодействия можно открыть оснастку управления DCOM (dcomcnfg), в ветке «Службы компонентов» открыть свойства сущности «Мой компьютер» и в открывшемся окне перейти на вкладку «Набор протоколов», где можно будет добавить произвольный диапазон портов (рекомендуется указывать диапазон не менее 1000 портов).

Кроме указанного способа на ОС старше Windows Server 2008 для настройки выделенного порта для удаленного подключения WMI можно перейти в настройки управления DCOM (dcomcnfg), в ветке «Службы компонентов» открыть «Мой компьютер», далее открыть вкладку  «Настройка DCOM» и открыть свойства приложения «Windows Management and Instrumentation». Далее на вкладке «Конечные узлы» нужно нажать кнопку «Добавить», в открывшемся окне в выпадающем списке последовательности протоколов выбрать «TCP/IP с ориентацией на подключение» и, переключив radio-button в значение «Использовать статический узел», ввести номер желаемого TCP-порта, например TCP:31000.

Далее, в соответствии с рекомендациями вендора, в командной строке нужно выполнить команду

winmgmt -standalonehost

и затем перезапустить службу «Инструментарий управления Windows» (Windows Management Instrumentation, winmgmt ), например, командами

net stop winmgmt /yes && net start winmgmt

Затем нужно разрешить входящие WMI-подключения на выбранный порт TCP:31000 в Windows Firewall, создав новое правило «WMIFixedPort» командой

netsh advfirewall firewall add rule name=»WMIFixedPort» dir=in action=allow protocol=TCP localport=31000 enable=yes profile=domain

Отмену изменений можно осуществить командой

winmgmt -sharedhost

с последующим перезапуском службы winmgmt. Затем созданное на Windows Firewall правило можно отключить или удалить.

 2. Для работы с WMI должна быть запущена служба «Инструментарий управления Windows» (Windows Management Instrumentation, winmgmt ).

 3. Нужно будет добавить сканирующую УЗ в группу локальных пользователей на сканируемых устройствах. При этом по умолчанию в группу локальных пользователей на доменных ПК включаются группы Domain Users, Authenticated Users, Interactive. Группа Authenticated Users (SID S-1-5-11) в свою очередь включает в себя всех доменных пользователей (User accounts) и все устройства (Computer accounts). Поэтому если на сканируемом устройстве членство группы локальных пользователей оставлено в состоянии по умолчанию, то никаких дополнительных действий не требуется. Однако, при защищенной настройке ОС Windows мы рекомендуем как минимум на серверах по умолчанию удалять из группы локальных пользователей всех и добавлять группу администраторов сервера для избегания проблем с отображением рабочего стола при включенном UAC.

 4. Потребуется предоставить сканирующей УЗ права доступа на WMI-объекты. Для выполнения WMI-запросов и запуска WMI-методов следует на WMI-пространство имен «Root» и на все подпространства имен предоставить для сканирующей УЗ права «Включить учетную запись» (Enable account) и «Включить удаленно» (Remote enable). При этом если для выполнения сканирования и инвентаризации планируется удаленно вызывать WMI-методы, примеры которых будут приведены ниже, то для таких действий потребуется предоставить еще и разрешение «Выполнение методов» (Execute method). Вручную описанные права можно предоставить из оснастки wmimgmt.msc — свойства элемента управления WMI — вкладка «Безопасность», свойства пространства «Root».

При этом следует учитывать, что не все подпространства имен WMI наследуют настройки пространства «Root» — так, например, подпространство Root\CIMV2\Security\MicrosoftVolumeEncryption, в котором содержатся данные о состоянии BitLocker-шифрования дисков устройства, не наследует DACL от корневого WMI-пространства.

В условиях домена и большого количества инвентаризируемых устройств следует, однако, автоматизировать процесс назначения прав доступа на WMI-объекты. Можно воспользоваться рекомендациями и выполнить операцию чтения настроек безопасности (Дескрипторов безопасности, Security Descriptor, SD) WMI-пространства «Root» с уже настроенного устройства, на котором WMI-права доступа для сканирующей УЗ были настроены вручную, с записью результата в текстовый файл:

wmic /namespace:\\root /output:»C:\folder\sd.txt» path __systemsecurity call getSD

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

SD = {1, 0, 4, 128, 148, 0, 0, 0, … 0}

Данный набор надо скопировать в текстовый файл, удалить все пробелы, а затем вставить очищенный от пробелов массив данных в VBS-скрипт следующего содержания:  

strSD = array(1,0,4,128,148,0,0,0,...0)

set namespace = createobject("wbemscripting.swbemlocator").connectserver(,"root")

set security = namespace.get("__systemsecurity=@")

nStatus = security.setsd(strSD)

Далее получившийся файл можно сохранить с расширением .vbs и запустить на всех сканируемых ПК с помощью соответствующего объекта групповой политики Windows. В случае ручного выполнения скрипта его надо запускать с административными полномочиями. Если потребуется применить DACL на WMI-подпространство, отличное от «Root», то выполняемые команды и скрипты должны быть модифицированы. Например, для подпространства MicrosoftVolumeEncryption они будут выглядеть следующим образом:

wmic /namespace:\\root\CIMV2\Security\MicrosoftVolumeEncryption /output:»C:\folder\sd.txt» path __systemsecurity call getSD

и

strSD = array(1,0,4,128,148,0,0,0,...0)

set namespace = createobject("wbemscripting.swbemlocator").connectserver(,"root\CIMV2\Security\MicrosoftVolumeEncryption")

set security = namespace.get("__systemsecurity=@")

nStatus = security.setsd(strSD)

5. Настройки DCOM

Для обеспечения удаленной работы через WMI следует настроить также права доступа к объектам DCOM, поскольку WMI-объекты являются их подмножеством. Проще всего добавить сканирующую УЗ в группу «Пользователи DCOM» (DCOM Users), но это даст некоторые избыточные полномочия на локальный запуск компонентов DCOM. Поэтому более правильно будет выполнить последовательность следующих действий:

1) Через GPO настроить политику Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options — DCOM: Machine Access Restrictions in SDDL syntax (Конфигурация компьютера \ Конфигурация Windows \ Параметры безопасности \ Локальные политики \  Параметры безопасности —  DCOM: Ограничения компьютера на доступ в синтаксисе SDDL), предоставив сканирующей УЗ право «Удаленный доступ» (Remote Access).

Данная настройка отражается в ключе реестра по пути HKLM \ Software \ Policies \ Microsoft \ Windows NT \ DCOM, ключ MachineAccessRestriction, его значение соответствует предоставленным правам доступа, выраженным в SDDL-синтаксисе.

 Вручную данная настройка делается через оснастку dcomcnfg, свойства «Мой компьютер», на вкладке «Безопасность COM» в разделе «Права доступа» нажать на кнопку «Изменить ограничения…» и предоставить сканирующей УЗ права «Удаленный доступ».

2) Через GPO настроить политику Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options — DCOM: Machine Launch Restrictions in SDDL syntax (Конфигурация компьютера \ Конфигурация Windows \ Параметры безопасности \ Локальные политики \  Параметры безопасности —  DCOM: Ограничения компьютера на запуск в синтаксисе SDDL), предоставив сканирующей УЗ права «Удаленный запуск» (Remote Launch) и «Удаленная активация» (Remote Activation).

Данная настройка отражается в ключе реестра по пути HKLM — Software — Policies — Microsoft — Windows NT — DCOM, ключ MachineLaunchRestriction, его значение соответствует предоставленным правам доступа, выраженным в SDDL-синтаксисе.

 Вручную данная настройка делается через оснастку dcomcnfg, свойства «Мой компьютер», на вкладке «Безопасность COM» в разделе «Разрешения на запуск и активацию» нажать на кнопку «Изменить ограничения…» и предоставить сканирующей УЗ права «Удаленный запуск» и «Удаленная активация».

3) После применения настроек прав доступа на DCOM на сканируемом устройстве в случае возникновения ошибок будет целесообразным проверить настройки безопасности для DCOM-приложения «Windows Management and Instrumentation»: перейти в настройки управления DCOM (dcomcnfg), в ветке «Службы компонентов» открыть «Мой компьютер», далее открыть вкладку  «Настройка DCOM» и открыть свойства приложения «Windows Management and Instrumentation». Далее на вкладке «Безопасность» проверить настройки пункта «Разрешения на запуск и активацию» (права «Удаленная активация» и «Удаленный запуск» для сканирующей УЗ), пункта «Разрешения на доступ» (право «Удаленный доступ» для сканирующей УЗ), пункта «Разрешение на изменение настроек» (право «Чтение» и детальные разрешения «Запрос значения», «Перечисление подразделов», «Уведомление», «Контроль чтения» для сканирующей УЗ).

6. Защита передаваемых через WMI данных.

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

Отметим, что есть две настройки WMI/DCOM, которые влияют на защищенность работы с данными протоколами: уровень олицетворения и уровень проверки подлинности.

 1) Уровень олицетворения задается через настройку «Уровня олицетворения» (Impersonation level), который определяет разрешения на использование вызываемым объектом учетных данных субъекта, который к нему обращается. Рекомендуемой настройкой является уровень олицетворения «Impersonate» («Олицетворение»). Данная настройка содержится в ветке реестра по пути HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\Scripting в параметре «Default Impersonation Level» — числовое значение «3» соответствует рекомендуемому уровню олицетворения «Impersonate», и в данном случае рекомендуемая безопасная настройка для WMI установлена по умолчанию.

Однако, для DCOM в целом по умолчанию установлены не самые строгие настройки уровня олицетворения, который установлен в значении «Определить» (Identify), что менее безопасно, чем рекомендуемый уровень «Олицетворение» (Impersonate). Поэтому можно изменить уровень олицетворения по умолчанию в настройках управления DCOM (dcomcnfg), в ветке «Службы компонентов» открыть свойства «Мой компьютер», далее открыть вкладку  «Свойства по умолчанию» и в выпадающем списке «Уровень олицетворения по умолчанию» установить значение «Олицетворение».

Централизованно в домене можно поменять уровень олицетворения на рекомендуемый, установив значение DWORD-параметра реестра «LegacyImpersonationLevel» в «3» по пути HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole , что будет соответствовать безопасному уровню олицетворения «Impersonate».

2) Уровень проверки подлинности задается через настройку «Уровня проверки подлинности» (Authentication level), который определяет уровень защиты (аутентичность, целостность и конфиденциальность) данных, передающихся через WMI/DCOM. Уровень по умолчанию для WMI установлен в значении Connect («Подключиться»), что ниже наиболее безопасного уровня Packet Privacy («Секретности пакетов»). Вручную данную настройку можно поменять в настройках управления DCOM (dcomcnfg), в ветке «Службы компонентов» открыть «Мой компьютер», далее открыть вкладку  «Настройка DCOM» и открыть свойства приложения «Windows Management and Instrumentation». Далее на вкладке «Общие» в настройке «Уровень проверки подлинности» в выпадающем списке нужно выбрать уровень «Секретности пакетов».

Эту же настройку можно выполнить централизованно через реестр, предварительно узнав «Код приложения» (App ID) для приложения «Windows Management and Instrumentation», например, в настройках управления DCOM (dcomcnfg), в ветке «Службы компонентов» открыть «Мой компьютер», далее открыть вкладку «Настройка DCOM» и открыть свойства приложения «Windows Management and Instrumentation» — на вкладке «Общие» будет указан искомый «Код приложения» (Application ID).

Далее в ветке реестра HKLM\SOFTWARE\Classes\AppID\{Код приложения} нужно создать DWORD-параметр AuthenticationLevel и задать ему значение «6», что будет соответствовать уровню Packet Privacy («Секретности пакетов»), а затем распространить данное значение реестра на доменные устройства.

Аналогично настройкам уровня олицетворения, для DCOM в целом по умолчанию установлены не самые строгие настройки уровня проверки подлинности, который установлен в значении «Подключиться» (Connect), что менее безопасно, чем рекомендуемый уровень Packet Privacy («Секретности пакетов»). Поэтому можно изменить уровень проверки подлинности по умолчанию в настройках управления DCOM (dcomcnfg), в ветке «Службы компонентов» открыть свойства «Мой компьютер», далее открыть вкладку  «Свойства по умолчанию» и в выпадающем списке «Уровень проверки подлинности по умолчанию» установить значение «Секретности пакетов».

Централизованно в домене можно поменять уровень проверки подлинности на рекомендуемый, установив значение DWORD-параметра реестра «LegacyAuthenticationLevel» в «6» по пути HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole , что будет соответствовать безопасному уровню проверки подлинности «Packet Privacy».

7. После выполнения настроек WMI следует перезапустить службу «Инструментарий управления Windows» (Windows Management Instrumentation, winmgmt). После изменения настроек DCOM потребуется выполнить перезагрузку устройства.

2) Реализация

Произведенные настройки дают возможность выполнения WMI-запросов и запуска WMI-методов на сканируемых ПК, которые могут выполняться в «классической» утилите wmic (Windows Management Instrumentation Command) и через PowerShell-командлет Get-WmiObject. Оба варианта поддерживают обращение к группам удаленных устройств и вывод полученных данных в разных формах. Упомянем также, что инструмент wmic в последних версиях Windows отмечен как устаревший (deprecated), однако продолжает исправно работать.

Приведем примеры полезных WMI-команд с некоторыми пояснениями.

Получение имен сетевых адаптеров на удаленном ПК с именем pcname.domain.local через PowerShell-командлет Get-WmiObject будет выглядеть так:

Get-WmiObject -ComputerName pcname.domain.local -Class Win32_NetworkAdapter | format-list Name

Этот запрос соответствует короткой записи с помощью PowerShell-алиасов:

gwmi -cn pcname.domain.local Win32_NetworkAdapter| fl Name

Данные запросы можно выполнить и без PowerShell, с помощью утилиты wmic. Так, команда

wmic /node:»pcname.domain.local» path Win32_NetworkAdapter get name

выполнит запрос WMI-класса Win32_NetworkAdapter и вернет список имен сетевых адаптеров.

Команда

wmic /node:»pcname.domain.local» nic get name

выполнит аналогичный запрос WMI-класса Win32_NetworkAdapter через алиас «nic». Полный список WMI-алиасов можно посмотреть командой wmic alias list full  , а краткую справку по определенном алиасу (например, по алиасу «nic») можно посмотреть к примеру так: wmic alias list brief | findstr /I nic

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

wmic /node:»pcname.domain.local» os get * /format:value (команда выведет информацию об ОС удаленного устройства)

Для удобства анализа и сохранения инвентаризационной информации можно использовать иные форматы представления полученных по WMI данных, например:

wmic /node:»pcname.domain.local» /output:»c:\folder\file.html» computersystem list full /format:htable (вывод общих сведений об устройстве в html-документ)

wmic /node:»pcname.domain.local» /output:»c:\folder\file.csv» path Win32_OperatingSystem get * /format:csv (вывод сведений об ОС в csv-файл)

При запросе WMI-алиасов также можно использовать и команду list с разнообразными значениями, например

wmic /node:»pcname.domain.local» nic list brief (просмотр краткой информации по сетевым адаптерам)

wmic /node:»pcname.domain.local» nic list status (просмотр статуса адаптеров)

wmic /node:»pcname.domain.local» nic list full /every:5 (запрос и интерактивное обновление информации каждые 5 секунд)

Более подробную информацию по форматам вывода можно получить в справке: wmic aliasname list /? (где aliasname — имя алиаса, например, nic)

Для уточнения интересующей инвентаризационной информации можно воспользоваться возможностями запросов в формате WQL (WMI Query Language), например, для выборки только физических сетевых адаптеров:

wmic /node:»pcname.domain.local» nic WHERE PhysicalAdapter=’true’ get * /format:value

что соответствует запросу

wmic /node:»pcname.domain.local» path Win32_NetworkAdapter WHERE PhysicalAdapter=’true’ get * /format:value

или через PowerShell

gwmi -cn pcname.domain.local -Query «Select * from Win32_NetworkAdapter WHERE PhysicalAdapter=’true’ » | fl *

Отметим, что по умолчанию и в PowerShell, и в wmic используется WMI-пространство имен «Root\Cimv2». Если запрашиваемая информация находится в другом подпространстве, то это надо указать явно, не забывая при этом, что права доступа на такое подпространство WMI могут и не наследоваться от корневого. Например, для запроса сведений о состоянии BitLocker-шифрования дисков устройства можно воспользоваться следующими командами, в которых указано запрашиваемое WMI-пространство имен:

wmic /node:»pcname.domain.local» /namespace:»\\Root\CIMV2\Security\MicrosoftVolumeEncryption» path Win32_EncryptableVolume get * /format:list

gwmi -cn pcname.domain.local -namespace:»Root\CIMV2\Security\MicrosoftVolumeEncryption» -class Win32_EncryptableVolume | fl *

Для вывода данных о BIOS и модели удаленного устройства можно использовать команды:

wmic /node:»pcname.domain.local» /namespace:»\\Root\wmi» path MS_SystemInformation get * /format:value

gwmi -cn pcname.domain.local -namespace:»Root\wmi» -class MS_SystemInformation | fl *

Для получения данных об установленном антивирусном средстве нужно опросить пространства имен Root\SecurityCenter (для версий ОС Windows XP/2003 и ниже) или Root\SecurityCenter2 (для версий ОС Windows Vista/2008 и выше):

wmic /namespace:»\\Root\SecurityCenter2″ path AntivirusProduct get * /format:value

gwmi -cn pcname.domain.local -namespace:»Root\SecurityCenter2″ -class AntivirusProduct | fl *

Отметим, что утилита wmic также поддерживает передачу в качестве параметра списка устройств в текстовом виде, а также указание логина и пароля в явном виде:

wmic /node:@pclist.txt /user:domain.local\Scan /password:P@$$w0rd CommandName

Рассмотрим далее удаленное выполнение WMI-методов, которое требует установленного разрешения «Выполнение методов» (Execute method) на WMI-пространство «Root». Например, запрос данных из реестра вызовом метода GetStringValue класса StdRegProv можно выполнить несколькими способами.

Выполним запрос имени УЗ последнего залогиненного пользователя из реестра через wmic:

wmic /node:»pcname.domain.local» /NameSpace:\\root\default Class StdRegProv Call GetStringValue sSubKeyName=»SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Authentication\\LogonUI» sValueName=»LastLoggedOnSAMUser» | findstr «sValue»

Или через PowerShell, с запросом дополнительных данных о залогиненной УЗ:

$hklm = 2147483650 #числовое обозначение HKLM-куста реестра

$key = "SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI"

$values = @('LastLoggedOnUser','LastLoggedOnUserSID','LastLoggedOnDisplayName')

Foreach ($value in $values) {

 $wmi = get-wmiobject -list "StdRegProv" -namespace root\default -computername pcname.domain.local

 ($wmi.GetStringValue($hklm,$key,$value)).svalue

 $wmi2 = ($wmi.GetStringValue($hklm,$key,$value)).svalue

}

Отметим также, что через WMI с наличием разрешения «Выполнение методов» (Execute method) на удаленной системе можно также запустить новый процесс вызовом метода Create класса Win32_process. При этом по умолчанию данный способ не позволяет запустить на удаленном ПК новый процесс от имени сканирующей УЗ, если профиль данной УЗ не загружен. Однако это ограничение можно обойти путем предоставления сканирующей УЗ привилегии SeRestorePrivilege (Restore files and directories , Восстановление файлов и каталогов), без наличия которой WMI вернет ошибку «Return Value=8». Это можно сделать через политику Computer Configuration\Windows Settings\Security Settings\User rights assignment — Restore files and directories ( Конфигурация компьютера \ Конфигурация Windows \ Параметры безопасности \ Локальные политики  \ Назначение прав пользователя  — Восстановление файлов и каталогов). Отметим, что запущенные таким образом процессы на удаленном устройстве не будут интерактивными, т.е. их взаимодействие с целевой ОС будет весьма ограничено, однако следует помнить, что привилегия SeRestorePrivilege дает полный доступ на запись ко всей файловой системе устройства, что позволит потенциальному атакующему перезаписать любой легитимный файл, например, системный сервис, библиотеку, утилиту и т.д. Поэтому, если все же принято решение о необходимости удаленного запуска процессов через WMI (например, в рамках процедуры реагирования на киберинциденты по результатам инвентаризации), то следует рассмотреть вариант включения УЗ, обладающей данной привилегией, только непосредственно в момент реагирования на инцидент, с отключением данной УЗ сразу после завершения выполнения команд на удаленном устройстве, с дальнейшей немедленной сменой пароля к ней.

Примеры запуска удаленных процессов через WMI:

wmic /node:»pcname.domain.local» path Win32_Process Call Create «cmd.exe /c C:\folder\batch.bat» (запуск преднастроенного bat-файла на удаленном ПК)

Invoke-WmiMethod -ComputerName pcname.domain.local -Class Win32_process -Name Create -ArgumentList ‘cmd /c schtasks /run /tn «task1» ‘ (запуск преднастроенной задачи «task1» из «Планировщика задач»)

Следует также учесть, что, если в целях реагирования на киберинциденты решено применять запуск удаленных процессов через WMI, то ограничения удаленно запущенных процессов (их неинтерактивность) не позволят выполнить ряд действий, в частности, не удастся получить полные пути запущенных процессов, что может пригодиться для получения хэш-сумм запущенных на удаленном устройстве процессов с последующей обработкой в системах CyberThreat Intelligence. Вариантом обхода таких ограничений будет предоставление сканирующему аккаунту могущественной привилегии  SeDebugPrivilege (Debug Program, Отладка программ). Это можно сделать через политику Computer Configuration\Windows Settings\Security Settings\User rights assignment — Debug Program ( Конфигурация компьютера \ Конфигурация Windows \ Параметры безопасности \ Локальные политики  \ Назначение прав пользователя  —  Отладка программ). При этом данная привилегия является фактически аналогом прав локального администратора и позволит потенциальному атакующему выполнить любые действия на устройстве. Ограничение несанкционированного использования данной привилегии, наряду с защитой памяти процесса LSA и другими методами, является мерой защиты (но не стопроцентной) от похищения учетных данных из ОС Windows, например, с помощью mimikatz и подобных утилит. Поэтому (по аналогии с использованием SeRestorePrivilege) следует рассмотреть вариант включения УЗ, обладающей привилегией SeDebugPrivilege, только непосредственно в момент реагирования на инцидент, с отключением данной УЗ сразу после завершения выполнения команд на удаленном устройстве, с дальнейшей немедленной сменой пароля к ней.

Таким образом, мы сможем получать данные о путях к образам выполняемых удаленно процессов:

wmic /node:»pcname.domain.local» path Win32_Process get ExecutablePath

или

gwmi win32_process -ComputerName pcname.domain.local | fl ExecutablePath

Совместив привилегии SeRestorePrivilege и SeDebugPrivilege, а также убедившись, что используемой УЗ предоставлены WMI-права Enable account, Remote enable и Execute method, мы сможем получать списки хэшей исполняемых удаленно процессов, например, для реагирования на киберинцидент:

Invoke-WmiMethod -ComputerName pcname.domain.local -Class Win32_Process -Name Create -ArgumentList ‘powershell.exe -command «get-process | get-unique | ForEach-Object {Get-FileHash $_.path -Algorithm SHA256} | fl * | out-file C:\folder\$env:COMPUTERNAME.$(get-date -format HH-mm-ss.dd.MM.yyyy).txt» ‘

Затем несложно будет автоматизировать отправку полученных значений хэш-сумм в системы анализа индикаторов компрометации, например, на VirusTotal через публичный API с использованием конструкций вида

Invoke-RestMethod -Method ‘POST’ -Uri «https://www.virustotal.com/vtapi/v2/file/report?apikey=$VTApiKey&resource=$item»

(где переменная VTApiKey — получаемый при регистрации бесплатного аккаунта VirusTotal Community API-токен, а переменная item — это значение проверяемой хэш-суммы). Или же можно сравнивать полученные значения хэш-сумм с известными «хорошими» хэшами, например, используя данные проекта xCyclopedia. Но стоит помнить, что если исследуемый ПК все же был заражен, то сканирующую УЗ нужно будет считать скомпрометированной со всеми вытекающими обстоятельствами, особенно с учетом предоставленных ей полномочий (выполнение WMI-методов, привилегии SeRestorePrivilege и SeDebugPrivilege).

3) Мониторинг удаленного доступа к WMI-объектам и запуска процессов

Для аудита действий с WMI-объектами следует включить политику  Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration \ Audit Policies \ Object Access \ Audit other object access events — Enable ( Конфигурация компьютера \ Конфигурация Windows \ Параметры безопасности \ Конфигурация расширенной политики аудита \ Политики аудита системы \ Доступ к объектам \ Аудит других событий доступа к объектам — Включить).

Далее нужно настроить SACL (разрешения аудита) на те WMI-объекты, доступ к которым следует контролировать.

Выполненные настройки аудита определенных WMI-объектов можно централизованно применить в домене по аналогии с распространением настроек DACL — через запуск на устройствах VBS-скрипта, содержащего команду на установку требуемого SACL для аудита WMI-объектов. После перезапуска службы «Инструментарий управления Windows» (Windows Management Instrumentation, winmgmt) в случае доступа (и локального, и удаленного) к контролируемым WMI-объектам в журнале «Безопасность» (Security) на удаленном устройстве будут создаваться события EventID=4662 с указанием имени УЗ, выполнившей WMI-запрос, самого WMI-запроса и имени опрошенного адресного пространства WMI.

Для аудита запущенных через WMI удаленных процессов потребуется включить политику «Конфигурация компьютера \ Конфигурация Windows \ Параметры безопасности \ Конфигурация расширенной политики аудита \ Политики аудита системы \ Подробное отслеживание \ Аудит создания процессов — Включить» (Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration \ Audit Policies \ Detailed tracking \ Audit process creation — Enable ), а также политику «Конфигурация компьютера \ Конфигурация Windows \ Административные шаблоны \ Система \ Аудит создания процессов — Включать командную строку в события создания процессов» (Computer Configuration \ Administrative Templates\System\Audit Process Creation — Include command line in process creation events). После этой настройки при удаленном запуске процессов в журнале «Безопасность» (Security) на удаленном устройстве будут создаваться события EventID=4688 с указанием имени УЗ и текста выполненной удаленно команды, имени и пути к образу созданного процесса, а также имени родительского процесса (в случае удаленного запуска процессов через WMI это будет C:\Windows\System32\wbem\WmiPrvSE.exe).

Для мониторинга использования привилегии SeRestorePrivilege потребуется включить политику «Конфигурация компьютера \ Конфигурация Windows \ Параметры безопасности \ Конфигурация расширенной политики аудита \ Политики аудита системы \ Использование прав — Аудит использования прав, затрагивающих конфиденциальные данные» (Computer Configuration\Windows Settings\Advanced Audit Policy Configuration\Privilege Use — Audit Sensitive Privilege Use), а также политику «Конфигурация компьютера \ Конфигурация Windows \ Параметры безопасности \ Локальные политики \ Параметры безопасности — Аудит: аудит прав на архивацию и восстановление» (Computer Configuration\Windows Settings\Security Settings\Local Policies \ Security Options \ Audit: Audit the use of Backup and Restore privilege) . В этом случае в журнале «Безопасность» (Security) на удаленном устройстве будут создаваться события EventID=4674 (An operation was attempted on a privileged object) с указанием имени УЗ и назначенной привилегии.

Для мониторинга использования привилегии SeDebugPrivilege потребуется включить политику «Конфигурация компьютера \ Конфигурация Windows \ Параметры безопасности \ Конфигурация расширенной политики аудита \ Политики аудита системы \ Вход/выход —  Аудит специального входа» (Computer Configuration\Windows Settings\Advanced Audit Policy Configuration\Audit Policies\Logon/Logoff — Audit Special Logon )  . В этом случае в журнале «Безопасность» (Security) на удаленном устройстве будут создаваться события EventID=4672 (Special privileges assigned to new logon) с указанием имени УЗ и назначенной привилегии.

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

https://www.blackhat.com/docs/us-14/materials/us-14-Kazanciyan-Investigating-Powershell-Attacks-WP.pdf

https://www.blackhat.com/docs/us-15/materials/us-15-Graeber-Abusing-Windows-Management-Instrumentation-WMI-To-Build-A-Persistent%20Asynchronous-And-Fileless-Backdoor-wp.pdf

3. WMI-запросы через WinRM

Рассмотренный ранее способ инвентаризации удаленных Windows-устройств с помощью WMI-запросов через протокол DCOM на современных ОС, начиная с Windows 7/2008R2, может быть заменен на работу с Common Information Model, т.е. на опрос CIM-объектов с помощью механизма Windows Remote Management (WinRM, использует протокол WSMan (WS-Management, Web Services for Management)) и PowerShell-командлетов Get-CimInstance и Invoke-CimMethod, которые заменили соответственно устаревшие командлеты Get-WmiObject и Invoke-WmiMethod. Функционал создания удаленных CIM-сессий позволяет явно указать протокол удаленного подключения (DCOM или WSMan) на основе результатов работы командлета Test-WSMan, который возвращает версию стека протокола WS-Management. По умолчанию для ОС Windows 8/2012 и выше используется версия 3.0, для ОС Windows 7/2008R2 — версия 2.0, а для ОС Windows XP/2003/2008 и ниже механизм WinRM и протокол WS-Management по умолчанию не устанавливались, но могли быть проинсталлированы дополнительно. При этом удаленное получение данных со множества устройств через WinRM должно выполняться существенно быстрее, чем через DCOM.

По умолчанию для шифрования WSMan-трафика в пределах одного Windows-домена используется Керберос-шифрование SOAP-данных, передаваемых через WinRM (режим HTTP-Kerberos-session-encrypted), при этом используется порт TCP:5985 (до Windows 7/2008 использовался TCP:80), а HTTP-заголовки и соответствующие метаданные передаются в открытом виде. Другой опцией является использование HTTPS с установкой SSL-сертификатов на взаимодействующих устройствах, которые могут не принадлежать одному домену, при этом используется порт TCP:5986 (в старых версиях Windows использовался TCP:443). При дальнейшем изложении будем считать, что мы работаем в одном домене и используем настройку по умолчанию.

Для обеспечения инвентаризации через WinRM на удаленном устройстве следует выполнить команду winrm qc -q , которая включит «Службу удаленного управления Windows» (Windows Remote Management (WS-Management), WinRM) и настроит прослушивание порта TCP:5985 для входящих соединений. Централизованно разрешить использование WinRM можно через политику «Конфигурация компьютера \ Административные шаблоны \ Компоненты Windows \ Удаленное управление Windows \ Служба удаленного управления Windows — Разрешить удаленное администрирование сервера средствами WinRM» (Computer Configuration \ Administrative Templates \ Windows Components \ Windows Remote Management (WinRM) \ WinRM Service — Allow remote server management through WinRM). Настройка фильтрации IP-адресов, присутствующая в данной политике, к сожалению, регулирует только локальные адреса сетевых адаптеров удаленных устройств, которые будут принимать подключения, поэтому в фильтрах можно установить значение «*». Для сетевой фильтрации подключений через WinRM можно использовать настройку Windows Firewall, создав, например, правило такого вида:

netsh advfirewall firewall add rule name=»WinRM-HTTP» dir=in action=allow protocol=TCP localport=5985 remoteip=X.X.X.X enable=yes profile=domain

где X.X.X.X — адрес сервера инвентаризации, с которого будет осуществляться удаленный доступ.

Просмотреть текущее состояние службы WinRM можно командой winrm get winrm/config , состояние прослушивателя WinRM-соединений — через команду winrm enumerate winrm/config/listener , а версию протокола WSMan — командой winrm id . Для «отката» изменений, внесенных командой winrm qc , потребуется отключить службу «Удаленное управление Windows» (Windows Remote Management (WS-Management) , WinRM) и выполнить команду удаления WinRM-прослушивателя: winrm delete winrm/config/Listener?Address=*+Transport=HTTP  . Также следует учесть, что выполнение команды winrm qc одновременно включает Windows Remote Shell (WinRS) и разрешает принимать входящие соединения для удаленного управления через функционал WinRS. Отключить WinRS можно либо через политику «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Удаленная оболочка Windows / Разрешить доступ к удаленной оболочке — Запретить» (Computer Configuration / Administrative Templates / Windows Components / Windows Remote Shell / Allow Remote Shell Access — Disabled), либо командой winrm set winrm/config/winrs @{AllowRemoteShellAccess=»false»} .

Далее следует предоставить сканирующей УЗ права доступа через WinRM. Можно это сделать, включив на удаленном ПК сканирующую УЗ в группу «Пользователи удаленного управления» (Remote Management Users), которая появилась в ОС Windows 10/2016, а на предыдущих версиях ОС использовалась группа «WinRMRemoteWMIUsers__». Однако, права удаленного WinRM-доступа, предоставляемые членам указанной группы, будут избыточны для целей инвентаризации — в частности, членам этой группы будут предоставлены разрешения на удаленное управление ПК через PowerShell Remoting. Поэтому можно предоставить гранулированные права доступа на CIM-ресурс, выполнив команду

winrm configsddl http://schemas.dmtf.org/wbem/wscim/1/cim-schema

В открывшемся окне нужно предоставить право «Чтение» / Read (Get,Enumerate,Subscribe) для запроса данных через командлет Get-CimInstance и право «Выполнение» / Execute (Invoke) для выполнения методов через командлет Invoke-CimMethod.

Кроме этого, в случае если планируется только запрашивать WMI-данные через Get-CimInstance, то на WMI-пространстве на удаленном устройстве будет достаточно задать для сканирующей УЗ только разрешения «Включить учетную запись» (Enable account) и «Включить удаленно» (Remote enable). Если же планируется выполнять удаленно методы через Invoke-CimMethod, то на WMI-пространстве на удаленном устройстве потребуется задать еще и разрешение «Выполнение методов» (Execute method). Также следует обеспечить сетевую доступность сканируемого устройства по TCP:5985, а для удаленного запуска процессов сканирующей УЗ потребуется привилегия SeRestorePrivilege.

Настройки CIM-ресурса хранятся в ветке реестра HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Plugin\WMI Provider в параметре ConfigXML, который содержит строковое значение в формате XML, включая настроенные права доступа на CIM-ресурс (в SDDL-синтаксисе). Следует иметь ввиду, что значение параметра ConfigXML также содержит свойство Architecture, указывающее на разрядность целевой ОС. Централизованно применить сделанную настройку можно, распространив данный ключ реестра в домене через GPO. Более подробно про гранулированное предоставление прав удаленного доступа через WinRM можно почитать по ссылкам:

https://www.sevecek.com/EnglishPages/Lists/Posts/Post.aspx?ID=10

Demystifying WinRM

Сделав такие настройки и перезапустив «Службу удаленного управления Windows» (Windows Remote Management (WS-Management) , WinRM), мы сможем выполнять, например, нижеследующие команды на удаленном устройстве.

Запрос из CIM данных об установленных на удаленном ПК сетевых адаптерах:

Get-CimInstance -ComputerName pcname.domain.local -Class Win32_NetworkAdapter

Получение списка хэшей исполняемых удаленно процессов, при наличии привилегий SeRestorePrivilege и SeDebugPrivilege:

Invoke-CimMethod -ComputerName pcname.domain.local -ClassName Win32_Process -MethodName Create -Arguments @{CommandLine = ‘powershell.exe -command «get-process | get-unique | ForEach-Object {Get-FileHash $_.path -Algorithm SHA256} | fl * | out-file C:\folder\$env:COMPUTERNAME.$(get-date -format HH-mm-ss.dd.MM.yyyy).txt» ‘ }

Отметим, что по аналогии с «классическими» WMI-запросами, аудит удаленного доступа к CIM-объектам можно выполнять, настроив политику «Аудит других событий доступа к объектам» — в журнале «Безопасность» (Security) на удаленном устройстве будут создаваться события EventID=4662 при удаленном получении информации через Get-CimInstance. Если же включить политики «Аудит создания процессов» и «Включать командную строку в события создания процессов», то в журнале «Безопасность» (Security) на удаленном устройстве будут создаваться события EventID=4688 при удаленном запуске процессов через Invoke-CimMethod.

4. Предоставление дополнительных прав доступа

Описанные в предыдущем пункте ограниченные привилегии позволяют выполнять многие CIM/WMI-запросы и методы. Однако, в ОС Windows есть определенные ограничения, которые не позволяют удаленно выполнять определенные действия — например, просматривать список выполняющихся служб или получать список установленных обновлений ОС на удаленном ПК. Разумеется, при выполнении инвентаризационных запросов от УЗ, обладающей правами локального администратора на удаленном устройстве, данных ограничений не будет, однако, как мы уже говорили в начале статьи, использование прав локального админа на удаленных ПК может представлять собой угрозу ИБ. Поэтому в данном пункте обсудим, как можно предоставить гранулированные права доступа сканирующей УЗ для получения дополнительной инвентаризационной информации с удаленного устройства. 

4.1. Предоставление полномочий на просмотр установленных обновлений ОС

Выполнив приведенные ранее настройки, мы по умолчанию не сможем получить список установленных на удаленном устройстве обновлений ОС, т.е. WMI-запросы класса win32_QuickFixEngineering не будут возвращать результат. Это связано с тем, что у сканирующей УЗ нет удаленного WMI/DCOM-доступа к сервису «TrustedInstaller», который предоставляет данные об установленных обновлениях. Для того, чтобы предоставить такой доступ, можно воспользоваться рекомендациями и открыть настройки управления DCOM (dcomcnfg), в ветке «Службы компонентов» открыть «Мой компьютер», далее открыть вкладку «Настройка DCOM» , открыть свойства приложения «Trusted Installer Service» и на вкладке «Безопасность» просмотреть настройки пункта «Разрешения на запуск и активацию» (права «Удаленная активация» и «Удаленный запуск» должны быть предоставлены для сканирующей УЗ) и пункта «Разрешения на доступ» (право «Удаленный доступ» должно быть предоставлено для сканирующей УЗ). Если доступ к изменению настроек безопасности отсутствует, то следует по «Коду приложения» (Application ID) приложения «Trusted Installer Service», который указан на вкладке «Общие», найти ветку реестра HKLM\SOFTWARE\Classes\AppID\{идентификатор приложения} и в ней сделать владельцем сканирующую УЗ и дать ей разрешение на изменение данного ключа. После этого следует вернуть в оснастку dcomcnfg и проверить, что появился доступ к изменению настроек безопасности приложения «Trusted Installer Service». Далее следует открыть настройки пункта «Разрешения на запуск и активацию» (предоставить для сканирующей УЗ права «Удаленная активация» и «Удаленный запуск») и пункта «Разрешения на доступ» (предоставить для сканирующей УЗ право «Удаленный доступ»). После этого следует вернуться в редактор реестра и вернуть в исходное состояние разрешения и владельца ветки реестра HKLM\SOFTWARE\Classes\AppID\{идентификатор приложения}. Для централизованного распространения указанных изменений доступа к приложению «Trusted Installer Service» можно сделать экспорт значений параметров AccessPermission и LaunchPermission из ветки реестра HKLM\SOFTWARE\Classes\AppID\{идентификатор приложения} с настроенной системы, а затем через соответствующую групповую политику распространить данные значения на все сканируемые устройства. После применения данных настроек потребуется сделать рестарт службы «Установщик модулей Windows» (Windows Modules Installer, TrustedInstaller). Таким образом, от удаленных систем в целях инвентаризации можно будет запрашивать список установленных обновлений ОС с помощью WMI-запросов вида:

wmic /node:»pcname.domain.local» qfe list full /format:table

или

gwmi -ComputerName pcname.domain.local -Class win32_QuickFixEngineering | fl *

или

Get-CimInstance -ComputerName pcname.domain.local -Class win32_QuickFixEngineering | fl *

4.2. Предоставление удаленного доступа на просмотр состояния служб Windows 

По умолчанию, удаленный просмотр списка запущенных на удаленном устройстве служб доступен только членам группы локальных администраторов, и это ограничение устанавливается системным диспетчером управления службами SCM (Service Control Manager), который отвечает в том числе за предоставление информации о состоянии запущенных на устройстве служб Windows. Для предоставления доступа сканирующей УЗ следует выполнить несколько описанных ниже действий.

Сначала требуется узнать SID сканирующей УЗ, например, командой

wmic useraccount where (name=»Scan» and domain=»domain.local») get sid

Далее потребуется узнать текущие разрешения SCM, выполнив на тестовом сканируемом ПК команду из-под админа:

sc sdshow scmanager

Результатом выполнения команды будет строка в SDDL-синтаксисе, которая описывает права доступа к SCM для различных пользователей и групп, например, такая:

D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)(A;;CC;;;AC)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)

Далее потребуется в текстовом редакторе создать строку вида:

(A;;CCLCRPRC;;;[SID]) , где вместо [SID] надо будет указать полученный на предыдущем шаге SID сканирующей УЗ.

Данной строкой мы разрешаем («A;;») доступ сканирующей УЗ и устанавливаем следующие права доступа на SCM: CC — получить конфигурацию сервиса, LC — получить статус сервиса, RP — прочесть свойства сервиса, RC — прочесть дескриптор безопасности сервиса.

Далее в текстовом редакторе надо будет создать новую SDDL-строку, которая включит созданное выражение, добавив его в блоке DACL («D:») перед блоком SACL («S:»):

D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)(A;;CC;;;AC)(A;;CCLCRPRC;;;[SID])S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)

Далее даем команду для применения созданных прав доступа, выполнив из-под админа:

sc sdset scmanager D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)(A;;CC;;;AC)(A;;CCLCRPRC;;;[SID])S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)

Указанные права доступа сохранятся в реестре в ветке HKLM\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder в параметре «Security» , откуда их можно будет централизованно применить ко всем устройствам в домене. Удаление из реестра параметра «Security» вернет настройки безопасности SCM в состояние по умолчанию. При этом необходимо помнить, что у каждой службы есть свои собственные права доступа (посмотреть которые можно командой sc sdshow имя_сервиса), поэтому при удаленном опросе служб их список может быть неполным.

Удаленно просмотреть список и состояние служб можно командами:

wmic /node:»pcname.domain.local» path Win32_Service get /format:list

или

gwmi -ComputerName pcname.domain.local -Class Win32_Service | fl *

или

Get-CimInstance -ComputerName pcname.domain.local -ClassName Win32_Service | fl *

5. Удаленные оболочки с минимальными правами доступа

У администраторов может возникнуть потребность в получении оперативной информации о состоянии ИТ-актива, например, списка запущенных процессов или активных сетевых соединений. Для решения таких задач на ОС, начиная с Windows 7/2008, можно применять утилиты удаленного управления PowerShell Remoting и Windows Remote Shell. Оба варианта используют механизм WinRM (протокол WSMan) и оба предоставляют возможность работы с удаленными устройствами в интерактивном режиме. Обе настройки требуют сетевой доступности сканируемого устройства по TCP:5985, наличие запущенной «Службы удаленного управления Windows» (Windows Remote Management (WS-Management), WinRM) и разрешение на удаленное управление через PSRemoting/WinRM, настроенное командами либо Enable-PSRemoting (для PowerShell Remoting), либо winrm qc (для Windows Remote Shell), либо через политику «Разрешить удаленное администрирование сервера средствами WinRM».

5.1. PowerShell Remoting

Для настройки оболочки PowerShell Remoting можно включить сканирующую УЗ в группу «Пользователи удаленного управления» (Remote Management Users). Однако, есть и другой способ: на удаленном устройстве надо будет выполнить

Set-PSSessionConfiguration -Name Microsoft.PowerShell -showSecurityDescriptorUI

В открывшемся окне для сканирующей УЗ следует предоставить права «Чтение» / Read (Get,Enumerate,Subscribe) и «Выполнение» / Execute (Invoke).

Данные настройки хранятся в ветке реестра HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Plugin\Microsoft.PowerShell в параметре ConfigXML, который содержит строковое значение в формате XML, включая настроенные права доступа в SDDL-синтаксисе. Следует иметь ввиду, что значение параметра ConfigXML также содержит свойство Architecture, указывающее на разрядность целевой ОС.

После этого для запуска оболочки PowerShell Remoting можно выполнить

Enter-PSSession -ComputerName pcname.domain.local

и далее выполнять команды PowerShell и cmd на удаленном устройстве.

Кроме того, можно выполнять команды вида

Invoke-Command -ComputerName pcname.domain.local -ScriptBlock {Get-Culture}

Invoke-Command -ComputerName pcname.domain.local -ScriptBlock {ipconfig}

Для мониторинга выполненных команд на удаленном устройстве потребуется включить политики «Аудит создания процессов» и «Включать командную строку в события создания процессов», и в журнале «Безопасность» (Security) на удаленном устройстве будут создаваться события EventID=4688 и с именем процесса-создателя «C:\Windows\System32\wsmprovhost.exe«. При этом логироваться будет выполнение только команд синтаксиса Windows cmd, а вот с логированием выполненных PowerShell-команд, видимо, есть некоторая сложность. Мы нашли только одну подходящую политику «Конфигурация компьютера \ Административные шаблоны \ Компоненты Windows \ Windows PowerShell — Включить транскрипции PowerShell», в которой нужно отметить check-box «Включить заголовки вызовов», а также потребуется указать каталог для хранения журналов выполненных удаленно PowerShell команд, при этом журналы будут создаваться в этой папке в виде текстовых файлов. Настройки политик «Конфигурация компьютера — Конфигурация Windows — Административные шаблоны — Компоненты Windows \ Windows PowerShell — Включить ведение журнала модулей» и «Включить регистрацию блоков сценариев PowerShell» не помогли вести аудит выполненных удаленно команд в журнале Microsoft-Windows-PowerShell/Operational, в журнале Microsoft-Windows-WinRM/Operational также не оказалось полезной информации.

Если вы знаете более удобный способ аудита команд, выполненных удаленно через Enter-PSSession и Invoke-Command — пишите в комментариях!

5.2. Windows Remote Shell 

Для настройки оболочки Windows Remote Shell на удаленном устройстве надо будет выполнить

winrm configSDDL default

В открывшемся окне для сканирующей УЗ следует предоставить права «Чтение» / Read (Get,Enumerate,Subscribe) и «Выполнение» / Execute (Invoke).

Данные настройки хранятся в ветке реестра KLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Service в строковом параметре rootSDDL, который содержит настроенные права доступа в SDDL-синтаксисе.

Также на сканируемом устройстве потребуется включить доступ к WinRS либо через политику «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Удаленная оболочка Windows / Разрешить доступ к удаленной оболочке — Разрешить» (Computer Configuration / Administrative Templates / Windows Components / Windows Remote Shell / Allow Remote Shell Access — Enabled), либо командой winrm set winrm/config/winrs @{AllowRemoteShellAccess=»true»}.

После этого для запуска оболочки Windows Remote Shell можно выполнить

winrs -r:pcname.domain.local cmd

и далее выполнять команды Windows cmd на удаленном устройстве.

Кроме того, можно выполнять команды вида

winrs -r:pcname.domain.local netstat -nao

winrs -r:pcname.domain.local tasklist

winrs -r:pcname.domain.local powershell  -command «get-culture»

Для мониторинга выполненных команд на удаленном устройстве потребуется включить политики «Аудит создания процессов» и «Включать командную строку в события создания процессов», и в журнале «Безопасность» (Security) на удаленном устройстве будут создаваться события EventID=4688 и с именем процесса-создателя «C:\Windows\System32\winrshost.exe«.

Заключение

В данной статье мы продемонстрировали некоторые возможности по проведению ИТ-инвентаризации штатными средствами ОС Windows, используя минимальные привилегии в удаленной системе. Настройка таких гранулированных полномочий может быть небыстрой, однако эти затраты окупятся более высоким уровнем защищенности конечных систем. Кроме того, получение и обработку данных ИТ-инвентаризации логично будет автоматизировать, также как и весь процесс управления ИТ-активами. Для автоматизации процесса можно воспользоваться, к примеру, инструментарием PowerShell, а можно использовать коммерческие продукты. Например, модуль «Управление активами» нашего продукта Security Vision работает в безагентном режиме с использованием конструктора коннекторов и встроенного модуля сканирования, сочетающего неаутентифицированный и аутентифицированный сбор информации об активах, и позволяет не только получить инвентаризационную информацию, но и выполнить некоторые операции администрирования на устройствах, построить и проанализировать графы связей активов, визуализировать полученную информацию на географической карте и дашбордах, а также предоставить агрегированную информацию в наглядном табличном виде с учетом ролевой модели доступа пользователей к данным активов. Механизм инвентаризации и удаленного администрирования Security Vision поддерживает функции безопасности удалённого выполнения команд акутальных версий ОС MS Windows. Это позволяет обезопасить инфраструктуру от массового заражения даже при компрометации сканирующей учетной записи. Для сервисов инвентаризации доступно разделение по многоуровневой модели домена (Рабочие станции – Сервера – Контроллеры домена), а ротацию паролей теперь можно передать механизму gMSA (Group Managed Service Account).