Резюме для руководства
BlueHammer (CVE-2026-33825) представляет собой цепочку повышения локальных привилегий из восьми этапов, нацеленную на платформу Windows Defender Antimalware Platform до версии 4.18.26030.3011. Она не предоставляет первоначальный доступ; злоумышленнику сначала требуется выполнение кода от имени стандартного пользователя. Тем не менее, в лабораторных условиях она позволила получить уровень NT AUTHORITY\SYSTEM, извлечь учетные данные администратора домена из LSASS и совершить латеральное перемещение с помощью pass-the-hash. Это не повреждение памяти. Цепочка объединяет обратные вызовы CloudFilter, пакетные оплоки (oplocks), символические ссылки диспетчера объектов, RPC-интерфейс обновления Защитника, автономный парсинг SAM и SAMR. Крайне важно то, что понятие «уязвимый» не тождественно понятию «эксплойтабельный»: факторы среды выполнения — ожидающее обновление сигнатур, состояние WinDefend, драйверы фильтров, VSS, доступность CloudFilter — определяют, сработает ли этот путь на конкретном хосте. Именно этот разрыв не может закрыть сканирование на основе версий. Qualys TruConfirm помечает хост как «Эксплойт подтвержден» (Exploit Validated) только после проверки окружения, а также неразрушающей BAS-валидации заморозки CloudFilter (этапы 2–3) без извлечения SAM, сброса паролей, создания служб и получения оболочки SYSTEM.
Введение и ход выполнения атаки
Идентификатор CVE сообщает о том, что может пойти не так. Он не говорит о том, сможет ли злоумышленник действительно реализовать это на вашей машине. Эксплойтабельность зависит от доступности уязвимого пути, привилегий, с которых начинает злоумышленник, доступных служб и компонентов, а также текущего состояния системы. Анализ эксплойтабельности объединяет эти сигналы, чтобы ответить на практический вопрос: можно ли проэксплуатировать эту уязвимость на данной машине прямо сейчас?
BlueHammer предоставляет конкретный пример для изучения. Защитник Windows — это постоянно работающий компонент с высокими привилегиями, чьи драйверы фильтров, RPC-интерфейсы, механизм сканирования и механизмы обновления функционируют с правами SYSTEM. Публично отслеживаемая как CVE-2026-33825, уязвимость BlueHammer объединяет эти доверенные компоненты в цепочку повышения локальных привилегий из восьми этапов. Microsoft определяет версии Defender Antimalware Platform до 4.18.26030.3011 как уязвимые; на нашем хосте для обратного проектирования была установлена версия 4.18.2104.10.
BlueHammer не предоставляет первоначальный доступ. Злоумышленник должен сначала получить выполнение кода в качестве стандартного пользователя, потенциально посредством фишинга, вредоносного контента или злоупотребления легитимными учетными записями. В нашей лаборатории эксплойт задействовал привилегированные пути обновления и обработки файлов Защитника для получения прав NT AUTHORITY\SYSTEM. Из этой командной оболочки мы восстановили учетные данные для CITRIX\administrator, которые уже присутствовали в LSASS. Используя метод pass-the-hash, мы прошли аутентификацию на контроллере домена от имени CITRIX\administrator, после чего получили доступ к защищенным системным папкам, запустили службы и извлекли NTDS.dit. Это продемонстрировало проверенный путь от пользовательской точки опоры до подтвержденного контроля над администратором домена.
Полный проверенный путь атаки вместе с его потенциальным последующим воздействием выглядит следующим образом:
BlueHammer не зависит от повреждения памяти. Вместо этого он интегрирует несколько компонентов, включая облачные файлы, обратные вызовы, оппортунистические блокировки, символические ссылки диспетчера объектов, интерфейс локального обновления RPC Защитника, автономный парсинг реестра и операции SAMR, причем каждый этап подготавливает следующий. Мы реконструировали цепочку путем обратного проектирования оригинального бинарного файла FunnyApp.exe в IDA Pro и его трассировки в x64dbg. В следующих разделах описываются восемь этапов, проверенный путь постинфомационной эксплуатации и то, как Qualys TruConfirm безопасно проверяет уязвимую среду клиентов до того, как злоумышленник достигнет деструктивных стадий.
Тестовая среда, использованная для данного анализа:
- Бинарный файл PoC: FunnyApp.exe (SHA-256: f4ffef4204880031a6a532ff5c1b5686e6a301c365f492071c1d462fa5b6b4a0)
- Хост: DESKTOP38, Windows 11 Pro 21H2, сборка ОС 22000.2295
- Платформа Защитника: 4.18.2104.10 | Движок: 1.1.17300.4 | Аналитика безопасности: 1.321.69.0
- Защита в реальном времени: включена
В этой статье рассматриваются два различных тестовых контекста. Обратное проектирование и комплексная отладка выполнялись на DESKTOP38 с использованием оригинального, неизмененного PoC FunnyApp.exe, хэш SHA-256 которого указан выше. Данные TruConfirm, представленные далее, были собраны на объекте проверки BlackHat2-CVE-2026-33825, в котором использовался модифицированный неразрушающий PoC. Этот процесс проверки останавливается до выполнения таких действий, как: извлечение SAM, изменение паролей, создание служб, восстановление учетных данных или выполнение командной оболочки.
Оценка эксплойта
Подход BlueHammer к определению эксплойтабельности адаптирован под каждый отдельный хост. Хотя определение уязвимой версии Защитника указывает на уязвимость, это не гарантирует, что уязвимый путь доступен или что вся цепочка эксплойта может выполниться успешно. Эффективность эксплойта зависит от среды выполнения и факторов окружающей среды, которые могут различаться на схожих конечных точках.
Анализ начинается с рассмотрения точки зрения злоумышленника, особенно его возможности выполнять код от имени стандартного пользователя. Оценивается несколько критических факторов, включая версию платформы Защитника, состояние WinDefend и его защиты в реальном времени, наличие необходимых драйверов фильтров, доступность теневого копирования томов и наличие ожидающих обновления сигнатур Защитника. Он также проверяет, доступны ли пути обновления CloudFilter и Defender в зависимости от текущего уровня привилегий.
В оцениваемом случае версия платформы Защитника 4.18.2104.10 соответствовала всем необходимым условиям. Оригинальный PoC продемонстрировал завершение всех восьми этапов эксплойта, получение оболочки SYSTEM, извлечение учетных данных администратора домена из LSASS и аутентификацию на контроллере домена через pass-the-hash. Это подтвердило не только то, что на хосте запущена уязвимая версия, но и то, что весь процесс эксплойта работает корректно в рамках его актуальной конфигурации и состояния системы.
С другой стороны, TruConfirm применяет проактивную стратегию в клиентских средах. Он начинает процесс с проверки наличия всех необходимых факторов окружающей среды. После этого он задействует модифицированный рабочий процесс имитации атак и взлома Qualys (Breach and Attack Simulation) для воспроизведения только неразрушающих аспектов эксплойта. Этот шаг имеет решающее значение для подтверждения доступности критического примитива CloudFilter. Процесс проверки фокусируется на соответствующих действиях на этапах 2 и 3, обеспечивая заморозку Защитника и чистый сброс Защитника. Он не выполняет потенциально опасные действия, такие как извлечение данных SAM, сброс паролей, создание службы, восстановление учетных данных, получение оболочки SYSTEM или воспроизведение пути компрометации домена, продемонстрированного в оригинальном PoC. Конечная точка получает статус «Эксплойт подтвержден» только тогда, когда она успешно проходит проверки среды и валидацию. Этот тщательный подход дает более веские доказательства для конкретного хоста, чем просто обнаружение версии, и при этом позволяет избежать выполнения деструктивных фаз и фаз постинфомационной эксплуатации оригинального PoC.
Этап 0 — Предварительная проверка обновлений Windows
Эксплойт начинается с запроса к стандартному COM-интерфейсу Microsoft.Update.Session для определения наличия ожидающего обновления сигнатур Defender. Он целенаправленно фильтрует результаты Windows Update (WU) по идентификатору категории E0789628-CE08-4437-BE74-2495B842F43B, который связан с обновлениями определений. Этот GUID служит отличительным идентификатором в секции .rdata, фактически выполняя роль сигнатуры для поиска. Если ожидающих обновлений нет, эксплойт завершает работу без каких-либо дальнейших действий. Для успешного перехвата процесса потребления обновлений на последующих этапах наличие ожидающего обновления имеет решающее значение. Кроме того, эта первичная проверка служит фильтром для мягких целей, поскольку системы с агрессивными расписаниями обновлений обычно не удерживают ожидающие обновления достаточно долго для того, чтобы эксплойт мог сработать.
Этап 1 — Загрузка подписанного пакета и извлечение CAB
Эксплойт начинается с загрузки подписанного исполняемого файла Microsoft mpam-fex64.exe из fwlink и извлечения из него внедренного CAB-пайлоада без сохранения на диск. Он имитирует User-Agent Chrome/141.0.0.0 в HTTPS-запросе, что нетипично для нативного бинарного файла, и считывает ответ в буфер с помощью InternetReadFile. Затем GetCabFileFromBuff извлекает CAB-пайлоад из исполняемого файла, определяя расположение его заголовочной части, и создает пользовательские回调-функции (обратные вызовы) ввода-вывода для обработки файла. В результате извлекаются пять файлов: mpasbase.vdm, mpavdlta.vdm и mpengine.dll. В самом эксплойте файл mpasbase.vdm заменяется на вредоносную версию, в то время как остальные четыре остаются побайтово идентичными легитимным подписанным оригиналам. Эта тактика помогает эксплойту обходить обнаружение, позволяя проверкам сигнатур механизма обновления Windows Defender проходить успешно.
Этап 2 — Сигнализация через oplock (оппортунистическую блокировку) на RstrtMgr.dll
Эксплойт опирается на точное определение времени, чтобы зафиксировать момент, когда Defender начинает сканирование файла, размещенного им в системе. Поскольку официального API для этого не существует, эксплойт искусно комбинирует два документированных метода. Он инициирует пакетный oplock для RstrtMgr.dll — системной DLL, к которой часто обращаются в процессе сканирования Defender, а затем создает тестовый файл EICAR для запуска сканирования.
Для реализации этого эксплойт сначала записывает файл EICAR и открывает RstrtMgr.dll с флагом FILE_FLAG_OVERLAPPED. Затем он запрашивает пакетный oplock с помощью вызова DeviceIoControl с кодом управления 0x90008. Открытие файла EICAR инициирует сканирование Defender в реальном времени. После этого эксплойт использует GetOverlappedResult, чтобы дождаться момента, когда процесс сканирования Defender затронет RstrtMgr.dll и освободит oplock, что сигнализирует о начале сканирования. В фоновом режиме поток с именем ShadowCopyFinderThread отслеживает пространство имен NT-объектов на предмет любых снимков VSS, которые Defender может создавать во время сканирования. Поскольку Defender часто использует теневые копии, эксплойт перехватывает их путь для дальнейшего использования. В контексте эксплойта, при возникновении определенного условия, эксплойт захватывает путь VSS-копии, обычно обозначаемый как \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN. Этот захваченный путь затем сохраняется для последующего использования на этапе 6 эксплойта. На этом этапе эксплойт манипулирует процессом, перенаправляя доступ к файлам Windows Defender к файлу Диспетчера учетных записей безопасности (SAM) системы, расположенному по адресу \??\<fullvsspath>\Windows\System32\Config\SAM на ранее захваченной теневой копии.
Чтобы избежать обнаружения, строка EICAR хранится в обратном порядке в секции .rdata бинарного файла и снова переворачивается во время выполнения, гарантируя, что бинарный файл не вызовет срабатывание сигнатурного детектирования EICAR в Defender. Примечательно, что код FSCTL 0x90008, используемый для установления oplock, появляется вновь на более поздних этапах эксплойта, что указывает на сильный признак: в одном бинарном файле присутствуют два независимых пакетных oplock.
Этап 3 — Заморозка MsMpEng.exe с помощью обратного вызова CloudFilter
Эксплойт на этапе 3 нацелен на движок сканирования Windows Defender, MsMpEng.exe, переводя его в контролируемое состояние ожидания. Эта манипуляция позволяет эксплойту выполнять файловые операции без вмешательства со стороны Defender. Техника использует поведение подсистемы Cloud Files, в частности минифильтра CloudFilter (cldflt.sys), который намеренно блокирует поток в режиме ядра в ожидании завершения от поставщика синхронизации в пользовательском режиме. Преднамеренное ожидание в процессе позволяет облачным провайдерам, таким как OneDrive, выполнять сетевые операции ввода-вывода, необходимые для получения и подготовки файла перед доставкой его данных запрашивающей стороне. Важно отметить, что предопределенного лимита длительности этого ожидания не существует.
Для реализации этой стратегии эксплойт регистрирует себя в качестве провайдера CloudFilter для контролируемого им каталога корневой синхронизации и сбрасывает в этот каталог поддельный исполняемый файл с именем foo.exe. Когда сканер реального времени MsMpEng обнаруживает исполняемый файл foo.exe, приоритетный для сканирования Defender, драйвер cldflt.sys активирует обратный вызов для получения заполнителей (placeholders) в процессе, связанном с эксплойтом. В этот момент эксплойт проверяет, совпадает ли идентификатор процесса вызвавшего абонента (CF_PROCESS_INFO) с идентификатором процесса службы WinDefend, полученным через QueryServiceStatusEx. Если они совпадают, обратный вызов останавливает операцию с помощью события, управляемого рабочим потоком эксплойта. Это эффективно удерживает MsMpEng в зависшем состоянии ожидания cldflt.sys, позволяя эксплойту продолжить работу без обнаружения со стороны Windows Defender.
Рабочий поток инициирует пакетный oplock для назначенного файла блокировки в корне синхронизации, а затем сигнализирует о событии освобождения. Во время этого процесса обратный вызов, сохраняющий контроль над MsMpEng, вызывает функцию CfExecute, используя заполнитель для файла блокировки. Компонент cldflt.sys затем обрабатывает вызов CfExecute, обращается к файлу блокировки и разрывает oplock, позволяя MsMpEng продолжить свою работу. Вся последовательность циклов происходит в рамках одного кругового пути CfExecute, что позволяет эксплойту выполнять операции этапа 4 и этапа 6 без помех со стороны Defender.
MsMpEng.exe работает как защищенный облегченный процесс (Protected Process Light, PPL) с защитой PsProtectedSignerAntimalware, что мешает любым наблюдателям в пользовательском режиме подключать отладчики или исследовать его потоки. Хотя Диспетчер задач отображает процесс как «Работающий» (Running), это может вводить в заблуждение, поскольку его основной поток сканирования может быть остановлен внутри cldflt.sys, а состояния ожидания для каждого отдельного потока не видны пользователям с ограниченными привилегиями. В то время как PPL защищает процесс, эксплойты могут обратить его против самой системы. Ключевое действие в данном контексте выполняется с помощью одной инструкции SetEvent, которая освобождает обратный вызов, как подробно показано на рисунке 7.
Microsoft определила версию платформы антивируса Defender 4.18.26030.3011 в качестве порога для устранения CVE-2026-33825. Конечные точки, работающие на этой или любой более поздней версии, защищены от уязвимого пути Defender, используемого BlueHammer, что эффективно предотвращает доступ к Этапу 4 атаки.
Этап 4 — Подготовка поддельных файлов определений
На этапе 4 эксплойта злоумышленник подготавливает файлы обновлений под своим управлением, создавая путь диспетчера объектов NT со структурой \Sessions\<N>\BaseNamedObjects\<GUID>. Этот путь устанавливается с помощью функции NtCreateDirectoryObjectEx. Внутри этого каталога создается символическая ссылка с именем WDUpdateDirectory, указывающая на временное расположение в файловой системе, где хранятся файлы обновлений из памяти с этапа 1. Этот подход имеет решающее значение, поскольку на этапе 6 злоумышленник незаметно заменит символическую ссылку после того, как Defender обратится к ней.
Файлы поэтапного обновления спроектированы так, чтобы быть побитово идентичными оригинальным подписанным версиям Microsoft, за исключением mpasbase.vdm, который заменяется вредоносной версией. Остальные файлы сохраняют свои действительные подписи, гарантируя, что проверки валидации подписей Defender продолжат завершаться успешно. Важно отметить, что эти файлы обновлений отличаются от приманки foo.exe, использовавшейся на этапе 3, которая была предназначена для вовлечения MsMpEng в обратный вызов CloudFilter, приводящий к его зависанию. Вместо этого здесь основное внимание уделяется подлинным файлам обновления сигнатур, которые Defender в конечном итоге будет использовать.
Этап 5 — RPC к механизму обновлений Defender
На этапе 5 процесса эксплойта вредоносные файлы обновлений доставляются в Windows Defender через его локальный механизм обновлений с использованием интерфейса RPC. Этот интерфейс, а именно MpAmDefinitionUpdateAPI, обычно используется для легитимных обновлений сигнатур Defender и управляется MsMpEng.exe при содействии MpSvc.dll.
Эксплойт создает рабочий поток WDCallerThread, который привязывается к интерфейсу RPC с использованием конкретного UUID по транспорту ncalrpc. Он нацелен на конечную точку, обозначенную как IMpService77BDAF73-B396-481F-9042-AD358843EC24, и вызывает процедуру 42 под названием ServerMpUpdateEngineSignature. В скомпилированном бинарном файле эксплойта соответствующая сгенерированная MIDL заглушка для этой процедуры была оптимизирована, а псевдокод отражает прямой вызов основной функции.
Примечательно, что аргумент, передаваемый этой процедуре, не является типичным путем файловой системы; вместо этого он отформатирован как путь диспетчера объектов NT, ведущий к промежуточному каталогу, настроенному на этапе 4 эксплойта. Этот путь может быть представлен как \\?\GLOBALROOT\Sessions\<N>\BaseNamedObjects\<GUID>\WDUpdateDirectory. Когда Defender обрабатывает эти файлы, он успешно проверяет их подписи, за исключением измененного mpasbase.vdm, который замаскирован под подлинный файл Microsoft.
Поскольку Defender создает новую копию файлов, принадлежащую SYSTEM, в подкаталоге C:\ProgramData\Microsoft\Windows Defender\Definition Updates\, эксплойт активно отслеживает этот каталог с помощью функции ReadDirectoryChangesW. Он фиксирует имя нового подкаталога сразу после завершения операции копирования Defender, что позволяет эксплойту продолжить выполнение своих задач.
Этап 6 — Состязание символических ссылок, синхронизированное с помощью oplock
Этап 6 представляет собой развитие этапа 5, превращая произвольную запись файлов от имени SYSTEM в целевое чтение файлов. В частности, он сосредоточен на доступе куста реестра SAM из теневой копии VSS, созданной на этапе 2. После этапа 5 Windows Defender создает новый каталог для обновлений сигнатур и заполняет его принадлежащими SYSTEM версиями подготовленных файлов. Перед загрузкой этих новых сигнатур Defender повторно открывает файл mpasbase.vdm из WDUpdateDirectory для проверки его содержимого. Это второе открытие имеет решающее значение, так как оно становится мишенью для состояния гонки.
В этой настройке пакетная блокировка операций (oplock) размещается на текущем mpasbase.vdm, расположенном в промежуточном каталоге эксплойта. К файлу осуществляется доступ с опцией FILE_DELETE_ON_CLOSE через NtCreateFile, в результате чего он исчезает сразу после закрытия дескриптора, не оставляя криминалистических следов. Впоследствии DeviceIoControl активирует пакетный oplock с использованием управляющего кода FSCTL 0x90008, того же управляющего кода, который использовался на этапе 2. Затем процесс использует GetOverlappedResult для блокировки до тех пор, пока второе открытие файла со стороны Defender не прервет oplock.
При срыве блокировки oplock операция ввода-вывода Defender временно приостанавливается в процессе открытия. Ядро вмешивается, прерывая oplock, и ожидает, пока текущий владелец дескриптора закроет его, прежде чем позволить операции Defender продолжиться. Эта ситуация создает краткую возможность, обычно длящуюся всего несколько сотен микросекунд, для эксплойта выполнить замену символической ссылки.
В течение этого узкого временного окна эксплойт закрывает существующий дескриптор симлинка WDUpdateDirectory. Затем он создает новый симлинк, указывающий непосредственно на каталог диспетчера объектов, и внедряет новую символическую ссылку mpasbase.vdm внутри этого каталога. Эта ссылка ведет к файлу SAM, расположенному в каталоге Windows System32 на теневой копии этапа 2.
Как только вызывается функция CloseHandle(FileHandle), она снимает состояние паузы процесса открытия Defender. В этот момент Defender обращается к кусту SAM, используя свой токен SYSTEM через только что замененную цепочку симлинков. Поскольку операция Defender выполняется в рамках транзакции, созданной эксплойтом, эксплойт может вызвать CreateFileTransacted с тем же дескриптором транзакции, чтобы открыть тот же файл. Оба дескриптора распознают куст SAM, к которому Defender только что обратился как SYSTEM, что позволяет дескриптору эксплойта перехватить утечку дескриптора SAM по мере перехода к этапу 7.
Этап 7 — Парсинг SAM до командной оболочки SYSTEM
Заключительный этап эксплойта, этап 7, служит кульминацией предыдущих этапов, предоставляя доступ к важнейшему артефакту: утечке дескриптора, который позволяет получить доступ к кусту реестра SAM системы на томовой теневой копии (VSS). Этот процесс обходит стандартный API реестра, который обычно требует монтирования куста под HKLM или HKCU. Вместо этого эксплойт полагается на автономный API реестра в offreg.dll, в частности на функцию OROpenHiveByHandle, для взаимодействия с кустом напрямую из байтов его файла.
Кроме того, диспетчер учетных записей безопасности (SAM) шифрует NT-хеш каждой учетной записи с помощью уникального для каждой машины ключа syskey. Этот ключ syskey производят из 16-байтового значения, известного как загрузочный ключ LSA (LSA bootkey), который распределен по четырем конкретным именам классов подразделов реестра, расположенным в HKLM\SYSTEM\CurrentControlSet\Control\Lsa. Доступ к этим именам классов требует использования RegQueryInfoKey, так как они не видны при стандартных запросах реестра. Функция GetLSASecretKey обходит эти четыре подраздела, извлекает их имена классов, декодирует их из шестнадцатеричного формата и применяет определенную перестановку для восстановления 16-байтового загрузочного ключа.
Процесс начинается с функции UnprotectPasswordEncryptionKey, которая извлекает зашифрованный большой двоичный объект syskey из SAM\Domains\Account\F с использованием Windows CryptoAPI. Это включает в себя получение «Microsoft Enhanced RSA and AES Cryptographic Provider» для импорта промежуточного ключа, производного от DES, с последующим выполнением 32-байтового дешифрования AES-CBC. Этот метод является стандартным для Windows 10 и 11 и предназначен для использования цепочки шифрования, связанной с этими системами, с обходом более старых версий, в которых для ключей syskey использовался только DES. После получения syskey эксплойт обращается к базе данных SAM по адресу SAM\Domains\Account\Users\<RID>, анализируя ее записи для извлечения зашифрованных NT-хешей для каждого пользователя. Затем функция UnprotectNTHash расшифровывает эти хеши, используя восстановленный syskey и RID учетной записи в качестве соли. Во время тестирования учетная запись администратора с RID 1001 показала открытый текст NT-хеша 8846f7eaee8fb117ad06bdd830b7586c и соответствующий MD4-хеш для пароля "password."
Следующий этап, называемый «подменой» (swap), происходит в два шага. Функция CalculateNTLMHash вызывается с открытым паролем "$PWNed666!!!WDFAIL", что приводит к получению MD4-хеша для замены существующего NT-хеша. Во время выполнения функции CalculateNTLMHash регистр RCX напрямую ссылается на определенный набор байтов открытого текста. Эти байты представлены в виде строки, которая также появляется в качестве литерала в бинарной секции .rdata. Эта строка выделяется как важный индикатор компрометации (IoC) во всем бинарном файле.
При изменении пароля пользователя вызывается функция ChangeUserPassword с определенными параметрами: имя целевой учетной записи в RCX, расшифрованный старый NT-хеш в RDX и вновь сгенерированный NT-хеш. В точке входа этой функции имя учетной записи "admin" сохраняется в RCX, в то время как R12 содержит расшифрованный старый NT-хеш из Диспетчера учетных записей безопасности (SAM). Этот хеш отображается в шестнадцатеричном формате, а именно "8846f7eaee8fb117ad06bdd830b7586c."
Внутри ChangeUserPassword вызывается функция SamiChangePasswordUser, которая заменяет сохраненный NT-хеш учетной записи администратора. Примечательным аспектом этого процесса является то, что для авторизации SamiChangePasswordUser требует старый NT-хеш, а не пароль в открытом виде. Поскольку эксплойт уже получил необходимый старый хеш в результате расшифрования SAM, он соответствует критериям авторизации.
Тем не менее, важно отметить, что простое извлечение SAM не предоставляет повышенных привилегий, так как вы не можете использовать исходный NT-хеш для входа в систему. Кроме того, сброс пароля обычно требует прав администратора. Только когда эти два действия выполняются вместе в указанном порядке, закэшированный хеш локального администратора может быть преобразован в рабочий пароль по выбору эксплойта.
После сброса пароля администратора эксплойт использует новые учетные данные для входа в систему в качестве администратора. Затем он извлекает связанный токен с повышенными привилегиями UAC с помощью функции GetTokenInformation(TokenLinkedToken) и олицетворяет (impersonate) администратора. Получив административные полномочия, эксплойт обращается к Диспетчеру управления службами (Service Control Manager) и создает временную службу. Этой службе присваивается случайное имя GUID, а ее ImagePath связывается с собственным бинарным файлом эксплойта, что позволяет ей успешно запускться. Диспетчер управления службами (SCM) по умолчанию запускает службу от имени LocalSystem.
В сценарии реализации эксплойта безопасности по мере развертывания атаки на рабочем столе появляются два экземпляра процесса conhost.exe. Один процесс работает под учетной записью NT AUTHORITY\SYSTEM, происходя из компонента эксплойта на стороне SYSTEM, в то время как другой работает под учетной записью взломанного администратора, инициированный исходным процессом через CreateProcessWithLogonW с использованием измененных учетных данных администратора.
