⭕ یادداشت‌ های اکسپلویت از تست نفوذ Active Directory - بخش اول دوستان من این مورد قبلا خونده بودم گفتم مطالب با شما هم به اشتراک بگذارم شاید براتون مفید باشه . اکتیودایرکتوری (AD) یک سرویس دایرکتوری است که توسط مایکروسافت برای شبکه‌ های دامنه ویندوز توسعه پیدا کرده است. شمارش یا Enumeration کشف یا Discovery کنترل‌ کننده‌های دامنه (Domain Controllers Discovery)

dig @<target-ip> example.local ANY
gobuster dns -d example.local -w subdomains.txt -t 25

شمارش با BloodHound 1. اجرای BloodHound  ما از BloodHound Community Edition استفاده میکنیم. دستور زیر Docker Compose BloodHound را شروع می‌ کند:   

curl -L https://ghst.ly/getbhce > docker-compose.yml
sudo docker-compose down -v # If you want to reset the password of BloodHound...
sudo docker-compose pull && sudo docker-compose up

    پس از آن، میتوانیم از رابط یا اینترفیس وب با دسترسی به localhost:8080 در مرورگر وب استفاده کنیم. با نام کاربری admin و رمز عبوری که در لاگ هنگام اجرای دستور بالا نمایش داده می‌شود، وارد شوید.  برای مشخص کردن IP و پورت دلخواه، متغیرهای محیطی را روی ماشین اتکر تنظیم کنید:  

  export BLOODHOUND_HOST=10.0.0.1
   export BLOODHOUND_PORT=8090

2. جمع‌ آوری داده‌ ها (Collect Data) گزینه 1. استفاده از NetExec اگر NetExec را در ماشین خود دارید، فکر میکنم ساده‌ ترین راه باشد.  

  netexec ldap <target-ip> -d example.local -u username -p password --dns-server <target-ip> --bloodhound -c All

      گزینه 2. استفاده از BloodHound.py ما همچنین میتوانیم از BloodHound.py استفاده کنیم. آن را به صورت زیر نصب کنید:  

python3 -m venv .venv
source .venv/bin/activate
pipx install bloodhound # or using 'pip3' instead of 'pipx'
bloodhound-python -h

   سپس داده‌ ها را جمع‌آوری کنید:     

   # -u: Username
   # -p: Password
   # -dc: Domain Controller
   # -c all: Collect all data
   # -ns: Alternate the nameserver
   bloodhound-python -d example.local -u username -p password -dc dc.example.local -c all -ns ns.example.local

   # If we cannot resolve the domain, try dnschef (https://github.com/iphelix/dnschef) to create a fake DNS by proxy.
   sudo python3 dnschef.py --fakeip <target-ip> --nameserver <target-ip>
   

#NoteADExploit @KavehAPT

⭕ یادداشت‌ های اکسپلویت از تست نفوذ Active Directory - بخش اول دوستان من این مورد قبلا خونده بودم گفتم مطالب با شما هم به اشتراک بگذارم شاید براتون مفید باشه . اکتیودایرکتوری (AD) یک سرویس دایرکتوری است که توسط مایکروسافت برای شبکه‌ های دامنه ویندوز توسعه پیدا کرده است. شمارش یا Enumeration کشف یا Discovery کنترل‌ کننده‌های دامنه (Domain Controllers Discovery)

gobuster dns -d example.local -w subdomains.txt -t 25

شمارش با BloodHound 1. اجرای BloodHound  ما از BloodHound Community Edition استفاده میکنیم. دستور زیر Docker Compose BloodHound را شروع می‌ کند:        

   sudo docker-compose pull && sudo docker-compose up
   

 پس از آن، میتوانیم از رابط یا اینترفیس وب با دسترسی به localhost:8080 در مرورگر وب استفاده کنیم. با نام کاربری admin و رمز عبوری که در لاگ هنگام اجرای دستور بالا نمایش داده می‌شود، وارد شوید.  برای مشخص کردن IP و پورت دلخواه، متغیرهای محیطی را روی ماشین اتکر تنظیم کنید:  

  export BLOODHOUND_HOST=10.0.0.1
   export BLOODHOUND_PORT=8090

