Атакующий AD - аутентификация:

Атакующий AD - аутентификация:

Атака на аутентификацию Active Directory:

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

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

Есть три метода обхода аутентификации AD, которые мы обсудим один за другим.

Хранение и извлечение кэшированных учетных данных:

Как и в моем предыдущем блоге, я уже обсуждал Kerberos, который хранит хешированные учетные данные организаций где-то для повторного создания запроса TGT или в LSASS (служба подсистемы локального органа безопасности).

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

Здесь мы собираемся использовать «Mimikatz» для извлечения хэшей из LSASS.

Примечание: Mimikatz работает с ранее определенными подписями. Он может работать в PowerShell или может работать как диспетчер задач.

а. Базовый подход:

я. Для начала вам нужно скачать мимкац в машину, вы можете найти его здесь.

II. После загрузки распаковать mimtakz, а затем открыть exe-файл, дважды щелкнув по нему, откроется терминал.

iii. Затем введите привилегия :: отладка, чтобы проверить процесс, принадлежащий другой учетной записи.

iv. Затем запустите sekurlsa :: logonpasswords, чтобы сбросить хэши паролей всех пользователей, вошедших в систему на текущем сервере, это также будет работать для сеансов удаленного входа.

На снимке экрана выше мы ясно видим NTLM, SHA1. Это означает, что мы используем Windows Server 2008 или более позднюю версию, потому что на этих серверах NTLM и SHA1 доступны только после Windows Server 2008. После сброса хэшей паролей теперь мы взламываем их в виде открытого текста, чтобы мы могли использовать пароль для повышения привилегий.

Примечание. Он показывает всю информацию об учетных данных, хранящуюся в LSASS, но я сосредоточусь только на одном.

Управление TGT и сервисными билетами:

Kerberos TGT и служебные билеты для пользователей, вошедших в систему, хранятся на локальном компьютере или в LSASS.

Итак, чтобы получить билеты зарегистрированных пользователей, мы будем использовать sekurlsa :: Tickets на mimikartz, мы получим результат ниже.

Примечание. TGS предоставит разрешение на доступ только к тем билетам, которые с ним связаны.

После выполнения этой команды мы можем легко получить «сеансовый ключ», связанный с TGT.

б. Атаки на служебные аккаунты:

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

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

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

Как использовать:

SPN для информационных служб Интернета существует в домене HTTP / example.com, и для запроса билета службы из него мы можем использовать класс KerberosRequestorSecurityToken.

i. Для загрузки любого сегмента кода мы используем командлет Add-Type с аргументом AssemblyName. Итак, здесь мы собираемся использовать пространство имен System.IdentityModel, которое по умолчанию не загружается в PowerShell. Теперь мы вызываем конструктор KerberosRequestorSecurityToken, указывая имя участника-службы с параметрами списка аргументов.

а. Add-Type -AssemblyName System.IdentityModel

б. New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList ‘HTTP / CorpWebServer.corp.com’

После этого мы получили сервисный билет, сгенерированный DC и сохраненный в локальной памяти Window 10.

II. Теперь мы проверяем, существует ли кешированный билет Kerberos или нет? Для этого мы используем команду klist. Мы также можем выполнить это с помощью mimikartz.

Когда мы запускаем команду klist на терминале:

Команда: klist

Когда мы запускаем команду klist на mimikartz

Команда: Kerberos :: list

iii. Теперь нам нужно загрузить сервисный тикет с помощью mimikartz.

Команда: Kerberos :: list / export

Это сообщит нам, где мы собираемся скачать билет.

iv. Для расшифровки билета службы мы используем технику перебора в Kerberos, то есть известную как «Kerberoasting», которая помогает нам предоставлять службы паролей в виде открытого текста.

Итак, чтобы выполнить это, сначала мы устанавливаем список слов, а затем устанавливаем пакет kerberoast (https://github.com/nidem/kerberoast). Затем запустите tgsrepcrack.py со списком слов, или мы можем использовать любой инструмент для взлома паролей, например John the Ripper вместо tgsrepcrack.py.

Примечание. Для этого этапа нам не нужны права администратора.

Мы должны выполнить этот шаг на машине kali и для этого команду:

python tgsrepcrack.py wordlist.txt 0–40e00000-tony@krbtgt~example.local-example.local.kirbi

символы после словаря обозначают файлы, которые мы экспортировали.

После этого шага мы получили все взломанные сервисные тикеты и соответствующие учетные данные в виде открытого текста.

c. Низкое и медленное угадывание пароля:

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

я. Мы в основном фокусируем политику блокировки учетной записи на том, сколько неудачных попыток будет заблокировано учетной записью. Поэтому для проверки мы используем команду net accounts.

Команда: чистые аккаунты

Сначала мы проверим порог блокировки учетных записей. Как и в моем случае, у меня не было политик блокировки учетных записей.

Предположим, что порог блокировки учетной записи равен пяти. Таким образом, при пятой неправильной попытке моя учетная запись была заблокирована на 30 минут, а окно наблюдения за блокировкой означает, что нам дается дополнительная «бесплатная» попытка входа каждые тридцать минут после последней попытки входа.

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

Не вызывая блокировки, пользователь домена надеется, что попытка входа в систему не потерпит неудачу для реальных пользователей ».

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

II. Мы тестируем вход пользователя в AD с помощью сценария Power Shell.

DirectoryEntry: мы можем предоставить 3 аргумента (путь LDAP, имя пользователя, пароль), а затем получить данные соответствующего пользователя.

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

Если учетные данные неверны, мы получим:

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

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

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