مسئله شماره ۲

ادامه میدیم با موضوع مسائل و سناریوی دوم رو بررسی می‌کنیم. باز هم بحث خواندن 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