PhantomRPC: новая техника повышения привилегий в Windows RPC

Вступление

Межпроцессное взаимодействие (IPC) — одна из наиболее сложных технологий в операционной системе Windows. В основе этой экосистемы лежит механизм удаленного вызова процедур (RPC), который может функционировать как самостоятельный канал связи или выступать базовым транспортным уровнем для более продвинутых технологий межпроцессного взаимодействия. Из-за своей сложности и широкой распространенности механизм RPC всегда был источником множества проблем безопасности. За прошедшие годы исследователи обнаружили многочисленные уязвимости в службах, использующих RPC, — от локального повышения привилегий до полноценного удаленного выполнения кода.

В данном исследовании я раскрою детали новой уязвимости в архитектуре RPC, позволяющей реализовать ранее неизвестную технику локального повышения привилегий во всех версиях Windows. Эта техника позволяет процессам с привилегиями имперсонации повышать свои права до уровня SYSTEM. Она фундаментально отличается от методов, используемых в известном семействе эксплойтов Potato. Хотя компании Microsoft известно об этой уязвимости, на момент публикации патча нет.

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

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

Технология MSRPC

Удаленный вызов процедур Microsoft (MSRPC) — это технология, используемая в Windows для организации взаимодействия между двумя процессами. Она позволяет одному процессу вызывать функции из кода другого процесса, даже если они существуют в разных контекстах выполнения.

Для лучшего понимания механизма рассмотрим схему ниже.

Предположим, у нас имеется хост A с двумя запущенными процессами — А и B. Процессу B понадобилась функция, которая находится внутри процесса А. Для такого взаимодействия в Windows предусмотрена архитектура удаленного вызова процедур (RPC), основанная на клиент-серверной модели. В этой модели процесс A выступает в роли RPC-сервера, предоставляющего доступ к части своих функций через интерфейс A. Каждый RPC-интерфейс однозначно идентифицируется с помощью 128-битного универсального уникального идентификатора (UUID). По этим идентификаторам операционная система различает отдельные интерфейсы.

Интерфейс определяет, какие именно функции может удаленно вызывать RPC-клиент, в роли которого выступает процесс B. В данном примере интерфейс предоставляет две функции: Fun1 и Fun2.

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

Примеры:

• Для TCP конечной точкой является TCP-порт.
• Для SMB взаимодействие проходит через именованный канал.
• Для ALPC конечной точкой служит ALPC-порт.

Каждый транспортный механизм связан с соответствующей последовательностью протоколов RPC. Примеры:

• ncacn_ip_tcp используется для RPC поверх TCP;
• ncacn_np используется для RPC поверх именованных каналов;
• ncalrpc используется для RPC поверх ALPC.

В данном исследовании я буду рассматривать именно ALPC как транспортный механизм RPC. ALPC (Advanced Local Procedure Call) — это механизм межпроцессного взаимодействия в Windows, который был до MSRPC. В современных системах ALPC может использоваться как эффективный транспортный уровень RPC для взаимодействия процессов на одной машине.

Для простоты канал связи, основанный на порту ALPC, можно рассматривать как файл, в который процессы отправляют (записывают) сообщения и из которого они их получают (считывают).

Для вызова удаленной функции (например, Fun1) клиент формирует RPC-запрос. Он должен содержать такую важную информацию, как UUID интерфейса, последовательность протоколов, конечная точка и идентификатор вызываемой функции. В RPC функции вызываются не по имени, а по числовому идентификатору — номеру операции (OPNUM). Запрос также может включать дополнительные структуры, например данные, связанные с безопасностью, в зависимости от требований вызова.

Механизм имперсонации в среде Windows

В Windows механизм имперсонации позволяет службе временно выполнять операции в контексте безопасности другого пользователя. Например, службе может потребоваться доступ к файлу, принадлежащему пользователю, в ходе выполнения определенной операции. Службе, действующей от имени вызывающего пользователя, система предоставляет необходимые права доступа к этому файлу, даже если у самой службы таких прав нет. Подробнее об имперсонации вы можете прочитать в книге Windows Security Internals («Внутренние компоненты системы безопасности Windows») Джеймса Форшоу.

