- Регистрация
- 7 Фев 2020
- Сообщения
- 525
- Реакции
- 98
- Репутация
- 147
Во время атаки на инфраструктуру Active Directory очень важно сохранить полученный доступ. Для этого используются различные методы и средства, в том числе — особенности групповых политик и бэкдоры. В этой статье мы рассмотрим использование групповой политики и некоторых методов внедрения в критические процессы для поддержания привилегированного доступа.
Объекты групповой политики
Групповая политика позволяет администраторам управлять компьютерами и пользователями в Active Directory. Она состоит из нескольких частей и в большой компании может оказаться сложной в использовании без привлечения сторонних инструментов.
Групповые политики сохраняются как объекты групповой политики (GPO), которые затем связываются с объектами Active Directory. Дело в том, что групповые политики могут включать параметры безопасности, разделы реестра, правила установки программного обеспечения, сценарии для запуска и завершения работы, а члены домена обновляют параметры групповой политики по умолчанию каждые 90 минут на своих машинах и каждые 5 минут на контроллере домена.
В большинстве случаев в домене точно настроены:
Управление групповой политикой
Файлы, которые содержат параметры политики («Шаблон групповой политики») расположены по пути C:\Windows\SYSVOL\[domain]\Policies\ на контроллере домена.
Шаблон групповой политики
Используя PowerShell Active Directory Get-ADObject, можно проверить наличие объекта групповой политики и его ключевые поля, интересующие нас.
PS > Get-ADObject 'CN={428FE319-FF53-4569-94A3-7C855A82570E},CN=Policies,CN=System,DC=domain,DC=dom'
Использование Get-ADObject для получения основной информации об объекте групповой политикиPS > Get-ADObject 'CN={428FE319-FF53-4569-94A3-7C855A82570E},CN=Policies,CN=System,DC=domain,DC=dom' -Properties displayname,gpcfilesyspath,gpcmachineextensionnames,gpcuserextensionnames
Использование Get-ADObject для получения ключевой информации об объекте групповой политики
При создании объекта групповой политики он может быть как связан, так и не связан с каким-либо объектом Active Directory. Если такая связь существует, атрибут gPLink этого объекта будет обновлен и в него будет добавлено значение DistinguishedName групповой политики. По этому признаку можно определить, какие групповые политики применяются к данному объекту Active Directory.
Если мы перейдем в любую директорию объекта групповой политики, то есть в C:\Windows\SYSVOL\[domain]\Policies\, то обнаружим следующие вложенные объекты:
Содержимое директории объекта групповой политики
Групповая политика была создана, чтобы упростить управление ресурсами в домене, однако злоумышленник также может использовать ее возможности для своих целей. К примеру, таким образом можно подменить программы, создать запланированные задачи, добавить новую локальную учетную запись на все компьютеры. Также приведу список интересных возможностей, которыми лично пользовался сам или видел, как пользовались другие операторы.
Разрешения групповой политики
Так мы можем добавлять задачи, выполняемые от имени администратора домена на всех компьютерах домена.
SeEnableDelegationPrivilege
Эта привилегия определяет разрешение доверия к учетным записям компьютеров и пользователей при делегировании. Таким образом, она распространяется на домен, а не на локальную машину в этом домене. Право SeEnableDelegationPrivilege контролирует изменение свойства msDS-AllowedToDelegateTo, которое содержит объекты для ограниченного делегирования.
Исходя из этого, оператор не может изменить ни настройки управления учетными записями пользователей, связанные с делегированием, ни свойство msDS-AllowedToDelegateTo для объекта, если мы не обладаем привилегией SeEnableDelegationPrivilege.
Запрет на изменение свойства msDS-AllowedToDelegateTo
Так как право SeEnableDelegationPrivilege применимо только на самом контроллере домена, оператору необходимо проверить политику контроллера домена по умолчанию (имеет guid {6AC1786C-016F-11D2-945F-00C04fB984F9}). Проверить данную настройку можно в файле \MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf для данной политики.
Разрешение SeEnableDelegationPrivilege
Иными словами, по умолчанию только администраторы имеют право изменять параметры делегирования. Если мы имеем права GenericAll/GenericWrite для любых объектов в домене, нам необходимо получить привилегию SeEnableDelegationPrivilege. Сделать это проще, чем кажется. Допишем имя учетной записи в указанный выше файл.
Разрешение SeEnableDelegationPrivilege после добавления записи
При добавлении любого SID или имени пользователя в любую строку данного файла в разделе [Privilege Rights] изменения вступают в силу, когда контроллер домена или пользователя перезагружают или обновляют групповую политику.
PS > $Policy = Get-DomainPolicy -Source DC
PS > $Policy['Privilege Rights']['SeEnableDelegationPrivilege']
SeEnableDelegationPrivilege в [Privilege Rights]
Таким образом, если целевой пользователь обладает полными правами на любого другого пользователя в домене, то оператор может изменить значения свойства msDS-AllowedToDelegateTo для подконтрольного пользователя, делегировав права абсолютно на любую службу в домене. Контроль над всеми службами в домене дает нам контроль над всем доменом.
Security Support Provider
Security Support Provider Interface (SSPI) — программный интерфейс в Microsoft Windows между приложениями и провайдерами безопасности. SSPI используется для отделения протоколов уровня приложения от деталей реализации сетевых протоколов безопасности и обеспечивает уровень абстракции для поддержки множества механизмов аутентификации.
SSPI позволяет легко расширять методы проверки подлинности Windows, позволяя добавлять новых поставщиков поддержки безопасности (SSP). Вот некоторые из стандартных служб SSP:
Есть два способа сделать это. Первый — воспользоваться модулем misc.
mimikatz # privilege::debug
mimikatz # misc::memssp
Использование модуля misc::memssp mimikatz
Но этот способ не переживет перезагрузки машины. Теперь разберем более сложный, но надежный второй способ. Необходимо скопировать в папку C:\Windwows\System32. После этого надо обновить запись в реестре по пути HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Security Packages, добавив туда mimilib.
Запись Security Packages в реестре
Используя групповые политики, можно собирать информацию со всех журналов всех машин в домене, а также сохранять их в какой-нибудь общедоступный ресурс.
Списки доступа и дескрипторы безопасности
Учетные записи теневого администратора (shadow admins) — это учетные записи, которые имеют «негласные» привилегии и обычно остаются незамеченными, так как они не входят в привилегированную группу Active Directory. Как правило, привилегии таким учетным записям предоставлены за счет прямого назначения разрешений (списков доступа). Поскольку учетная запись теневого администратора обладает неявными привилегиями и ее сложнее обнаружить (она не состоит ни в каких привилегированных группах), то она наиболее приоритетна для оператора.
Каждый объект в Active Directory имеет свой собственный список разрешений ACE (записи контроля доступа), которые в совокупности составляют ACL (список контроля доступа). ACL каждого объекта определяет, кто имеет разрешения на этот конкретный объект и какие действия могут быть выполнены с ним.
ACL группы «Администраторы домена для всех»
То есть группе «Администраторы домена» по умолчанию предоставляется полный доступ ко всем объектам домена. Но оператор может взять непривилегированную учетную запись пользователя и предоставить ей те же ACE, что и группе «Администраторы домена». Такая учетная запись и будет классифицироваться как учетная запись теневого администратора.
Преимущество этого метода состоит в том, что обнаружить его можно, только постоянно отслеживая списки контроля доступа, что на самом деле делается очень редко либо вообще никогда. Рассмотрим три самых распространенных варианта использования метода.
Первый вариант — когда оператор предоставляет учетной записи полный контроль над группой «Администраторы домена».
Полный контроль над группой «Администраторы домена»
В данном варианте учетная запись не состоит в указанной группе и не является привилегированной, но в любой момент может добавить себя или другую подконтрольную учетную запись в эту группу, выполнить необходимые действия и удалиться из группы.
Второй вариант — когда оператор предоставляет учетной записи разрешение «Сбросить пароль» для другой учетной записи из группы «Администраторы домена».
Разрешение «Сбросить пароль» для учетной записи «Администратор»
И третий вариант — когда оператор предоставляет учетной записи привилегии на репликацию изменений каталога.
Любой пользователь с таким разрешением имеет возможность реплицировать любые объекты, включая пароли. Это дает оператору право на выполнение атаки DCSync.
Directory Services Restore Mode
Каждый контроллер домена имеет внутреннюю учетную запись локального администратора. Она называется учетной записью режима восстановления служб каталогов (DSRM). Причем пароль для данной учетной записи редко подлежит изменению, так как основной способ сделать это на контроллере домена заключается в запуске инструмента командной строки ntdsutil.
Есть возможность синхронизировать пароль DSRM на контроллере домена с определенной учетной записью домена. Установить пароль можно, выполнив последовательно следующие команды.
> ntdsutil
: set dsrm password
: reset password on server null
: []
: q
: q
Замена пароля DSRM
Но дело в том, что пользователь DSRM по умолчанию — это «Администратор». Таким образом, их пароли совпадают. Но оператор может связать пользователя DSRM с любым другим пользователем домена.
> ntdsutil
: set dsrm password
: sync from domain account [пользователь]
: q
: q
Связывание пользователя DSRM с другой учетной записью
После того как удалось связать учетную запись DSRM с другой учетной записью, определимся, как ее можно использовать. Первым делом добавим свойство DsrmAdminLogonBehavior в HKLM:\System\CurrentControlSet\Control\Lsa\. Возможные значения:
PS> New-ItemProperty "HKLM:\System\CurrentControlSet\Control\Lsa\" -Name "DsrmAdminLogonBehavior" -Value 2 -PropertyType DWORD
Добавление свойства DsrmAdminLogonBehavior
При этом оператору не нужно знать пароль пользователя, достаточно хеша пароля (для path the hash). Если значение свойства DsrmAdminLogonBehavior равно 2, а оператор может изменить пароль DSRM, то данный способ позволяет ему сохранить права администратора на контроллере домена даже при изменении всех паролей пользователей и компьютеров домена.
Skeleton Key
Skeleton Key — это особенное вредоносное программное обеспечение, которое позволяет легко понижать защищенность учетных записей в домене Active Directory с точки зрения авторизации. Эта программа внедряется в процесс LSASS и создает там собственный пароль, который будет актуален для любой учетной записи домена. Причем настоящие пароли тоже будут действительны, поэтому риск, что бэкдор обнаружат, значительно снижается.
В сетях Windows, как правило, есть два основных метода аутентификации: NTLM и Kerberos. И оба этих метода подвергаются вмешательству Skeleton Key. Таким образом, при NTLM-аутентификации хеш пароля сравнивается не с базой SAM, а с хешем Skeleton Key внутри LSASS. В случае с Kerberos шифрование будет понижено до алгоритма, который не поддерживает соль (RC4_HMAC_MD5). Поэтому хеш, проверяемый на стороне сервера, будет удовлетворять хешу Skeleton Key, и аутентификация всегда будет успешной.
Для внедрения бэкдора необходимы права администратора домена. Но стоит помнить, что, поскольку используется внедрение в процесс, перезагрузка контроллера домена удалит вредоносную программу. При этом выполнить атаку очень просто, для этого нужен mimikatz.
mimikatz # privilege::debug
mimikatz # misc::skeleton
Внедрение Skeleton Key с помощью mimikatz
В результате этих действий появился еще один пароль, который также работает для пользователя: mimikatz.
Авторизация с поддельным паролем Skeleton Key
При этом данный пароль подходит для авторизации под абсолютно любой учетной записью пользователя домена.
Авторизация под пользователем «Администратор» с паролем Skeleton Key
Стоит также упомянуть и LSA. При внедрении бэкдора может появиться следующая ошибка.
Авторизация под пользователем notroot с паролем Skeleton Key
Чтобы избежать этого, нам нужно выполнить атаку в обход LSA. Но и это несложно сделать с помощью mimikatz.
mimikatz # privilege::debug
mimikatz # !+
mimikatz # !processprotect /process:lsass.exe /remove
mimikatz # misc::skeleton
Внедрение бэкдора Skeleton Key в обход LSAЗаключение
Можно сказать, что Skeleton Key — это метод, который оператор может использовать для доступа к хостам и сетевым ресурсам без необходимости взламывать пароли пользователей домена. Полученный этим способом доступ сохраняется после смены паролей всех пользователей (включая администраторов) до перезагрузки контроллера домена.
Для тех, кто хочет получить больше информации по этой теме, я создал телеграм-канал @RalfHackerChannel. Здесь можно задать свои вопросы или ответить на вопросы других юзеров.
Авторизация с реальным паролем пользователя
Свойство DsrmAdminLogonBehavior в реестре
ACL группы «Администраторы домена для System»
Пароль пользователя root в открытом виде
Имя объекта по SID
Объекты групповой политики
Групповая политика позволяет администраторам управлять компьютерами и пользователями в Active Directory. Она состоит из нескольких частей и в большой компании может оказаться сложной в использовании без привлечения сторонних инструментов.
Групповые политики сохраняются как объекты групповой политики (GPO), которые затем связываются с объектами Active Directory. Дело в том, что групповые политики могут включать параметры безопасности, разделы реестра, правила установки программного обеспечения, сценарии для запуска и завершения работы, а члены домена обновляют параметры групповой политики по умолчанию каждые 90 минут на своих машинах и каждые 5 минут на контроллере домена.
В большинстве случаев в домене точно настроены:
- один объект групповой политики, определяющий обязательный пароль, Kerberos и политики всего домена;
- один объект групповой политики, настроенный для подразделения контроллеров домена;
- один объект групповой политики, настроенный для подразделения серверов и рабочих станций.
Управление групповой политикой
Файлы, которые содержат параметры политики («Шаблон групповой политики») расположены по пути C:\Windows\SYSVOL\[domain]\Policies\ на контроллере домена.
Шаблон групповой политики
Используя PowerShell Active Directory Get-ADObject, можно проверить наличие объекта групповой политики и его ключевые поля, интересующие нас.
PS > Get-ADObject 'CN={428FE319-FF53-4569-94A3-7C855A82570E},CN=Policies,CN=System,DC=domain,DC=dom'
Использование Get-ADObject для получения основной информации об объекте групповой политикиPS > Get-ADObject 'CN={428FE319-FF53-4569-94A3-7C855A82570E},CN=Policies,CN=System,DC=domain,DC=dom' -Properties displayname,gpcfilesyspath,gpcmachineextensionnames,gpcuserextensionnames
Использование Get-ADObject для получения ключевой информации об объекте групповой политики
При создании объекта групповой политики он может быть как связан, так и не связан с каким-либо объектом Active Directory. Если такая связь существует, атрибут gPLink этого объекта будет обновлен и в него будет добавлено значение DistinguishedName групповой политики. По этому признаку можно определить, какие групповые политики применяются к данному объекту Active Directory.
Если мы перейдем в любую директорию объекта групповой политики, то есть в C:\Windows\SYSVOL\[domain]\Policies\, то обнаружим следующие вложенные объекты:
- Machine — директория с настройками машины для объекта групповой политики.
- User — директория с пользовательскими настройками для объекта групповой политики.
- GPT.INI — файл, который содержит параметры конфигурации объекта групповой политики.
Содержимое директории объекта групповой политики
Групповая политика была создана, чтобы упростить управление ресурсами в домене, однако злоумышленник также может использовать ее возможности для своих целей. К примеру, таким образом можно подменить программы, создать запланированные задачи, добавить новую локальную учетную запись на все компьютеры. Также приведу список интересных возможностей, которыми лично пользовался сам или видел, как пользовались другие операторы.
- Использование сценариев PowerShell или VBS для настройки членства в группах на уровне домена.
- Запуск Invoke-Mimikatz на всех контроллерах домена в качестве SYSTEM через определенный промежуток времени (например, раз в три дня).
- Получение учетной записи krbtgt, а затем планирование задачи запуска DCSync на определенных машинах во всем лесу с использованием поддельных билетов Kerberos.
- Установка RAT и добавление исключения в антивирусные правила в домене или лесу.
Разрешения групповой политики
Так мы можем добавлять задачи, выполняемые от имени администратора домена на всех компьютерах домена.
SeEnableDelegationPrivilege
Эта привилегия определяет разрешение доверия к учетным записям компьютеров и пользователей при делегировании. Таким образом, она распространяется на домен, а не на локальную машину в этом домене. Право SeEnableDelegationPrivilege контролирует изменение свойства msDS-AllowedToDelegateTo, которое содержит объекты для ограниченного делегирования.
Исходя из этого, оператор не может изменить ни настройки управления учетными записями пользователей, связанные с делегированием, ни свойство msDS-AllowedToDelegateTo для объекта, если мы не обладаем привилегией SeEnableDelegationPrivilege.
Запрет на изменение свойства msDS-AllowedToDelegateTo
Так как право SeEnableDelegationPrivilege применимо только на самом контроллере домена, оператору необходимо проверить политику контроллера домена по умолчанию (имеет guid {6AC1786C-016F-11D2-945F-00C04fB984F9}). Проверить данную настройку можно в файле \MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf для данной политики.
Разрешение SeEnableDelegationPrivilege
Иными словами, по умолчанию только администраторы имеют право изменять параметры делегирования. Если мы имеем права GenericAll/GenericWrite для любых объектов в домене, нам необходимо получить привилегию SeEnableDelegationPrivilege. Сделать это проще, чем кажется. Допишем имя учетной записи в указанный выше файл.
Разрешение SeEnableDelegationPrivilege после добавления записи
При добавлении любого SID или имени пользователя в любую строку данного файла в разделе [Privilege Rights] изменения вступают в силу, когда контроллер домена или пользователя перезагружают или обновляют групповую политику.
PS > $Policy = Get-DomainPolicy -Source DC
PS > $Policy['Privilege Rights']['SeEnableDelegationPrivilege']
SeEnableDelegationPrivilege в [Privilege Rights]
Таким образом, если целевой пользователь обладает полными правами на любого другого пользователя в домене, то оператор может изменить значения свойства msDS-AllowedToDelegateTo для подконтрольного пользователя, делегировав права абсолютно на любую службу в домене. Контроль над всеми службами в домене дает нам контроль над всем доменом.
Security Support Provider
Security Support Provider Interface (SSPI) — программный интерфейс в Microsoft Windows между приложениями и провайдерами безопасности. SSPI используется для отделения протоколов уровня приложения от деталей реализации сетевых протоколов безопасности и обеспечивает уровень абстракции для поддержки множества механизмов аутентификации.
SSPI позволяет легко расширять методы проверки подлинности Windows, позволяя добавлять новых поставщиков поддержки безопасности (SSP). Вот некоторые из стандартных служб SSP:
- NTLM — это протокол аутентификации, используемый в сетях, которые включают машины с операционной системой Windows.
- Kerberos — определяет, как клиенты взаимодействуют со службой сетевой аутентификации на основе билетов.
- Negotiate — это SSP, который действует как прикладной уровень между SSPI и другими поставщиками общих служб.
- Schannel — это SSP, который содержит набор протоколов безопасности, обеспечивающих идентификацию личности и безопасную конфиденциальную связь посредством шифрования.
- Digest — это SSP, который реализует упрощенный протокол аутентификации для сторон, участвующих в обмене данными на основе протоколов HTTP или SASL.
- CredSSP — это SSP, позволяющий приложению делегировать учетные данные пользователя для удаленной аутентификации.
Есть два способа сделать это. Первый — воспользоваться модулем misc.
mimikatz # privilege::debug
mimikatz # misc::memssp
Использование модуля misc::memssp mimikatz
Но этот способ не переживет перезагрузки машины. Теперь разберем более сложный, но надежный второй способ. Необходимо скопировать в папку C:\Windwows\System32. После этого надо обновить запись в реестре по пути HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Security Packages, добавив туда mimilib.
Запись Security Packages в реестре
Используя групповые политики, можно собирать информацию со всех журналов всех машин в домене, а также сохранять их в какой-нибудь общедоступный ресурс.
Списки доступа и дескрипторы безопасности
Учетные записи теневого администратора (shadow admins) — это учетные записи, которые имеют «негласные» привилегии и обычно остаются незамеченными, так как они не входят в привилегированную группу Active Directory. Как правило, привилегии таким учетным записям предоставлены за счет прямого назначения разрешений (списков доступа). Поскольку учетная запись теневого администратора обладает неявными привилегиями и ее сложнее обнаружить (она не состоит ни в каких привилегированных группах), то она наиболее приоритетна для оператора.
Каждый объект в Active Directory имеет свой собственный список разрешений ACE (записи контроля доступа), которые в совокупности составляют ACL (список контроля доступа). ACL каждого объекта определяет, кто имеет разрешения на этот конкретный объект и какие действия могут быть выполнены с ним.
ACL группы «Администраторы домена для всех»
То есть группе «Администраторы домена» по умолчанию предоставляется полный доступ ко всем объектам домена. Но оператор может взять непривилегированную учетную запись пользователя и предоставить ей те же ACE, что и группе «Администраторы домена». Такая учетная запись и будет классифицироваться как учетная запись теневого администратора.
Преимущество этого метода состоит в том, что обнаружить его можно, только постоянно отслеживая списки контроля доступа, что на самом деле делается очень редко либо вообще никогда. Рассмотрим три самых распространенных варианта использования метода.
Первый вариант — когда оператор предоставляет учетной записи полный контроль над группой «Администраторы домена».
Полный контроль над группой «Администраторы домена»
В данном варианте учетная запись не состоит в указанной группе и не является привилегированной, но в любой момент может добавить себя или другую подконтрольную учетную запись в эту группу, выполнить необходимые действия и удалиться из группы.
Второй вариант — когда оператор предоставляет учетной записи разрешение «Сбросить пароль» для другой учетной записи из группы «Администраторы домена».
Разрешение «Сбросить пароль» для учетной записи «Администратор»
И третий вариант — когда оператор предоставляет учетной записи привилегии на репликацию изменений каталога.
Любой пользователь с таким разрешением имеет возможность реплицировать любые объекты, включая пароли. Это дает оператору право на выполнение атаки DCSync.
Directory Services Restore Mode
Каждый контроллер домена имеет внутреннюю учетную запись локального администратора. Она называется учетной записью режима восстановления служб каталогов (DSRM). Причем пароль для данной учетной записи редко подлежит изменению, так как основной способ сделать это на контроллере домена заключается в запуске инструмента командной строки ntdsutil.
Есть возможность синхронизировать пароль DSRM на контроллере домена с определенной учетной записью домена. Установить пароль можно, выполнив последовательно следующие команды.
> ntdsutil
: set dsrm password
: reset password on server null
: []
: q
: q
Замена пароля DSRM
Но дело в том, что пользователь DSRM по умолчанию — это «Администратор». Таким образом, их пароли совпадают. Но оператор может связать пользователя DSRM с любым другим пользователем домена.
> ntdsutil
: set dsrm password
: sync from domain account [пользователь]
: q
: q
Связывание пользователя DSRM с другой учетной записью
После того как удалось связать учетную запись DSRM с другой учетной записью, определимся, как ее можно использовать. Первым делом добавим свойство DsrmAdminLogonBehavior в HKLM:\System\CurrentControlSet\Control\Lsa\. Возможные значения:
- 0 (по умолчанию): можно использовать учетную запись DSRM, только если DC запущен в DSRM;
- 1: можно использовать учетную запись DSRM для входа в систему, если локальная служба AD остановлена;
- 2: всегда можно использовать учетную запись DSRM.
PS> New-ItemProperty "HKLM:\System\CurrentControlSet\Control\Lsa\" -Name "DsrmAdminLogonBehavior" -Value 2 -PropertyType DWORD
Добавление свойства DsrmAdminLogonBehavior
При этом оператору не нужно знать пароль пользователя, достаточно хеша пароля (для path the hash). Если значение свойства DsrmAdminLogonBehavior равно 2, а оператор может изменить пароль DSRM, то данный способ позволяет ему сохранить права администратора на контроллере домена даже при изменении всех паролей пользователей и компьютеров домена.
Skeleton Key
Skeleton Key — это особенное вредоносное программное обеспечение, которое позволяет легко понижать защищенность учетных записей в домене Active Directory с точки зрения авторизации. Эта программа внедряется в процесс LSASS и создает там собственный пароль, который будет актуален для любой учетной записи домена. Причем настоящие пароли тоже будут действительны, поэтому риск, что бэкдор обнаружат, значительно снижается.
В сетях Windows, как правило, есть два основных метода аутентификации: NTLM и Kerberos. И оба этих метода подвергаются вмешательству Skeleton Key. Таким образом, при NTLM-аутентификации хеш пароля сравнивается не с базой SAM, а с хешем Skeleton Key внутри LSASS. В случае с Kerberos шифрование будет понижено до алгоритма, который не поддерживает соль (RC4_HMAC_MD5). Поэтому хеш, проверяемый на стороне сервера, будет удовлетворять хешу Skeleton Key, и аутентификация всегда будет успешной.
Для внедрения бэкдора необходимы права администратора домена. Но стоит помнить, что, поскольку используется внедрение в процесс, перезагрузка контроллера домена удалит вредоносную программу. При этом выполнить атаку очень просто, для этого нужен mimikatz.
mimikatz # privilege::debug
mimikatz # misc::skeleton
Внедрение Skeleton Key с помощью mimikatz
В результате этих действий появился еще один пароль, который также работает для пользователя: mimikatz.
Авторизация с поддельным паролем Skeleton Key
При этом данный пароль подходит для авторизации под абсолютно любой учетной записью пользователя домена.
Авторизация под пользователем «Администратор» с паролем Skeleton Key
Стоит также упомянуть и LSA. При внедрении бэкдора может появиться следующая ошибка.
Авторизация под пользователем notroot с паролем Skeleton Key
Чтобы избежать этого, нам нужно выполнить атаку в обход LSA. Но и это несложно сделать с помощью mimikatz.
mimikatz # privilege::debug
mimikatz # !+
mimikatz # !processprotect /process:lsass.exe /remove
mimikatz # misc::skeleton
Внедрение бэкдора Skeleton Key в обход LSAЗаключение
Можно сказать, что Skeleton Key — это метод, который оператор может использовать для доступа к хостам и сетевым ресурсам без необходимости взламывать пароли пользователей домена. Полученный этим способом доступ сохраняется после смены паролей всех пользователей (включая администраторов) до перезагрузки контроллера домена.
Для тех, кто хочет получить больше информации по этой теме, я создал телеграм-канал @RalfHackerChannel. Здесь можно задать свои вопросы или ответить на вопросы других юзеров.
Авторизация с реальным паролем пользователя
Свойство DsrmAdminLogonBehavior в реестре
ACL группы «Администраторы домена для System»
Пароль пользователя root в открытом виде
Имя объекта по SID