Сохраняем доступ. Бэкдоры в Active Directory. Часть 1.

[Tartuga]

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

Объекты групповой политики.
Групповая политика позволяет администраторам управлять компьютерами и пользователями в 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\, то обнаружим следующие вложенные объекты:

1. Machine — директория с настройками машины для объекта групповой политики.
2. User — директория с пользовательскими настройками для объекта групповой политики.
3. GPT.INI — файл, который содержит параметры конфигурации объекта групповой политики.

Содержимое директории объекта групповой политики
Групповая политика была создана, чтобы упростить управление ресурсами в домене, однако злоумышленник также может использовать ее возможности для своих целей. К примеру, таким образом можно подменить программы, создать запланированные задачи, добавить новую локальную учетную запись на все компьютеры. Также приведу список интересных возможностей, которыми лично пользовался сам или видел, как пользовались другие операторы.

1. Использование сценариев PowerShell или VBS для настройки членства в группах на уровне домена.
2. Запуск Invoke-Mimikatz на всех контроллерах домена в качестве SYSTEM через определенный промежуток времени (например, раз в три дня).
3. Получение учетной записи krbtgt, а затем планирование задачи запуска DCSync на определенных машинах во всем лесу с использованием поддельных билетов Kerberos.
4. Установка 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

Имя объекта по SID
Иными словами, по умолчанию только администраторы имеют право изменять параметры делегирования. Если мы имеем права GenericAll/GenericWrite для любых объектов в домене, нам необходимо получить привилегию SeEnableDelegationPrivilege. Сделать это проще, чем кажется. Допишем имя учетной записи в указанный выше файл.