مثال عملی abuse: اول با Certify.exe templateها رو enumerate کن (مثل find /clientauth). بعد، گواهی با EKU خاص درخواست بده. برای Pass-the-Certificate، از Rubeus استفاده کن:    Rubeus.exe asktgt /user:target /certificate:cert.pfx /password:pass    این کار TGT می‌گیره و می‌تونی escalate کنی. - اگر نیاز به custom OID داشتی، تو لاب تست کن مثلاً برای شبیه‌سازی vulnها. در کل، درک EKU و OIDها کمک میکنه ببینی کجاها AD CS ضعیفه. اگر administratorها templateها رو درست harden نکنن (مثل محدود کردن enrollment rights یا اضافه کردن manager approval)، راه برای حمله بازه. پیشنهادم اینه که تو محیط تست امتحان کنی تا بهتر دستت بیاد. #ADCS @KavehAPT

- مثال عملی abuse: اول با Certify.exe templateها رو enumerate کن (مثل find /clientauth). بعد، گواهی با EKU خاص درخواست بده. برای Pass-the-Certificate، از Rubeus استفاده کن:    Rubeus.exe asktgt /user:target /certificate:cert.pfx /password:pass    این کار TGT می‌گیره و می‌تونی escalate کنی. - اگر نیاز به custom OID داشتی، تو لاب تست کن مثلاً برای شبیه‌سازی vulnها. در کل، درک EKU و OIDها کمک میکنه ببینی کجاها AD CS ضعیفه. اگر administratorها templateها رو درست harden نکنن (مثل محدود کردن enrollment rights یا اضافه کردن manager approval)، راه برای حمله بازه. پیشنهادم اینه که تو محیط تست امتحان کنی تا بهتر دستت بیاد. #ADCS @KavehAPT

⭕ مقدمه‌ای بر AD CS: گواهی های EKUها و OIDها سلام، اگر بخوایم در مورد Active Directory Certificate Services (AD CS) حرف بزنیم، یکی از بخش‌های کلیدیش گواهی‌های دیجیتال هستن که توشون چیزایی مثل Extended Key Usage (EKU) و Object Identifier (OID) نقش مهمی بازی میکنن. اینا اساساً کمک میکنن تا بفهمیم یک گواهی برای چی ساخته شده و چطور میتونه سوءاستفاده بشه، مخصوصاً تو سناریوهای red teaming یا تست نفوذ. من اینجا سعی می‌کنم این بخش رو با جزئیات بیشتری توضیح بدم، چون واقعاً کلیدیه برای درک چگونگی abuse کردن templateهای گواهی. EKU چیه؟ در واقع یک extension تو گواهی‌های X.509 هست که مشخص میکنه این گواهی دقیقاً برای چه هدفی میتونه استفاده بشه. بدون EKU، گواهی میتونه برای هر کاری استفاده بشه (که این خودش یک حفره امنیتی بزرگه)، اما با EKU، محدودیت‌هایی اعمال میشه. تو محیط AD CS، این EKUها میتونن توسط administratorها روی templateها تنظیم بشن، و اگر درست کانفیگ نشن، راه رو برای حمله باز می‌کنن. مثلاً تو حملات escalation privilege، مثل ESC1 تا ESC3 که تو گزارش‌های SpecterOps توضیح دادن، EKUهای خاصی مثل Client Authentication میتونن به مهاجم ها کمک کنن تا دسترسی بالاتری بگیرن. OID چیه؟ OIDها identifierهای منحصر به‌ فردی هستن که ساختار hierarchy دارن مثل یک درخت که هر شاخه‌ اش یک کد عددی داره. اینا توسط سازمان‌هایی مثل IANA یا Microsoft تعریف میشن و هر OID یک کاربرد خاص رو نشون میده. OIDها تو EKUها استفاده میشن تا دقیق‌تر بگن گواهی چیکار میتونه بکنه. مثلاً، OIDها مثل شماره سریال هستن که کمک میکنن سیستم‌ها بفهمن گواهی معتبره یا نه. اگر بخوای custom OID بسازی (مثل تو تست‌های vuln)، میتونی از ابزارهایی مثل Certify.exe استفاده کنی تا ببینی چطور کار میکنه. OIDهای رایج و کاربردهاشون (با تمرکز روی abuse) اینجا چند تا OID مهم رو لیست می‌کنم، همراه با توضیح اینکه چطور میتونن تو abuse templateها مفید باشن. اینا رو بر اساس تجربیات red teaming انتخاب کردم، چون اغلب تو حملات واقعی دیده شدن: - Server Authentication (OID: 1.3.6.1.5.5.7.3.1):    این برای SSL/TLS سرورها استفاده میشه، مثل وب‌سرورها. تو abuse، اگر templateی داشته باشی که این EKU رو اجازه بده و enrollment rights داشته باشی، میتونی گواهی جعلی بسازی برای impersonation سرورها. ولی معمولاً کمتر برای escalation استفاده میشه. - Client Authentication (OID: 1.3.6.1.5.5.7.3.2):    این یکی برای احراز هویت کلاینت‌ها طراحی شده، مثلاً تو PKINIT برای گرفتن Kerberos TGT. کلیدیه برای abuse! اگر templateی با این EKU داشته باشی و enrollment داشته باشی، میتونی privilege escalate کنی. مثلاً تو آموزش‌های red team، می‌گن: template با Client Auth + enrollment rights = escalation path. برای enumerate کردنش، از Certify.exe find /clientauth استفاده کن. اگر نیاز به تست vuln داشتی، custom OID بساز و امتحان کن. - Code Signing (OID: 1.3.6.1.5.5.7.3.3):    برای امضای کد، که میتونه Windows Defender Application Control (WDAC) رو bypass کنه. تو abuse، اگر بتونی گواهی با این EKU بگیری، کد مخربت رو امضا میکنی و سیستم فکر میکنه معتبره. - Secure Email (OID: 1.3.6.1.5.5.7.3.4):    برای رمزنگاری و امضای ایمیل‌ها (SMIME). کمتر abuse میشه، اما اگر template vuln باشه، میتونی برای spoofing ایمیل استفاده کنی. - Encrypting File System (EFS) (OID: 1.3.6.1.4.1.311.10.3.4):    برای رمزنگاری فایل‌ها تو ویندوز. تو سناریوهای خاص، می‌ تونی ازش برای دسترسی به فایل‌ های encrypt‌شده سوءاستفاده کنی. - Any Purpose (OID: 2.5.29.37.0):    این یکی همه‌کاره‌ست و هیچ محدودیتی نداره – دقیقاً مثل نداشتن EKU. vulnerable به حملاتی مثل ESC2، چون میتونی گواهی رو برای هر کاری استفاده کنی، از authentication گرفته تا signing. - Certificate Request Agent (OID: 1.3.6.1.4.1.311.20.2.1):    این برای on-behalf-of enrollment استفاده میشه، که تو ESC3 کلیدیه. اگر template این EKU رو داشته باشه، attacker میتونه گواهی برای کاربر دیگه درخواست کنه و privilege بگیره. نکته‌های کلیدی برای abuse در red teaming - No EKU = Any Purpose: اگر گواهی EKU نداشته باشه، مثل Any Purpose عمل می‌کنه عالی برای ESC2، چون محدودیت نداره و میتونی باهاش هر کاری کنی. #ADCS @KavehAPT

