Очередной DCOM-объект для горизонтального перемещения

Введение

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

За прошедшие годы было обнаружено множество разных DCOM-объектов. Некоторые опираются на системные компоненты Windows, другие зависят от стороннего ПО, например Microsoft Office, а некоторые объекты и вовсе являются недокументированными и были найдены посредством реверс-инжиниринга. Многие из них перестали функционировать в более новых версиях Windows, но далеко не все.

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

Сначала мы рассмотрим, что представляет собой технология COM. После этого мы оценим текущее состояние скрипта Impacket dcomexec, сосредоточимся на все еще рабочих объектах, обсудим потенциальные исправления и улучшения их работы, а затем перейдем к техникам перечисления объектов в системе. Далее мы изучим элементы панели управления и обсудим, как злоумышленники могут ими воспользоваться для получения первоначального доступа и закрепления в системе и как DCOM-объект может привести к их компрометации, предоставляя возможность выполнения команд.

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

Технология COM/DCOM

Что такое COM

COM (Component Object Model, «модель компонентных объектов») — это технология Microsoft, определяющая стандарт бинарного интерфейса приложений. Технология позволяет создавать многократно используемые программные компоненты, которые могут взаимодействовать во время выполнения без необходимости компилировать COM-библиотеки непосредственно в приложение.

Эти программные компоненты работают по клиент-серверной модели. COM-объект предоставляет свою функциональность через один или несколько интерфейсов. Интерфейс представляет собой набор связанных функций-членов (методов).

COM также обеспечивает взаимодействие между процессами на одном компьютере, используя локальный RPC (Remote Procedure Call) для межпроцессного обмена.

Термины

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

1. COM-интерфейс
   COM-интерфейс определяет функциональность, которую предоставляет COM-объект. Каждый COM-интерфейс идентифицируется по уникальному GUID, известному как IID (Interface ID).

   Все COM-интерфейсы можно найти в реестре Windows в разделе HKEY_CLASSES_ROOT\Interface, где они упорядочены по GUID.

2. COM-класс (COM CoClass)
   COM-класс — это фактическая реализация одного или нескольких COM-интерфейсов. Как и COM-интерфейсы, классы идентифицируются по уникальному GUID, который в данном случае называется CLSID (Class ID). Этот GUID необходим для поиска нужного COM-сервера и активации соответствующего COM-класса.

   Все COM-классы регистрируются в реестре в разделе HKEY_CLASSES_ROOT\CLSID, где хранится GUID каждого класса. Для каждого GUID может иметься несколько подключей разного назначения, например:

   • InprocServer32/LocalServer32 — системный путь к COM-серверу, в котором определен класс. InprocServer32 используется для внутрипроцессных серверов (DLL), а LocalServer32 — для внепроцессных (EXE). Подробнее об этом чуть позже.
   • ProgID — человекочитаемое имя, присвоенное COM-классу;
   • TypeLib — описание COM-класса в бинарном виде (по сути, документация для класса);
   • AppID — описание конфигурации безопасности для класса.
3. COM-сервер
   COM-сервер — это модуль, в котором определен COM-класс. Сервер может быть реализован как EXE, в этом случае он называется внепроцессным сервером (out-of-process server), или как DLL — такой вариант называется внутрипроцессным сервером (in-process server).

У каждого COM-сервера есть уникальный файловый путь или расположение в системе. Информация о COM-серверах хранится в реестре Windows. Руководствуясь этими записями, среда выполнения COM находит нужный сервер и выполняет последующие действия. Записи реестра для COM-серверов располагаются в корневом разделе HKEY_CLASSES_ROOT как для 32-разрядных, так и для 64-разрядных серверов.

Реализация технологии COM

Клиент-серверная модель

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

   Внутрипроцессный COM-сервер

2. Внепроцессный сервер
   В этом случае сервер реализован как исполняемый файл (EXE). Поскольку клиент не может загрузить EXE в свое адресное пространство, сервер работает отдельно от клиента в собственном процессе. Эти два процесса обмениваются данными через порты ALPC (Advanced Local Procedure Call), которые выступают в роли транспортного уровня RPC для COM.
   

   Внепроцессный COM-сервер

Что такое DCOM

DCOM — это расширение COM, где D означает Distributed («распределенная» модель компонентных объектов). DCOM позволяет клиенту и серверу находиться на разных машинах. С точки зрения пользователя нет никакой разницы: DCOM предоставляет уровень абстракции, благодаря которому и клиент, и сервер ведут себя так, будто они работают на одной машине.

