DPAPI (Data Protection API)
یک تکنولوژی است که توسط مایکروسافت برای حفاظت از داده‌ها در سیستم‌عامل‌های ویندوز طراحی شده است. این تکنولوژی برای رمزنگاری اطلاعات حساس مانند پسوردها، کلیدهای رمزنگاری، و دیگر داده‌های مهم استفاده می‌شود. DPAPI برای کاربران و برنامه‌ها امکان حفاظت از داده‌هایشان را فراهم می‌کند و به صورت خودکار از طریق کلیدهای رمزنگاری خاص سیستم عامل، داده‌ها را حفاظت می‌کند.

حمله به DPAPI:

حمله به DPAPI معمولاً به منظور استخراج داده‌های رمزنگاری‌شده از سیستم یا نفوذ به اطلاعات حساس انجام می‌شود. این نوع حملات می‌تواند بر روی سیستم‌های آسیب‌پذیر یا زمانی که دسترسی به سیستم یا کلیدهای خاص موجود باشد، انجام گیرد.

روش‌های رایج حمله به DPAPI:

1. دسترسی به فایل‌های رمزنگاری‌شده:

* اگر یک مهاجم به فایل‌هایی که با DPAPI رمزنگاری شده‌اند دسترسی داشته باشد، ممکن است قادر به استخراج داده‌های رمزنگاری‌شده باشد. البته این داده‌ها تنها زمانی قابل رمزگشایی هستند که مهاجم به کلیدهای مناسب دسترسی داشته باشد.

2. دسترسی به کلیدهای DPAPI:

* برای رمزگشایی اطلاعاتی که توسط DPAPI رمزنگاری شده‌اند، مهاجم باید به کلیدهای خاص سیستم دسترسی پیدا کند. در حالت عادی، این کلیدها باید به طور امن ذخیره شوند، ولی در صورتی که مهاجم بتواند به این کلیدها دسترسی پیدا کند، می‌تواند داده‌های رمزنگاری‌شده را رمزگشایی کند.

3. حملات مبتنی بر حافظه (Memory Dumping):

* یکی از روش‌های معمول حمله به DPAPI، dump کردن حافظه سیستم است. در این روش، مهاجم ممکن است بتواند از حافظه سیستم (که کلیدهای DPAPI در آن ذخیره می‌شوند) اطلاعاتی استخراج کند. در صورتی که مهاجم به حافظه فیزیکی یا حافظه سیستم دسترسی داشته باشد، ممکن است بتواند کلیدها یا داده‌های رمزنگاری‌شده را شبیه‌سازی کند.

4. حملات به ذخیره‌سازی و پروفایل‌های سیستم:

* بسیاری از اطلاعاتی که با DPAPI رمزنگاری می‌شوند، در پروفایل‌های کاربران ویندوز ذخیره می‌شوند. اگر مهاجم به پروفایل‌های خاص یا فولدرهای مربوط به کاربران دسترسی پیدا کند، می‌تواند به اطلاعات رمزنگاری‌شده یا کلیدهای لازم برای رمزگشایی آنها دسترسی پیدا کند.

5. مهندسی اجتماعی (Social Engineering):

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

نتیجه‌گیری:

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

@KavehOffSec

خب، اولین مسئله:
در حین جمع‌آوری و تحلیل اطلاعات، متوجه شدیم روی ایستگاه کاری W-434 سرویس Web Client فعال هست. حساب کامپیوتری W-434 می‌تونه «رمز عبور» حساب سرویس GMSA$ رو بخونه. حساب سرویس GMSA$ عضو گروهیه که اجازه خوندن ویژگی LAPS برای ادمین لوکال روی سرور SERVERHTTP رو داره. خود حساب سرور هم برای Kerberos Unconstrained Delegation تنظیم شده.

شرط اضافه: سطح دامنه ۲۰۱۶ هست.

هدف: گرفتن دسترسی ادمین دامنه.

راه‌حل:

فعال بودن سرویس Web Client این امکان رو میده که تکنیک NTLM Relay رو از HTTP به LDAP اجرا کنیم و سطح دامنه ۲۰۱۶ هم اجازه می‌ده تکنیک Shadow Credentials رو به‌عنوان payload استفاده کنیم. با وادار کردن ایستگاه کاری W-434 به احراز هویت و relay کردن احراز هویت NTLM به LDAP، تکنیک Shadow Credentials رو اجرا می‌کنیم.

