Active Directory Hardening

تمامی مطالب این داکیومنت مختص آدمین های می باشد که چند سالی با سرویس  Active Directory کار کرده اند و برای دوستانی که تجربه و اشنائی با این سرویس ندارند مفید نمی باشد. به همین دلیل در بعضی از قسمتهای این مقاله مقدمه یا توضیحی اضافه ای داده نشده است و فقط اشاره ای کوتاهی به دستورالعملها خواهیم داشت و جزئیات را به خوانده عزیز واگذار می کنیم.

یکی از مهمترین و حساس ترین سرویس ها در ساختارهای مایکروسافتی به ضرس قاطع  Active Directory و سرورهای نگهدارنده این رل Domain Controller ها می باشند. امنیت این سرویس از هر سرویس دیگری بالاتر و مهمتر می باشد، چون در صورت  Down شدن چنین سرویسی تمامی کاربران، سرویس ها، سیستم های اکانتینگ  و غیره  Downخواهند شد. در نتیجه علاوه بر امن سازی شبکه در لایه ۲ و لایه  Application مانند نصب آنتی ویروس و غیره  Hardening سرویس اکتیو دایرکتوری و اجزای آن از هر لایه امنیتی مهمتر و واجبتر می باشد.

بدون هیچگونه مقدمه ای دستوالعمل ها را آغاز می کنیم.

Backup گیری از Domain Controller:

اگر از نرم افزار خاصی برای Backup استفاده نمی کنید می توانید از  Windows server backup استفاده کنید. برای نصب آن:

دوستان عزیز محل نگهداری  Backup AD خیلی مهم می باشد و  پیشنهاده می شود که محل نگهداری Backupها باید بر روی سیستمی باشد که عضو اکتیو دایرکتوری نباشد و اطلاعات آن رمز گذاری شده باشد. حتما یک نسخه از Backup اکتیو دایرکتوری را بصورت  Offline نگهداری کنید.

برای سرعت و کیفیت  Backup های گرفته شده از  PowerShell استفاده کنید که می توانید از این لینک استفاده کنید.

همیشه پروسه  Backup گیری را  Track کنید که می توانیم از  Event Viewer استفاده کنیم.

Backup گیری از DHCP سرور:

اهمیت این سرویس را همه همکاران عزیز می دانند پس باید برای روزهايی که کل اطلاعات از بین برود راه حلی داشته باشیم. برای  Backup گیری از  DHCP از دستور زیر استفاده کنید:

برای  Restore کردن Backup  در مواقع ضروری بر روی  DHCP فعلی می توان از  CMDlet زیر استفاده کنید:

Backup گیری از DNSسرور:

برای اینکار از دستور زیر استفاده کنید:

Backup گیری از ADCS:

برای Backup گیری از این سرویس می توانید از  PS استفاده کنید. ولی این نکته را متذکر شوم که این روش وقتی کاربرد دارد که اطلاعات  خود  CA از بین رود. ولی اگر بخواید سرور را  Migrate کنید یا این سرویس را بر روی سرور جدید ریستور کنید باید از این روش استفاده کنید.

Secure کردن پلاسی Default Domain Controllers Policy:

سیاست های Default Domain Controllers Policy به گروه های مثل Backup Operators or Server Operators دسترسی های بیش از حد داده است که اگر فردی عضو چنین گروه های باشد به سادگی می توان با استفاده از متدهای خود را عضو گروه Domain Admins کند و ساختار اکتیو دایرکتوری را کنترول کند. پس در نتیجه بهتر است این  GPO را با تنظیمات زیر Replace کنید.

نکته:

اگر از گروه  Backup Operators استفاده ای ندارید توصیه شده این گروه را از  GPO فوق پاک نمائید.

توجه داشته باشید  سیاستی که با رنگ قرمز مشخص شده خیلی مهم و آن را در صورتی اعمال کنید که مطمئن شوید Device یا سرویس از  NTLMv1 استفاده نکند.

برای اینکه درخواستهای NTLMv1 سمت  DC ها را مانیتور کنید از  Auditing های زیر استفاده کنید.

برای تشخیص ترافیک  NTLM از لاگ شماره ۴۶۲۴ استفاده کنید.

برای اینکه شما کلا  NTLMv1 را غیرفعال کنید و فقط از  NTLMv2 استفاده کنید باید مراحل زیر را به ترتیب انجام دهید.

غیر فعال کردن سرویس های غیر ضروری:

سرویس های زیر بر روی  Domain Controller غیر ضروری هستن و باید غیرفعال شوند:

Xbox live auth manager

Xbox live game save

Print spooler

آخرین Backup گرفته شده بر روی  Domain Controller ها را همیشه مانیتور کنید:

می توانید از دستور  repadmin /showbackup استفاده کنید. یا  Event Viewer را چک کنید.

Get-WinEvent *backup*

بنا به توصیه مایکروسافت هر ۱۸۰ روز یکبار پسورد یوزر KRBTGT را ریست کنید:

برای جلوگیری از حملات Golden Ticket و حملات دیگر باید این پروسه را انجام دهیم. برای دیدن اخرین زمانی که پسورد  KRBTGT تغییر کرده از دستور زیر استفاده کنید.