Однако «под капотом» COM использует TCP в качестве транспортного уровня RPC для взаимодействия между машинами.

Реализация DCOM

Чтобы превратить COM-объект в DCOM-объект, необходимо выполнить ряд требований. Наиболее важным для нашего исследования является наличие подключа AppID в реестре внутри записи CLSID соответствующего COM-объекта.

Значение AppID содержит GUID, которому соответствует ключ в HKEY_CLASSES_ROOT\AppID. Внутри этого GUID может быть несколько подключей. Критически важны два из них:

• AccessPermission: контроль прав доступа;
• LaunchPermission: контроль прав на активацию.

Именно через эти параметры реестра удаленным клиентам предоставляются права на активацию DCOM-объектов и взаимодействие с ними.

Горизонтальное перемещение через DCOM

Как только злоумышленникам удается скомпрометировать хост, зачастую они пытаются получить контроль над другими машинами в сети. Это то, что мы называем горизонтальным перемещением. Одна из распространенных техник горизонтального перемещения — поиск возможности удаленного выполнения команд на целевой машине. Это можно сделать разными способами, одним из которых является использование DCOM-объектов.

За годы существования этой технологии было обнаружено и описано множество DCOM-объектов. В этом исследовании я сосредоточусь на объектах, с помощью которых в скрипте dcomexec.py из набора Impacket реализовано выполнение команд. Мы рассмотрим следующие три объекта: ShellWindows, ShellBrowserWindow и MMC20.

1. ShellWindows
   ShellWindows был одним из первых DCOM-объектов, обнаруженных исследователями. Он представляет собой коллекцию открытых окон проводника и размещен в процессе explorer.exe, а значит, любой COM-клиент может взаимодействовать с этим процессом.

   После создания экземпляра этого COM-объекта на удаленной машине скрипт dcomexec.py из набора Impacket открывает полуинтерактивную командную оболочку. При вводе каждой команды вызывается функция, предоставляемая этим COM-объектом. Результат выполнения команды записывается в файл, который скрипт считывает через SMB и выводит обратно в оболочку, имитируя работу обычного терминала.

   Для подключения скрипт выполняет следующую команду:
   cmd.exe /Q /c cd \ 1> \\127.0.0.1\ADMIN$\__17602 2>&1

   Она устанавливает C:\ в качестве рабочего каталога и перенаправляет вывод в файл __17602 в общем ресурсе ADMIN$. После этого скрипт проверяет наличие файла. Если он существует, команда считается успешно выполненной, и скрипт выводит его содержимое так, словно команда была выполнена в терминале.

   Если запустить dcomexec.py в ОС Windows 10 или 11, используя объект ShellWindows, скрипт зависнет после подтверждения инициализации SMB-подключения и вывода SMB-баннера. Как я уже отмечал в своем личном блоге, похоже, этот DCOM-объект больше не имеет разрешения на запись в общий ресурс ADMIN$.

   Простое решение — перенаправить вывод в каталог, в который DCOM-объект по-прежнему имеет право на запись, например в папку Temp. Затем можно обратиться к папке Temp через тот же общий ресурс ADMIN$. Чтобы код снова работал, достаточно внести небольшую правку. Например:

   OUTPUT_FILENAME = 'Temp\\__' + str(time.time())[:5]

2. ShellBrowserWindow
   Объект ShellBrowserWindow ведет себя почти так же, как ShellWindows, и в Windows 10 скрипт точно так же зависает. То же обходное решение, которое мы применяли для ShellWindows, работает и здесь.

   Однако в Windows 11 возможность выполнения команд через этот объект была отключена.

3. MMC20
   COM-объект MMC20.Application является интерфейсом автоматизации для Microsoft Management Console (MMC). Предусмотренные в нем методы и свойства позволяют автоматизировать работу с оснастками MMC.

   Раньше этот объект работал во всех версиях Windows. Однако начиная с Windows Server 2025 попытки использовать этот объект вызывают предупреждение Защитника Windows и последующее блокирование процесса.

   Как показано в предыдущих примерах, скрипт dcomexec.py записывает вывод команды в файл в каталоге ADMIN$, имя которого начинается с символов __:

   OUTPUT_FILENAME = '__' + str(time.time())[:5]

   По всей видимости, Защитник проверяет, не записываются ли в ADMIN$ файлы с двойным подчеркиванием (__) в начале имени, и при их обнаружении блокирует процесс и уведомляет пользователя. Быстрое решение — убрать двойное подчеркивание из имени выходного файла.

   Другой способ обойти эту проблему — перенаправить вывод в папку Temp, как и в случае с ShellWindows.