- مثال عملی abuse: اول با Certify.exe templateها رو enumerate کن (مثل find /clientauth). بعد، گواهی با EKU خاص درخواست بده. برای Pass-the-Certificate، از Rubeus استفاده کن: Rubeus.exe asktgt /user:target /certificate:cert.pfx /password:pass این کار TGT می‌گیره و می‌تونی escalate کنی. - اگر نیاز به custom OID داشتی، تو لاب تست کن مثلاً برای شبیه‌سازی vulnها. در کل، درک EKU و OIDها کمک میکنه ببینی کجاها AD CS ضعیفه. اگر administratorها templateها رو درست harden نکنن (مثل محدود کردن enrollment rights یا اضافه کردن manager approval)، راه برای حمله بازه. پیشنهادم اینه که تو محیط تست امتحان کنی تا بهتر دستت بیاد. #ADCS @KavehAPT

⭕ مقدمه‌ای بر AD CS: گواهی های EKUها و OIDها سلام، اگر بخوایم در مورد Active Directory Certificate Services (AD CS) حرف بزنیم، یکی از بخش‌های کلیدیش گواهی‌های دیجیتال هستن که توشون چیزایی مثل Extended Key Usage (EKU) و Object Identifier (OID) نقش مهمی بازی میکنن. اینا اساساً کمک میکنن تا بفهمیم یک گواهی برای چی ساخته شده و چطور میتونه سوءاستفاده بشه، مخصوصاً تو سناریوهای red teaming یا تست نفوذ. من اینجا سعی می‌کنم این بخش رو با جزئیات بیشتری توضیح بدم، چون واقعاً کلیدیه برای درک چگونگی abuse کردن templateهای گواهی. EKU چیه؟ در واقع یک extension تو گواهی‌های X.509 هست که مشخص میکنه این گواهی دقیقاً برای چه هدفی میتونه استفاده بشه. بدون EKU، گواهی میتونه برای هر کاری استفاده بشه (که این خودش یک حفره امنیتی بزرگه)، اما با EKU، محدودیت‌هایی اعمال میشه. تو محیط AD CS، این EKUها میتونن توسط administratorها روی templateها تنظیم بشن، و اگر درست کانفیگ نشن، راه رو برای حمله باز می‌کنن. مثلاً تو حملات escalation privilege، مثل ESC1 تا ESC3 که تو گزارش‌های SpecterOps توضیح دادن، EKUهای خاصی مثل Client Authentication میتونن به مهاجم ها کمک کنن تا دسترسی بالاتری بگیرن. OID چیه؟ OIDها identifierهای منحصر به‌ فردی هستن که ساختار hierarchy دارن مثل یک درخت که هر شاخه‌ اش یک کد عددی داره. اینا توسط سازمان‌هایی مثل IANA یا Microsoft تعریف میشن و هر OID یک کاربرد خاص رو نشون میده. OIDها تو EKUها استفاده میشن تا دقیق‌تر بگن گواهی چیکار میتونه بکنه. مثلاً، OIDها مثل شماره سریال هستن که کمک میکنن سیستم‌ها بفهمن گواهی معتبره یا نه. اگر بخوای custom OID بسازی (مثل تو تست‌های vuln)، میتونی از ابزارهایی مثل Certify.exe استفاده کنی تا ببینی چطور کار میکنه. OIDهای رایج و کاربردهاشون (با تمرکز روی abuse) اینجا چند تا OID مهم رو لیست می‌کنم، همراه با توضیح اینکه چطور میتونن تو abuse templateها مفید باشن. اینا رو بر اساس تجربیات red teaming انتخاب کردم، چون اغلب تو حملات واقعی دیده شدن: - Server Authentication (OID: 1.3.6.1.5.5.7.3.1): این برای SSL/TLS سرورها استفاده میشه، مثل وب‌سرورها. تو abuse، اگر templateی داشته باشی که این EKU رو اجازه بده و enrollment rights داشته باشی، میتونی گواهی جعلی بسازی برای impersonation سرورها. ولی معمولاً کمتر برای escalation استفاده میشه. - Client Authentication (OID: 1.3.6.1.5.5.7.3.2): این یکی برای احراز هویت کلاینت‌ها طراحی شده، مثلاً تو PKINIT برای گرفتن Kerberos TGT. کلیدیه برای abuse! اگر templateی با این EKU داشته باشی و enrollment داشته باشی، میتونی privilege escalate کنی. مثلاً تو آموزش‌های red team، می‌گن: template با Client Auth + enrollment rights = escalation path. برای enumerate کردنش، از Certify.exe find /clientauth استفاده کن. اگر نیاز به تست vuln داشتی، custom OID بساز و امتحان کن. - Code Signing (OID: 1.3.6.1.5.5.7.3.3): برای امضای کد، که میتونه Windows Defender Application Control (WDAC) رو bypass کنه. تو abuse، اگر بتونی گواهی با این EKU بگیری، کد مخربت رو امضا میکنی و سیستم فکر میکنه معتبره. - Secure Email (OID: 1.3.6.1.5.5.7.3.4): برای رمزنگاری و امضای ایمیل‌ها (SMIME). کمتر abuse میشه، اما اگر template vuln باشه، میتونی برای spoofing ایمیل استفاده کنی. - Encrypting File System (EFS) (OID: 1.3.6.1.4.1.311.10.3.4): برای رمزنگاری فایل‌ها تو ویندوز. تو سناریوهای خاص، می‌ تونی ازش برای دسترسی به فایل‌ های encrypt‌شده سوءاستفاده کنی. - Any Purpose (OID: 2.5.29.37.0): این یکی همه‌کاره‌ست و هیچ محدودیتی نداره – دقیقاً مثل نداشتن EKU. vulnerable به حملاتی مثل ESC2، چون میتونی گواهی رو برای هر کاری استفاده کنی، از authentication گرفته تا signing. - Certificate Request Agent (OID: 1.3.6.1.4.1.311.20.2.1): این برای on-behalf-of enrollment استفاده میشه، که تو ESC3 کلیدیه. اگر template این EKU رو داشته باشه، attacker میتونه گواهی برای کاربر دیگه درخواست کنه و privilege بگیره. نکته‌های کلیدی برای abuse در red teaming - No EKU = Any Purpose: اگر گواهی EKU نداشته باشه، مثل Any Purpose عمل می‌کنه عالی برای ESC2، چون محدودیت نداره و میتونی باهاش هر کاری کنی.

