ESC10 — це потужна техніка постексплуатації в службах сертифікації Active Directory (ADCS), яка дозволяє зловмисникам автентифікуватися як будь-який користувач (навіть адміністратор домену), не знаючи його пароля. Вона експлуатує дві основні слабкості: слабке примусове зіставлення сертифікатів та тіньові облікові дані (shadow credentials) (кастомні входи за сертифікатами). На відміну від традиційних атак, ESC10 зловживає моделлю довіри PKI та гнучкістю AD, що робить її прихованою, стійкою та часто ігнорованою в корпоративних середовищах.

Зміст

• Огляд атаки ESC10
• Принцип роботи ESC10
• ESC10 як розширення ESC9
• Попередні умови
• Налаштування лабораторії
• Збір інформації та експлуатація
• Слабке зіставлення UPN через Shadow Credentials
• Постексплуатація
• Переміщення мережею та підвищення привілеїв за допомогою LDAP Shell від Certipy від імені адміністратора
• Переміщення мережею та підвищення привілеїв за допомогою Evil-Winrm
• Заходи захисту

Огляд атаки ESC10

ESC10 — це потужна варіація атаки ESC9, обидві з яких призводять до повної компрометації домену. У той час як ESC9 вимагає від зловмисника ідентифікації неправильно налаштованого шаблону сертифіката та облікового запису, який він може змінити (через GenericWrite), вона обмежена шаблонами зі специфічними небезпечними конфігураціями (наприклад, ENROLLEE_SUPPLIES_SUBJECT). Навпаки, ESC10 повністю усуває це обмеження, роблячи атаку набагато гнучкішою та ширшою у застосуванні. Вона використовує припущення про довіру на рівні системи, а не покладається виключно на властивості конкретного шаблону сертифіката.

ESC10 експлуатує вразливості в AD CS та Kerberos-автентифікації на основі сертифікатів (PKINIT):

Слабке примусове зіставлення сертифікатів (StrongCertificateBindingEnforcement = 0)

• Коли сильна прив’язка вимкнена, AD покладається лише на User Principal Name (UPN) сертифіката, ігноруючи Security Identifier (SID).
• Це дозволяє зловмисникам підробляти UPN привілейованих користувачів (наприклад, адміністраторів домену) та отримувати несанкціонований доступ за допомогою підробленого сертифіката.

Shadow credentials через права запису в msDS-KeyCredentialLink

• Якщо зловмисник має права запису в цей атрибут облікового запису користувача, він може впорскнути кастомні облікові дані на основі сертифіката.
• Це уможливлює атаки типу Pass-the-Certificate та стійкий безпарольний доступ.

Підміна UPN через маніпуляції з обліковим записом

• Маючи права GenericWrite, зловмисник може змінити UPN контрольованого або цільового облікового запису, щоб імітувати іншого користувача.
• У поєднанні зі слабкою прив’язкою це дозволяє реєстрацію сертифіката та Kerberos-автентифікацію від імені підробленої особи.

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

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

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

• Зловмисник отримує контроль над обліковим записом користувача з низькими привілеями через будь-який метод початкового доступу (наприклад, фішинг, брутфорс, дамп облікових даних).
• Зловмисник виявляє, що перевірка ключа реєстру послаблює модель довіри домену щодо автентифікації на основі сертифікатів:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesKdcStrongCertificateBindingEnforcement

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

• Використовуючи права GenericWrite над іншим об’єктом користувача (наприклад, sanjeet), зловмисник змінює User Principal Name (UPN) контрольованого акаунта, щоб він збігався з ціллю (наприклад, Administrator@ignite.local).
• Потім зловмисник запитує сертифікат на ім’я цієї цілі, використовуючи будь-який шаблон сертифіката, доступний для реєстрації.
• З цим підробленим сертифікатом зловмисник автентифікується як привілейований користувач і отримує повний доступ до домену.

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

ESC10 як розширення ESC9

ESC10 розширює той самий основний шлях зловживання, представлений в ESC9:

• ESC9: Покладається на конкретний вразливий шаблон сертифіката, де ввімкнено ENROLLEE_SUPPLIES_SUBJECT, а зловмисник має GenericWrite над іншим об’єктом користувача.
• ESC10: Узагальнює техніку, усуваючи обмеження щодо шаблону сертифіката і замість цього експлуатує слабке примусове зіставлення сертифіката з користувачем (тобто StrongCertificateBindingEnforcement = 0), значно збільшуючи поверхню атаки.

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

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

Для успішного проведення атаки ESC10 у цільовому середовищі Active Directory мають бути виконані кілька умов:

• Примусове зіставлення сертифікатів має бути встановлено на “слабке” або вимкнено.
• Зловмисник (raj) повинен мати доступ на запис (наприклад, GenericWrite, WriteProperty) до цільового облікового запису проксі-користувача (sanjeet) для маніпулювання атрибутами, такими як UPN та msDS-KeyCredentialLink.
• Для реєстрації має бути доступний шаблон сертифіката з низькими привілеями (як для raj).

Ці умови начувано поширені в середовищах ADCS, що недостатньо аудіюються.

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

• Windows Server 2019 як Active Directory з підтримкою PKINIT
• Домен повинен мати налаштовані служби сертифікації Active Directory та Центр сертифікації.
• Kali Linux із необхідними інструментами
• Інструменти: Evil-Winrm, certipy-ad

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

Щоб симулювати атаку ESC10 у лабораторії, почніть із встановлення StrongCertificateBindingEnforcement = 0 на контролері домену, щоб дозволити слабке зіставлення сертифікатів, а потім надайте доступ GenericWrite на обліковий запис із низькими привілеями (sanjeet) вашому акаунту зловмисника (raj), щоб уможливити ін’єкцію тіньових облікових даних та маніпуляцію UPN.

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

Щоб створити умови, придатні для ESC10, або перевірити середовище на вразливість, перевірте наступне налаштування реєстру на контролері домену: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc

• 0 = Disabled — Зіставлення сертифікатів базується тільки на UPN, а валідація SID пропускається. Це налаштування робить домен повністю вразливим до ESC10 та інших атак зі зловживанням сертифікатами.
• 1 = Compatibility mode — Намагається забезпечити прив’язку SID, коли це можливо, але повертається до зіставлення за UPN, якщо SID відсутній. Усе ще частково вразливо.
• 2 = Strict — Вимагає зіставлення SID, що фактично нівелює ESC10.

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

Далі ми підготуємо ґрунт, надавши нашому зловмиснику (raj) контроль над проксі-акаунтом (sanjeet) для використання в ланцюжку імітації сертифіката.

Надання прав запису на проксі-акаунт

Для налаштування ESC10 призначте дозволи GenericWrite або WriteProperty на цільовий проксі-акаунт (наприклад, sanjeet) обліковому запису, який контролює зловмисник (raj). Це можна зробити через Active Directory Users and Computers (увімкнувши Advanced Features), Active Directory ACL Editor або через PowerShell.

Чому це важливо: Маючи ці права, raj отримує можливість:

• Впорскнути підроблений сертифікат (shadow credential) користувачеві sanjeet через атрибут msDS-KeyCredentialLink.
• Змінити UPN користувача sanjeet, щоб він збігався з UPN привілейованого користувача, наприклад Administrator@ignite.local.
• Контролювати поведінку зіставлення сертифікатів, особливо коли ввімкнено слабке примусове виконання (StrongCertificateBindingEnforcement = 0).

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

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

Слабке зіставлення UPN через Shadow Credentials

Це дозволяє нам впорскнути підроблений сертифікат в атрибут msDS-KeyCredentialLink цільового облікового запису та автентифікуватися як цей користувач, експлуатуючи слабке зіставлення UPN до SID, коли StrongCertificateBindingEnforcement = 0. Продовжимо.

Додавання та використання Shadow Credential (режим Auto)

Використовуючи Certipy, виконайте команду для впорскування тіньових облікових даних в акаунт sanjeet та негайної автентифікації:

certipy-ad shadow auto -u raj@ignite.local -p Password@1 -account sanjeet -dc-ip 192.168.1.16

Запускаючи команду certipy-ad shadow auto, ми впорскуємо прихований логін на основі сертифіката (KeyCredential) в акаунт sanjeet, негайно автентифікуємося як цей користувач, а потім видаляємо впорскнутий ключ, щоб уникнути виявлення.

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

Підміна UPN для відповідності Administrator

За допомогою наступної команди Certipy ми змінюємо User Principal Name (UPN) користувача sanjeet для імітації облікового запису адміністратора домену:

certipy-ad account update -u raj@ignite.local -password Password@1 -user sanjeet -upn Administrator -dc-ip 192.168.1.16

Ця зміна експлуатує раніше виявлене неправильне налаштування реєстру (StrongCertificateBindingEnforcement = 0), де контролер домену довіряє зіставленню сертифікатів на основі UPN без перевірки SID облікового запису.

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

Це готує ґрунт для автентифікації як адміністратор домену на наступному етапі атаки ESC10.

Запит сертифіката з підробленим UPN

Далі скористайтеся Certipy, щоб запросити сертифікат для sanjeet, чий UPN вже підроблено під Administrator.

certipy-ad req -u sanjeet@ignite.local -hashes 64fbae31cc352fc26af97cbdef151e03 -ca ignite-DC1-CA -template USER -dc-ip 192.168.1.16

Цей крок видає сертифікат, що містить підроблений UPN (Administrator), але підписаний для sanjeet. Оскільки Центр сертифікації (CA) не перевіряє UPN на відповідність реальним привілеям або SID запитувача, а також через слабке примусове зіставлення, Active Directory вважатиме цей сертифікат легітимним для Administrator.

Результатом є дійсний .pfx сертифікат, який ми тепер можемо використати для автентифікації як адміністратор домену, завершуючи критичний етап ланцюжка ESC10.

Повернення UPN для прихованості

Щоб відновити оригінальний User Principal Name (UPN) для sanjeet, використовується наступна команда:

certipy-ad account update -u raj@ignite.local -p Password@1 -user sanjeet -upn sanjeet@ignite.local -dc-ip 192.168.1.16

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

Відновлення UPN дозволяє користувачеві знову “злитися” із середовищем, ефективно приховуючи будь-яку попередню підміну UPN і знижуючи ризик відстеження адміністративної активності.

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

Щоб автентифікуватися як адміністратор за допомогою підробленого сертифіката, виконується наступна команда:

certipy-ad auth -pfx administrator.pfx -domain ignite.local

Ця команда використовує підроблений сертифікат для запиту Kerberos-квитка від імені Administrator. PKINIT підтримує вхід за сертифікатами, який довіряє виданому сертифікату, якщо UPN збігається. Як результат, ми тепер автентифіковані як адміністратор домену, що надає повні адміністративні привілеї.

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

Переміщення мережею та підвищення привілеїв за допомогою LDAP Shell від Certipy від імені адміністратора

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

certipy-ad auth -pfx administrator.pfx -domain ignite.local -ldap-shell -dc-ip 192.168.1.16

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

Переміщення мережею та підвищення привілеїв за допомогою Evil-Winrm

Отримавши доступ через certipy-ad ldap-shell, ми можемо за бажанням використати Evil-WinRM для отримання повноцінної віддаленої оболонки. Використовуючи NTLM-хеш привілейованого акаунта, запускаємо:

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

Це дає пряму адміністративну сесію PowerShell для кращого контролю. Це необов’язково, але підвищує прихованість та гнучкість виконання команд.

Mitigation

• Встановіть StrongCertificateBindingEnforcement = 2 або вище.
• Обмежте доступ на запис до атрибута msDS-KeyCredentialLink.
• Забезпечте належні дозволи на шаблони та робочі процеси схвалення.
• Проводьте аудит змін UPN, особливо для облікових записів адміністративного типу.
• Моніторте логи PKINIT та видачі сертифікатів (Event IDs 4886/4887).