Windows список com объектов — Ваш верный помощник с OS Windows

Подпишись на телеграм канал Data Engineering Инжиниринг данных

30.03.2018 от Qlik Expert Russia

Получить список COM объектов из PowerShell Windows

Для 1С Предприятие 8.3 в Windows 10 есть следующие объекты:

V83.Application
V83C.Application

Получение перечня всех ComObject в Windows (Команда PowerShell)

Открыть Windows PowerShell ISE
Запустить код:

1	gci HKLM:\Software\Classes —ea 0\| ? {$_.PSChildName —match ‘^\w+\.\w+$’ —and (gp «$($_.PSPath)\CLSID» —ea 0)} \| ft PSChildName

0
0
голос

Рейтинг статьи

PowerShell и QlikView 12. Книги по PowerShell. Примеры и практика.
Обзор модуля Аналитика – Управление нашей фирмой 1С Предприятие 8.3
Программирование в 1С:Предприятие 8.3 Внешняя обработка Программный модуль
Концепция системы 1С:Предприятие 7.7. Метаданные, Основные понятия

Уведомить о

1 Комментарий

Старые

Новые
Популярные

Межтекстовые Отзывы

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

Ness

5 лет назад

Спасибо. Помогло.

Ответить

Источник

Let’s see what WMI can tell us about COM objects on the system.

Get a list of all WMI classes with the word “COM” in them (doing a case sensitive match to avoid entries like “computer”).

PS> gwmi -list | ?{ $_.Name -cmatch «COM» }

NameSpace: ROOT\cimv2

Name Methods Properties

—— ———— —————

MSFT_WMI_GenericNonCOMEvent {} {ProcessId, PropertyNames, PropertyValues, ProviderName...}

Win32_COMApplication {} {Caption, Description, InstallDate, Name...}

Win32_DCOMApplication {} {AppID, Caption, Description, InstallDate...}

Win32_COMClass {} {Caption, Description, InstallDate, Name...}

Win32_ClassicCOMClass {} {Caption, ComponentId, Description, InstallDate...}

Win32_COMSetting {} {Caption, Description, SettingID}

Win32_ClassicCOMClassSetting {} {AppID, AutoConvertToClsid, AutoTreatAsClsid, Caption...}

