AD CS Domain Escalation
Це резюме секцій технік ескалації постів:
Неправильно налаштовані шаблони сертифікатів - ESC1
Пояснення
Неправильно налаштовані шаблони сертифікатів - ESC1 Пояснено
Права на реєстрацію надаються користувачам з низькими привілеями через Enterprise CA.
Затвердження менеджера не потрібне.
Не потрібні підписи уповноважених осіб.
Безпекові дескриптори на шаблонах сертифікатів є надто ліберальними, що дозволяє користувачам з низькими привілеями отримувати права на реєстрацію.
Шаблони сертифікатів налаштовані для визначення EKU, які полегшують аутентифікацію:
Ідентифікатори розширеного використання ключів (EKU), такі як Аутентифікація клієнта (OID 1.3.6.1.5.5.7.3.2), Аутентифікація клієнта PKINIT (1.3.6.1.5.2.3.4), Вхід за допомогою смарт-картки (OID 1.3.6.1.4.1.311.20.2.2), Будь-яка мета (OID 2.5.29.37.0) або без EKU (SubCA) включені.
Шаблон дозволяє запитувачам включати subjectAltName у Запит на підпис сертифіката (CSR):
Active Directory (AD) надає пріоритет subjectAltName (SAN) у сертифікаті для перевірки особи, якщо він присутній. Це означає, що, вказуючи SAN у CSR, можна запитати сертифікат для видачі від імені будь-якого користувача (наприклад, адміністратора домену). Чи може запитувач вказати SAN, вказується в об'єкті AD шаблону сертифіката через властивість
mspki-certificate-name-flag
. Ця властивість є бітовою маскою, і наявність прапораCT_FLAG_ENROLLEE_SUPPLIES_SUBJECT
дозволяє запитувачу вказувати SAN.
Ця конфігурація дозволяє користувачам з низькими привілеями запитувати сертифікати з будь-яким вибраним SAN, що дозволяє аутентифікацію як будь-якого доменного принципала через Kerberos або SChannel.
Ця функція іноді активується для підтримки генерації HTTPS або хост-сертифікатів на льоту продуктами або службами розгортання, або через брак розуміння.
Зазначено, що створення сертифіката з цією опцією викликає попередження, чого не відбувається, коли існуючий шаблон сертифіката (такий як шаблон WebServer
, у якого активовано CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT
) дублюється, а потім модифікується для включення OID аутентифікації.
Зловживання
Щоб знайти вразливі шаблони сертифікатів, ви можете виконати:
Щоб зловживати цією вразливістю для видавання себе за адміністратора, можна виконати:
Тоді ви можете перетворити згенерований сертифікат у формат .pfx
і використовувати його для автентифікації за допомогою Rubeus або certipy знову:
Віконні двійкові файли "Certreq.exe" та "Certutil.exe" можуть бути використані для генерації PFX: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee
Перерахунок шаблонів сертифікатів у конфігураційній схемі лісу AD, зокрема тих, які не потребують затвердження або підписів, що мають EKU для клієнтської аутентифікації або Smart Card Logon, та з увімкненим прапором CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT
, можна виконати, запустивши наступний LDAP запит:
Неправильно налаштовані шаблони сертифікатів - ESC2
Пояснення
Другий сценарій зловживання є варіацією першого:
Права на реєстрацію надаються користувачам з низькими привілеями через Enterprise CA.
Вимога на затвердження менеджера вимкнена.
Необхідність авторизованих підписів пропущена.
Надмірно дозволяючий дескриптор безпеки на шаблоні сертифіката надає права на реєстрацію сертифікатів користувачам з низькими привілеями.
Шаблон сертифіката визначено так, щоб включати Any Purpose EKU або не мати EKU.
Any Purpose EKU дозволяє зловмиснику отримати сертифікат для будь-якої мети, включаючи автентифікацію клієнта, автентифікацію сервера, підписування коду тощо. Та ж техніка, що використовується для ESC3, може бути застосована для експлуатації цього сценарію.
Сертифікати з без EKU, які діють як сертифікати підпорядкованого CA, можуть бути використані для будь-якої мети і також можуть бути використані для підписування нових сертифікатів. Отже, зловмисник може вказати довільні EKU або поля в нових сертифікатах, використовуючи сертифікат підпорядкованого CA.
Однак нові сертифікати, створені для автентифікації домену, не працюватимуть, якщо підпорядкований CA не довіряється об'єкту NTAuthCertificates
, що є налаштуванням за замовчуванням. Проте зловмисник все ще може створювати нові сертифікати з будь-яким EKU та довільними значеннями сертифікатів. Ці сертифікати можуть бути потенційно зловживані для широкого спектру цілей (наприклад, підписування коду, автентифікація сервера тощо) і можуть мати значні наслідки для інших додатків у мережі, таких як SAML, AD FS або IPSec.
Щоб перерахувати шаблони, які відповідають цьому сценарію в конфігураційній схемі лісу AD, можна виконати наступний LDAP запит:
Неправильно налаштовані шаблони агентів реєстрації - ESC3
Пояснення
Цей сценарій схожий на перший і другий, але зловживає іншим EKU (Агент запиту сертифіката) та 2 різними шаблонами (отже, має 2 набори вимог),
EKU агента запиту сертифіката (OID 1.3.6.1.4.1.311.20.2.1), відомий як Агент реєстрації в документації Microsoft, дозволяє суб'єкту реєструватися на сертифікат від імені іншого користувача.
“Агент реєстрації” реєструється в такому шаблоні і використовує отриманий сертифікат для спільного підписання CSR від імені іншого користувача. Потім він надсилає спільно підписаний CSR до CA, реєструючись у шаблоні, який дозволяє “реєстрацію від імені”, і CA відповідає сертифікатом, що належить “іншому” користувачу.
Вимоги 1:
Права на реєстрацію надаються користувачам з низькими привілеями через Enterprise CA.
Вимога на затвердження менеджера пропускається.
Немає вимоги на авторизовані підписи.
Безпековий дескриптор шаблону сертифіката є надмірно дозволяючим, надаючи права на реєстрацію користувачам з низькими привілеями.
Шаблон сертифіката включає EKU агента запиту сертифіката, що дозволяє запитувати інші шаблони сертифікатів від імені інших суб'єктів.
Вимоги 2:
Enterprise CA надає права на реєстрацію користувачам з низькими привілеями.
Затвердження менеджера обходиться.
Версія схеми шаблону є або 1, або перевищує 2, і вона вказує на вимогу політики застосування, яка вимагає EKU агента запиту сертифіката.
EKU, визначений у шаблоні сертифіката, дозволяє автентифікацію домену.
Обмеження для агентів реєстрації не застосовуються на CA.
Зловживання
Ви можете використовувати Certify або Certipy для зловживання цим сценарієм:
Користувачі, яким дозволено отримувати сертифікат агента реєстрації, шаблони, в яких агентам реєстрації дозволено реєструватися, та рахунки, від імені яких агент реєстрації може діяти, можуть бути обмежені корпоративними ЦС. Це досягається шляхом відкриття certsrc.msc
додатку, клацання правою кнопкою миші на ЦС, вибору Властивості, а потім переміщення на вкладку “Агенти реєстрації”.
Однак зазначено, що за замовчуванням налаштування для ЦС полягає в тому, щоб “Не обмежувати агентів реєстрації.” Коли обмеження для агентів реєстрації активується адміністраторами, встановлення його на “Обмежити агентів реєстрації” залишає конфігурацію за замовчуванням надзвичайно ліберальною. Це дозволяє Усім отримати доступ до реєстрації в усіх шаблонах як будь-хто.
Вразливий контроль доступу до шаблону сертифіката - ESC4
Пояснення
Безпековий дескриптор на шаблонах сертифікатів визначає дозволи, які конкретні принципали AD мають щодо шаблону.
Якщо зловмисник має необхідні дозволи для зміни шаблону та встановлення будь-яких експлуатованих неконфігурацій, описаних у попередніх розділах, може бути полегшено підвищення привілеїв.
Значні дозволи, що застосовуються до шаблонів сертифікатів, включають:
Власник: Надає неявний контроль над об'єктом, дозволяючи змінювати будь-які атрибути.
Повний контроль: Дозволяє повну владу над об'єктом, включаючи можливість змінювати будь-які атрибути.
Змінити власника: Дозволяє змінювати власника об'єкта на принципала під контролем зловмисника.
Змінити DACL: Дозволяє коригувати контроль доступу, потенційно надаючи зловмиснику Повний контроль.
Змінити властивість: Дозволяє редагувати будь-які властивості об'єкта.
Зловживання
Приклад підвищення привілеїв, як у попередньому:
ESC4 - це коли користувач має права на запис над шаблоном сертифіката. Це, наприклад, може бути зловжито для переписування конфігурації шаблона сертифіката, щоб зробити шаблон вразливим до ESC1.
Як ми бачимо на наведеному вище шляху, лише JOHNPC
має ці привілеї, але наш користувач JOHN
має новий AddKeyCredentialLink
до JOHNPC
. Оскільки ця техніка пов'язана з сертифікатами, я також реалізував цю атаку, яка відома як Shadow Credentials. Ось невеликий попередній перегляд команди shadow auto
Certipy для отримання NT хешу жертви.
Certipy може перезаписати конфігурацію шаблону сертифіката одним командою. За замовчуванням, Certipy перезаписує конфігурацію, щоб зробити її вразливою до ESC1. Ми також можемо вказати -save-old
параметр для збереження старої конфігурації, що буде корисно для відновлення конфігурації після нашої атаки.
Вразливий контроль доступу до об'єктів PKI - ESC5
Пояснення
Широка мережа взаємопов'язаних відносин на основі ACL, яка включає кілька об'єктів, крім шаблонів сертифікатів і центру сертифікації, може вплинути на безпеку всієї системи AD CS. Ці об'єкти, які можуть суттєво вплинути на безпеку, охоплюють:
Об'єкт комп'ютера AD сервера CA, який може бути скомпрометований через механізми, такі як S4U2Self або S4U2Proxy.
RPC/DCOM сервер сервера CA.
Будь-який нащадок об'єкта AD або контейнера в межах конкретного шляху контейнера
CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>
. Цей шлях включає, але не обмежується, контейнерами та об'єктами, такими як контейнер шаблонів сертифікатів, контейнер центрів сертифікації, об'єкт NTAuthCertificates та контейнер послуг реєстрації.
Безпека системи PKI може бути скомпрометована, якщо зловмисник з низькими привілеями зможе отримати контроль над будь-яким з цих критичних компонентів.
EDITF_ATTRIBUTESUBJECTALTNAME2 - ESC6
Пояснення
Тема, обговорена в пості CQure Academy, також торкається наслідків прапора EDITF_ATTRIBUTESUBJECTALTNAME2
, як зазначено Microsoft. Ця конфігурація, коли вона активована на Центрі сертифікації (CA), дозволяє включати значення, визначені користувачем, у додаткову назву суб'єкта для будь-якого запиту, включаючи ті, що створені з Active Directory®. Внаслідок цього, ця можливість дозволяє зловмиснику зареєструватися через будь-який шаблон, налаштований для автентифікації домену — зокрема, ті, що відкриті для реєстрації непривілейованими користувачами, як стандартний шаблон користувача. В результаті, сертифікат може бути отриманий, що дозволяє зловмиснику автентифікуватися як доменний адміністратор або будь-яка інша активна сутність в межах домену.
Примітка: Підхід до додавання додаткових імен у Запит на підпис сертифіката (CSR) через аргумент -attrib "SAN:"
у certreq.exe
(який називається “Пари значення імен”) представляє контраст з експлуатаційною стратегією SAN у ESC1. Тут відмінність полягає в тому, як інформація про обліковий запис інкапсульована — в атрибуті сертифіката, а не в розширенні.
Зловживання
Щоб перевірити, чи активовано налаштування, організації можуть використовувати наступну команду з certutil.exe
:
Ця операція в основному використовує доступ до віддаленого реєстру, отже, альтернативний підхід може бути:
Інструменти, такі як Certify та Certipy, здатні виявляти цю неправильну конфігурацію та експлуатувати її:
Щоб змінити ці налаштування, припускаючи, що у вас є права адміністратора домену або еквівалентні, можна виконати наступну команду з будь-якої робочої станції:
Щоб вимкнути цю конфігурацію у вашому середовищі, прапорець можна видалити за допомогою:
Після оновлень безпеки травня 2022 року, нові видані сертифікати міститимуть розширення безпеки, яке включає властивість objectSid
запитувача. Для ESC1 цей SID отримується з вказаного SAN. Однак для ESC6 SID відображає objectSid
запитувача, а не SAN.
Щоб експлуатувати ESC6, важливо, щоб система була вразливою до ESC10 (Слабкі відображення сертифікатів), яке надає пріоритет SAN над новим розширенням безпеки.
Вразливий контроль доступу до центру сертифікації - ESC7
Атака 1
Пояснення
Контроль доступу для центру сертифікації підтримується через набір дозволів, які регулюють дії CA. Ці дозволи можна переглянути, отримавши доступ до certsrv.msc
, клацнувши правою кнопкою миші на CA, вибравши властивості, а потім перейшовши на вкладку Безпека. Крім того, дозволи можна перерахувати за допомогою модуля PSPKI з командами, такими як:
Це надає уявлення про основні права, а саме ManageCA
та ManageCertificates
, що відповідають ролям "адміністратор CA" та "менеджер сертифікатів" відповідно.
Зловживання
Наявність прав ManageCA
на центрах сертифікації дозволяє суб'єкту маніпулювати налаштуваннями віддалено, використовуючи PSPKI. Це включає в себе перемикання прапорця EDITF_ATTRIBUTESUBJECTALTNAME2
для дозволу специфікації SAN у будь-якому шаблоні, що є критичним аспектом ескалації домену.
Спрощення цього процесу можливе за допомогою використання cmdlet Enable-PolicyModuleFlag PSPKI, що дозволяє вносити зміни без прямої взаємодії з GUI.
Володіння правами ManageCertificates
полегшує затвердження очікуючих запитів, ефективно обходячи захист "затвердження менеджера сертифікатів CA".
Комбінація модулів Certify та PSPKI може бути використана для запиту, затвердження та завантаження сертифіката:
Attack 2
Explanation
У попередньому нападі Manage CA
дозволи використовувалися для включення прапора EDITF_ATTRIBUTESUBJECTALTNAME2 для виконання ESC6 атаки, але це не матиме жодного ефекту, поки служба CA (CertSvc
) не буде перезапущена. Коли у користувача є право доступу Manage CA
, користувач також має право перезапустити службу. Однак це не означає, що користувач може перезапустити службу віддалено. Крім того, ESC6 може не працювати з коробки в більшості патчованих середовищ через оновлення безпеки травня 2022 року.
Тому тут представлено ще один напад.
Перелік вимог:
Тільки
ManageCA
дозвілManage Certificates
дозвіл (може бути наданий зManageCA
)Шаблон сертифіката
SubCA
повинен бути включений (може бути включений зManageCA
)
Техніка базується на тому, що користувачі з правами доступу Manage CA
та Manage Certificates
можуть видавати невдалі запити на сертифікати. Шаблон сертифіката SubCA
є вразливим до ESC1, але тільки адміністратори можуть зареєструватися в шаблоні. Таким чином, користувач може запросити реєстрацію в SubCA
- що буде відхилено - але потім видано менеджером пізніше.
Abuse
Ви можете наділити себе правом доступу Manage Certificates
, додавши свого користувача як нового офіцера.
Шаблон SubCA
може бути увімкнений на CA за допомогою параметра -enable-template
. За замовчуванням шаблон SubCA
увімкнений.
Якщо ми виконали попередні умови для цієї атаки, ми можемо почати з запиту сертифіката на основі шаблону SubCA
.
Цей запит буде відхилено, але ми збережемо приватний ключ і запишемо ідентифікатор запиту.
З нашими Manage CA
та Manage Certificates
ми можемо випустити невдалий запит на сертифікат за допомогою команди ca
та параметра -issue-request <request ID>
.
І нарешті, ми можемо отримати виданий сертифікат за допомогою команди req
та параметра -retrieve <request ID>
.
NTLM Relay to AD CS HTTP Endpoints – ESC8
Пояснення
У середовищах, де встановлено AD CS, якщо існує вразливий веб-інтерфейс для реєстрації і принаймні один шаблон сертифіката опубліковано, що дозволяє реєстрацію комп'ютерів домену та автентифікацію клієнтів (такий як за замовчуванням Machine
шаблон), стає можливим, щоб будь-який комп'ютер з активною службою спулера був скомпрометований зловмисником!
Кілька методів реєстрації на основі HTTP підтримуються AD CS, які доступні через додаткові ролі сервера, які можуть встановити адміністратори. Ці інтерфейси для реєстрації сертифікатів на основі HTTP вразливі до атак NTLM relay. Зловмисник з скомпрометованої машини може видавати себе за будь-який обліковий запис AD, який автентифікується через вхідний NTLM. В той час як зловмисник видає себе за обліковий запис жертви, ці веб-інтерфейси можуть бути доступні зловмиснику для запиту сертифіката автентифікації клієнта, використовуючи шаблони сертифікатів User
або Machine
.
Веб-інтерфейс реєстрації (старий ASP-додаток, доступний за адресою
http://<caserver>/certsrv/
), за замовчуванням працює тільки через HTTP, що не забезпечує захисту від атак NTLM relay. Крім того, він явно дозволяє тільки NTLM-автентифікацію через свій заголовок Authorization HTTP, що робить більш безпечні методи автентифікації, такі як Kerberos, непридатними.Служба реєстрації сертифікатів (CES), Політика реєстрації сертифікатів (CEP) веб-сервісу та Служба реєстрації мережевих пристроїв (NDES) за замовчуванням підтримують автентифікацію negotiate через свій заголовок Authorization HTTP. Автентифікація negotiate підтримує як Kerberos, так і NTLM, що дозволяє зловмиснику знизити рівень до NTLM автентифікації під час атак relay. Хоча ці веб-сервіси за замовчуванням активують HTTPS, HTTPS сам по собі не захищає від атак NTLM relay. Захист від атак NTLM relay для HTTPS-сервісів можливий лише тоді, коли HTTPS поєднується з прив'язкою каналу. На жаль, AD CS не активує Розширений захист для автентифікації на IIS, що є необхідним для прив'язки каналу.
Звичайною проблемою атак NTLM relay є коротка тривалість сесій NTLM та неможливість зловмисника взаємодіяти з сервісами, які вимагають підписування NTLM.
Проте, це обмеження долається шляхом використання атаки NTLM relay для отримання сертифіката для користувача, оскільки термін дії сертифіката визначає тривалість сесії, а сертифікат може бути використаний з сервісами, які вимагають підписування NTLM. Для інструкцій щодо використання вкраденого сертифіката, зверніться до:
Ще одним обмеженням атак NTLM relay є те, що машина, контрольована зловмисником, повинна бути автентифікована обліковим записом жертви. Зловмисник може або чекати, або намагатися примусити цю автентифікацію:
Зловживання
Certify’s cas
перераховує включені HTTP AD CS кінцеві точки:
Властивість msPKI-Enrollment-Servers
використовується корпоративними центрами сертифікації (CAs) для зберігання кінцевих точок служби реєстрації сертифікатів (CES). Ці кінцеві точки можна розібрати та перерахувати, використовуючи інструмент Certutil.exe:
```powershell Import-Module PSPKI Get-CertificationAuthority | select Name,Enroll* | Format-List * ```
Зловживання з Certify
Зловживання з Certipy
Запит на сертифікат за замовчуванням здійснюється Certipy на основі шаблону Machine
або User
, залежно від того, чи закінчується ім'я облікового запису, що передається, на $
. Вказати альтернативний шаблон можна за допомогою параметра -template
.
Техніку, таку як PetitPotam, можна використовувати для примусу аутентифікації. При роботі з контролерами домену необхідно вказати -template DomainController
.
No Security Extension - ESC9
Пояснення
Новий значення CT_FLAG_NO_SECURITY_EXTENSION
(0x80000
) для msPKI-Enrollment-Flag
, відомий як ESC9, запобігає вбудовуванню нового szOID_NTDS_CA_SECURITY_EXT
безпекового розширення в сертифікат. Цей прапорець стає актуальним, коли StrongCertificateBindingEnforcement
встановлено на 1
(значення за замовчуванням), що контрастує з налаштуванням 2
. Його значущість зростає в сценаріях, де може бути використано слабше відображення сертифікатів для Kerberos або Schannel (як у ESC10), оскільки відсутність ESC9 не змінює вимоги.
Умови, за яких налаштування цього прапорця стає значущим, включають:
StrongCertificateBindingEnforcement
не налаштовано на2
(за замовчуванням1
), абоCertificateMappingMethods
включає прапорецьUPN
.Сертифікат позначений прапорцем
CT_FLAG_NO_SECURITY_EXTENSION
у налаштуванніmsPKI-Enrollment-Flag
.Будь-який EKU аутентифікації клієнта вказується сертифікатом.
Доступні дозволи
GenericWrite
над будь-яким обліковим записом для компрометації іншого.
Сценарій зловживання
Припустимо, що John@corp.local
має дозволи GenericWrite
над Jane@corp.local
, з метою компрометації Administrator@corp.local
. Шаблон сертифіката ESC9
, в який Jane@corp.local
дозволено реєструватися, налаштований з прапорцем CT_FLAG_NO_SECURITY_EXTENSION
у своєму налаштуванні msPKI-Enrollment-Flag
.
Спочатку хеш Jane
отримується за допомогою Shadow Credentials, завдяки GenericWrite
Джона:
Потім userPrincipalName
Jane
змінюється на Administrator
, навмисно пропускаючи частину домену @corp.local
:
Ця модифікація не порушує обмеження, оскільки Administrator@corp.local
залишається відмінним як userPrincipalName
Administrator
.
Після цього запитується шаблон сертифіката ESC9
, позначений як вразливий, від імені Jane
:
Зазначено, що userPrincipalName
сертифіката відображає Administrator
, без будь-якого “object SID”.
userPrincipalName
Jane
потім повертається до її оригінального, Jane@corp.local
:
Спроба аутентифікації з виданим сертифікатом тепер дає NT хеш Administrator@corp.local
. Команда повинна включати -domain <domain>
через відсутність специфікації домену в сертифікаті:
Weak Certificate Mappings - ESC10
Explanation
Два значення ключа реєстру на контролері домену відносяться до ESC10:
Значення за замовчуванням для
CertificateMappingMethods
підHKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel
дорівнює0x18
(0x8 | 0x10
), раніше було встановлено на0x1F
.Налаштування за замовчуванням для
StrongCertificateBindingEnforcement
підHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc
дорівнює1
, раніше0
.
Case 1
Коли StrongCertificateBindingEnforcement
налаштовано як 0
.
Case 2
Якщо CertificateMappingMethods
включає біт UPN
(0x4
).
Abuse Case 1
При налаштуванні StrongCertificateBindingEnforcement
як 0
, обліковий запис A з правами GenericWrite
може бути використаний для компрометації будь-якого облікового запису B.
Наприклад, маючи права GenericWrite
на Jane@corp.local
, зловмисник намагається скомпрометувати Administrator@corp.local
. Процедура повторює ESC9, дозволяючи використовувати будь-який шаблон сертифіката.
Спочатку хеш Jane
отримується за допомогою Shadow Credentials, експлуатуючи GenericWrite
.
В результаті, Jane
's userPrincipalName
змінюється на Administrator
, навмисно пропускаючи частину @corp.local
, щоб уникнути порушення обмеження.
Наступним кроком запитується сертифікат, що дозволяє автентифікацію клієнта, від імені Jane
, з використанням шаблону за замовчуванням User
.
Jane
's userPrincipalName
потім повертається до свого оригінального, Jane@corp.local
.
Аутентифікація з отриманим сертифікатом дасть NT хеш Administrator@corp.local
, що вимагає вказівки домену в команді через відсутність деталей домену в сертифікаті.
Зловживання випадком 2
З CertificateMappingMethods
, що містить бітовий прапорець UPN
(0x4
), обліковий запис A з правами GenericWrite
може скомпрометувати будь-який обліковий запис B, який не має властивості userPrincipalName
, включаючи облікові записи машин і вбудованого доменного адміністратора Administrator
.
Тут мета полягає в компрометації DC$@corp.local
, починаючи з отримання хешу Jane
через Shadow Credentials, використовуючи GenericWrite
.
Jane
's userPrincipalName
тепер встановлено на DC$@corp.local
.
Сертифікат для автентифікації клієнта запитується як Jane
, використовуючи шаблон за замовчуванням User
.
Jane
's userPrincipalName
повертається до свого оригіналу після цього процесу.
Щоб аутентифікуватися через Schannel, використовується опція Certipy -ldap-shell
, що вказує на успішну аутентифікацію як u:CORP\DC$
.
Через LDAP shell команди, такі як set_rbcd
, дозволяють атаки на основі ресурсів з обмеженою делегацією (RBCD), що потенційно може скомпрометувати контролер домену.
Ця вразливість також поширюється на будь-який обліковий запис користувача, який не має userPrincipalName
або де він не збігається з sAMAccountName
, при цьому за замовчуванням Administrator@corp.local
є основною мішенню через свої підвищені привілеї LDAP та відсутність userPrincipalName
за замовчуванням.
Relaying NTLM to ICPR - ESC11
Пояснення
Якщо сервер CA не налаштований з IF_ENFORCEENCRYPTICERTREQUEST
, це може призвести до атак NTLM relay без підпису через службу RPC. Посилання тут.
Ви можете використовувати certipy
, щоб перевірити, чи вимкнено Enforce Encryption for Requests
, і certipy покаже вразливості ESC11
.
Сценарій зловживання
Потрібно налаштувати сервер ретрансляції:
Примітка: Для контролерів домену ми повинні вказати -template
в DomainController.
Або використовуючи форк sploutchy імпакту:
Shell доступ до ADCS CA з YubiHSM - ESC12
Пояснення
Адміністратори можуть налаштувати Центр сертифікації для зберігання його на зовнішньому пристрої, наприклад, "Yubico YubiHSM2".
Якщо USB-пристрій підключено до сервера CA через USB-порт або до сервера USB у випадку, якщо сервер CA є віртуальною машиною, потрібен ключ аутентифікації (іноді його називають "паролем") для того, щоб Провайдер зберігання ключів міг генерувати та використовувати ключі в YubiHSM.
Цей ключ/пароль зберігається в реєстрі за адресою HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword
у відкритому вигляді.
Посилання тут.
Сценарій зловживання
Якщо приватний ключ CA зберігається на фізичному USB-пристрої, коли ви отримали доступ до оболонки, можливо відновити ключ.
Спочатку вам потрібно отримати сертифікат CA (це публічно), а потім: