В этой статье мы представляем новые методы восстановления хэша NTLM из зашифрованных учетных данных, защищенных Credential Guard в Защитнике Windows. В то время как предыдущие методы обхода Credential Guard были сосредоточены на атакующих, нацеленных на новых жертв, которые вошли на скомпрометированный сервер, эти новые методы также могут быть применены к жертвам, вошедшим в систему до того, как сервер был скомпрометирован. Здесь рассмотрим как победить Credential Guard в Защитнике Windows
Credential Guard 101
Есть много сообщений в блогах о Credential Guard, некоторые из которых более точны, чем другие. В этом разделе мы представим обзор Credential Guard и объясним, почему злоумышленникам и защитникам важно его понимать.
Чтобы процитировать Microsoft о Credential Guard, Pass-the-Hash и Pass-The-Ticket:
Credential Guard в Защитнике Windows предотвращает эти атаки [Pass-the-Hash и Pass-The-Ticket], защищая хэши паролей NTLM, билеты на предоставление билетов Kerberos и учетные данные, хранящиеся приложениями в качестве учетных данных домена.
Процесс LSASS (служба подсистемы локального органа безопасности) отвечает за управление и применение политик безопасности в системе Windows. Он обрабатывает такие задачи, как аутентификация пользователей, предоставление доступа к ресурсам и применение политик безопасности.
Процесс LSASS хранит учетные данные в памяти, включая хешированные пароли. Credential Guard в Защитнике Windows предназначен для защиты этих учетных данных, изолируя их от памяти процесса LSASS. Мы рассмотрим реализацию этого более подробно в ближайшее время.
Почему мы заботимся об этом?
Злоумышленники часто пытаются выгрузить учетные данные из памяти процесса LSASS на скомпрометированном компьютере, чтобы перемещаться по сети в горизонтальном направлении, используя такие инструменты, как Mimikatz, которые могут извлекать различные учетные данные, включая пароли в открытом виде, хэши NTLM и билеты Kerberos.
При атаке Pass-the-Hash (PtH) злоумышленник может использовать скомпрометированный хэш NTLM для аутентификации в системе или службе, не зная фактического пароля. Это возможно, потому что хэши NTLM получаются из пароля пользователя и используются для аутентификации во многих протоколах.
Credential Guard защищает от этих типов атак, изолируя хэши NTLM (и билеты Kerberos) в памяти процесса LSASS, тем самым защищая от первоначальной компрометации хэша NTLM пользователя.
Теперь, если мы скомпрометируем систему с включенным Credential Guard и попытаемся извлечь учетные данные из памяти процесса LSASS с помощью Mimikatz, что мы увидим?
Как показано выше, мы не можем извлечь хэш NTLM из памяти LSASS и вместо этого получаем «Изолированные данные LSA: NtlmHash». Для сравнения, вот как будет выглядеть вывод в системе, не защищенной Credential Guard.
Затем этот скомпрометированный хэш NTLM можно использовать для аутентификации в системе или службе.
В IFCR мы заметили увеличение числа систем, защищенных Credential Guard, во время наших операций Red Team. Кроме того, начиная с Windows 11 Корпоративная версии 22H2 и Windows 11 для образовательных учреждений версии 22H2, в системах, совместимых с Credential Guard, он включен по умолчанию.
Как?
Credential Guard в Защитнике Windows использует безопасность на основе виртуализации (VBS) для изоляции секретов. VBS использует функции аппаратной виртуализации для создания безопасной области памяти, отдельной от обычной операционной системы.
Чтобы понять проблемы, с которыми сталкиваются злоумышленники при работе с Credential Guard, полезно представить обычную операционную систему, работающую внутри одной виртуальной машины (ВМ), и безопасные процессы, работающие внутри другой ВМ с отдельным ядром. Эти виртуальные машины управляются «гипервизором».
Даже если бы злоумышленники могли получить выполнение кода ядра в обычной операционной системе, им все равно нужно было бы покинуть виртуальную машину, атакуя гипервизор или защищенную виртуальную машину. Этот сценарий похож на то, что происходит с безопасностью на основе виртуализации.
Итак, как же работает Credential Guard? Когда Credential Guard включен, процесс под названием LSAIso (LSA Isolated) запускается внутри защищенной виртуальной машины. LSASS и LSAIso могут взаимодействовать через расширенные локальные вызовы процедур (ALPC).
Как работает Credential Guard в Защитнике Windows | Майкрософт учиться
Когда процессу LSASS нужно защитить секрет, он может вызвать LSAIso для его шифрования. Затем зашифрованный секрет возвращается в LSASS. В идеале только LSAIso должен иметь возможность расшифровать секрет. После защиты хэша NTLM процесс LSASS содержит только изолированный секрет (зашифрованный большой двоичный объект).
Как показано на картинке выше, процесс LSAIso имеет «поддержку NTLM». Когда процессу LSASS требуется выполнить операцию NTLM с зашифрованным секретом, он может вызывать различные методы в процессе LSAIso для выполнения операции. Стоит отметить, что LSAIso не имеет доступа к сети. Поэтому, несмотря на то, что LSAIso может выполнять операции NTLM, процесс LSASS по-прежнему отвечает за выполнение любых действий, которые выполняются до и после операции. Например, в то время как LSAIso может вычислять пару запрос/ответ NTLM, LSASS отвечает за получение и отправку пары.
Предыдущее состояние победы над Credential Guard
До сих пор единственные общеизвестные атаки на Credential Guard включали атаку на конвейер аутентификации LSASS до того, как секреты были защищены. Например, это может включать перехват функции в LSASS, чтобы при входе новой жертвы на скомпрометированный сервер ее учетные данные могли быть скомпрометированы до того, как они будут отправлены в LSAIso.
Новое состояние победы над Credential Guard
Хотя для этого требуется несколько дополнительных шагов, восстановить NTLM-хэш изолированного секрета NTLM все же можно. Другими словами, если нам удастся скомпрометировать систему и обнаружить зашифрованные учетные данные NTLM в памяти процесса LSASS, мы все равно сможем извлечь хэш NTLM.
Используя открытые функции процесса LSAIso вместе с зашифрованными учетными данными, мы можем выполнять необходимые операции, чтобы в конечном итоге получить хэш NTLM.
Восстановление хэша NTLM
В этом разделе мы продемонстрируем два метода получения хэша NTLM.
Во-первых, мы должны добиться выполнения кода в процессе LSASS, чтобы взаимодействовать с процессом LSAIso по установленному каналу связи ALPC.
Во-вторых, мы должны получить дамп памяти процесса LSASS, чтобы извлечь зашифрованные учетные данные. Для этого я изменил код Pypykatz, подробности также приведены в разделе «Технические подробности».
Для этого примера я создал учетную запись администратора домена с длинным случайным паролем, который соответствует хэшу NTLM 65A13AB2FAEB5B700DE1A938AE5621CA.
В этом сценарии мы получили дамп памяти процесса LSASS и извлекли зашифрованные учетные данные с помощью модифицированной версии Pypykatz, как показано ниже.
В следующих двух разделах мы покажем, как извлечь хэш NTLM 65A13AB2FAEB5B700DE1A938AE5621CA из «зашифрованного блоба» (изолированного секрета).
Я также создал инструмент под названием «PassTheChallenge», который вызывает методы LSAIso, загружая библиотеку в процесс LSASS. Этот инструмент будет доступен в этом сообщении в блоге, а технические подробности и необходимая информация будут представлены в разделе «Технические подробности».
PtCv1
Этот метод позволяет нам восстановить хэш NTLM за относительно короткое время.
Процесс LSAIso предоставляет метод с именем NtlmIumCalculateNtResponse, который позволяет нам вычислить ответ NTLMv1 для произвольного вызова сервера с использованием зашифрованных учетных данных.
Используя «дескриптор контекста», «информацию о прокси-сервере» и «зашифрованный большой двоичный объект» из дампа памяти, мы можем передать эти параметры в PassTheChallenge.exe с помощью команды nthash. По умолчанию инструмент использует статическую задачу 1122334455667788. Если все пойдет хорошо, он выдаст NTHASH. Несмотря на формат, это не хэш NTLM, а ответ NTLMv1.
Теперь самое интересное. С ответом NTLMv1 и статическим вызовом 1122334455667788 мы можем отправить его на crack.sh и взломать бесплатно. Прежде чем вы подумаете, что это требует часов взлома, просто продолжайте читать. Мы превращаем ответ NTLMv1 не в пароль, а в хэш NTLM.
Если вам нужно напомнить, как генерируется ответ NTLMv1, вы можете обратиться к следующему коду:
Ответ NTLMv1 состоит из трех 8-байтовых фрагментов. Каждый фрагмент создается путем шифрования запроса с помощью DES и 7-байтового фрагмента ключа. Вы могли заметить, что три 7-байтовых фрагмента ключа в сумме составляют 21 байт, что больше, чем 16-байтовый хэш NTLM. Чтобы решить эту проблему, последний фрагмент ключа состоит из первых 2 байтов хэша NTLM, за которыми следуют нулевые байты.
Подводя итог, нам нужно взломать три шифрования DES, используя три разных 7-байтовых ключа, один из которых имеет только 2 неизвестных байта, чтобы восстановить хэш NTLM. Этот процесс намного проще, чем взлом одного 16-байтового ключа. К счастью, Crack.sh создал одну из самых больших общедоступных Радужных таблиц для всего пространства ключей DES. Они утверждают, что могут достичь среднего времени взлома 25 секунд и уровня успеха 99,5%. Если система не может взломать ключ немедленно, она передаст работу установке грубой силы, которая должна найти ключ в течение нескольких дней.
Давайте посмотрим на это в действии. Во-первых, мы можем бесплатно отправить формат NTHASH на Crack.sh.
Менее чем через минуту я получил электронное письмо от Crack.sh, в котором говорилось, что хэш NTLM был успешно восстановлен за 30 секунд: 65A13AB2FAEB5B700DE1A938AE5621CA.
Хотя это не реклама Crack.sh, это показывает, насколько просто взломать хэш NTLMv1 обратно в хэш NTLM.
Этот конкретный хэш ранее не отправлялся в crack.sh, а использование длинного случайного пароля указывает на то, что взлом — это не вопрос сложности пароля, а скорее слабость, присущая хэшам NTLMv1.
PtCv2
Теперь предположим, что опция NTLMv1 по какой-то причине недоступна — возможно, Microsoft решила ее удалить. Другой интересный вариант — вычислить ответ NTLMv2 с помощью метода LSAIso NtlmIumLm20GetNtlm3ChallengeResponse.
Чтобы продемонстрировать это, я модифицировал функцию CompetResponseNTLMv2 Impacket для интерактивной печати запроса и запроса ответа. Эта единственная модификация будет работать со всеми сценариями и инструментами, использующими Impacket для аутентификации, такими как Certipy.
Когда пароль установлен на CHALLENGE, функция calculateResponseNTLMv2 в Impacket вместо этого распечатает вызов и запросит ответ. Давайте посмотрим на это в действии. Для первой демонстрации мы будем использовать psexec.py от Impacket, чтобы получить выполнение кода на контроллере домена DC.
Мы будем запускать скрипт как обычно, но чтобы моя модификация вступила в силу, нам нужно указать пароль CHALLENGE. Затем Impacket распечатает вызов в пользовательском формате и будет ждать ответа, как показано ниже.
Затем мы можем использовать PassTheChallenge.exe, как и раньше, но на этот раз мы используем вызов команды и добавляем вызов к ранее использованным параметрам.
Затем мы можем использовать PassTheChallenge.exe, как и раньше, но на этот раз мы используем вызов команды и добавляем вызов к ранее использованным параметрам.
Затем инструмент выведет ответ, который мы передадим psexec.py.
Как показано выше, psexec.py выполняет множественную аутентификацию, поэтому нам нужно будет повторить эти шаги несколько раз. Однако в конечном итоге мы получаем доступ к оболочке и выполняем код.
Хотя это не позволило нам восстановить хэш NTLM, это повышает вероятность других способов сделать это с помощью нашего примитива NTLMv2.
Теперь давайте воспользуемся нашим примитивом NTLMv2 и Certipy, чтобы запросить сертификат для пользователя-жертвы «Администратор» через службы сертификации Active Directory.
Как упоминалось ранее, измененная функция Impacket даже заставит Certipy распечатать вызов и запросить ответ, если пароль установлен на CHALLENGE. Как показано выше, запрос сертификата был выполнен успешно, и выданный сертификат вместе с закрытым ключом был сохранен в файле administrator.pfx.
Наконец, мы можем использовать сертификат и Certipy для аутентификации в качестве администратора и получения хэша NTLM, как показано ниже.
Стоит отметить, что для запроса сертификатов и аутентификации с их помощью в среде необходимо установить AD CS. После включения AD CS любой пользователь может быть выбран по умолчанию.
Дополнительное примечание
Основываясь на моем собственном тестировании, кажется, что зашифрованные учетные данные могут использоваться при перезагрузке, вопреки некоторой существующей информации. Похоже, что LSAIso не использует загрузочный секрет для шифрования учетных данных. Таким образом, можно вернуться к скомпрометированному компьютеру позднее для выполнения этих операций. Единственное, что нужно иметь в виду, это то, что «Context Handle» и «Proxy Info» — это адреса памяти, извлеченные из дампа памяти, и их необходимо пересчитать с помощью нового дампа памяти или аналогичных методов. Адреса «Context Handle» и «Proxy Info» не привязаны к определенному набору учетных данных, и все зашифрованные учетные данные NTLM будут иметь один и тот же адрес «Context Handle» и «Proxy Info» в дампе памяти.
Заключение
В этой статье мы сосредоточились именно на NTLM. Однако стоит учитывать, что Kerberos также может предлагать интересные функции, которые могли бы помочь нам в достижении наших целей.