Win32_DCOMApplicationSetting {GetLaunchSecurit... {AppID, AuthenticationLevel, Caption, CustomSurrogate...}

Win32_ClassicCOMClassSettings {} {Element, Setting}

Win32_COMApplicationSettings {} {Element, Setting}

Win32_DCOMApplicationAccessAllow... {} {Element, Setting}

Win32_COMApplicationClasses {} {GroupComponent, PartComponent}

Win32_ClassicCOMApplicationClasses {} {GroupComponent, PartComponent}

Win32_DCOMApplicationLaunchAllow... {} {Element, Setting}

Win32_COMApplication gives me about 386 results. It includes the AppID of the application associated with the COM object.

I am not a programmer so I won’t be going further into AppIDs and such, but it’s worth knowing about this and related COM terminology so here’s a quick rundown:

All COM objects have a CLSID which is basically a 128-bit hexadecimal Globally Unique IDentifier (GUID) for the COM object. This way COM objects can be referred to independent of their installation path. The CLSID is unique across network computers too (relevant, when used with DCOM).
WMI objects refer to this as ComponentID. They can also be found in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID. For example, the CLSID for WordPad is {73FDDC80-AEA9-101A-98A7-00AA00374959}

CLSIDs are not easy to remember, and sometimes COM objects with different CLSIDs can be used interchangeably (for instance: different versions of Internet Explorer will have different CLSIDs but you need some way of referring to the Internet Explorer COM object such that whatever version is installed on the system is used). For this reason you have ProgIDs (Programmatic IDentifier).

ProgIDs can be found in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Classes. The format of a ProgID is <Program>.<Component>.<Version>, separated by periods and with no spaces. For example, the ProgID for WordPad is WordPad.Document.1.

PowerShell’s New-Object cmdlet uses ProgID when creating new objects that refer to COM objects so ProgIDs are relevant to us.

PS> help New-Object -Parameter ComObject

-ComObject <String>

Specifies the programmatic identifier (ProgID) of the COM object.

Required? true

Position? 1

Default value None

Accept pipeline input? false

Accept wildcard characters? false

While not relevant to the current topic, there’s also an AppID which is yet another 128-bit hexadecimal GUID. You can read more about it here.

Now let’s get a list of how many objects are returned by each WMI class.

PS> gwmi -list | ?{ $_.Name -cmatch «COM» } | ft Name,@{Name=«Number of objects»;Expr={(gwmi $_.Name | Measure-Object -Line).Lines}} -AutoSize

Name Number of objects

—— —————————

MSFT_WMI_GenericNonCOMEvent 0

Win32_COMApplication 397

Win32_DCOMApplication 397

Win32_COMClass 5721

Win32_ClassicCOMClass 5721

Win32_COMSetting 6118

Win32_ClassicCOMClassSetting 5721

Win32_DCOMApplicationSetting 397

Win32_ClassicCOMClassSettings 5721

Win32_COMApplicationSettings 397

Win32_DCOMApplicationAccessAllowedSetting 526

Win32_COMApplicationClasses 579

Win32_ClassicCOMApplicationClasses 579

Win32_DCOMApplicationLaunchAllowedSetting 491

The biggest results are from the Win32_COMSetting class. Let’s compare the results of this with the Win32_ClassicCOMClassSetting class (which has the second largest number of results) to see what’s different. Since the ProgID property is what’s relevant to PowerShell, let’s filter the results to objects where ProgID is not $null.

# store the results from each class in a variable; filter out ones where ProgID is $null

PS> $COMClassicSet = gwmi Win32_ClassicCOMClassSetting | ?{ $_.ProgId -ne $null } | Sort-Object

PS> $COMSet = gwmi Win32_COMSetting | ?{ $_.ProgId -ne $null } | Sort-Object

PS> Compare-Object $COMSet $COMClassicSet

PS>

There’s no difference. So in terms of ProgID both classes contain the same number of objects. Now let’s recreate the above table to only consider results where ProgID is not $null.

PS> gwmi -list | ?{ $_.Name -cmatch «COM» } | ft Name,@{Name=«Number of objects»;Expr={(gwmi $_.Name | ?{ $_.ProgID -ne $null } | Measure-Object -Line).Lines}} -AutoSize

Name Number of objects

—— —————————

MSFT_WMI_GenericNonCOMEvent 0

Win32_COMApplication 0

Win32_DCOMApplication 0

Win32_COMClass 0

Win32_ClassicCOMClass 0

Win32_COMSetting 1613

Win32_ClassicCOMClassSetting 1613

Win32_DCOMApplicationSetting 0

Win32_ClassicCOMClassSettings 0

Win32_COMApplicationSettings 0

Win32_DCOMApplicationAccessAllowedSetting 0

Win32_COMApplicationClasses 0

Win32_ClassicCOMApplicationClasses 0

Win32_DCOMApplicationLaunchAllowedSetting 0

The interesting thing to note is that all the other classes have 0 objects now. In fact, we can see that the number of objects returned by the Win32_COMSetting class is equal to the number returned by Win32_ClassicCOMClassSetting plus Win32_COMApplication or Win32_DCOMApplication or Win32_DCOMApplicationSetting or Win32_COMApplicationSettings. Something to investigate later?

PS C:\Users\rakhesh\Code> gwmi -list | ?{ $_.Name -cmatch «COM» } | ft Name,@{Name=«Number of objects»;Expr={(gwmi $_.Name | Measure-Object -Line).Lines}} -AutoSize

Name Number of objects

—— —————————

MSFT_WMI_GenericNonCOMEvent 0

Win32_COMApplication 397

Win32_DCOMApplication 397

Win32_COMClass 5721

Win32_ClassicCOMClass 5721

Win32_COMSetting 6118

Win32_ClassicCOMClassSetting 5721

Win32_DCOMApplicationSetting 397

Win32_ClassicCOMClassSettings 5721

Win32_COMApplicationSettings 397

Win32_DCOMApplicationAccessAllowedSetting 526

Win32_COMApplicationClasses 579

Win32_ClassicCOMApplicationClasses 579

Win32_DCOMApplicationLaunchAllowedSetting 491

So, the best way to get COM objects via WMI & PowerShell is to use the Win32_COMSetting class. And to get the ProgID or any application (such as Internet Explorer in the previous post) something along the following lines will do:

PS> gwmi Win32_COMSetting | ?{ $_.ProgId -match «Internet» } | ft ProgId,Caption

ProgId Caption

——— ————

InternetExplorer.Application.1 Internet Explorer(Ver 1.0)

Internet.HHCtrl.1 HHCtrl Object

InternetShortcut Internet Shortcut

If there’s only one version, the version number can be skipped in ProgID which is why InternetExplorer.Application too works.

Update: In fact, only the Win32_COMSetting and Win32_ClassicCOMClassSetting classes contain ProgID in their output. So these are the only two classes one can use. And since the only difference them is that Win32_COMSetting contains objects without any ProgID (of no use in our case!) it’s ok to use either class.

PS> gwmi -list | ?{ $_.Name -cmatch «^Win32.*COM» } | ?{ @(gwmi $_.Name | gm -MemberType Property | select -Unique -Expand Name).Contains(«ProgId») }

NameSpace: ROOT\cimv2

Name Methods Properties

—— ———— —————

Win32_COMSetting {} {Caption, Description, SettingID}

Win32_ClassicCOMClassSetting {} {AppID, AutoConvertToClsid, AutoTreatAsClsid, Caption...}

Update2: Turns out WMI is not a good way to get the list of COM objects. A better approach is to query the registry. See my next post.

Источник

Уровень сложностиСредний

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

Количество просмотров12K

Привет, Хабр!

Изучая отчеты по разбору вредоносного ПО, приходишь к выводу, что в последнее время одним из популярных методов для закрепления в системе является COM Hijacking (T1546.015), применяемый атакующими для закрепления зловредов в ОС Windows через Component Object Model. Яркий тому пример — использование COM Hijacking группировкой Fancy Bear, а также вредоносными программами,такими как Jumplump и одной из недавних — RomCom.

При этом, если рассмотреть подробнее использование RomCom, можно увидеть, что он перезаписывает COM-объект с GUID {C90250F3-4D7D-4991-9B69-A5C5BC1C2AE6}с соответствующим файломActXPrxy.dll, предназначенным для управления компонентами «ActiveX» Windows, на prxyms.dll. В то же время одним из процессов, который использует данный COM-объект, является explorer.exe. Это означает, что закрепление в системе гарантированно, поскольку без данного процесса не обходится работа на устройстве с операционной системой Windows.

Таким образом, умение детектировать данный вид атаки является важным аспектом для Blue Team. Поэтому я решила подготовить серию статей, посвященных технологии Component Object Model (COM), а также разбору атаки COM Hijacking и ее детектированию.

Сегодня я начну с основ и расскажу вам о том, что представляет собой Component Object Model. Сразу отмечу, что данная тема очень обширная, и разобрать ее подробно в одном материале не получится. В этой статье мною будут рассмотренны базовые понятия COM, которые в будущем помогут нам лучше понимать принцип работ атаки COM Hijacking. После чего я проанализирую, какие стратегии может ипользовать злоумышленник для выбора подходящего COM-объекта с целью последующей атаки.

Немного определений

COM (Component Object Model) — это стандарт, позволяющий разработчикам повторно использовать в своем коде независимые компоненты ПО. При этом им не нужно знать внутреннее устройство данных компонентов, заниматься их совместимостью на разных языках программирования и повторной компиляцией.

Также в начале статьи я уже упомянула такое понятие, как COM-объект. За ним кроется определение объекта, в котором указаны данные о нем и о наборе интерфейсов для обеспечения его функциональности. COM-объект реализуется в форматах DLL или EXE.

На основе стандарта COM выполняется очень много процессов в Windows, поэтому отключить его с целью защитится от атакующих не получится. Соответственно, атаки с помощью COM-объектов становятся лакомым кусочком для злоумышленников.

Программное обеспечение для поиска необходимого COM-объекта использует реестр, поэтому далее мы рассмотрим, какие ключи задействованы в данном процессе и можно ли их применять для проведения атаки (Спойлер: ДА!).

Представление COM-объектов в реестре

Реестр содержит информацию обо всех установленных в системе COM-объектах, которая находится в следующих ветках:

HKEY_LOCAL_MACHINE\Software\Classes (HKLM) — информация, применимая на локальном компьютере при любом активном пользователе;
HKEY_CURRENT_USER\Software\Classes (HKCU) — информация, применимая к текущему интерактивному пользователю;
HKEY_CLASSES_ROOT (HKCR) — виртуальный куст, объединяющий сведения из двух выше указанных веток. Объединение происходит по определенному правилу: включаются все разделы и ключи из HKCU\Software\Classes, а из HKLM\Software\Classes включаются разделы и ключи, отсутствующие HKCU\Software\Classes.

Так как архитектура 64-битной операционной системы поддерживает совместимость с x86 приложениями, существуют дополнительные ветки в реестре, представленные под спойлером:

COM-объекты в x64 архитектуре ОС для x86 приложений

Для поддержания 32-разрядных приложений в 64-разрядный операционных системах Windows используются аналогичная структура ключей, но вложены они в Wow6432Node. Например:

HKEY_CURRENT_USER\SOFTWARE\WOW6432Node\Classes;
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Classes;
HKEY_CLASSES_ROOT\WOW6432Node.

Во всех выше перечисленных ветках есть подраздел CLSID, содержащий идентификаторы (GUID) класса. А дальше, в зависимости исходных данных атакующего, используются следующие подразделы:

InprocServer/InprocServer32 — путь к dll-библиотеке, который будет подгружаться в процесс, вызванный COM-объектом;
LocalServer/LocalServer32 — путь к исполняемому файлу (.exe). В данном случае COM-объект запускается в новом процессе;
TreatAs — перенаправляет на другой COM-объект, путем указания CLSID;
ProgID — текстовый идентификатор, который используется аналогично CLSID. ProgID всегда сопоставляется CLSID, и на последующих шагах используется именно он;
VersionIndependentProgID — аналогичен ProgID, но имеет некоторые исключения. ProgID может содержать в себе версию COM-объекта и обслуживается непосредственно кодом приложения, в то время как VersionIndependentProgID указывает единый независимый от версии идентификатор. И в ответ уже сопоставляется с CLSID последней версии объекта.

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

Порядок проверки ключей в реестре

Согласно документации Microsoft, параметры, указанные для интерактивного пользователя в HKCU\Software\Classes, имеют приоритет над HKCR (HKLM). Если процесс запускается в интерактивном сеансе с правами администратор (т.е. уровень целостности выше среднего), и при этом UAC отключен, то применяется конфигурация, указанная в HKLM. Подробнее про UAC и методы его обхода можно почитать в статье моего коллеги. Процессы, которые не выполняются в контексте безопасности интерактивного пользователя, не используют HKCU и HKCR, а напрямую обращаются к HKEY_LOCAL_MACHINE\Software\Classes.

Итак, с приоритетом веток мы разобрались. Выбор между ProgID и CLSID тоже понятен — он зависит от обращение к COM-объекту: идет ли оно через GUID или используется текстовый идентификатор. А вот приоритет внутри CLSID между параметрами InprocServer, LocalServer и TreatAs пока не известен. Поэтому давайте проверим его на практике и для этого проведем небольшой эксперимент.

Выбор приоритета внутри CLSID

Как правило, сразу три параметра не указываются, но нам ничего не мешает сделать это. Для этого я создала два dll-файла (для ключей InprocServerи TreatAs) и exe (для ключа LocalServer) с разными MessageBox. Под спойлером представлен конфигурационный файл реестра для проведения эксперимента. В нем указаны сразу все три ключа, а также применение созданных мною соответствующих исполняемых файлов.

Конфигурация реестра

Для проведения эксперимента на устройстве применена следующая конфигурация реестра:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{00000001-0000-0000-0000-0000FEEDACDC}]
@="ComHijacking"

[HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{00000001-0000-0000-0000-0000FEEDACDC}\InprocServer32]
@="C:\\hijacking_dll_treatas.dll"
"ThreadingModel"="Apartment"

[HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{72C34DD5-D70A-438B-8A42-98424B88AFB8}]

[HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{72C34DD5-D70A-438B-8A42-98424B88AFB8}\TreatAs]
@="{00000001-0000-0000-0000-0000FEEDACDC}"

[HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{72C34DD5-D70A-438B-8A42-98424B88AFB8}\InprocServer32]
@="C:\\hijacking_dll_inprocserver.dll"
"ThreadingModel"="Apartment"

[HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{72C34DD5-D70A-438B-8A42-98424B88AFB8}\LocalServer32]
@="C:\\hijacking_exe_localserver.exe"

[HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{72C34DD5-D70A-438B-8A42-98424B88AFB8}\ProgID]
@="Hijack.COM"

[HKEY_CURRENT_USER\SOFTWARE\Classes\Hijack.COM]
@=""

[HKEY_CURRENT_USER\SOFTWARE\Classes\Hijack.COM\CLSID]
@="{72C34DD5-D70A-438B-8A42-98424B88AFB8}"

Далее производится вызов COM-объекта по ProgID «Hijack.COM». На рисунке 1 видно, что заданных всех выше перечисленных параметров наивысший приоритет имеет TreatAs. В свою очередь, Process Monitor показывает, что было обращение только к ключу TreatAs, остальные ключи не проверялись (рисунок 2).