В рамках данного исследования рассматривается только исперсонация в RPC. В этом контексте участники процесса — это не служба и пользователь, а клиент и сервер. RPC-сервер может временно действовать от имени клиента, инициировавшего запрос.

Для выполнения этой операции RPC-сервер может вызвать API-функцию RpcImpersonateClient, которая заставляет поток сервера выполняться в контексте безопасности клиента.

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

Эти параметры входят в число настроек SQOS (Security Quality of Service) и задаются с помощью структуры SECURITY_QUALITY_OF_SERVICE.

Как видно, эта структура содержит поле уровня имперсонации (SECURITY_IMPERSONATION_LEVEL), которое определяет широту полномочий сервера, когда он действует от имени клиента. Уровни имперсонации варьируются от Anonymous (Анонимный), при котором сервер не может действовать от имени клиента, до Impersonation (Имперсонация) и Delegation (Делегирование), позволяющих серверу полноценно действовать от имени клиента.

При этом не каждый серверный процесс может действовать от имени клиента. Если бы любое приложение могло свободно пользоваться имперсонацией, это создало бы серьезные риски для безопасности. Чтобы это предотвратить, Windows требует наличия специальной привилегии SeImpersonatePrivilege. Только процессы, обладающие этой привилегией, могут действовать от имени клиента.

По умолчанию SeImpersonatePrivilege предоставляется определенным служебным учетным записям, таким как Local Service и Network Service.

Взаимодействие служб Group Policy и TermService

Служба Group Policy Client (gpsvc) — основная служба Windows, отвечающая за применение и принудительное выполнение параметров групповой политики в системе. Служба работает от имени учетной записи SYSTEM внутри процесса svchost.exe.

Для обновления групповой политики Windows использует утилиту gpupdate.exe. Ее можно запустить с параметром /force, чтобы принудительно обновить все параметры групповой политики. В процессе работы этот исполняемый файл взаимодействует со службой Group Policy, которая координирует процесс обновления.

На одном из этапов обновления служба Group Policy устанавливает связь со службой TermService через RPC.

TermService обеспечивает функциональность удаленного рабочего стола. По умолчанию эта служба не запущена: администратор может сделать это вручную, включив доступ по RDP. При активации она разворачивает RPC-сервер с набором интерфейсов и конечных точек. TermService работает под учетной записью NT AUTHORITY\Network Service.

При выполнении команды gpupdate /force служба Group Policy инициирует RPC-вызов к TermService со следующими параметрами:

• UUID: bde95fdf-eee0-45de-9e12-e5a61cd0d4fe
• Конечная точка: ncalrpc:[TermSrvApi]
• Функция: void Proc8(int)

Но поскольку служба TermService по умолчанию отключена, RPC-вызов завершается неудачно и внутри библиотеки среды выполнения RPC (rpcrt4.dll) возникает исключение. Возвращается следующая ошибка:

• 0x800706BA (RPC_S_SERVER_UNAVAILABLE, 1722)

Ошибка означает, что RPC-клиент не смог установить соединение с целевым сервером.

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

Функция NtAlpcConnectPort отвечает за подключение к заданному порту ALPC и возвращает дескриптор, используемый клиентом для последующего взаимодействия. Она принимает несколько параметров.

Первые два из них:

• указатель на возвращаемый дескриптор порта;
• имя порта ALPC в виде ASCII-строки.

Другим важным аргументом является PortAttributes — структура типа ALPC_PORT_ATTRIBUTES. Внутри нее содержится структура SECURITY_QUALITY_OF_SERVICE, которая, как уже упоминалось, определяет уровень имперсонации, используемый для соединения.

Последний интересующий нас параметр — RequiredServerSid, который задает ожидаемую идентичность целевого серверного процесса. Эта идентичность определяется по идентификатору безопасности (SID).

Если проанализировать этот вызов, можно увидеть, что служба Group Policy пытается подключиться к RPC-серверу, используя уровень имперсонации Impersonation, и ожидает, что удаленный сервер работает от имени учетной записи Network Service. В этом нет ничего странного, поскольку TermService обычно функционирует под учетной записью Network Service.

Собрав воедино всю известную нам информацию, можно выстроить схему взаимодействия между TermService и gpsvc.

Пока что система работает как задумано. RPC-клиент пытается подключиться к RPC-серверу, который недоступен, что приводит к исключению, обрабатываемому средой выполнения RPC.

Однако возникает вопрос: что произойдет, если злоумышленник скомпрометирует службу, работающую под учетной записью Network Service, и попытается сымитировать такой же RPC-сервер, как у службы TermService?

Может ли атакующий развернуть поддельный RPC-сервер с той же конечной точкой?

Если это возможно, позволит ли среда выполнения RPC, чтобы клиент подключился к такому нелегитимному серверу?

И какие действия сможет выполнить злоумышленник в случае успешного установления соединения?

Принуждение службы Group Policy

Чтобы лучше понять, к чему может привести описанное поведение системы, рассмотрим потенциальный сценарий атаки.

Предположим, что злоумышленник скомпрометировал службу, работающую в системе под учетной записью Network Service, например сервер IIS. Обладая таким уровнем доступа, злоумышленник может развернуть вредоносный RPC-сервер.

Этот сервер должен имитировать RPC-интерфейс службы удаленных рабочих столов (TermService). В частности, он должен использовать тот же UUID RPC-интерфейса и то же имя конечной точки: TermSrvApi. После развертывания вредоносный сервер начинает прослушивать RPC-запросы, которые в обычных условиях направлялись бы легитимной службе RDP.

Далее злоумышленник инициирует обновление политик с помощью команды gpupdate.exe /force, чтобы принудить службу Group Policy к выполнению требуемого условия. В результате служба Group Policy Client (gpsvc), работающая от имени учетной записи SYSTEM, выполняет ранее описанный RPC-вызов. Напомним, данный RPC-вызов выполняется с высоким уровнем исперсонации — Impersonation.

Когда поддельный RPC-сервер злоумышленника получает запрос, он вызывает API-функцию RpcImpersonateClient, которая позволяет потоку сервера использовать контекст безопасности вызывающего клиента, в данном случае — SYSTEM.

В конечном счете злоумышленник повышает привилегии с уровня Network Service до SYSTEM. И наш проверочный эксплойт демонстрирует повышение привилегий путем запуска командной строки с правами SYSTEM.

Когда данный сценарий атаки рассматривался изначально, он носил сугубо теоретический характер. Но эксперимент с вредоносным RPC-сервером подтвердил, что Windows позволяет развернуть и запустить такой сервер, а среда выполнения RPC разрешает клиенту подключаться к поддельной конечной точке. Эта техника позволяет повысить привилегии с уровня Network Service до SYSTEM. Тем не менее для успешной атаки в системе должна быть применена хотя бы одна групповая политика.

Схема архитектуры RPC

Дальнейший анализ показал, что многие службы Windows пытаются обратиться к TermService через RPC, и такие вызовы часто инициируются из библиотеки winsta.dll, выступающей в роли RPC-клиента.

Процессы Windows вызывают API-функции winsta.dll, внутренняя реализация которых полагается на RPC-взаимодействие с TermService. Подобная модель характерна для Windows: вызовы экспортируемых функций многих системных DLL фактически перенаправляются через RPC к другим компонентам системы.

При этом, по всей видимости, среда выполнения RPC (rpcrt4.dll) никак не проверяет легитимность RPC-серверов. Более того, в Windows допускается, чтобы другой процесс развернул RPC-сервер с той же конечной точкой, что и у легитимной службы.

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

Идентификация RPC-вызовов к недоступным серверам

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

В частности, требуется фиксировать такие ключевые метаданные RPC:

• UUID интерфейса, конечную точку и идентификатор OPNUM;
• уровень имперсонации и код состояния RPC;
• уровень привилегий клиентского процесса, имя процесса и путь к модулю.

Это критически важные сведения, с которыми можно реконструировать RPC-взаимодействие, имитировать ожидаемый RPC-сервер и понять, как именно инициируется вызов.

Подходящая платформа с такими возможностями — трассировка событий Windows (ETW). ETW — это встроенная в Windows система логирования, фиксирующая в реальном времени события как в режиме ядра, так и в пользовательском режиме.