کلید خصوصی و عمومی به‌دست‌ اومده رو استفاده می‌کنیم و TGT بلیت برای شیء کامپیوتر W-434 می‌گیریم. حالا با دسترسی حساب کامپیوتر W-434، هش رمز عبور حساب سرویس GMSA$ رو می‌خونیم.

با اجرای تکنیک Overpass-the-Hash، می‌تونیم درخواست‌ها رو به‌جای حساب سرویس بفرستیم. چون این حساب عضو گروه READ_LAPS هست، مقدار ویژگی ms-Mcs-AdmPwd سرور SERVERHTTP (یعنی رمز ادمین محلی) رو می‌گیریم.

با استفاده از این اطلاعات وارد سرور SERVERHTTP می‌شیم. Rubeus رو در حالت مانیتور اجرا می‌کنیم و احراز هویت اجباری کنترلر دامنه رو راه می‌ندازیم و سرور SERVERHTTP رو به‌عنوان listener می‌ذاریم. بعد از چند ثانیه، TGT بلیت کنترلر دامنه رو می‌گیریم.

حالا با تکنیک Pass-the-Ticket این بلیت رو ایمپورت می‌کنیم. در این حالت می‌تونیم تکنیک DCSync رو از طرف کنترلر دامنه اجرا کنیم و هش رمز ادمین دامنه رو به‌دست بیاریم.
@KavehOffSec

LDAPWhoami

در برخی مواقع، لازم است بدانید که درخواست‌های LDAP در چه زمینه‌ای (context) اجرا می‌شوند. این موضوع به‌ویژه پس از اجرای تکنیک‌های Pass-the-Ticket و OverPass-the-Hash اهمیت دارد. اگر یک سشن جدید با استفاده از دستور runas /netonly ایجاد شده باشد، دستور whoami کاربری را که این دستور را اجرا کرده است، نشان می‌دهد. می‌توان با استفاده از دستور klist اطلاعاتی درباره بلیط‌های Kerberos مشاهده کرد، اما اگر هیچ درخواست Kerberos وجود نداشته باشد، klist اطلاعاتی درباره بلیط‌ها ارائه نخواهد داد.

در این حالت، می‌توان از اسکریپت زیر برای به‌دست آوردن اطلاعات مفید استفاده کرد:

function Invoke-LDAPWhoami
{
    Add-Type -AssemblyName System.DirectoryServices.Protocols -ErrorAction Stop
    $connect = new-object System.DirectoryServices.Protocols.LdapConnection("domain.local")
    $request = new-object System.DirectoryServices.Protocols.ExtendedRequest('1.3.6.1.4.1.4203.1.11.3')
    $result = ([System.Text.Encoding]::ASCII.GetString($connect.SendRequest($request).ResponseValue)).split(":")[1]
    Write-Host "Current context is: $result"
}
Invoke-LDAPWhoami

این اسکریپت یک درخواست گسترش‌یافته LDAP با OID 1.3.6.1.4.1.4203.1.11.3 را اجرا می‌کند که حساب کاربری را که درخواست را به نمایندگی از آن انجام شده است، برمی‌گرداند. پارامتر دامنه، در اینجا domain.local، می‌تواند از محیط $env:USERDNSDOMAIN به‌دست آید اگر اسکریپت بر روی یک ماشین دامنه اجرا شود.

در این پست، من روش‌های جایگزین برای دستور whoami را ذکر کرده‌ام، بنابراین می‌توان این روش را نیز به مجموعه اضافه کرد.

@KavehOffSec

مسئله شماره ۲

ادامه میدیم با موضوع مسائل و سناریوی دوم رو بررسی می‌کنیم. باز هم بحث خواندن LAPS هست، ولی این فقط یه تصادفه.

سناریو 
در نتیجه تحلیل مسیرها در BloodHound مشخص شد که سرور SCCM دارای دسترسی ادمین لوکال روی SERVER است. این SERVER هم به نوبه خودش دارای دسترسی برای خواندن ویژگی LAPS برای سرور SERVERDB می‌باشد. روی سرور SERVERDB هم یک سشن از ادمین AD-ADMIN وجود دارد.

شرط اضافه: روی سرور SERVER امضای SMB غیرفعال است.

وظیفه: 
تلاش برای به دست آوردن حساب ادمین AD-ADMIN.

راه‌حل:

اگر روی سرور SCCM هیچ محافظتی برای احراز هویت اجباری (RPC filter) فعال نباشد، ما می‌توانیم تلاش کنیم تا احراز هویت اجباری انجام دهیم و احراز هویت NTLM را به سرور SERVER relay کنیم. به عنوان payload می‌توان چند گزینه داشت:
⦁ اضافه کردن خودمان به گروه ادمین‌های لوکال؛
⦁ خواندن داده‌ها از LSA و به دست آوردن اطلاعات ورود لوکال؛
⦁ اجرای یک درخواست LDAP برای خواندن ویژگی ms-Mcs-AdmPwd

گزینه سوم را بررسی می‌کنیم. اگرچه حساب SCCM عضو گروه ادمین‌های لوکال است، اما ورود تعاملی برای کامپیوترها روی ماشین راه دور ممنوع است. بنابراین همه دستورات از طرف SYSTEM اجرا می‌شوند. اگر دستورات از SYSTEM روی ماشین دامنه اجرا شوند، هنگام اتصال به LDAP، از حساب کامپیوتر (در اینجا SERVER) استفاده می‌شود.

برای اجرای درخواست به LDAP از یک کوئری ADSI استفاده می‌کنیم:

$object = [ADSI]"LDAP://CN=SERVERDB,CN=Computers,DC=domain,DC=local"
$name, $laps =  $object.Properties["name","ms-Mcs-AdmPwd"]
Write-Output "$name has LAPS password $laps"

این دستور را به base64 تبدیل می‌کنیم تا از شر کاراکترهای خاص راحت شویم. NTLM Relay را اجرا می‌کنیم، هدف را SERVER قرار می‌دهیم و به عنوان payload از -c "powershell -enc <base64>" استفاده می‌کنیم.

حالا احراز هویت اجباری سرور SCCM را اجرا می‌کنیم و نتایج را مشاهده می‌کنیم. اگر همه چیز درست پیش برود، پسورد LAPS را به دست می‌آوریم و می‌توانیم وارد سرور SERVERDB شویم و با dump کردن بلیت‌های Kerberos یا impersonate کردن توکن‌های دسترسی، حساب AD-ADMIN را به دست آوریم.

اگر مشکلی پیش آمد، همیشه دو گزینه اول باقی می‌ماند.

@KavehOffSec

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

برخلاف آموزش‌های تئوریک OpSec، این کتاب کاملاً فنی است آموزش قدم‌به‌قدم ابزارها از مخفی‌سازی اثر انگشت شبکه و راه‌اندازی C2 تا ضد جرم‌شناسی و متادیتا، خوانندگان مهارت‌هایی واقعی برای عملیات‌های تهاجمی سطح بالا و حفظ ناشناس بودن به دست می‌آورند.

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

اگر پیشنهادی دارید خوشحال میشوم توی گروه tryhackbox بنویسید یا از طریق توییتر به من بگید .
twitter : https://www.x.com/kavehxnet
chat : @TryHackBoxGroup

بخشی از مطالب کتاب :

شاخص‌های سازش (IoC) تولیدشده توسط Red Teamها
 
شاخص‌های سازش (Indicators of Compromise – IoC) آرتیفکت‌های فنی هستند که به تیم آبی اجازه می‌دهند فعالیت مخرب را شناسایی، مسدود یا بررسی کنند. اگرچه معمولاً مربوط به مهاجمان واقعی (APTها، بدافزار، کمپین‌های جاسوسی) هستند، IoCها مستقیماً به عملیات‌های رد تیم ضعیف هم مربوط می‌شوند.

رد تیم‌های بی‌تجربه یا دارای OpSec ضعیف IoCهایی تولید می‌کنند که منجر به انتساب فوری، همبستگی کمپین‌ها و حتی شناسایی اپراتورها یا شرکت مجری عملیات می‌شود.

چه چیزی IoC محسوب می‌شود؟ 
IoC
هر سیگنال فنی قابل مشاهده است که نشان‌دهنده حضور یا فعالیت مهاجم باشد. برای رد تیم‌ها، دسته‌های کلیدی شامل:

