Привет, Хабр! Сегодня я продолжу рассказывать о 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. Вспомнив принципы работы атаки COM Hijacking, давайте детальнее рассмотрим каждый из методов для ее проведения. И начнем со способа, где для Hijacking используется ключ InprocServer в реестре.  Ключ InprocServer применяется для указания dll-файла, который при вызове соответствующего COM-объекта загрузится в память вызывающего его процесса.  Суть метода заключается в том, чтобы в ветке HKCU прописать вредоносную dll. Таким образом, dll, указанная в HKCU, будет иметь больший приоритет для выполнения, если вызывающий процесс обладает соответствующим уровнем целостности. Именно здесь используется выбранный на предыдущем этапе COM-объект. Для удобства демонстрации атаки мною был выбран COM-объект {72C24DD5-D70A-438B-8A42-98424B88AFB8} - Wscript.Shell. До атаки данный CLSID был прописан только в ветке HKLM (рисунок 2): При вызове данного объекта в Process Monitor можно заметить, что первым делом проверяется ветка HKCU, но файл не найден (NAME NOT FOUND), и впоследствии происходит проверка COM-объекта в HKLM (рисунки 3 и 4).  После проведения атаки на выбранный нами COM-объект мы увидим, что в реестре проверка ключа InprocServer в HKCU завершается успехом (SUCCESS) (рисунок 5) и в результате подгружается вредоносная dll, что отображено на рисунках 6 и 7: Так как данный способ основан на изменении реестра, то нам подойдут любые инструменты, позволяющие редактировать реестр. Первый из рассмотренных мной был reg.exe. С помощью данной утилиты можно внести изменения двумя способами:  Способ 1 - внести все изменения вручную: Для того, чтобы удаленно редактировать реестр требуется включить службу Remote Registry. В данном случае все изменения в реестре будут производится процессом C:\Windows\system32\svchost.exe -k localService -p -s RemoteRegistry. С помощью инструментов reg.exe и оснастки regedit нельзя удаленно редактировать ветку HKEY_CURRENT_USER, но так как HKCU является ссылкой на HKU, то достаточно внести изменения в HKEY_USERS\{SID}. Способ 2 - заранее в файле подготовить все изменения в реестре, а далее произвести импорт:  Ниже показан пример команды для применения конфигурации: Второй инструмент, который можно использовать для редактирования реестра - Powershell.  Командлеты, которые нужно в нем запустить, выглядят следующий образом: В отличии от первого инструмента, Powershell позволяет удаленно редактировать ветку HKCU. Для этого можно применять командлет Invoke-Command -ComputerName COMPUTER -ScriptBlock {...}. В данном случае используется порт 5985 и протокол WS-Management, а в событиях на удаленном хосте все изменения происходят от имени wsmprovhost.exe (Windows Remote Powershell). В инструменте acCOMplice этот способ атаки автоматизирован с помощью функции Hijack-CLSID: Данный скрипт написан на Powershell и использует вышеупомянутую функцию New-Item.  Также в качестве входного параметра можно выбрать InprocServer или LocalServer. Далее мы рассмотрим еще один способ атаки с использованием ключа LocalServer.  Атака с LocalServer проводится также, как и с использованием ключа InprocServer/InprocServer32. Отличие только в том, что COM-объект будет загружен как отдельный процесс. Как это выглядит на практике я расскажу далее.  И в качестве примера для демонстрации атаки я буду использовать объект InternetExplorer c CLSID {0002DF01-0000-0000-C000-000000000046}. Для внесения изменений в реестр можно применять утилиты из прошлого метода:  Ниже на рисунках показан вызов COM-объекта, который происходил из Powershell. В качестве родительского процесса здесь выступает svchost.exe -k DcomLaunch -p. Как мы видим из рисунков 8,9,10 вредоносный исполняемый файл загружен как отдельный процесс, и в качестве родителя выступает служба DcomLaunch. Перейдем к следующему способу.  В данном методе перехват осуществляется за счет перенаправления определенного COM-объекта на другой. То есть мы регистрируем свой CLSID в кусте реестра HKCU с вредоносным COM-объектом, а далее за счет ключа TreatAs перенаправляем легитимный COM-объект на вредоносный CLSID. В нашем примере мы перехватим COM-объект с GUID {72C24DD5-D70A-438B-8A42-98424B88AFB8} (Рисунок 12) и перенаправим его на COM-объект с GUID {00000001-0000-0000-0000-0000FEEDACDC} (Рисунок 11).Редактирование реестра осуществляется с помощью утилит, рассмотренных в первом способе. Ниже под спойлером предствлен файл конфигурации, применимый к данному методу атаки.   Аналогично можно перенаправлять на объект с LocalServer. (Рисунок 13, 14) Перенаправление на COM-объект с LocalServer происходит с помощью следующей команды: Приложение на компьютере может использовать ProgID\VersionIndependentProgID, если ему неизвестен CLSID компонента. Для захвата ProgID возможно добавить ложную запись ProgID в HKCU с вредоносным CLSID. И после этого зарегистрировать наш вредоносный CLSID. Покажу это на примере COM-объекта {72C24DD5-D70A-43 8B-8A42-98424B88AFB8} - Wscript.Shell. На рисунках 15,16,17 представлена конфигурация данного COM-объекта по умолчанию в ветке HKLM до проведения атаки. Для внесения изменений также можно использовать утилиты из метода с использованием ключа InprocServer.  Ниже приведена конфигурация с требуемыми изменениями. ProgID и VersionIndependentProgID можно использовать как вместе, так и по отдельности.  Для того чтобы перехват сработал, необходимо обязательно вызывать COM-объект по ProgID\VersionIndependentProgID.  Если мы попытаемся выполнить его через CLSID, который в данном случае не захватывается, то атака не сработает.  Ниже представлен пример вызова по ProgID c помощью предустановленного компонента ОС Windows rundll32.exe:  Рассмотрим еще один ключ для проведения атаки Hijacking.  Если мы не хотим размещать на диске у жертвы свою вредоносную DLL, то в реестре для COM-объектов есть специальный ключ ScriptletURL, который позволяет указать расположение скриптлета на внешнем ресурсе. Для примера проведения атаки с помощью этого способа возьмем следующий Scriptlet. При этом обязательно в ключе InprocServer нужно указывать scrobj.dll, иначе sct файл не выполнится. На рисунках 18, 19, 20 представлено получение объекта scrobj.dll  и скачивание с удаленного ресурса, указанного в ключе ScriptletURL скриптлета с полезной нагрузкой. Пример файла конфигурации для данного метода атаки показан под спойлером:  И последний рассмотренный мною способ отличается от всех остальных. В данном методе не требуется редактировать реестр и т.д. В его основе лежит определение Phantom COM-объектов, о чем я рассказывала в предыдущей статье.  Далее, если имеются права, то записываем по требуемому пути и с необходимым именем свою вредоносную dll на диск. Как показывает практика, наиболее часто встречается фантомный объект psmachine_64.dll, связанный с обновлениями браузеров Microsoft Edge или Google. Набор фантомных объектов на устройстве будет зависеть от когда-либо установленного ПО. Наличие таких объектов может быть вызвано ошибками в разработке этого ПО или некорректным удалением/обновлением, из-за чего записи в реестре останутся. В данном случае построение детекта на основе этого способа будет отличаться от возможных способов выявления выше рассмотренных методов. В этой статье я разобрала основные способы проведения атаки COM Hijacking и показала, что именно использование более приоритетной ветки или ключа делает атаку возможной. На основе разобранных способов в следующей статье  мы проанализируем события в журналах Windows, а также поговорим про возможные стратегии детекта данной атаки. Стоит отметить, что все способы имеют право на жизнь, ни один не является лучше или хуже. Здесь, как говорится, выбор на вкус и цвет атакующего, а также он зависит от исходно заданных ключей COM-объекта. То есть, если, например, по умолчанию у COM-объекта будет задан в HKLM ключ TreatAs, то единственный способ проведения атаки является использование ключа TreatAs в HKCU, так как остальные ключи имеют меньший приоритет и не будут выполнены в процессе атаки.  Надеюсь, данный материал оказался для вас полезным! Если у вас появились вопросы или знаете еще какие-либо интересные способы проведения атаки, не упомянутых сегодня, то делитесь в комментариях! Автор: Кожушок Диана( @wildresearcher) аналитик-исследователь киберугроз в компании R-Vision