2. جمع‌ آوری داده‌ ها (Collect Data) گزینه 1. استفاده از NetExec اگر NetExec را در ماشین خود دارید، فکر میکنم ساده‌ ترین راه باشد.            گزینه 2. استفاده از BloodHound.py ما همچنین میتوانیم از BloodHound.py استفاده کنیم. آن را به صورت زیر نصب کنید:     

   source .venv/bin/activate
   pipx install bloodhound # or using 'pip3' instead of 'pipx'
   bloodhound-python -h
   

   سپس داده‌ ها را جمع‌آوری کنید:     

   # -u: Username
   # -p: Password
   # -dc: Domain Controller
   # -c all: Collect all data
   # -ns: Alternate the nameserver
   bloodhound-python -d example.local -u username -p password -dc dc.example.local -c all -ns ns.example.local

   # If we cannot resolve the domain, try dnschef (https://github.com/iphelix/dnschef) to create a fake DNS by proxy.
   sudo python3 dnschef.py --fakeip <target-ip> --nameserver <target-ip>
   

#NoteADExploit @KavehAPT

⭕ یادداشت‌ های اکسپلویت از تست نفوذ Active Directory - بخش اول دوستان من این مورد قبلا خونده بودم گفتم مطالب با شما هم به اشتراک بگذارم شاید براتون مفید باشه . اکتیودایرکتوری (AD) یک سرویس دایرکتوری است که توسط مایکروسافت برای شبکه‌ های دامنه ویندوز توسعه پیدا کرده است. شمارش یا Enumeration کشف یا Discovery کنترل‌ کننده‌های دامنه (Domain Controllers Discovery)

gobuster dns -d example.local -w subdomains.txt -t 25

شمارش با BloodHound 1. اجرای BloodHound  ما از BloodHound Community Edition استفاده میکنیم. دستور زیر Docker Compose BloodHound را شروع می‌ کند:        

   sudo docker-compose pull && sudo docker-compose up

    پس از آن، میتوانیم از رابط یا اینترفیس وب با دسترسی به localhost:8080 در مرورگر وب استفاده کنیم. با نام کاربری admin و رمز عبوری که در لاگ هنگام اجرای دستور بالا نمایش داده می‌شود، وارد شوید.  برای مشخص کردن IP و پورت دلخواه، متغیرهای محیطی را روی ماشین اتکر تنظیم کنید:     

   export BLOODHOUND_PORT=8090

2. جمع‌ آوری داده‌ ها (Collect Data) گزینه 1. استفاده از NetExec اگر NetExec را در ماشین خود دارید، فکر میکنم ساده‌ترین راه باشد.            گزینه 2. استفاده از BloodHound.py ما همچنین میتوانیم از BloodHound.py استفاده کنیم. آن را به صورت زیر نصب کنید:     

   source .venv/bin/activate
   pipx install bloodhound # or using 'pip3' instead of 'pipx'
   bloodhound-python -h

      سپس داده‌ ها را جمع‌آوری کنید:     

   # -u: Username
   # -p: Password
   # -dc: Domain Controller
   # -c all: Collect all data
   # -ns: Alternate the nameserver
   bloodhound-python -d example.local -u username -p password -dc dc.example.local -c all -ns ns.example.local

   # If we cannot resolve the domain, try dnschef (https://github.com/iphelix/dnschef) to create a fake DNS by proxy.
   sudo python3 dnschef.py --fakeip <target-ip> --nameserver <target-ip>

   #NoteADExploit @KavehAPT

دامنه صوری (Domain Fronting) چیست؟ Domain Fronting تکنیکی است که در آن دامنه‌ای که در SNI (Server Name Indication) TLS درخواست می‌ شود که برای شبکه قابل مشاهده است با دامنه‌ای که در هدر HTTP Host استفاده می‌ شود که تا پس از انجام handshake رمزگذاری‌شده قابل مشاهده نیست متفاوت است. این روش باعث می ‌شود ترافیک به نظر برسد که به دامنه‌ای قانونی یا پرطرفدار (مثلاً cdn.cloudflare.net) هدایت می‌ شود، در حالی که در واقع به یک دامنه C2 مخفی پشت CDN مسیر‌دهی می ‌شود. @KavehAPT

در موضوع Active Directory دو گروه داخلی وجود دارند: Key Admins و Enterprise Key Admins . اعضای این گروه‌ها حق تغییر ویژگی ms-DS-Key-Credential-Link برای ابجکت های computer را دارند، که امکان اجرای حمله Shadow Credentials را فراهم می‌کند.

