Зачем этот пост?
Цель этого руководства — рассмотреть Active Directory с точки зрения злоумышленника. Я попытаюсь рассмотреть различные аспекты Active Directory и те термины, которые должен контролировать каждый пентестер, чтобы понять атаки, которые могут быть выполнены в сети Active Directory.
Чтобы понять, как атаковать Active Directory (и любую другую технологию), я думаю, важно знать не только инструменты, но и то, как они работают, какие протоколы/механизмы они используют и почему эти механизмы/протоколы существуют.
Информация, представленная здесь, взята из открытых источников и моего собственного опыта работы с Active Directory. Тем не менее, я не могу быть уверен, что все изложенное здесь верно, поэтому вам предлагается выполнить собственный тест и, если вы обнаружите какую-либо ошибку, сообщите мне об этом (zer1t0ps@protonmail.com)
Более того, я знаю, что здесь описано не все об Active Directory, но я намерен охватить хотя бы базовые знания, необходимые для понимания Active Directory и их атак, и расширить этот источник в будущем. Итак, если вы чувствуете, что я упускаю что-то, что пентестер должен знать, связанный с Active Directory, пожалуйста, дайте мне знать ( zer1t0ps@protonmail.com)
Отказ от ответственности: Все это делается в образовательных целях, и вы должны применять описанные здесь атаки только к системам, для которых у вас есть разрешение.
Я попытался объяснить темы, присутствующие здесь, насколько я мог. Однако каждая тема сложна, поэтому я привожу как можно больше ссылок на внешние ресурсы. Мое основное намерение состоит в том, чтобы собрать всю информацию по Active Directory в одном месте, которое можно использовать для консультаций по атакам/протоколам/методам, а не просто объяснять каждую деталь конкретной техники (даже если я попытаюсь это сделать). Так что вам настоятельно рекомендуется перейти по гиперссылкам, чтобы узнать больше о конкретной теме, там есть отличные ресурсы.
Кстати, я хотел бы поблагодарить всех создателей контента, которые на протяжении многих лет делились знаниями с сообществом с помощью инструментов, блогов, выступлений на конференциях и т. д. Я ознакомился со столькими ресурсами, что мне было бы невозможно поблагодарить всех создателей контента одного за другим, но если вы найдете ссылку на один из ваших ресурсов или ресурс, с которым вы сотрудничали напрямую (путем добавления функции в инструмент, или помочь вашему другу написать пост) или косвенно (например, создание библиотеки/фрагмента/языка/ОС/IDE/редактора, который используется инструментом или блогом, который используется в качестве основы для поста, связанного здесь), спасибо .
На протяжении всей статьи я буду использовать Powershell, чтобы показать, как получить информацию из Active Directory. Для этой цели я буду использовать модуль ActiveDirectory Powershell (https://docs.microsoft.com/en-us/powershell/module/addsadministration/?view=windowsserver2019-ps), но вместо него можно использовать другие инструменты, такие как Powerview (https://github.com/BC-SECURITY/Empire/blob/master/data/module_source/situational_awareness/network/powerview.ps1) или ldapsearch (https://docs.ldap.com/ldap-sdk/docs/tool-usages/ldapsearch.html ) .
Теперь давайте перейдем к делу.
Что такое Active Directory?
С моей точки зрения, Active Directory — это система, которая позволяет управлять набором компьютеров и пользователей, подключенных к одной сети, с центрального сервера.
Конечно, это определение далеко не совсем точное, но я надеюсь, что оно достаточно простое, чтобы дать вам представление о том, что такое AD.
Представьте себе компанию с сотнями сотрудников, где каждый работает на своем (вероятно, Windows) компьютере. В этой компании есть несколько разных отделов, таких как продажи, отдел кадров, ИТ и т. д.
Теперь представьте, что отделу продаж требуется установить новую программу на своих рабочих станциях. Или что каждый день пользователь в другом офисе забывает свой пароль, и его нужно восстановить. Или что новая группа стажеров должна работать только с несколькими документами файлового сервера.
Должна ли ИТ-группа устанавливать программу на все рабочие станции отдела продаж одну за другой? Должны ли они пойти в разные офисы и восстановить пароль пользователя? Должны ли они создавать нового пользователя для каждого стажера на файловом сервере, который позволяет просматривать файлы только в каталоге?
Ну, они могли бы это сделать, хотя это заняло много времени и работы (и пустая трата денег для компании). Но поскольку они умные люди, у них все компьютеры подключены к сети Active Directory, поэтому они могут выполнять все эти операции со своей рабочей станции.
Active Directory позволяет это за счет ведения централизованной базы данных, в которой хранится вся информация о пользователях, компьютерах, политиках, разрешениях и т. д. Так, например, ИТ-команда может подключиться к этой базе данных и создать новых пользователей для стажеров и назначить им разрешения на чтение файлов только в указанных каталогах определенных серверов их отделов.
Затем, когда один из этих стажеров пытается войти на компьютер в сети Active Directory, компьютер обращается к центральной базе данных, чтобы проверить, существует ли стажер-пользователь (и правильно ли введен пароль). Таким образом, пользователи могут входить на любой из компьютеров компании (если у них есть разрешения), позволяя сотрудникам использовать только пользователя для выполнения всей своей работы на всех компьютерах компании (это могут быть рабочие станции, серверы баз данных, файловые серверы, так далее).
Аналогичным образом, если пользователь забывает свой пароль, он может сообщить об этом ИТ-команде, и они могут изменить пароль пользователя в этой центральной базе данных (и пользователю предлагается изменить этот пароль на новый, который знает только он).
В случае отдела продаж ИТ-отдел может создать новую политику в базе данных, которая указывает, что компьютеры этого отдела должны установить указанную программу, и как они должны это делать. Затем, когда рабочая станция продавцов прочтет базу данных, они узнают, что должны выполнить эту политику, и будет установлена новая программа.
Я надеюсь, что этот пример позволит вам понять, почему Active Directory так полезна и почему ее использует практически любая организация (средняя и большая) в мире. Вероятно, вы использовали его, обычно с компьютера, который требует от вас нажатия Ctrl+Alt+Del перед запросом имени пользователя и пароля.
И… что произойдет, если кто-то сможет украсть пароль ИТ-пользователя? Может ли она изменить пароли других пользователей? А доступ к базе?
Теперь понятно, почему Active Directory так важна, давайте представим их элементы.
Домены
Во-первых, то, что мы называем сетью Active Directory, обычно называют доменом. Домен — это набор подключенных компьютеров, которые совместно используют базу данных Active Directory, которой управляют центральные серверы домена, называемые контроллерами домена.
Доменное имя
У каждого домена есть DNS-имя. Во многих компаниях имя домена совпадает с именем их веб-сайта, например, contoso.com, а другие имеют другой внутренний домен, например contoso.local.
PS C:\Users\Anakin> $env:USERDNSDOMAIN
CONTOSO.LOCAL
PS C:\Users\Anakin> (Get-ADDomain).DNSRoot
contoso.local
PS C:\Users\Anakin> (Get-WmiObject Win32_ComputerSystem).Domain
contoso.local
В дополнение к DNS-имени каждый домен также можно идентифицировать по NetBIOS-имени. Например, домен contoso.local может иметь NetBIOS-имя CONTOSO. Вы можете увидеть имя NetBIOS, используемое в операциях входа в систему, где пользователь идентифицируется чем-то вроде CONTOSO\Administrator, где первая часть — это имя NetBIOS, а вторая — имя пользователя.
Наконец, домен можно идентифицировать по его SID (идентификатору безопасности). SID больше используется программами (использующими Windows API), чем пользователями, но вы должны знать, как его получить, если он вам понадобится.
PS C:\Users\Anakin> Get-ADDomain | select DNSRoot,NetBIOSName,DomainSID
DNSRoot NetBIOSName DomainSID
------- ----------- ---------
contoso.local CONTOSO S-1-5-21-1372086773-2238746523-2939299801
Леса
Использование DNS-имени очень полезно, так как оно позволяет создавать поддомены для целей управления. Например, у компании может быть корневой домен contoso.local, а затем субдомены для разных (обычно крупных) отделов, например it.contoso.local или sales.contoso.local.
Как вы заметили, Active Directory предлагает множество способов организации вашей инфраструктуры, поэтому то, как организация использует поддомены, варьируется от одного к другому, некоторые создают поддомены для отделов, а другие используют их для разных офисов.
Это дерево доменов известно как Лес (https://docs.microsoft.com/en-us/windows/win32/ad/forests). Имя леса совпадает с именем корневого домена дерева.
PS C:\Users\Anakin> Get-ADForest
ApplicationPartitions : {DC=DomainDnsZones,DC=contoso,DC=local, DC=ForestDnsZones,DC=contoso,DC=local}
CrossForestReferences : {}
DomainNamingMaster : dc01.contoso.local
Domains : {contoso.local}
ForestMode : Windows2016Forest
GlobalCatalogs : {dc01.contoso.local, dc02.contoso.local}
Name : contoso.local
PartitionsContainer : CN=Partitions,CN=Configuration,DC=contoso,DC=local
RootDomain : contoso.local
SchemaMaster : dc01.contoso.local
Sites : {Default-First-Site-Name}
SPNSuffixes : {}
UPNSuffixes : {}
В лесу у каждого домена есть своя база данных и свои собственные контроллеры домена. Однако пользователи домена в лесу также могут получить доступ к другим доменам леса.
Это означает, что, даже если домен может быть автономным, без необходимости взаимодействия с другими доменами, он не изолирован с точки зрения безопасности, поскольку, как мы увидим, пользователь из домена может получить доступ к ресурсам других доменов в том же домене. лес (по умолчанию). Однако по умолчанию пользователи леса не могут получить доступ к ресурсам из других лесов, поэтому логической структурой, которая может обеспечить изоляцию безопасности, является лес.
Как я уже говорил, у каждого домена есть свои собственные контроллеры домена, поэтому, если отдел невероятно разрастается, вам могут понадобиться выделенные контроллеры домена, которые обрабатывают запросы всех компьютеров в этом отделе. Вы можете добиться этого, создав новый поддомен, и пользователи по-прежнему смогут получать доступ к компьютерам в других поддоменах того же леса.
Функциональные режимы
Как и компьютеры Windows, домены/леса также могут иметь свою "версию", которая называется функциональным режимом (https://docs.microsoft.com/en-us/tr...ive-directory-domain-forest-functional-levels). В зависимости от режима домена/леса могут использоваться новые характеристики.
Названия режимов основаны на минимальной операционной системе Windows Server, необходимой для работы с ними. Существуют следующие функциональные режимы( https://docs.microsoft.com/en-us/op.../ms-adts/564dc969-6db3-49b3-891a-f2f8d0a68a7f) :
Windows2000
Windows2000MixedDomains
Windows2003
Windows2008
Windows2008R2
Windows2012
Windows2012R2
Windows2016
PS C:\Users\Administrator\Downloads> (Get-ADForest).ForestMode
Windows2016Forest
PS C:\Users\Administrator\Downloads> (Get-ADDomain).DomainMode
Windows2016Domain
Затем, если, например, вы найдете домен/лес с режимом Windows2012, вы можете знать, что все контроллеры домена имеют как минимум Windows Server 2012. Вы должны знать о режиме, чтобы использовать некоторые характеристики домена, например, для группы "Защищенные пользователи" требуется режим Windows2012R2.
Доверие
Пользователи могут получить доступ к другим доменам в тех же лесах, поскольку они связаны соединениями, называемыми трастами.
Доверие — это соединение одного домена с другим (https://docs.microsoft.com/en-us/pr...ows-server-2008-r2-and-2008/cc731335(v=ws.10)). Не физическое сетевое соединение, а своего рода соединение для аутентификации/авторизации. Вы можете получить доступ к компьютерам в сети, которые находятся в других доменах, но вы не можете войти на эти компьютеры под своим пользователем этого домена. Это то, что доверие позволяет вам делать.
Направление доверия
Доверие – это направленное отношение, при котором одна сторона является доверяющей, а другая – доверенной. Когда эта ссылка установлена, пользователи доверенного домена могут получить доступ к ресурсам доверенного домена.
Направление доверия противоположно направлению доступа (https://docs.microsoft.com/en-us/pr...ows-server-2008-r2-and-2008/cc731404(v=ws.10). Вы можете думать, что если вы доверяете своей подруге, вы позволяете ей получить доступ к вашему дому и есть вашу еду, когда она в ней нуждается.
Когда доверие направляется через ваш текущий домен, оно называется входящим или входящим доверием. Входящие доверительные отношения позволяют пользователям вашего домена получать доступ к другому домену.
С другой стороны, существуют исходящие или исходящие доверительные отношения, которые переходят из вашего домена в другой. Поэтому пользователи другого домена могут получить доступ к вашему домену.
И когда два домена связаны как входящим, так и исходящим доверием, говорят, что они связаны двунаправленным доверием (даже если на самом деле существует два доверия).
Вы можете увидеть доверительные отношения вашего домена с помощью nltest /domain_trusts.
PS C:\Users\Administrator> nltest /domain_trusts
List of domain trusts:
0: CONTOSO contoso.local (NT 5) (Direct Outbound) ( Attr: foresttrans )
1: ITPOKEMON it.poke.mon (NT 5) (Forest: 2) (Direct Outbound) (Direct Inbound) ( Attr: withinforest )
2: POKEMON poke.mon (NT 5) (Forest Tree Root) (Primary Domain) (Native)
The command completed successfully
Здесь мы видим, что наш текущий домен — poke.mon (причина атрибута (основной домен)) и есть пара доверий. Исходящее доверие с contoso.local указывает, что его пользователи могут получить доступ к нашему домену, poke.mon. Более того, существует второй двунаправленный траст с it.poke.mon, который является субдоменом poke.mon и находится в том же лесу.
PS C:\Users\Anakin> nltest /domain_trusts
List of domain trusts:
0: POKEMON poke.mon (NT 5) (Direct Inbound) ( Attr: foresttrans )
1: CONTOSO contoso.local (NT 5) (Forest Tree Root) (Primary Domain) (Native)
The command completed successfully
Следовательно, если мы проверим доверие contoso.local, мы увидим входящее соединение от poke.mon, что согласуется с предыдущей информацией. Таким образом, пользователи contoso.local могут получить доступ к poke.mon.
Доверие транзитивности
Кроме того, траст может быть транзитивным или нетранзитивным (https://docs.microsoft.com/en-us/pr...ows-server-2008-r2-and-2008/cc754612(v=ws.10) ). Нетранзитивное доверие может использоваться только двумя сторонами доверия, доверяющей и доверенной. Принимая во внимание, что транзитивное доверие может действовать как мост и использоваться для третьих доменов, связанных с доменами, которые связаны транзитивным доверием.
Например, если доверие между доменом A и доменом B является транзитивным, то пользователи домена C могут получить доступ к домену A, пересекая оба доверия. Если отношение Домен A --> Домен B было нетранзитивным, пользователи домена C не могли бф получить доступ к домену A, а пользователи домена B могли.
Следовательно, в отношении доменов в одном лесу все пользователи доменов могут получить доступ к другим доменам, потому что все родительские и дочерние домены связаны через двунаправленные транзитивные доверительные отношения. Таким образом, любой домен леса может пройти необходимые доверительные отношения для доступа к другому домену в том же лесу.
В лесу, чтобы разрешить доступ из любого домена к любому другому, все родительские и дочерние домены связаны двунаправленным транзитивным доверием.
Таким образом, чтобы получить доступ к компьютерам hr.contoso.local, пользователь webs.it.contoso.local должен пройти три доверия.
Типы доверия
В Active Directory существует несколько типов доверия (https://docs.microsoft.com/en-us/pr...008-r2-and-2008/cc730798(v=ws.10)#trust-types) для разных целей:
-Parent-Child: доверительные отношения по умолчанию, созданные между родительским доменом и его дочерним.
- Forest : траст для обмена ресурсами между лесами. Таким образом, любой домен леса может получить доступ к любому домену другого леса (если это позволяют направление и транзитивность доверия). Если доверие леса настроено неправильно, оно может позволить получить контроль над другим лесом. ( http://www.harmj0y.net/blog/redteaming/not-a-security-boundary-breaking-forest-trusts/)
- External : доверие для подключения к определенному домену, который находится в недоверенном лесу.
- Realm: специальное доверие для соединения Active Directory и домена, отличного от Windows.
-Shortcut: когда два домена в лесу часто взаимодействуют, но не связаны напрямую, вы можете избежать перехода через множество доверительных отношений, создав прямое сокращенное доверие.
Ключ доверия
Технически, когда вы используете доверие, существует связь между контроллером домена вашего домена и контроллером домена целевого домена (или промежуточного домена).
Способ установления связи зависит от используемого протокола (это может быть NTLM, Kerberos и т. д.), но в любом случае контроллеры домена должны совместно использовать ключ для обеспечения безопасности связи. Этот ключ известен как ключ доверия и создается при установлении доверия.
Когда создается доверие, в базе данных домена создается доверительная учетная запись (
) как если бы это был пользователь (с именем, заканчивающимся $). Затем ключ доверия сохраняется, как если бы он был паролем доверенного пользователя (в хэше NT
и ключах Kerberos (https://zer1t0.gitlab.io/posts/attacking_ad/#user-kerberos-keys ).
Подробнее о доверии
Чтобы узнать, как можно злоупотреблять доверием в пентесте, вы можете проверить следующие сообщения (для их прочтения также рекомендуется небольшое знание Kerberos):
- Все дело в доверии — подделка билетов доверия Kerberos для подмены доступа через доверительные отношения Active Directory (https://adsecurity.org/?p=1588 )
- Руководство по атаке доменных трастов -(http://www.harmj0y.net/blog/redteaming/a-guide-to-attacking-domain-trusts/ )
- Доверия леса Active Directory, часть 1. Как работает фильтрация SID? (https://dirkjanm.io/active-directory-forest-trusts-part-one-how-does-sid-filtering-work/)
- Inter-Realm Key Roasting (well… within the first 30 days) (https://blog.xpnsec.com/inter-realm-key-roasting/)
-Не граница безопасности: нарушение лесных трастов (http://www.harmj0y.net/blog/redteaming/not-a-security-boundary-breaking-forest-trusts/)
Пользователи
Одним из ключевых моментов использования Active Directory является управление пользователями. Каждая организация управляет своими пользователями по-разному, устанавливая для них форматы имен, назначая разные разрешения и т. д.
Чтобы упростить управление пользователями в Active Directory, они хранятся в виде объектов в центральной базе данных, с которыми можно консультироваться и манипулировать ими из любой точки домена (если у вас достаточно прав).
Свойства пользователя
Идентификаторы пользователей
Пользовательский объект хранит множество различных данных, но в первую очередь следует учитывать те атрибуты, которые позволяют нам идентифицировать пользователя.
Для идентификации пользователя обычно используется имя пользователя, которое хранится в атрибуте SamAccountName. Кроме того, SID (идентификатор безопасности) также может использоваться для идентификации пользователя.
SID пользователя похож на SID домена и фактически представляет собой комбинацию SID домена и RID пользователя (относительный идентификатор), который является последним числом, которое появляется в SID пользователя.
PS C:\Users\Anakin> Get-ADUser Anakin
DistinguishedName : CN=Anakin,CN=Users,DC=contoso,DC=local
Enabled : True
GivenName : Anakin
Name : Anakin
ObjectClass : user
ObjectGUID : 58ab0512-9c96-4e97-bf53-019e86fd3ed7
SamAccountName : anakin
SID : S-1-5-21-1372086773-2238746523-2939299801-1103
Surname :
UserPrincipalName : anakin@contoso.local
В этом случае SID домена — S-1-5-21-1372086773-2238746523-2939299801, а RID пользователя — 1103. Некоторые инструменты отображают SID в своих выходных данных вместо имени пользователя (поскольку оно используется в некоторых структурах, таких как дескрипторы безопасности), поэтому вам следует знать его формат, чтобы идентифицировать его. (https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-security_descriptor)
Кроме того, DistinguishedName используется API LDAP для идентификации объектов (https://docs.microsoft.com/en-us/previous-versions/windows/desktop/ldap/distinguished-names), поэтому, если вы запрашиваете базу данных с помощью LDAP (что является одним из наиболее распространенных способов), вы, вероятно, увидите ссылки на объекты через его DistinguishedName.
Секреты пользователя
Кроме того, база данных также должна хранить секреты пользователя, чтобы позволить контроллеру домена аутентифицировать пользователя. Пароль пользователя не хранится в открытом виде, но сохраняются следующие полученные из него секреты:
-NT хеш (и LM хеш для старых учетных записей)
-Керберос ключи
Излишне говорить, что пользовательские секреты не могут быть получены пользователями без прав администратора. Даже компьютеры домена не могут получить к ним доступ, но оставляют аутентификацию контроллеру домена.
Чтобы получить пользовательские секреты, вам нужны права администратора (или эквивалентные) для создания дампа базы данных домена с помощью атаки dcsync или захвата файла C:\Windows\NTDS\ntds.dit с контроллера домена.
Хэши LM/NT
Хэши LM и NT (https://medium.com/@petergombos/lm-ntlm-net-ntlmv2-oh-my-a9b235c58ed4) хранятся как в локальной базе данных SAM Windows (https://en.wikipedia.org/wiki/Security_Account_Manager), так и в базе данных Active Directory NTDS для аутентификации локальных пользователей и пользователей домена соответственно. Эти хэши, как LM, так и NT, имеют длину 16 байт.
Password: 123456
LM hash: 44EFCE164AB921CAAAD3B435B51404EE
NT hash: 32ED87BDB5FDC5E9CBA88547376818D4
Однако хэши LM довольно слабые (https://en.wikipedia.org/wiki/LAN_Manager#Security_weaknesses), поэтому они не используются, начиная с Windows Vista/Server 2008. Процедура создания хэша LM следующая (https://asecuritysite.com/encryption/lmhash) :
1. Преобразуйте пароль пользователя в верхний регистр. (Это уменьшает пространство поиска для атаки полным перебором).
2. Если пароль пользователя меньше 14 символов, он дополняется символами NULL, пока длина не станет 14.
Если пароль больше 14 символов, то он усекается. (Бесполезно иметь пароли более 14 символов).
3. Затем пароль разбивается на две строки по 7 байт каждая.
4. Каждая 7-байтовая строка используется в качестве ключа для шифрования строки KGS!+#$% с использованием криптографического алгоритма DES. В результате получается два хэша.
5. Два результирующих значения объединяются для формирования хэша LM. (можно взломать каждую часть отдельно)
upper_password = to_uppercase(password)
14_password = truncate_to_14_bytes(upper_password)
7_part1, 7_part2 = split_7(14_password)
hash1 = des(7_part1, "KGS!+#$%")
hash2 = des(7_part2, "KGS!+#$%")
lm_hash = hash1 + hash2
С другой стороны, хэш NT немного сильнее (https://en.wikipedia.org/wiki/Salt_(cryptography)), но для его вычисления не используется соль, поэтому его можно взломать, используя предварительно вычисленные значения (например, радужные таблицы (https://en.wikipedia.org/wiki/Rainbow_table)).
Если вам интересно, хэш NT вычисляется путем применения алгоритма MD4 (https://en.wikipedia.org/wiki/MD4 )(который устарел (https://tools.ietf.org/html/rfc6150)) непосредственно к версии Unicode (в частности, кодировке UTF-16LE) пароля пользователя.
nt_hash = md4(encode_in_utf_16le(password))
Много раз хэш NT называется хэшем NTLM, однако это может сбивать с толку, поскольку протокол NTLM также использует хэши, называемые хешами NTLM. В этой статье хеш NTLM будет хэшем протокола NTLM.
Многие инструменты позволяют извлекать хэши LM и NT и обычно возвращают вывод с несколькими строками, по одной на пользователя, в формате <username>:<rid>:<LM>:<NT>:::. Если LM не используется, его значение будет aad3b435b51404eeaad3b435b51404ee (LM-хэш пустой строки).
Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
WDAGUtilityAccount:504:aad3b435b51404eeaad3b435b51404ee:6535b87abdb112a8fc3bf92528ac01f6:::
user:1001:aad3b435b51404eeaad3b435b51404ee:57d583aa46d571502aad4bb7aea09c70:::
Для пентестера важно распознавать хэши NT, поскольку, даже если они не являются паролями пользователей, они используются для аутентификации на машинах Windows, поэтому они очень полезны. Их можно использовать для выполнения атак Pass-The-Hash или Overpass-the-Hash, чтобы выдавать себя за пользователей на удаленных машинах.
Кроме того, вы можете попытаться взломать хэши LM и NT с помощью hashcat (https://hashcat.net/), чтобы восстановить исходный пароль. Если вам повезло и LM-хеш присутствует, это должно быть быстро.
Ключи Kerberos
Помимо хэшей LM/NT, сохраняются ключи Kerberos, полученные из пароля пользователя и используемые в протоколе аутентификации Kerberos.
Ключи Kerberos можно использовать для запроса билета Kerberos, который представляет пользователя при проверке подлинности Kerberos. Существует несколько разных ключей, и разные используются для разной поддержки шифрования Kerberos:
-Ключ AES 256: используется алгоритмом AES256-CTS-HMAC-SHA1-96 (https://tools.ietf.org/html/rfc3962). Это тот, который обычно используется Kerberos, и его должен использовать пентестер, чтобы избежать срабатывания аварийных сигналов.
-Ключ AES 128: используется алгоритмом AES128-CTS-HMAC-SHA1-96 (https://tools.ietf.org/html/rfc3962).
- Ключ DES: используется устаревшим алгоритмом DES-CBC-MD5 (https://datatracker.ietf.org/doc/html/rfc3961#section-6.2.1).
- Ключ -RC4: это NT-хэш пользователя, используемый алгоритмом RC4-HMAC (https://tools.ietf.org/html/rfc4757).
$ secretsdump.py 'contoso.local/Administrator@192.168.100.2' -just-dc-user anakin
Impacket v0.9.21 - Copyright 2020 SecureAuth Corporation
Password:
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
contoso.local\anakin:1103:aad3b435b51404eeaad3b435b51404ee:cdeae556dc28c24b5b7b14e9df5b6e21:::
[*] Kerberos keys grabbed
contoso.local\anakin:aes256-cts-hmac-sha1-96:ecce3d24b29c7f044163ab4d9411c25b5698337318e98bf2903bbb7f6d76197e
contoso.local\anakin:aes128-cts-hmac-sha1-96:18fe293e673950214c67e9f9fe753198
contoso.local\anakin:des-cbc-md5:fbba85fbb63d04cb
[*] Cleaning up...
Эти ключи можно использовать в атаке Pass-The-Key (
) для получения билета для олицетворяемого пользователя. Затем вы можете использовать этот билет Kerberos для аутентификации в различных службах домена от имени пользователя.
UserAccountControl
Одним интересным свойством пользовательского класса является UserAccountControl (UAC) (не путайте его с механизмом контроля учетных записей (https://docs.microsoft.com/en-us/tr...raccountcontrol-manipulate-account-properties) , чтобы избежать выполнения программ с повышенными правами на компьютерах с Windows).
Свойство UserAccountControl содержит ряд флагов, которые очень важны для безопасности и домена и используются во многих атаках, упомянутых в этом посте. Вот самые актуальные:
- ACCOUNTDISABLE -> Учетная запись отключена и не может быть использована.
- DONT_REQUIRE_PREAUTH -> Учетная запись не требует предварительной аутентификации Kerberos.
- NOT_DELEGATED -> Эта учетная запись не может быть делегирована через делегирование Kerberos.
- TRUSTED_FOR_DELEGATION -> Неограниченное делегирование Kerberos включено для этой учетной записи и ее служб. Для его изменения требуется SeEnableDelegationPrivilege ( http://www.harmj0y.net/blog/actived...-user-right-you-probably-have-never-heard-of/).
- TRUSTED_TO_AUTH_FOR_DELEGATION -> Расширение Kerberos S4U2Self включено для этой учетной записи и ее служб. Для его изменения требуется SeEnableDelegationPrivilege ( http://www.harmj0y.net/blog/actived...-user-right-you-probably-have-never-heard-of/).
Другие свойства пользователя
Есть и другие свойства, которые могут быть полезны в пентесте:
- Description (https://docs.microsoft.com/en-us/windows/win32/adschema/a-description) -> Описание пользователя. Он может дать представление о правах пользователя, а иногда даже включает пароль.
-AdminCount (https://docs.microsoft.com/en-us/windows/win32/adschema/a-admincount)-> Указывает, защищен ли пользователь (или группа) объектом AdminSDHolder, или он был защищен. Поскольку иногда не обновляется, используйте его только как ссылку.
- MemberOf -> Группы, членом которых является пользователь. Это свойство является логическим и генерируется из свойства группы Members.
-PrimaryGroupID (https://docs.microsoft.com/en-us/windows/win32/adschema/a-primarygroupid) -> Основная группа пользователя. Эта группа не отображается в свойстве MemberOf.
-ServicePrincipalName (https://docs.microsoft.com/en-us/windows/win32/adschema/a-serviceprincipalname) -> Службы пользователя. Может быть полезен для атаки Kerberoast.
-msDS-AllowedToDelegateTo( https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-ada2/86261ca1-154c-41fb-8e5f-c6446e77daaa) -> Список служб, для которых пользователь (и его собственные службы) может олицетворять клиентов с помощью ограниченного делегирования Kerberos. Для его изменения требуется SeEnableDelegationPrivilege( http://www.harmj0y.net/blog/actived...-user-right-you-probably-have-never-heard-of/).
Важные пользователи
Для консультации с пользователями есть несколько вариантов, таких как команда net user /domain или Powershell. Нет необходимости иметь специальную привилегию для вывода списка пользователей, это может сделать любой пользователь.
PS C:\Users\Anakin> Get-ADUser -Filter * | select SamAccountName
SamAccountName
--------------
Administrator
Guest
krbtgt
anakin
han
POKEMON$
Как вы могли заметить, мой тестовый домен небольшой, с очень небольшим количеством пользователей, но в реальном взаимодействии будут сотни или тысячи пользователей. Поэтому важно различать, что действительно важно. Это может быть немного сложно, так как это зависит от организации, но обычно члены ИТ-команды используют привилегированных пользователей, им это нужно для работы.
Более того, по умолчанию встроенный пользователь-администратор является самой привилегированной учетной записью домена. Он может выполнять любые действия на любом компьютере. Таким образом, если вам удастся скомпрометировать эту учетную запись, вы получите полный контроль над доменом (и даже над лесом, используя атаку с использованием истории SID (https://adsecurity.org/?p=1640)).
Кроме того, учетная запись krbtgt также очень важна. Его секреты (хэш NT и ключи Kerberos) используются для шифрования билетов (в частности, TGT), используемых Kerberos, что позволяет аутентифицировать пользователей. Если вам удастся скомпрометировать учетную запись krbtgt, вы сможете создавать золотые билеты( https://en.hackndo.com/kerberos-silver-golden-tickets/). Обычно эту учетную запись можно скомпрометировать только путем сброса базы данных домена, поскольку она используется только в контроллерах домена, для чего потребуются права администратора в домене.
Учетные записи компьютеров
Еще одна вещь, которую следует учитывать, это то, что в организации у каждого человека есть свой пользователь, и даже у некоторых людей, таких как ИТ-отдел, может быть несколько пользователей на человека для выполнения различных задач. Более того, также у каждого компьютера домена есть свой пользователь, так как им тоже нужно выполнять свои действия в домене.
Разница между учетными записями пользователей и учетными записями компьютеров заключается в том, что первые хранятся как экземпляры класса User (https://docs.microsoft.com/en-us/windows/win32/adschema/c-user) в базе данных, тогда как другие хранятся как экземпляры класса Computer (https://docs.microsoft.com/en-us/windows/win32/adschema/c-computer), который является подклассом класса User. Кроме того, имена учетных записей компьютеров представляют собой имена хостов компьютеров, заканчивающиеся знаком доллара $.
Вы можете проверить это, выполнив следующую команду:
PS C:\> Get-ADObject -LDAPFilter "objectClass=User" -Properties SamAccountName | select SamAccountName
SamAccountName
--------------
Administrator
Guest
DC01$
krbtgt
anakin
WS01-10$
WS02-7$
DC02$
han
POKEMON$
Как видите, пользователей намного больше, чем при использовании команды Get-ADUser, поскольку теперь включены подклассы класса User. Вы можете оценить, что новые учетные записи заканчиваются знаком доллара и, кажется, имеют имя компьютера. Например, DC01$ и DC02$ для контроллеров домена и WS01-10$ и WS02-7$ для рабочих станций.
Более того, объекты-компьютеры также сохранили информацию об их операционной системе, которую можно получить из атрибутов OperatingSystem или OperatingSystemVersion.
Кроме того, во многих организациях существуют правила выбора имен компьютеров и пользователей, поэтому, если вы в состоянии понять имена, вы можете быть осведомлены об использовании компьютеров и учетных записей пользователей, а также о том, какие из них могут быть привилегированные или содержат доступ к важной информации. Кроме того, вы можете проверить другие атрибуты объектов, такие как Описание, чтобы найти там больше информации (и даже пароли в открытом виде). Для этой цели может быть полезен командлет Find-DomainObjectPropertyOutlier (https://gist.github.com/HarmJ0y/184f9822b195c52dd50c379ed3117993) для Powerview (https://github.com/BC-SECURITY/Empi...e/situational_awareness/network/powerview.ps1).
Аккаунты доверия
Однако есть также учетная запись POKEMON$, которая появляется как в Get-ADUser, так и в Get-ADObject, но имя которой заканчивается знаком доллара. Это может быть обычный пользователь (нет проблем с созданием имен пользователей, заканчивающихся $), однако, как мы видели ранее, существует доверие с доменом poke.mon.
При установлении доверия в каждом домене создается связанный пользовательский объект для хранения ключа доверия. Имя пользователя — это NetBIOS-имя другого домена, заканчивающееся $ (аналогично имени учетной записи компьютера). Например, в случае доверия между доменами FOO и BAR, домен FOO будет хранить ключ доверия в пользователе BAR$, а домен BAR будет хранить его в пользователе FOO$.
PS C:\> Get-ADUser -LDAPFilter "(SamAccountName=*$)" | select SamAccountName
SamAccountName
--------------
POKEMON$
Этот пользовательский объект POKEMON$ используется для хранения ключей доверия, которые являются хэшем NT или ключами Kerberos (один из других используется в зависимости от контекста). Если вы можете получить секреты этой учетной записи ( https://zer1t0.gitlab.io/posts/attacking_ad/Domain database dumping), вы можете создавать билеты Kerberos ( https://adsecurity.org/?p=1588) между областями.
Группы
Но управление пользователями может быть громоздким без групп. Представьте, что у вас есть отдел менеджеров, которому нужен доступ к очень конфиденциальным документам. Следует ли давать разрешение каждому менеджеру по одному? Работы много, но вы справитесь, потому что каждый год добавляется только новый менеджер. Но теперь политика меняется, и менеджеры также должны иметь доступ к документам отдела кадров. Стоит ли менять все разрешения менеджеров по одному? Нет, будет слишком много работы и довольно скучно.
Решение заключается в использовании групп (https://docs.microsoft.com/en-us/wi...ctory-security-groups#default-security-groups). В этом случае у вас может быть группа Менеджер, в которую добавляются пользователи-менеджеры, и при изменении политики вы должны добавлять или удалять разрешения для группы.
Как и пользователи, группы хранятся в базе данных домена. Точно так же их можно идентифицировать по атрибуту SamAccountName или SID.
Вы можете обратиться к базе данных, чтобы составить список групп и их членов.
PS C:\Users\Anakin> Get-ADGroup -Filter * | select SamAccountName
SamAccountName
--------------
Administrators
Users
Guests
<-- stripped output -->
Domain Computers
Domain Controllers
Schema Admins
Enterprise Admins
Cert Publishers
Domain Admins
Domain Users
<-- stripped output -->
Protected Users
Key Admins
Enterprise Key Admins
DnsAdmins
DnsUpdateProxy
DHCP Users
DHCP Administrators
Важные группы
Административные группы
В Active Directory существует множество групп по умолчанию (https://docs.microsoft.com/en-us/wi...ctory-security-groups#default-security-groups), определенных для разных ролей в домене/лесу. Для злоумышленника одной из самых привлекательных групп является группа "Администраторы домена" ( https://docs.microsoft.com/en-us/wi...e-directory-security-groups#bkmk-domainadmins), которая дает права администратора своим членам в домене, поэтому важно знать, кто является этой группой.
PS C:\Users\Anakin> Get-ADGroup "Domain Admins" -Properties members,memberof
DistinguishedName : CN=Domain Admins,CN=Users,DC=contoso,DC=local
GroupCategory : Security
GroupScope : Global
MemberOf : {CN=Denied RODC Password Replication Group,CN=Users,DC=contoso,DC=local,
CN=Administrators,CN=Builtin,DC=contoso,DC=local}
Members : {CN=Administrator,CN=Users,DC=contoso,DC=local}
Name : Domain Admins
ObjectClass : group
ObjectGUID : ac3ac095-3ea0-4922-8130-efa99ba99afa
SamAccountName : Domain Admins
SID : S-1-5-21-1372086773-2238746523-2939299801-512
Но есть и другие важные группы, которые могут дать вам много привилегий, а некоторые даже больше. Это относится к группе Enterprise Admins (https://docs.microsoft.com/en-us/wi...tive-directory-security-groups#bkmk-entadmins), которая предоставляет права администратора во всем лесу.
Администраторы предприятия — это группа, которая существует только в корневом домене леса, но по умолчанию добавляется в группу администраторов всех доменов леса. (https://docs.microsoft.com/en-us/wi...tive-directory-security-groups#administrators)
С другой стороны, группа "Администраторы домена" добавляется в группу "Администраторы" домена, а также в группы "Администраторы" компьютеров домена.
Другие важные группы
Но есть и другие важные группы (https://adsecurity.org/?p=3700), которые необходимо учитывать:
DNS-администраторы
Группа DNSAdmins (https://docs.microsoft.com/en-us/wi...tive-directory-security-groups#bkmk-dnsadmins) может разрешить своим членам выполнять код в контроллерах домена (https://www.semperis.com/blog/dnsadmins-revisited/) как SYSTEM с помощью произвольной библиотеки DLL.
Защищенные пользователи
Группа Защищенные пользователи (https://docs.microsoft.com/en-us/wi...and-management/protected-users-security-group) позволяет обеспечить безопасность учетных записей. Их участникам запрещается:
- Аутентифицироваться с помощью NTLM (только Kerberos).
- Использовать типы шифрования DES или RC4 в предварительной аутентификации Kerberos.
- Быть делегированным с неограниченным или ограниченным делегированием.
- Обновлять TGT Kerberos по истечении первоначального четырехчасового срока службы.
Это может помешать попыткам злоупотребления этой учетной записью с помощью ретрансляции NTLM (https://en.hackndo.com/ntlm-relay/) или атак делегирования Kerberos (https://www.tarlogic.com/en/blog/kerberos-iii-how-does-delegation-work/).
Администраторы схемы
Администраторы схемы( https://docs.microsoft.com/en-us/wi...ctive-directory-security-groups#schema-admins) могут изменять схему базы данных Active Directory.
Операторы Аккаунтов
Группа Операторы учетных записей (https://docs.microsoft.com/en-us/wi...rectory-security-groups#bkmk-accountoperators) может изменять членов многих групп домена, за исключением многих групп администраторов. Однако он может изменить группу операторов сервера.
Операторы резервного копирования
Члены резервных операторов (https://docs.microsoft.com/en-us/wi...ve-directory-security-groups#backup-operators) могут создавать резервные копии и восстанавливать файлы в контроллерах домена (они также могут входить в них). Это может позволить изменять файлы в контроллерах домена.
Операторы печати
Операторы печати (https://docs.microsoft.com/en-us/wi...ive-directory-security-groups#print-operators) могут входить в контроллеры домена.
Операторы сервера
Операторы сервера (https://docs.microsoft.com/en-us/wi...ve-directory-security-groups#server-operators) могут входить в контроллеры домена и управлять его конфигурацией.
Пользователи удаленного рабочего стола
Члены пользователей удаленного рабочего стола (https://docs.microsoft.com/en-us/wi...ctory-security-groups#bkmk-remotedesktopusers) могут войти в контроллер домена через RDP.
Владельцы создателей групповой политики
Члены владельцев-создателей групповой политики (https://docs.microsoft.com/en-us/wi...y-security-groups#group-policy-creator-owners) могут редактировать объекты групповой политики в домене.
Есть много других групп, описанных в документах Microsoft (https://docs.microsoft.com/en-us/wi...l/active-directory-security-groups#replicator). Более того, многие организации добавляют настраиваемые группы, которые также могут быть очень привилегированными, например, используемые членами ИТ.
Кроме того, многие программы (особенно программы Microsoft) добавляют свои собственные группы для управления, такие как Exchange, которые могут добавлять привилегированные группы (https://adsecurity.org/?p=4119) , такие как Exchange Windows Permissions, которые могут позволить пользователю выполнять атаку DCSync (если они не обновлены должным образом).
Цель этого руководства — рассмотреть Active Directory с точки зрения злоумышленника. Я попытаюсь рассмотреть различные аспекты Active Directory и те термины, которые должен контролировать каждый пентестер, чтобы понять атаки, которые могут быть выполнены в сети Active Directory.
Чтобы понять, как атаковать Active Directory (и любую другую технологию), я думаю, важно знать не только инструменты, но и то, как они работают, какие протоколы/механизмы они используют и почему эти механизмы/протоколы существуют.
Информация, представленная здесь, взята из открытых источников и моего собственного опыта работы с Active Directory. Тем не менее, я не могу быть уверен, что все изложенное здесь верно, поэтому вам предлагается выполнить собственный тест и, если вы обнаружите какую-либо ошибку, сообщите мне об этом (zer1t0ps@protonmail.com)
Более того, я знаю, что здесь описано не все об Active Directory, но я намерен охватить хотя бы базовые знания, необходимые для понимания Active Directory и их атак, и расширить этот источник в будущем. Итак, если вы чувствуете, что я упускаю что-то, что пентестер должен знать, связанный с Active Directory, пожалуйста, дайте мне знать ( zer1t0ps@protonmail.com)
Отказ от ответственности: Все это делается в образовательных целях, и вы должны применять описанные здесь атаки только к системам, для которых у вас есть разрешение.
Я попытался объяснить темы, присутствующие здесь, насколько я мог. Однако каждая тема сложна, поэтому я привожу как можно больше ссылок на внешние ресурсы. Мое основное намерение состоит в том, чтобы собрать всю информацию по Active Directory в одном месте, которое можно использовать для консультаций по атакам/протоколам/методам, а не просто объяснять каждую деталь конкретной техники (даже если я попытаюсь это сделать). Так что вам настоятельно рекомендуется перейти по гиперссылкам, чтобы узнать больше о конкретной теме, там есть отличные ресурсы.
Кстати, я хотел бы поблагодарить всех создателей контента, которые на протяжении многих лет делились знаниями с сообществом с помощью инструментов, блогов, выступлений на конференциях и т. д. Я ознакомился со столькими ресурсами, что мне было бы невозможно поблагодарить всех создателей контента одного за другим, но если вы найдете ссылку на один из ваших ресурсов или ресурс, с которым вы сотрудничали напрямую (путем добавления функции в инструмент, или помочь вашему другу написать пост) или косвенно (например, создание библиотеки/фрагмента/языка/ОС/IDE/редактора, который используется инструментом или блогом, который используется в качестве основы для поста, связанного здесь), спасибо .
На протяжении всей статьи я буду использовать Powershell, чтобы показать, как получить информацию из Active Directory. Для этой цели я буду использовать модуль ActiveDirectory Powershell (https://docs.microsoft.com/en-us/powershell/module/addsadministration/?view=windowsserver2019-ps), но вместо него можно использовать другие инструменты, такие как Powerview (https://github.com/BC-SECURITY/Empire/blob/master/data/module_source/situational_awareness/network/powerview.ps1) или ldapsearch (https://docs.ldap.com/ldap-sdk/docs/tool-usages/ldapsearch.html ) .
Теперь давайте перейдем к делу.
Что такое Active Directory?
С моей точки зрения, Active Directory — это система, которая позволяет управлять набором компьютеров и пользователей, подключенных к одной сети, с центрального сервера.
Конечно, это определение далеко не совсем точное, но я надеюсь, что оно достаточно простое, чтобы дать вам представление о том, что такое AD.
Представьте себе компанию с сотнями сотрудников, где каждый работает на своем (вероятно, Windows) компьютере. В этой компании есть несколько разных отделов, таких как продажи, отдел кадров, ИТ и т. д.
Теперь представьте, что отделу продаж требуется установить новую программу на своих рабочих станциях. Или что каждый день пользователь в другом офисе забывает свой пароль, и его нужно восстановить. Или что новая группа стажеров должна работать только с несколькими документами файлового сервера.
Должна ли ИТ-группа устанавливать программу на все рабочие станции отдела продаж одну за другой? Должны ли они пойти в разные офисы и восстановить пароль пользователя? Должны ли они создавать нового пользователя для каждого стажера на файловом сервере, который позволяет просматривать файлы только в каталоге?
Ну, они могли бы это сделать, хотя это заняло много времени и работы (и пустая трата денег для компании). Но поскольку они умные люди, у них все компьютеры подключены к сети Active Directory, поэтому они могут выполнять все эти операции со своей рабочей станции.
Active Directory позволяет это за счет ведения централизованной базы данных, в которой хранится вся информация о пользователях, компьютерах, политиках, разрешениях и т. д. Так, например, ИТ-команда может подключиться к этой базе данных и создать новых пользователей для стажеров и назначить им разрешения на чтение файлов только в указанных каталогах определенных серверов их отделов.
Затем, когда один из этих стажеров пытается войти на компьютер в сети Active Directory, компьютер обращается к центральной базе данных, чтобы проверить, существует ли стажер-пользователь (и правильно ли введен пароль). Таким образом, пользователи могут входить на любой из компьютеров компании (если у них есть разрешения), позволяя сотрудникам использовать только пользователя для выполнения всей своей работы на всех компьютерах компании (это могут быть рабочие станции, серверы баз данных, файловые серверы, так далее).
Аналогичным образом, если пользователь забывает свой пароль, он может сообщить об этом ИТ-команде, и они могут изменить пароль пользователя в этой центральной базе данных (и пользователю предлагается изменить этот пароль на новый, который знает только он).
В случае отдела продаж ИТ-отдел может создать новую политику в базе данных, которая указывает, что компьютеры этого отдела должны установить указанную программу, и как они должны это делать. Затем, когда рабочая станция продавцов прочтет базу данных, они узнают, что должны выполнить эту политику, и будет установлена новая программа.
Я надеюсь, что этот пример позволит вам понять, почему Active Directory так полезна и почему ее использует практически любая организация (средняя и большая) в мире. Вероятно, вы использовали его, обычно с компьютера, который требует от вас нажатия Ctrl+Alt+Del перед запросом имени пользователя и пароля.
И… что произойдет, если кто-то сможет украсть пароль ИТ-пользователя? Может ли она изменить пароли других пользователей? А доступ к базе?
Теперь понятно, почему Active Directory так важна, давайте представим их элементы.
Домены
Во-первых, то, что мы называем сетью Active Directory, обычно называют доменом. Домен — это набор подключенных компьютеров, которые совместно используют базу данных Active Directory, которой управляют центральные серверы домена, называемые контроллерами домена.
Доменное имя
У каждого домена есть DNS-имя. Во многих компаниях имя домена совпадает с именем их веб-сайта, например, contoso.com, а другие имеют другой внутренний домен, например contoso.local.
PS C:\Users\Anakin> $env:USERDNSDOMAIN
CONTOSO.LOCAL
PS C:\Users\Anakin> (Get-ADDomain).DNSRoot
contoso.local
PS C:\Users\Anakin> (Get-WmiObject Win32_ComputerSystem).Domain
contoso.local
В дополнение к DNS-имени каждый домен также можно идентифицировать по NetBIOS-имени. Например, домен contoso.local может иметь NetBIOS-имя CONTOSO. Вы можете увидеть имя NetBIOS, используемое в операциях входа в систему, где пользователь идентифицируется чем-то вроде CONTOSO\Administrator, где первая часть — это имя NetBIOS, а вторая — имя пользователя.
Наконец, домен можно идентифицировать по его SID (идентификатору безопасности). SID больше используется программами (использующими Windows API), чем пользователями, но вы должны знать, как его получить, если он вам понадобится.
PS C:\Users\Anakin> Get-ADDomain | select DNSRoot,NetBIOSName,DomainSID
DNSRoot NetBIOSName DomainSID
------- ----------- ---------
contoso.local CONTOSO S-1-5-21-1372086773-2238746523-2939299801
Леса
Использование DNS-имени очень полезно, так как оно позволяет создавать поддомены для целей управления. Например, у компании может быть корневой домен contoso.local, а затем субдомены для разных (обычно крупных) отделов, например it.contoso.local или sales.contoso.local.
Как вы заметили, Active Directory предлагает множество способов организации вашей инфраструктуры, поэтому то, как организация использует поддомены, варьируется от одного к другому, некоторые создают поддомены для отделов, а другие используют их для разных офисов.
Это дерево доменов известно как Лес (https://docs.microsoft.com/en-us/windows/win32/ad/forests). Имя леса совпадает с именем корневого домена дерева.
PS C:\Users\Anakin> Get-ADForest
ApplicationPartitions : {DC=DomainDnsZones,DC=contoso,DC=local, DC=ForestDnsZones,DC=contoso,DC=local}
CrossForestReferences : {}
DomainNamingMaster : dc01.contoso.local
Domains : {contoso.local}
ForestMode : Windows2016Forest
GlobalCatalogs : {dc01.contoso.local, dc02.contoso.local}
Name : contoso.local
PartitionsContainer : CN=Partitions,CN=Configuration,DC=contoso,DC=local
RootDomain : contoso.local
SchemaMaster : dc01.contoso.local
Sites : {Default-First-Site-Name}
SPNSuffixes : {}
UPNSuffixes : {}
В лесу у каждого домена есть своя база данных и свои собственные контроллеры домена. Однако пользователи домена в лесу также могут получить доступ к другим доменам леса.
Это означает, что, даже если домен может быть автономным, без необходимости взаимодействия с другими доменами, он не изолирован с точки зрения безопасности, поскольку, как мы увидим, пользователь из домена может получить доступ к ресурсам других доменов в том же домене. лес (по умолчанию). Однако по умолчанию пользователи леса не могут получить доступ к ресурсам из других лесов, поэтому логической структурой, которая может обеспечить изоляцию безопасности, является лес.
Как я уже говорил, у каждого домена есть свои собственные контроллеры домена, поэтому, если отдел невероятно разрастается, вам могут понадобиться выделенные контроллеры домена, которые обрабатывают запросы всех компьютеров в этом отделе. Вы можете добиться этого, создав новый поддомен, и пользователи по-прежнему смогут получать доступ к компьютерам в других поддоменах того же леса.
Функциональные режимы
Как и компьютеры Windows, домены/леса также могут иметь свою "версию", которая называется функциональным режимом (https://docs.microsoft.com/en-us/tr...ive-directory-domain-forest-functional-levels). В зависимости от режима домена/леса могут использоваться новые характеристики.
Названия режимов основаны на минимальной операционной системе Windows Server, необходимой для работы с ними. Существуют следующие функциональные режимы( https://docs.microsoft.com/en-us/op.../ms-adts/564dc969-6db3-49b3-891a-f2f8d0a68a7f) :
Windows2000
Windows2000MixedDomains
Windows2003
Windows2008
Windows2008R2
Windows2012
Windows2012R2
Windows2016
PS C:\Users\Administrator\Downloads> (Get-ADForest).ForestMode
Windows2016Forest
PS C:\Users\Administrator\Downloads> (Get-ADDomain).DomainMode
Windows2016Domain
Затем, если, например, вы найдете домен/лес с режимом Windows2012, вы можете знать, что все контроллеры домена имеют как минимум Windows Server 2012. Вы должны знать о режиме, чтобы использовать некоторые характеристики домена, например, для группы "Защищенные пользователи" требуется режим Windows2012R2.
Доверие
Пользователи могут получить доступ к другим доменам в тех же лесах, поскольку они связаны соединениями, называемыми трастами.
Доверие — это соединение одного домена с другим (https://docs.microsoft.com/en-us/pr...ows-server-2008-r2-and-2008/cc731335(v=ws.10)). Не физическое сетевое соединение, а своего рода соединение для аутентификации/авторизации. Вы можете получить доступ к компьютерам в сети, которые находятся в других доменах, но вы не можете войти на эти компьютеры под своим пользователем этого домена. Это то, что доверие позволяет вам делать.
Направление доверия
Доверие – это направленное отношение, при котором одна сторона является доверяющей, а другая – доверенной. Когда эта ссылка установлена, пользователи доверенного домена могут получить доступ к ресурсам доверенного домена.
Направление доверия противоположно направлению доступа (https://docs.microsoft.com/en-us/pr...ows-server-2008-r2-and-2008/cc731404(v=ws.10). Вы можете думать, что если вы доверяете своей подруге, вы позволяете ей получить доступ к вашему дому и есть вашу еду, когда она в ней нуждается.
Когда доверие направляется через ваш текущий домен, оно называется входящим или входящим доверием. Входящие доверительные отношения позволяют пользователям вашего домена получать доступ к другому домену.
С другой стороны, существуют исходящие или исходящие доверительные отношения, которые переходят из вашего домена в другой. Поэтому пользователи другого домена могут получить доступ к вашему домену.
И когда два домена связаны как входящим, так и исходящим доверием, говорят, что они связаны двунаправленным доверием (даже если на самом деле существует два доверия).
Вы можете увидеть доверительные отношения вашего домена с помощью nltest /domain_trusts.
PS C:\Users\Administrator> nltest /domain_trusts
List of domain trusts:
0: CONTOSO contoso.local (NT 5) (Direct Outbound) ( Attr: foresttrans )
1: ITPOKEMON it.poke.mon (NT 5) (Forest: 2) (Direct Outbound) (Direct Inbound) ( Attr: withinforest )
2: POKEMON poke.mon (NT 5) (Forest Tree Root) (Primary Domain) (Native)
The command completed successfully
Здесь мы видим, что наш текущий домен — poke.mon (причина атрибута (основной домен)) и есть пара доверий. Исходящее доверие с contoso.local указывает, что его пользователи могут получить доступ к нашему домену, poke.mon. Более того, существует второй двунаправленный траст с it.poke.mon, который является субдоменом poke.mon и находится в том же лесу.
PS C:\Users\Anakin> nltest /domain_trusts
List of domain trusts:
0: POKEMON poke.mon (NT 5) (Direct Inbound) ( Attr: foresttrans )
1: CONTOSO contoso.local (NT 5) (Forest Tree Root) (Primary Domain) (Native)
The command completed successfully
Следовательно, если мы проверим доверие contoso.local, мы увидим входящее соединение от poke.mon, что согласуется с предыдущей информацией. Таким образом, пользователи contoso.local могут получить доступ к poke.mon.
Доверие транзитивности
Кроме того, траст может быть транзитивным или нетранзитивным (https://docs.microsoft.com/en-us/pr...ows-server-2008-r2-and-2008/cc754612(v=ws.10) ). Нетранзитивное доверие может использоваться только двумя сторонами доверия, доверяющей и доверенной. Принимая во внимание, что транзитивное доверие может действовать как мост и использоваться для третьих доменов, связанных с доменами, которые связаны транзитивным доверием.
Например, если доверие между доменом A и доменом B является транзитивным, то пользователи домена C могут получить доступ к домену A, пересекая оба доверия. Если отношение Домен A --> Домен B было нетранзитивным, пользователи домена C не могли бф получить доступ к домену A, а пользователи домена B могли.
Следовательно, в отношении доменов в одном лесу все пользователи доменов могут получить доступ к другим доменам, потому что все родительские и дочерние домены связаны через двунаправленные транзитивные доверительные отношения. Таким образом, любой домен леса может пройти необходимые доверительные отношения для доступа к другому домену в том же лесу.
В лесу, чтобы разрешить доступ из любого домена к любому другому, все родительские и дочерние домены связаны двунаправленным транзитивным доверием.
Таким образом, чтобы получить доступ к компьютерам hr.contoso.local, пользователь webs.it.contoso.local должен пройти три доверия.
Типы доверия
В Active Directory существует несколько типов доверия (https://docs.microsoft.com/en-us/pr...008-r2-and-2008/cc730798(v=ws.10)#trust-types) для разных целей:
-Parent-Child: доверительные отношения по умолчанию, созданные между родительским доменом и его дочерним.
- Forest : траст для обмена ресурсами между лесами. Таким образом, любой домен леса может получить доступ к любому домену другого леса (если это позволяют направление и транзитивность доверия). Если доверие леса настроено неправильно, оно может позволить получить контроль над другим лесом. ( http://www.harmj0y.net/blog/redteaming/not-a-security-boundary-breaking-forest-trusts/)
- External : доверие для подключения к определенному домену, который находится в недоверенном лесу.
- Realm: специальное доверие для соединения Active Directory и домена, отличного от Windows.
-Shortcut: когда два домена в лесу часто взаимодействуют, но не связаны напрямую, вы можете избежать перехода через множество доверительных отношений, создав прямое сокращенное доверие.
Ключ доверия
Технически, когда вы используете доверие, существует связь между контроллером домена вашего домена и контроллером домена целевого домена (или промежуточного домена).
Способ установления связи зависит от используемого протокола (это может быть NTLM, Kerberos и т. д.), но в любом случае контроллеры домена должны совместно использовать ключ для обеспечения безопасности связи. Этот ключ известен как ключ доверия и создается при установлении доверия.
Когда создается доверие, в базе данных домена создается доверительная учетная запись (
Attacking Active Directory: 0 to 0.9 | zer1t0
zer1t0.gitlab.io
Attacking Active Directory: 0 to 0.9 | zer1t0
zer1t0.gitlab.io
Подробнее о доверии
Чтобы узнать, как можно злоупотреблять доверием в пентесте, вы можете проверить следующие сообщения (для их прочтения также рекомендуется небольшое знание Kerberos):
- Все дело в доверии — подделка билетов доверия Kerberos для подмены доступа через доверительные отношения Active Directory (https://adsecurity.org/?p=1588 )
- Руководство по атаке доменных трастов -(http://www.harmj0y.net/blog/redteaming/a-guide-to-attacking-domain-trusts/ )
- Доверия леса Active Directory, часть 1. Как работает фильтрация SID? (https://dirkjanm.io/active-directory-forest-trusts-part-one-how-does-sid-filtering-work/)
- Inter-Realm Key Roasting (well… within the first 30 days) (https://blog.xpnsec.com/inter-realm-key-roasting/)
-Не граница безопасности: нарушение лесных трастов (http://www.harmj0y.net/blog/redteaming/not-a-security-boundary-breaking-forest-trusts/)
Пользователи
Одним из ключевых моментов использования Active Directory является управление пользователями. Каждая организация управляет своими пользователями по-разному, устанавливая для них форматы имен, назначая разные разрешения и т. д.
Чтобы упростить управление пользователями в Active Directory, они хранятся в виде объектов в центральной базе данных, с которыми можно консультироваться и манипулировать ими из любой точки домена (если у вас достаточно прав).
Свойства пользователя
Идентификаторы пользователей
Пользовательский объект хранит множество различных данных, но в первую очередь следует учитывать те атрибуты, которые позволяют нам идентифицировать пользователя.
Для идентификации пользователя обычно используется имя пользователя, которое хранится в атрибуте SamAccountName. Кроме того, SID (идентификатор безопасности) также может использоваться для идентификации пользователя.
SID пользователя похож на SID домена и фактически представляет собой комбинацию SID домена и RID пользователя (относительный идентификатор), который является последним числом, которое появляется в SID пользователя.
PS C:\Users\Anakin> Get-ADUser Anakin
DistinguishedName : CN=Anakin,CN=Users,DC=contoso,DC=local
Enabled : True
GivenName : Anakin
Name : Anakin
ObjectClass : user
ObjectGUID : 58ab0512-9c96-4e97-bf53-019e86fd3ed7
SamAccountName : anakin
SID : S-1-5-21-1372086773-2238746523-2939299801-1103
Surname :
UserPrincipalName : anakin@contoso.local
В этом случае SID домена — S-1-5-21-1372086773-2238746523-2939299801, а RID пользователя — 1103. Некоторые инструменты отображают SID в своих выходных данных вместо имени пользователя (поскольку оно используется в некоторых структурах, таких как дескрипторы безопасности), поэтому вам следует знать его формат, чтобы идентифицировать его. (https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-security_descriptor)
Кроме того, DistinguishedName используется API LDAP для идентификации объектов (https://docs.microsoft.com/en-us/previous-versions/windows/desktop/ldap/distinguished-names), поэтому, если вы запрашиваете базу данных с помощью LDAP (что является одним из наиболее распространенных способов), вы, вероятно, увидите ссылки на объекты через его DistinguishedName.
Секреты пользователя
Кроме того, база данных также должна хранить секреты пользователя, чтобы позволить контроллеру домена аутентифицировать пользователя. Пароль пользователя не хранится в открытом виде, но сохраняются следующие полученные из него секреты:
-NT хеш (и LM хеш для старых учетных записей)
-Керберос ключи
Излишне говорить, что пользовательские секреты не могут быть получены пользователями без прав администратора. Даже компьютеры домена не могут получить к ним доступ, но оставляют аутентификацию контроллеру домена.
Чтобы получить пользовательские секреты, вам нужны права администратора (или эквивалентные) для создания дампа базы данных домена с помощью атаки dcsync или захвата файла C:\Windows\NTDS\ntds.dit с контроллера домена.
Хэши LM/NT
Хэши LM и NT (https://medium.com/@petergombos/lm-ntlm-net-ntlmv2-oh-my-a9b235c58ed4) хранятся как в локальной базе данных SAM Windows (https://en.wikipedia.org/wiki/Security_Account_Manager), так и в базе данных Active Directory NTDS для аутентификации локальных пользователей и пользователей домена соответственно. Эти хэши, как LM, так и NT, имеют длину 16 байт.
Password: 123456
LM hash: 44EFCE164AB921CAAAD3B435B51404EE
NT hash: 32ED87BDB5FDC5E9CBA88547376818D4
Однако хэши LM довольно слабые (https://en.wikipedia.org/wiki/LAN_Manager#Security_weaknesses), поэтому они не используются, начиная с Windows Vista/Server 2008. Процедура создания хэша LM следующая (https://asecuritysite.com/encryption/lmhash) :
1. Преобразуйте пароль пользователя в верхний регистр. (Это уменьшает пространство поиска для атаки полным перебором).
2. Если пароль пользователя меньше 14 символов, он дополняется символами NULL, пока длина не станет 14.
Если пароль больше 14 символов, то он усекается. (Бесполезно иметь пароли более 14 символов).
3. Затем пароль разбивается на две строки по 7 байт каждая.
4. Каждая 7-байтовая строка используется в качестве ключа для шифрования строки KGS!+#$% с использованием криптографического алгоритма DES. В результате получается два хэша.
5. Два результирующих значения объединяются для формирования хэша LM. (можно взломать каждую часть отдельно)
upper_password = to_uppercase(password)
14_password = truncate_to_14_bytes(upper_password)
7_part1, 7_part2 = split_7(14_password)
hash1 = des(7_part1, "KGS!+#$%")
hash2 = des(7_part2, "KGS!+#$%")
lm_hash = hash1 + hash2
С другой стороны, хэш NT немного сильнее (https://en.wikipedia.org/wiki/Salt_(cryptography)), но для его вычисления не используется соль, поэтому его можно взломать, используя предварительно вычисленные значения (например, радужные таблицы (https://en.wikipedia.org/wiki/Rainbow_table)).
Если вам интересно, хэш NT вычисляется путем применения алгоритма MD4 (https://en.wikipedia.org/wiki/MD4 )(который устарел (https://tools.ietf.org/html/rfc6150)) непосредственно к версии Unicode (в частности, кодировке UTF-16LE) пароля пользователя.
nt_hash = md4(encode_in_utf_16le(password))
Много раз хэш NT называется хэшем NTLM, однако это может сбивать с толку, поскольку протокол NTLM также использует хэши, называемые хешами NTLM. В этой статье хеш NTLM будет хэшем протокола NTLM.
Многие инструменты позволяют извлекать хэши LM и NT и обычно возвращают вывод с несколькими строками, по одной на пользователя, в формате <username>:<rid>:<LM>:<NT>:::. Если LM не используется, его значение будет aad3b435b51404eeaad3b435b51404ee (LM-хэш пустой строки).
Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
WDAGUtilityAccount:504:aad3b435b51404eeaad3b435b51404ee:6535b87abdb112a8fc3bf92528ac01f6:::
user:1001:aad3b435b51404eeaad3b435b51404ee:57d583aa46d571502aad4bb7aea09c70:::
Для пентестера важно распознавать хэши NT, поскольку, даже если они не являются паролями пользователей, они используются для аутентификации на машинах Windows, поэтому они очень полезны. Их можно использовать для выполнения атак Pass-The-Hash или Overpass-the-Hash, чтобы выдавать себя за пользователей на удаленных машинах.
Кроме того, вы можете попытаться взломать хэши LM и NT с помощью hashcat (https://hashcat.net/), чтобы восстановить исходный пароль. Если вам повезло и LM-хеш присутствует, это должно быть быстро.
Ключи Kerberos
Помимо хэшей LM/NT, сохраняются ключи Kerberos, полученные из пароля пользователя и используемые в протоколе аутентификации Kerberos.
Ключи Kerberos можно использовать для запроса билета Kerberos, который представляет пользователя при проверке подлинности Kerberos. Существует несколько разных ключей, и разные используются для разной поддержки шифрования Kerberos:
-Ключ AES 256: используется алгоритмом AES256-CTS-HMAC-SHA1-96 (https://tools.ietf.org/html/rfc3962). Это тот, который обычно используется Kerberos, и его должен использовать пентестер, чтобы избежать срабатывания аварийных сигналов.
-Ключ AES 128: используется алгоритмом AES128-CTS-HMAC-SHA1-96 (https://tools.ietf.org/html/rfc3962).
- Ключ DES: используется устаревшим алгоритмом DES-CBC-MD5 (https://datatracker.ietf.org/doc/html/rfc3961#section-6.2.1).
- Ключ -RC4: это NT-хэш пользователя, используемый алгоритмом RC4-HMAC (https://tools.ietf.org/html/rfc4757).
$ secretsdump.py 'contoso.local/Administrator@192.168.100.2' -just-dc-user anakin
Impacket v0.9.21 - Copyright 2020 SecureAuth Corporation
Password:
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
contoso.local\anakin:1103:aad3b435b51404eeaad3b435b51404ee:cdeae556dc28c24b5b7b14e9df5b6e21:::
[*] Kerberos keys grabbed
contoso.local\anakin:aes256-cts-hmac-sha1-96:ecce3d24b29c7f044163ab4d9411c25b5698337318e98bf2903bbb7f6d76197e
contoso.local\anakin:aes128-cts-hmac-sha1-96:18fe293e673950214c67e9f9fe753198
contoso.local\anakin:des-cbc-md5:fbba85fbb63d04cb
[*] Cleaning up...
Эти ключи можно использовать в атаке Pass-The-Key (
Attacking Active Directory: 0 to 0.9 | zer1t0
zer1t0.gitlab.io
UserAccountControl
Одним интересным свойством пользовательского класса является UserAccountControl (UAC) (не путайте его с механизмом контроля учетных записей (https://docs.microsoft.com/en-us/tr...raccountcontrol-manipulate-account-properties) , чтобы избежать выполнения программ с повышенными правами на компьютерах с Windows).
Свойство UserAccountControl содержит ряд флагов, которые очень важны для безопасности и домена и используются во многих атаках, упомянутых в этом посте. Вот самые актуальные:
- ACCOUNTDISABLE -> Учетная запись отключена и не может быть использована.
- DONT_REQUIRE_PREAUTH -> Учетная запись не требует предварительной аутентификации Kerberos.
- NOT_DELEGATED -> Эта учетная запись не может быть делегирована через делегирование Kerberos.
- TRUSTED_FOR_DELEGATION -> Неограниченное делегирование Kerberos включено для этой учетной записи и ее служб. Для его изменения требуется SeEnableDelegationPrivilege ( http://www.harmj0y.net/blog/actived...-user-right-you-probably-have-never-heard-of/).
- TRUSTED_TO_AUTH_FOR_DELEGATION -> Расширение Kerberos S4U2Self включено для этой учетной записи и ее служб. Для его изменения требуется SeEnableDelegationPrivilege ( http://www.harmj0y.net/blog/actived...-user-right-you-probably-have-never-heard-of/).
Другие свойства пользователя
Есть и другие свойства, которые могут быть полезны в пентесте:
- Description (https://docs.microsoft.com/en-us/windows/win32/adschema/a-description) -> Описание пользователя. Он может дать представление о правах пользователя, а иногда даже включает пароль.
-AdminCount (https://docs.microsoft.com/en-us/windows/win32/adschema/a-admincount)-> Указывает, защищен ли пользователь (или группа) объектом AdminSDHolder, или он был защищен. Поскольку иногда не обновляется, используйте его только как ссылку.
- MemberOf -> Группы, членом которых является пользователь. Это свойство является логическим и генерируется из свойства группы Members.
-PrimaryGroupID (https://docs.microsoft.com/en-us/windows/win32/adschema/a-primarygroupid) -> Основная группа пользователя. Эта группа не отображается в свойстве MemberOf.
-ServicePrincipalName (https://docs.microsoft.com/en-us/windows/win32/adschema/a-serviceprincipalname) -> Службы пользователя. Может быть полезен для атаки Kerberoast.
-msDS-AllowedToDelegateTo( https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-ada2/86261ca1-154c-41fb-8e5f-c6446e77daaa) -> Список служб, для которых пользователь (и его собственные службы) может олицетворять клиентов с помощью ограниченного делегирования Kerberos. Для его изменения требуется SeEnableDelegationPrivilege( http://www.harmj0y.net/blog/actived...-user-right-you-probably-have-never-heard-of/).
Важные пользователи
Для консультации с пользователями есть несколько вариантов, таких как команда net user /domain или Powershell. Нет необходимости иметь специальную привилегию для вывода списка пользователей, это может сделать любой пользователь.
PS C:\Users\Anakin> Get-ADUser -Filter * | select SamAccountName
SamAccountName
--------------
Administrator
Guest
krbtgt
anakin
han
POKEMON$
Как вы могли заметить, мой тестовый домен небольшой, с очень небольшим количеством пользователей, но в реальном взаимодействии будут сотни или тысячи пользователей. Поэтому важно различать, что действительно важно. Это может быть немного сложно, так как это зависит от организации, но обычно члены ИТ-команды используют привилегированных пользователей, им это нужно для работы.
Более того, по умолчанию встроенный пользователь-администратор является самой привилегированной учетной записью домена. Он может выполнять любые действия на любом компьютере. Таким образом, если вам удастся скомпрометировать эту учетную запись, вы получите полный контроль над доменом (и даже над лесом, используя атаку с использованием истории SID (https://adsecurity.org/?p=1640)).
Кроме того, учетная запись krbtgt также очень важна. Его секреты (хэш NT и ключи Kerberos) используются для шифрования билетов (в частности, TGT), используемых Kerberos, что позволяет аутентифицировать пользователей. Если вам удастся скомпрометировать учетную запись krbtgt, вы сможете создавать золотые билеты( https://en.hackndo.com/kerberos-silver-golden-tickets/). Обычно эту учетную запись можно скомпрометировать только путем сброса базы данных домена, поскольку она используется только в контроллерах домена, для чего потребуются права администратора в домене.
Учетные записи компьютеров
Еще одна вещь, которую следует учитывать, это то, что в организации у каждого человека есть свой пользователь, и даже у некоторых людей, таких как ИТ-отдел, может быть несколько пользователей на человека для выполнения различных задач. Более того, также у каждого компьютера домена есть свой пользователь, так как им тоже нужно выполнять свои действия в домене.
Разница между учетными записями пользователей и учетными записями компьютеров заключается в том, что первые хранятся как экземпляры класса User (https://docs.microsoft.com/en-us/windows/win32/adschema/c-user) в базе данных, тогда как другие хранятся как экземпляры класса Computer (https://docs.microsoft.com/en-us/windows/win32/adschema/c-computer), который является подклассом класса User. Кроме того, имена учетных записей компьютеров представляют собой имена хостов компьютеров, заканчивающиеся знаком доллара $.
Вы можете проверить это, выполнив следующую команду:
PS C:\> Get-ADObject -LDAPFilter "objectClass=User" -Properties SamAccountName | select SamAccountName
SamAccountName
--------------
Administrator
Guest
DC01$
krbtgt
anakin
WS01-10$
WS02-7$
DC02$
han
POKEMON$
Как видите, пользователей намного больше, чем при использовании команды Get-ADUser, поскольку теперь включены подклассы класса User. Вы можете оценить, что новые учетные записи заканчиваются знаком доллара и, кажется, имеют имя компьютера. Например, DC01$ и DC02$ для контроллеров домена и WS01-10$ и WS02-7$ для рабочих станций.
Более того, объекты-компьютеры также сохранили информацию об их операционной системе, которую можно получить из атрибутов OperatingSystem или OperatingSystemVersion.
Кроме того, во многих организациях существуют правила выбора имен компьютеров и пользователей, поэтому, если вы в состоянии понять имена, вы можете быть осведомлены об использовании компьютеров и учетных записей пользователей, а также о том, какие из них могут быть привилегированные или содержат доступ к важной информации. Кроме того, вы можете проверить другие атрибуты объектов, такие как Описание, чтобы найти там больше информации (и даже пароли в открытом виде). Для этой цели может быть полезен командлет Find-DomainObjectPropertyOutlier (https://gist.github.com/HarmJ0y/184f9822b195c52dd50c379ed3117993) для Powerview (https://github.com/BC-SECURITY/Empi...e/situational_awareness/network/powerview.ps1).
Аккаунты доверия
Однако есть также учетная запись POKEMON$, которая появляется как в Get-ADUser, так и в Get-ADObject, но имя которой заканчивается знаком доллара. Это может быть обычный пользователь (нет проблем с созданием имен пользователей, заканчивающихся $), однако, как мы видели ранее, существует доверие с доменом poke.mon.
При установлении доверия в каждом домене создается связанный пользовательский объект для хранения ключа доверия. Имя пользователя — это NetBIOS-имя другого домена, заканчивающееся $ (аналогично имени учетной записи компьютера). Например, в случае доверия между доменами FOO и BAR, домен FOO будет хранить ключ доверия в пользователе BAR$, а домен BAR будет хранить его в пользователе FOO$.
PS C:\> Get-ADUser -LDAPFilter "(SamAccountName=*$)" | select SamAccountName
SamAccountName
--------------
POKEMON$
Этот пользовательский объект POKEMON$ используется для хранения ключей доверия, которые являются хэшем NT или ключами Kerberos (один из других используется в зависимости от контекста). Если вы можете получить секреты этой учетной записи ( https://zer1t0.gitlab.io/posts/attacking_ad/Domain database dumping), вы можете создавать билеты Kerberos ( https://adsecurity.org/?p=1588) между областями.
Группы
Но управление пользователями может быть громоздким без групп. Представьте, что у вас есть отдел менеджеров, которому нужен доступ к очень конфиденциальным документам. Следует ли давать разрешение каждому менеджеру по одному? Работы много, но вы справитесь, потому что каждый год добавляется только новый менеджер. Но теперь политика меняется, и менеджеры также должны иметь доступ к документам отдела кадров. Стоит ли менять все разрешения менеджеров по одному? Нет, будет слишком много работы и довольно скучно.
Решение заключается в использовании групп (https://docs.microsoft.com/en-us/wi...ctory-security-groups#default-security-groups). В этом случае у вас может быть группа Менеджер, в которую добавляются пользователи-менеджеры, и при изменении политики вы должны добавлять или удалять разрешения для группы.
Как и пользователи, группы хранятся в базе данных домена. Точно так же их можно идентифицировать по атрибуту SamAccountName или SID.
Вы можете обратиться к базе данных, чтобы составить список групп и их членов.
PS C:\Users\Anakin> Get-ADGroup -Filter * | select SamAccountName
SamAccountName
--------------
Administrators
Users
Guests
<-- stripped output -->
Domain Computers
Domain Controllers
Schema Admins
Enterprise Admins
Cert Publishers
Domain Admins
Domain Users
<-- stripped output -->
Protected Users
Key Admins
Enterprise Key Admins
DnsAdmins
DnsUpdateProxy
DHCP Users
DHCP Administrators
Важные группы
Административные группы
В Active Directory существует множество групп по умолчанию (https://docs.microsoft.com/en-us/wi...ctory-security-groups#default-security-groups), определенных для разных ролей в домене/лесу. Для злоумышленника одной из самых привлекательных групп является группа "Администраторы домена" ( https://docs.microsoft.com/en-us/wi...e-directory-security-groups#bkmk-domainadmins), которая дает права администратора своим членам в домене, поэтому важно знать, кто является этой группой.
PS C:\Users\Anakin> Get-ADGroup "Domain Admins" -Properties members,memberof
DistinguishedName : CN=Domain Admins,CN=Users,DC=contoso,DC=local
GroupCategory : Security
GroupScope : Global
MemberOf : {CN=Denied RODC Password Replication Group,CN=Users,DC=contoso,DC=local,
CN=Administrators,CN=Builtin,DC=contoso,DC=local}
Members : {CN=Administrator,CN=Users,DC=contoso,DC=local}
Name : Domain Admins
ObjectClass : group
ObjectGUID : ac3ac095-3ea0-4922-8130-efa99ba99afa
SamAccountName : Domain Admins
SID : S-1-5-21-1372086773-2238746523-2939299801-512
Но есть и другие важные группы, которые могут дать вам много привилегий, а некоторые даже больше. Это относится к группе Enterprise Admins (https://docs.microsoft.com/en-us/wi...tive-directory-security-groups#bkmk-entadmins), которая предоставляет права администратора во всем лесу.
Администраторы предприятия — это группа, которая существует только в корневом домене леса, но по умолчанию добавляется в группу администраторов всех доменов леса. (https://docs.microsoft.com/en-us/wi...tive-directory-security-groups#administrators)
С другой стороны, группа "Администраторы домена" добавляется в группу "Администраторы" домена, а также в группы "Администраторы" компьютеров домена.
Другие важные группы
Но есть и другие важные группы (https://adsecurity.org/?p=3700), которые необходимо учитывать:
DNS-администраторы
Группа DNSAdmins (https://docs.microsoft.com/en-us/wi...tive-directory-security-groups#bkmk-dnsadmins) может разрешить своим членам выполнять код в контроллерах домена (https://www.semperis.com/blog/dnsadmins-revisited/) как SYSTEM с помощью произвольной библиотеки DLL.
Защищенные пользователи
Группа Защищенные пользователи (https://docs.microsoft.com/en-us/wi...and-management/protected-users-security-group) позволяет обеспечить безопасность учетных записей. Их участникам запрещается:
- Аутентифицироваться с помощью NTLM (только Kerberos).
- Использовать типы шифрования DES или RC4 в предварительной аутентификации Kerberos.
- Быть делегированным с неограниченным или ограниченным делегированием.
- Обновлять TGT Kerberos по истечении первоначального четырехчасового срока службы.
Это может помешать попыткам злоупотребления этой учетной записью с помощью ретрансляции NTLM (https://en.hackndo.com/ntlm-relay/) или атак делегирования Kerberos (https://www.tarlogic.com/en/blog/kerberos-iii-how-does-delegation-work/).
Администраторы схемы
Администраторы схемы( https://docs.microsoft.com/en-us/wi...ctive-directory-security-groups#schema-admins) могут изменять схему базы данных Active Directory.
Операторы Аккаунтов
Группа Операторы учетных записей (https://docs.microsoft.com/en-us/wi...rectory-security-groups#bkmk-accountoperators) может изменять членов многих групп домена, за исключением многих групп администраторов. Однако он может изменить группу операторов сервера.
Операторы резервного копирования
Члены резервных операторов (https://docs.microsoft.com/en-us/wi...ve-directory-security-groups#backup-operators) могут создавать резервные копии и восстанавливать файлы в контроллерах домена (они также могут входить в них). Это может позволить изменять файлы в контроллерах домена.
Операторы печати
Операторы печати (https://docs.microsoft.com/en-us/wi...ive-directory-security-groups#print-operators) могут входить в контроллеры домена.
Операторы сервера
Операторы сервера (https://docs.microsoft.com/en-us/wi...ve-directory-security-groups#server-operators) могут входить в контроллеры домена и управлять его конфигурацией.
Пользователи удаленного рабочего стола
Члены пользователей удаленного рабочего стола (https://docs.microsoft.com/en-us/wi...ctory-security-groups#bkmk-remotedesktopusers) могут войти в контроллер домена через RDP.
Владельцы создателей групповой политики
Члены владельцев-создателей групповой политики (https://docs.microsoft.com/en-us/wi...y-security-groups#group-policy-creator-owners) могут редактировать объекты групповой политики в домене.
Есть много других групп, описанных в документах Microsoft (https://docs.microsoft.com/en-us/wi...l/active-directory-security-groups#replicator). Более того, многие организации добавляют настраиваемые группы, которые также могут быть очень привилегированными, например, используемые членами ИТ.
Кроме того, многие программы (особенно программы Microsoft) добавляют свои собственные группы для управления, такие как Exchange, которые могут добавлять привилегированные группы (https://adsecurity.org/?p=4119) , такие как Exchange Windows Permissions, которые могут позволить пользователю выполнять атаку DCSync (если они не обновлены должным образом).
ickets: Извлекает билеты Kerberos, хранящиеся на машине.
