Lateral Movement: Pass the Certificate // TERMINAL // DATA

Вступ

Pass-the-Certificate — це високоефективна техніка постексплуатації, яка використовує сертифікати X.509 замість традиційних паролів або NTLM-хешів для автентифікації в середовищі Active Directory. Ця техніка експлуатує розширення PKINIT (Public Key Cryptography for Initial Authentication) протоколу Kerberos, дозволяючи атакуючому отримати Ticket-Granting Ticket (TGT) за допомогою викраденого або підробленого сертифіката.

У цій статті ми продемонструємо, як атакуючий, озброєний файлом сертифіката PFX (administrator.pfx), може використовувати різні інструменти для досягнення віддаленого виконання команд та доступу до інтерактивної оболонки на машинах, приєднаних до домену.

Зміст

Вступ
Передумови
Лабораторне середовище (Lab Environment)
Необхідні інструменти (Tools Required)
Конфігурація Kerberos (Kerberos Configuration)
Pass the Certificate (PFX файл)
Техніка 1: NetExec SMB із сертифікатом PFX
Техніка 2: NetExec WMI із сертифікатом PFX
Техніка 3: NetExec WinRM із сертифікатом PFX
Техніка 4: NetExec MSSQL із сертифікатом PFX
Матриця порівняння інструментів
Виявлення та рекомендації щодо захисту
Можливості виявлення
Рекомендації щодо захисту
Висновок

Ланцюг атак, який ми розглядаємо в цій статті, включає два основні методи автентифікації:

Автентифікація за PFX-сертифікатом: Безпосереднє використання файлу сертифіката .pfx з такими інструментами, як NetExec (nxc), для виконання команд через протоколи SMB, WMI, WinRM та MSSQL.

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

Перш ніж переходити до технік, продемонстрованих у цій статті, переконайтеся, що виконані наступні вимоги:

Лабораторне середовище

Конфігурація Kerberos

Для автентифікації на базі Kerberos із використанням файлів CCACHE необхідно правильно налаштувати файл /etc/krb5.conf на машині атакуючого (Kali Linux). Цей файл визначає область Kerberos (realm), Центр розподілу ключів (Key Distribution Center, KDC) та зіставлення доменів із областями (domain-to-realm mapping).

Наведена вище конфігурація встановлює наступне:

default_realm = IGNITE.LOCAL: Встановлює типову область Kerberos як IGNITE.LOCAL (має бути великими літерами).
kdc = DC.ignite.local: Вказує Контролер Домену як Центр розподілу ключів (KDC).
admin_server = DC.ignite.local: Вказує на адміністративний сервер Kerberos.
domain_realm mappings: Зіставляє як .ignite.local, так і ignite.local з областю IGNITE.LOCAL.

Крім того, переконайтеся, що файл /etc/hosts містить наступний запис:

192.168.1.11 DC.ignite.local dc.ignite.local

Pass the Certificate (PFX файл)

У цьому розділі ми демонструємо, як безпосередньо використовувати файл сертифіката administrator.pfx з NetExec (nxc) для виконання команд через різні протоколи без використання пароля або NTLM-хеша. NetExec підтримує автентифікацію на основі сертифікатів через SMB, WMI, WinRM та MSSQL.

Техніка 1: NetExec SMB із сертифікатом PFX

Перша техніка демонструє виконання команд через протокол SMB (порт 445) із використанням PFX-сертифіката. NetExec автентифікується на Контролері Домену за допомогою сертифіката та виконує команду ipconfig через стандартний метод виконання wmiexec.

nxc smb 192.168.1.11 --pfx-cert administrator.pfx -u administrator -x ipconfig

Вивід підтверджує успішну автентифікацію за допомогою NTLM-хеша облікового запису адміністратора (32196b56ffe6f45e294117b91a83bf38) та виконання команди через wmiexec. Вивід ipconfig розкриває конфігурацію мережі Контролера Домену: IP 192.168.1.11, підмережа 255.255.255.0 та шлюз 192.168.1.1.

