Токены. От появления до продвижения в Active Directory
Прежде чем говорить о токенах, мне бы хотелось сказать несколько слов о механизмах, которые пригодятся для понимания работы токенов в современных операционных системах. В ходе написания данного материала я ставил перед собой следующие вопросы:
• откуда берутся токены?
• как устроены токены?
• как это работает на практике?
Примечание: стоит отметить, что в ходе изучения других материалов могут встречаться такие понятия как «токен», «токен доступа», «маркер доступа» и «маркер безопасности». Все они являются синонимами.
Теория. Часть 1. Откуда берутся токены?
В более ранних версиях операционных систем семейства Windows все службы запускались в том же сеансе, что и первый пользователь. Этот сеанс назывался сеансом 0 или Session 0. Совместное выполнение служб и пользовательских приложений в Session 0 представляло угрозу безопасности, поскольку службы работают с повышенными привилегиями и, следовательно, являются целями для злоумышленников, которые ищут средства для повышения привилегий в операционной системе. Начиная с Windows Vista Session 0 является не интерактивным сеансом, тем самым осуществляя изоляцию служб от пользователя. Теперь в Session 0 выполняются только системные процессы и службы. Пользователь входит в сеанс 1 или Session 1. Это означает, что службы никогда не запускаются в одном сеансе с приложениями пользователей и, следовательно, защищены от атак, исходящих из кода приложения. Вход в Windows можно осуществить по-разному, далее рассмотрен интерактивный вход пользователя в операционную систему, а ниже представлена схема, которая иллюстрирует основные этапы.
Примечание: сессия пользователя предоставляется в результате успешной аутентификации пользователя и позволяет получить доступ к защищаемым объектам операционной системы при наличии соответствующих прав.
При интерактивном входе в систему, когда операционная система загружена, пользователю необходимо ввести свой логин и пароль. Для этого пользовательский интерфейс входа вызывается пользователем с использованием специальной комбинации клавиш Secure attention sequence (SAS), по умолчанию Ctrl+Alt+Del. За процесс входа в Windows, в том числе за интерактивный вход и выход из системы, отвечает процесс Winlogon.
1.) Вход в систему начинается, когда пользователь нажимает комбинацию SAS.
Примечание: SAS предназначен для защиты пользователей от программ осуществляющих перехват паролей. SAS не может быть перехвачен непривилегированными приложениями.
Примечание: процесс Winlogon активизируется не только во время входа и выхода, но и каждый раз при перехвате SAS с клавиатуры. Например, при нажатии Ctrl+Alt+Delete при выполненном входе появляется экран безопасности Windows с командами завершения работы, запуска диспетчера задач и так далее. Процесс Winlogon обеспечивает это взаимодействие.
2.) При инициализации системы, когда еще ни одно пользовательское приложение не активно, Winlogon выполняет ряд операций, обеспечивающих ему контроль над рабочей станцией с момента готовности системы к взаимодействию с пользователем. Winlogon гарантирует, что недоверенный процесс не сможет перехватить управление рабочим столом и получить доступ к паролю. Поскольку Winlogon является критическим системным процессом, от которого зависит работа системы, он запускает дочерний процесс под названием LogonUI, который в случае сбоя может просто перезапустить. Таким образом, когда процесс Winlogon обнаруживает SAS, он запускает процесс, инициализирующий поставщиков учетных данных (Credential Providers) и создает дочерний процесс LogonUI, который выводит пользователю интерфейс входа в систему.
Примечание: Winlogon также создает и открывает интерактивную станцию окна WinSta0 в пространстве имен диспетчера объектов для представления клавиатуры, мыши и монитора. Кроме того, Winlogon создает и открывает два рабочих стола, интерактивный рабочий стол пользователя в рамках Session 1 и защищаемый рабочий стол Winlogon в рамках Session 0. Защита рабочего стола Winlogon устроена таким образом, что доступ к этому рабочему столу может получить только процесс Winlogon.
3.) После происходит опрос всех возможных вариантов проверки подлинности Credential Provider (их может быть несколько). В сочетании с имеющимся оборудованием Credential Providers могут значительно расширить возможности операционной системы Windows, чтобы пользователи могли входить в систему с помощью биометрических данных, пароля, PIN-кода или любого пользовательского пакета аутентификации, который может быть создан сторонним разработчиком.
4.) LogonUI запускает пользовательский интерфейс входа и отображает все возможные варианты проверки подлинности Credential Provider пользователю.
5.) Пользователь выбирает интересующий его вариант входа (на схеме представлены два варианта: графический ключ и стандартный PIN-код). Как только пользователь вводит свои учетные данные или отказывается от входа в систему, процесс LogonUI завершается.
6.) Запрос на получение учетных данных отправляется в Credential Providers. В свою очередь Credential Providers перенаправляет запрос на конкретного поставщика безопасности Credential Provider (на схеме стандартный PIN-код).
7.) Введенные учетные данные пользователя, предназначенные для входа в систему, передаются от конкретного поставщика безопасности в Credential Providers.
8.) Credential Providers передает учетные данные процессу Winlogon.
Примечание: Winlogon создает для пользователя уникальный локальный SID входа в систему, который назначается его экземпляру рабочего стола (куда входят клавиатура, экран и мышь). Как только будут зарегистрированы имя пользователя и пароль, Winlogon передает этот SID процессу сервера проверки подлинности локальной системы безопасности LSASS.
9.) После получения имени пользователя и пароля Winlogon извлекает дескриптор пакета аутентификации для выполнения фактической проверки, например, для проверки соответствия пароля тому, что сохранен в Security Accounts Manager (SAM). SAM является службой, отвечающей за управление базой данных, содержащей определения локальных пользователей и групп, наряду с их паролями и другими атрибутами, на локальной машине (ветка реестра HKEY_LOCAL_MACHINE\SAM\SAM). Все доступные пакеты аутентификации перечислены в разделе реестра HKLM\SYSTEM\CurrentControlSet\Control\Lsa. Winlogon передает учетные данные пользователя и его SID в LSASS с использованием вызова функции LsaLogonUser (), в которой также передается параметр, включающий тип выполняемого входа в систему. Он может быть не только интерактивным, но и сетевым, пакетным или служебным. Передаваемый SID входа в систему в дальнейшем применяется в контексте использования элементов управления доступом (ACE), которые разрешают доступ к файлам и другим объектам во время сеанса пользователя в системе.
Примечание: в дальнейшем, если вход пользователя в систему пройдет успешно, этот SID будет включен в токен процесса входа в систему.
10.) LSASS передает учетные данные пользователя конкретному пакету аутентификации. Для интерактивного входа в систему Windows использует два стандартных пакета аутентификации: Kerberos и MSV1_0. Исходным пакетом аутентификации на автономной Windows-системе является MSV1_0. Пакет аутентификации Kerberos, используется на компьютерах осуществляющих аутентификацию в домене. Пакет аутентификации MSV1_0 принимает имя пользователя и хэшированную версию пароля и отправляет запрос в локальную базу SAM для извлечения информации об учетной записи, включающей хэшированный пароль, группы, в которые входит пользователь, и любые ограничения учетной записи. MSV1_0 сначала проверяет ограничения учетной записи, например период времени или тип разрешенного доступа. Если ограничений нет, MSV1_0 сравнивает хэшированный пароль и имя пользователя с той информацией, которая была получена из SAM. Если информация совпадает, MSV1_0 генерирует Locally unique identifier (LUID) для сеанса входа в систему и создает сеанс входа в систему путем вызова LSASS, связывая сгенерированный уникальный идентификатор LUID с сеансом пользователя и передавая информацию, необходимую для создания токена пользователя (следует напомнить, что токен включает SID пользователя, SID-идентификаторы групп и назначенные привилегии). LUID является локальным уникальным идентификатором токена пользователя. Если пользователь не может войти в систему по причине ограничений в базе данных SAM, вызов входа в систему завершается отказом, и MSV1_0 возвращает статус ошибки.
Примечание: если ни один из пакетов аутентификации не покажет успешного входа в систему, процесс входа прекращается.
11.) После того как вход в систему был аутентифицирован и запрошенный доступ разрешен, создается первичный токен для интерактивного входа в систему. LSASS добавляет соответствующие дополнительные идентификаторы безопасности и проверяет свою базу данных политик на предмет наличия любых предоставленных привилегий для всех SID-идентификаторов этого пользователя и добавляет эти привилегии к принадлежащему пользователю токену. После успешного создания токена LSASS дублирует токен, создавая дескриптор, который может быть передан в Winlogon, и закрывает свой собственный дескриптор. Наряду с дескриптором токена LSASS возвращает Winlogon сообщение об успехе, LUID для сеанса входа в систему и иную информацию, если такая была возвращена пакетом аутентификации. Токен пользователя описывает контекст безопасности процесса, работающего от имени указанного пользователя и используется для идентификации пользователя, так как в нем хранится информация о группах и привилегиях.
12.) Как только пользователь аутентифицирован Winlogon продолжает процесс входа в систему. Полученный токен используется Winlogon для создания исходного процесса в пользовательском сеансе. Исходный процесс хранится в параметре реестра Userinit, который находится в разделе HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon.
13.) Userinit выполняет действия по инициализации пользовательской среды окружения.
Указанная схема не является полной и адаптирована с учетом излагаемого материала. Ниже показана связь SID пользователя и LUID.
Теперь, когда мы знаем как в операционной системе Windows появляются токены, рассмотрим их более подробно.
Теория. Часть 2. Как устроены токены?
Поскольку по умолчанию дочерние процессы, запущенные в сеансе пользователя, наследуют копию токена своего создателя, все процессы (а значит и потоки этих процессов) в сеансе пользователя запускаются под одним и тем же токеном. Модель безопасности Windows требует, чтобы поток, прежде чем открыть объект (например, файл), указал, какого типа действия он хочет совершить над объектом. Для выполнения проверок прав доступа, которые хочет получить поток, диспетчер объектов вызывает монитор безопасности Security reference monitor (SRM) и если доступ к объекту предоставляется, то процессу потока назначается дескриптор, с которым поток (или другие потоки процесса) может выполнять дальнейшие операции над объектом. Под объектами в Windows понимаются файлы, устройства, задания, события, рабочие столы, сетевые ресурсы, службы, разделы реестра, принтеры, объекты Active Directory и так далее (теоретически все, что управляется диспетчером объектов операционной системы).
Примечание: SRM реализован в виде компонента операционной системы и отвечает за определение структуры данных токена с целью выполнения проверки безопасности доступа к объектам и работу с привилегиями (правами пользователей) и генерацию сообщений проверки безопасности. Сутью модели безопасности SRM является уравнение, имеющее три входных параметра: идентификационные данные безопасности потока, доступ, который поток желает получить к объекту, и настройки безопасности объекта. На выходе получаем либо «да», либо «нет», что показывает, дает модель безопасности потоку запрошенный доступ или не дает.
Для идентификации контекста безопасности процесса или потока SRM использует токен. Контекст безопасности состоит из информации, описывающей учетную запись, группы и привилегии, связанные с процессом или потоком. При выполнении входа в систему процесс LSASS создает токен для представления пользователя, входящего в систему, затем он определяет, относится ли пользователь к группе, имеющей высокие полномочия, или обладает ли он высокими привилегиями. После чего токен пользователя прикрепляется к исходному процессу или процессам, запускаемым Winlogon. Этот токен можно использовать для создания процесса, выполняющегося в контексте безопасности пользователя, вошедшего в систему. Токены варьируются по длине, поскольку у разных учетных записей пользователей имеются разные наборы привилегий. Наиболее важные поля токена представлены ниже.
Существует два типа токена: основной токен, идентифицирующий контекст безопасности процесса, и токен заимствования/олицетворения (который потоки используют для временного заимствования другого контекста безопасности, обычно для другого пользователя, иными словами для имперсонализации). В случае, когда приложению, запускаемому из-под сессии пользователя, нужно позаимствовать его права на усеченном уровне безопасности, главным образом из соображений предосторожности, используются ограниченный токен и фильтрованный токен администратора, которые создаются на основе основного токена. Олицетворяющие токены имеют следующую важную характеристику — уровень олицетворения, который отражает степень того, насколько сервер может олицетворять клиента. Всего существуют следующие четыре уровня олицетворения:
SecurityAnonymous — является самым ограниченным уровнем заимствования прав, удаленный сервер не может заимствовать права или олицетворять клиента. Используется для анонимного подключения;
SecurityIdentification — позволяет серверу получать информацию об идентичности (SID-идентификаторы) клиента и привилегии клиента, но сервер не может заимствовать его права. Иными словами удаленный сервер может идентифицировать, но не может олицетворять клиента;
SecurityImpersonation — позволяет серверу идентифицировать клиента и олицетворять его на локальной системе. Подобные токены обычно создаются в результате сетевого входа, например при доступе к FTP серверу;
SecurityDelegation — наиболее разрешающий уровень заимствования прав. Он позволяет серверу заимствовать права клиента на удаленных системах. То есть удаленный сервер может идентифицировать и олицетворять клиента в удаленных системах. Подобные токены обычно создаются в результате интерактивного входа, например по RDP.
Однако токены, идентифицирующие учетные данные пользователя, являются только лишь частью, определяющей безопасность объекта и контекста безопасности в целом. Другой частью является информация, связанная с объектом (например, файлом), которая определяет, кто и какие действия с ним может выполнять. Структура данных для этой информации называется дескриптором безопасности. Дескриптор безопасности может содержать следующие сведения о безопасности:
идентификаторы безопасности для владельца и основной группы объекта;
discretionary access control list (DACL) — избирательный список управления доступом, указывает, кто и какой доступ имеет к объекту;
system access control list (SACL) — системный список управления доступом, указывает, какие операции какими пользователями должны регистрироваться в журнале аудита безопасности и конкретный уровень целостности объекта;
набор битов элементов управления, которые определяют значение дескриптора безопасности или его отдельных членов.
Список управления доступом (ACL) состоит из заголовка и нескольких элементов управления доступом (ACE). Существует два типа ACL-списков: DACL и SACL. В DACL в каждом ACE-элементе содержится SID и маска доступа, которая обычно определяет права доступа (чтение, запись, удаление и так далее), предоставленные или запрещенные держателю SID. Аккумулирование прав доступа, предоставленных отдельными ACE-элементами, формирует набор прав доступа, предоставленных ACL-списком.
Первый ACE разрешает пользователю zdvighkov запрашивать файл только на чтение. Второй ACE позволяет участникам группы Administrators осуществлять доступ к файлу с правами на чтение и запись. Теперь, когда мы по отдельности обсудили, что такое токены, списки доступа и дескриптор безопасности, настало время связать это воедино и рассмотреть как все это взаимодействует.
Итак, защищаемый объект в данном случае файл «Отчет.docx», его дескриптор безопасности определяет операции, которые могут выполнять с данным объектом пользователи. Дескриптор безопасности основан на списке управления доступом ACL в котором содержится два элемента ACE. Процесс запущенный из под пользователя zdvighkov запрашивает доступ на чтение файла обращаясь к его дескриптору безопасности. Последний в свою очередь просматривает доступные ACE из которых состоит ACL. Одна из ACE содержит имя пользователя и список его прав, который совпадает с именем пользователя и типом запрашиваемого им доступа из токена, после чего дескриптор безопасности предоставляет запрашиваемый доступ процессу.
Теперь, когда изложена общая структура токена и принцип его работы, можно переходить к практической части.
Практика. Часть 1. Механизм подмены токена с использованием WinDBG.
С помощью WinDBG на практике рассмотрим устройство токенов и повысим свои привилегии в операционной системе. Запустим локальную отладку и рассмотрим процесс повышения привилегий, позволяющий присвоить процессу cmd.exe, запущенному от имени обычного пользователя с низкими привилегиями, токен системного процесса System, имеющего высокие привилегии.
Для начала получим информацию о запущенных процессах в операционной системе. Сделать это можно несколькими способами исходя из того какую информацию необходимо получить. Команда »! process 0 0» выведет минимальную информацию, в то время как команда »! process 0» отображает полный список потоков и событий, связанных с процессом. Вывести информацию о запущенных процессах в виде списка можно с использованием команды »! dml_proc».
1.) lkd>! dml_proc
Кроме того, получить подробную информацию о конкретном процессе можно указав его название, например »! process 0 0 cmd.exe». Рассмотрим результат работы команды и сведения содержащиеся в Диспетчере задач.
Обратимся к параметру Cid в окне WinDBG, он представляет собой идентификатор процесса и представлен в шестнадцатеричном виде. Конвертируем Cid из шестнадцатеричного вида в десятичный, открываем Диспетчер задач и убеждаемся в том, что сведения получены действительно об интересующем нас процессе. Кроме того, рассмотрим ряд других параметров полученных в результате работы команды »! process 0 0 cmd.exe». ParentCid указывает на идентификатор родительского процесса, ObjectTable является указателем на таблицу дескрипторов процесса, а DirBase указывает на таблицу страниц которая обеспечивают сопоставление между виртуальными адресами (адресами памяти, используемыми приложениями) и физическими адресами (фактическими местоположениями в аппаратной физической памяти).
Вернемся к выводу команды »! dml_proc» в окне WinDBG и обратимся к полю «Address», которое содержит адрес процесса, в нашем примере системного процесса System (ffffac89`4e6d5080). По этому адресу расположена структура _EPROCESS указанного процесса. Структура _EPROCESS содержит поле Token, которое сообщает системе о том, какие привилегии есть у процесса. Наша цель — токен привилегированного системного процесса System. Если мы сможем «позаимствовать» его токен и перезаписать его другому процессу, например, cmd.exe, привилегии последнего повысятся до системных. Получим более подробную информацию о процессе System, используя структуру _EPROCESS. Сделать это можно с использованием следующей команды.
2.) lkd> dt nt!_EPROCESS ffffac89`4e6d5080
Результат работы команды содержит информацию о различных переменных и типах данных. Обратим внимание на заветное поле Token, именно эта структура и будет нас интересовать. Обычно при выводе команды она находится гораздо ниже от начала вывода, поэтому для удобства я сделал небольшую склейку из нескольких скриншотов. Поле Token имеет смещение 0×4b8 относительно начала структуры _EPROCESS и указывает на _EX_FAST_REF. То есть _EPROCESS.Token фактически указывает на указатель _EX_FAST_REF, а не на сам Token. Рассмотрим структуру _EX_FAST_REF поближе, для этого необходимо перейти по адресу процесса System (оно же местоположение _EPROCESS) добавив смещение элемента Token (ffffac89`4e6d5080+0×4b8).
3.) lkd> dt nt!_EX_FAST_REF ffffac89`4e6d5080+0×4b8
Указатель _EX_FAST_REF представляет собой структуру данных которая всегда равна 16 байтам в 64-битных системах и 8 байтам в 32-битных системах. Все три элемента имеют одинаковое смещение, а Object и Value указывают на один и тот же адрес, но интересным является элемент RefCnt. Он используется для подсчета количества ссылок на токен, этот механизм предназначен для внутреннего использования в ядре операционной системы. То есть элемент RefCnt содержит значение, добавляемое к токену, позволяющее отслеживать актуальное количество ссылок на токен, на 32-битных системах это 3 бита, а на 64-битных системах (моя текущая архитектура) это 4 бита. Так как RefCnt содержит количество ссылок на токен это значит, что он не является частью адреса токена. Чтобы получить фактический адрес структуры Token для процесса System необходимо обнулить последние 4 бита, используя побитовое И. Таким образом, мы просто извлекаем фактическое значение Token.
4.) lkd>? (0xffffce8d`2e45fa6d & 0xfffffffffffffff0) или lkd>! process ffffac89`4e6d5080 1
Воспользуемся побитовым И, чтобы обнулить последние 4 бита поля RefCnt структуры _EX_FAST_REF или воспользуемся командой »! process ffffac89`4e6d5080 1». Вывод обеих команд даст один и тот же результат.
Теперь посмотрим, что произойдет если мы скопируем значение токена системного процесса System в адрес токена процесса cmd.exe, который запущен с правами обычного пользователя.
5.) lkd> eq ffffac89`59b8e300+0×4b8 ffffce8d2e45fa60
Команда завершена без каких-либо ошибок. Обратимся к командной строке и убедимся в том, что привилегии повышены. Теперь команды выполняются от имени встроенной учетной записи NT AUTHORITY\SYSTEM, обладающей высокими правами доступа, о чем свидетельствуют сами привилегии.
Данный пример «на пальцах» иллюстрирует процесс подмены токена, позволяя повысить привилегии в системе.
Практика. Часть 2. Повышение привилегий в домене Active Directory.
Рассмотрев устройство токенов и изучив теоретическую часть перейдем к более жизненному примеру, который продемонстрирует возможности манипулирования токенами в домене на базе Microsoft Active Directory. Возьмем за основу небольшую сеть, схема которой представлена ниже. В данном примере участвует контроллер домена, сервер и машина атакующего. Предположим, что мы скомпрометировали пользовательскую учетную запись zdvighkov_user/P@ssw0rd1, которая необходима для осуществления каких-либо действий с сервисом (например, c базой данных) расположенном на сервере.
Открыв оснастку «Локальные пользователи и группы» на сервере можно увидеть, что скомпрометированная учетная запись zdvighkov_user состоит в группах «Administrators» и «Remote Managment», а значит обладает правами локального администратора на данном сервере и имеет возможность удаленного подключения к нему.
Осуществим подключение к серверу с машины атакующего, используя учетную запись zdvighkov_user, посредством утилиты evil-winrm. Дальнейшей целью является получение доступа к активным сессиям других пользователей, имеющихся на скомпрометированном сервере. С использованием команды «query user» можно увидеть, что в системе присутствуют две сессии. Пользователем zdvighkov_adm осуществлен интерактивный вход в систему, о чем свидетельствует соответствующая запись «console», а пользователь daenerys.targaryen осуществил удаленное подключение посредством RDP, о чем свидетельствует запись «rdp-console». Для работы с токенами пользователей zdvighkov_adm и daenerys.targaryen воспользуемся утилитой Impersonate.exe. Перенесем ее на атакуемую машину, например, c использованием smb-сервера развернутого на атакующей машине.
Пользователь zdvighkov_adm вошел в систему первым, поэтому воспользуемся его сессией для дальнейшего продвижения. Рассмотрим в какие группы входят пользователи zdvighkov_adm и zdvighkov_user (для наглядности воспользуемся оснасткой ADUC на контроллере домена). Видно, что учетная запись zdvighkov_user принадлежит непривилегированному пользователю домена, в то время как учетная запись zdvighkov_adm наоборот, является учетной записью администратора домена.
Теперь, когда утилита Impersonate.exe находится на атакуемой машине воспользуемся ей. Данная утилита имеет три модуля:
list — выводит имеющиеся токены в системе;
exec — позволяет запускать команды, от имени пользователя которому принадлежит токен;
adduser — позволяет добавлять нового пользователя в домен.
Воспользуемся последним модулем, для работы которого нужен токен администратора домена и он у нас есть! Модуль adduser позволяет повысить привилегии в домене с помощью функции ImpersonateLoggedOnUser (). Для работы этого модуля необходим основной токен — TokenPrimary, связанный с учетной записью администратора домена. Модуль создает нового пользователя в домене, задает ему пароль и добавляет его в необходимые группы. Для успешной работы утилиты необходимо найти ID пользователя zdvighkov_adm, имеющего TokenPrimary, например ID: 2. Далее необходимо указать имя нового пользователя, например, zdvighkov_adm_2 и пароль, а также перечень групп в которые необходимо добавить нового пользователя. Последний аргумент необходимый для работы Impersonate.exe это FQDN контроллера домена, в нашем случае meereen.essos.local.
Примечание: в данном примере сессия пользователя с ID=2 имеет уровень целостности Integrity=Medium, в соответствии с механизмом контроля целостности учетных данных Mandatory integrity control (механизм MIC). Этот механизм используется, когда необходим дополнительный уровень контроля безопасности для защиты объектов. MIC использует уровни целостности и обязательную политику для оценки доступа. Участникам безопасности и защищаемым объектам назначаются уровни целостности, которые определяют их уровни доступа или защиты. Windows определяет четыре уровня целостности: низкий, средний, высокий и системный. Для токенов с уровнем целостности Medium или выше подразумеваемое значение уровня целостности объекта остается средним (Medium), поэтому значения Integrity=Medium будет вполне достаточно для работы утилиты.
Примечание: в утилите Impersonate.exe используется функция CreateProcessAsUser, которая предназначена для создания процесса в контексте безопасности пользователя вошедшего в систему. Для этого необходимо указать сессию пользователя, в которой используется основной токен TokenPrimary, идентифицирующий контекст безопасности процесса, так как токен заимствования TokenImpersonation не может дать доступ к файлам и не имеет соответствующих полномочий на аутентификацию на удаленной машине.
Обратимся к выводу команды. Как видно из последних двух строк, новый пользователь успешно добавлен в домен. Также можно увидеть названия привилегий, благодаря которым удалось это сделать. Привилегия SeDebugPrivilege позволяет проводить отладку программ, если эта привилегия включена у вызывающего процесса, то диспетчер процессов разрешает доступ к любому процессу или потоку независимо от дескриптора безопасности этого процесса или потока (исключение составляют защищенные процессы). Когда для нового процесса создается первичный токен доступа, обычно он наследуют профиль безопасности родительского процесса, привилегия SeAssignPrimaryToken позволяет процессу заменить основной токен назначенный по умолчанию. Используя утилиту crackmapexec проверим, что созданная учетная запись zdvighkov_adm_2 действительно имеет доступ на контроллер домена! Данный пример наглядно показывает, как с помощью токенов других пользователей, имеющихся на захваченной машине, можно повысить свои привилегии в домене.
Вывод и рекомендации по защите.
Данный материал подготовлен исключительно в образовательных целях и призван повысить уровень собственных знаний.
В качестве одной из основных компенсационных мер, позволяющих защититься от подобных воздействий, можно порекомендовать использование для администрирования инфраструктуры в домене различные учетные записи с различными правами.
Список используемой литературы.
1. https://ardent101.github.io/posts/tokens_theory/
2. Windows Internals 6 Edition Part1 2013, Mark Russinovich
3. https://github.com/sensepost/impersonate
4. https://learn.microsoft.com/en-us/windows-server/security/windows-authentication/credentials-processes-in-windows-authentication
5. https://rutube.ru/video/f2c934203c0e159a715eadc9efa19a7e/? t=14