В таблице ниже приведен рабочий статус этих объектов в разных версиях Windows.

Перечисление объектов COM/DCOM

Чтобы определить, какие DCOM-объекты могут быть использованы для горизонтального перемещения в сети, сначала их нужно перечислить. И под «перечислить» я имею в виду не просто сформировать список. Перечисление должно включать:

• поиск объектов и фильтрацию конкретно DCOM-объектов;
• определение интерфейсов этих объектов;
• изучение доступных функций.

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

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

1. Автоматизация с помощью PowerShell
   В PowerShell можно использовать .NET для создания DCOM-объектов и взаимодействия с ними. Можно создать объект по его ProgID или CLSID, а затем вызывать его функции (как показано на рисунке ниже).
   

   Список функций COM-объекта Shell.Application в PowerShell

   Для этого PowerShell проверяет, есть ли у COM-объекта TypeLib и поддерживает ли он интерфейс IDispatch. IDispatch обеспечивает отложенное связывание (late binding), которое позволяет динамически создавать объект во время выполнения и вызывать его функции. При соблюдении этих двух условий PowerShell может динамически взаимодействовать с COM-объектами во время выполнения.

   Наша стратегия выглядит следующим образом:
   
   Как видно в последнем блоке схемы, мы вручную ищем функции с представляющими интерес названиями, такими как Execute, Exec и Shell, которые могут быть связаны с выполнением команд.

   Однако у этого подхода есть несколько ограничений.

   • Требование наличия TypeLib. Не у всех COM-объектов есть TypeLib, поэтому многие из них невозможно перечислить этим методом.
   • Требование наличия IDispatch. Не во всех COM-объектах реализован интерфейс IDispatch, который необходим для взаимодействия через PowerShell.
   • Фиксированный интерфейс. При создании экземпляра объекта в PowerShell невозможно выбрать, к какому интерфейсу будет привязан этот экземпляр. Если в COM-классе предусмотрено несколько интерфейсов, PowerShell автоматически выберет тот, который помечен в TypeLib как [default]. Следовательно, другие нестандартные интерфейсы, которые могут содержать дополнительные полезные функции, такие как выполнение команд, могут быть упущены из виду.
2. Автоматизация с помощью C++
   C++ относится к языкам программирования с нативной поддержкой COM-клиентов. В C++ можно создавать экземпляры COM-объектов и вызывать их функции через файлы заголовков, определяющие интерфейсы.

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

   Этот метод в основном полагается на интерфейс IUnknown. Все COM-интерфейсы должны наследоваться от этого интерфейса, а все COM-классы — поддерживать его. Интерфейс IUnknown предоставляет три основные функции. Самая важная из них — QueryInterface(), которая используется для запроса у COM-объекта указателя на один из его интерфейсов.

   Наша стратегия такова.

   • Перечислить COM-классы в системе, считав все CLSID в разделе HKEY_CLASSES_ROOT\CLSID.
   • Проверить, поддерживают ли они какие-либо известные интерфейсы с вредоносным потенциалом. Если поддерживают, возможно, через эти классы можно выполнять команды или другие потенциально опасные действия.

   Этот метод имеет ряд преимуществ.

   • Отсутствие зависимости от TypeLib. В отличие от варианта на PowerShell, этот подход не требует наличия TypeLib у COM-объекта.
   • Использование IUnknown. В C++ можно использовать функцию QueryInterface из базового интерфейса IUnknown, чтобы проверить, поддерживает ли COM-класс определенный интерфейс.
   • Нет необходимости в определениях интерфейсов. Даже не зная точной структуры интерфейса, можно получить указатель на его виртуальную таблицу функций (vtable), обычно приводимый к типу void*. Этого достаточно, чтобы подтвердить существование интерфейса и при необходимости исследовать его.

   На схеме ниже представлена эта стратегия.

   

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

3. Ручной анализ с помощью инструментов с открытым исходным кодом
   Как видно, автоматизация анализа сопряжена со значительными сложностями: она требует соблюдения ряда условий и во многих случаях все равно сводится к ручной проверке.
   Альтернативный подход — ручной анализ с использованием инструмента OleViewDotNet, разработанного Джеймсом Форшоу (James Forshaw). Этот инструмент позволяет:
   • составлять список всех COM-классов в системе;
   • создавать экземпляры этих классов;
   • проверять поддерживаемые интерфейсы;
   • вызывать конкретные функции;
   • применять разные фильтры для удобства анализа;
   • выполнять другие аналитические задачи.
   

   Инструмент с открытым исходным кодом для анализа COM-интерфейсов

   Одна из самых полезных функций этого инструмента — отображение имен. OleViewDotNet извлекает имена интерфейсов и классов из реестра Windows, если они доступны, и отображает их вместе с соответствующими библиотеками типов.

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

