GitHub - EvanMcBroom/lsa-whisperer: Tools for interacting with authentication packages using their individual message protocols
Tools for interacting with authentication packages using their individual message protocols - EvanMcBroom/lsa-whisperergithub.com
Спасибо SpectreOps за поддержку этого исследования, Elad за помощь в составлении этого блога, а также Саре , Дэниелу и Адаму за корректуру и редактирование! Кросспостинг на GitHub .
Далее следует кульминация двух лет исследований при финансовой поддержке SpectreOps и вкладе многих моих коллег.
Особая благодарность выражается Эладу , Ли , Уиллу , Дэниелу и Каю . Элад, Ли и Уилл внесли в проект несколько идей, которые описаны здесь, и каждый из них потратил несколько дней на тестирование инструмента. Дэниел ответил на все мои неизбежные вопросы об AzureAD (упс, теперь Entra ID! Когда я начинал, это был AzureAD
) и OAuth 2.0. Кай помог как исследовать пакет аутентификации CloudAP (AP) LSA, так и добавить в этот инструмент поддержку пакетов Kerberos. Каждому спасибо!Проект LSA Whisperer фокусируется на взаимодействии с «Пакетами аутентификации» с использованием их индивидуальных протоколов сообщений. Точки доступа представляют собой библиотеки DLL поставщика поддержки безопасности (SSP), которые LSA загружает для реализации определенной логики аутентификации (например, локальных входов в систему). SSP также может называться пакетом безопасности (SP), если он реализует протокол безопасности (например, NTLM), но любое использование слова «пакет» в этом блоге будет относиться только к функциям AP SSP.
Дневник разработчика
Проект, о котором я собираюсь рассказать, был на пути к завершению, поэтому позвольте мне объяснить, как все началось.Лето, 2022 г.
SpectreOps проводит серию внутренних технических переговоров, представленных коллегами и ведущихся Коди Томасом . Во время одного из таких выступлений Ли Чаголла-Кристенсен продемонстрировал свою работу по отслеживанию того, как браузеры запрашивают файлы cookie SSO из пакета LSA под названием Cloudap. Он был заинтересован в том, чтобы сделать тот же запрос программно, но у него еще не было возможности выяснить, как это сделать.Идея напрямую запросить файл cookie SSO была заманчивой, поэтому я предложил помощь. Во время перерывов во время преподавания курса SpectreOps Tradecraft Analysis нам удалось добиться некоторого взаимодействия с CloudAP через LsaCallAuthenticationPackageWin32 API. Мы выяснили, как запросить Cloudap для обновления основного токена обновления (PRT) для пользователя, но еще не выяснили, как восстановить файл cookie SSO пользователя. Тем не менее успешное взаимодействие было захватывающим. Аудит Cloudap в Ghidra также позволил нам наткнуться на множество функций, известных как «вызовы», которые мы могли использовать для взаимодействия с пакетом другими способами.
После этого я начал работать над утилитой интерфейса командной строки (CLI) для взаимодействия с вызовами Cloudap, которые нам показались интересными. В то время не рассматривался потенциальный вариант использования инструмента в наступательных целях. Меня просто интересовало, какие вызовы предлагает Cloudap, и возможность самому вызывать полезные из них. Дэниел Хейнсен оказал мне огромную помощь во время этого процесса, ответив на мои многочисленные вопросы, касающиеся Entra ID и OAuth 2.0.
Осень, 2022 г.
Вскоре после этого Элад Шамир вернулся в SpectOps. Он слышал, что я работаю с LSA, поэтому мы поговорили о потоке аутентификации, который он исследовал с помощью пакета Kerberos. В частности, когда пакет Kerberos восстанавливает хэш NT OWF из расшифрованного PAC, Kerberos сохранит хэш в сеансе входа, управляемом пакетом msv1_0, используя внутренний CacheLogonвызов msv1_0. Ему было интересно посмотреть, сможем ли мы CacheLogonсами выполнить тот же вызов Pass-the-Hash (PtH) с помощью инструментов на хосте. Единственная альтернатива локальным инструментам — использовать Mimikatz или аналогичный инструмент для изменения памяти LSASS.Идея была фантастической, и я начал одитировать CacheLogon, чтобы увидеть, как сделать колл. Мы обнаружили, что такой подход действительно возможен, но в конечном итоге мы столкнулись с препятствием, заключающимся в том, что msv1_0 ограничивает CacheLogonвызов только клиентами, которые сами являются процессом LSASS. Однако мы заметили несколько других вызовов msv1_0, которые показались мне интригующими, и я начал работать над эквивалентной CLI-утилитой msv1_0 для взаимодействия с интересующими нас вызовами.
За это время мы обнаружили тот факт, что GetCredentialKeyвызов msv1_0 возвращает подмножество основных учетных данных для управляемого сеанса входа в систему msv1_0. Это производные от открытого текстового пароля пользователя (например, NT-хэша), который сохраняет msv1_0, чтобы впоследствии выполнять различные действия для пользователя. В то время мы не до конца понимали значение этих учетных данных, но знали, что они каким-то образом использовались с API защиты данных (DPAPI) . Мы также не смогли найти никого, кто задокументировал бы этот же вызов, что было удивительно и побудило нас продолжать работу и исследовать другие пакеты.
ПРИМЕЧАНИЕ. «Ключи учетных данных» — это термин Microsoft, обозначающий хеш односторонней функции (OWF) или безопасный хэш учетных данных пароля пользователя. Соответствующий ключ может использоваться для расшифровки главного ключа DPAPI. Уилл Шредер добавил в SharpDPAPI поддержку кредитных ключей , чтобы использовать этот вывод в качестве оружия. Спасибо, Уилл!
Примерно в это же время Ли пошутил:
«Почему бы вам не сделать утилиту CLI для Kerberos? Собственно, почему бы не сделать один для всех пакетов?»
Идея не показалась слишком надуманной для реализации, поэтому утилиты были объединены и началась дополнительная работа по выполнению вызовов Kerberos. Элад придумал имя, которое всем понравилось, и так родился LSA Whisperer.
Весна, 2023 г.
Вся компания собралась на наш ежегодный ретрит в начале 2023 года. К этому времени я поменял местами названия всех вызовов для всех пакетов, которые в настоящее время поставляются с Windows. Я определил, что Cloudap загружает плагины, что эти плагины также поддерживают вызовы, и поменял местами имена каждого из этих вызовов. Я также перевернул диспетчер пакетов безопасности (SPM), который в целом управляет пакетами LSA, определил, что он тоже поддерживает вызовы, и определил их имена.Полный список доступных вызовов был ошеломляющим. Во время ретрита я поговорил с Эладом, Ли и Уиллом, чтобы распределить его по приоритетам и составить меньший список звонков, о которых мы хотели узнать больше. Примерно в это же время к проекту присоединился Кай Хуан, чтобы помогать исследовать вызовы в более крупных пакетах, а именно Cloudap и Kerberos. Список приоритетов и дополнительная помощь сделали проект намного более управляемым.
Осень, 2023 г.
В четвертом квартале 2023 года SpectreOps профинансировала мою работу в течение всего квартала над разработкой LSA Whisperer. Хотя SpectreOps обычно предоставляет сотрудникам рабочее время и другие ресурсы для их личных проектов, я понимаю, что это необычно для отрасли, и я благодарен SpectreOps за вашу поддержку.К началу четвертого квартала проект был хорошо организован. Инструмент уже мог совершать множество вызовов к нескольким пакетам, все исследования документировались в вики проекта, а план работы и основные этапы на квартал были изложены в официальном плане исследований. За это время прогресс ускорился, и инструмент получил частичную или полную поддержку 12 вызовов CloudAP, 10 вызовов плагинов CloudAP AzureAD (Microsoft использует предыдущее имя Entra ID для плагина), 21 вызов Kerberos, 1 вызов lifesp, 1 вызов msv1_0 (многие из них были реализовано ранее), 4 вызова negoexts, 2 вызова pku2u, 2 вызова schannel и 2 вызова SPM. Ли и Уилл любезно провели много дней в конце квартала, тестируя каждый из этих новых вызовов, чтобы подтвердить или опровергнуть наши идеи относительно их потенциальных вариантов использования.
За это время также были выявлены три ошибки, о которых ответственно сообщили в Центр реагирования безопасности Microsoft (MSRC). Две из них были проблемами разыменования произвольных указателей в процессе LSASS для NT 6.4 и выше. Для этого требуются SeTcbPrivilegeпривилегии, которые снижают вероятность злоупотреблений, и MSRC в конечном итоге сочла, что и то, и другое предусмотрено намеренно. Третьим была утечка памяти в LSASS, которую мог вызвать любой вошедший в систему пользователь, по крайней мере, для NT 5.1 и выше. Третьей ошибке был присвоен номер CVE-2024–26209 , она была исправлена 9 апреля 2024 г. и теперь доступна всем конечным пользователям через обновления безопасности. MSRC быстро ответила, и с ней было приятно работать по всем этим вопросам, что я ценю. Для тех, кто заинтересован, описание и подтверждение концепции (POC) для каждой из этих проблем можно найти в проекте GitHub, где я делюсь различными POC, автором которых являюсь .
Весна, 2024 г.
У меня была возможность представить LSA Whisperer на ежегодной конференции SpectreOps (SOCON) в Арлингтоне, штат Вирджиния. Посещаемость была очень большой, а отзывы после выступления заставили нас почувствовать, что все прошло хорошо! Спасибо всем, кто смог присутствовать на беседе. Ваше присутствие и интерес сделали презентацию радостью!Я хотел бы поблагодарить моих коллег за всю поддержку до и во время презентации. Без этого разговор не прошел бы так гладко. Наконец, презентация представляла собой сочетание моих собственных идей и идей многих моих коллег, включая Элада, Ли и Уилла. Для меня было честью представить кульминацию работы каждого, спасибо!
Теперь мы подходим к настоящему: апрель 2024 года. Выпущено обновление безопасности, и вместе с ним мы можем выпустить наши инструменты.
Обзор проекта
Если вы хотите, вы можете пропустить это руководство и перейти непосредственно на главную страницу проекта . На главной странице описано, как собрать наш инструментарий — LSA Whisperer, а в вики проекта описано, как использовать этот инструмент , как он работает и какие функции пакета аутентификации он поддерживает. Вики большая, поэтому здесь мы даем более подробное введение в эти же темы.Поставщики поддержки безопасности
Как описано во введении к блогу, SSP — это библиотеки DLL, загружаемые LSA, которые реализуют конкретную логику аутентификации (например, локальный вход в систему) или протокол безопасности (например, NTLM). В таблице ниже представлена сводная информация о SSP, выпущенных Microsoft за прошедшие годы. LSA Whisperer поддерживает взаимодействие с подмножеством показанных SSP, помеченных как пакет аутентификации (AP). Многие из этих SSP реализуют протокол безопасности и, как таковые, могут также называться пакетом безопасности (SP), но для целей этого блога мы сосредоточимся только на функциональности AP этих SSP.Пакетные вызовы
Каждая точка доступа имеет возможность поддерживать получение, обработку и ответ на произвольные запросы от другого программного обеспечения. Эти запросы называются «вызовами пакетов». Вызов пакета официально поддерживается как для пользовательского режима, так и для программного обеспечения драйвера устройства посредством использования API LsaCallAuthenticationPackage.Помимо wdigest, все точки доступа, которые в настоящее время поставляются с Windows, поддерживают обработку пакетных вызовов. Точки доступа используют эту функцию для поддержки пользовательских функций, которые иначе недоступны через стандартную таблицу функций SSP, которую должна реализовать точка доступа. В течение многих лет красные команды и злоумышленники злоупотребляли некоторыми из этих пользовательских функций (например, для восстановления билетов Kerberos).
Несмотря на то, что некоторые из этих вызовов пакетов хорошо известны, мы заметили, что подавляющее большинство из них не задокументировано. Наш интерес заключается в выявлении всех пользовательских функций, которые поддерживает каждая точка доступа, путем выполнения пакетных вызовов, поскольку мы предположили, что во время наступательной операции многие из них могут стать объектом злоупотреблений. Если это вас заинтересовало, читайте дальше!
Техники
В ходе нашего исследования мы задокументировали вызовы пакетов, доступные для всех точек доступа, которые в настоящее время поставляются с Windows. Мы сузили их до подмножества, которое мы считаем полезным, и реализовали поддержку большей части этого подмножества в LSA Whisperer.Вот основные моменты пакетных вызовов, которые могут быть выполнены на данном хосте. Все вызовы пакетов, не упомянутые в этих обзорах, можно найти в вики проекта. Если вас интересует вызов пакета, который не реализован, или вы видите область вики, которую можно улучшить, отправьте сообщение о проблеме на GitHub или рассмотрите возможность создания запроса на включение (PR) для проекта.
Керберос
Мы начнем с пакета Kerberos, поскольку его вызовы пакетов более известны в отрасли. Первое, на что следует обратить внимание, как и во многих точках доступа, — это возможность использовать вызовы пакетов для сбора данных перечисления хостов. С помощью пакета Kerberos вы можете показать текущие кэшированные билеты Kerberos, расширенные политики домена (например, «Включена ли FAST Armouring?») и то, как Kerberos настроен на этом хосте.Наибольший интерес для людей, вероятно, представляет способность пакета восстанавливать билеты Kerberos для активных сеансов входа в систему или, возможно, его способность кэшировать данный билет Kerberos для использования на хосте: метод, известный как «Передача билета» (PTT) . Менее важным, но все же представляющим интерес для наступательных операций, является способность пакета очищать билеты, привязывать доменное имя и закреплять доменное имя.
Очистка билета полезна, если вы применили метод PTT, использованный вами билет больше не является работоспособным, и вам необходимо удалить его из кэша. Хотя большинство инструментов Red Team поддерживают только очистку всех заявок в вашем кеше, мы обнаружили, что пакет позволяет вам выборочно очищать заявки, что потенциально может значительно улучшить качество жизни этих инструментов Red Team. Привязка доменного имени может помочь в реализации метода «Золотого билета», как это определил Марсьяль Пюигренье, в то время как Джеймс Форшоу и Ник Ландерс показали, что привязка доменного имени допускает логические злоупотребления Kerberos. В их случае они продемонстрировали локальное повышение привилегий (LPE), SYSTEMно людям следует искать и другие потенциальные злоупотребления закреплением домена
Все вызовы пакетов Kerberos документированы на странице Kerberos вики . Соответствующие требования к методам, представленным в этом разделе, включают:
- AddBindingCacheEntry
- PinKdc / UnpinAllKdc
- PrintCloudKerberosDebug
- Query/Purge BindingCache
- Query/Purge KdcProxyCache
- Query/Purge TicketCache[Ex|Ex2|Ex3]
- QueryDomainExtendedPolicies
- QueryS4U2ProxyCache
- Retrieve[Encoded]Ticket
- SubmitTicket
Облачная точка доступа
Далее идет Cloudap, который управляет входом в систему с помощью Entra ID, AD FS и учетных записей Microsoft. Как и в случае с Kerberos, Cloudap предлагает функциональные возможности для сбора базовой информации о хосте и сеансах входа в систему, управляемых Cloudap, например, если частичный TGT, также известный как «TGT из облака в локальную среду», присутствует в локальном кеше.Хотя эта информация полезна для устранения проблем со входом в систему, более интересными являются отдельные плагины, которые загружаются в Cloudap. Cloudap в настоящее время имеет два плагина. Первый, известный как AzureAD или AAD, управляет входами в Entra ID и AD FS. Второй, известный как Windows Live ID или MSA, управляет входом в учетную запись Microsoft.
Главный интерес этих плагинов заключается в том, что их можно использовать для запроса файла cookie единого входа (SSO) для аутентификации у поставщика удостоверений (IDP) в качестве целевого пользователя. Плагин AAD позволяет вам запрашивать файл cookie единого входа для Entra, AD FS и файл cookie единого входа для самого вашего текущего устройства. Хотя мы еще не отправили успешный запрос в MSA, мы уверены, что сможем запросить у него файл cookie единого входа для учетных записей Microsoft, поскольку мы успешно сделали это с устаревшей точкой доступа lifesp, на которой он основан.
Менее непосредственное влияние, но все же важное, оказывают дополнительные параметры перечисления хостов, которые специально предлагает подключаемый модуль AAD. Инструменты Red Team обычно собирают облачную информацию с помощью NetGetAadJoinInformationAPI Win32, но этой функции явно не хватает информации SSO, которую можно получить из других инструментов CLI, таких как dsregcmd. Недостающую информацию о едином входе из этого API можно собрать с помощью подключаемого модуля AAD.
Все вызовы Cloudap и плагина AAD документированы на странице Cloudap вики . Соответствующие требования к методам, представленным в этом разделе, включают:
- GetAuthenticatingProvider
- GetDpApiCredKeyDecryptStatus
- GetPwdExpiryInfo
- GetUnlockKeyType
- IsCloudToOnPremTgtPresentInCache
- ААД ->CreateSSOCookie
- ААД ->CreateDeviceSSOCookie
- AAD -> CreateEnterpriseSSOCookie(Предприятие относится к AD FS)
- ААД ->DeviceValidityCheck
Пакет проверки подлинности Microsoft версии 1.0
Последний пакет, который мы рассмотрим в этом посте, — это msv1_0, но другие пакеты описаны в вики ! Основная цель Msv1_0 как точки доступа — облегчить вход в систему на локальном компьютере. Будучи самой старой из точек доступа, она взяла на себя другие обязанности, такие как управление учетными данными DPAPI, отправку запросов Netlogon и создание данных для сообщений NTLM, чтобы поддерживать свою вторую роль в качестве пакета безопасности для NTLM.Из-за этих дополнительных обязанностей msv1_0 оказался столь же плодотворным в наших выводах, как и Cloudap в восстановлении учетных данных. Первое, что мы определили, это то, что msv1_0 позволяет восстановить «ключ учетных данных» DPAPI вошедшего в систему пользователя. Термин «ключ учетных данных» описан в вики , и мы планируем рассказать о нем подробнее в будущем блоге, но если вы восстановите ключ учетных данных пользователя, вы сможете расшифровать его файл главного ключа DPAPI. Этот процесс работает, даже если включен Credential Guard.
Следующее, что мы определили, это то, что msv1_0 позволяет генерировать ответ NTLMv1 с выбранным значением запроса сервера. Это работает независимо от того, отключен ли NTLMv1 с помощью LmCompatibilityLevelключа в реестре (как это необходимо для подобных атак, таких как Internal Monologue ), но мы считаем, что это не сработает, если включен Credential Guard. Важность возможности получить ответ NTLMv1, особенно при выбранном вызове сервера, заключается в том, что взломать пригодный для использования NT-хеш для передачи методов хеширования (PtH) и других профессиональных приемов тривиально. Некоторые онлайн-ресурсы, такие как Crack.sh, даже бесплатно взломают эти ответы, если ответ содержит конкретную проблему с сервером, которую мы можем гарантировать. Процесс взлома Crack.sh также будет мгновенным, поскольку для этих бесплатных запросов используется радужная таблица.
Все вызовы плагина msv1_0 документированы на странице msv1_0 вики . Соответствующие требования к методам, представленным в этом разделе, включают:
- GetCredentialKey
- GetStrongCredentialKey
- Lm20GetChallengeResponse
Тупики
Исследователи безопасности часто празднуют свои успехи и скрывают неудачи. Я подумал, что для разнообразия было бы неплохо поделиться тем, что не получилось так, как мы надеялись. Большинство исследовательских усилий не увенчались успехом, и если мы тоже начнем ими делиться, возможно, это побудит больше людей попробовать, и, возможно, другие смогут опираться на нашу незавершенную работу и идеи, чтобы преодолеть препятствия, которые мешали нашему прогрессу.Передача учетных данных как альтернатива краже токенов
В нескольких пакетах есть TransferCredsвызов, который, как следует из названия, либо передает, либо дублирует учетные данные из одного сеанса входа, управляемого пакетом, в другой. Наша идея этих вызовов заключалась в том, чтобы использовать их как новую альтернативную технику кражи токенов доступа .Кража токенов была введена еще в 2008 году Люком Дженнингсом с выпуском Incognito . Это был революционный метод, который позволил злоумышленникам использовать учетные данные других вошедших в систему пользователей, не нацеливаясь на LSASS. В настоящее время многие EDR могут обнаружить эту технику и ее варианты, но, что более важно, Windows удалит все учетные данные, которые больше не используются процессом или потоком после выхода пользователя из системы, ограничивая окно возможностей для этой атаки. В 2022 году Уилл Шредер выпустил Koh , инструмент, который может заставить Windows в некоторых обстоятельствах сохранять учетные данные после выхода пользователя из системы, чтобы расширить это окно возможностей.
Мы полагали, что этот TransferCredsпризыв имел аналогичный потенциал для злоупотреблений. Наша идея заключалась в том, чтобы злоумышленник либо создал новый сеанс входа в систему, либо использовал существующий «жертвенный» сеанс входа в систему, который он контролировал, а затем перенес учетные данные сеанса входа в систему для целевого пользователя в сеанс, контролируемый злоумышленником. Это позволит злоумышленнику использовать учетные данные пользователя после того, как он вышел из системы, не создавая дублирования токенов и действий по выдаче себя за другое лицо, которые могут рассматриваться как подозрительные.
Этот вызов доступен в точках доступа msv1_0, Kerberos, Cloudap и в согласовании. Пакет msv1_0 предотвращает выполнение вызова любым процессом, кроме самого LSASS. Поддержка этого выходит за рамки проекта, потому что если вы можете выполнить код внутри LSASS для выполнения этого вызова, то у вас уже есть возможность напрямую восстанавливать учетные данные из памяти LSASS, и этот вызов становится ненужным.
Пакет Kerberos позволяет другим процессам выполнять этот вызов, но он удалит все билеты Kerberos и ключи Kerberos из исходного сеанса входа в систему. Это не должно нарушить работу пользователя при доступе к службам, использующим Negotiate для аутентификации, поскольку его сеанс входа в систему вернется к использованию NTLM, но это нарушит его способность использовать службы, которые используют только Kerberos для аутентификации. Как только вы перенесете билеты на другой сеанс, вы сможете перенести их обратно. Таким образом, он по-прежнему может представлять ценность для злоумышленников, позволяя им временно передавать билеты в контролируемый сеанс входа в систему для использования, возможно, в обход любой кражи токенов, сброса билетов или торговой телеметрии PTT, которые обычно происходят при краже билетов Kerberos пользователя. Если у вас есть другие идеи о том, как можно использовать этот призыв, мы будем рады их услышать!
У нас не было времени исследовать поведение реализации Cloudap, но мы считаем, что она будет иметь тот же эффект, что и пакет Kerberos. Наконец, реализация пакета согласования просто перенаправит TransferCredsвызов тому пакету, который использовался для согласованного сеанса входа в систему, что делает ранее упомянутые проблемы также всеми проблемами и для пакета согласования.
Передача хеша
NTLM — это встроенный протокол проверки подлинности «запрос-ответ» в Windows. В протоколе клиент доказывает наличие пароля, используя его производную — NT-хэш — для шифрования или генерации HMAC-запроса, заданного сервером, к которому он пытается подключиться. Использование NT-хеша в качестве ключа подвергает поток аутентификации атакам Pass-the-Hash (PtH), в которых злоумышленник может создать действительный ответ на запрос сервера, зная NT-хеш пользователя, но не зная его открытого пароля.За исключением Mimikatz, все инструменты, реализующие атаку PtH, реализуют NTLM-клиент, позволяющий генерировать ответы клиента с использованием NT-хеша вместо пароля пользователя. Mimikatz предлагает единственное альтернативное решение. Подход Mimikatz состоит в том, чтобы создать новый сеанс входа в систему на хосте Windows, определить местоположение NT-хеша этого сеанса в памяти LSASS, а затем перезаписать его указанным NT-хешем. Это заставляет любой процесс, использующий этот новый сеанс, использовать указанный NT-хеш при аутентификации на другом хосте с использованием NTLM. Mimikatz использует этот подход, поскольку не существует API-интерфейсов Windows, которые позволяли бы создавать сеанс входа в систему с использованием указанного NT-хэша. Такой подход может сделать LSASS нестабильным, поскольку он изменяет свою память, но является единственным целевым вариантом, когда сетевой инструмент не может быть проксирован.
Пакет msv1_0 предлагает CacheLogonвызов, который позволяет пользователю кэшировать указанный NT-хэш в активный сеанс входа в систему. Если сеанс входа в систему имеет кэшированный NT-хэш, он будет использоваться для аутентификации NTLM вместо фактического NT-хеша для учетной записи пользователя сеанса. Например, пакет Kerberos использует этот вызов в сценариях аутентификации без пароля. В этих сценариях, таких как вход в систему со смарт-картой или Windows Hello для бизнеса, будет использоваться схема проверки подлинности PKINIT, и контроллер домена (DC) отправит зашифрованную копию хэша NT пользователя в пакет Kerberos. Пакет Kerberos расшифрует NT-хэш пользователя, а затем воспользуется CacheLogonвызовом msv1_0, чтобы сохранить его для использования во вновь созданном сеансе входа в систему.
Мы хотели использовать этот CacheLogonвызов так же, как пакет Kerberos, чтобы сеанс входа в систему использовал известный хэш NT для аутентификации NTLM. Это должно обеспечить более стабильное решение, чем Mimikatz, для проведения PtH-атаки с использованием локальных или непрокси-инструментов, поскольку оно не требует перезаписи памяти LSASS. Существуют также дополнительные вызовы, которые вы можете объединить с CacheLogon, например CacheLookup, который может проверять текущий кэш msv1_0 для сеанса входа в систему, и ClearCachedCredentials, который вы можете использовать для удаления кэшированного хэша NT для сеанса входа в систему, когда вы закончите его использовать. К сожалению, как и TransferCredsвызов, msv1_0 позволяет CacheLogonвыполнять вызов только из самого процесса LSASS. Мы по-прежнему заинтересованы в поддержке этих функций для хостов, на которых LSASS не работает как PPL, например, управляемая пользователем виртуальная машина, которая подключена к целевой сети для оценки красной командой, но мы еще не реализовали их.
Обход проверок «только LSA» с помощью сквозных вызовов
На данный момент мы упомянули три вызова, которые могут быть выполнены только самим процессом LSASS; а именно CacheLogon, CacheLookupи TransferCredвызывает msv1_0. При выполнении любого из этих вызовов они проверяют, равна ли информация для запроса клиента нулю, что происходит только в том случае, если клиент сам является LSASS, и, если информация не равна нулю, возвращаются с кодом ошибки «доступ запрещен». »Мы можем реализовать решение, когда LSASS не работает как PPL, внедрив в LSASS код, который будет выполнять эти вызовы изнутри процесса, но мы хотели знать, существует ли альтернативное решение, не требующее внедрения кода. Действительно, почти было!
В нашем исследовании мы рассмотрели вызов пакета msv1_0 с именем GenericPassthrough. Вызов GenericPassthroughпринимает произвольный запрос точки доступа и отправляет его с помощью Netlogon на контроллер домена для обработки. Пакет Kerberos, например, поддерживает VerifyPacвызов, и хосты, присоединенные к домену, будут отправлять VerifyPacзапросы на контроллер домена, используя GenericPassthroughвызов, чтобы контроллер домена проверил информацию PAC билета Kerberos.
Мы заметили интересную вещь: когда хост не присоединен к домену, msv1_0 будет повторно отправлять любой запрос AP, который он получает, обратно GenericPassthroughсамому локальному экземпляру LSA. Это сделано для поддержки определенных действий рабочей группы, но важно то, что msv1_0 будет рассматривать окончательный перевыпущенный запрос AP как исходящий из процесса LSASS. Мы также считаем, что msv1_0 можно обмануть, заставив его поверить в то, что хост не присоединен к домену, чтобы повторно отправить нам запрос AP, временно остановив службу входа в сеть и отключив определенное именованное событие, которое устанавливается при запуске службы.
К сожалению, мы обнаружили, что даже если мы реализовали код, позволяющий обманным путем заставить msv1_0 повторно выдать запрос AP, чтобы мы могли обойти проверку «только LSA», которую выполняют некоторые вызовы (например, msv1_0 CacheLogon), мы обнаружили, что окончательный запрос будет считаться « запрос на транзит». Точки доступа обычно ограничивают сквозные запросы от клиентов лишь небольшим подмножеством полного списка запросов AP, которые обычно может сделать клиент. Например, Kerberos разрешает только VerifyPacсквозной запрос, а msv1_0 разрешает запрос только SubAuthдля реализации концепции «пакета дополнительной аутентификации».
Ключевой вывод заключается в том, что, хотя возможно обманом заставить msv1_0 повторно отправить запрос AP для обхода проверки «только LSA», мы не сможем использовать этот подход для выполнения любого из интересующих нас вызовов: msv1_0's CacheLogon, CacheLookup, и TransferCredзвонит. Нам по-прежнему нравится поддерживать эти вызовы, но в настоящее время мы планируем реализовать решение, требующее для этого внедрения кода в LSASS.
Сброс NT-хэшей
Вызовы GetCredentialKeyи GetStrongCredentialKeyдля msv1_0 возвращают «ключ учетных данных» DPAPI для сеанса входа в систему. Как упоминалось в разделе техники msv1_0, мы планируем подробнее рассказать о ключах учетных данных в будущем блоге. Однако важно знать, что в некоторых не очень распространенных ситуациях ключ учетной записи на самом деле является просто NT-хешем пользователя!Когда мы впервые реализовали эти вызовы, мы фактически столкнулись с этой ситуацией довольно надежно и продолжали получать NT-хеш для нашего целевого пользователя. Мы понятия не имели, что такое ключ учетной записи, имеет ли он какое-либо отношение к DPAPI и что эти вызовы редко передают NT-хеш пользователя. Вместо этого мы подумали, что нашли идеальный способ выгрузить учетные данные из LSASS, и были в восторге.
Наше первоначальное понимание оказалось слишком хорошим, чтобы быть правдой, но по мере дальнейшего изучения эти звонки стали для нас интересными по-другому. Вскоре мы обнаружили, что вместо этого эти вызовы создают учетный ключ DPAPI, который в этих не столь частых крайних случаях оказывается хэшем NT, но во всех случаях будет ключевым материалом, который вы можете использовать для расшифровки файла главного ключа пользователя DPAPI. . Если этот ключ также является хэшем NT, одним из требований для этого крайнего случая является то, что учетная запись является локальной. Это делает его восстановление менее важным из-за множества альтернативных методов извлечения того же значения из локального SAM.
В любом случае, мы решили считать восстановление учетного ключа DPAPI победой, а позже, почти случайно, мы определили способность msv1_0 генерировать ответы NTLMv1 с выбранным значением запроса сервера, что, как описано в разделе о профессиональном мастерстве msv1_0, тривиально. можно взломать до NT-хеша для пользователя. Итак, приложив больше усилий, мы в конечном итоге достигли своей цели, но это оказалось не так просто, как мы думали изначально.
Сброс таблиц ключей Kerberos
В файле keytab хранятся ключи аутентификации Kerberos для учетной записи, и они обычно используются для автоматизации аутентификации пользователя, не требуя взаимодействия с пользователем. Когда мы исследовали пакет Kerberos, мы заметили, что он поддерживает вызов RetrieveKeytab.Мы надеялись, что сможем использовать этот вызов для создания файла keytab с ключами аутентификации Kerberos для учетной записи, аналогичной sekurlsa::ekeysкоманде Mimikatz. Однако этот вызов требует, чтобы вызывающий абонент предоставил пароль. Результирующий файл keytab будет заполнен ключами, полученными из этого пароля, а не пароля для существующей учетной записи пользователя, что делает вызов не слишком ценным для злоумышленника с нашей точки зрения.
Решение проблемы двойного прыжка
Когда пользователь входит в систему на удаленном хосте (первый переход), а затем с этого удаленного хоста пытается войти на еще один удаленный хост (второй переход), аутентификация на втором переходе обычно завершается неудачно. Это проблема двойного прыжка.Проблема двойного перехода возникает из-за того, как работает аутентификация в средах Windows, и влияет не только на наступательные операции, но и на законное системное администрирование. Сеанс входа в систему на первом удаленном хосте (первый переход) — это «вход в сеть», установленный с использованием Kerberos или NTLM, а не с использованием многократно используемых учетных данных, таких как пароль или данные смарт-карты. Таким образом, хост первого прыжка не может аутентифицировать пользователя на втором прыжке. Первый переход просто не имеет многократно используемого учетного материала для выполнения этого действия.
Существует несколько законных решений этой проблемы, включая делегирование Kerberos, делегирование учетных данных (поддерживается CredSSP) и Remote Credential Guard. Хотя изначально они не были предназначены для решения проблемы двойного перехода, два подхода, которые обычно используются в красных командах, включают метод Kerberos Pass the Ticket (PTT) и создание нового сеанса входа в систему с явными учетными данными . Первый подход уже реализуется посредством вызова пакета AP, в частности, SubmitTicketвызова Kerberos. Второй нет. Вместо этого это достигается за счет использования одного из LogonUserAPI-интерфейсов Win32, который make_tokenиспользуется командой Cobalt Strike и ее производными.
Исследуя вызовы пакетов, которые мы могли сделать, мы заметили ChangeCachedPasswordвызов msv1_0 и AddExtraCredentialsвызов Kerberos. Мы думали, что любой из них потенциально может позволить нам применить известный пароль к существующему сеансу входа в систему. Это позволит решить проблему двойного перехода при использовании известных паролей без необходимости LogonUserвызова API. Это позволило бы нам использовать известный пароль на хосте без генерации события для создания нового сеанса входа в систему. Но и это оказалось нежизнеспособным. В результате тестирования ChangeCachedPasswordоказалось, что пакет не применяется к входу в сеть и AddExtraCredentialsне влияет на последующие попытки аутентификации.
В конце концов мы нашли вызов msv1_0 CacheLogon, который все еще может достичь той же цели; а именно, решение проблемы двойного перехода при использовании известного пароля без создания нового сеанса входа в систему. Этот вызов описан далее в разделе «Передача хеша», но мы считаем, что на хосте без LSASS, работающего как PPL, мы можем предварительно преобразовать известный пароль в хеш NT и передать его вызову CacheLogonдля использования в существующем вызове. сеанс входа в систему. Обратной стороной этого подхода является то, что нам придется выполнять код в LSASS, что, вероятно, создаст больше телеметрии, чем одно событие для нового сеанса входа в систему.
Удаленные вызовы
Сервер RPC интерфейса SSP (SSPI), который обеспечивает все, что делает LSA Whisperer, был разработан для локального использования. Сам сервер регистрирует только порт ALPC для прослушивания своей конечной точки, которая доступна только локально. Однако основная конструкция RPC заключается в том, что среда выполнения RPC позволяет отправлять запросы RPC для любого интерфейса RPC, зарегистрированного процессом, в любую конечную точку RPC, которую процесс в данный момент прослушивает, и среда выполнения выполнит этот запрос.Хотя сервер SSPI RPC регистрирует только один порт ALPC для конечной точки RPC, сам процесс LSASS прослушивает множество конечных точек RPC, некоторые из которых доступны удаленно. Мы хотели отправить эти запросы SSPI RPC к одной из этих конечных точек на удаленном хосте. Это позволит LSA Whisperer выполнять такие действия, как выгрузка билетов Kerberos, учетных ключей DPAPI и файлов cookie SSO на удаленном хосте.
Разве это не было бы здорово? Что ж, (к сожалению) интерфейс SSPI RPC зарегистрирован с флагом, RPC_IF_ALLOW_LOCAL_ONLYкоторый заставляет среду выполнения RPC разрешать только локальным клиентам RPC взаимодействовать с интерфейсом. Итак, если вы когда-нибудь задавались вопросом, можно ли сбросить билеты Kerberos на удаленный хост, насколько нам известно, это невозможно, но мы были бы рады, если бы мы оказались неправы!
Смягчения
У администратора практически нет встроенных возможностей предотвращения вызовов пакетов, выполняемых LSA Whisperer. LSA Whisperer использует только предусмотренные для Windows функции, и блокирование успешных вызовов пакетов помешает успешному выполнению обычных процессов аутентификации Windows. При этом включение Credential Guard блокирует некоторые команды восстановления учетных данных DPAPI, и мы полагаем, что также предотвращает генерацию ответа NTLMv1 с использованием основных учетных данных активного сеанса входа в систему. Одна команда восстановления учетных данных DPAPI по-прежнему доступна при включенном Credential Guard, но блокировка генерации ответа NTLMv1 не позволяет злоумышленникам легко восстановить пригодный для использования NT-хеш для пользователя. Credential Guard может влиять на команды, которые мы не заметили во время тестирования. Если вы заметили, что Credential Guard влияет на команду, которую мы пропустили, рассмотрите возможность сделать запрос на вики .У администраторов также почти нет встроенных возможностей для мониторинга LSA Whisperer и подобных инструментов. Наибольший потенциал имеет мониторинг с помощью трассировки событий для Windows (ETW), который используется во всех пакетах, но не согласованным и не документированным способом. Дополнительная помощь со стороны Microsoft с указанием поставщиков ETW для мониторинга и публикацией схем сообщений для каждого из них будет иметь большое значение для предоставления администраторам возможности отслеживать эти вызовы.
Вызовы пакетов теперь выполняются сервером SSPI RPC, поэтому мы также исследовали использование функций RPC в качестве метода отслеживания или предотвращения вызовов определенных пакетов. Существует поставщик ETW под названием «RPC Events», который дает некоторое представление обо всей активности RPC, включая действия, облегчающие вызов пакета, но, по нашему мнению, он не дает достаточного понимания для эффективного мониторинга этой активности. Мы исследовали использование встроенного в Windows механизма фильтров RPC, но он не обеспечивает степень детализации, необходимую для эффективного мониторинга или предотвращения вызовов пакетов. Наконец, мы исследовали использование брандмауэра RPC , популярного стороннего решения FOSS, поддерживаемого Zero Networks . Хотя это решение кажется многообещающим для административных нужд, оно не предотвращает локальный трафик RPC и несовместимо с LSA, работающим как PPL. Сервер SSPI RPC разрешает только локальный трафик RPC, поэтому брандмауэр RPC для этой цели непригоден. Даже если бы это было так, разрешение LSA не работать как PPL дало бы злоумышленникам возможность использовать Mimikatz и связанные с ним инструменты для прямого восстановления учетных данных из памяти LSASS, что делает альтернативный подход, который использует LSA Whisperer, спорно ненужным.
В конечном итоге наши рекомендации для администраторов включают в себя:
- Включить LSASS для работы в качестве PPL
- Включение Credential Guard
- Выходите из системы, когда закончите ее использовать.
- Используйте рабочие станции/устройства с привилегированным доступом и следуйте принципу чистого исходного кода.
Здесь суммированы наши рекомендации администраторам относительно того, что, по нашему мнению, напрямую влияет на LSA Whisperer, но есть настройки, которые вы можете включить для дальнейшего усиления Credential Guard. Эти настройки описаны на специальной странице образовательного портала Microsoft . Не все из этих настроек могут быть доступны для вашей организации, но мы рекомендуем те, которые есть.
Рекомендации по ЭДР
Поставщики Endpoint Detection and Response (EDR), включая саму Microsoft, вероятно, смогут лучше всего отслеживать и предотвращать использование LSA Whisperer и подобных инструментов. Вот что мы рекомендуем отслеживать с помощью EDR:- Вызовы LsaCallAuthenticationPackageWin32 API
- Взаимодействие с портом ALPClsasspirpc
Наконец, мы рекомендуем, чтобы EDR предотвращали следующую деятельность:
- Вызовы к конечным точкам LSASS RPC, отличным lsasspirpc от интерфейса 4f32adc8–6052–4a04–8701–293ccf2096f0(SSPI).
Заключение
В этом посте мы затронули несколько тем, но я хочу, чтобы вы усвоили, что большинство (а возможно, и все) учетных данных, необходимых злоумышленнику для достижения своих целей в операции Windows, могут быть получены без доступа к памяти LSASS. Вам даже не нужно открывать дескриптор LSASS. В правильной ситуации вы можете получить то, что хотите, если вежливо попросите LSA.Вам нужны билеты Kerberos? Подождите, пока целевой пользователь войдет в систему, выдаст себя за пользователя или SYSTEM, а затем попросите LSA передать их вам, используя обычный метод «сброса билетов». Вместо этого вам нужен NT-хеш для работы с PtH? Предполагая, что Credential Guard отключен, олицетворите его SYSTEM, запросите ответ NTLMv1 для сеанса входа в систему целевого пользователя с выбранным запросом сервера, а затем взломайте его до пригодного для использования NT-хэша для пользователя. Вместо этого вам нужен доступ к множеству пользовательских данных, зашифрованных с помощью DPAPI? Олицетворяйте SYSTEM, запросите ключ учетных данных DPAPI для сеанса входа в систему целевого пользователя, а затем используйте его с SharpDPAPI для расшифровки файла главного ключа DPAPI. Включают ли теперь оценки вашей красной команды облачные цели? Выдайте себя за сеанс входа пользователя в облако, а затем попросите LSA предоставить вам файл cookie единого входа для этой учетной записи.
Если вам понравилась эта работа, ознакомьтесь с проектом LSA Whisperer на GitHub ! Проект также включает в себя обширную вики-страницу со всеми проведенными исследованиями. Чтобы начать работу , вы можете использовать руководство по сборке в файле readme проекта и руководство по использованию в вики проекта. Слайды презентации SOCON доступны на Github , а видео будет доступно бесплатно на канале SpectreOps на YouTube после его выпуска. Если у вас есть вопросы, вы можете обратиться ко мне в команду Slack BloodHoundGang или начать обсуждение на GitHub . Я сделаю все возможное, чтобы ответить на вопросы, как я могу. Если вы видите область, где проект или вики можно улучшить, отправьте сообщение о проблеме на GitHub или рассмотрите возможность запроса на включение проекта. Ваш вклад оценен по достоинству!