• XSS.stack #1 – первый литературный журнал от юзеров форума

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

Azrv3l

win32kfull
Эксперт
Регистрация
30.03.2019
Сообщения
215
Реакции
539
backdoor-h.jpg

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

Объекты групповой политики.
Групповая политика позволяет администраторам управлять компьютерами и пользователями в Active Directory. Она состоит из нескольких частей и в большой компании может оказаться сложной в
использовании без привлечения сторонних инструментов.

Групповые политики сохраняются как объекты групповой политики (GPO), которые затем связываются с объектами Active Directory. Дело в том, что групповые политики могут включать параметры безопасности, разделы реестра,
правила установки программного обеспечения, сценарии для запуска и завершения работы, а члены домена обновляют параметры групповой политики по умолчанию каждые 90 минут на своих машинах и каждые 5 минут на контроллере домена.

В большинстве случаев в домене точно настроены:
  • один объект групповой политики, определяющий обязательный пароль, Kerberos и политики всего домена;
  • один объект групповой политики, настроенный для подразделения контроллеров домена;
  • один объект групповой политики, настроенный для подразделения серверов и рабочих станций.
Посмотреть групповые политики можно в окне «Диспетчер серверов → Управление групповой политикой».

1.jpg


Файлы, которые содержат параметры политики («Шаблон групповой политики») расположены по пути C:\Windows\SYSVOL\[domain]\Policies\ на контроллере домена.

2.jpg


Используя PowerShell Active Directory Get-ADObject, можно проверить наличие объекта групповой политики и его ключевые поля, интересующие нас.
Код:
PS > Get-ADObject 'CN={428FE319-FF53-4569-94A3-7C855A82570E},CN=Policies,CN=System,DC=domain,DC=dom'

3.jpg

Код:
PS > Get-ADObject 'CN={428FE319-FF53-4569-94A3-7C855A82570E},CN=Policies,CN=System,DC=domain,DC=dom' -Properties displayname,gpcfilesyspath,gpcmachineextensionnames,gpcuserextensionnames

4.jpg


Использование Get-ADObject для получения ключевой информации об объекте групповой политики

При создании объекта групповой политики он может быть как связан, так и не связан с каким-либо объектом Active Directory. Если такая связь существует, атрибут gPLink этого объекта будет обновлен и в него будет добавлено значение
DistinguishedName групповой политики. По этому признаку можно определить, какие групповые политики применяются к данному объекту Active Directory.

Если мы перейдем в любую директорию объекта групповой политики, то есть в C:\Windows\SYSVOL\[domain]\Policies\, то обнаружим следующие вложенные объекты:
  1. Machine — директория с настройками машины для объекта групповой политики.
  2. User — директория с пользовательскими настройками для объекта групповой политики.
  3. GPT.INI — файл, который содержит параметры конфигурации объекта групповой политики.
5.jpg


Групповая политика была создана, чтобы упростить управление ресурсами в домене, однако злоумышленник также может использовать ее возможности для своих целей. К примеру, таким образом можно подменить программы,
создать запланированные задачи, добавить новую локальную учетную запись на все компьютеры. Также приведу список интересных возможностей, которыми лично пользовался сам или видел, как пользовались другие операторы.
  1. Использование сценариев PowerShell или VBS для настройки членства в группах на уровне домена.
  2. Запуск Invoke-Mimikatz на всех контроллерах домена в качестве SYSTEM через определенный промежуток времени (например, раз в три дня).
  3. Получение учетной записи krbtgt, а затем планирование задачи запуска DCSync на определенных машинах во всем лесу с использованием поддельных билетов Kerberos.
  4. Установка RAT и добавление исключения в антивирусные правила в домене или лесу.
Применение групповой политики по умолчанию заключается в обновлении групповой политики на клиентах. При этом если новая политика совпадает со старой, та обновляться не будет.
Назначить разрешения для политики можно в том же разделе «Управление групповой политикой», выбрав политику и перейдя к настройкам делегирования.

6.jpg


Так мы можем добавлять задачи, выполняемые от имени администратора домена на всех компьютерах домена.

SeEnableDelegationPrivilege.
Эта привилегия определяет разрешение доверия к учетным записям компьютеров и пользователей при делегировании. Таким образом, она распространяется на домен, а не на локальную машину в этом домене.
Право SeEnableDelegationPrivilege контролирует изменение свойства msDS-AllowedToDelegateTo, которое содержит объекты для ограниченного делегирования.

Исходя из этого, оператор не может изменить ни настройки управления учетными записями пользователей, связанные с делегированием, ни свойство msDS-AllowedToDelegateTo для объекта,
если мы не обладаем привилегией SeEnableDelegationPrivilege.

7.jpg


Так как право SeEnableDelegationPrivilege применимо только на самом контроллере домена, оператору необходимо проверить политику контроллера домена по умолчанию (имеет guid {6AC1786C-016F-11D2-945F-00C04fB984F9}).
Проверить данную настройку можно в файле \MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf для данной политики.

8.jpg


9.jpg


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

10.jpg


При добавлении любого SID или имени пользователя в любую строку данного файла в разделе [Privilege Rights] изменения вступают в силу, когда контроллер домена или пользователя перезагружают или обновляют групповую политику.

Код:
PS > $Policy = Get-DomainPolicy -Source DC
PS > $Policy['Privilege Rights']['SeEnableDelegationPrivilege']

11.jpg


Таким образом, если целевой пользователь обладает полными правами на любого другого пользователя в домене, то оператор может изменить значения свойства msDS-AllowedToDelegateTo для подконтрольного пользователя,
делегировав права абсолютно на любую службу в домене. Контроль над всеми службами в домене дает нам контроль над всем доменом.

Security Support Provider.
Security Support Provider Interface (SSPI) — программный интерфейс в Microsoft Windows между приложениями и провайдерами безопасности. SSPI используется для отделения протоколов уровня приложения от
деталей реализации сетевых протоколов безопасности и обеспечивает уровень абстракции для поддержки множества механизмов аутентификации.

SSPI позволяет легко расширять методы проверки подлинности Windows, позволяя добавлять новых поставщиков поддержки безопасности (SSP). Вот некоторые из стандартных служб SSP:
  1. NTLM — это протокол аутентификации, используемый в сетях, которые включают машины с операционной системой Windows.
  2. Kerberos — определяет, как клиенты взаимодействуют со службой сетевой аутентификации на основе билетов.
  3. Negotiate — это SSP, который действует как прикладной уровень между SSPI и другими поставщиками общих служб.
  4. Schannel — это SSP, который содержит набор протоколов безопасности, обеспечивающих идентификацию личности и безопасную конфиденциальную связь посредством шифрования.
  5. Digest — это SSP, который реализует упрощенный протокол аутентификации для сторон, участвующих в обмене данными на основе протоколов HTTP или SASL.
  6. CredSSP — это SSP, позволяющий приложению делегировать учетные данные пользователя для удаленной аутентификации.
Но мы можем добавить свой SSP в систему Windows. Имеющийся в mimikatz модуль SSP обеспечивает автоматическую регистрацию локально аутентифицированных учетных данных. Таким образом,
оператор сможет получать актуальный пароль учетной записи компьютера, учетные данные служб, а также все учетные записи, которые авторизуются в системе.

Есть два способа сделать это. Первый — воспользоваться модулем misc.
Код:
mimikatz # privilege::debug
mimikatz # misc::memssp

12.jpg


Но этот способ не переживет перезагрузки машины. Теперь разберем более сложный, но надежный второй способ. Необходимо скопировать mimilib.dll в папку C:\Windwows\System32. После этого надо обновить запись в реестре по пути HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Security Packages, добавив туда mimilib.

13.jpg


Теперь все данные авторизации будут регистрироваться в журнале C:\Windwows\System32\kiwissp.log.

14.jpg


15.jpg


Используя групповые политики, можно собирать информацию со всех журналов всех машин в домене, а также сохранять их в какой-нибудь общедоступный ресурс.

Списки доступа и дескрипторы безопасности.
Учетные записи теневого администратора (shadow admins) — это учетные записи, которые имеют «негласные» привилегии и обычно остаются незамеченными, так как они не входят в привилегированную группу Active Directory.
Как правило, привилегии таким учетным записям предоставлены за счет прямого назначения разрешений (списков доступа). Поскольку учетная запись теневого администратора обладает неявными привилегиями и ее сложнее обнаружить
(она не состоит ни в каких привилегированных группах), то она наиболее приоритетна для оператора.

Каждый объект в Active Directory имеет свой собственный список разрешений ACE (записи контроля доступа), которые в совокупности составляют ACL (список контроля доступа). ACL каждого объекта определяет,
кто имеет разрешения на этот конкретный объект и какие действия могут быть выполнены с ним.