برای ریست پسورد این کاربر Script فراوانی وجود دارد. ولی من از دستور زیر استفاده می کنم

ولی یادتون باشه این تغییرات باید هر چه سریعتر به  DCهای دیگر Replication شود وگرنه سرویس های مثل  Exchange یا احرازهویت کاربران، دسترسی کاربران به سرویسها مختل می شود. (روزهای تعطیل اینکار را انجام دهید).

نکته:

برای اینکه بفهمیم تغییرات به  DC های دیگه Replicate شده از Script بالا استفاده کنید.

پسورد DSRMرا نیز باید به ترتیب هر نیم سال یا ۱۸۲ روز یکبار ریست شود:

برای اینکار:

برای  track کردن این پروسه به Log شماره ۴۷۹۴ مراجعه کنید.

تکمیل و بهبود تنظیمات Auditing:

تنظیمات پیش فرض سیاستهای  Auditing در دومین مناسب و ناکافی می باشد و شما نمی توانید تمام تراکنش های انجام شده در ساختار را  Track کنید. برای انجام این تنظیمات بصورت کامل و اصولی از Microsoft Security Compliance استفاده کنید. که در این داکیومنت سعی کردیم به بعضی از این تنظیمات اشاره کنیم.

Policy Path	Policy Setting	Configured setting
Account Logon	Audit Credential Validation	Failure
Account Logon	Audit Kerberos Authentication Service	Success and Failure
Audit Logon	Audit Kerberos Service Ticket Operations	Failure
Account Management	Audit Computer Account Management	Success
Account Management	Audit Other Account Management	Success
Account Management	Audit Security Group Man-agement	Success
Account Management	Audit User Account Management	Success and Failure
Detailed Tracking	Audit PNP Activity	Success
Detailed Tracking	Audit Process Creation	Success
DS Access	Audit Directory Services Access	Failure
DS Access	Audit Directory Service Changes	Success
Logon/Logoff	Audit Account Lockout	Failure
Logon/Logoff	Audit Group Membership	Success
Logon/Logoff	Audit Logon	Success and Failure
Logon/Logoff	Audit Other Logon/Logoff Events	Success and Failure
Logon/Logoff	Audit Special Logon	Success
Object Access	Audit Detailed File Share	Failure
Object Access	Audit File Share	Success and Failure
Object Access	Audit Other Object Access	Success and Failure
Object Access	Audit Removable Storage	Success and Failure
Policy Change	Audit Policy Change	Success
Policy Change	Audit Authentication Policy Change	Success
Policy Change	Audit MPSSVC Rule-Level Pol-icy Change	Success and Failure
Policy Change	Audit Other Policy Change Events	Failure
Privilege Use	Audit Sensitive Privilege Use	Success and Failure
System	Audit Other System Events	Success and Failure
System	Audit Security State Change	Success
System	Audit Security System Extension	Success
System	Audit System Integrity	Success and Failure

 

هر از گاهی لیست ACL های ست شده بر روی Object های اکتیو دایرکتوری را چک کنید:

میدانم این پروسه وقت گیر، سخت و نیاز به تمرکز بالا دارد ولی برای اینکه این پروسه را با دقت و آسان انجام دهید می توانید از ابزار های زیر استفاده کنید:

AD ACL Scanner

Run Bloodhound

برای دانلود ابزار AD ACL Scanner از این لینک استفاده کنید. کار با این ابزار بسیار راحت می باشد. که می توانید بصورت GUI

و دستوری استفاده کنید. این ابزار دو نوع خروجی به شما می دهد که بصورت HTML و CSV می باشد.

ACL های ست شده بر روی OU=Domain Controller:

اگر یوزر غیر مجاز بر روی این ابجکت مجوز بیش از حد داشته باشد می تواند  GPO این  OU را غیرفعال نماید یا یک  GPO جدید لینک کند یا می تواند تنظیمات کامپیوتر اکانت  DCها را تغییر دهد.

در تصویر بالا مشاهده می کنید یوزر A.jahloli (اگر این یوزر  Authorizesنباشد) مجوز  Fullبر روی این کانتینر دارد که بسیار خطرناک می باشد.

ACL های ست شده بر روی Domain Controller Computer Account:

اگر یک یوزر غیر مجاز بر روی کامپیوتر آکانتهای Domain Controller مجوز داشته باشد می تواند از متد Resource-Based Constrained Delegation Abuse استفاده کند و دسترسی به کل  Active Directory را بدست خواهد آورد. اگر هکر مجوز  Write بر روی صفت  ms-DS-Allowed-To-Act-on-Behalf-of-other-identity کامپیوتر اکانتهای  Domain Controller داشته باشد می تواند از جانب سرویس  Active Directoryهر دستوری که بخواهد بر روی  Domain Controller اجرا کند.

ACL های ست شده بر روی اعضای گروه Domain Admins:

یک  Delegation یا  ACL بیش از حد بر روی اعضای این گروه باعث می شود از این یوزرها سوء استفاده شود و افراد عادی بتوانند به این یوزرها دسترسی داشته باشند. ACL های ست شده بر روی این یوزرها را چک می کنیم.

