AdminSDHolder
После того как злоумышленник скомпрометировал привилегированные учетные данные, он стремится обеспечить сохранение своего доступа к домену. То есть, даже если скомпрометированные учетные записи будут отключены или их пароли сброшены, злоумышленник хочет легко восстановить права администратора домена.
Один из способов добиться такой устойчивости — использовать особенности Active Directory, предназначенные для защиты привилегированных учетных записей - AdminSDHolder. Рассмотрим как работает эта тактика.
AdminSDHolder — это контейнер, который существует в каждом домене Active Directory для особой цели: список управления доступом (ACL) объекта AdminSDHolder используется как шаблон для копирования разрешений для всех защищенных групп в Active Directory и их участников. (Защищенные группы — это встроенные группы, которые определены как требующие повышенной безопасности, включая Domain Admins, Administrators, Enterprise Admins и Schema Admins.)
Процесс SDProp применяет ACL объекта AdminSDHolder ко всем защищенным группам и их участникам каждые 60 минут по умолчанию. Поскольку ACL для AdminSDHolder изначально настроен быть крайне ограничительным, этот процесс обычно способствует усилению безопасности. Однако, если злоумышленник изменит ACL для AdminSDHolder, то эти измененные разрешения на доступ автоматически будут применены ко всем защищенным объектам. Например, злоумышленник может добавить контролируемую им учетную запись пользователя в ACL AdminSDHolder и предоставить ей полный доступ:
Даже если администратор заметит некорректное разрешение у конкретного защищенного объекта и удалит его, процесс SDProp просто снова применит измененный ACL в течение часа. В результате такая стратегия позволяет злоумышленникам получать доступ к конфиденциальной информации.
AdminCount — это атрибут объектов Active Directory. Значение AdminCount, равное 1, указывает на то, что объект является (или был) участником хотя бы одной из защищенных групп. Соответственно, анализ всех объектов с AdminCount, равным 1, позволит понять, насколько серьезной могла бы быть атака на AdminSDHolder в вашей среде.
Этот анализ можно легко выполнить с помощью PowerShell и операции LDAP-фильтрации:
$ldapFilter = “(adminCount=l)”
$domain = New-Object System.DirectoryServices.DirectoryEntry
$search = New-Object System.DirectoryServices.DirectorySearcher
$search.SearchRoot = $domain
$search.PageSize = 1000
$search.Filter = $ldapFilter
$search.SearchScope = “Subtree”
$results = $search.FindAll()
foreach ($result in $results)
{
SuserEntry = $result.GetDirectoryEntry()
Write-host “Object Name = “ $userEntry.name
Write-host “Obect Class = “ $userEntry.objectClass
foreach($AdminCount in $userEntry.adminCount)
{
Write-host “AdminCount =” $AdminCount
Write-host “”
}
}Стоит отметить, что даже если пользователь удален из привилегированной группы, его значение AdminCount все равно останется равным 1; однако Active Directory больше не будет считать его защищенным объектом, поэтому ACL AdminSDHolder к нему применяться не будет. Тем не менее, у такого пользователя, скорее всего, все еще останется версия разрешений AdminSDHolder.
Защита от злоупотреблений AdminSDHolder
Только пользователи с административными правами могут изменять ACL AdminSDHolder, поэтому лучший способ защититься от этой тактики — предотвратить компрометацию административных учетных данных. Кроме того, в случае компрометации административной учетной записи важно мониторить объект AdminSDHolder и получать уведомления о любых изменениях. Изменения не должны происходить в принципе, поэтому любое уведомление требует немедленного расследования и отката изменений. Также важно регулярно составлять отчеты по объектам со значением AdminCount, равным 1.