https://github.com/TryHackBox/Kaveh-WebDiff-Monitor توضیحات ابزار : این ابزار یک مانیتورینگ تغییرات و وضعیت HTTP است که برای بررسی سلامت سرویس‌های وب، مانیتورینگ Virtual Hostها و شناسایی تغییرات محتوا استفاده می‌شود. با استفاده از این اسکریپت می‌توانید چندین IP/Port/Schema/Vhost را به صورت دوره‌ای بررسی کنید و در صورت تغییر وضعیت پاسخ یا تغییر در محتوای صفحه، هشدار دریافت کنید. اگر فکر میکنید ویژیگی این ابزار بهتر میکنه پیشنهاد بدید اضافه کنم میتونید در گفتگوی مستقیم پیشنهاد بدید یا توییتر . @KavehAPT

https://twitter.com/KavehxNet/status/1956458306035482921?s=19 امیدوارم از این ابزاری که نوشتم خوشتون بیاد ...

https://twitter.com/KavehxNet/status/1956458306035482921?s=19 امیدوارم از این ابزاری که نوشتم خوشتون بیاد ...

در راستای کمک به دوستان علاقه‌مند به تحلیل شبکه و استفاده از ابزار Wireshark، یک فایل آموزشی به زبان فارسی تحت عنوان «Wireshark برای Red Teamers» را درحال ترجمه کردنش هستم. این فایل شامل مباحث پایه‌ای تا پیشرفته در استفاده از Wireshark برای ردیابی، تحلیل و دستکاری ترافیک شبکه از دیدگاه Red Team است و می‌تواند منبع بسیار مفیدی برای همه علاقه‌مندان به امنیت شبکه و ردتیم باشد. جهت حمایت از ادامه کار و تکمیل ترجمه بخش‌های باقی‌مانده، چند صفحه اول این فایل را رایگان قرار داده‌ام. در صورت تمایل به دریافت نسخه کامل فایل، خواهشمند است یک دونیت نمادین انجام دهید. با دونیت شما، می‌توانم بخش‌های بعدی را نیز تکمیل و در اختیار دوستان قرار دهم. لینک دونیت 🙏 سپاس فراوان از حمایت شما!