در تصویر بالا می بینیم که گروه  Netmon مجوز  Full Control دارد و به سادگی اعضای گروه  Netmon می توانند پسورد کاربران عضو  Domain Admins را ریست کنند و از آن استفاده کنند.

نکته:

پروسه بالا را برای گروه های سطح بالا انجام دهید مانند :

Domain Admins

Schema Admins

Enterprise Admins

Backup Operation

افرادی که پرمیژن  Write all properties بر روی اعضای گروه Domain Admins داشته باشند می توانند خود را عضو این گروه ها کنند.

چک کردن ACL ست شده بر روی  DNS Object و  DNSAdmins:

کارشناسان امنیت روشی کشف کردن که افرادی که بر روی ابجکت های  DNS مجوز  Write all properties داشته باشند و عضو گروه  DNSAdminsباشند می توانند یک فایل  Dllبا مجوز System بر روی  DC اجرا کنند تا دسترسی  Domain Admins را بدست آورند. لینک های زیر را با دقت بخوانید تا با این روش آشنا شوید:

From DNSAdmins to Domain Admin, When DNSAdmins is More than Just DNS Administration.

DNS Admin Privesc in Active Directory (AD)(Windows).

هر از گاهی  ACL های موجود بر روی  DNSAdmins را چک کنید.

چک کردن ACL های ست شده بر روی  GPOهای لینک شده بر روی   OU ی  Domain Controllers:

افرادی که بر روی  GPO های OU ی  Domain Controllers مجوز  Full داشته باشند به راحتی می توانند   GPO ها را تغییر دهند و خود را بوسیله پلاسی عضو گروه  Domain Admins کنند.

چک کردن ACL های ست شده بر روی  Domain Object ها:

ساختارهای زیادی دیده ام که آدمین  اکتیو دایرکتوری به  Help Desk های آن ساختار بر روی مجموعه ای از Object ها مجوز  Full Control می دهد! علت را اگر جویا شوید متوجه خواهید شد که برای آسانی کارهای روزمره انجام شده است.

گروه های که بر روی ابکجتهای موجود در اکتیودایرکتوری مجوز  Full & Modify داشته باشند می توانند با متد های  Credential یوزرها را استخراج کنند. به این نکته توجه کنید:

ابزار Bloodhound:

شاید برای شما کار سختی باشد که  ACL/ACE تمام ابجکتهای دومین را چک کنید و متوجه شوید مجوز این  Object باعث دادن چه دسترسی های می شود، شما با استفاده از این ابزار به راحتی می توانید ACL های ست شده  بر روی تمام ابجکت ها را بصورت شماتیک مشاهده کنید. لینک دانلود. دوستان و همکارهای عزیز حتما از این ابزار استفاده کنید و به نظر من حقیر برای هر  Active Directory Admin یاد گرفتن و استفاده از این ابزار ضروری می باشد.

ببینید هکرها چگونه از این ابزار برای حمله به اکتیو دایرکتوری استفاده می کنند و آدمین های اکتیو چگونه با استفاده از این ابزار جلوی این حملات را میگیگرند.

Finding Active Directory attack paths using BloodHound.

AD Permissions Attack #2: Attacking Permissions with BloodHound.

فعال کردن Active Directory Recycle Bin:

 صحبت کردن از مزایای این قابلیت بنظرم حرف اضافه اس و بیشتر دوستان با این قابلیت اشنا هستند. برای فعال کردن آن از دستور زیر استفاده کنید:

برای مطمئن بودن از فعال بودن Recycle Bin از دستور زیر استفاده کنید:

Delegate کردن مجوز ریستور کردن ابجکت بوسیله Recycle Bin:

 پیش فرض اعضای گروه  Domain Admins توانائی ریستور کردن ابجکت با   Recycle Bin را دارند. با دستورات زیر من به گروه  Recycle Bin Admins مجوز لازم را خواهم داد و دیگر برای ریستور کردن ابجکت نیازی به مجوز Domain Admins نمی باشد.

من با یوزر مورد نظر (در مثال پایین  Recycle) به سرویس اکیتو دایرکتوری وصل می شوم و چک میکنم چه ابجکتهای پاک شده است:

و در آخر چک می کنم می توانم با این یوزر این ابجکت را ریستور کنم!

که با موفقیت ابجکتهای مورد نظر  Restoreشده اند. فقط به این نکته توجه داشته باشید که مثل من ساعت ها معطل نشوید. بعد از انجام تنظیمات بالا اگر ابجکتی حذف شود می توانید با این روش آن را ریستور کنید وگرنه ابجکتهای که قبل از این تنظیمات حذف شده اند نمی توان با این روش ریستور کرد.  Ref

Delegated permissions only apply to objects deleted after configuration

Objects deleted before configuration must be restored by Domain Admin

Delegated administrator must have permissions on the source/target OU

خالی نگه داشتن گروه های Build-in:

گروه های  پبش فرض و Built-in در اکتیودایرکتوری در نسخه ۲۰۰۳ ایجاد شده اند زمانی که بحث امنیت زیاد مطرح و مهم نبوده است . ولی امروزه یکی از ریسکهای موجود در شبکه های اکتیودایرکتوری عضویت بدون برنامه ریزی در چنین گروه ها می باشد.  مشکل عمده چنین گروه های مانند :

Server Operators

Backup Operators

Account Operators

Print Operators

مجوزهای بیش از حدی که علاوه بر عملکرد آنها، دارا می باشند. پس سعی کنید همیشه این گروه ها را خالی نگهدارید. مایکروسافت (ع) در این باره می فرماید:

فعال نمودن  SID Filtering:

وقتی منه ادمین، یوزرها را از یک  Domain  منتقل کنم به  Domain دیگری، برای تمام یوزرها در  Domain جدید یک  SID جدید ایجاد می شود و برای اینکه  User های  Domain جدید بتوانند به منابع   Domainقدیمی دسترسی داشته باشند SID ، دومین قدیمی به SID History  یوزر اضافه می شود. با اینکه  SID History با کمترین تغییرات توانسته است دسترسی کاربران را به منابع برقرار کند ولی این اجازه را به هکرها می دهد که  SID کاربران سطح بالا را کپی کنند و در  SID History خود قرار دهند و به تمام منابعی که کاربران سطح بالا دسترسی دارند، دسترسی می یابند. مایکروسافت برای رفع این مشکل قابلیت SID Filtering را ایجاد کرده است که با فعال نمودن آن در Trust ها،  SID History کاربر را فیلتر می کند و فقط  اجازه عبور  SID های یک دومین (دومینی که در آن قرار دارند) را می دهد.

فرض کنید من کاربران خود را از  Source Domain انتقال دادم به Distention Domain و پیش فرض  SID Filtering فعال می باشد و می خواهم به  SQLسروری که در  Source Domain می باشد وصل شوم ولی با این خطا مواجه می شوم

و علت آن پاک کردن  Source Domain SID از  SID History کاربر بوسیله  SID Filtering می باشد. برای تسلط بیشتر به این موضوع این داکیومنت را بخوانید. برای دیدن  SID History کاربران از دستور زیر استفاده کنید:

در نتیجه سعی شود برای عدم سوء استفاده از  SID History قابلیت  SID Filtering فعال گردد (گرچه پیش فرض فعال می باشد)

عضو کردن Tier-0 Admins در گروه Protected Users Group:

به علت حساس بودن این  Tier توصیه شده است که تمامی ادمین های این  Tier عضو گروه Protected Users Group شوند.

برای اطلاع بیشتر از  Protected Users Group اینجا را مطالعه بفرمائید.  فقط بدانید و آگاه باشید به همین سادگی نیست که یوزرهای ادمین رو فرتی عضو این گروه کنید ممکن است  ساختار اکتیو را مختل کنید.:)

فعال کردن گذینه Account is sensitive and cannot be delegated بر روی تمامی ادمین های  Tier-0:

با فعال کردن این گذینه بر روی یک یوزر،   Credential این یوزر برای کامپیوتر یا یک سرویس در سطح شبکه ارسال نمی شود. ما در ساختار اکتیودایرکتوری قابلیتی داریم به نام  Kerberos  Delegation که باعث میشه یک  Application/Service قادر باشه به منابعی که بر روی سرورهای دیگه میزبانی می شود دسترسی داشته باشه.

برای درک آن یک مثال می زنم. فرض کنید یک  Web Server داریم که محتویات آن در  SQL سرور ذخیره شده است. برای اینکه به یوزرهای وصل شده به  Web Server مجوز اتصال به  SQL را بدهیم دو روش پیش رو داریم:

• روش اول به Service Accountی که سرویس  Web Server را اجرا می کند مستقیما در  SQL پرمیژن می دهیم.
• روش دوم استفاده از Kerberos Delegation، بدین معنی که سرویس اکانت وب سرور Credential یوزر وصل شده به آن را   Delegate (واگذار می شود، سپردن، تفویض) می کند به  SQLسرور.

در روش دوم وقتی یوزر  x به وب سرور وصل شود و می خواهد به اطلاعات درون  دیتابیس دسترسی داشته باشد، سرویس اکانت وب سرور Credential یوزر  X را سمت  SQL ارسال می کند. این روش باعث می شود یوزر  x به محتویات دیتابیس دسترسی داشته باشد بدون اینکه یوزر  x اطلاعات  Credential خود را در وب سرور یا  دیتابیس وارد کند.

خب برگردیم سراغ بحث اصلیمون. گذینه Account is sensitive and cannot be delegated باعث میشه یوزر X اطلاعات  Credentialخود را در شبکه ارسال نکند و در پروسه  Kerberos Delegation شرکت نکند. برای اطلاع بیشتر اینجا کلیک کنید.

برای ست کردن این گذینه بر روی یوزر از دستور زیر استفاده کنید:

برای لیست کردن کاربرانی که این گذینه برای آنها فعال شده از دستور زیر استفاده کنید:

همکاران مایکروسافتی عزیز سعی کنید به اصطلاحات زیر مسلط شوید:

• Unconstrained Delegation.
• Constrained Delegation
• Proxy tickets
• Forwarded tickets

فعال کردن Auditing بر روی ساختار PKI:

یکی از کلیدی ترین سرویس های یک سازمان سرویس  ADCS می باشد که ۹۰ درصد سرویس ها برای کارکرد خود نیازمند این سرویس می باشند. آدمین های شبکه باید این سرویس را در امنترین حالت خود قرار دهند. یکی از اقداماتی که باید در این راستا انجام شود فعال نمودن  Auditing بر روی این سرویس می باشد. برای اینکار:

 همچنین فعال نمودن سیاست زیر  الزامی می باشد:

مانیتورینگ  Event log های ساختار  PKI:

Logهای زیر مربوط می شود به تراکنش های  ADCS که در محیط  Enterprise باید مانیتورینگ شود.

Event ID	Description		Priority
۴۸۸۲		The security permissions for Certificate Services changed
۴۸۹۰		The certificate manager set-tings for Certificate Services changed.
۴۹۰۰		Certificate Services template security was updated.
۴۸۹۶		One or more rows have been deleted from the certificate database.
۴۸۹۱		A configuration entry changed in Certificate Services.
۴۸۷۳		A certificate request extension changed.
۴۸۷۷		Certificate Services backup completed.
۴۸۷۹		Certificate Services restore completed.

 

Hardening کردن سرویس ADCS بوسیله GPO:

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

Accounts: Administrator account status	Disabled
Accounts: Rename Administrator account	PKIAccount
Accounts: Rename Guest account	PKIGuest
Devices: Restrict CD-ROM access to locally logged on-user only	Enabled
Network Security: LAN Manager authentication level	Send NTLMv2 responses only. Refuse LM & NTLM
Microsoft network client: Digitally sign communications (always)	Enabled
Microsoft network server: Digitally sign communications (always)	Enabled

 

ایجاد Fine-Grained Password Policies برای  Service Accountها:

Service Account ها بهترین هدف برای هکرها می باشد به علت مجوز دادن بیش از حد ادمین های عزیز به نوع اکانتهاست. متاسفانه  بعضی از سرویس ها قابلیت  MSA را پشتیبانی نمی کنند و ما مجبور می شویم از اکانتهای معمولی استفاده کنیم که به احتمال ۹۰ درصد بعد از ایجاد این کانتها تیک گذینه PasswordNeverExpires زده می شود که بعنوان  Best Practice مایکروسافت به حساب نمی آید و مایکروسافت می گوید هر از گاهی پسورد سرویس آکانتها را تغییر دهید.(می دانم پروسه حساس و سختیه ولی باید انجامش داد) برای اینکه ما این پروسه را اجباری کنیم یک Fine-Grained Password Policies بر روی چنین اکانتهای اعمال می کنیم. در قدم اول برای هر نوع از  Service Account ها یک گروه ایجاد کنید و Fine-Grained Password Policies را بر روی آن گروه آعمال کنید.

ایجاد Fine-Grained Password Policies برای آدمین های  Tier-0:

به علت حساس بودن آدمین های این محدوده، لازم است یک Fine-Grained Password Policies کاملا جداگانه برای چنین آدمین های تنظیم شود.

نکته: برای هر محدوده (Tier) یک Fine-Grained Password Policies جداگانه ایجاد کنید.

ریسک  SPNهای مربوط به  Service Accountها:

در ساختار اکتیو دایرکتوری هر  Userی مجوز آن را دارد که یک  Service Ticket برای هر  SPNی درخواست دهد. رل  Ticket Granting Service وقتی بخواهد برای درخواست کنند آن  SPN یک  Service Ticket ارسال کند، آن  Service Ticket را با پسورد  Service Account سرویس رمزگذاری می کند. یک هکر می تواند این  Service Ticket را اکسپورت کند و بصورت افلاین پسورد یا هش  Service Account را استخراج کند. به همین علت سعی شود برای سرویس اکانتها از  MSA استفاده شود و اگر امکانش نباشد  Service Account ها را عضو گروه های سطح بالا نکنید.  Ref

اگر شخصی یا پیمانکاری وارد سازمان شما شود و قصد راه اندازی سرویسی را داشته باشد و اصرار کرد که سرویس اکانت آن سرویس باید عضو  Domain Admins باشد شما دو راه حل دارید.

• تا حد مرگ آن شخص را کتک بزنید.
• از شرکت مربوطه بخواهید که سرویس آنها دقیقا چه مجوزهای در چه قسمت های نیاز دارد و مجوزها را بصورت دستی بر روی قسمتهای که لازم دارند اعمال کنید.

 

همیشه Kerberos Pre-Authentication را بر روی یوزرها غیرفعال نکنید:

بصورت عادی وقتی کاربر برای دریافت TGT Ticket از  Authentication Serviceدرخواستی برای آن ارسال می کند  پروتکل  Kerberos یوزر را وادار می کند که در این مرحله خود را Authenticate کند (بدون وارد کردن پسورد) در این مرحله کاربر برای احراز هویت Timestamp خود را بوسیله هش پسورد نام کاربری خود (User) رمزگذاری می کند و سمت  AS ارسال می کند. در این لحظه  AS تایم کاربر را رمزگشائی می کند و تایم کاربر را با  KDC مقایسه می کند و اگر تایم ها یکسان بوده اند  AS تیکت  TGTرا برای کاربر ارسال می کند.

ولی اگر گذینه Pre-Authentication بر روی کاربری غیرفعال باشد آن کاربر می تواند یک درخواست ساختگی سمت  AS ارسال کند و  AS بدون احراز هویت نمودن کاربر  TGT Ticket را برای کاربر ارسال می کند. که هکر می تواند اطلاعات درون  TGT را استخراج نماید و برای حملات دیگر از آن استفاده کند. در این لینک ببینید چگونه از غیرفعال بودن Pre-Authentication سوء استفاده می شود. همچنین برای اطلاع بیشتر از Pre-Authentication اینجا کلیک کنید. (این پروسه در  Kerberos با نام  Authenticator شناخته می شود. (شک دارم ولی اگر اشتباه می کنم یادآوری کنید تا اصلاح کنم))

برای لیست کاربرانی که Pre-Authentication بر روی آنها غیرفعال شده از دستور زیر استفاده کنید.

بررسی Kerberos Unconstrained Delegation در ساختار و غیرفعال نمودن آن:

در قسمت فعال کردن گذینه Account is sensitive and cannot be delegated بر روی تمامی ادمین های  Tier-0 بصورت مختصر توضیح دادیم که  Kerberos Delegation چی هست و چگونه کار می کند. در این قسمت انواع آنها را نیز بررسی میکنیم.

ما دو نوع  Kerberos Delegation داریم:

• Unconstrained Delegation: در این مد وقتی این قابلیت را بر روی Computer Account/Service Account فعال میکنیم Computer Account/Service Account اطلاعات Credential ، End-User را به همه سرویس های درون Domain, Forest and Domain/Forest های که به آنها Trust داشته باشیم ارسال می کند. (این لینک را حتما مطالعه کنید)
• Constrained Delegation: در این مد ما مشخص می کنیم که Computer account/ Service account فقط مجاز هستن اطلاعات Credential ،   End-User را به سرویس های خاصی ارسال کنند.

وقتی ما Unconstrained Delegation را بر روی سرویسی فعال می کنیم اتفاق جالبی می افتد که از لحاظ امنیتی فاجعه اس. برای اینکه منظورم را بهتر متوجه شوید مجبوریم یه چرخی تو پروسه  Kerberos بزینم

• کاربر با یوزر و پسورد خود به سیستم لاگین می کند.
• پسورد یوزر به NTLM hash تبدیل می شود و  TimeStamp را با هش بدست آمده رمزگذاری می کند. و یک درخواست برای دریافت تیکت TGT سمت  Authentication Service ارسال می کند.  (KRB_AS_REQ)
• رل  AS تیکت را رمزگشائی می کند و یک  TGT به همراه یک  Session Key ( Session Key برای رمزگذاری ارتباط آتی کاربر با  KDC برای دریافت  Service Ticket استفاده می شود) ایجاد می کند و به سمت کاربر ارسال می کند.  (KRB_AS_REP)
• در این لحظه کاربر قصد دارد به سرویسی وصل شود، در نتیجه برای اتصال نیاز به Service Ticket دارد. بنابراین تیکت  TGT را برای Ticket Granting Service (TGS) ارسال می کند  (KRB_KDC_REQ).
• رل  TGS تیکت  TGT را رمزگشائی می کند و   PAC Checksum (Authenticator) را انجام می دهد و  Service Ticket را ایجاد می کند و با هش پسورد  Service Account سرویس (سرور)،  Service Ticket را رمزگذاری می کند و به سمت کاربر ارسال می کند.  (KRB_TGS_REP)
• کاربر به سرویس (سرور) وصل می شود و Service Ticket را به سرویس ارائه می دهد  (KRB_AP_REQ)
• سرویس، Service Ticket دریافتی از کاربر را با هش پسورد  Service Account خود رمزگشائی میکند.
• در این مرحله اگر بر روی این سرویس (سرور) قابلیت Unconstrained Delegation فعال باشد، DC از قبل یک نسخه از  TGT کاربر را در  Service Ticketی که کاربر قصد داشت آن را به سرویس مورد نظر ارائه دهد قرار می دهد. و در آخر سرویس،   Service Ticketکاربر را رمزگشائی می کند و  TGT کاربر را در پروسه  LSASS برای استفاده های بعدی قرار می دهد.
• سرویس (سرور) در این مرحله  TGTکاربر (یوزر) را سمت  Back-end Server ارسال می کند و یوزر تراکنش های خود را انجام می دهد.

متوجه شدید؟؟ سرور  TGT یوزر را در  LSASS خود کش می کند. فرض کنید یوزر عضو گروه  Domain Admins باشد. هکر با هر ابزار و وسیله ای به عنوان مثال مهندسی اجتماعی یوزری که عضو  Domain Admins هستش را وادار می کند به سروری که قابلیت Unconstrained Delegation بر روی آن فعال هستش وصل شود و  Kerberos Delegationرا استفاده کند! خلاص هکر میشه سلطان جنگل!! ببخشید دومین.

پس از من به شما نصیحت:

• به هیچ وجه این قابلیت را فعال نکنید.
• یوزهای حساس و Tier-0 را عضو گروه  Protect Users Group کنید.
• تیک گذینه Account is sensitive and cannot be delegated را بر روی چنین یوزرهای فعال کنید.

برای پیدا کردن سرورهای که Unconstrained Delegation هستن از دستور زیر استفاده کنید:

Get-ADComputer -Filter {(trustedfordelegation -eq $true) -and (primarygroupid -eq 515)} -properties trustedfordelegation, trustedtoauthfordelegation, serviceprincipalname, description

• Unconstrained Delegation: TrustedForDelegation = True
• Constrained Delegation: TrustedToAuthForDelegation = True

 

امن سازی ابجکت  AdminSDHolder:

کار این ابجکت ریست کردن جدول  ACL گروه های سطح بالا  (Protect Group)و اعضای آن می باشد. بعنوان مثال یوزر  A.Jahloli زیر مجموعه  OU ی X هستش و عضو گروه  Domain Admins، در این لحظه یک  Active Directory Delegation از طرف گروه  Help Desk یا غیره بر روی  OUی  X ایجاد می شود و در نتیجه جدول  ACL یوزر  A.Jahloli تغییر می کند، در این وضعیت  AdminSDHolder وارد عمل می شود و توسط پروسه  SDPROP جدول  ACL این یوزر را به حالت قبل برمی گرداند.

نکته:

AdminSDHolder یک ACL Template می باشد که اگر   ACL یوزر A.Jahloli تغییر کند تمپلت AdminSDHolder بر روی جدول  ACL  یوزر A.Jahloli اعمال می شود.  Ref

یک هکر می تواند با متد  Exploiting weak permission with powershell تمپلیت  AdminSDHolder را تغییر دهد و بتواند  Permission خود را بر روی تمام  Protect Objectها اعمال کند. Ref

در نتیجه همیشه  ACL های  AdminSDHolder را مانیتور کنید. لاگ  ۵۱۳۶ و “CN=AdminSDHolder,DC=System” و مراقب باشید  Delegationی بر روی این ابجکت اعمال نشود.

ایجاد یک  Service Account تقلبی و Fake:

هر سرویس اکانتی در دومین یک ریسک حساب می شود چون تمام یوزرهای  forest می توانند برای  SPN اختصاص داده شده به آن سرویس آکانت درخواست  Service Ticket دهند. (دومین کنترولر  Service Ticket را با پسورد سرویس اکانت  (Service Account) رمزگذاری می کند و یک هکر می تواند  Service Ticket را بصورت افلاین کرک کند) بخاطر همین موضوع تاکید شده پسورد  Service Account ها باید بیشتر از ۲۰ کارکتر باشد. (در صورت استفاده نکردن از MSA)

یک راه بهتر برای تشخیص چنین حملاتی، ایجاد یک سرویس کانت و  SPNتقلبی می باشد. چون یوزرهای عادی هرگز به SPN های فیک وصل نمی شوند و فقط یک هکر می باشد که تمام  Service Account را پالایش می کند.

یک درخواست برای این سرویس اکانت می فرستم:

با فیلتر کردن لاگ  ۴۷۶۹ می توانیم این سرویس اکانت را مانیتور کنیم:

عضویت در گروه های سطح بالا را همیشه مانیتور کنید:

برای اینکار می توانید از سیستم های مانیتورینگ مانند  SCOM استفاده کنید که در صورت عضو شدن یوزری به گروهی  Alert مناسب ایجاد کند یا می توایند از لاگ  ۴۷۲۸ و غیره استفاده کنید.

 

مانیتور کردن Event ID های زیر بر روی  Domain Controller:

Event ID	Description
۱۱۰۰	The event log service has shutdown
۱۱۰۲	The audit log was cleared

 

Event ID	Description
۴۷۰۴	A user right was assigned
۴۷۰۵	A user right was removed

 

Event ID	Description
۴۷۱۵	The audit policy (SACL) on an object was changed
۴۷۱۹	System audit policy was changed

 

Event ID	Description
۴۷۲۸	A member was added to a security-enabled global group
۴۷۲۹	A member was removed from a security-enabled global group

 

Event ID	Description
۴۷۷۱	Kerberos pre-authentication failed
۴۷۷۲	A Kerberos authentication ticket request failed
۴۷۷۳	A Kerberos service ticket request failed

 

Event ID	Description
۴۷۸۰	The ACL was set on accounts which are members of administrators groups

 

Event ID	Description
۴۷۴۲	A computer account was changed

 

Event ID	Description
۴۹۴۶	A change has been made to Windows Firewall exception list. A rule was added
۴۹۴۷	A change has been made to Windows Firewall exception list. A rule was modified

 

سعی شود این لاگ ها به یک نقطه مرکزی به عنوان مثال  SIEM ارسال شود و در آنجا آنالیز شود.

 

پیاده سازی مدل Administrative Tier Model:

یکی از بهترین مدل های پیاده سازی شده توسط شرکت مایکروسافت برای جلوگیری از به سرقت رفتن  Credential یوزرهای سطح بالا.

در بیشتر سازمانها (به نظر شخصی بنده ۷۰درصد) اعضای  Domain Admins به کل ساختار لاگین می کنند.  DC, Servers and Workstation که باعث می شود Credential این یوزرها در Memory سیستم ها کش شوند و باعث می شود به راحتی از سیستم ها استخراج شوند. ساختار بالا باعث می شود چنین حملاتی کاهش چشمگیری پبدا کنند. و قانونی ایجاد می شود که اعضای  Domain Admins فقط و فقط به  Tier-0 بتوانند لاگین کنند. آدمین های Tier-0 سرویس های زیر را مدیریت می کنند مانند:

Domain Controller.

ADCS Servers.

ASFS Servers.

Azure AD Connect.

NPS.

Etc.

این مدل یک ساختار ۳ لایه ای تعریف می کند که:

• Tier-0 مهمترین و حساس ترین قسمت ساختار می باشد و اعضای Domain Admins, Enterprise Admins و غیره در این قسمت لاگین می کنند.
• Tier-1 قسمتی می باشد که Resource سازمان در آنجا نگهداری می شود. مانند File Server, Print Server, Web Server  و غیره  که ادمین های  Tier-0 گروه ها و آدمین های این قسمت را تعریف می کنند. و آدمین های Tier-1 Resourceهای این  Tier را مدیریت می کنند. آدمین های این  Tier حق لاگین کردن به  Tier-2 ندارند.
• Tier-2 شامل Workstationها، یوزرها و… پرسنل می باشد که آدمین های این قسمت (Help Desk) به مدیریت و عیب یابی منابع این قسمت می پردازند.

نکته: آدمین های هر  Tier فقط مجاز هستند که فقط به  Tier خود لاگین کنند.

پیاده سازی این مدل فقط ساختن چند  OU نیست! شما باید آن را در محیط پایلوت پیاده سازی و تست کنید و سیاستهای سازمان را به آن آدغام کنید و در آخر یک طرح کلی ایجاد می شود که در محیط  production اعمال خواهد شد.

تعریف آدمین های  Tier-0:

بیشتر دوستان یک استنباط اشتباهی از آدمین های Tier-0 دارند، که فقط آدمین های Domain Controller باید عضو این  Tier باشند که این برداشت کلا اشتباه می باشد.

شما باید این قانون را برای تعیین آدمین های  Tier-0 بکار ببرید:

• هر سرویسی که ایجاد اختلال در آن باعث شود کل ساختار صدمه ببیند،  آدمین های چنین سرویس های باید در  Tier-0 قرار بگیرند.  بعنوان مثال:

Domain Controller های یک سازمان بصورت مجازی راه اندازی شده است، اگر اکانت آدمین ماشین های مجازی، دست هکر افتد چه اتفاقی می افتد؟

هکر می تواند کل  DC ها را خاموش و آنها را کلا پاک کند یا بلای دیگری سر DC ها بیاورد واضح است کل سرویس ها و یوزرها ارتباط آنها با شبکه قطع می شود. در نتیجه آدمین این ماشین های مجازی باید عضو آدمین  Tier-0 باشد.

تاثیر کل سرورها و سرویس ها را بسنجید و در مرحله بعد  Tier آنها را مشخص کنید.

Server	Description	Business Impact
Domain Controller	Handles authentication for users in a Windows network	Management would probably run with their hair on fire if all the DC’s were down or com-promised.
Azure AD Connect	Responsible for synchronizing passwords to Azure	Attacker can leverage to Azure AD Connect to obtain Domain Dominance Escalate privileges to AAD permissions of the Sync account in Azure

 

تمامی GPO های که به  Tier-0 لینک هستن باید توسط آدمین های  Tier-0 مدیریت شوند:

وقتی که این مدل را پیاده سازی کرده اید باید مواظب باشید که  GPO های که به  Tier-0 لینک می شوند توسط آدمین های آن  Tier انجام و مدیریت شود، در غیر این صورت آدمین های  Tier-1 می توانند با سوء استفاده از تنظیمات بد و اشتباه GPO راه خود را به  Tier-0باز کنند.

GPOهای زیر باید توسط آدمین های Tier-0 آنجام و مدیریت شوند.

Domain Policy	Tier 0
OU=Domain Controllers	Tier 0
OU=Tier 0 servers	Tier 0
OU=Tier 0 devices	Tier 0

 

همچنین مواظب  ACLهای ست شده بر روی  GPOهای لینک شده به  Tier-0 باشید.

در آخر یک عذرخواهی کنم از تمام خواندگان عزیز سایت به علت ناخوانا بودن تصاویر. متاسفانه این سایت قابلیت بزرگ کردن تصاویر یا زوم کردن بر روی آنها ندارد.

 

موفق و پیروز باشید

نویسنده: احمد جهلولی