Рисунок 1 — Сработал триггер, указанный в TreatAs

Рисунок 2 — Process Monitor показывает обращение к TreatAs

Ниже на рисунке 3 мы видим, что если из всех заданных ключей убрать TreatAs, а оставить LocalServer32 и InprocServer32, то в текущей ситуации приоритет будет иметь InprocServer32. При этом Process Monitor показывает, что сначала был запрос к TreatAs, но так как он не задан, запрос оказался безуспешным (рисунок 4). На следующем этапе было получено значение из InprocServer32, а потом из LocalServer32, но приоритет был отдан InprocServer32.

Рисунок 3 — Сработал триггер, указанный в InprocServer32

Рисунок 4 — Process Monitor показывает порядок обращений к ключам реестра

Логично, что убрав все ключи, кроме LocalServer32обращение будет произведено именно к нему (LocalServer32)(рисунок 5) . В то же время, Process Monitor показывает, что сохраняется последовательность обращений к реестру, но к TreatAs и InprocServer32 они безуспешны.

Рисунок 5 — Сработал триггер, указанный в LocalServer32

Рисунок 6 — Process Monitor показывает порядок обращений к ключам реестра

Подводя итог нашего эксперимента, сделаем вывод, что приоритет ключей в реестре определяется в следующем порядке: TreatAs > InprocServer32 > LocalServer32.