Элементы панели управления как вектор атаки

С помощью элементов панели управления пользователи могут просматривать и изменять параметры компьютера. Обычно такие элементы имеют расширение .cpl и по сути представляют собой DLL-файлы с экспортируемой функцией CPlApplet. Элементы панели управления могут быть и исполняемыми файлами, однако в нашем исследовании мы сосредоточимся только на DLL.

Элементы панели управления

Злоумышленники могут использовать CPL-файлы для получения первоначального доступа. Когда пользователь запускает вредоносный файл .cpl (например, из фишингового письма), система может оказаться скомпрометирована (см. технику MITRE ATT&CK T1218.002).

Злоумышленники также могут изменить расширение вредоносных DLL на .cpl и зарегистрировать их, добавив соответствующие записи в указанные ниже разделы реестра.

• В корневой раздел HKEY_CURRENT_USER:
  HKCU\Software\Microsoft\Windows\CurrentVersion\Control Panel\Cpls

• В корневой раздел HKEY_LOCAL_MACHINE:
  • Для 64-разрядных DLL:
    HKLM\Software\Microsoft\Windows\CurrentVersion\Control Panel\Cpls
  • Для 32-разрядных DLL:
    HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Control Panel\Cpls

В зависимости от выбранных разделов реестра вредоносные DLL-файлы панели управления могут быть доступны либо текущему пользователю, либо всем пользователям компьютера. Однако подключ Control Panel и его подключ Cpls в ветке HKCU нужно создавать вручную, в отличие от одноименных подключей в HKLM, которые создаются автоматически операционной системой.

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

Стоит отметить, что, даже если DLL-библиотека не соответствует спецификации CPL, не экспортирует функцию CPlApplet или не имеет расширения .cpl, она все равно может быть выполнена через функцию DllEntryPoint, если зарегистрирована в одном из перечисленных выше ключей реестра.

Существует несколько способов запуска элементов панели управления:

• из командной строки: exe [имяфайла].cpl;
• двойным щелчком по файлу .cpl.

Оба этих способа реализованы через rundll32.exe:

rundll32.exe shell32.dll,Control_RunDLL [имяфайла].cpl

Эта команда вызывает функцию Control_RunDLL из shell32.dll, передавая CPL-файл в качестве аргумента. Затем выполняется весь код, находящийся внутри его функции CPlApplet.

Однако, если CPL-файл был зарегистрирован в реестре описанным ранее способом, он будет загружаться в память через процесс COM Surrogate (dllhost.exe) при каждом открытии панели управления:

Процесс COM Surrogate, загружающий CPL-файл

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

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

«DCOM-изация» элементов панели управления

При ручном переборе COM/DCOM-объектов в поисках тех, что могут быть полезны для горизонтального перемещения в сети, я обнаружил COM-объект COpenControlPanel. Он реализован внутри библиотеки shell32.dll и имеет CLSID {06622D85-6856-4460-8DE1-A81921B41C4B}. Этот объект поддерживает несколько интерфейсов, одним из которых является IOpenControlPanel с IID {D11AD862-66DE-4DF4-BF6C-1F5621996AF1}.

Интерфейс IOpenControlPanel в выводе OleViewDotNet

Я сразу подумал о возможности компрометации через элементы панели управления и решил выяснить, какие функции предоставляет этот интерфейс. К сожалению, ни интерфейс, ни COM-класс не содержат библиотеки типов.

Интерфейсы COpenControlPanel без TypeLib

Обычно анализ определения интерфейса требует реверс-инжиниринга, поэтому сначала показалось, что придется менять направление исследования. Но, как выяснилось, интерфейс IOpenControlPanel задокументирован на MSDN, и в описании указано, что он предоставляет несколько функций. Одна из них называется Open и позволяет открыть указанный элемент панели управления, если передать его имя в качестве первого аргумента.

Полные определения типов и функций приведены в файле заголовка Windows shobjidl_core.h.

Функция Open, предоставляемая интерфейсом IOpenControlPanel

Стоит отметить, что в более новых версиях Windows (например, Windows Server 2025 и Windows 11) компания Microsoft убрала имена интерфейсов из реестра, поэтому они больше не отображаются через OleViewDotNet.

Интерфейсы COpenControlPanel без имен