⭕ مقدمه‌ای بر AD CS – ویژگی‌های گواهینامه (Certificate Attributes) در این بخش به بررسی چند ویژگی مهم و کاربردی گواهینامه‌ها در Active Directory Certificate Services می‌پردازیم. این ویژگی‌ها هم در کارهای عادی و هم در عملیات تیم قرمز می‌توانند نکات جالبی داشته باشند. ویژگی‌های اصلی گواهی Subject موجودیت دریافت‌کننده گواهی. مثال:   CN=user@domain.com Issuer صادرکننده گواهی، که معمولاً یک CA داخلی یا سازمانی است. Subject Alternative Name (SAN) نام‌های جایگزین که می‌تواند شامل DNS، آدرس IP یا ایمیل باشد. Validity Period بازه زمانی اعتبار گواهی (تاریخ شروع و پایان). Extended Key Usage (EKU) تعیین هدف یا سناریوی استفاده از گواهی (جزئیاتش در بخش‌های بعدی گفته می‌شود). نکات عملیاتی برای تیم قرمز SAN قابل تغییر (SAN Modifiable) اگر قالب صدور گواهی (Certificate Template) به شما اجازه ویرایش SAN بدهد، می‌توان از این قابلیت برای Impersonation استفاده کرد. سناریوی کلاسیک: اضافه کردن altname=admin به گواهی درخواست شده. مثال:

  Certify.exe request /ca:CA_NAME /template:User /altname:admin
  

بررسی دوره اعتبار (Validity) تاریخ اعتبار را زیر نظر داشته باشید تا پیش از انقضا گواهی را تمدید کنید وPersistence ایجاد شود. Evasion استفاده از پارامتر /sidextension برای دور زدن برخی پچ‌های CBA. 💡 نکته: اگر قالب گواهی در بخش SAN آسیب‌پذیر باشد، این می‌ تواند یک مسیر مستقیم به سمت Domain Escalation باشد. #ADCS @KavehAPT

⭕ مقدمه‌ای بر AD CS – ویژگی‌های گواهینامه (Certificate Attributes) در این بخش به بررسی چند ویژگی مهم و کاربردی گواهینامه‌ها در Active Directory Certificate Services می‌پردازیم. این ویژگی‌ها هم در کارهای عادی و هم در عملیات تیم قرمز می‌توانند نکات جالبی داشته باشند. ویژگی‌های اصلی گواهی Subject موجودیت دریافت‌کننده گواهی. مثال: CN=user@domain.com Issuer صادرکننده گواهی، که معمولاً یک CA داخلی یا سازمانی است. Subject Alternative Name (SAN) نام‌های جایگزین که می‌تواند شامل DNS، آدرس IP یا ایمیل باشد. Validity Period بازه زمانی اعتبار گواهی (تاریخ شروع و پایان). Extended Key Usage (EKU) تعیین هدف یا سناریوی استفاده از گواهی (جزئیاتش در بخش‌های بعدی گفته می‌شود). نکات عملیاتی برای تیم قرمز SAN قابل تغییر (SAN Modifiable) اگر قالب صدور گواهی (Certificate Template) به شما اجازه ویرایش SAN بدهد، می‌توان از این قابلیت برای Impersonation استفاده کرد. سناریوی کلاسیک: اضافه کردن altname=admin به گواهی درخواست شده. مثال:

  Certify.exe request /ca:CA_NAME /template:User /altname:admin
  