Техніка 2: NetExec WMI із сертифікатом PFX

Друга техніка використовує протокол WMI (порт 135/RPC) для віддаленого виконання команд. Виконання на основі WMI, як правило, є більш прихованим (stealthier), ніж SMB, оскільки воно не створює службу на віддаленому хості.

nxc wmi 192.168.1.11 --pfx-cert administrator.pfx -u administrator -x whoami

Вивід показує успішну автентифікацію через RPC (порт 135) із прапорцем Pwn3d!, що підтверджує адміністративні привілеї. Команда whoami повертає ignite\administrator, перевіряючи, що виконання команди відбувається в контексті адміністратора домену. Використаний метод виконання — wmiexec.

Техніка 3: NetExec WinRM із сертифікатом PFX

Третя техніка використовує протокол WinRM (порт 5985) для віддаленого виконання команд. WinRM (Windows Remote Management) — це реалізація протоколу WS-Management від Microsoft, яка зазвичай використовується для легітимного віддаленого адміністрування. Це робить атаки на основі WinRM особливо важкими для виявлення, оскільки вони зливаються зі звичайним адміністративним трафіком.

nxc winrm 192.168.1.11 --pfx-cert administrator.pfx -u administrator -x "systeminfo" --kdcHost 192.168.1.11

Вивід systeminfo розкриває вичерпні деталі про Контролер Домену: Windows Server 2019 Standard Evaluation (Build 17763), налаштований як Primary Domain Controller, працює на VMware з 2 процесорами, 2047 МБ оперативної пам’яті, часовий пояс UTC+05:30, та встановлено три оновлення (hotfixes) (KB4514366, KB4512577, KB4512578).

Техніка 4: NetExec MSSQL із сертифікатом PFX

Четверта техніка демонструє виконання команд через протокол MSSQL (порт 1433) на рядовому сервері (WIN-SQL на 192.168.1.13). Це важливо, оскільки показує, що один сертифікат адміністратора домену можна використовувати для виконання команд не лише на Контролері Домену, але й на будь-якій машині, приєднаній до домену, на якій запущені доступні служби.

nxc mssql 192.168.1.13 --pfx-cert administrator.pfx -u administrator -x "systeminfo"

Команда, виконана через mssqlexec, показує, що WIN-SQL є окремим рядовим сервером (не Контролером Домену) з 8191 МБ оперативної пам’яті, який працює на VMware та приєднаний до домену ignite.local. Метод виконання — mssqlexec, який використовує збережену процедуру xp_cmdshell для виконання команд ОС через екземпляр SQL Server.

Матриця порівняння інструментів

У наведеній нижче таблиці представлено всебічне порівняння всіх дев’яти технік, продемонстрованих у цій статті:

Виявлення та рекомендації щодо захисту

Можливості виявлення

Event ID 4768: Було надіслано запит на Kerberos TGT. Відстежуйте пре-автентифікацію PKINIT (на основі сертифіката) з незвичайних вихідних IP-адрес або хостів не на базі Windows.
Event ID 4769: Було надіслано запит на сервісний квиток Kerberos. Зіставляйте з 4768 для виявлення ланцюжків pass-the-ticket.
Event ID 4672: Новому входу призначено спеціальні привілеї. Сповіщає про видачу адміністративних токенів.
Event ID 7045: Було встановлено нову службу. Виявляє створення служб у стилі PsExec (служби з випадковими іменами).
Event ID 4688: Створення процесу. Відстежуйте запуск cmd.exe/powershell.exe дочірніми процесами wmiprvse.exe (WMI) або wsmprovhost.exe (WinRM).
Event ID 4698: Було створено заплановане завдання. Виявляє зловживання планувальником завдань у стилі AtExec.

Висновок

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

SYSTEM_HALTED

>