Для сбора данных ETW в Windows предусмотрен инструмент logman, позволяющий создавать сеансы трассировки, выбирать поставщиков событий и настраивать уровень детализации отслеживания. Результаты его работы сохраняются в файле формата .etl, который затем можно изучить с помощью Event Viewer или других инструментов для анализа ETW.

ETW обеспечивает глубокую видимость RPC-активности без необходимости модификации приложений. С его помощью можно получить детализированную информацию об RPC, включая:

• привязки RPC;
• конечные точки;
• UUID интерфейсов;
• детали аутентификации;
• поток вызовов и их время;
• коды состояния RPC.

Однако меня интересуют не все RPC-события, а только неудачные RPC-вызовы, в частности те, которые возвращают исключение RPC_S_SERVER_UNAVAILABLE.

Чтобы зафиксированное событие считалось релевантным для исследования, исключение должно соответствовать двум условиям:

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

Чтобы провести такую проверку, нельзя полагаться исключительно на необработанные выходные данные ETW — они содержат тысячи событий и вручную фильтровать их стандартными инструментами не очень эффективно. Этот процесс необходимо автоматизировать. Рабочий процесс, представленный ниже, позволяет эффективно отобрать и извлечь только те события, которые релевантны для анализа.

После генерации логов в формате .etl их можно конвертировать в JSON с помощью утилиты etw2json или аналогичного инструмента. Формат JSON намного удобнее обрабатывать программным методом. Для этого можно воспользоваться Python-скриптом, который отфильтровывает и извлекает необходимую информацию.

Процесс фильтрации начинается с поиска события с ID 1, соответствующего завершению RPC-операции. Это событие означает, что RPC-клиент завершил вызов и его результат стал доступен. Из него можно извлечь следующую полезную информацию:

• код состояния;
• имя клиентского процесса;
• идентификатор клиентского процесса (PID);
• конечную точку.

После извлечения кода состояния выполняется фильтрация по значению RPC_S_SERVER_UNAVAILABLE, которое указывает на RPC-вызовы, где целевой сервер был недоступен. Именно такие события представляют интерес для дальнейшего анализа.

Однако событие с ID 1 не содержит всех необходимых метаданных RPC. Чтобы получить недостающую информацию, его нужно сопоставить с событием с ID 5, которое соответствует началу RPC-операции. Это событие генерируется в момент, когда клиент инициирует RPC-вызов.
Путем сопоставления метаданных событий с ID 1 и ID 5 можно восстановить недостающие детали, включая:

• UUID интерфейса;
• идентификатор OPNUM;
• уровень имперсонации.

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

• название DLL-библиотеки, в которой реализован RPC-интерфейс;
• расположение этой DLL;
• количество процедур, предоставляемых интерфейсом.

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

В конце этого процесса у меня есть полный набор JSON-данных, пригодный для дальнейшего анализа.

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

В моем исследовании использовалось несколько подходов для инициирования подобных событий.

1. Мониторинг RPC-активности во время запуска системыЯ отслеживал RPC-активность в процессе загрузки операционной системы. Во время старта системы инициализируется множество служб, выполняющих различные RPC-вызовы, что повышает вероятность выявить обращения к недоступным серверам.
2. Запуск административных операций
   Я разработал PowerShell-скрипты, выполняющие типовые административные задачи, такие как обновление групповой политики, изменение сетевых настроек или создание новых пользователей. Подобные операции часто инициируют RPC-взаимодействие и могут приводить к возникновению исключений.
3. Намеренное отключение служб
   Поскольку служба удаленного рабочего стола по умолчанию отключена, это натолкнуло меня на мысль, что стоит последовательно отключать дополнительные службы и повторять предыдущие пункты. Таким образом можно выявить RPC-клиенты, которые пытаются подключиться к уже недоступным службам.

Дополнительные пути повышения привилегий

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

Взаимодействие с пользователем: от Edge к RDP

Браузер Microsoft Edge (msedge.exe) установлен в системах Windows по умолчанию. При запуске Edge инициирует RPC-вызов к службе TermService с высоким уровнем имперсонации.

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

Атака основана на том же предположении, что и ранее: злоумышленник уже скомпрометировал процесс, работающий от имени Network Service. В этом контексте атакующий разворачивает поддельный RPC-сервер, имитирующий легитимный RPC-интерфейс TermService.

В отличие от предыдущего сценария, полагающегося на принуждение службы Group Policy к определенным действиям, здесь в этом нет необходимости. Злоумышленнику достаточно дождаться запуска Microsoft Edge пользователем с высокими привилегиями, например администратором.

При запуске Edge RPC-клиент пытается подключиться к ожидаемому RPC-интерфейсу TermService. Поскольку легитимный сервер неактивен, запрос получает поддельный RPC-сервер злоумышленника. Так как RPC-вызов выполняется с высоким уровнем имперсонации, вредоносный сервер может вызвать функцию RpcImpersonateClient и выполнять операции от имени клиентского процесса.

В результате злоумышленник получает возможность действовать от имени клиента с правами администратора и повысить привилегии с Network Service до уровня Administrator.

Фоновые службы: от WDI к RDP

Некоторые фоновые службы Windows периодически выполняют RPC-вызовы к службе RDP без участия пользователя. Одной из них является WdiSystemHost. Служба Diagnostic System Host (WDI) — встроенный компонент Windows, отвечающий за системную диагностику и устранение неполадок. Она работает под учетной записью SYSTEM.

В процессе работы WDI периодически инициирует фоновые RPC-вызовы к службе удаленных рабочих столов (TermService), используя высокий уровень имперсонации. Такие взаимодействия происходят автоматически каждые 5–15 минут, не требуя никакого участия пользователя.

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

Однако в этом сценарии не требуется никаких действий пользователя или применения техник принуждения. После развертывания вредоносного RPC-сервера, имитирующего ожидаемый RPC-интерфейс TermService, злоумышленнику остается дождаться очередного периодического RPC-вызова со стороны WDI. Поскольку запрос выполняется с высоким уровнем имперсонации, вредоносный сервер может вызвать функцию RpcImpersonateClient для выполнения действий от имени вызывающего процесса, что позволяет повысить привилегии до уровня SYSTEM.

Злоупотребление учетной записью Local Service: от ipconfig к DHCP

Другой сценарий связан со службой DHCP Client, которая отвечает за управление операциями DHCP-клиента в системах Windows. Эта служба работает под учетной записью Local Service и включена по умолчанию.

Она предоставляет RPC-сервер с несколькими интерфейсами и конечными точками. Эти интерфейсы часто вызываются системными DLL, нередко с высоким уровнем имперсонации.

В данном сценарии вместо компрометации процесса с привилегиями Network Service предполагается, что злоумышленник получил контроль над процессом, работающим под учетной записью Local Service. Также предполагается, что служба DHCP Client отключена, из-за чего легитимный RPC-сервер недоступен.

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

Получив контроль над процессом с привилегиями Local Service, атакующий разворачивает поддельный RPC-сервер, имитирующий подлинный RPC-интерфейс DHCP Client. После запуска вредоносного сервера злоумышленник дожидается, пока пользователь с высокими привилегиями, например администратор, выполнит команду ipconfig.exe.

При ее запуске внутри системы инициируется RPC-запрос к службе DHCP Client. Поскольку легитимный RPC-сервер неактивен, запрос получает поддельный RPC-сервер злоумышленника. Так как RPC-вызов выполняется с высоким уровнем имперсонации, вредоносный сервер может вызвать функцию RpcImpersonateClient и выполнять операции от имени клиентского процесса.

В результате злоумышленник может повысить привилегии с уровня Local Service до Administrator.

Злоупотребление службой времени

Служба Windows Time (W32Time) отвечает за синхронизацию даты и времени между системами в среде Windows. Эта служба включена по умолчанию и работает под учетной записью Local Service.

Она предоставляет RPC-сервер с двумя конечными точками:

• \PIPE\W32TIME_ALT
• \RPC Control\W32TIME_ALT

Исполняемый файл C:\Windows\System32\w32tm.exe взаимодействует со службой Windows Time через RPC. Но прежде чем подключиться к корректным конечным точкам RPC этой службы, он пытается обратиться к несуществующему именованному каналу \PIPE\W32TIME. В легитимной службе W32Time этот канал недоступен. Но если бы такая конечная точка была, исполняемый файл w32tm.exe попытался бы к ней подключиться.