۱. شاخص‌های مبتنی بر میزبان (Host-Based Indicators):
   ⦁ فایل‌های ایجاد یا تغییر یافته (مثلاً payloadها در %TEMP%، DLLهای مخرب)
   ⦁ کلیدهای رجیستری برای ماندگاری (Run، RunOnce، Services)
   ⦁ پردازش‌های تزریق‌شده یا مشکوک (rundll32، regsvr32، mshta)
   ⦁ زمان‌بندی‌های ناسازگار (نشانه timestomping)
   ⦁ رشته‌های استاتیک داخل فایل‌های اجرایی

@KavehOffSec

بخشی از کتاب :

هر اقدام رد تیم یک ردپا به جا می‌گذارد. هرچه ابزار و زیرساختت را کمتر شخصی‌سازی کنی، شبیه تهدیدهای شناخته‌شده‌تر می‌شی. تولید IoC گاهی اجتناب‌ناپذیر است اما درک، کنترل و مدیریت آن چیزی است که حرفه‌ای‌ها را از آماتورها جدا می‌کند.
@KavehAPT

وقتی بحث رد تیم میشه، معمولاً میگن این نوع عملیات فقط به درد شرکت‌های بالغ می‌خوره یعنی شرکت‌هایی که امنیت اطلاعات قوی، SOC اختصاصی و تست نفوذ منظم دارن. اما صحبت درباره بلوغ خود تیم رد تیم کمتر پیش میاد.

بلوغ تیم رد تیم رو نمیشه فقط با تعداد عملیات‌های انجام‌شده سنجید. اگه یه تیم توی شش ماه ۸ تا ۱۰ عملیات داشته باشه، باید به کیفیت کار و سطح آمادگی تردید کرد (مگر اینکه تیم خیلی بزرگ باشه و کارها رو موازی انجام بده). هر عملیات معمولاً ۶ تا ۸ هفته طول می‌کشه.

بلوغ رد تیم رو میشه با سطح آمادگی، نوع TTP‌هایی که استفاده می‌کنه و داشتن R&D اختصاصی ارزیابی کرد. این بلوغ به سه سطح تقسیم میشه:

⦁  سطح ابتدایی
⦁ استفاده از TTPهای ساده و رایج
⦁ اجرای سناریوهای حمله ساده و عمدتاً تکراری
⦁ اتکا به ابزارهای متداول
⦁ نداشتن توسعه اختصاصی
⦁ سطح پنهان‌کاری پایین

⦁  سطح متوسط
⦁ استفاده از TTPهای رایج با تغییرات
⦁ اجرای سناریوهای پیچیده‌تر و اعمال تغییر در صورت نیاز
⦁ استفاده محدودتر و هوشمندانه‌تر از ابزارها
⦁ ترکیب ابزارها با امکانات سیستم‌عامل
⦁ انجام توسعه‌های ابتدایی یا تغییر در ابزارهای موجود
⦁ سطح پنهان‌کاری متوسط

⦁  سطح پیشرفته
⦁ ابداع و استفاده از TTPهای اختصاصی
⦁ پیاده‌سازی سناریوهای پیچیده و غیر تکراری
⦁ خودداری از استفاده ابزارهای شناخته شده بازار (مگر در حالت آفلاین)
⦁ تمرکز روی امکانات سیستم‌عامل
⦁ توسعه اختصاصی، C2 اختصاصی و R&D
⦁ سطح پنهان‌کاری بسیار بالا (مگر طبق توافق یا اتفاق)

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

ناشناسی یک حالت باینری نیست یک رشته لایه‌ای است. شما می‌توانید در فضای IP کاملاً ناشناس باشید و همچنان از طریق زمان‌بندی، رفتار، DNS یا استفاده از گواهینامه هویت خود را افشا کنید. هر لایه (شبکه، اپلیکیشن، انسان) باید به‌صورت جداگانه مقاوم‌سازی شود.

بخشی از کتاب ناشناس بودن برای ردتیمرها
@KavehOffSec

BloodHound v8.0

#پاسخ به #سوالات شما :

ریدایرکتور چیست؟