16.jpg


17.jpg


То есть группе «Администраторы домена» по умолчанию предоставляется полный доступ ко всем объектам домена. Но оператор может взять непривилегированную учетную запись пользователя и предоставить ей те же ACE,
что и группе «Администраторы домена». Такая учетная запись и будет классифицироваться как учетная запись теневого администратора.

Преимущество этого метода состоит в том, что обнаружить его можно, только постоянно отслеживая списки контроля доступа, что на самом деле делается очень редко либо вообще никогда.
Рассмотрим три самых распространенных варианта использования метода.

Первый вариант — когда оператор предоставляет учетной записи полный контроль над группой «Администраторы домена».

18.jpg


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

Второй вариант — когда оператор предоставляет учетной записи разрешение «Сбросить пароль» для другой учетной записи из группы «Администраторы домена».

19.jpg


И третий вариант — когда оператор предоставляет учетной записи привилегии на репликацию изменений каталога.

20.jpg


Любой пользователь с таким разрешением имеет возможность реплицировать любые объекты, включая пароли. Это дает оператору право на выполнение атаки DCSync.

Directory Services Restore Mode.
Каждый контроллер домена имеет внутреннюю учетную запись локального администратора. Она называется учетной записью режима восстановления служб каталогов (DSRM).
Причем пароль для данной учетной записи редко подлежит изменению, так как основной способ сделать это на контроллере домена заключается в запуске инструмента командной строки ntdsutil.

Есть возможность синхронизировать пароль DSRM на контроллере домена с определенной учетной записью домена. Установить пароль можно, выполнив последовательно следующие команды.

Код:
> ntdsutil
: set dsrm password
: reset password on server null
: []
: q
: q

21.jpg


Но дело в том, что пользователь DSRM по умолчанию — это «Администратор». Таким образом, их пароли совпадают.
Но оператор может связать пользователя DSRM с любым другим пользователем домена.

Код:
> ntdsutil
: set dsrm password
: sync from domain account [пользователь]
: q
: q

22.jpg


После того как удалось связать учетную запись DSRM с другой учетной записью, определимся, как ее можно использовать. Первым делом добавим свойство DsrmAdminLogonBehavior в HKLM:\System\CurrentControlSet\Control\Lsa\. Возможные значения:
  • 0 (по умолчанию): можно использовать учетную запись DSRM, только если DC запущен в DSRM;
  • 1: можно использовать учетную запись DSRM для входа в систему, если локальная служба AD остановлена;
  • 2: всегда можно использовать учетную запись DSRM.
Для авторизации по сети (ведь это запись администратора DSRM) нам необходимо выставить значение 2.

Код:
PS> New-ItemProperty "HKLM:\System\CurrentControlSet\Control\Lsa\" -Name "DsrmAdminLogonBehavior" -Value 2 -PropertyType DWORD

23.jpg

24.jpg


При этом оператору не нужно знать пароль пользователя, достаточно хеша пароля (для 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

25.jpg


В результате этих действий появился еще один пароль, который также работает для пользователя: mimikatz.

26.jpg

27.jpg


При этом данный пароль подходит для авторизации под абсолютно любой учетной записью пользователя домена.

28.jpg

29.jpg


Стоит также упомянуть и LSA. При внедрении бэкдора может появиться следующая ошибка.

30.jpg


Чтобы избежать этого, нам нужно выполнить атаку в обход LSA. Но и это несложно сделать с помощью mimikatz.

Код:
mimikatz # privilege::debug
mimikatz # !+
mimikatz # !processprotect /process:lsass.exe /remove
mimikatz # misc::skeleton

31.jpg


Заключение.
Можно сказать, что Skeleton Key — это метод, который оператор может использовать для доступа к хостам и сетевым ресурсам без необходимости взламывать пароли пользователей домена.
Полученный этим способом доступ сохраняется после смены паролей всех пользователей (включая администраторов) до перезагрузки контроллера домена.

От ТС:
Оригинал вот - https://xakep.ru/2020/05/15/windows-ad-backdoor/
Если есть ошибки, пишите, исправлю.
 
По скелетону, если несколько DC в сетке нужно на каждом запускать или достаточно на PDC ?Запустил, все вроде отработало, но пасс не подходит для RDP
 


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх