💠 یک بررسی جامع و دقیق درباره پروتکل Kerberos که به ویژه برای متخصصان تست نفوذ و ردتیم در محیط‌های مبتنی بر Active Directory بسیار مفید است. این کتاب ابتدا به تاریخچه و تکامل Kerberos می‌پردازد، سپس به تشریح اصول و ساختار کلی پروتکل Kerberos نسخه ۵ می‌پردازد و تفاوت‌های آن با نسخه‌های قبلی را توضیح می‌دهد.

🔶️ در ادامه، کتاب به مفاهیم کلیدی و اصطلاحات مهم در Kerberos مانند Realm، Principal، KDC (مرکز توزیع کلید) و انواع بلیط‌ها (TGT و Service Ticket) می‌پردازد و نحوه عملکرد فرآیند احراز هویت را با تشبیه‌های ساده و نمودارهای گرافیکی توضیح می‌دهد. همچنین، مراحل مختلف تبادل پیام‌ها در پروتکل Kerberos مطابق با RFC 4120 به تفصیل شرح داده شده است.

🔹 بخش مهمی از کتاب به پیاده‌سازی Kerberos در Active Directory اختصاص یافته است که تفاوت‌ها و ویژگی‌های خاص این پیاده‌سازی را بیان می‌کند، از جمله نقش کنترل‌کننده دامنه به عنوان KDC، نحوه ذخیره‌سازی اطلاعات کاربران در فایل ntds.dit و مکانیزم پیش‌احراز هویت (Pre-authentication) که در Active Directory به صورت پیش‌فرض فعال است.

🔶️ علاوه بر این، کتاب به جزئیات فنی مانند الگوریتم‌های رمزنگاری مورد استفاده، نحوه تولید کلیدها، و ساختار پیام‌های مختلف در پروتکل می‌پردازد. همچنین به کاربردهای عملی Kerberos در محیط‌های مختلف و اهمیت آن در امنیت شبکه اشاره شده است.

⭕ برای تیم‌های ردتیم (Red Team) و تست نفوذ، درک عمیق این پروتکل بسیار حیاتی است، زیرا بسیاری از حملات کلاسیک و جدید علیه Active Directory و سیستم‌های مبتنی بر Kerberos طراحی شده‌اند. شناخت دقیق نحوه عملکرد Kerberos به تیم‌های امنیتی کمک می‌کند تا آسیب‌پذیری‌ها را بهتر شناسایی و حملات پیچیده‌تر را شبیه‌سازی کنند.

🧩 https://github.com/TryHackBox/Books/


🆔 @TryHackBox

💠 یک بررسی جامع و دقیق درباره پروتکل Kerberos که به ویژه برای متخصصان تست نفوذ و ردتیم در محیط‌های مبتنی بر Active Directory بسیار مفید است. این کتاب ابتدا به تاریخچه و تکامل Kerberos می‌پردازد، سپس به تشریح اصول و ساختار کلی پروتکل Kerberos نسخه ۵ می‌پردازد و تفاوت‌های آن با نسخه‌های قبلی را توضیح می‌دهد.

🔹 بخش مهمی از کتاب به پیاده‌سازی Kerberos در Active Directory اختصاص یافته است که تفاوت‌ها و ویژگی‌های خاص این پیاده‌سازی را بیان می‌کند، از جمله نقش کنترل‌کننده دامنه به عنوان KDC، نحوه ذخیره‌سازی اطلاعات کاربران در فایل ntds.dit و مکانیزم پیش‌احراز هویت (Pre-authentication) که در Active Directory به صورت پیش‌فرض فعال است.


⭕ برای تیم‌های ردتیم (Red Team) و تست نفوذ، درک عمیق این پروتکل بسیار حیاتی است، زیرا بسیاری از حملات کلاسیک و جدید علیه Active Directory و سیستم‌های مبتنی بر Kerberos طراحی شده‌اند. شناخت دقیق نحوه عملکرد Kerberos به تیم‌های امنیتی کمک می‌کند تا آسیب‌پذیری‌ها را بهتر شناسایی و حملات پیچیده‌تر را شبیه‌سازی کنند.
Github

@KavehOffSec

دوستان خوشحال میشم اگر این کتاب هم واستون مفید هست توی گیت هاب حمایت کنید .

بسی رنج بردم در این سال سی
عجم زنده کردم بدین پارسی

25 اردیبهشت بزرگداشت فردوسی بزرگ

این مخزن حاوی اطلاعاتی درباره سیستم‌های EDR است که می‌تواند در تمرینات رد تیم (Red Team Exercise) مفید باشه .

https://github.com/Mr-Un1k0d3r/EDRs/

@KavehOffSec

delegation
چه خطراتی داره یا چطوری می‌شه ازش سوءاستفاده کرد کمی توضیح بدمش به زبون ساده :
ببینید، delegation تو Kerberos یعنی اینکه یه سرویس (مثلاً سرویس A) بتونه با هویت کاربر، به سرویس دیگه‌ای (مثلاً سرویس B) وصل بشه و کار انجام بده. این موضوع وقتی مهم میشه که سرویس‌ها به همدیگه اعتماد دارن و باید به جای کاربر درخواست بفرستن.

حالا خطرش چیه؟ اگه هکری بتونه به یه سرویسی که delegation داره نفوذ کنه، می‌تونه با هویت هر کاربری که به اون سرویس وصل شده، به سرویس‌های دیگه هم دسترسی پیدا کنه. یعنی عملاً می‌تونه خودش رو جای اون کاربر جا بزنه و به منابع حساس دسترسی بگیره! به همین خاطر باید delegation فقط برای سرویس‌هایی فعال باشه که واقعاً نیاز دارن و امنیتشون تضمین شده‌ست.

@KavehOffSec

TGT چیه ؟
خیلی ساده بخوام بگم بهتون اینه که فرض کنیم میری یه هتل خیلی لوکس. وقتی وارد می‌شی، ابتدا به دفترش می‌رسی و کارت هویتت رو نشون میدی. اونها یه کارت ورود به هتل بهت میدن.
این کارت می‌گه: "این فرد شناسایی شده، می‌تونه تو هتل حرکت کنه."

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

در دنیای شبکه و Kerberos:

"دفتر هتل" = KDC (Key Distribution Center)
"کارت ورودی" = TGT (Ticket Granting Ticket)
"رستوران یا استخر" = سرویس‌های مختلف در شبکه مثل فایل سرور، وب سرور و غیره


پس:
TGT یعنی یه بلیط اولیه که وقتی کاربر وارد سیستم می‌شه (با نام کاربری و رمز) از سرور KDC دریافت می‌کنه و باهاش می‌تونه بدون دوباره وارد کردن رمز، به سرویس‌های مختلف دسترسی پیدا کنه.

چرا TGT مهمه؟

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

طول عمر زیادی داره
مثلاً یه TGT می‌تونه ۱۰ ساعت یا بیشتر فعال بمونه. پس اگه مهاجم بتونه اون رو بدزده، می‌تونه چندین بار ازش استفاده کنه.

دروازه ورود به شبکه‌های داخلیه
وقتی یه مهاجم TGT یه حساب با دسترسی بالا (مثل مدیر دامنه) رو داشته باشه، می‌تونه تمام شبکه رو تحت کنترل بگیره .

مثال ساده:
تو یه روزی که سر کار می‌رسی، لاگین می‌کنی و سیستم متوجه می‌شه "آره، این آدم حق دسترسی داره"، و یه جواز حرکت بهش میده.این جواز تو سیستم تو ذخیره می‌شه.
اگه یه هکر بفهمه کجا نگه داشته شده و اونو برداره، الان او هست تو ! می‌تونه جای تو به همه چیز دسترسی داشته باشه.

چرا باید نگران باشیم؟

چون:
مهاجمان می‌تونن با ابزارهایی مثل Mimikatz یا Rubeus ، این TGT‌ها رو از حافظه (lsass.exe) استخراج کنن.
این کار رو بدون دونستن رمز عبور انجام بدن.
حتی می‌تونن این اعتبارنامه‌ها رو به سرورای دیگه منتقل کنن و بدون نیاز به حضور فیزیکی بودن تو محل ، دسترسی داشته باشن.

@KavehOffSec

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