Интересно то, что приоритет этих ключей выше приоритета рассмотренных ранее веток. Это значит, что, например, наличие ключа InprocServer32 в HKCR приоритетнее, чем ключ LocalServer32 в HKCU. То есть более привилегированный ключ в менее привилегированной ветке будет иметь приоритет над менее привилегированным ключом в более привилегированной ветке реестра. Ниже показано это выглядит в схематичном виде:

Рисунок 7 — Приоритет ключей в реестре

Таким образом, определив приоритет выбора ключа, по которому будет исполняться COM-объект, мы поймем, что атакующий может этим воспользоваться и переопределить COM-объект, указав в более приоритетном ключе значение, ссылающееся на вредоносный объект.

Но то, какими правами нужно обладать для изменения этих ключей, разберем далее.

Права доступа на редактирование реестра

Как видно из рисунка 8, ветка HKCU может изменяться интерактивным пользователем без прав администратора.

$Рисунок 8 - Права на HKEY_CURRENT_USER\Software\Classes$

Рисунок 8 — Права на HKEY_CURRENT_USER\Software\Classes

А дальше мы видим, что HKLM и HKCR требует прав локального администратора или SYSTEM для изменения (рисунки 9 и 10) . Согласно документации Microsoft, если вносить изменения в HKCR, то они буду прописываться в HKEY_LOCAL_MACHINE\Software\Classes.

$Рисунок 9 - Права на HKEY_LOCAL_MACHINE\Software\Classes$

Рисунок 9 — Права на HKEY_LOCAL_MACHINE\Software\Classes

Рисунок 10 — Права на HKEY_CLASSES_ROOT

В Windows существует большое количество COM-объектов, а при установке дополнительного прикладного ПО, это количество только растет.

Тогда как же злоумышленнику определиться, какой COM-объект лучше всего атаковать? Для этого мы посмотрим, каким критериям должен соответствовать выбранный COM-объект, а затем разберем стратегии, которыми может пользоваться атакующий при выборе COM-объекта для атаки.

Выбор COM-объекта для атаки

Безусловно, можно создать новый COM-объект и дальше попытаться его вызвать, но чтобы сделать этого без «лишнего шума» лучше воспользоваться существующими ключами, которые могут быть уже настроены на вызов по какому-либо триггеру. Выбранный COM-объект должен соответствовать двум критериям: первый их них — часто запускаться, а второй — не ломать логику работы приложений.

Для выбора подходящего COM-объекта существует несколько стратегий, давайте их рассмотрим поподробнее.

Часто используемые COM-объекты

Первая стратегия будет основываться на использовании такого инструмента, как Process Monitor. Суть метода заключается в том, чтобы собрать события запросов к реестру с ключами InprocServer32, LocalServer32, TreatAs, ScriptletURL, ProgID или любой ключ в разделе \Classes\ (рисунок 11), а далее оценить какие COM-объекты наиболее часто используются (рисунок 12). При этом для удобства можно выгрузить в CSV файл, а далее в EXEL посчитать статистику.
На основании полученной оценки производится выбор наиболее подходящего COM-объекта для атаки COM-hijacking. О том, как используется выбранный объект дальше, я расскажу в последующих статьях.

Рисунок 11 — Пример фильтров в Process Monitor для сбора статистика по часто используемым COM-объектам

Рисунок 12 — Результат вывода Process Monitor с заданными фильтрами

Так с помощью данного метода можно обнаружить следующие COM-объекты:

Легитимное ПО	GUID COM-объекта	Легитимное значение по умолчанию	Вредоносное ПО
wmiprvse.exe	{CF4CC405-E2C5-4DDD-B3CE-5E7582D8C9FA}	`%systemroot%\system32\wbem\wmiutils.dll`	Candiru
firefox.exe	{1f486a52-3cb1-48fd-8f50-b8dc300d9f9d}	`%SystemRoot%\system32\propsys.dll`	Jumplump
explorer.exe	{42aedc87-2188-41fd-b9a3-0c966feabec1}	`%SystemRoot%\system32\windows.storage.dll`	Дроппер rtlstat.dll APT Space Pirates

Отсутствующие в HKCU COM-объекты

Вторая стратегия также основывается на использовании Process Monitor, но в данном случае выбираются не самые популярные, а отсутствующие в HKCU COM-объекты (рисунок 13). В HKCU проверка проходит раньше, чем в HKCR. Исключение составляют процессы с высоким уровнем целостности. Это сделано для того, чтобы предотвратить повышение привилегий.

Рисунок 13 — Пример фильтров в Process Monitor для получения COM-объектов, отсутствующих в HKCU

Полученный результат можно сохранить в CSV формате, а далее отфильтровать уникальные значения в EXEL. Или воспользоваться автоматизацией, «скормив» данный CSV-файл acCOMplice. Этот набор скриптов предназначен для изучения атаки COM-hijacking: с его помощью можно определить подходящий COM-объект для использования в атаке, а затем провести на выбранный объект атаку COM-hijacking. Так, например, функция Extract-HijackableKeysFromProcmonCSV выводит уникальные COM-объекты из CSV-файла (рисунок 14).

Рисунок 14 — Результат работы скрипта по поиску уникальных COM-объектов в csv файле

Использование обнаруженных COM-объектов вредоносным ПО представлено в таблице:

Легитимное ПО	GUID COM-объекта	Легитимное значение по умолчанию	Вредоносное ПО
explorer.exe	{00020424-0000-0000-c000-000000000046}	`C:\Windows\System32\oleaut32.dll`	Saburex.A

Фантомные COM-объекты

Третья стратегия базируется на выявлении COM-объектов, ссылающихся на несуществующие dll или exe файлы. Пример получения списка COM-объектов с отсутствующими исполняемыми файлами показан на рисунке ниже. Таким образом можно будет положить файл по требуемому пути с нужным именем и не изменять реестр. Подобные COM-объекты называются Phantom COM.

Рисунок 15 — Пример фильтра для получения списка COM-объектов, у которых отсутствует на диске исполняемый файл

Такого же результата возможно добиться и с помощью утилиты acCOMplice, что наглядно отображено на рисунке 16. В функции Find-MissingLibraries осуществляется получение значений ключей реестра inprocserver и localserver в ветке HKCR\CLSID. Далее происходит проверка, на предмет существования на диске файла, полученного на предыдущем этапе из реестра. Дополнительно можно проверить права пользователя на данный файл. Если он не найден, то данный COM-объект является потенциальным для использования в атаке.

Рисунок 16 — Получение списка COM-объектов, у которых отсутствует исполняемый файл на диске, с помощью acCOMplice

Если в представленной выше утилите для получения списка COM-объектов использовались запросы к реестру, то аналогичную информацию можно узнать с помощью wmi, выполнив командуgwmi Win32_COMSetting.

Использование обнаруженных COM-объектов вредоносным ПО представлено в таблице:

Легитимное ПО	GUID COM-объекта	Легитимное значение по умолчанию	Вредоносное ПО
microsoftedgeupdate.exe	<>	`%ProgramFiles(x86)%\microsoft\edgeupdate\1.3..\psmachine_64.dll`	Trojan.Siggen17.58258

COM-объекты в запланированных задачах

Четвертый способ строится на анализе запланированных задач (ScheduledTask). Данный метод был автоматизирован с помощью powershell скрипта Get-ScheduledTaskComHandler. Он осуществляет проверку всех ScheduledTask, где в качестве обработчика назначен Custom handler (т.е. использование COM). Для этого скрипт получает описание запланированных задач в xml формате, которые располагаются по пути: C:\Windows\System32\Tasks. Далее выбираются только те задачи, у которых в качестве Actions используется ComHandler. По полученному CLSID из xml осуществляется поиск dll в реестре по пути HKCR:\CLSID\{GUID}\InprocServer32. Дополнительно происходит проверка, в каком контексте выполняется задача (InteractiveUsers, AllUsers, AnyUser) и выполняется ли задача при логоне пользователя или нет.

Рисунок 17 — Пример строк в xml файле с описанием запланированной задачи, которая использует COM в качестве

Просто запуск скрипта без каких-либо параметров выводит все задачи, использующие COM (рисунок 18).

Рисунок 18 — Пример вывода скрипта Get-ScheduledTaskComHandler без параметров

Если использовать параметр -PersistenceLocations, то в результате мы получим список задач, которые можно использовать для закрепления в системе с помощью COM Hijacked, что видно на рисунке 19. В данном случае осуществляется дополнительная проверка того, что задача выполняется в пользовательском контексте и запускается при входе пользователя.

Рисунок 19 — Получение списка COM-объектов пригодных для закрепления в системе с помощью Get-ScheduledTaskComHandler скрипта

Данный способ покрывает сразу два этапа атаки: выбор COM-объекта и вызов вредоносного объекта при каждом входе пользователя. Атакующему остается только заменить COM-объект на вредоносный (об этом будет рассказано в последующих статьях).

Примеры COM-объектов, используемые атакующими

Также мною были проанализированы отчеты по ransomware и APT за последнее время. Опираясь на них, можно сделать вывод, что наиболее популярными COM-объектами у атакующих в данной атаке являются следующие объекты:

GUID COM-объекта	Легитимное значение по умолчанию
{BCDE0395-E52F-467C-8E3D-C4579291692E}	`%SystemRoot%\System32\MMDevApi.dll`
{00021401-0000-0000-C000-000000000046}	`C:\Windows\SysWOW64\windows.storage.dll`
{AB8902B4-09CA-4bb6-B78D-A8F59079A8D5}	`C:\Windows\SysWOW64\thumbcache.dll`
{CF4CC405-E2C5-4DDD-B3CE-5E7582D8C9FA}	`%systemroot%\system32\wbem\wmiutils.dll`
{7C857801-7381-11CF-884D-00AA004B2E24}	`%systemroot%\system32\wbem\wbemsvc.dll`
{ddc05a5a-351a-4e06-8eaf-54ec1bc2dcea}	`%SystemRoot%\System32\ApplicationFrame.dll`
{1f486a52-3cb1-48fd-8f50-b8dc300d9f9d}	`%SystemRoot%\system32\propsys.dll`
{4590f811-1d3a-11d0-891f-00aa004b2e24}	`%SystemRoot%\system32\wbem\wbemprox.dll`
{4de225bf-cf59-4cfc-85f7-68b90f185355}	`%SystemRoot%\system32\wbem\wmiprvsd.dll`
{F56F6FDD-AA9D-4618-A949-C1B91AF43B1A}	`%SystemRoot%\System32\Actioncenter.dll`

Такие COM-объекты по умолчанию присутствуют в Windows и часто вызываются легитимными процессами. Например, как можно заметить, часть из этих объектов относятся к WMI. Многие встроенные в Windows утилиты по типу tasklist.exe, systeminfo.exe и др., под капотом используют WMI и, следовательно, используют данные COM-объекты. Этот факт гарантирует атакующему, что после выполнения замены COM-объекта на вредоносный он будет вызываться в системе жертвы и при этом достаточно часто.

Заключение

В этой статье я рассмотрела базовые принципы устройства Component Object Model в Windows. Из всего выше сказанного особо важным является приоритет ключей InprocServer, LocalServer и TreatAs. Именно игра на приоритетах делает возможным проведение атаки COM-Hijacking. COM-объекты в ветке HKCU имеют больший приоритет, а также данная ветка дает права на запись для интерактивного пользователя, т.е. атакующему не требуется искать способы для повышения привилегий.

Кроме этого, мною были проанализированы четыре основных способа выбора COM-объекта, любым из которых можно воспользоваться. Уверена, данные способы не являются исчерпывающими. Но если цель атакующего — закрепление в системе, а атака COM-Hijacking относиться именно к закреплению, то важно учитывать, что выбранный COM-объект должен часто запускаться на устройстве жертвы и не ломать логику работы других процессов, использующих его.

Надеюсь данная статья оказалась для вас полезной! Если у вас появились вопросы, пишите в комментариях!

Update: А еще, у нас вышло продолжение материала. Тайная жизнь COM: погружение в методы Hijacking .

Автор: Кожушок Диана( @wildresearcher), аналитик-исследователь киберугроз в компании R-Vision

Источник

Note: This tip requires PowerShell 2.0 or above.

Recently a question was posted on the PowerShell.com forums: How to get a full list of available ComObjects? This tip will show how fetch all of them from the registry.

Here is the code that we can use to generate this list:

Get-ChildItem HKLM:\Software\Classes -ErrorAction SilentlyContinue | Where-Object {
	$_.PSChildName -match '^\w+\.\w+$' -and (Test-Path -Path "$($_.PSPath)\CLSID")
} | Select-Object -ExpandProperty PSChildName

The first Cmdlet reads out a complete list of values from HKLM:\Software\Classes and then verifies if the following two conditions are true:

Does the object match the naming convention for a ComObject?
Does the registry key have a CLSID folder? Every registered ComObject should have a CLSID as a unique identifier.

An example of the output generated by this command is as follows:

AccClientDocMgr.AccClientDocMgr
AccDictionary.AccDictionary
Access.ACCDAExtension
Access.ACCDCFile
Access.ACCDEFile
Access.ACCDTFile
Access.ACCFTFile
Access.ADEFile

To make the process of discovering ComObject easier the following function can be used.

function Get-ComObject {
    param(
        [Parameter(Mandatory=$true,
        ParameterSetName='FilterByName')]
        [string]$Filter,

        [Parameter(Mandatory=$true,
        ParameterSetName='ListAllComObjects')]
        [switch]$ListAll
    )

    $ListofObjects = Get-ChildItem HKLM:\Software\Classes -ErrorAction SilentlyContinue | Where-Object {
        $_.PSChildName -match '^\w+\.\w+$' -and (Test-Path -Path "$($_.PSPath)\CLSID")
    } | Select-Object -ExpandProperty PSChildName

    if ($Filter) {
        $ListofObjects | Where-Object {$_ -like $Filter}
    } else {
        $ListofObjects
    }
}

This function is available in the TechNet Script Gallery:

http://gallery.technet.microsoft.com/Get-ComObject-Function-to-50a92047

Share on:

Источник

Как использовать OAuth2 со Spring Security в Java

Javaican 14.05.2025

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

Анализ текста на Python с NLTK и Spacy

AI_Generated 14.05.2025

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

Реализация DI в PHP

Jason-Webb 13.05.2025

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

Обработка изображений в реальном времени на C# с OpenCV

stackOverflow 13.05.2025

Объединение библиотеки компьютерного зрения OpenCV с современным языком программирования C# создаёт симбиоз, который открывает доступ к впечатляющему набору возможностей. Ключевое преимущество этого. . .

POCO, ACE, Loki и другие продвинутые C++ библиотеки

NullReferenced 13.05.2025

В C++ разработки существует такое обилие библиотек, что порой кажется, будто ты заблудился в дремучем лесу. И среди этого многообразия POCO (Portable Components) – как маяк для тех, кто ищет. . .

Паттерны проектирования GoF на C#

UnmanagedCoder 13.05.2025

Вы наверняка сталкивались с ситуациями, когда код разрастается до неприличных размеров, а его поддержка становится настоящим испытанием. Именно в такие моменты на помощь приходят паттерны Gang of. . .

Создаем CLI приложение на Python с Prompt Toolkit

py-thonny 13.05.2025

Современные командные интерфейсы давно перестали быть черно-белыми текстовыми программами, которые многие помнят по старым операционным системам. CLI сегодня – это мощные, интуитивные и даже. . .

Конвейеры ETL с Apache Airflow и Python

AI_Generated 13.05.2025

ETL-конвейеры – это набор процессов, отвечающих за извлечение данных из различных источников (Extract), их преобразование в нужный формат (Transform) и загрузку в целевое хранилище (Load). . . .

Выполнение асинхронных задач в Python с asyncio

py-thonny 12.05.2025

Современный мир программирования похож на оживлённый мегаполис – тысячи процессов одновременно требуют внимания, ресурсов и времени. В этих джунглях операций возникают ситуации, когда программа. . .

Работа с gRPC сервисами на C#

UnmanagedCoder 12.05.2025

gRPC (Google Remote Procedure Call) — открытый высокопроизводительный RPC-фреймворк, изначально разработанный компанией Google. Он отличается от традиционых REST-сервисов как минимум тем, что. . .

Источник

Получить список COM объектов из PowerShell Windows

Получение перечня всех ComObject в Windows (Команда PowerShell)

Related posts:

Немного определений

Представление COM-объектов в реестре

Порядок проверки ключей в реестре

Выбор приоритета внутри CLSID

Права доступа на редактирование реестра

Выбор COM-объекта для атаки

Часто используемые COM-объекты

Отсутствующие в HKCU COM-объекты

Фантомные COM-объекты

COM-объекты в запланированных задачах

Примеры COM-объектов, используемые атакующими

Заключение