📖 وایرشارک برای ردتیمرها: از پایه تا پیشرفته 📚 عنوان کتاب: وایرشارک برای ردتیمرها (Wireshark for Red Teamers)  این کتاب یک راهنمای جامع و عملی برای یادگیری ابزار قدرتمند Wireshark است، با تمرکز ویژه روی کاربردهای آن در حوزه Red Teaming (تیم قرمز) و امنیت سایبری تهاجمی. کتاب از پایه شروع می‌ کند و به مفاهیم پیشرفته مانند تحلیل ترافیک شبکه، شناسایی آسیب‌پذیری‌ها، و تکنیک‌های نفوذ می‌ پردازد. محتوای اصلی کتاب شامل فصل‌هایی مانند معرفی Wireshark، درک ترافیک شبکه، تکنیک‌های کپچرینگ پکت‌ها، فیلترینگ، و کاربردهای عملی در Reconnaissance (شناسایی) و Command and Control (C2) است. این کتاب مناسب چه کسانی است؟ ویژگی‌ های کتاب ؟ چرا باید این کتاب را بخرید؟ دانلود فایل های تمرین و سناریوها توضیحات کامل را بخوانید . 💰 قیمت : ۲۵۰,۰۰۰ تومان 💢 ۱۰ نفر اول میتوانند این کتاب را با قیمت ۲۰۰,۰۰۰ تومان تهیه کنند . 📌 جهت خرید و کسب اطلاعات بیشتر، به ایدی زیر پیام دهید: @THBxSupport

📖 وایرشارک برای ردتیمرها: از پایه تا پیشرفته 📚 عنوان کتاب: وایرشارک برای ردتیمرها (Wireshark for Red Teamers)  این کتاب یک راهنمای جامع و عملی برای یادگیری ابزار قدرتمند Wireshark است، با تمرکز ویژه روی کاربردهای آن در حوزه Red Teaming (تیم قرمز) و امنیت سایبری تهاجمی. کتاب از پایه شروع می‌ کند و به مفاهیم پیشرفته مانند تحلیل ترافیک شبکه، شناسایی آسیب‌پذیری‌ها، و تکنیک‌های نفوذ می‌ پردازد. محتوای اصلی کتاب شامل فصل‌هایی مانند معرفی Wireshark، درک ترافیک شبکه، تکنیک‌های کپچرینگ پکت‌ها، فیلترینگ، و کاربردهای عملی در Reconnaissance (شناسایی) و Command and Control (C2) است. این کتاب مناسب چه کسانی است؟ ویژگی‌ های کتاب ؟ چرا باید این کتاب را بخرید؟ دانلود فایل های تمرین و سناریوها توضیحات کامل را بخوانید . 💰 قیمت : ۲۵۰,۰۰۰ تومان 📌 جهت خرید و کسب اطلاعات بیشتر، به ایدی زیر پیام دهید: @THBxSupport

ما در حال راه‌اندازی یک تیم امنیتی هستیم شرکتی پیشرو در مشاوره امنیت سایبری، عملیات ردتیم ، تست نفوذ  و تولید محتوای آموزشی پیشرفته. هدف ما، ارائه خدمات مشاوره‌ای، آموزش‌های عملی در زمینه تست نفوذ و ایجاد محتوای جذاب برای جامعه امنیت سایبری است. اگر علاقه‌مند به پیوستن به یک تیم پویا هستید که بر روی حفاظت از دارایی‌های دیجیتال تمرکز دارد، این فرصت را از دست ندهید! موقعیت‌های مورد نیاز: 1. مدرسین حوزه تست نفوذ وب و شبکه 2. ادمین‌های تولید محتوا (چند نفر، با تمرکز بر اینستاگرام و تلگرام ): 3. عضویت در تیم به عنوان ضبط پادکست‌ها و برگزاری لایو 4. عضویت در تیم به عنوان توسعه ابزار های امنیتی چرا به ما بپیوندید؟ - فرصت کار در یک تیم نوپا، با تمرکز بر نوآوری در امنیت سایبری. اگر مهارت‌های فوق را دارید، رزومه و نمونه‌کارهای خود (مانند مقالات نوشته‌ شده یا پست‌های اینستاگرام و ... ) را به ایمیل tryhackbox@gmail.com ارسال کنید یا به پشتیبانی @ThbxSupport پیام دهید. منتظر شما هستیم .

⭕ مقدمه‌ای بر AD CS: کانتینرها در Active Directory حالا می‌رسیم به بخش کانتینرها تو اکتیو دایرکتوری که مستقیماً با Certificate Services مرتبطه. این کانتینرها اساساً جایی هستن که همه تنظیمات و objectهای مرتبط با PKI ذخیره میشن، و اگر بتونی بهشون دسترسی پیدا کنی، راه برای persistence یا حتی escalation باز میشه. من اینجا تمرکز میکنم روی Public Key Services container، که مسیرش اینه: CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=com. این کانتینر تو partition Configuration قرار داره، یعنی site-wide و replicate میشه تو همه DCها. زیرمجموعه‌های کلیدی تو Public Key Services این کانتینر چند تا sub-container مهم داره که هر کدوم نقش خاصی تو AD CS بازی میکنن: - Certificate Templates:    اینجا templateهای گواهی ذخیره میشن 📌  چیزایی مثل User یا Computer که مشخص میکنن چطور گواهی صادر بشه، شامل EKUها، enrollment rights و غیره. اینا کلیدین برای abuse، چون اگر vuln باشن، میتونی دسترسی بگیری. - Certification Authorities:    لیست trusted root CAها اینجا هست. این rootها از طریق Group Policy Object (GPO) propagate میشن به کلاینت‌ها. یعنی اگر بتونی یک CA جعلی اضافه کنی، همه ماشین‌ها بهش trust میکنن. - Enrollment Services:    این بخش Enterprise CAها رو لیست میکنه 📌 CAهایی که integrate شدن با AD و میتونن گواهی صادر کنن. اگر دسترسی داشته باشی، میتونی enrollment رو manipulate کنی. - NTAuthCertificates:    برای چیزایی مثل smart card authentication و key archival استفاده میشه. این objectها مشخص میکنن کدوم CAها مجازن برای NT authentication، که تو Kerberos مهمه. آموزش ردتیم: چطور این کانتینرها رو abuse کنیم؟ تو سناریوهای حمله، ACLهای ضعیف روی این کانتینرها میتونه به persistence منجر بشه. مثلاً، اگر Write rights داشته باشی روی Certification Authorities، می‌ تونی یک trusted root جعلی اضافه کنی (مثل حمله DPERSIST2 تو گزارش‌های persistence). این کار domain-wide trust رو میشکنه. برای enumerate کردن، از PowerShell استفاده کن:

Powershell

ls 'AD:\CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=com'

این کامند لیست objectها رو نشون میده. برای templateها، ابزار Certify.exe عالیه: Certify find رو بزن تا vuln templateها رو پیدا کنی. abuse عملی: اگر ACL Write داری روی یک template، می‌ تونی modify کنی (مثل ESC4) . مثلاً enrollment rights اضافه کنی یا EKUها رو تغییر بدی تا vuln بشه. بعد، گواهی درخواست بده و escalate کن. نکته ای که هس : این کانتینرها جزو Tier 0 assetها حساب می‌شن یعنی compromiseشون معادل domain persistence. adminها باید ACLها رو سختگیرانه چک کنن، چون حتی یک low-priv کاربر اگر rights داشته باشه، میتونه کل PKI رو به هم بریزه. تمرین پیشنهادی برای دست‌گرمی، تو محیط تستت یک template enumerate کن با Certify (مثل Certify find /template:User) و EKUها رو چک کن ببین آیا Client Auth داره یا Any Purpose، که vuln هستن. این کمک میکنه بهتر بفهمی کجا حمله کنی. #ADCS @KavehAPT

⭕ مقدمه‌ای بر AD CS: کانتینرها در Active Directory حالا می‌رسیم به بخش کانتینرها تو اکتیو دایرکتوری که مستقیماً با Certificate Services مرتبطه. این کانتینرها اساساً جایی هستن که همه تنظیمات و objectهای مرتبط با PKI ذخیره میشن، و اگر بتونی بهشون دسترسی پیدا کنی، راه برای persistence یا حتی escalation باز میشه. من اینجا تمرکز میکنم روی Public Key Services container، که مسیرش اینه: CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=com. این کانتینر تو partition Configuration قرار داره، یعنی site-wide و replicate میشه تو همه DCها. زیرمجموعه‌های کلیدی تو Public Key Services این کانتینر چند تا sub-container مهم داره که هر کدوم نقش خاصی تو AD CS بازی میکنن: - Certificate Templates:    اینجا templateهای گواهی ذخیره میشن 📌  چیزایی مثل User یا Computer که مشخص میکنن چطور گواهی صادر بشه، شامل EKUها، enrollment rights و غیره. اینا کلیدین برای abuse، چون اگر vuln باشن، میتونی دسترسی بگیری. - Certification Authorities:    لیست trusted root CAها اینجا هست. این rootها از طریق Group Policy Object (GPO) propagate میشن به کلاینت‌ها. یعنی اگر بتونی یک CA جعلی اضافه کنی، همه ماشین‌ها بهش trust میکنن. - Enrollment Services:    این بخش Enterprise CAها رو لیست میکنه 📌 CAهایی که integrate شدن با AD و میتونن گواهی صادر کنن. اگر دسترسی داشته باشی، میتونی enrollment رو manipulate کنی. - NTAuthCertificates:    برای چیزایی مثل smart card authentication و key archival استفاده میشه. این objectها مشخص میکنن کدوم CAها مجازن برای NT authentication، که تو Kerberos مهمه. آموزش ردتیم: چطور این کانتینرها رو abuse کنیم؟ تو سناریوهای حمله، ACLهای ضعیف روی این کانتینرها میتونه به persistence منجر بشه. مثلاً، اگر Write rights داشته باشی روی Certification Authorities، می‌ تونی یک trusted root جعلی اضافه کنی (مثل حمله DPERSIST2 تو گزارش‌های persistence). این کار domain-wide trust رو میشکنه. برای enumerate کردن، از PowerShell استفاده کن: Powershell ls 'AD:\CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=com' این کامند لیست objectها رو نشون میده. برای templateها، ابزار Certify.exe عالیه: Certify find رو بزن تا vuln templateها رو پیدا کنی. abuse عملی: اگر ACL Write داری روی یک template، می‌ تونی modify کنی (مثل ESC4) . مثلاً enrollment rights اضافه کنی یا EKUها رو تغییر بدی تا vuln بشه. بعد، گواهی درخواست بده و escalate کن. نکته ای که هس : این کانتینرها جزو Tier 0 assetها حساب می‌شن یعنی compromiseشون معادل domain persistence. adminها باید ACLها رو سختگیرانه چک کنن، چون حتی یک low-priv کاربر اگر rights داشته باشه، میتونه کل PKI رو به هم بریزه. تمرین پیشنهادی برای دست‌گرمی، تو محیط تستت یک template enumerate کن با Certify (مثل Certify find /template:User) و EKUها رو چک کن ببین آیا Client Auth داره یا Any Purpose، که vuln هستن. این کمک میکنه بهتر بفهمی کجا حمله کنی. #ADCS @KavehAPT

⭕ مقدمه‌ای بر AD CS: کانتینرها در Active Directory حالا می‌رسیم به بخش کانتینرها تو اکتیو دایرکتوری که مستقیماً با Certificate Services مرتبطه. این کانتینرها اساساً جایی هستن که همه تنظیمات و objectهای مرتبط با PKI ذخیره میشن، و اگر بتونی بهشون دسترسی پیدا کنی، راه برای persistence یا حتی escalation باز میشه. من اینجا تمرکز میکنم روی Public Key Services container، که مسیرش اینه: CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=com. این کانتینر تو partition Configuration قرار داره، یعنی site-wide و replicate میشه تو همه DCها. زیرمجموعه‌های کلیدی تو Public Key Services این کانتینر چند تا sub-container مهم داره که هر کدوم نقش خاصی تو AD CS بازی میکنن: - Certificate Templates: اینجا templateهای گواهی ذخیره میشن 📌 چیزایی مثل User یا Computer که مشخص میکنن چطور گواهی صادر بشه، شامل EKUها، enrollment rights و غیره. اینا کلیدین برای abuse، چون اگر vuln باشن، میتونی دسترسی بگیری. - Certification Authorities: لیست trusted root CAها اینجا هست. این rootها از طریق Group Policy Object (GPO) propagate میشن به کلاینت‌ها. یعنی اگر بتونی یک CA جعلی اضافه کنی، همه ماشین‌ها بهش trust میکنن. - Enrollment Services: این بخش Enterprise CAها رو لیست میکنه 📌 CAهایی که integrate شدن با AD و میتونن گواهی صادر کنن. اگر دسترسی داشته باشی، میتونی enrollment رو manipulate کنی. - NTAuthCertificates: برای چیزایی مثل smart card authentication و key archival استفاده میشه. این objectها مشخص میکنن کدوم CAها مجازن برای NT authentication، که تو Kerberos مهمه. آموزش ردتیم: چطور این کانتینرها رو abuse کنیم؟ تو سناریوهای حمله، ACLهای ضعیف روی این کانتینرها میتونه به persistence منجر بشه. مثلاً، اگر Write rights داشته باشی روی Certification Authorities، می‌ تونی یک trusted root جعلی اضافه کنی (مثل حمله DPERSIST2 تو گزارش‌های persistence). این کار domain-wide trust رو میشکنه. برای enumerate کردن، از PowerShell استفاده کن:

Powershell
ls 'AD:\CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=com'

این کامند لیست objectها رو نشون میده. برای templateها، ابزار Certify.exe عالیه: Certify find رو بزن تا vuln templateها رو پیدا کنی. abuse عملی: اگر ACL Write داری روی یک template، می‌ تونی modify کنی (مثل ESC4) . مثلاً enrollment rights اضافه کنی یا EKUها رو تغییر بدی تا vuln بشه. بعد، گواهی درخواست بده و escalate کن. نکته ای که هس : این کانتینرها جزو Tier 0 assetها حساب می‌شن یعنی compromiseشون معادل domain persistence. adminها باید ACLها رو سختگیرانه چک کنن، چون حتی یک low-priv کاربر اگر rights داشته باشه، میتونه کل PKI رو به هم بریزه. تمرین پیشنهادی برای دست‌گرمی، تو محیط تستت یک template enumerate کن با Certify (مثل Certify find /template:User) و EKUها رو چک کن ببین آیا Client Auth داره یا Any Purpose، که vuln هستن. این کمک میکنه بهتر بفهمی کجا حمله کنی. #ADCS @KavehAPT

⭕ مقدمه‌ای بر AD CS – درخواست امضای گواهی (Signing Request) درود ادامه بحثمون، حالا میخوام برم سراغ بخش Certificate Signing Request یا CSR. این یکی از مراحل کلیدی تو فرآیند صدور گواهی‌ هاست و اگر خوب درک نشه، میتونه نقطه ضعفی باشه تو امنیت دامنه. من اینجا سعی می‌ کنم فرآیند رو قدم به قدم توضیح بدم، با تمرکز روی جنبه‌های red teaming و چگونگی abuse کردنش. CSR چیه و چطور کار میکنه؟ به طور خلاصه، CSR یک درخواست رسمی برای امضای گواهی هست که از سمت کلاینت (کاربر یا سیستم) به Certificate Authority (CA) ارسال میشه. تو این درخواست، کلاینت public key خودش رو همراه با اطلاعات دیگه مثل Subject Name، Subject Alternative Name (SAN)، Extended Key Usage (EKU) و جزئیات دیگه میفرسته. CA این اطلاعات رو validate میکنه مثلاً چک میکنه که آیا requester حقوق لازم رو داره یا نه و اگر همه چیز اوکی باشه، گواهی رو sign میکنه و برمیگردونه. این فرآیند معمولاً تو AD CS از طریق templateها مدیریت میشه. مثلاً، template مشخص میکنه که چه fieldهایی تو CSR مجاز هستن. اما اگر CA درست کانفیگ نشده باشه، مهاجم میتونه fieldهایی مثل SAN رو manipulate کنه تا گواهی جعلی بسازه. CSR میتونه شامل extensionهایی مثل EKU (که تو پست قبلی توضیح دادم) یا حتی custom OIDها باشه، که اینا رو کلاینت موقع generate کردن CSR اضافه میکنه. آموزش ردتیم: چطور CSR رو abuse کنیم؟ تو سناریوهای حمله، CSR یکی از بهترین جاها برای injection اطلاعات جعلی هست، مخصوصاً تو حملاتی مثل ESC1 (که تو گزارش SpecterOps توضیح دادن). ایده اینه که SAN جعلی inject کنی. مثلاً یک altname مثل admin یا یک کاربر دسترسی دار و اگر template vulnerable باشه (مثل اینکه SAN editable باشه و manager approval نداشته باشه)، CA بدون چک کردن sign میکنه. ابزار عالی برای این کار Certify.exe هست، که میتونی باهاش CSR generate کنی و مستقیم submit کنی به CA. مثال عملی:

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