Вернемся к COM-объекту COpenControlPanel. В ходе анализа я обнаружил, что с помощью функции Open можно инициировать загрузку DLL-библиотеки в память, если она зарегистрирована в реестре. В целях этого исследования я создал DLL, которая просто отображает окно сообщения. Соответствующий код был размещен в функции DllEntryPoint. Затем я зарегистрировал эту библиотеку в разделе HKCU\Software\Microsoft\Windows\CurrentVersion\Control Panel\Cpls и создал простой COM-клиент на C++, чтобы вызвать функцию Open из рассматриваемого интерфейса.

Как я и ожидал, DLL-библиотека действительно была загружена в память. Она работала так же, как при обычном запуске панели управления, то есть через родительский процесс COM Surrogate (dllhost.exe). В Process Explorer я убедился, что процесс dllhost.exe загружал мою DLL; одновременно с этим в нем был размещен объект COpenControlPanel вместе с другими COM-объектами.

Кастомизированная DLL и объект COpenControlPanel, загружаемые процессом COM Surrogate

По результатам своего теста я сделал несколько наблюдений.

1. Библиотека DLL, которую нужно зарегистрировать, необязательно должна быть CPL-файлом — успешно загружается любая DLL с корректно определенной точкой входа.
2. Функция Open() принимает в качестве первого аргумента имя элемента панели управления. Однако эксперимент показал, что, даже если ей передать произвольную строку, она все равно загружает в память все DLL, зарегистрированные в соответствующем разделе реестра.

Возникает вопрос: можно ли вызвать этот COM-объект удаленно? Иными словами, можем ли мы превратить его из обычного COM-объекта в DCOM-объект? Чтобы проверить это, мы изучили AppID объекта COpenControlPanel с помощью OleViewDotNet.

Объект COpenControlPanel в OleViewDotNet

Разрешения на запуск и доступ не прописаны в объекте, следовательно, он будет наследовать стандартную политику безопасности DCOM в системе. По умолчанию участники группы Administrators имеют право запускать DCOM-объекты и обращаться к ним.

Отталкиваясь от этого, можно выстроить следующую стратегию удаленного выполнения. Сначала загрузим «вредоносную» DLL, затем через службу удаленного реестра зарегистрируем ее в нужном разделе. Наконец, с помощью триггера, действующего как DCOM-клиент, удаленно вызовем функцию Open(), что приведет к загрузке нашей DLL. Последовательность действий показана на схеме ниже.

Загрузка вредоносных DLL с использованием DCOM

Триггер может быть написан как на C++, так и на Python (например, с помощью Impacket). Я остановился на Python из-за его гибкости. Сам триггер прост: мы определяем класс DCOM, интерфейс и вызываемую функцию. Полный пример кода можно найти здесь.

После выполнения триггера мы будем наблюдать то же поведение, что и при локальном запуске COM-клиента: наша DLL загрузится через родительский процесс COM Surrogate (dllhost.exe).

Как видно, эта техника позволяет не только выполнять команды, но и закрепляться в системе. Кастомизированная библиотека может быть запущена двумя способами: при открытии пользователем панели управления или удаленно через DCOM.

Обнаружение

Первый шаг в обнаружении такой активности — посмотреть, какие элементы панели управления зарегистрированы в следующих разделах реестра:

• HKCU\Software\Microsoft\Windows\CurrentVersion\Control Panel\Cpls
• HKLM\Software\Microsoft\Windows\CurrentVersion\Control Panel\Cpls
• HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Control Panel\Cpls

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

Кроме того, появление необычных COM-объектов в родительском процессе dllhost.exe (COM Surrogate), например COpenControlPanel, также может служить индикатором вредоносной активности.

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

Заключение

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

• DCOM представляет обширную поверхность для атаки. Windows содержит множество DCOM-классов, и значительная их часть не имеет библиотек типов. Реверс-инжиниринг может выявить дополнительные классы, которые потенциально могут использоваться для горизонтального перемещения в сети.
• Изменение значений реестра для регистрации вредоносных CPL-файлов — плохая практика с точки зрения этики red teaming. Средства защиты обычно отслеживают часто используемые разделы реестра для закрепления в системе. Однако апплеты панели управления могут быть зарегистрированы в разных ключах реестра, что оставляет потенциальные возможности для эксплуатации.
• Разрядность также имеет значение: на x64-системах загрузка 32-разрядной DLL-библиотеки приведет к созданию 32-разрядного процесса COM Surrogate (dllhost.exe *32), что нетипично для 64-разрядной среды. Такой индикатор будет полезен специалистам по защите и должен учитываться при проведении тестирования на проникновение.