Этой ситуацией может воспользоваться злоумышленник, развернув поддельный RPC-сервер, который имитирует легитимный RPC-интерфейс службы Windows Time. Вместо легитимных конечных точек такой сервер будет предоставлять доступ к фиктивной точке \PIPE\W32TIME, как показано на схеме ниже.

Как и в предыдущих сценариях, предполагается, что злоумышленник уже получил контроль над процессом, работающим под учетной записью Local Service. Затем ему нужно развернуть поддельный RPC-сервер, реализующий такой же RPC-интерфейс, как у службы Windows Time, но с альтернативной конечной точкой, к которой пытается обратиться w32tm.exe.

После запуска вредоносного сервера злоумышленнику остается дождаться, пока пользователь с высокими привилегиями, например администратор, выполнит команду w32tm.exe. При запуске исполняемый файл пытается подключиться к конечной точке \PIPE\W32TIME. Поскольку она доступна в поддельном сервере, RPC-запрос перенаправляется на него.

Так как RPC-вызов выполняется с высоким уровнем имперсонации, вредоносный сервер сможет выполнять операции от имени клиента, осуществившего вызов. В результате злоумышленник может повысить привилегии с уровня Local Service до Administrator.

Важно отметить, что данный сценарий работает, даже если легитимная служба Windows Time не отключена. Поскольку исполняемый файл пытается подключиться к несуществующей конечной точке, злоумышленнику достаточно создать эту точку в своем вредоносном RPC-сервере.

Раскрытие уязвимости

После обнаружения уязвимости команда Kaspersky Security Services подготовила десятистраничный технический отчет, описывающий проблему и ранее рассмотренные сценарии эксплуатации. Отчет был направлен в Центр реагирования Microsoft (MSRC), чтобы уведомить компанию о проблеме и запросить исправление.

Через 20 дней компания Microsoft ответила, что ее специалисты не считают уязвимость критической. Проблеме присвоили среднюю степень серьезности, в связи с чем немедленное исправление не планируется, CVE назначен не будет, а обращение закрывается без дальнейшего отслеживания.

В обосновании своей оценки Microsoft указала, что для эксплуатации требуется наличие привилегии SeImpersonatePrivilege у исходного процесса. Поскольку без этого зачастую невозможно провести успешную атаку, компания сочла, что проблема не требует срочного устранения.
Команда Kaspersky Security Services уважает оценку Microsoft. Исследование выходит по завершении периода эмбарго. В соответствии с принципами координированного раскрытия уязвимостей из отчета исключены любые детали, которые могут поспособствовать массовой эксплуатации или ускорить ее.

Хронология раскрытия представлена ниже:

• 19 сентября 2025 г. — отчет по уязвимости отправлен в Центр реагирования Microsoft (обращение № 101749)
• 10 октября 2025 г. — получен ответ MSRC: уязвимости присвоена средняя степень серьезности, вознаграждение не полагается, CVE не присвоен, обращение закрыто без дальнейшего отслеживания
• 24 апреля 2026 г. —публикация технического анализа

Меры по обнаружению и защите

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

Тем не менее организации могут принять меры для обнаружения и снижения рисков возможной эксплуатации. Мониторинг на базе ETW с применением описанного мной процесса позволяет ИБ-командам выявить RPC-исключения в своих средах, в частности случаи, когда RPC-клиенты пытаются подключиться к недоступным серверам.

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

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

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

Заключение

Все эксплойты, описанные в данном исследовании, были протестированы в Windows Server 2022 и Windows Server 2025 с последними обновлениями, доступными на момент подачи отчета. Проверочные эксплойты доступны в репозитории исследования. Тем не менее высока вероятность, что данная уязвимость актуальна и для других версий Windows.

Поскольку уязвимость обусловлена архитектурным просчетом, могут существовать сценарии атак и помимо рассмотренных в данном исследовании. Конкретные способы эксплуатации могут различаться от системы к системе в зависимости, например, от установленных компонентов, библиотек DLL, используемых в RPC-взаимодействиях, и доступности соответствующих RPC-серверов.