تو این کامند، /ca اسم CA رو مشخص میکنه، /template template مورد نظر (مثل User که معمولاً vulnerable)، و /altname SAN جعلی رو اضافه میکنه. اگر CA vuln باشه مثلاً enrollment rights داشته باشی و validation سستی داشته باشه گواهی میگیری که میتونی باهاش impersonation کنی، مثل login کردن به عنوان admin بدون نیاز به credential واقعی. بعد از گرفتن گواهی، میتونی از ابزارهایی مثل Rubeus برای Pass-the-Certificate استفاده کنی و escalate کنی. نکته‌های مهم برای abuse - Intercept کردن CSR: اگر enrollment از طریق وب باشه (مثل Web Enrollment Services)، میتونی CSR رو وسط راه intercept کنی برای Man-in-the-Middle (MITM) attacks. مثلاً با پروکسی مثل Burp، request رو modify کنی و fieldهایی مثل SAN یا EKU رو تغییر بدی. این تو محیط‌ هایی که HTTPS درست کانفیگ نشده، خیلی آسونه. 📌همیشه چک کن که template چطور تنظیم شده 📌 اگر SAN user-supplied باشه و CA auto-approve کنه، راه بازه برای حمله. در نهایت، CSR قلب فرآیند صدور گواهی تو AD CS هست، و اگر adminها حواسشون نباشه، میتونه به escalation سریع منجر بشه. پیشنهادم اینه که تو لاب خودتون emulate کنید و با ابزارهایی مثل Certify تست کنید. #ADCS @KavehAPT

⭕ مقدمه‌ای بر AD CS – درخواست امضای گواهی (Signing Request) درود ادامه بحثمون، حالا میخوام برم سراغ بخش Certificate Signing Request یا CSR. این یکی از مراحل کلیدی تو فرآیند صدور گواهی‌ هاست و اگر خوب درک نشه، میتونه نقطه ضعفی باشه تو امنیت دامنه. من اینجا سعی می‌ کنم فرآیند رو قدم به قدم توضیح بدم، با تمرکز روی جنبه‌های red teaming و چگونگی abuse کردنش. CSR چیه و چطور کار میکنه؟ به طور خلاصه، CSR یک درخواست رسمی برای امضای گواهی هست که از سمت کلاینت (کاربر یا سیستم) به Certificate Authority (CA) ارسال میشه. تو این درخواست، کلاینت public key خودش رو همراه با اطلاعات دیگه مثل Subject Name، Subject Alternative Name (SAN)، Extended Key Usage (EKU) و جزئیات دیگه میفرسته. CA این اطلاعات رو validate میکنه مثلاً چک میکنه که آیا requester حقوق لازم رو داره یا نه و اگر همه چیز اوکی باشه، گواهی رو sign میکنه و برمیگردونه. این فرآیند معمولاً تو AD CS از طریق templateها مدیریت میشه. مثلاً، template مشخص میکنه که چه fieldهایی تو CSR مجاز هستن. اما اگر CA درست کانفیگ نشده باشه، مهاجم میتونه fieldهایی مثل SAN رو manipulate کنه تا گواهی جعلی بسازه. CSR میتونه شامل extensionهایی مثل EKU (که تو پست قبلی توضیح دادم) یا حتی custom OIDها باشه، که اینا رو کلاینت موقع generate کردن CSR اضافه میکنه. آموزش red teaming: چطور CSR رو abuse کنیم؟ تو سناریوهای حمله، CSR یکی از بهترین جاها برای injection اطلاعات جعلی هست، مخصوصاً تو حملاتی مثل ESC1 (که تو گزارش SpecterOps توضیح دادن). ایده اینه که SAN جعلی inject کنی. مثلاً یک altname مثل admin یا یک کاربر دسترسی دار و اگر template vulnerable باشه (مثل اینکه SAN editable باشه و manager approval نداشته باشه)، CA بدون چک کردن sign میکنه. ابزار عالی برای این کار Certify.exe هست، که میتونی باهاش CSR generate کنی و مستقیم submit کنی به CA. مثال عملی:

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

تو این کامند، /ca اسم CA رو مشخص میکنه، /template template مورد نظر (مثل User که معمولاً vulnerable)، و /altname SAN جعلی رو اضافه میکنه. اگر CA vuln باشه مثلاً enrollment rights داشته باشی و validation سستی داشته باشه گواهی میگیری که میتونی باهاش impersonation کنی، مثل login کردن به عنوان admin بدون نیاز به credential واقعی. بعد از گرفتن گواهی، میتونی از ابزارهایی مثل Rubeus برای Pass-the-Certificate استفاده کنی و escalate کنی. نکته‌های مهم برای abuse - Intercept کردن CSR: اگر enrollment از طریق وب باشه (مثل Web Enrollment Services)، میتونی CSR رو وسط راه intercept کنی برای Man-in-the-Middle (MITM) attacks. مثلاً با پروکسی مثل Burp، request رو modify کنی و fieldهایی مثل SAN یا EKU رو تغییر بدی. این تو محیط‌ هایی که HTTPS درست کانفیگ نشده، خیلی آسونه. 📌همیشه چک کن که template چطور تنظیم شده 📌 اگر SAN user-supplied باشه و CA auto-approve کنه، راه بازه برای حمله. در نهایت، CSR قلب فرآیند صدور گواهی تو AD CS هست، و اگر adminها حواسشون نباشه، میتونه به escalation سریع منجر بشه. پیشنهادم اینه که تو لاب خودتون emulate کنید و با ابزارهایی مثل Certify تست کنید. #ADCS @KavehAPT