بررسی دوره اعتبار (Validity) تاریخ اعتبار را زیر نظر داشته باشید تا پیش از انقضا گواهی را تمدید کنید وPersistence ایجاد شود. Evasion استفاده از پارامتر /sidextension برای دور زدن برخی پچ‌های CBA. 💡 نکته: اگر قالب گواهی در بخش SAN آسیب‌پذیر باشد، این می‌ تواند یک مسیر مستقیم به سمت Domain Escalation باشد. #ADCS @KavehAPT

مقدمه ای بر AD CS – ویژگی های گواهینامه ( Attributes ) این بخش ویژگی‌های جالب گواهی‌ ها رو معرفی میکنه. مقدمه ویژگی‌ها شامل:   - Subject: موجودی گیرنده (مثل CN=user@domain.com).   - Issuer: صادرکننده (CA).   - Subject Alternative Name (SAN): نام‌های جایگزین (DNS، IP، email).   - Validity Period: مدت اعتبار (start/end date).   - Extended Key Usage (EKU): هدف استفاده (بعداً جزئیات). - آموزش ردتیم: SAN modifiable رو abuse کن برای impersonation (ESC1: altname=admin بذار). validity رو چک کن برای persistence (renew قبل expire). مثال: گواهی request کن با custom SAN:   

    Certify.exe request /ca:CA_NAME /template:User /altname:admin

        evasion: از /sidextension برای بایپس CBA patch استفاده کن. نکته: اگر SAN vulnerable باشه، مستقیم به domain escalation برو. @KavehAPT

مقدمه ای بر AD CS – ویژگی های گواهینامه ( Attributes ) این بخش ویژگی‌های جالب گواهی‌ ها رو معرفی میکنه. مقدمه ویژگی‌ها شامل:   - Subject: موجودی گیرنده (مثل CN=user@domain.com).   - Issuer: صادرکننده (CA).   - Subject Alternative Name (SAN): نام‌های جایگزین (DNS، IP، email).   - Validity Period: مدت اعتبار (start/end date).   - Extended Key Usage (EKU): هدف استفاده (بعداً جزئیات). - آموزش ردتیم: SAN modifiable رو abuse کن برای impersonation (ESC1: altname=admin بذار). validity رو چک کن برای persistence (renew قبل expire). مثال: گواهی request کن با custom SAN:        Certify.exe request /ca:CA_NAME /template:User /altname:admin         evasion: از /sidextension برای بایپس CBA patch استفاده کن. نکته: اگر SAN vulnerable باشه، مستقیم به domain escalation برو. @KavehAPT

دوستان به وقتش به بررسی حملات APT میرسیم تا اون موقع یکسری مطالب میزارم که با مباحث و مفاهیم اشنا شید و بعد بریم سراغ فریم ورک mitre و دنیای APT هکرها .

