Большинство людей видят UAC как раздражающее всплывающее окно. Нажал «Да» — программа запустилась с правами. Нажал «Нет» — не запустилась. Кажется, всё понятно. На самом деле за этим диалогом стоит многоуровневый механизм, который работает принципиально по-разному в зависимости от типа учётной записи. И именно это различие определяет, насколько сложно вредоносному коду получить права в вашей системе. https://seberd.ru/25242
Два токена вместо одного
Когда пользователь из группы Administrators входит в Windows, система создаёт не один, а два токена доступа. Первый — полный, со всеми привилегиями группы: доступ к системным объектам, изменение критических параметров, установка драйверов. Второй — отфильтрованный, идентичный токену обычного пользователя без специальных прав.
Explorer, браузер, почта и всё остальное, что открывается при входе, запускается под отфильтрованным токеном. Пользователь фактически работает как стандартный, даже не зная об этом.
Когда появляется запрос на повышение прав, UAC не создаёт новый токен с нуля. Он берёт уже существующий полный токен и запускает под ним отдельный изолированный процесс. Пользователь нажимает «Да» — новый процесс появляется с высоким уровнем целостности. Остальная сессия остаётся нетронутой.
Это разделение защищает от случайной компрометации. Вредоносный код, запущенный в пользовательском контексте, работает с отфильтрованным токеном. Напрямую получить полный токен он не может. Но это не значит, что барьер непробиваем — об этом ниже.
Стандартная учётка: другая механика
У стандартного пользователя ситуация принципиально иная. При входе создаётся только один токен — без административных привилегий. Второго просто нет.
Когда что-то требует повышенных прав, система не переключает токен. Она показывает диалог с полями для ввода учётных данных. Без пароля отдельной административной учётки элевация невозможна вообще.
Вредоносный процесс в сессии стандартного пользователя оказывается в тупике. Нет токена администратора — нет пути к повышению прав через стандартные механизмы Windows. Атака переходит в другой класс: нужно либо перехватить пароль, либо найти уязвимость, которая обходит проверку токена на уровне ядра.
Разница в модели угроз существенная. Под учёткой администратора достаточно одного неосторожного клика. Под стандартной учёткой требуется либо знание пароля, либо эксплойт — а это другой уровень квалификации и другой уровень риска.
Уровни целостности: барьер под барьером
Помимо токенов, каждому процессу присваивается уровень целостности. Это отдельный механизм, который работает независимо от UAC и прав учётной записи.
| Уровень | Описание | Пример |
|---|---|---|
| Low | Изолированные процессы | Браузер в защищённом режиме |
| Medium | Обычные пользовательские задачи | Explorer, офисные приложения |
| High | Системные операции | Процессы после элевации UAC |
| System | Ядро и системные службы | lsass.exe, services.exe |
Процесс не может записать данные в объект с более высоким уровнем целостности, даже если у учётной записи формально есть права. Браузер с уровнем Low не запишет в Program Files, даже если пользователь — администратор.
Проверить текущий уровень легко:
whoami /groups | findstr "Mandatory"
В обычной сессии вы увидите Medium Mandatory Level. После элевации — High Mandatory Level. Разница именно в уровне целостности, а не только в правах учётной записи.
Как это атакуют
UAC — не серебряная пуля. У него есть известные векторы обхода, которые работают без эксплойтов и без запроса прав у пользователя.
Auto-elevation через доверенные COM-объекты. Некоторые системные компоненты Windows имеют флаг автоматической элевации. Вредоносный код может воспользоваться ими как трамплином: запустить доверенный процесс, который сам поднимает права, а внутри него выполнить нужный код. Классический пример — eventvwr.exe, который в старых версиях Windows читал путь к интерпретатору из реестра без проверки.
DLL hijacking в процессах с высоким уровнем целостности. Если привилегированный процесс загружает DLL из директории, куда пользователь имеет право записи, вредоносная библиотека запускается в контексте этого процесса — уже с высокими правами.
Подмена манифеста. Приложения с requireAdministrator в манифесте запрашивают элевацию при запуске. Подделанный манифест заставляет Windows думать, что стандартное приложение требует прав администратора.
Большинство этих техник работают только под учёткой администратора — полный токен уже есть в сессии, нужно лишь его активировать в обход диалога. Под стандартной учёткой они бесполезны: токена нет, активировать нечего.
Настройка через реестр
Поведение UAC управляется несколькими параметрами в HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System:
ConsentPromptBehaviorAdmin — поведение при запросе от администратора:
0— элевация без запроса (опасно, не использовать)1— запрос пароля на защищённом рабочем столе2— запрос пароля без защищённого рабочего стола5— стандартный диалог подтверждения (по умолчанию)
ConsentPromptBehaviorUser — поведение при запросе от стандартного пользователя:
0— автоматический отказ (жёсткий вариант)1— запрос пароля на защищённом рабочем столе3— запрос пароля (по умолчанию)
PromptOnSecureDesktop — при значении 1 диалог появляется на отдельном рабочем столе с затемнением экрана. Это защищает от атак с подменой окон: вредоносный код не может нарисовать поверх диалога UAC свою кнопку «Да».
Проверить текущие настройки:
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" |
Select-Object ConsentPromptBehaviorAdmin, ConsentPromptBehaviorUser, PromptOnSecureDesktop, EnableLUA
Аудит через журнал событий
Каждый запуск процесса фиксируется в журнале при включённом аудите. Событие 4688 содержит уровень целостности нового процесса и токен, под которым он создан.
Get-WinEvent -FilterHashtable @{
LogName = 'Security'
Id = 4688
} | Where-Object {
$_.Message -match 'High Mandatory Level'
} | Select-Object TimeCreated, Message | Select-Object -First 20
Серия событий 4688 с высоким уровнем целостности в нерабочее время — сигнал для расследования. Особенно если инициатор процесса — не стандартный системный компонент.
Стандартная учётка для повседневной работы — не просто рекомендация из учебника. Это конкретное изменение модели угроз: перевод из режима «злоумышленнику достаточно вашего клика» в режим «злоумышленнику нужен ваш пароль».
При проектировании рабочих станций это означает:
Аварийный доступ строится на именованной административной учётке с чёткой принадлежностью. Встроенный Администратор остаётся для Safe Mode и восстановления — там он нужен именно потому, что это аварийный сценарий.
В домене LAPS закрывает вопрос одинаковых паролей локального Администратора. Без него компрометация одной машины через Pass-the-Hash даёт доступ ко всем остальным с тем же паролем.
Аудит строится на событии 4688 с фильтром по высокому уровню целостности. Настроенные оповещения на неожиданные источники элевации дешевле, чем расследование постфактум.
Знание внутренней механики элевации меняет подход к проектированию рабочих станций. Вместо абстрактных рекомендаций «включить контроль» специалист получает инструмент управления токенами и уровнями целостности. Разделение сценариев становится возможным: аварийный доступ использует полный токен, повседневная работа опирается на отфильтрованный вариант, аудит строится на логах создания процессов с высоким уровнем целостности.
Архитектура становится предсказуемой, а не зависимой от всплывающих окон. Настройка параметров под конкретные задачи снижает количество инцидентов, связанных с правами доступа, и упрощает расследование подозрительной активности в корпоративной сети. Модель элевации — не просто интерфейс подтверждения, а многоуровневая система контроля, которая работает на стыке аутентификации, авторизации и изоляции процессов.