مقدمه‌ای بر AD CS – درخواست امضای گواهی (Signing Request) درود ادامه بحثمون، حالا میخوام برم سراغ بخش Certificate Signing Request یا CSR. این یکی از مراحل کلیدی تو فرآیند صدور گواهی‌ هاست و اگر خوب درک نشه، میتونه نقطه ضعفی باشه تو امنیت دامنه. من اینجا سعی می‌ کنم فرآیند رو قدم به قدم توضیح بدم، با تمرکز روی جنبه‌های red teaming و چگونگی abuse کردنش. CSR چیه و چطور کار میکنه؟ به طور خلاصه، CSR یک درخواست رسمی برای امضای گواهی هست که از سمت کلاینت (کاربر یا سیستم) به Certificate Authority (CA) ارسال میشه. تو این درخواست، کلاینت public key خودش رو همراه با اطلاعات دیگه مثل Subject Name، Subject Alternative Name (SAN)، Extended Key Usage (EKU) و جزئیات دیگه میفرسته. CA این اطلاعات رو validate میکنه مثلاً چک میکنه که آیا requester حقوق لازم رو داره یا نه و اگر همه چیز اوکی باشه، گواهی رو sign میکنه و برمیگردونه. این فرآیند معمولاً تو AD CS از طریق templateها مدیریت میشه. مثلاً، template مشخص میکنه که چه fieldهایی تو CSR مجاز هستن. اما اگر CA درست کانفیگ نشده باشه، مهاجم میتونه fieldهایی مثل SAN رو manipulate کنه تا گواهی جعلی بسازه. CSR میتونه شامل extensionهایی مثل EKU (که تو پست قبلی توضیح دادم) یا حتی custom OIDها باشه، که اینا رو کلاینت موقع generate کردن CSR اضافه میکنه. آموزش red teaming: چطور CSR رو abuse کنیم؟ تو سناریوهای حمله، CSR یکی از بهترین جاها برای injection اطلاعات جعلی هست، مخصوصاً تو حملاتی مثل ESC1 (که تو گزارش SpecterOps توضیح دادن). ایده اینه که SAN جعلی inject کنی. مثلاً یک altname مثل admin یا یک کاربر دسترسی دار و اگر template vulnerable باشه (مثل اینکه SAN editable باشه و manager approval نداشته باشه)، CA بدون چک کردن sign میکنه. ابزار عالی برای این کار Certify.exe هست، که میتونی باهاش CSR generate کنی و مستقیم submit کنی به CA. مثال عملی:

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

تو این کامند، /ca اسم CA رو مشخص میکنه، /template template مورد نظر (مثل User که معمولاً vulnerable)، و /altname SAN جعلی رو اضافه میکنه. اگر CA vuln باشه مثلاً enrollment rights داشته باشی و validation سستی داشته باشه گواهی میگیری که میتونی باهاش impersonation کنی، مثل login کردن به عنوان admin بدون نیاز به credential واقعی. بعد از گرفتن گواهی، میتونی از ابزارهایی مثل Rubeus برای Pass-the-Certificate استفاده کنی و escalate کنی. نکته‌های مهم برای abuse - Intercept کردن CSR: اگر enrollment از طریق وب باشه (مثل Web Enrollment Services)، میتونی CSR رو وسط راه intercept کنی برای Man-in-the-Middle (MITM) attacks. مثلاً با پروکسی مثل Burp، request رو modify کنی و fieldهایی مثل SAN یا EKU رو تغییر بدی. این تو محیط‌ هایی که HTTPS درست کانفیگ نشده، خیلی آسونه. 📌همیشه چک کن که template چطور تنظیم شده 📌 اگر SAN user-supplied باشه و CA auto-approve کنه، راه بازه برای حمله. در نهایت، CSR قلب فرآیند صدور گواهی تو AD CS هست، و اگر adminها حواسشون نباشه، میتونه به escalation سریع منجر بشه. پیشنهادم اینه که تو لاب خودتون emulate کنید و با ابزارهایی مثل Certify تست کنید. #ADCS @KavehAPT