- Автор темы
- Добавить закладку
- #21
Типы логинов
Для входа пользователей как локально, так и удаленно, Windows определяет различные типы входа в систему, которые важны для злоумышленника по нескольким причинам. Во-первых, не каждый вход в систему может использоваться любым пользователем, поэтому вам нужно знать, что вам разрешено делать. Во-вторых, многие входы в систему кэшируют учетные данные в процессе lsass (https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/reference-tools-logon-types) или даже в секретах LSA, которые могут быть восстановлены пентестером, поэтому важно распознавать эти входы.
Интерактивный логин
Интерактивный логин в систему или локальный вход в систему происходит, когда есть вход в систему на физическом компьютере или при использовании runas. Учетные данные кэшируются в процессе lsass машины.
runas /user:<username> cmd
При этом типе входа в систему, в случае локальных учетных записей, компьютер проверяет пароль, сравнивая свой хэш NT с хэшем, хранящимся в SAM. Если пользователь использует учетную запись домена, компьютер проверяет учетные данные пользователя, запрашивая TGT Kerberos у контроллера домена, который кэшируется на машине. Если контроллер домена недоступен, компьютер проверяет учетные данные пользователя в хранилище кэшированных учетных данных домена (DCC), которое кэширует учетные данные (https://docs.microsoft.com/en-us/tr...les-and-logon/cached-domain-logon-information) последних пользователей домена, вошедших в систему на компьютере. Если учетные данные домена не кэшированы, компьютер не сможет аутентифицировать пользователя.
После проверки подлинности хэш NT, полученный из пароля, сохраняется в процессе lsass. Для учетных записей домена также кэшируются ключи Kerberos, также полученные из пароля пользователя, и билеты для обеспечения единого входа (SSO). На старых компьютерах кэшируется даже простой пароль.
Для выполнения интерактивного входа в систему может потребоваться право SeInteractiveLogonRight (https://docs.microsoft.com/en-us/wi...security-policy-settings/allow-log-on-locally), особенно на контроллерах домена или других компьютерах с Windows Server.
Сетевой логин
Вход в сеть происходит, когда вы подключаетесь к удаленному компьютеру с помощью неинтерактивной службы, такой как SMB, RPC, SQL и т. д. Для такого входа в систему вам потребуется пароль, хэш NT или билет Kerberos, поэтому они подвержены атакам Pass-The-Hash, Pass-The-Key или Pass-The-Ticket. Одним из важных фактов является то, что учетные данные не кэшируются на удаленном компьютере, за исключением случаев, когда включено делегирование Kerberos.
Это, вероятно, тип входа в систему, который чаще всего используется злоумышленником (я имею в виду сознательно, потому что он также чаще всего используется законными пользователями, поскольку компьютеры постоянно подключаются друг к другу в домене).
Psexec (https://docs.microsoft.com/en-us/sysinternals/downloads/psexec), пакет impacket ( https://github.com/SecureAuthCorp/impacket) и удаленный Powershell (использующий WinRM с входом по умолчанию) используют этот тип проверки подлинности, даже если они предоставляют интерактивную оболочку.
Вот несколько примеров входа в сеть:
dir \\ws01-10\Temp
.\PsExec.exe \\dc01 cmd
При этом типе входа клиент подключается к удаленному компьютеру и использует SPNEGO (https://zer1t0.gitlab.io/posts/attacking_ad/#spnego) для согласования протокола аутентификации и, наконец, использует Kerberos (https://zer1t0.gitlab.io/posts/attacking_ad/#kerberos) или NTLM (https://zer1t0.gitlab.io/posts/attacking_ad/#ntlm). Поскольку при использовании любого из этих протоколов учетные данные пользователя не отправляются напрямую, они не могут быть кэшированы на целевой машине. Исключение составляет, если включено делегирование Kerberos (https://zer1t0.gitlab.io/posts/attacking_ad/#kerberos-delegation).
Имейте в виду, что даже если вы можете выполнить вход в сеть, может быть много причин, по которым служба не может быть использована. Во-первых, существует брандмауэр, запрещающий подключение к удаленным службам, а во-вторых, многие из служб, доступных через вход в сеть, могут использоваться только администраторами.
Например, вы можете использовать вход в сеть для доступа к некоторым общим ресурсам удаленного компьютера, но не можете запустить оболочку с помощью PsExec, поскольку для этого требуется доступ к диспетчеру служб, доступ к которому имеют только администраторы.
Пакетный логин
Используется для запуска запланированных задач в контексте пользователя. В документации Microsoft указано, что пароль пользователя задачи хранится в секретах LSA, однако мне не удалось сохранить пароль в моих тестах. Также учетные данные будут кэшироваться в процессе lsass при выполнении задачи.
schtasks.exe /create /tn notepaddaily /tr notepad.exe /sc daily /ru CONTOSO\TaskUser /rp task1234!
Имейте в виду, что пакетный вход в систему будет производиться при выполнении задачи, а не при ее создании. Поэтому, возможно, у вас есть права запускать задачу (например, SeBatchLogonRight (https://docs.microsoft.com/en-us/wi...ecurity-policy-settings/log-on-as-a-batch-job)), но вы не можете создать задачу. Например, у операторов резервного копирования есть право SeBatchLogonRight, но они не могут создавать задачи (по умолчанию).
При запуске задачи учетные данные проверяются и кэшируются, как и при интерактивном входе в систему (https://zer1t0.gitlab.io/posts/attacking_ad/#interactive-logon) .
Сервис логин
Вход в службу используется, когда служба будет запущена в контексте пользователя. Простой пароль хранится в секретах LSA машины, а учетные данные будут кэшироваться в процессе lsass при выполнении службы.
sc.exe create MySvc2 binpath= c:\windows\system32\notepad.exe obj=CONTOSO.local\svcUser password=svc1234!
Имейте в виду, что вход в службу будет производиться при выполнении службы, а не при ее создании. Поэтому, возможно, у вас есть привилегии для входа в качестве службы (например, SeServiceLogonRight (https://docs.microsoft.com/en-us/wi.../security-policy-settings/log-on-as-a-service)), но вы не можете создать службу.
При запуске службы учетные данные проверяются и кэшируются, как и при интерактивном входе в систему (https://zer1t0.gitlab.io/posts/attacking_ad/#interactive-logon) .
NetworkCleartext logon
В случае входа в систему NetworkCleartext пароль отправляется по сети на целевую машину (в зашифрованном виде). Этот тип входа используется удаленным взаимодействием Powershell, когда указана проверка подлинности CredSSP.
CredSSP выполняет сетевую аутентификацию с использованием NTLM или Kerberos и при создании зашифрованного канала отправляет пароль на целевую машину.
Следует отметить, что учетные данные кэшируются на целевой машине, поскольку они отправляются в сообщении.
New-PSSession -Credential $(Get-Credential) -Authentication Credssp
Вход в систему NewCredentials происходит при использовании runas (https://docs.microsoft.com/en-us/pr...ows-server-2012-R2-and-2012/cc771525(v=ws.11)) с параметром /netonly. Затем запущенный процесс будет использовать учетные данные только для удаленных подключений, сохраняя текущий сеанс пользователя для локальных операций.
Учетные данные кэшируются в локальном процессе lsass, чтобы их можно было использовать для сетевых подключений. Затем, когда процесс требует этого, он может выполнять вход в сеть для доступа к удаленным ресурсам домена.
runas /netonly /user:CONTOSO\OtherUser cmd
Учетные данные не проверяются до тех пор, пока не будет выполнено сетевое подключение, но они кэшируются при выполнении команды runas, как и при интерактивном входе в систему (https://zer1t0.gitlab.io/posts/attacking_ad/#interactive-logon) (за исключением билетов Kerberos, поскольку они извлекаются при проверке учетных данных). Вы должны принять это во внимание, поскольку этот метод позволяет кэшировать поддельные учетные данные в процессе lsass и иногда используется синей командой (https://securitywa.blogspot.com/2016/04/improve-detection-using-honeycreds.html) для создания хонипот учетных данных для обнаружения злоумышленников.
Аутентификация аналогична сетевому входу (https://zer1t0.gitlab.io/posts/attacking_ad/#network-logon), но учетные данные отправляются на целевую машину, поэтому они кэшируются, как и при интерактивном входе в систему (https://zer1t0.gitlab.io/posts/attacking_ad/#interactive-logon).
Чтобы иметь возможность войти на удаленный компьютер с помощью входа в RemoteInteractive, ваш пользователь должен быть частью пользователей (https://docs.microsoft.com/en-us/wi...ctory-security-groups#bkmk-remotedesktopusers) удаленного рабочего стола или иметь право SeRemoteInteractiveLogonRight (https://docs.microsoft.com/en-us/wi.../allow-log-on-through-remote-desktop-services) на целевом компьютере.
Авторизация
Как только клиент смог разрешить целевое имя хоста и пройти аутентификацию, целевая служба/программа/компьютер теперь должна знать о своих разрешениях, то есть знать имя пользователя и SID, а также группы, к которым он принадлежит. Как только эта информация известна, программа может решить, имеет ли пользователь достаточные привилегии для доступа к определенным объектам.
ACL
Дескриптор безопасности
Но как проверить, есть ли у пользователя доступ к объекту? Проверяя его дескриптор безопасности (http://www.selfadsi.org/deep-inside/ad-security-descriptors.htm). В Active Directory каждый объект базы данных имеет связанный с ним дескриптор безопасности (https://docs.microsoft.com/en-us/windows/win32/secauthz/security-descriptors) в свойстве NTSecurityDescriptor (https://docs.microsoft.com/en-us/windows/win32/adschema/a-ntsecuritydescriptor). Дескриптор безопасности хранится в двоичном формате (https://www.gabescode.com/active-directory/2019/07/25/nt-security-descriptors.html), но его также можно преобразовать в строковый формат дескриптора безопасности (https://docs.microsoft.com/en-us/windows/win32/secauthz/security-descriptor-string-format).
Дескриптор безопасности содержит следующую информацию о безопасности:
- SID принципала, который является владельцем объекта
- SID основной группы владельца
- (Необязательно) DACL (дискреционный список управления доступом)
- (Необязательно) SACL (Системный список управления доступом)
PS C:\> $(Get-ADUser anakin -Properties nTSecurityDescriptor).nTSecurityDescriptor | select Owner,Gro
up,Access,Audit | Format-List
Owner : CONTOSO\Domain Admins
Group : CONTOSO\Domain Admins
Access : {System.DirectoryServices.ActiveDirectoryAccessRule, System.DirectoryServices.ActiveDirectoryAccessRule,
System.DirectoryServices.ActiveDirectoryAccessRule, System.DirectoryServices.ActiveDirectoryAccessRule...}
Audit :
Как видите, в каждом дескрипторе безопасности может быть два ACL (списка управления доступом): DACL и SACL. ACL представляет собой список ACE (запись управления доступом). ACE в SACL определяют попытки доступа, которые будут генерировать журналы (https://docs.microsoft.com/en-us/windows/win32/secauthz/audit-generation), и они могут быть полезны с точки зрения защиты.
Однако наиболее важной частью является DACL, который обычно присутствует во всех объектах, ACE которого определяет пользователей/группы, которые могут получить доступ к объекту, и тип разрешенного доступа. Обычно, когда кто-то обращается к объектному ACL, имеется в виду DACL.
ACEs
Каждый ACE (http://web.archive.org/web/20150907...echtarget.com/feature/The-structure-of-an-ACE) состоит из нескольких частей:
- Тип ACE: указывает, предназначен ли ACE для разрешения или отказа в доступе (или регистрации доступа в случае SACL).
- Наследование: указывает, наследуется ли ACE.
- Принципал: Указывает участника (пользователя/группу), для которого применяется ACE. Основной SID сохраняется.
- Права: указывает тип доступа, применяемый ACE.
- Тип объекта: идентификатор GUID (https://en.wikipedia.org/wiki/Universally_unique_identifier), указывающий расширенное право, свойство или дочерний объект в зависимости от флагов маски доступа. Устанавливается в ноль, если не используется.
- Тип наследования: тип класса объекта, который может наследовать ACE от этого объекта.
PS C:\Users\Administrator> $(Get-ADUser anakin -Properties nTSecurityDescriptor).nTSecurityDescriptor.Access[0]
ActiveDirectoryRights : GenericRead
InheritanceType : None
ObjectType : 00000000-0000-0000-0000-000000000000
InheritedObjectType : 00000000-0000-0000-0000-000000000000
ObjectFlags : None
AccessControlType : Allow
IdentityReference : NT AUTHORITY\SELF
IsInherited : False
InheritanceFlags : None
PropagationFlags : None
Таким образом, ACE можно использовать для предоставления доступа, но также и для его ограничения. Следует отметить, что в случае, если участнику разрешен доступ и запрещен доступ разными ACE, то ACE отказа имеет предпочтение, и доступ запрещен.
С другой стороны, ACE могут наследоваться от родительских объектов базы данных (OU и контейнеров), и на самом деле наследуются большинство ACE, которые применяются к объектам. В случае, если унаследованный доступ противоречит явному ACE (не унаследованному), то явный ACE определяет правило доступа. Таким образом, приоритет для ACE следующий:
1. Явный запрет ACE
2. Явное разрешение ACE
3. Унаследованный отказ от ACE
4. Унаследовано разрешение ACE
Существует особый случай, который не ограничен ACE, и это владелец объекта. Владелец имеет неявное разрешение на изменение ACE объекта (право WriteDacl).
Кроме того, необходимо также учитывать, что в случае, если дескриптор безопасности не имеет DACL (DACL установлен в NULL), любой доступ к объекту есть у всех. Однако если дескриптор безопасности имеет пустой список DACL (нет ACE в DACL), то никто не имеет доступа к объекту.
Права
В ACE могут быть указаны следующие права (https://docs.microsoft.com/en-us/op.../ms-adts/990fb975-ab31-4bc1-8b75-5da132cd4584):
- Delete : удалить объект.
- ReadControl: чтение дескриптора безопасности, кроме SACL.
- WriteDacl: изменение списка DACL объекта в дескрипторе безопасности.
- WriteOwner: изменение владельца объекта в дескрипторе безопасности.
- CreateChild: создание дочерних объектов. Для контейнеров.
- DeleteChild: удаление дочернийхобъектов. Для контейнеров.
- ListContents: список дочерних объектов. Для контейнеров. Объект скрыт от пользователя, если это право или ListObject не предоставлены.
- ReadProperty: чтение свойства или набора свойств (https://docs.microsoft.com/en-us/op.../ms-adts/177c0db5-fa12-4c31-b75a-473425ce9cca), указанного в типе объекта . Если тип объекта равен нулю, то все свойства могут быть прочитаны. Не позволяет читать конфиденциальные свойства (https://docs.microsoft.com/en-us/op.../ms-adts/7c1cdf82-1ecc-4834-827e-d26ff95fb207).
- WriteProperty: изменить свойство, указанное в типе объекта. Если тип объекта нулевой, то все свойства могут быть изменены.
- WritePropertyExtended: выполнить проверенную запись (https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/20504d60-43ec-458f-bc7a-754eb64446df). Возможно, наиболее интересной подтвержденной записью (https://docs.microsoft.com/en-us/windows/win32/adschema/validated-writes) является самостоятельное членство для групп (https://docs.microsoft.com/en-us/windows/win32/adschema/r-self-membership), которое позволяет добавить вашего текущего пользователя в группу с помощью ACE.
- DeleteTree: удаление всех дочерних объектов с помощью операции удаления дерева.
- ListObject: список объектов. Объект скрыт от пользователя, если это право или ListContents не предоставлены.
- ControlAccess: специальное разрешение, которое можно интерпретировать по-разному в зависимости от типа объекта. Если тип объекта является GUID конфиденциального свойства (https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/e6685d31-5d87-42d0-8a5f-e55d337f47cd) , он дает разрешение на его чтение. Если GUID расширенного права (https://docs.microsoft.com/en-us/windows/win32/adschema/extended-rights) зарегистрирован в схеме базы данных, то право предоставляется. Если тип объекта нулевой (GUID состоит из нулей), то предоставляются все расширенные права.
Существуют также некоторые общие права, которые охватывают несколько прав:
- GenericRead: ReadControl, ListContents, ReadProperty (all), ListObject.
- GenericWrite: ReadControl, WriteProperty (all), WritePropertyExtended (all).
- GenericExecute: ReadControl, ListContents.
- GenericAll: Delete, WriteDacl, WriteOwner, CreateChild, DeleteChild, DeleteTree, ControlAccess (all), GenericAll, GenericWrite.
Расширенных прав много (https://docs.microsoft.com/en-us/windows/win32/adschema/extended-rights), но вот одни из самых интересных:
- User-Force-Change-Password (https://docs.microsoft.com/en-us/windows/win32/adschema/r-user-force-change-password) : изменить пароль пользователя, не зная текущего пароля. Для пользовательских объектов. Не путайте с правом User-Change-Password (https://docs.microsoft.com/en-us/windows/win32/adschema/r-user-force-change-password), которое требует знать пароль для его изменения.
- DS-Replication-Get-Changes ( https://docs.microsoft.com/en-us/windows/win32/adschema/r-ds-replication-get-changes): для репликации данных базы данных. Для объекта домена. Требуется для выполнения dcsync.
- DS-Replication-Get-Changes-All (https://docs.microsoft.com/en-us/windows/win32/adschema/r-ds-replication-get-changes-all) : для репликации секретных данных базы данных. Для объекта домена. Требуется для выполнения dcsync.
PS C:\Users\Administrator\Downloads> (Get-Acl 'AD:\DC=contoso,DC=local').Access[49]
ActiveDirectoryRights : ExtendedRight
InheritanceType : None
ObjectType : 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2
InheritedObjectType : 00000000-0000-0000-0000-000000000000
ObjectFlags : ObjectAceTypePresent
AccessControlType : Allow
IdentityReference : CONTOSO\Domain Controllers
IsInherited : False
InheritanceFlags : None
PropagationFlags : None
В предыдущем примере показан ACE ExtendedRight, который дает DS-Replication-Get-Changes-All в домене для группы контроллеров домена.
Как вы можете себе представить, когда кто-то говорит, что группа "Администраторы домена" имеет права администратора в домене, это означает, что это группа, для которой есть много ACE в объектах с большим количеством прав, поэтому вы можете предположить, что группа принадлежит к группе "Администраторы домена". Группа администраторов домена, вы можете выполнять множество действий с привилегиями, но в конечном итоге именно списки DACL объектов определяют силу группы/пользователя.
Помимо объектов базы данных, на компьютерах с Windows также есть много защищаемых объектов (https://docs.microsoft.com/en-us/windows/win32/secauthz/securable-objects), которые также защищены локальными DACL, управляемыми локальным компьютером. Среди этих объектов файлы/каталоги, процессы, ключи реестра или службы. Но поскольку администраторы домена по умолчанию добавляются в локальную группу администраторов на машинах, обычно администратор домена может получить доступ к любому локальному объекту на компьютере с Windows. Вы можете использовать такие инструменты, как Get-Acl (https://docs.microsoft.com/en-us/po...wershell.security/get-acl?view=powershell-7.1), icacls (https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/icacls), для проверки ACL файлов.
ACL-атаки
Из-за огромного количества списков ACL, которые могут находиться в домене, управлять ими может быть сложно. Это может привести к нескольким неправильным конфигурациям (https://www.ired.team/offensive-sec...eros-abuse/abusing-active-directory-acls-aces), которые могут позволить злоумышленнику повысить привилегии (https://blog.fox-it.com/2018/04/26/escalating-privileges-with-acls-in-active-directory/) в домене или даже в лесу (помните, что домены одного и того же леса связаны, поэтому вы можете добавить ссылку ACE на участников других доменов). Давайте рассмотрим некоторые неверные конфигурации:
- Измените пароль пользователя: если у вас есть права User-Force-Change-Password или GenericAll на объект пользователя, вы можете взять на себя учетную запись, установив новый пароль.
- Сделайте пользователя Kerberoasteable: если вы можете написать SPN в свойстве ServicePrincipalName пользователя, вы можете выполнить атаку Kerberoast (https://www.ired.team/offensive-sec...-directory-kerberos-abuse/t1208-kerberoasting) на эту учетную запись и попытаться взломать ее пароль. Для записи SPN требуется, чтобы у вас была проверенная запись Validated-SPN (https://docs.microsoft.com/en-us/windows/win32/adschema/r-validated-spn) с WritePropertyExtended, GenericWrite или GenericAll.
- Выполнение вредоносного сценария: если вы можете изменить свойство ScriptPath пользователя с помощью WriteProperty, GenericWrite или GenericAll, то вы можете установить вредоносный файл, который будет выполняться при следующем входе пользователя в систему. Вы можете использовать путь UNC (https://www.ired.team/offensive-sec...tive-directory-acls-aces#genericwrite-on-user), чтобы указать на общий ресурс. Вам также может потребоваться включить флаг SCRIPT для свойства UserAccountControl.
- Добавить пользователей в группу: если вы можете изменить свойство участников группы с помощью WriteProperty, GenericWrite или GenericAll, то вы можете добавить любого члена в группу. Если у вас есть право на самостоятельное членство, вы можете добавить текущего пользователя в эту группу.
- Атака RBCD Kerberos (https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/resource-based-constrained-delegation-ad-computer-object-take-over-and-privilged-code-execution) : если вы можете изменить msDS-AllowedToActOnBehalfOfOtherIdentity учетной записи компьютера с помощью WriteProperty, GenericWrite или GenericAll, то вы включаете ограниченное делегирование на основе ресурсов Kerberos для другого пользователя к компьютерным службам и, наконец, получаете доступ в качестве администратора к компьютеру.
- Пароль LAPS (https://adsecurity.org/?p=3164) : если вы можете прочитать конфиденциальное свойство компьютера ms-Mcs-AdmPwd, используемое LAPS для хранения пароля локального администратора машины, то вы можете прочитать его для доступа к машине в качестве локального администратора. Вы можете определить использование LAPS на компьютере, проверив, существует ли свойство ms-Mcs-AdmPwdExpirationTime в его учетной записи компьютера.
- Атака DCSync (https://adsecurity.org/?p=1729) : если у вас есть расширенные права DS-Replication-Get-Changes и DS-Replication-Get-Changes-All на объект домена, вы можете выполнить атаку DCSync для создания дампа содержимого базы данных.
- Злоупотребление GPO: если вы можете изменить GPC-File-Sys-Path контейнера групповой политики (https://zer1t0.gitlab.io/posts/attacking_ad/#group-policy-container) с помощью WriteProperty, GenericWrite или GenericAll, то вы можете изменить GPO и выполнить код на компьютерах, затронутых GPO.
- Изменить ACL: если у вас есть право WriteDacl (или GenericAll), то вы можете создать ACE, чтобы дать любое право на объект и выполнить некоторые из предыдущих атак. Кроме того, если у вас есть право WriteOwner, поскольку объект-владелец имеет неявное право WriteDacl, вы можете изменить владельца объекта на своего пользователя, а затем изменить ACL.
Помимо возможности повышения привилегий, ACL также могут быть весьма полезными и незаметными, если вы хотите создать лазейки (https://www.specterops.io/assets/resources/an_ace_up_the_sleeve.pdf) , чтобы сохранить свой доступ в сети. Чтобы создать бэкдоры, есть несколько приемов сокрытия вредоносных ACE, описанных в официальном документе An ACE Up the Sleeve (https://www.specterops.io/assets/resources/an_ace_up_the_sleeve.pdf) , написанном командой Specterops, которые вы должны проверить.
AdminSDHolder
Однако, возможно, один из самых интересных приемов сохранения — это модификация объекта AdminSDHolder. AdminSDHolder — это специальный объект в базе данных, список DACL которого используется в качестве шаблона для дескриптора безопасности привилегированных субъектов.
PS C:\> Get-ADObject 'CN=AdminSDHolder,CN=system,DC=contoso,DC=local'
DistinguishedName Name ObjectClass ObjectGUID
----------------- ---- ----------- ----------
CN=AdminSDHolder,CN=system,DC=contoso,DC=local AdminSDHolder container 7f34e8a5-ffbd-474a-b436-1e02b7b49984
Каждые 60 минут SDProp (распространитель дескрипторов безопасности) проверяет дескриптор безопасности этих привилегированных субъектов и заменяет их DACL копией DACL AdminSDHolder (если они отличаются). Это делается для предотвращения изменений в списках DACL этих субъектов, но если вы можете добавить пользовательские элементы управления доступом в список DACL AdminSDHolder, то эти новые элементы управления доступом (https://adsecurity.org/?p=1906) также будут применяться к защищенным субъектам.
По умолчанию следующие участники "защищены" AdminSDHolder:
Account Operators
Administrator
Administrators
Backup Operators
Domain Admins
Domain Controllers
Domain Guests
Enterprise Admins
Enterprise Key Admins
Enterprise Read-Only Domain Controllers
Key Admins
krbtgt
Print Operators
Read-only Domain Controllers
Replicator
Schema Admins
Server Operators
Привилегии
Если вы знакомы с платформой Windows, возможно, вы знаете о привилегиях пользователей, которые позволяют пользователям выполнять действия в обход ACL объектов. Например, SeDebugPrivilege на компьютере с Windows позволяет читать/записывать любую память процесса на компьютере, даже если у вас нет прав.
В Active Directory также можно злоупотреблять некоторыми привилегиями (https://adsecurity.org/?p=3700) (в основном в контроллерах домена):
SeEnableDelegationPrivilege
SeEnableDelegationPrivilege (http://www.harmj0y.net/blog/activedirectory/the-most-dangerous-user-right-you-probably-have-never-heard-of/) должен быть установлен в контроллере домена для пользователя (это локальная привилегия), а затем он позволяет изменять свойство msDS-AllowedToDelegateTo пользователей и флаги TRUSTED_FOR_DELEGATION и TRUSTED_TO_AUTH_FOR_DELEGATION из свойства UserAccountControl. Другими словами, SeEnableDelegationPrivilege позволяет управлять параметрами Kerberos Unconstrained и Constrained Delegation домена, которые злоумышленник может использовать для повышения привилегий. По умолчанию предоставляется только учетной записи администратора.
SeBackupPrivilege
Привилегия резервного копирования (https://docs.microsoft.com/en-us/wi...policy-settings/back-up-files-and-directories) позволяет читать любой файл контроллера домена, чтобы сделать его резервную копию, которую можно использовать для чтения базы данных домена. По умолчанию предоставляется группам Операторы резервного копирования, Операторы сервера и Администраторы. Эта привилегия эффективна только при использовании API резервного копирования NTFS (https://docs.microsoft.com/en-us/windows/win32/backup/backup-reference), доступ к которому можно получить с помощью утилиты wbadmin (https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/wbadmin) или Powershell WindowsServerBackup (https://docs.microsoft.com/en-us/powershell/module/windowsserverbackup/?view=windowsserver2019-ps) (для обоих требуется функция резервного копирования Windows Server (https://docs.microsoft.com/en-us/pr...ows-server-2012-R2-and-2012/jj614621(v=ws.11))). Вы также можете использовать reg save ( https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/reg-save) для доступа к секретам SAM и LSA (https://zer1t0.gitlab.io/posts/attacking_ad/#dumping-registry-credentials) .
SeRestorePrivilege
Привилегия восстановления ( https://docs.microsoft.com/en-us/wi...policy-settings/restore-files-and-directories) позволяет записывать любой файл на контроллере домена из резервной копии. Это может позволить злоумышленнику изменить базу данных домена. По умолчанию предоставляется группам Операторы резервного копирования, Операторы сервера и Администраторы. Вы можете использовать эту привилегию для изменения ключей реестра и обеспечения привилегированного выполнения команд (https://github.com/hatRiot/token-priv/blob/master/poptoke/poptoke/SeRestorePrivilege.cpp) .
SeTakeOwnershipPrivilege
С привилегией владения ( https://docs.microsoft.com/en-us/wi...ings/take-ownership-of-files-or-other-objects) вы можете стать владельцем защищаемых объектов машины (https://docs.microsoft.com/en-us/windows/win32/secauthz/securable-objects), таких как файлы, процессы или ключи реестра. Владелец объекта всегда может изменить разрешения объекта (WriteDacl). Например, вы можете использовать вызов API SetNamedSecurityInfo (https://github.com/hatRiot/token-pr...toke/poptoke/SeTakeOwnershipPrivilege.cpp#L31), чтобы стать владельцем объекта. Как я могу стать владельцем объектов базы данных Active Directory???
Помимо привилегий, используемых в домене, также полезно знать об опасных привилегиях (https://foxglovesecurity.com/2017/0...leges-for-windows-local-privilege-escalation/), которые могут быть полезны для повышения привилегий на компьютере с Windows.
Обычно используются следующие:
SeDebugPrivilege
Пользователь может отлаживать любой процесс на машине, поэтому он может вводить код в любой процесс, что может привести к повышению привилегий, или читать память процесса, что позволяет читать, например, секреты процесса lsass пользователей, вошедших в систему. машина (можно использовать mimikatz (https://github.com/gentilkiwi/mimikatz)).
SeImpersonatePrivilege
Пользователь может получить токены безопасности (https://github.com/hatRiot/token-priv/blob/master/abusing_token_eop_1.0.txt#L155) других пользователей на машине. Если уровень маркера олицетворения — SecurityDelegation, то пользователь может использовать этот маркер для олицетворения целевого пользователя на других компьютерах домена (маркеры SecurityDelegation связаны с учетными данными пользователя, такими как билеты Kerberos, которые можно использовать в сетевых подключениях). Если уровень маркера олицетворения — SecurityImpersonation, то целевой пользователь может олицетворяться только на локальном компьютере (полезно для повышения привилегий). SeImpersonatePrivilege предоставляется "NT AUTHORITY\Network Service", который обычно используется для запуска веб-серверов и тому подобного, поэтому, если вы можете скомпрометировать веб-сервер, возможно, вы можете использовать инкогнито (https://labs.f-secure.com/archive/incognito-v2-0-released/), чтобы выдать себя за какого-либо пользователя домена в сети. Но определенно, если вы хотите повысить привилегии с помощью SeImpersonatePrivilege на локальной машине, используйте картофель (https://jlajara.gitlab.io/others/2020/11/22/Potatoes_Windows_Privesc.html).
Существуют и другие привилегии, которые можно использовать для повышения привилегий на компьютерах с Windows. Если они вас интересуют, вам следует проверить репозиторий token-priv (https://github.com/hatRiot/token-priv) FoxGlove, который включает документ с их описанием и PoC для их использования, настоятельно рекомендуемый ресурс.
Групповая политика
Целью Active Directory является управление компьютерами и пользователями организации. И часть процесса управления осуществляется групповой политикой.
Групповая политика (https://adsecurity.org/?p=2716)— это механизм, который позволяет применять набор правил/действий к пользователям и компьютерам сети Active Directory. Вот некоторые из возможностей:
- Отключить NTLM
- Требовать сложности пароля
- Выполнять запланированные или немедленные задачи
- Создавать локальных пользователей на компьютерах
- Устанавливать обои по умолчанию
- Синхронизировать файлы с OneDrive
- Так далее
Чтобы определить правила, вы можете создать объекты групповой политики (GPO). Каждый объект групповой политики определяет ряд политик, которые можно применять к определенным машинам доменов. Кроме того, вы можете создавать политики, которые применяются ко всей машине или сеансам пользователей. Например, вы можете выполнить сценарий при запуске компьютера или при входе пользователя в систему.
Область действия объекта групповой политики
При создании объекта групповой политики необходимо указать, к каким компьютерам он будет применяться (https://docs.microsoft.com/en-us/pr...rver-2012-R2-and-2012/dn581922(v=ws.11)#scope). Для этого вам необходимо связать объект групповой политики с одним из следующих контейнеров базы данных:
- Домен
- Организационная единица (OU)
- Site (https://docs.microsoft.com/en-us/windows/win32/adschema/c-site) (контейнер для групп компьютеров, которые физически расположены близко друг к другу, не рекомендуется для объектов групповой политики)
На компьютере с Windows также может быть локальная групповая политика. Таким образом, к машине на разных уровнях можно применить множество различных объектов групповой политики, которые обрабатываются в следующем порядке:
1. Локально
2. Сайт
3. Домен
4. Организационная единица
Здесь локальные GPO имеют наименьшее предпочтение, а OU GPO — наиболее предпочтительные. Поэтому, если, например, объект групповой политики, примененный к домену, противоречит локальному объекту групповой политики, то объект групповой политики домена будет следовать.
Однако для объектов групповой политики Active Directory (не локальных) также возможно установить правило No Override. Таким образом, если установлено правило политики домена, никакие правила из подразделений не могут противоречить этому вышестоящему правилу.
Кроме того, с объектом групповой политики может быть связан запрос WMI (https://docs.microsoft.com/en-us/wi...ndows-firewall/create-wmi-filters-for-the-gpo) , что позволяет отфильтровать компьютер, к которому будет применяться объект групповой политики. Например, чтобы применить политики только к компьютерам с Windows 7.
В домене каждый компьютер проверяет наличие обновлений политики каждые 90 минут, за исключением контроллеров домена, которые делают это каждые 5 минут. Вы также можете выполнить немедленную проверку с помощью gpupdate (https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/gpupdate) .
Каждый объект групповой политики идентифицируется идентификатором GUID и состоит из двух объектов: шаблона групповой политики и контейнера групповой политики.
Шаблон групповой политики
Шаблон групповой политики — это каталог в общей папке SYSVOL. Шаблоны могут находиться в \\<домен>\SYSVOL\<домен>\Policies\. Каждому каталогу шаблона присваивается имя с использованием GUID объекта групповой политики.
PS C:\> ls \\contoso.local\SYSVOL\contoso.local\Policies\
Directory: \\contoso.local\SYSVOL\contoso.local\Policies
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 11/28/2020 10:02 AM {31B2F340-016D-11D2-945F-00C04FB984F9}
d----- 11/28/2020 10:02 AM {6AC1786C-016F-11D2-945F-00C04fB984F9}
d----- 4/19/2021 5:12 PM {BE864EFE-6C07-4A53-A9D8-7EB6EB36BE5A}
Каждый каталог GPO содержит следующие элементы:
- Каталог машины: для политик на уровне машины.
- Пользовательский каталог: для политик на уровне пользователя.
- GPT.INI: основная информация о GPO, версия и отображаемое имя.
Затем в этих каталогах (https://docs.microsoft.com/en-us/pr...=MSDN#subfolders-of-the-group-policy-template) могут быть самые разные файлы и каталоги, в которых вы можете найти INI-файлы конфигурации, в которых указаны значения ключей реестра, членов групп или сценариев для выполнения. И, если вам повезет, возможно, вы найдете учетные данные в сценариях или файлах предпочтений групповой политики (GPP) (https://adsecurity.org/?p=2288) с тегами cpassword. Вы можете использовать сценарий Get-GPPPasword (https://github.com/PowerShellMafia/PowerSploit/blob/master/Exfiltration/Get-GPPPassword.ps1) для поиска учетных данных GPP.
Предпочтения групповой политики (https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn581922(v=ws.11)#scope) — это имя, используемое для набора новых политик, добавленных в Windows Server 2008.
Контейнер групповой политики
Чтобы машины могли находить шаблоны групповой политики, база данных Active Directory хранит информацию об объектах групповой политики в контейнере CN=Policies,CN=System,DC=<domain>,DC=<com>. Каждый объект групповой политики хранится в объекте GroupPolicyContainer (https://docs.microsoft.com/en-us/windows/win32/adschema/c-grouppolicycontainer), содержащем объект групповой политики GUID и путь к шаблону групповой политики.
PS C:\> Get-ADObject -LDAPFilter "(ObjectClass=GroupPolicyContainer)" -Properties Name, DisplayName,gPCFileSysPath | select Name, DisplayName,GPCFileSysPath | Format-List
Name : {31B2F340-016D-11D2-945F-00C04FB984F9}
DisplayName : Default Domain Policy
GPCFileSysPath : \\contoso.local\sysvol\contoso.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}
Name : {6AC1786C-016F-11D2-945F-00C04fB984F9}
DisplayName : Default Domain Controllers Policy
GPCFileSysPath : \\contoso.local\sysvol\contoso.local\Policies\{6AC1786C-016F-11D2-945F-00C04fB984F9}
Name : {BE864EFE-6C07-4A53-A9D8-7EB6EB36BE5A}
DisplayName : test policy
GPCFileSysPath : \\contoso.local\SysVol\contoso.local\Policies\{BE864EFE-6C07-4A53-A9D8-7EB6EB36BE5A}
Вы должны заметить, что GUID GPO отличается от GUID, используемого для идентификации каждого объекта в базе данных Active Directory. Также обратите внимание, что если вы можете изменить свойство GPCFileSysPath (https://docs.microsoft.com/en-us/windows/win32/adschema/a-gpcfilesyspath) объекта групповой политики, вы можете установить контролируемый вами путь и создать вредоносный объект групповой политики, который может содержать вредоносные сценарии, которые будут выполняться на нескольких машинах.
С другой стороны, объекты базы данных домена, подразделений и сайтов связаны с объектами групповой политики с помощью свойства GpLink (https://docs.microsoft.com/en-us/windows/win32/adschema/a-gplink) .
PS C:\> Get-ADObject -LDAPFilter '(gPLink=*)' -Properties CanonicalName,gpLink | select objectclass,CanonicalName,gplink | Format-List
objectclass : domainDNS
CanonicalName : contoso.local/
gplink : [LDAP://cn={BE864EFE-6C07-4A53-A9D8-7EB6EB36BE5A},cn=policies,cn=system,DC=contoso,DC=local;1][LDAP://C
N={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=contoso,DC=local;0]
objectclass : organizationalUnit
CanonicalName : contoso.local/Domain Controllers
gplink : [LDAP://CN={6AC1786C-016F-11D2-945F-00C04fB984F9},CN=Policies,CN=System,DC=contoso,DC=local;0]
objectclass : organizationalUnit
CanonicalName : contoso.local/web servers
gplink : [LDAP://cn={BE864EFE-6C07-4A53-A9D8-7EB6EB36BE5A},cn=policies,cn=system,DC=contoso,DC=local;0]
Компьютер может определить объекты групповой политики, которые применяются к нему самому, изучив объекты OU, к которым он принадлежит, и объект домена.
Например, машина, на которой объект компьютера находится в CN=mypc,OU=workstations,OU=computers,DC=domain,DC=com, будет применять объекты групповой политики рабочих станций, OU компьютера и домена domain.com.
PS C:\> Get-ADObject -LDAPFilter '(gPLink=*)' -SearchBase "CN=Configuration,$((Get-ADDomain).DistinguishedName)" -Properties CanonicalName,gpLink | select objectclass,CanonicalName,gplink | Format-List
objectclass : site
CanonicalName : contoso.local/Configuration/Sites/mysite
gplink : [LDAP://cn={BE864EFE-6C07-4A53-A9D8-7EB6EB36BE5A},cn=policies,cn=system,DC=contoso,DC=local;0]
Для входа пользователей как локально, так и удаленно, Windows определяет различные типы входа в систему, которые важны для злоумышленника по нескольким причинам. Во-первых, не каждый вход в систему может использоваться любым пользователем, поэтому вам нужно знать, что вам разрешено делать. Во-вторых, многие входы в систему кэшируют учетные данные в процессе lsass (https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/reference-tools-logon-types) или даже в секретах LSA, которые могут быть восстановлены пентестером, поэтому важно распознавать эти входы.
Интерактивный логин
Интерактивный логин в систему или локальный вход в систему происходит, когда есть вход в систему на физическом компьютере или при использовании runas. Учетные данные кэшируются в процессе lsass машины.
runas /user:<username> cmd
При этом типе входа в систему, в случае локальных учетных записей, компьютер проверяет пароль, сравнивая свой хэш NT с хэшем, хранящимся в SAM. Если пользователь использует учетную запись домена, компьютер проверяет учетные данные пользователя, запрашивая TGT Kerberos у контроллера домена, который кэшируется на машине. Если контроллер домена недоступен, компьютер проверяет учетные данные пользователя в хранилище кэшированных учетных данных домена (DCC), которое кэширует учетные данные (https://docs.microsoft.com/en-us/tr...les-and-logon/cached-domain-logon-information) последних пользователей домена, вошедших в систему на компьютере. Если учетные данные домена не кэшированы, компьютер не сможет аутентифицировать пользователя.
После проверки подлинности хэш NT, полученный из пароля, сохраняется в процессе lsass. Для учетных записей домена также кэшируются ключи Kerberos, также полученные из пароля пользователя, и билеты для обеспечения единого входа (SSO). На старых компьютерах кэшируется даже простой пароль.
Для выполнения интерактивного входа в систему может потребоваться право SeInteractiveLogonRight (https://docs.microsoft.com/en-us/wi...security-policy-settings/allow-log-on-locally), особенно на контроллерах домена или других компьютерах с Windows Server.
Сетевой логин
Вход в сеть происходит, когда вы подключаетесь к удаленному компьютеру с помощью неинтерактивной службы, такой как SMB, RPC, SQL и т. д. Для такого входа в систему вам потребуется пароль, хэш NT или билет Kerberos, поэтому они подвержены атакам Pass-The-Hash, Pass-The-Key или Pass-The-Ticket. Одним из важных фактов является то, что учетные данные не кэшируются на удаленном компьютере, за исключением случаев, когда включено делегирование Kerberos.
Это, вероятно, тип входа в систему, который чаще всего используется злоумышленником (я имею в виду сознательно, потому что он также чаще всего используется законными пользователями, поскольку компьютеры постоянно подключаются друг к другу в домене).
Psexec (https://docs.microsoft.com/en-us/sysinternals/downloads/psexec), пакет impacket ( https://github.com/SecureAuthCorp/impacket) и удаленный Powershell (использующий WinRM с входом по умолчанию) используют этот тип проверки подлинности, даже если они предоставляют интерактивную оболочку.
Вот несколько примеров входа в сеть:
dir \\ws01-10\Temp
.\PsExec.exe \\dc01 cmd
При этом типе входа клиент подключается к удаленному компьютеру и использует SPNEGO (https://zer1t0.gitlab.io/posts/attacking_ad/#spnego) для согласования протокола аутентификации и, наконец, использует Kerberos (https://zer1t0.gitlab.io/posts/attacking_ad/#kerberos) или NTLM (https://zer1t0.gitlab.io/posts/attacking_ad/#ntlm). Поскольку при использовании любого из этих протоколов учетные данные пользователя не отправляются напрямую, они не могут быть кэшированы на целевой машине. Исключение составляет, если включено делегирование Kerberos (https://zer1t0.gitlab.io/posts/attacking_ad/#kerberos-delegation).
Имейте в виду, что даже если вы можете выполнить вход в сеть, может быть много причин, по которым служба не может быть использована. Во-первых, существует брандмауэр, запрещающий подключение к удаленным службам, а во-вторых, многие из служб, доступных через вход в сеть, могут использоваться только администраторами.
Например, вы можете использовать вход в сеть для доступа к некоторым общим ресурсам удаленного компьютера, но не можете запустить оболочку с помощью PsExec, поскольку для этого требуется доступ к диспетчеру служб, доступ к которому имеют только администраторы.
Пакетный логин
Используется для запуска запланированных задач в контексте пользователя. В документации Microsoft указано, что пароль пользователя задачи хранится в секретах LSA, однако мне не удалось сохранить пароль в моих тестах. Также учетные данные будут кэшироваться в процессе lsass при выполнении задачи.
schtasks.exe /create /tn notepaddaily /tr notepad.exe /sc daily /ru CONTOSO\TaskUser /rp task1234!
Имейте в виду, что пакетный вход в систему будет производиться при выполнении задачи, а не при ее создании. Поэтому, возможно, у вас есть права запускать задачу (например, SeBatchLogonRight (https://docs.microsoft.com/en-us/wi...ecurity-policy-settings/log-on-as-a-batch-job)), но вы не можете создать задачу. Например, у операторов резервного копирования есть право SeBatchLogonRight, но они не могут создавать задачи (по умолчанию).
При запуске задачи учетные данные проверяются и кэшируются, как и при интерактивном входе в систему (https://zer1t0.gitlab.io/posts/attacking_ad/#interactive-logon) .
Сервис логин
Вход в службу используется, когда служба будет запущена в контексте пользователя. Простой пароль хранится в секретах LSA машины, а учетные данные будут кэшироваться в процессе lsass при выполнении службы.
sc.exe create MySvc2 binpath= c:\windows\system32\notepad.exe obj=CONTOSO.local\svcUser password=svc1234!
Имейте в виду, что вход в службу будет производиться при выполнении службы, а не при ее создании. Поэтому, возможно, у вас есть привилегии для входа в качестве службы (например, SeServiceLogonRight (https://docs.microsoft.com/en-us/wi.../security-policy-settings/log-on-as-a-service)), но вы не можете создать службу.
При запуске службы учетные данные проверяются и кэшируются, как и при интерактивном входе в систему (https://zer1t0.gitlab.io/posts/attacking_ad/#interactive-logon) .
NetworkCleartext logon
В случае входа в систему NetworkCleartext пароль отправляется по сети на целевую машину (в зашифрованном виде). Этот тип входа используется удаленным взаимодействием Powershell, когда указана проверка подлинности CredSSP.
CredSSP выполняет сетевую аутентификацию с использованием NTLM или Kerberos и при создании зашифрованного канала отправляет пароль на целевую машину.
Следует отметить, что учетные данные кэшируются на целевой машине, поскольку они отправляются в сообщении.
New-PSSession -Credential $(Get-Credential) -Authentication Credssp
NewCredentials logon
Вход в систему NewCredentials происходит при использовании runas (https://docs.microsoft.com/en-us/pr...ows-server-2012-R2-and-2012/cc771525(v=ws.11)) с параметром /netonly. Затем запущенный процесс будет использовать учетные данные только для удаленных подключений, сохраняя текущий сеанс пользователя для локальных операций.
Учетные данные кэшируются в локальном процессе lsass, чтобы их можно было использовать для сетевых подключений. Затем, когда процесс требует этого, он может выполнять вход в сеть для доступа к удаленным ресурсам домена.
runas /netonly /user:CONTOSO\OtherUser cmd
Учетные данные не проверяются до тех пор, пока не будет выполнено сетевое подключение, но они кэшируются при выполнении команды runas, как и при интерактивном входе в систему (https://zer1t0.gitlab.io/posts/attacking_ad/#interactive-logon) (за исключением билетов Kerberos, поскольку они извлекаются при проверке учетных данных). Вы должны принять это во внимание, поскольку этот метод позволяет кэшировать поддельные учетные данные в процессе lsass и иногда используется синей командой (https://securitywa.blogspot.com/2016/04/improve-detection-using-honeycreds.html) для создания хонипот учетных данных для обнаружения злоумышленников.
RemoteInteractive logon
Вход в RemoteInteractive используется при подключении к машине через RDP (https://zer1t0.gitlab.io/posts/attacking_ad/#RDP). RDP использует CredSSP (https://zer1t0.gitlab.io/posts/attacking_ad/#cred-ssp) для удаленного входа в систему, поэтому пароль отправляется по сети на целевую машину, а учетные данные кэшируются в удаленном процессе lsass.
Аутентификация аналогична сетевому входу (https://zer1t0.gitlab.io/posts/attacking_ad/#network-logon), но учетные данные отправляются на целевую машину, поэтому они кэшируются, как и при интерактивном входе в систему (https://zer1t0.gitlab.io/posts/attacking_ad/#interactive-logon).
Чтобы иметь возможность войти на удаленный компьютер с помощью входа в RemoteInteractive, ваш пользователь должен быть частью пользователей (https://docs.microsoft.com/en-us/wi...ctory-security-groups#bkmk-remotedesktopusers) удаленного рабочего стола или иметь право SeRemoteInteractiveLogonRight (https://docs.microsoft.com/en-us/wi.../allow-log-on-through-remote-desktop-services) на целевом компьютере.
Авторизация
Как только клиент смог разрешить целевое имя хоста и пройти аутентификацию, целевая служба/программа/компьютер теперь должна знать о своих разрешениях, то есть знать имя пользователя и SID, а также группы, к которым он принадлежит. Как только эта информация известна, программа может решить, имеет ли пользователь достаточные привилегии для доступа к определенным объектам.
ACL
Дескриптор безопасности
Но как проверить, есть ли у пользователя доступ к объекту? Проверяя его дескриптор безопасности (http://www.selfadsi.org/deep-inside/ad-security-descriptors.htm). В Active Directory каждый объект базы данных имеет связанный с ним дескриптор безопасности (https://docs.microsoft.com/en-us/windows/win32/secauthz/security-descriptors) в свойстве NTSecurityDescriptor (https://docs.microsoft.com/en-us/windows/win32/adschema/a-ntsecuritydescriptor). Дескриптор безопасности хранится в двоичном формате (https://www.gabescode.com/active-directory/2019/07/25/nt-security-descriptors.html), но его также можно преобразовать в строковый формат дескриптора безопасности (https://docs.microsoft.com/en-us/windows/win32/secauthz/security-descriptor-string-format).
Дескриптор безопасности содержит следующую информацию о безопасности:
- SID принципала, который является владельцем объекта
- SID основной группы владельца
- (Необязательно) DACL (дискреционный список управления доступом)
- (Необязательно) SACL (Системный список управления доступом)
PS C:\> $(Get-ADUser anakin -Properties nTSecurityDescriptor).nTSecurityDescriptor | select Owner,Gro
up,Access,Audit | Format-List
Owner : CONTOSO\Domain Admins
Group : CONTOSO\Domain Admins
Access : {System.DirectoryServices.ActiveDirectoryAccessRule, System.DirectoryServices.ActiveDirectoryAccessRule,
System.DirectoryServices.ActiveDirectoryAccessRule, System.DirectoryServices.ActiveDirectoryAccessRule...}
Audit :
Как видите, в каждом дескрипторе безопасности может быть два ACL (списка управления доступом): DACL и SACL. ACL представляет собой список ACE (запись управления доступом). ACE в SACL определяют попытки доступа, которые будут генерировать журналы (https://docs.microsoft.com/en-us/windows/win32/secauthz/audit-generation), и они могут быть полезны с точки зрения защиты.
Однако наиболее важной частью является DACL, который обычно присутствует во всех объектах, ACE которого определяет пользователей/группы, которые могут получить доступ к объекту, и тип разрешенного доступа. Обычно, когда кто-то обращается к объектному ACL, имеется в виду DACL.
ACEs
Каждый ACE (http://web.archive.org/web/20150907...echtarget.com/feature/The-structure-of-an-ACE) состоит из нескольких частей:
- Тип ACE: указывает, предназначен ли ACE для разрешения или отказа в доступе (или регистрации доступа в случае SACL).
- Наследование: указывает, наследуется ли ACE.
- Принципал: Указывает участника (пользователя/группу), для которого применяется ACE. Основной SID сохраняется.
- Права: указывает тип доступа, применяемый ACE.
- Тип объекта: идентификатор GUID (https://en.wikipedia.org/wiki/Universally_unique_identifier), указывающий расширенное право, свойство или дочерний объект в зависимости от флагов маски доступа. Устанавливается в ноль, если не используется.
- Тип наследования: тип класса объекта, который может наследовать ACE от этого объекта.
PS C:\Users\Administrator> $(Get-ADUser anakin -Properties nTSecurityDescriptor).nTSecurityDescriptor.Access[0]
ActiveDirectoryRights : GenericRead
InheritanceType : None
ObjectType : 00000000-0000-0000-0000-000000000000
InheritedObjectType : 00000000-0000-0000-0000-000000000000
ObjectFlags : None
AccessControlType : Allow
IdentityReference : NT AUTHORITY\SELF
IsInherited : False
InheritanceFlags : None
PropagationFlags : None
Таким образом, ACE можно использовать для предоставления доступа, но также и для его ограничения. Следует отметить, что в случае, если участнику разрешен доступ и запрещен доступ разными ACE, то ACE отказа имеет предпочтение, и доступ запрещен.
С другой стороны, ACE могут наследоваться от родительских объектов базы данных (OU и контейнеров), и на самом деле наследуются большинство ACE, которые применяются к объектам. В случае, если унаследованный доступ противоречит явному ACE (не унаследованному), то явный ACE определяет правило доступа. Таким образом, приоритет для ACE следующий:
1. Явный запрет ACE
2. Явное разрешение ACE
3. Унаследованный отказ от ACE
4. Унаследовано разрешение ACE
Существует особый случай, который не ограничен ACE, и это владелец объекта. Владелец имеет неявное разрешение на изменение ACE объекта (право WriteDacl).
Кроме того, необходимо также учитывать, что в случае, если дескриптор безопасности не имеет DACL (DACL установлен в NULL), любой доступ к объекту есть у всех. Однако если дескриптор безопасности имеет пустой список DACL (нет ACE в DACL), то никто не имеет доступа к объекту.
Права
В ACE могут быть указаны следующие права (https://docs.microsoft.com/en-us/op.../ms-adts/990fb975-ab31-4bc1-8b75-5da132cd4584):
- Delete : удалить объект.
- ReadControl: чтение дескриптора безопасности, кроме SACL.
- WriteDacl: изменение списка DACL объекта в дескрипторе безопасности.
- WriteOwner: изменение владельца объекта в дескрипторе безопасности.
- CreateChild: создание дочерних объектов. Для контейнеров.
- DeleteChild: удаление дочернийхобъектов. Для контейнеров.
- ListContents: список дочерних объектов. Для контейнеров. Объект скрыт от пользователя, если это право или ListObject не предоставлены.
- ReadProperty: чтение свойства или набора свойств (https://docs.microsoft.com/en-us/op.../ms-adts/177c0db5-fa12-4c31-b75a-473425ce9cca), указанного в типе объекта . Если тип объекта равен нулю, то все свойства могут быть прочитаны. Не позволяет читать конфиденциальные свойства (https://docs.microsoft.com/en-us/op.../ms-adts/7c1cdf82-1ecc-4834-827e-d26ff95fb207).
- WriteProperty: изменить свойство, указанное в типе объекта. Если тип объекта нулевой, то все свойства могут быть изменены.
- WritePropertyExtended: выполнить проверенную запись (https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/20504d60-43ec-458f-bc7a-754eb64446df). Возможно, наиболее интересной подтвержденной записью (https://docs.microsoft.com/en-us/windows/win32/adschema/validated-writes) является самостоятельное членство для групп (https://docs.microsoft.com/en-us/windows/win32/adschema/r-self-membership), которое позволяет добавить вашего текущего пользователя в группу с помощью ACE.
- DeleteTree: удаление всех дочерних объектов с помощью операции удаления дерева.
- ListObject: список объектов. Объект скрыт от пользователя, если это право или ListContents не предоставлены.
- ControlAccess: специальное разрешение, которое можно интерпретировать по-разному в зависимости от типа объекта. Если тип объекта является GUID конфиденциального свойства (https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/e6685d31-5d87-42d0-8a5f-e55d337f47cd) , он дает разрешение на его чтение. Если GUID расширенного права (https://docs.microsoft.com/en-us/windows/win32/adschema/extended-rights) зарегистрирован в схеме базы данных, то право предоставляется. Если тип объекта нулевой (GUID состоит из нулей), то предоставляются все расширенные права.
Существуют также некоторые общие права, которые охватывают несколько прав:
- GenericRead: ReadControl, ListContents, ReadProperty (all), ListObject.
- GenericWrite: ReadControl, WriteProperty (all), WritePropertyExtended (all).
- GenericExecute: ReadControl, ListContents.
- GenericAll: Delete, WriteDacl, WriteOwner, CreateChild, DeleteChild, DeleteTree, ControlAccess (all), GenericAll, GenericWrite.
Расширенных прав много (https://docs.microsoft.com/en-us/windows/win32/adschema/extended-rights), но вот одни из самых интересных:
- User-Force-Change-Password (https://docs.microsoft.com/en-us/windows/win32/adschema/r-user-force-change-password) : изменить пароль пользователя, не зная текущего пароля. Для пользовательских объектов. Не путайте с правом User-Change-Password (https://docs.microsoft.com/en-us/windows/win32/adschema/r-user-force-change-password), которое требует знать пароль для его изменения.
- DS-Replication-Get-Changes ( https://docs.microsoft.com/en-us/windows/win32/adschema/r-ds-replication-get-changes): для репликации данных базы данных. Для объекта домена. Требуется для выполнения dcsync.
- DS-Replication-Get-Changes-All (https://docs.microsoft.com/en-us/windows/win32/adschema/r-ds-replication-get-changes-all) : для репликации секретных данных базы данных. Для объекта домена. Требуется для выполнения dcsync.
PS C:\Users\Administrator\Downloads> (Get-Acl 'AD:\DC=contoso,DC=local').Access[49]
ActiveDirectoryRights : ExtendedRight
InheritanceType : None
ObjectType : 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2
InheritedObjectType : 00000000-0000-0000-0000-000000000000
ObjectFlags : ObjectAceTypePresent
AccessControlType : Allow
IdentityReference : CONTOSO\Domain Controllers
IsInherited : False
InheritanceFlags : None
PropagationFlags : None
В предыдущем примере показан ACE ExtendedRight, который дает DS-Replication-Get-Changes-All в домене для группы контроллеров домена.
Как вы можете себе представить, когда кто-то говорит, что группа "Администраторы домена" имеет права администратора в домене, это означает, что это группа, для которой есть много ACE в объектах с большим количеством прав, поэтому вы можете предположить, что группа принадлежит к группе "Администраторы домена". Группа администраторов домена, вы можете выполнять множество действий с привилегиями, но в конечном итоге именно списки DACL объектов определяют силу группы/пользователя.
Помимо объектов базы данных, на компьютерах с Windows также есть много защищаемых объектов (https://docs.microsoft.com/en-us/windows/win32/secauthz/securable-objects), которые также защищены локальными DACL, управляемыми локальным компьютером. Среди этих объектов файлы/каталоги, процессы, ключи реестра или службы. Но поскольку администраторы домена по умолчанию добавляются в локальную группу администраторов на машинах, обычно администратор домена может получить доступ к любому локальному объекту на компьютере с Windows. Вы можете использовать такие инструменты, как Get-Acl (https://docs.microsoft.com/en-us/po...wershell.security/get-acl?view=powershell-7.1), icacls (https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/icacls), для проверки ACL файлов.
ACL-атаки
Из-за огромного количества списков ACL, которые могут находиться в домене, управлять ими может быть сложно. Это может привести к нескольким неправильным конфигурациям (https://www.ired.team/offensive-sec...eros-abuse/abusing-active-directory-acls-aces), которые могут позволить злоумышленнику повысить привилегии (https://blog.fox-it.com/2018/04/26/escalating-privileges-with-acls-in-active-directory/) в домене или даже в лесу (помните, что домены одного и того же леса связаны, поэтому вы можете добавить ссылку ACE на участников других доменов). Давайте рассмотрим некоторые неверные конфигурации:
- Измените пароль пользователя: если у вас есть права User-Force-Change-Password или GenericAll на объект пользователя, вы можете взять на себя учетную запись, установив новый пароль.
- Сделайте пользователя Kerberoasteable: если вы можете написать SPN в свойстве ServicePrincipalName пользователя, вы можете выполнить атаку Kerberoast (https://www.ired.team/offensive-sec...-directory-kerberos-abuse/t1208-kerberoasting) на эту учетную запись и попытаться взломать ее пароль. Для записи SPN требуется, чтобы у вас была проверенная запись Validated-SPN (https://docs.microsoft.com/en-us/windows/win32/adschema/r-validated-spn) с WritePropertyExtended, GenericWrite или GenericAll.
- Выполнение вредоносного сценария: если вы можете изменить свойство ScriptPath пользователя с помощью WriteProperty, GenericWrite или GenericAll, то вы можете установить вредоносный файл, который будет выполняться при следующем входе пользователя в систему. Вы можете использовать путь UNC (https://www.ired.team/offensive-sec...tive-directory-acls-aces#genericwrite-on-user), чтобы указать на общий ресурс. Вам также может потребоваться включить флаг SCRIPT для свойства UserAccountControl.
- Добавить пользователей в группу: если вы можете изменить свойство участников группы с помощью WriteProperty, GenericWrite или GenericAll, то вы можете добавить любого члена в группу. Если у вас есть право на самостоятельное членство, вы можете добавить текущего пользователя в эту группу.
- Атака RBCD Kerberos (https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/resource-based-constrained-delegation-ad-computer-object-take-over-and-privilged-code-execution) : если вы можете изменить msDS-AllowedToActOnBehalfOfOtherIdentity учетной записи компьютера с помощью WriteProperty, GenericWrite или GenericAll, то вы включаете ограниченное делегирование на основе ресурсов Kerberos для другого пользователя к компьютерным службам и, наконец, получаете доступ в качестве администратора к компьютеру.
- Пароль LAPS (https://adsecurity.org/?p=3164) : если вы можете прочитать конфиденциальное свойство компьютера ms-Mcs-AdmPwd, используемое LAPS для хранения пароля локального администратора машины, то вы можете прочитать его для доступа к машине в качестве локального администратора. Вы можете определить использование LAPS на компьютере, проверив, существует ли свойство ms-Mcs-AdmPwdExpirationTime в его учетной записи компьютера.
- Атака DCSync (https://adsecurity.org/?p=1729) : если у вас есть расширенные права DS-Replication-Get-Changes и DS-Replication-Get-Changes-All на объект домена, вы можете выполнить атаку DCSync для создания дампа содержимого базы данных.
- Злоупотребление GPO: если вы можете изменить GPC-File-Sys-Path контейнера групповой политики (https://zer1t0.gitlab.io/posts/attacking_ad/#group-policy-container) с помощью WriteProperty, GenericWrite или GenericAll, то вы можете изменить GPO и выполнить код на компьютерах, затронутых GPO.
- Изменить ACL: если у вас есть право WriteDacl (или GenericAll), то вы можете создать ACE, чтобы дать любое право на объект и выполнить некоторые из предыдущих атак. Кроме того, если у вас есть право WriteOwner, поскольку объект-владелец имеет неявное право WriteDacl, вы можете изменить владельца объекта на своего пользователя, а затем изменить ACL.
Помимо возможности повышения привилегий, ACL также могут быть весьма полезными и незаметными, если вы хотите создать лазейки (https://www.specterops.io/assets/resources/an_ace_up_the_sleeve.pdf) , чтобы сохранить свой доступ в сети. Чтобы создать бэкдоры, есть несколько приемов сокрытия вредоносных ACE, описанных в официальном документе An ACE Up the Sleeve (https://www.specterops.io/assets/resources/an_ace_up_the_sleeve.pdf) , написанном командой Specterops, которые вы должны проверить.
AdminSDHolder
Однако, возможно, один из самых интересных приемов сохранения — это модификация объекта AdminSDHolder. AdminSDHolder — это специальный объект в базе данных, список DACL которого используется в качестве шаблона для дескриптора безопасности привилегированных субъектов.
PS C:\> Get-ADObject 'CN=AdminSDHolder,CN=system,DC=contoso,DC=local'
DistinguishedName Name ObjectClass ObjectGUID
----------------- ---- ----------- ----------
CN=AdminSDHolder,CN=system,DC=contoso,DC=local AdminSDHolder container 7f34e8a5-ffbd-474a-b436-1e02b7b49984
Каждые 60 минут SDProp (распространитель дескрипторов безопасности) проверяет дескриптор безопасности этих привилегированных субъектов и заменяет их DACL копией DACL AdminSDHolder (если они отличаются). Это делается для предотвращения изменений в списках DACL этих субъектов, но если вы можете добавить пользовательские элементы управления доступом в список DACL AdminSDHolder, то эти новые элементы управления доступом (https://adsecurity.org/?p=1906) также будут применяться к защищенным субъектам.
По умолчанию следующие участники "защищены" AdminSDHolder:
Account Operators
Administrator
Administrators
Backup Operators
Domain Admins
Domain Controllers
Domain Guests
Enterprise Admins
Enterprise Key Admins
Enterprise Read-Only Domain Controllers
Key Admins
krbtgt
Print Operators
Read-only Domain Controllers
Replicator
Schema Admins
Server Operators
Привилегии
Если вы знакомы с платформой Windows, возможно, вы знаете о привилегиях пользователей, которые позволяют пользователям выполнять действия в обход ACL объектов. Например, SeDebugPrivilege на компьютере с Windows позволяет читать/записывать любую память процесса на компьютере, даже если у вас нет прав.
В Active Directory также можно злоупотреблять некоторыми привилегиями (https://adsecurity.org/?p=3700) (в основном в контроллерах домена):
SeEnableDelegationPrivilege
SeEnableDelegationPrivilege (http://www.harmj0y.net/blog/activedirectory/the-most-dangerous-user-right-you-probably-have-never-heard-of/) должен быть установлен в контроллере домена для пользователя (это локальная привилегия), а затем он позволяет изменять свойство msDS-AllowedToDelegateTo пользователей и флаги TRUSTED_FOR_DELEGATION и TRUSTED_TO_AUTH_FOR_DELEGATION из свойства UserAccountControl. Другими словами, SeEnableDelegationPrivilege позволяет управлять параметрами Kerberos Unconstrained и Constrained Delegation домена, которые злоумышленник может использовать для повышения привилегий. По умолчанию предоставляется только учетной записи администратора.
SeBackupPrivilege
Привилегия резервного копирования (https://docs.microsoft.com/en-us/wi...policy-settings/back-up-files-and-directories) позволяет читать любой файл контроллера домена, чтобы сделать его резервную копию, которую можно использовать для чтения базы данных домена. По умолчанию предоставляется группам Операторы резервного копирования, Операторы сервера и Администраторы. Эта привилегия эффективна только при использовании API резервного копирования NTFS (https://docs.microsoft.com/en-us/windows/win32/backup/backup-reference), доступ к которому можно получить с помощью утилиты wbadmin (https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/wbadmin) или Powershell WindowsServerBackup (https://docs.microsoft.com/en-us/powershell/module/windowsserverbackup/?view=windowsserver2019-ps) (для обоих требуется функция резервного копирования Windows Server (https://docs.microsoft.com/en-us/pr...ows-server-2012-R2-and-2012/jj614621(v=ws.11))). Вы также можете использовать reg save ( https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/reg-save) для доступа к секретам SAM и LSA (https://zer1t0.gitlab.io/posts/attacking_ad/#dumping-registry-credentials) .
SeRestorePrivilege
Привилегия восстановления ( https://docs.microsoft.com/en-us/wi...policy-settings/restore-files-and-directories) позволяет записывать любой файл на контроллере домена из резервной копии. Это может позволить злоумышленнику изменить базу данных домена. По умолчанию предоставляется группам Операторы резервного копирования, Операторы сервера и Администраторы. Вы можете использовать эту привилегию для изменения ключей реестра и обеспечения привилегированного выполнения команд (https://github.com/hatRiot/token-priv/blob/master/poptoke/poptoke/SeRestorePrivilege.cpp) .
SeTakeOwnershipPrivilege
С привилегией владения ( https://docs.microsoft.com/en-us/wi...ings/take-ownership-of-files-or-other-objects) вы можете стать владельцем защищаемых объектов машины (https://docs.microsoft.com/en-us/windows/win32/secauthz/securable-objects), таких как файлы, процессы или ключи реестра. Владелец объекта всегда может изменить разрешения объекта (WriteDacl). Например, вы можете использовать вызов API SetNamedSecurityInfo (https://github.com/hatRiot/token-pr...toke/poptoke/SeTakeOwnershipPrivilege.cpp#L31), чтобы стать владельцем объекта. Как я могу стать владельцем объектов базы данных Active Directory???
Помимо привилегий, используемых в домене, также полезно знать об опасных привилегиях (https://foxglovesecurity.com/2017/0...leges-for-windows-local-privilege-escalation/), которые могут быть полезны для повышения привилегий на компьютере с Windows.
Обычно используются следующие:
SeDebugPrivilege
Пользователь может отлаживать любой процесс на машине, поэтому он может вводить код в любой процесс, что может привести к повышению привилегий, или читать память процесса, что позволяет читать, например, секреты процесса lsass пользователей, вошедших в систему. машина (можно использовать mimikatz (https://github.com/gentilkiwi/mimikatz)).
SeImpersonatePrivilege
Пользователь может получить токены безопасности (https://github.com/hatRiot/token-priv/blob/master/abusing_token_eop_1.0.txt#L155) других пользователей на машине. Если уровень маркера олицетворения — SecurityDelegation, то пользователь может использовать этот маркер для олицетворения целевого пользователя на других компьютерах домена (маркеры SecurityDelegation связаны с учетными данными пользователя, такими как билеты Kerberos, которые можно использовать в сетевых подключениях). Если уровень маркера олицетворения — SecurityImpersonation, то целевой пользователь может олицетворяться только на локальном компьютере (полезно для повышения привилегий). SeImpersonatePrivilege предоставляется "NT AUTHORITY\Network Service", который обычно используется для запуска веб-серверов и тому подобного, поэтому, если вы можете скомпрометировать веб-сервер, возможно, вы можете использовать инкогнито (https://labs.f-secure.com/archive/incognito-v2-0-released/), чтобы выдать себя за какого-либо пользователя домена в сети. Но определенно, если вы хотите повысить привилегии с помощью SeImpersonatePrivilege на локальной машине, используйте картофель (https://jlajara.gitlab.io/others/2020/11/22/Potatoes_Windows_Privesc.html).
Существуют и другие привилегии, которые можно использовать для повышения привилегий на компьютерах с Windows. Если они вас интересуют, вам следует проверить репозиторий token-priv (https://github.com/hatRiot/token-priv) FoxGlove, который включает документ с их описанием и PoC для их использования, настоятельно рекомендуемый ресурс.
Групповая политика
Целью Active Directory является управление компьютерами и пользователями организации. И часть процесса управления осуществляется групповой политикой.
Групповая политика (https://adsecurity.org/?p=2716)— это механизм, который позволяет применять набор правил/действий к пользователям и компьютерам сети Active Directory. Вот некоторые из возможностей:
- Отключить NTLM
- Требовать сложности пароля
- Выполнять запланированные или немедленные задачи
- Создавать локальных пользователей на компьютерах
- Устанавливать обои по умолчанию
- Синхронизировать файлы с OneDrive
- Так далее
Чтобы определить правила, вы можете создать объекты групповой политики (GPO). Каждый объект групповой политики определяет ряд политик, которые можно применять к определенным машинам доменов. Кроме того, вы можете создавать политики, которые применяются ко всей машине или сеансам пользователей. Например, вы можете выполнить сценарий при запуске компьютера или при входе пользователя в систему.
Область действия объекта групповой политики
При создании объекта групповой политики необходимо указать, к каким компьютерам он будет применяться (https://docs.microsoft.com/en-us/pr...rver-2012-R2-and-2012/dn581922(v=ws.11)#scope). Для этого вам необходимо связать объект групповой политики с одним из следующих контейнеров базы данных:
- Домен
- Организационная единица (OU)
- Site (https://docs.microsoft.com/en-us/windows/win32/adschema/c-site) (контейнер для групп компьютеров, которые физически расположены близко друг к другу, не рекомендуется для объектов групповой политики)
На компьютере с Windows также может быть локальная групповая политика. Таким образом, к машине на разных уровнях можно применить множество различных объектов групповой политики, которые обрабатываются в следующем порядке:
1. Локально
2. Сайт
3. Домен
4. Организационная единица
Здесь локальные GPO имеют наименьшее предпочтение, а OU GPO — наиболее предпочтительные. Поэтому, если, например, объект групповой политики, примененный к домену, противоречит локальному объекту групповой политики, то объект групповой политики домена будет следовать.
Однако для объектов групповой политики Active Directory (не локальных) также возможно установить правило No Override. Таким образом, если установлено правило политики домена, никакие правила из подразделений не могут противоречить этому вышестоящему правилу.
Кроме того, с объектом групповой политики может быть связан запрос WMI (https://docs.microsoft.com/en-us/wi...ndows-firewall/create-wmi-filters-for-the-gpo) , что позволяет отфильтровать компьютер, к которому будет применяться объект групповой политики. Например, чтобы применить политики только к компьютерам с Windows 7.
В домене каждый компьютер проверяет наличие обновлений политики каждые 90 минут, за исключением контроллеров домена, которые делают это каждые 5 минут. Вы также можете выполнить немедленную проверку с помощью gpupdate (https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/gpupdate) .
Каждый объект групповой политики идентифицируется идентификатором GUID и состоит из двух объектов: шаблона групповой политики и контейнера групповой политики.
Шаблон групповой политики
Шаблон групповой политики — это каталог в общей папке SYSVOL. Шаблоны могут находиться в \\<домен>\SYSVOL\<домен>\Policies\. Каждому каталогу шаблона присваивается имя с использованием GUID объекта групповой политики.
PS C:\> ls \\contoso.local\SYSVOL\contoso.local\Policies\
Directory: \\contoso.local\SYSVOL\contoso.local\Policies
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 11/28/2020 10:02 AM {31B2F340-016D-11D2-945F-00C04FB984F9}
d----- 11/28/2020 10:02 AM {6AC1786C-016F-11D2-945F-00C04fB984F9}
d----- 4/19/2021 5:12 PM {BE864EFE-6C07-4A53-A9D8-7EB6EB36BE5A}
Каждый каталог GPO содержит следующие элементы:
- Каталог машины: для политик на уровне машины.
- Пользовательский каталог: для политик на уровне пользователя.
- GPT.INI: основная информация о GPO, версия и отображаемое имя.
Затем в этих каталогах (https://docs.microsoft.com/en-us/pr...=MSDN#subfolders-of-the-group-policy-template) могут быть самые разные файлы и каталоги, в которых вы можете найти INI-файлы конфигурации, в которых указаны значения ключей реестра, членов групп или сценариев для выполнения. И, если вам повезет, возможно, вы найдете учетные данные в сценариях или файлах предпочтений групповой политики (GPP) (https://adsecurity.org/?p=2288) с тегами cpassword. Вы можете использовать сценарий Get-GPPPasword (https://github.com/PowerShellMafia/PowerSploit/blob/master/Exfiltration/Get-GPPPassword.ps1) для поиска учетных данных GPP.
Предпочтения групповой политики (https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn581922(v=ws.11)#scope) — это имя, используемое для набора новых политик, добавленных в Windows Server 2008.
Контейнер групповой политики
Чтобы машины могли находить шаблоны групповой политики, база данных Active Directory хранит информацию об объектах групповой политики в контейнере CN=Policies,CN=System,DC=<domain>,DC=<com>. Каждый объект групповой политики хранится в объекте GroupPolicyContainer (https://docs.microsoft.com/en-us/windows/win32/adschema/c-grouppolicycontainer), содержащем объект групповой политики GUID и путь к шаблону групповой политики.
PS C:\> Get-ADObject -LDAPFilter "(ObjectClass=GroupPolicyContainer)" -Properties Name, DisplayName,gPCFileSysPath | select Name, DisplayName,GPCFileSysPath | Format-List
Name : {31B2F340-016D-11D2-945F-00C04FB984F9}
DisplayName : Default Domain Policy
GPCFileSysPath : \\contoso.local\sysvol\contoso.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}
Name : {6AC1786C-016F-11D2-945F-00C04fB984F9}
DisplayName : Default Domain Controllers Policy
GPCFileSysPath : \\contoso.local\sysvol\contoso.local\Policies\{6AC1786C-016F-11D2-945F-00C04fB984F9}
Name : {BE864EFE-6C07-4A53-A9D8-7EB6EB36BE5A}
DisplayName : test policy
GPCFileSysPath : \\contoso.local\SysVol\contoso.local\Policies\{BE864EFE-6C07-4A53-A9D8-7EB6EB36BE5A}
Вы должны заметить, что GUID GPO отличается от GUID, используемого для идентификации каждого объекта в базе данных Active Directory. Также обратите внимание, что если вы можете изменить свойство GPCFileSysPath (https://docs.microsoft.com/en-us/windows/win32/adschema/a-gpcfilesyspath) объекта групповой политики, вы можете установить контролируемый вами путь и создать вредоносный объект групповой политики, который может содержать вредоносные сценарии, которые будут выполняться на нескольких машинах.
С другой стороны, объекты базы данных домена, подразделений и сайтов связаны с объектами групповой политики с помощью свойства GpLink (https://docs.microsoft.com/en-us/windows/win32/adschema/a-gplink) .
PS C:\> Get-ADObject -LDAPFilter '(gPLink=*)' -Properties CanonicalName,gpLink | select objectclass,CanonicalName,gplink | Format-List
objectclass : domainDNS
CanonicalName : contoso.local/
gplink : [LDAP://cn={BE864EFE-6C07-4A53-A9D8-7EB6EB36BE5A},cn=policies,cn=system,DC=contoso,DC=local;1][LDAP://C
N={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=contoso,DC=local;0]
objectclass : organizationalUnit
CanonicalName : contoso.local/Domain Controllers
gplink : [LDAP://CN={6AC1786C-016F-11D2-945F-00C04fB984F9},CN=Policies,CN=System,DC=contoso,DC=local;0]
objectclass : organizationalUnit
CanonicalName : contoso.local/web servers
gplink : [LDAP://cn={BE864EFE-6C07-4A53-A9D8-7EB6EB36BE5A},cn=policies,cn=system,DC=contoso,DC=local;0]
Компьютер может определить объекты групповой политики, которые применяются к нему самому, изучив объекты OU, к которым он принадлежит, и объект домена.
Например, машина, на которой объект компьютера находится в CN=mypc,OU=workstations,OU=computers,DC=domain,DC=com, будет применять объекты групповой политики рабочих станций, OU компьютера и домена domain.com.
PS C:\> Get-ADObject -LDAPFilter '(gPLink=*)' -SearchBase "CN=Configuration,$((Get-ADDomain).DistinguishedName)" -Properties CanonicalName,gpLink | select objectclass,CanonicalName,gplink | Format-List
objectclass : site
CanonicalName : contoso.local/Configuration/Sites/mysite
gplink : [LDAP://cn={BE864EFE-6C07-4A53-A9D8-7EB6EB36BE5A},cn=policies,cn=system,DC=contoso,DC=local;0]