ریدایرکتور، همان‌طور که از نامش پیداست، سروری است که درخواست‌های HTTP/HTTPS را بر اساس اطلاعات موجود در بدنه درخواست HTTP هدایت (ریدایرکت) می‌کند. در سیستم‌های عملیاتی، ممکن است یک "ریدایرکتور" را به شکل یک لود بالانسر (Load Balancer) ببینید. این سرور معمولاً از آپاچی 2 یا NGINX استفاده می‌کند.

@KavehOffSec

🔖 چگونه یک فریم ورک C2 انتخاب کنیم ؟

پس از اتمام این کتاب، ممکن است سوالاتی براتون پیش بیاد و امیدواریم یکی از آن‌ها این باشد: «چگونه بدونم کدوم فریم ورک C2 رو برای عملیات‌های تیم قرمز خود انتخاب کنم؟» پاسخ درست یا غلطی برای این سوال وجود ندارد، فقط چند سوال کلی که ابتدا باید به آن‌ها پاسخ بدید :

اهداف شما چیست؟
آیا بودجه‌ای دارید؟
آیا به چیزی بسیار قابل تنظیم نیاز دارید؟
آیا از Evasion آنتی‌ویروس‌های آماده (Off-the-shelf AV Evasion) ضروری است؟
آیا نیاز دارید که بتوانید ماژول‌ها/اسکریپت‌های خودتان را ایجاد کنید؟
آیا گزارش‌گیری داخلی برای شما ضروری است؟

سپس باید این اطلاعات را به فایل xlsx گسترده C2 Matrix ببرید و انتخاب خود را بر اساس سوالات بالا محدود کنید. اگر یک فریم ورک C2 پریمیوم پیدا کردید که معیارهای شما را برآورده می‌کند، به شدت توصیه می‌شود که درخواست یک نسخه آزمایشی/ارزیابی کنید تا ببینید آیا آن فریم ورک C2 برای شما بهترین گزینه است یا خیر.

مطالب بخشی از کتاب ردتیم ما که در حال آماده شدن است .
@TryHackBox | #RedTeam

با تمرکز روی حملات به AD CS من روی مفاهیم پایه‌ای تمرکز می‌کنم اما با دیدگاه ردتیم: چطور این ویژگی‌ها رو enumerate کنیم abuse کنیم برای escalation یا theft و evasion تکنیک‌ها رو اضافه می‌کنم.

مثال‌های عملی با ابزارهایی مثل Certify، CertUtil، و PowerShell میدم تا بتونید در لابراتورتون تمرین کنید.

با هشتگ زیر این آموزش ها رو دنبال کنید :

#ADCS
@KavehOffSec

⭕ مقدمه‌ای بر AD CS: زیرساخت کلید عمومی در اکتیو دایرکتوری

AD CS یا Active Directory Certificate Services
یکی از نقش‌های کلیدی ویندوز سرور است که به سازمان‌ ها امکان میدهد تا زیرساخت کلید عمومی (PKI) را پیاده‌سازی و مدیریت کنند. این سرویس برای صدور، مدیریت و اعتبارسنجی گواهی‌ های دیجیتال استفاده می‌شود که در پروتکل‌ های امنیتی مانند SSL/TLS، احراز هویت و رمزنگاری کاربرد دارند. گواهی‌های دیجیتال، جایگزینی امن‌ تر و قابل‌ اعتمادتر برای احراز هویت مبتنی بر پسورد هستند و از رمزنگاری نامتقارن (کلید عمومی و خصوصی) به همراه امضاهای دیجیتال بهره می‌برند.

💢 چرا AD CS مهم است؟

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

- رمزنگاری ایمیل‌ها: برای اطمینان از محرمانگی و اصالت ایمیل‌ها.
- امضای دیجیتال: برای امضای اسناد یا کد های نرم‌افزاری جهت تضمین یکپارچگی و اصالت.
- احراز هویت مبتنی بر گواهی: برای کاربران، کامپیوترها یا دستگاه‌ها (مثلاً در Kerberos با پروتکل PKINIT).
- پروتکل‌های امن: مانند VPN، SSH یا سیستم فایل رمزنگاری‌شده (EFS).

این قابلیت‌ها باعث می‌شوند AD CS به یکی از اجزای حیاتی زیرساخت امنیتی سازمان‌ها تبدیل شود.