⭕ مقدمه ای بر AD CS – فرمت های گواهینامه یا Certificate اینجا در مورد فرمت‌های رایج گواهی‌ها یا سرتیفیکیت حرف می‌زنیم. دونستن این فرمت‌ها خیلی مهمه، چون برای سرقت یا خروجی گرفتن ازشون لازمه بدونیم چطور کار میکنن. بیایم از پایه شروع کنیم: AD CS از استاندارد X.509 استفاده میکنه. حالا فرمت‌های اصلیشون اینان: - PEM: این یکی DER رو به صورت Base64 انکود کرده. پسوندهای رایجش .pem، .crt، .cer، .key هستن. معمولاً شامل گواهی (سرتیفیکیت)به علاوه کلید خصوصی بدون هیچ حفاظتی میشه. بیشتر تو لینوکس یا وب‌ سرورها می‌بینیش. - DER: نسخه باینری PEM هست، ساده و مستقیم برای ماشین‌ ها. - PFX یا P12 (که همون PKCS#12 هست): این باینریه و با پسورد حفاظت میشه. داخلش گواهی و کلید خصوصی رو نگه میداره. عالیه برای خروجی گرفتن تو ویندوز. - P7B (PKCS#7): فقط زنجیره گواهی‌ها رو داره، بدون کلید خصوصی. حالا برای تیم قرمز: گواهی‌ها رو روی دیسک جستجو کن (مثل THEFT4) با این اکستنشن‌ها. مثلاً با پاورشل اینطوری:

Get-ChildItem C:\ -include ('*.pem', '*.pfx', '*.p12', '*.crt', '*.cer', '*.key') -recurse -ErrorAction SilentlyContinue

اگه PFX پیدا کردی، با CertUtil خروجی بگیر و اگه بدون حفاظت بود، پسوردش رو بروت فورس کن. ابزار Seatbelt هم خوبه برای اتومات کردن جستجو. نکته مهم: از PEM یا PEM بدون حفاظت برای سوءاستفاده کراس‌ پلتفرم استفاده کن . #ADCS @KavehAPT

سوالات شما من سوالی را که در توییتر مطرح شد دوست داشتم، مفهوم آن این بود: «در کدام مرحله تیم رد تیم به راحتی شناسایی می‌شود؟» یکی از وظایف تیم مهاجم این است که اجازه دهد تیم دفاعی آن‌ها را شناسایی کند. انجام یک اشتباه آگاهانه، گذاشتن IOC، اجرای برنامه یا دستوراتی که باید محرک شروع یک حادثه باشند. اما انجام این اقدامات توسط تیم مهاجم در مرحله پایانی خواهد بود، زمانی که فقط هدف عملیات باقی مانده است. اگر تیم مهاجم خیلی زود شناسایی شود، ممکن است بر ادامه عملیات تأثیر منفی بگذارد. همه چیز به توافقات اجرای پروژه بستگی دارد. برگردیم به سوال. به نظر من سخت‌ترین و خطرناک‌ترین مراحل، مراحل دسترسی اولیه هستند: آگاهی موقعیتی و تثبیت. در مرحله ابتدایی دسترسی به شبکه داخلی، تیم مهاجم باید بسیار محتاط و دقیق باشد. اعضای تیم هنوز نمی‌دانند چه مکانیزم‌های دفاعی استفاده می‌شود و چگونه تنظیم شده‌اند. هنگام انجام آگاهی موقعیتی ممکن است عملی انجام شود که هشدار ایجاد کند. به عنوان مثال، دستور whoami که مورد علاقه پنتسترها است اما کاربران عادی هرگز از آن استفاده نمی‌کنند. پس از دسترسی به شبکه داخلی، تیم مهاجم باید تثبیت کند و پایگاهی برای پیشروی به هدف عملیات بسازد. انتخاب نادرست مکانیزم تثبیت نیز می‌تواند هشدار ایجاد کند. اما به محض اینکه اعضای رد تیم در شبکه جا بیفتند، می‌توانند با جسارت بیشتری عمل کنند و گاهی حتی جسورانه. در کتاب ناشناس بودن برای ردتیمر ها میخوانید که چطور از شناسایی شدن جلو گیری کنید . #FAQ #RedTeam @KavehAPT

⭕ مقدمه‌ای بر AD CS – اجزاء کلیدی حالا که توی پست قبل یه مقدمه کلی از AD CS دادیم بیایم سراغ اجزای اصلیش بریم. این سرویس واقعاً پیچیده‌ ست و اجزاش با هم هماهنگ کار میکنن تا گواهی‌ ها رو صادر، مدیریت و توزیع کنن. هر کدوم از این اجزا رو میشه بررسی کرد و حتی از زاویه ردتیم بهشون نگاه کرد که چطور میتونن نقطه ضعف باشن. من سعی کردم هر بخش رو ساده توضیح بدم و بعد abuse احتمالیش رو بگم. نگاه کلی  AD CS :  از چند کامپوننت اصلی تشکیل شده که با همدیگه enrollment (ثبت‌نام برای گواهی)، issuance (صدور گواهی) و مدیریت گواهی‌ ها رو هندل میکنن. این اجزا معمولاً روی سرور ویندوز نصب میشن و با اکتیو دایرکتوری یکپارچه هستن. بدون این‌ها، PKI کار نمیکنه. اجزای کلیدی AD CS اینجا لیست‌شون کردم با توضیح مختصر و نکات ردتیم: - Certification Authority (CA): این قلب تپنده AD CS هست. گواهی‌ها رو صادر، revoke و مدیریت می‌کنه بر اساس templateها. میتونه Root CA (ریشه، که خودش رو امضا میکنه) یا Subordinate CA (زیرمجموعه، که از root امضا می‌گیره) باشه. برای فعال کردنش باید نقش AD CS رو روی سرور نصب کنی.   - دیدگاه ردتیم و آموزش: اگر بتونی CA رو compromise کنی (مثل حمله ESC5)، می‌تونی golden certificate forge کنی و persistence بسازی (DPERSIST1). برای enumerate، از ابزار Certify.exe cas استفاده کن تا لیست CAها و تنظیماتشون رو بگیری. - Certificate Template: این‌ ها مثل blueprint هستن برای گواهی‌ ها. مجوزهای enrollment، EKUها (Extended Key Usages مثل Client Auth)، تاریخ انقضا و چیزای دیگه رو تعریف می‌کنن.   - دیدگاه ردتیم و آموزش: templateهای vulnerable رو پیدا کن که اجازه enrollment بدون مجوز درست بدن (مثل ESC1). با Certify.exe find می‌تونی لیست templateها رو بگیری و misconfigها رو چک کنی مثلاً اگر EKU خطرناکی داشته باشن. - Certificate Enrollment Web Service (CES): این سرویس enrollment رو از طریق HTTPS برای کاربران و کامپیوترها فراهم میکنه، بدون نیاز به دسترسی مستقیم به CA.   - دیدگاه ردتیم و آموزش: اگر روی HTTP باشه، vulnerable به NTLM relay attack هست (ESC8). می‌تونی authentication رو coerce کنی با ابزار Coercer و بعد relay کنی با ntlmrelayx تا گواهی بگیری. - Certificate Enrollment Policy Web Service: این یکی policyهای enrollment رو به کلاینت‌ها میده تا بدونن چطور ثبت‌ نام کنن.   - (این بخش کمتر abuse داره، اما بخشی از زنجیره enrollment هست.) - CA Web Enrollment: رابط وب برای enrollment گواهی‌ ها، مخصوصاً برای دستگاه‌های non-domain یا خارج از شبکه.   - دیدگاه ردتیم و آموزش: اگر وب‌ باز باشه، scan کن برای vulnهایی مثل relay attacks یا injection. همیشه چک کن HTTPS باشه یا نه. - Network Device Enrollment Service (NDES): برای دستگاه‌های شبکه مثل روترها یا چیزایی که offline هستن (مثل پیاده سازی با Intune). از پروتکل SCEP استفاده میکنه.   - دیدگاه‌ ردتیم و آموزش: templateهای offline vulnerable به سرقت (THEFT4) یا bypass پچ‌های CBA (Certificate-Based Authentication). اگر NDES فعال باشه، می‌تونی گواهی‌ های دستگاه رو abuse کنی. جمع بندی از دید تیم قرمز، اول باید این اجزا رو enumerate کنی تا attack surface رو پیدا کنی. مثلاً اگر CES فعال باشه، حتماً relay attack تست کن میتونه در رو باز کنه بدون نیاز به privilege بالا. برای evasion، از winrs (Windows Remote Shell) استفاده کن تا دسترسی بگیری بدون اینکه logging سنگینی بشه. ابزارهایی مثل Certify رو فراموش نکن، چون سریع misconfigها رو نشون میدن. در نهایت، AD CS پر از جزئیاته و هر اجزاش میتونه نقطه ورود باشه. #ADCS @KavehAPT