Привет, Хабр!
Сегодня я продолжу рассказывать про Component Object Model (COM) и атаку COM Hijacking.
В предыдущей части "Тайная жизнь COM: погружение в методы hijacking" я разобрала способы hijacking, а из первой статьи мы также узнали, что вызов этой полезной нагрузки может происходить по расписанию в случае с запланированной задачи или при запуске пользователем какого-либо ПО.
Но у вас может возникнуть вопрос, а что, если я хочу самостоятельно вызывать COM-объект, не дожидаясь каких-либо сторонних событий? Предвосхищая его, в этой статье я как раз и хочу рассказать вам немного об этом, а после мы рассмотрим, как можно детектировать атаку COM Hijacking.
И предлагаю начать со способов запуска COM-объектов штатными средствами Windows.
COM-клиенты или запуск COM-объектов
В этом разделе я рассмотрю наиболее популярные способы запуска COM-объекта после выполнения hijacking: rundll32, powershell, verclsid, xwizard и mmc, но без какой-либо их детализации. Так как данные утилиты хоть и связаны с COM, но уже больше относятся к другим техникам, например, как: Inter-Process Communication: Component Object Model (T1559.001) или System Binary Proxy Execution (T1218). Список утилит, рассмотренных мною, не является исчерпывающим, существуют и другие инструменты, позволяющие выполнить запуск COM-объекта. Но их глубокое изучение не является нашей целью сегодня.
rundll32
rundll32 - исполняемый файл, который предназначен для запуска DLL-файлов. С помощью данного способа можно запускать COM-объекты, у которых используется ключ InprocServer.
rundll32.exe -sta {CLSID}
rundll32.exe -sta {ProgID}powershell
Следующей утилитой будет Powershell. Запуск через нее универсален, то есть он подходит как для InprocServer, так и для LocalServer. Для запуска можно использовать командлеты CreateInstance или New-Object:
#CLSID
[activator]::CreateInstance([type]::GetTypeFromCLSID("0002DF01-0000-0000-C000-000000000046"))
#ProgID
[System.Activator]::CreateInstance([type]::GetTypeFromProgID("Hijack.Scriptlets"))
#Удаленный запуск через DCOM
[System.Activator]::CreateInstance([type]::GetTypeFromProgID("Hijack.Scriptlets","10.150.50.101"))New-Object -ComObject Hijack.Scripletsverclsid
Еще один способ, с помощью verclsid.exe, который проверяет COM-объект перед тем, как будет создан его экземпляр Windows Explorer'ом. Данный способ использовался в фишинговой атаке. Verclsid.exe аналогично rundll32.exe позволяет запускать COM-объекты с ключом InprocServer.
verclsid.exe /S /C {72C24DD5-D70A-438B-8A42-98424B88AFB8}xwizard
xwizard.exe - это предустановленная диагностическая утилита Windows для различных исполняемых файлов, которая также загружает dll-файлы для различных задач.
xwizard.exe RunWizard /taero /u {72C24DD5-D70A-438B-8A42-98424B88AFB8}mmc
Существует достаточное количество компонентов с графическим интерфейсом с поддержкой COM. Например, mmc.exe, iexplore.exe, winword.exe и др.
Рассмотрим пример запуска COM-объекта с помощью mmc:
Для начала создаем свою оснастку (файл .msc) с требуемым
CLSIDи сохраняем ее;Далее можем ее открыть в GUI mmc.exe или через командную строку:
mmc.exe -Embedding C:\Users\user\hijack.mscТакже существует возможность добавить в автозапуск, тогда при каждом входе в систему будет выполняться наш CLSID.
Запланированный задачи
Еще один из способов - запланированные задачи (Scheduled Tasks). Про них упоминалось в самой первой статье про COM: Выбор COM-объекта для атаки. Графический интерфейс не позволяет создавать задачи, где по триггеру будет запускаться COM-объект, но есть уже созданные по умолчанию. Их и можно использовать для перехвата COM, а также попробовать создать новую задачу через Реестр или написать свой код. Задачи с обработчиком Customer Handler выполняются из HKCR\CLSID. В результате после перехвата наш COM-объект будет выполняться по уже установленному триггеру или этот триггер можно переопределить. Но в событиях это является "лишним шумом".
Мы рассмотрели наиболее очевидные способы для запуска COM-объекта, а теперь предлагаю вернуться к основной теме статьи и проанализировать события в журналах Windows, возникающие при проведении атаки COM Hijacking.
Анализ событий
Для всех рассмотренных в прошлой статье методов hijacking, кроме подмены dll на диске, в комбинации с рассмотренными утилитами формируются идентичные события в журналах Windows. Во всех способах происходит изменение реестра в одних и тех же ветках, но в то же время отличаются редактируемые ключи. В журнале Security за изменения в реестре отвечает событие 4657 (A registry value was modified), но для формирования данного события требуется настроить SACL (пример как настраивать приведен под спойлером в конце раздела).
Аналогичные события можно получить благодаря Sysmon EventID 12 и 13 (RegistryEvent) и для этих событий не требуется настраивать SACL. На рисунках 3 и 4 видно, что с помощью утилиты powershell были в реестре созданы ключи {72C24DD5-D70A-438B-8A42-98424B88AFB8} и InprocServer32, а далее на рисунках 5 и 6 установлены значения для InprocServer32 и ThreadingModel.
Как мы видим, по информативности события совпадают: у нас есть возможность получить такие ключевые значения, как User (Account Name), Image (Process Name), TargetObject (Object Name + Object Value Name), EventType (Operation Type), Details (New value). Дополнительно в событии 4657 мы получим LogonID, с помощью которого можно проследить все действия пользователя за конкретную сессию. Но есть одно НО: 4657 не регистрирует события создания нового ключа в реестре и установка значения вDefault, именно в этом поле указываются dll \ exe файлы. Таким образом, ориентируясь только на это событие, есть вероятность пропустить атаку, так как можно обойтись только созданием ключей и указанием Default значений.
Из этих событий также видно, что при изменении ветки HKCU на самом деле происходит изменение HKU\{SID}. Данный момент является подтверждением того, что HKCU - ссылка на HKU текущего пользователя.
При использовании ключа InprocServer не мало важным событием является Sysmon 7 (Image loaded), которое свидетельствует о подгрузке вредоносной dll в процесс (рисунок 7). При использовании ключа LocalServer вредоносный процесс подгружает сам себя (рисунок 8).
В случае с использованием LocalServer32 запуск вредоносного COM-объект происходит от имени процесса svchost.exe -k DcomLaunch -p. Проследить это можно с помощью EventID 4688 (A new process has been created) или Sysmon 1 (Process creation).
Также благодаря Process Creation есть возможность отследить, с помощью какой утилиты изменялся реестр и с какими аргументами она запускалась. Если атакующий будет использовать собственное ПО с применением API для редактирования реестра, то отследить такие операции с помощью Process Creation не получиться, только запуск этого ПО.
Настройка SACL для мониторинга реестра
Для начала требуется включить политику с помощью групповой политики: Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Audit Policies\Object Access\Audit Registry со значениями Success and Failure.
Посмотреть и выставить SACL можно в оснастке редактирования реестра (Registry Editor). Для этого нужно перейти в реестр по веткам перечисленным в разделе Представление COM-объектов в реестре. Далее перейти в Permissions → Advanced → Auditing → Add
В данном разделе статьи мы проанализировали события, возникающие при атаке COM Hijacking. Большинство способов проведения атаки полагаются на изменения в реестре и отследить их можно с помощью Sysmon EventID 12 и 13. Теперь давайте посмотрим, как эта информация может нам помочь при построении детекта.
Детектирование
Техника захвата COM не является легко обнаруживаемой, потому что она использует доверенные системные процессы. Из анализа событий выше становится ясно, что наиболее универсальным и подходящим решением для детектирования будет использование мониторинга изменений в реестре по веткам:
HKEY_CURRENT_USER\SOFTWARE\ClassesHKEY_LOCAL_MACHINE\SOFTWARE\ClassesHKEY_CLASSES_ROOT\HKEY_CURRENT_USER\SOFTWARE\WOW6432Node\ClassesHKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\ClassesHKEY_CLASSES_ROOT\WOW6432Node
Существуют разные классы программного обеспечения для решения данной проблемы. Так отслеживание аномалий в изменении реестра можно проводить с помощью EDR и \ или UEBA решений. SIEM-система тоже подходит для отслеживания изменений, но при установке нового легитимного ПО или обновлениях текущего будут присутствовать ложно-положительные сработки, и каждый такой кейс требует внимания специалиста. За основу событий лучше брать события Sysmon с номерами 12, 13, так как они отражают не только установление значения, но и создание новых ключей в отличии от 4657.
При использовании dll в качестве COM-объекта следует отслеживать аномалии в подгрузке нетипичной dll легитимным ПО, сделать это можно с помощью Sysmon EventID 7.
Также подозрительным является тот факт, что COM-объект для пользователя и для машины будет иметь разные DLL\EXE. При подмене dll на диске можно рассматривать подозрительную запись файла в нетипичную для пользователя директорию. Также во всех случаях проводится проверка доставленного исполняемого файла антивирусом на известные сигнатуры и поведенческий анализ.
Что еще стоит посмотреть
При COM-Hijacking происходит подмена выполняемой dll. Логично, что в злонамеренную dll не зашит первоначальный функционал COM-объекта. Поэтому, в случае попытки легитимного обращения к COM-объекту могут возникать ошибки, и требуемый запрос не будет выполнен. Это должно насторожить пользователя. На git есть проект COMProxy, в котором реализуется поиск легитимной dll в ветке реестра HKLM и проксирование на нее с помощью DllGetClassObject. Зловредный функционал также нужно реализовать в этой dll. Таким образом, при легитимном обращении к COM-объекту не возникнет никаких ошибок и требуемые задачи будут отработаны, а параллельно могут выполняться зловредные действия. Также в проекте есть пример COM-клиента, но в данном случае сохраняется работоспособность запуска полезной нагрузки, перечисленной выше. Пример приводится на COM-объект WScript.Shell, однако данная dll может быть внедрена в любой другой объект.
Заключение
Это была заключительная часть из данной серии статей, в которых я попыталась раскрыть несколько важных моментов о Component Object Model. Ранее мы узнали о том, какие ключи в реестре важны для атаки COM-hijacking и какими правами необходимо обладать для редактирования этих ключей. А после мы изучили стратегии, которыми может пользоваться атакующий для выбора COM-объекта для последующей атаки на него, и какими способами можно осуществить перехват
В этой части я рассказала о том, как запустить скомпрометированный объект, а также обсудили самое главное - это как выявлять атаку. Однозначное детектирование COM-hijacking не является тривиальной задачей, поэтому потребуется использовать средства, которые могут анализировать аномалии в реестре с помощью Machine Learning. Если компания не обладает такими решениями, но есть SIEM или другие инструменты, умеющие анализировать журналы с событиями по типу sigma, можно осуществлять мониторинг по событиям sysmon 12,13. Однако при обновлении или установке легитимных программных средств могут возникать ложно-положительные сработки, и каждый такой кейс будет требовать внимания специалиста.
Спасибо всем за внимание! Пишите комментарии и задавайте вопросы!
Автор: Кожушок Диана( @wildresearcher ) аналитик-исследователь киберугроз в компании R-Vision