💢 چرا AD CS برای تیم قرمز جذاب است؟

از منظر تیم قرمز (Red Team)، AD CS یک هدف طلایی است، چون اغلب به‌درستی درک یا پیکربندی نمی‌شود. تنظیمات نادرست (misconfiguration) مثل قالب‌های گواهی آسیب‌پذیر (vulnerable certificate templates) می‌توانند راه را برای نفوذ به دامنه (domain) بدون نیاز به اکسپلویت‌ های پیچیده باز کنند. برای مثال، اگر مهاجم بتواند گواهی‌ ای با Extended Key Usage (EKU) مربوط به Client Authentication را سرقت کند، می‌تواند یک TGT (Ticket Granting Ticket) از Kerberos بگیرد و به‌ راحتی هویت یک کاربر یا سیستم را جعل (impersonate) کند. این تکنیک که به Pass-the-Cert معروف است، یکی از روش‌های قدرتمند سوءاستفاده از AD CS است.

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

Get-ADObject -LDAPFilter '(objectclass=certificationAuthority)' -SearchBase 'CN=Configuration,DC=yourdomain,DC=com'

اگر این دستور خروجی برگرداند، یعنی AD CS در دامنه فعال است. حالا می‌توانید از ابزارهایی مثل Certify برای لیست کردن Certification Authorities (CAs) و بررسی تنظیمات آن‌ها استفاده کنید.

نکته برای Evasion: برای جلوگیری از شناسایی توسط آنتی‌ویروس‌هایی مثل Windows Defender، ابزار Certify را با استفاده از ConfuserEx مبهم‌ سازی (obfuscate) کنید تا احتمال تشخیص آن کاهش یابد.

نکته : سوءاستفاده از PKI برای پایداری (Persistence)
یکی از بزرگ‌ترین مزیت‌های سوءاستفاده از AD CS برای مهاجمان، امکان ایجاد پایداری (persistence) در محیط است. برخلاف پسوردها که ممکن است تغییر کنند، گواهی‌ های دیجیتال معمولاً تاریخ انقضای طولانی‌ مدت دارند و تغییر پسورد کاربر تأثیری بر اعتبار آن‌ها ندارد. این ویژگی، PKI را به ابزاری ایده‌ آل برای حفظ دسترسی غیرمجاز تبدیل می‌کند.

جمع‌بندی
AD CS:
یکی از ستون‌های اصلی امنیت در محیط‌ های مبتنی بر اکتیو دایرکتوری است، اما تنظیمات نادرست آن می‌تواند به پاشنه آشیل سازمان تبدیل شود. برای تیم‌های امنیتی (Blue Team)، درک عمیق این سرویس و ایمن‌سازی آن ضروری است. برای تیم‌های قرمز، AD CS دریچه‌ای به سوءاستفاده‌های پیشرفته و پایداری طولانی‌مدت در شبکه است. با ابزارهای مناسب و دانش کافی، این سرویس می‌تواند نقطه شروعی برای حملات پیچیده باشد.

#ADCS #PKI
@KavehOffSec

⭕ مقدمه‌ای بر 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
@KavehOffSec

سوالات شما

من سوالی را که در توییتر مطرح شد دوست داشتم، مفهوم آن این بود: «در کدام مرحله تیم رد تیم به راحتی شناسایی می‌شود؟»

یکی از وظایف تیم مهاجم این است که اجازه دهد تیم دفاعی آن‌ها را شناسایی کند. انجام یک اشتباه آگاهانه، گذاشتن IOC، اجرای برنامه یا دستوراتی که باید محرک شروع یک حادثه باشند. اما انجام این اقدامات توسط تیم مهاجم در مرحله پایانی خواهد بود، زمانی که فقط هدف عملیات باقی مانده است. اگر تیم مهاجم خیلی زود شناسایی شود، ممکن است بر ادامه عملیات تأثیر منفی بگذارد. همه چیز به توافقات اجرای پروژه بستگی دارد.

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

در کتاب ناشناس بودن برای ردتیمر ها میخوانید که چطور از شناسایی شدن جلو گیری کنید .

#FAQ #RedTeam
@KavehOffSec

⭕ مقدمه ای بر 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
@KavehOffSec

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