16 основных уязвимостей Active Directory

Следующая информация предназначена для помощи тестерам на проникновение и аудиторам в выявлении типичных проблем, связанных с безопасностью, когда дело доходит до администрирования сред Active Directory. Он содержит шаги по обнаружению каждой уязвимости практически с точки зрения тестера на проникновение, используя стандартный набор наступательных инструментов и легко доступные инструменты. Разберем 16 основных уязвимостей Active Directory.

16 основных уязвимостей Active Directory

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

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

1. Пользователи, имеющие право добавлять компьютеры в домен

При установке Active Directory по умолчанию любой пользователь домена может добавлять в домен рабочие станции. Это определяется атрибутом ms-DS-MachineAccountQuota, который по умолчанию имеет значение 10.

Это означает, что любой пользователь домена с низкими привилегиями может присоединить к домену до 10 компьютеров. Ладно, наверное, не очень, но что в этом такого?

Проблема в том, что эти настройки позволяют любому пользователю присоединиться к своему собственному неуправляемому компьютеру для доступа к корпоративному домену со следующими преимуществами:

• Никакие антивирусные программы или решения EDR не будут загружены на их машину.
• К их системе не будут применяться никакие настройки или политики GPO.
• Позволяет им иметь права администратора в своей системе.

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

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

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

Как проверить

Самый простой способ проверить это — подключить тестовую машину Windows (физическую или виртуальную) к целевой корпоративной сети, чтобы она могла подключиться к контроллерам домена.

1) Запустите «sysdm.cpl», чтобы открыть «Свойства системы» -> нажмите «Изменить» и укажите имя целевого домена:

Щелкните «ОК».

2) Теперь нам будет предложено ввести учетные данные. Предоставьте любые учетные данные пользователя домена с низким уровнем привилегий.

В случае успеха мы должны увидеть сообщение «Добро пожаловать в домен org.local!» сообщение, и наша тестовая машина должна быть добавлена ​​в AD в контейнере CN = Computers.

2. Атрибут AdminCount установлен для обычных пользователей.

Атрибут AdminCount в Active Directory используется для защиты административных пользователей и членов привилегированной группы, например:

• Администраторы домена
• Администраторы предприятия
• Расписание администраторов
• Операторы резервного копирования
• Операторы сервера
• Репликатор

Внутренняя работа, связанная с этим, — довольно сложная тема, включающая объект AdminSDHolder и процесс SDProp, который периодически изменяет такие учетные записи. Короче говоря, атрибут AdminCount никогда не следует устанавливать для обычных пользователей, поскольку он может предоставить им излишне высокие привилегии.

Например, это может помешать пользователям применять корпоративные групповые политики и модификации ACL, или, с другой стороны, это может привести к назначению им высоких привилегий (см. Описанный здесь вектор атаки с постоянством). В любом случае это представляет собой риск наличия в организации «бэкдор» пользователей, даже не подозревающих об этом.

Проблема в том, что атрибут AdminCount автоматически устанавливается в 1, когда пользователь назначается какой-либо привилегированной группе, но он никогда не сбрасывается автоматически, когда пользователь удаляется из этих групп.

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

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

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

Как проверить

Чтобы найти пользователей с атрибутом AdminCount, равным 1, мы можем использовать инструмент LDAPDomainDump. Этот инструмент собирает важную информацию обо всех пользователях, группах и компьютерах в домене. Все, что нам нужно, это учетные данные любого пользователя домена с низким уровнем привилегий и возможность доступа к порту LDAP любого контроллера домена.

Вот что делать …

1) Сначала соберите информацию с контроллера домена:

python ldapdomaindump.py -u <DOMAIN>\\<USER> -p <PASS> -d <DELIMITER> <DC-IP>

# Example:

python ldapdomaindump.py -u example.com\\john -p pass123 -d ';' 10.100.20.1

Обратите внимание, что вместо пароля мы также могли бы просто предоставить хеш NTLM (pass-the-hash).

2) После завершения сброса мы можем получить список пользователей с атрибутом AdminCount, равным 1, путем анализа файла «domain_users.json»:

jq -r '.[].attributes | select(.adminCount == [1]) | .sAMAccountName[]' domain_users.json

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

Import-Module ActiveDirectory

Get-AdObject -ldapfilter "(admincount=1)" -properties admincount

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

3. Большое количество пользователей в привилегированных группах.

Эта уязвимость связана с чрезмерным количеством пользователей в группах привилегий, таких как:

• Администраторы домена
• Расписание администраторов
• Администраторы предприятия

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

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

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

Как проверить

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

Вот как перечислить эти группы с компьютера, подключенного к домену, с Windows:

net group "Schema Admins" /domain

net group "Domain Admins" /domain

net group "Enterprise Admins" /domain

На неподключенной машине с Windows нам нужно сначала пройти аутентификацию в домене:

runas /netonly /user:<DOMAIN>\<USER> cmd.exe

Вот как мы можем проверить это в Linux (например, Kali Linux) с помощью команды «net»:

net rpc group members 'Schema Admins' -I <DC-IP> -U "<USER>"%"<PASS>"

net rpc group members 'Domain Admins' -I <DC-IP> -U "<USER>"%"<PASS>"

net rpc group members 'Enterprise Admins' -I <DC-IP> -U "<USER>"%"<PASS>"

 

# Example:

net rpc group members 'Domain Admins' -I 10.10.30.52 -U "john"%"pass123"

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

4. Учетные записи служб, являющиеся членами администраторов домена.

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

Проблема в том, что этим учетным записям назначаются непомерные привилегии и / или членство, например, при добавлении в группу «Администраторы домена».

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

Это означает, что если такая уязвимая учетная запись службы будет скомпрометирована, это позволит злоумышленнику получить полный контроль над доменом AD. И, наверное, надолго.

How to test

Просто просмотрите всех участников, принадлежащих к привилегированным группам:

net group "Schema Admins" /domain

net group "Domain Admins" /domain

net group "Enterprise Admins" /domain

В Linux мы можем использовать команду «net», как показано в предыдущей уязвимости.

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

5. Чрезмерные привилегии, позволяющие администраторам теневого домена

Эта уязвимость более сложная. Речь идет о неправильном использовании прав Active Directory и расширенных прав, также известных как записи управления доступом (ACE).

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

Некоторые из прав, которые обычно используются не по назначению, включают:

• ForceChangePassword — Возможность сбросить пароль другого пользователя
• GenericAll — полный контроль над объектом (чтение / запись)
• GenericWrite — Обновление любых атрибутов объекта
• WriteOwner — Предполагает владение объектом
• WriteDacl — изменение DACL объекта
• Самостоятельно — произвольно изменять себя

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

Вот очень хорошая статья, в которой эта проблема описывается более подробно и с примерами:

https://ired.team/offensive-security-experiments/active-directory-kerberos-abuse/abusing-active-directory-acls-aces

Как проверить

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

Одним из инструментов, который очень помогает в этом процессе, является Bloodhound. Вот вкратце его использование:

1) Сначала мы используем «приемник» для сбора данных из среды AD — например, SharpHound.

2) Затем мы загружаем данные в интерфейсный интерфейс Bloodhound, где мы можем визуализировать отношения между объектами.

Затем язык запросов Bloodhound позволяет нам находить пути, как в этом примере:

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

• «Найдите 10 лучших пользователей с наибольшим количеством прав локального администратора»
• «Найдите кратчайшие пути к администраторам домена»
• «Доверительные отношения между доменами карты»

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

Вот еще несколько запросов, которые могут помочь (ссылка1, ссылка2).

6. Учетные записи служб, уязвимые для Kerberoasting.

Kerberoasting — очень популярный вектор атаки, направленный на учетные записи служб в Active Directory.

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

Вот оригинал статьи (слайды) Тима Медина — автора Kerberoasting:

https://www.sans.org/cyber-security-summit/archives/file/summit-archive-1493862736.pdf

Как проверить

Эта атака была автоматизирована с помощью нескольких инструментов (например, Impacket или Rubeus), и все, что нам нужно для тестирования, — это иметь какие-либо учетные данные пользователя домена с низким уровнем привилегий.

Вот пример использования Impacket:

GetUserSPNs.py -request <DOMAIN>/<USER>:<PASS>

 

# Example:

GetUserSPNs.py -request example.com/john:pass123

Обратите внимание, что вместо пароля мы также можем использовать хеш NTLM (pass-the-hash).

Если мы получили какие-то хэши, это означает, что есть учетные записи служб, уязвимые для Kerberoasting.

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

hashcat -m 13100 -a 0 hashes.txt wordlist.txt

 

# Faster with optimized kernels, but limited password length to 31 characters:

hashcat -m 13100 -a 0 -O --self-test-disable hashes.txt wordlist.txt

Вот что мы должны посоветовать нашим клиентам, когда дело доходит до защиты учетных записей служб от Kerberoasting:

• • Используйте новые алгоритмы шифрования, такие как AES128, AES256 или лучше
  • Принудительное использование надежных и сложных паролей (в идеале длиной 25+ символов)
  • Убедитесь, что их пароль периодически истекает
  • Держите их привилегии как можно ниже

7. Пользователи с паролями, срок действия которых не истекает.

В основном из-за удобства в некоторых организациях учетные записи домена настроены с установленным флагом DONT_EXPIRE_PASSWORD.

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

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

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

Как проверить

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

Вот шаги:

1) Сначала соберите информацию с контроллера домена:

python ldapdomaindump.py -u <DOMAIN>\\<USER> -p <PASS> -d <DELIMITER> <DC-IP>

 

# Example:

python ldapdomaindump.py -u example.com\\john -p pass123 -d ';' 10.100.20.1

2) После завершения сброса мы можем получить список пользователей с паролями с неограниченным сроком действия, используя следующую команду:

grep DONT_EXPIRE_PASSWD domain_users.grep | grep -v ACCOUNT_DISABLED | awk -F ';' '{print $3}'

В качестве альтернативы для получения списка таких пользователей на контроллере домена можно использовать следующую команду PowerShell:

Import-Module ActiveDirectory
Get-ADUser -filter * -properties Name, PasswordNeverExpires | where { $_.passwordNeverExpires -eq "true" } | where {$_.enabled -eq "true" }

8. Пользователи с паролем не требуются.

Еще один интересный флаг в Active Directory — это флаг PASSWD_NOTREQD. Если для учетной записи пользователя установлен этот флаг, это означает, что для учетной записи не требуется пароль.

Это не означает, что у учетной записи пользователя нет пароля, это просто означает, что он не обязательно должен быть. Это означает, что подойдет любой пароль — короткий, несоответствующий (противоречащий политике паролей домена) или пустой. Просто любой.

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

Как проверить

Поиск пользователей с установленным флагом PASSWD_NOTREQD очень похож на поиск пользователей с паролями, срок действия которых не истекает. Мы снова можем использовать инструмент LDAPDomainDump.

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

1) Сначала соберите информацию с контроллера домена:

python ldapdomaindump.py -u <DOMAIN>\\<USER> -p <PASS> -d <DELIMITER> <DC-IP>

# Example:

python ldapdomaindump.py -u example.com\\john -p pass123 -d ';' 10.100.20.1

2) После завершения дампа получите список пользователей с флагом PASSWD_NOTREQD, используя следующие команды:

grep PASSWD_NOTREQD domain_users.grep | grep -v ACCOUNT_DISABLED | awk -F ';' '{print $3}'

В качестве альтернативы можно использовать следующую команду PowerShell на контроллере домена, чтобы получить список пользователей с ненужным паролем:

Import-Module ActiveDirectory

Get-ADUser -Filter {UserAccountControl -band 0x0020}

9. Хранение паролей с использованием обратимого шифрования.

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

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

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

• • Права на выполнение операции DCSYNC (например, через Mimikatz)
  • Доступ к файлу NTDS.DIT ​​на контроллере домена

Как проверить

Оба метода уже подразумевают полную компрометацию домена AD, так что на самом деле это не такая уж катастрофа.

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

Итак, чтобы проверить эту уязвимость, мы должны выгрузить файл NDTS.DIT ​​с контроллера домена и извлечь из него хэши. Только тогда мы сможем увидеть, у каких пользователей пароли хранятся с использованием обратимого шифрования — их пароли будут просто распечатаны в виде обычного текста.

Обратите внимание, что мы также можем получить пароль в виде обычного текста, используя Mimikatz, работающий в контексте пользователя с высокими привилегиями (который может выполнять DCSYNC), но нам нужно будет знать имя пользователя затронутого пользователя.

Вот команда Mimikatz, которая сделает это:

mimikatz # lsadump::dcsync /domain:<DOMAIN> /user:<AFFECTED-USER>

# Example:

mimikatz # lsadump::dcsync /domain:example.com /user:poorjohn

В любом случае пароли никогда не следует хранить в виде обычного текста. Эта уязвимость дает злоумышленникам, скомпрометировавшим домен AD (например, APT), и высокопривилегированным инсайдерам (например, администраторам домена) мгновенный доступ к паролям уязвимых пользователей в виде обычного текста.

10. Хранение паролей с использованием хэшей LM.

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

LM-хэш — это устаревший метод хранения паролей, который имеет следующие недостатки:

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

Из-за этих недостатков LM-хэши чрезвычайно легко взломать. Любой, у кого есть к ним доступ, например высокопривилегированные инсайдеры (администраторы домена) могут легко взломать их и получить пароли в виде простого текста.

Как проверить

Как указывалось выше, эта проблема обычно обнаруживается после взлома AD и извлечения файлов NTDS.DIT.

Вот несколько слов о хэшах LM и NTLM:

Когда для части LM установлено значение, отличное от «aad3b435b51404eeaad3b435b51404ee» (пустая строка), это означает, что мы ищем хеш LM.

Итак, вот как мы можем идентифицировать хеши LM:

grep -iv ':aad3b435b51404eeaad3b435b51404ee:' dumped_hashes.txt