Запросы LDAP для разных операций

В эпоху BloodHound многие консультанты привыкли, что этот очень мощный инструмент выполняет большую часть тяжелой работы по перечислению доменов. BloodHound объединяет сильную визуальную перспективу, дескрипторы безопасности, входящие и исходящие элементы управления объектами, информацию об использовании, соображения OPSEC и многое другое. Это такой же защитный инструмент, как и наступательный. Тем не менее, некоторые задания могут предпочесть, чтобы консультанты использовали «низкий и медленный» подход, чтобы увидеть, какую полезную информацию можно получить о каталоге и его объектах без BloodHound. Сегодня разберем запросы LDAP для разных операций.

Поиск информацию каталога о моем текущем пользователе

Например: предположим, что samaccountname моего пользователя — ericazelic.

dsquery * -filter "(&(objectCategory=person)(objectClass=user)(samaccountname=ericazelic))" -limit 0 -attr *

Поиск всех контроллеров домена (DC):

Для некоторых тестов может потребоваться два контроллера домена (например, нулевой вход в систему, ретрансляция перехода на более раннюю версию NTLM через LDAP с проверкой подлинности на втором контроллере домена). Другими местами, где эта информация может быть доступна, является кэш DNS-клиента или klist. Тем не менее, иметь список всех из них может быть полезно.

(&(objectCategory=Computer)(userAccountControl:1.2.840.113556.1.4.803:=8192))

Поиск мест (серверов) для бокового перемещения

Традиционные тесты на проникновение часто полагаются на сканирование Nessus и/или nmap. С помощью перечисления LDAP вы можете найти все серверы в каталоге, которые не являются контроллерами домена, для поиска информации и возможности бокового перемещения:

(&(objectCategory=computer)(operatingSystem=*server*)(!(userAccountControl:1.2.840.113556.1.4.803:=8192)))

Поиск центров сертификации и издателей:

(CN="Cert Publishers"*)

Поиск всех организационных подразделений (OU) :

В разных подразделениях могут быть разные групповые политики, целевые конфигурации и администраторы:

(objectCategory=organizationalUnit)

Пример VBScript:

On Error Resume Next

Const ADS_SCOPE_SUBTREE = 2

Set objConnection = CreateObject("ADODB.Connection")
Set objCommand = CreateObject("ADODB.Command")
objConnection.Provider = "ADsDSOObject"
objConnection.Open "Active Directory Provider"
Set objCommand.ActiveConnection = objConnection

objCommand.Properties("Page Size") = 1000
objCommand.Properties("Searchscope") = 2
objCmd.Properties("Timeout") = 30
objCmd.Properties("Cache Results") = False

objCommand.CommandText = _
"SELECT Name FROM 'LDAP://DC=ad,DC=yummy,DC=tacos' WHERE objectCategory='organizationalUnit'"
Set objRecordSet = objCommand.Execute

objRecordSet.MoveFirst
Do Until objRecordSet.EOF
Wscript.Echo objRecordSet.Fields("Name").Value
objRecordSet.MoveNext
Loop

Поиск всех контейнеров :

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

(objectCategory=container)

Поиск учетных записей с именем участника-службы (SPN)

Поиск учетных записей с именами участников-служб помогает нам идентифицировать учетные записи с поддержкой Kerberoastable, а также помогает нам понять, какие службы работают и где в среде. В некоторых случаях, если у нас есть возможность записи в объект в каталоге, мы можем добавить к объекту имя службы-принципала, чтобы сделать его совместимым с Kerbero. Этот запрос также можно использовать, чтобы помочь нам подтвердить добавление serviceprincipalname:

DSQuery

* -filter "(&(objectClass=User)(serviceprincipalname=*)(samaccountname=*))" -limit 0 -attr samaccountname serviceprincipalname

Powershell:

([adsisearcher]'(servicePrincipalName=*)').FindAll()

Ограниченное делегирование:

Учетные записи с ограниченным делегированием позволяют вам олицетворять любую учетную запись пользователя домена, если она не помечена как «Учетная запись конфиденциальна и не может быть делегирована» или не является членом группы «Защищенные пользователи».

(&(objectClass=User)(msDS-AllowedToDelegateTo=*))

Неограниченное делегирование (включая контроллеры домена) :

Ограниченное делегирование на основе ресурсов (RBCD):

Поиск RBCD помогает нам идентифицировать цели на потенциальных путях атаки, а также позволяет нам проверять атрибут объекта при его установке самостоятельно. Обсуждение RBCD выходит за рамки этого поста, однако отличной ссылкой является пост в блоге Элада Шамира «Виляние собакой».

(msDS-AllowedToActOnBehalfOfOtherIdentity=*)

Например, если machineaccountquota > 0, мы можем использовать powermad для добавления учетной записи машины:

Используя dsquery, чтобы проверить, была ли создана учетная запись компьютера, и перечислить SID:

Добавьте необработанный дескриптор безопасности в msds-allowedtoactonbehalfofotheridentity и убедитесь, что он был успешно добавлен с помощью dsquery:

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

Аккаунты, не доверенные для делегирования:

Если этот атрибут установлен, учетные записи нельзя использовать в делегировании, описанном выше.

(&(samaccountname=*)(userAccountControl:1.2.840.113556.1.4.803:=1048576))

Теневые учетные данные:

В доменах, использующих службу сертификатов Active Directory (AD CS) и контроллер домена (DC) с включенным PKINIT версии 2016 или более поздней, мы можем изменить этот атрибут, чтобы взять на себя учетные записи пользователей и компьютеров. После того, как мы сгенерировали сертификат и записали атрибут, мы можем подтвердить модификацию с помощью этого запроса LDAP. Подробнее о Shadow Credentials можно узнать здесь.

(msDS-KeyCredentialLink=*)

Предварительная аутентификация Kerberos отключена:

Хотя редко, учетная запись с этим атрибутом означает, что она может быть обжарена AS-REP.

(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=4194304))

Пользователи Kerberoastable:

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

(&(objectClass=user)(servicePrincipalName=*)(!(cn=krbtgt))(!(samaccounttype=805306369)))

Члены группы через вложенность:

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

(memberOf:1.2.840.113556.1.4.1941:=cn=Test,ou=East,dc=Domain,dc=com)

Пользователям, которым не требуется пароль:

Это помогает нам находить возможности для бокового движения. Согласно Microsoft, даже если пароль требуется групповой политикой (GP), этот параметр переопределяет GP.

(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=32))

Группы:

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

(objectCategory=group)

Группа защищенных пользователей:

Члены этой группы могут входить только с помощью Kerberos. Если учетная запись находится в группе «Защищенные пользователи», делегирование и NTLM-атаки с передачей хеша не будут работать. Кроме того, типы шифрования DES или RC4 в предварительной аутентификации Kerberos не будут работать, TGT Kerberos нельзя будет обновить по истечении начального 4-часового периода, а пароли не будут кэшироваться.

(&(objectCategory=CN=group,CN=Schema,CN=configuration,DC=yourDomainName,DC=yourDomainExtension)(samaccountname=Protect*)(member=*))

Пользовательские объекты с описанием:

Атрибуты описания объектов пользовательского каталога иногда содержат пароли или дополнительную полезную информацию о пользователях.

(&(objectCategory=user)(description=*))

Компьютерные объекты с описанием:

Атрибут описания объектов-компьютеров иногда раскрывает дополнительную информацию о системе и ее назначении, которая не может быть получена из имени NetBIOS.

(&(objectCategory=computer)(description=*))

Срок действия паролей не истекает:

Аккаунты со старыми паролями могут быть более уязвимы. Например, мы могли бы просматривать информацию об утечках и создавать более точные списки для атак с низким и медленным подбором (не идеально), гарантируя, что мы не блокируем пользователей.

(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=65536))

Пользователь должен сменить пароль при следующем входе в систему:

Некоторые организации могут использовать сценарий пароля при смене пароля. Предположим, мы находим этот пароль на общем ресурсе со Snaffler. Мы можем использовать такие инструменты, как smbpasswd или rpcclient, чтобы изменить его с Linux. Вероятно, это плохая идея делать тест на проникновение, не спросив сначала клиента. Как правило, менять пароли пользователей — плохая идея, если у вас нет возможности изменить их обратно до того, как они это заметят, и получить разрешение от клиента при консультации.

Что касается атрибута pwdlastset=0, согласно Microsoft, есть 3 случая, когда этот атрибут может быть установлен равным нулю:

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

(&(objectCategory=person)(objectClass=user)(pwdLastSet=0)(!(useraccountcontrol:1.2.840.113556.1.4.803:=2)))

Пользовательские объекты с повышенными правами домена:

Обычно, если у объекта установлен этот атрибут, он является частью защищенной группы с повышенными привилегиями домена или когда-то был. Примеры групп безопасности, в которых известно, что этот атрибут позволяет повысить привилегии домена, включают операторов резервного копирования, операторов учетных записей, операторов сервера, операторов печати, администраторов домена, администраторов предприятия, администраторов схемы, администраторов DNS и иногда контроллеров домена только для чтения. Если учетная запись является членом одной из этих групп, прямо или косвенно, мы можем получить контроль над доменом. Знание того, какие объекты каталога имеют этот набор атрибутов, помогает нам создать список целей. Нет ничего необычного в том, что учетные записи служб с поддержкой Kerberoastable можно увидеть с этим значением атрибута, хотя в последние годы стало сложнее взломать пароли для учетных записей служб в автономном режиме из-за более надежных паролей в учетных записях служб с высокой ценностью.

(&(objectClass=user)(admincount=1)(!(samaccountname=krbtgt))(!(samaccountname=administrator)))

Учетные записи пользователей с историей SID:

Учетные записи с SIDHistory могут иметь доступ в других доменах.

(&(objectCategory=Person)(objectClass=User)(sidHistory=*))

Создайте список учетных записей пользователей samaccountname:

(&(objectCategory=Person)(objectClass=User)(samaccountname=*))

Сгенерируйте список имен объектов компьютеров:

(&(objectClass=Computer)(samaccountname=*))

Заключение

Ни один из изложенных здесь запросов не является новой или последней информацией. За исключением нескольких, они были получены из нескольких ресурсов в Интернете. На самом деле, первые RFC для LDAP относятся как минимум к 1997 году для LDAP версии 3. Существует множество блогов, RFC и технических спецификаций; все объясняют, как собирать информацию из AD DS с помощью запросов LDAP.