DCSync Attacks Introduction and Detection
همان‌طور که می‌دانید سرویس active directory یکی از حیاتی‌ترین سرویس‌های مبتنی بر پلتفرم ویندوزی است که به مدیران تیم فناوری اطلاعات کمک می‌کند تا سیستم‌ها، کاربران و سیاست‌ها را به صورت متمرکز در سراسر شبکه مدیریت کنند. می‌توان گفت Active Directory کامل‌ترین سرویسی است که برای (AAA) authentication accounting authorization استفاده می‌شود. از آن‌جایی‌که این سامانه‌ی یک‌پارچه، بخشی جدایی‌ناپذیر از زیرساخت سازمان است، فرصت‌هایی را برای مهاجمان ایجاد می‌کند تا از ویژگی‌های موجود در Active Directory در راستای اهداف مخرب خود سواستفاده کنند. در این مقاله به یکی از این ویژگی‌ها که به نام Active Directory Replication معروف است و همچنین به بررسی چند رویکرد جهت به دست آوردن درک عمیقی از حمله‌ی DCSync و روش شناسایی آن پرداخته شده است.
Active Directory Replication چیست؟
Domain Controllerها یا به اختصار DCها ستون‌های محیط Active Directory هستند و سازمان‌ها اغلب چندین DC برای یک Active Directory در نظر می‌گیرند تا دسترس‌پذیر بودن این سرویس را تا حد ممکن تضمین کنند. برخی از سازمان‌های بزرگ نیز از چندین DC در سایت‌های مختلف زیرساخت خود بهره می‌برند تا احراز هویت کاربران و سایر سیاست‌ها در هر سایت به صورت محلی انجام شود. بنابراین با توجه به این‌که چندین DC در سازمان وجود دارد مهم است که هر DC از آخرین تغییرات ایجاد شده در محیط Active Directory آگاه باشد. به همین منظور با استفاده از Microsoft Directory Replication Service Remote Protocol (MS-DRSR) تمام DCهای شبکه با Active Directory همگام می‌شوند. به این فرایند Active Directory Replication گفته می‌شود.
معرفی و بررسی حمله‌ی DCSync
DCSync نام تکنیکی است که برای استخراج اطلاعات احراز هویت (شامل نام کاربری و NTLM متناظر با آن) از DCها کاربرد دارد. ساختار کلی این حمله به این صورت است که یک DC جعلی را به AD اضافه کرده و سپس با بهره‌گیری از فرآیند Active Directory Replication برای همگام‌سازی DC جعلی خود با Active Directory بهره می‌بریم. به عبارت دیگر در این حمله از پروتکل MS-DRSR و تابع GetNCChanges درخواست Replication به Active Directory ارسال می‌کنیم و در پاسخ به این درخواست، DC اصلی داده‌هایی که شامل NTLM کاربران نیز می‌شود را به ما بر می‌گرداند. این تکنیک در ابزار Mimikatz در آگوست 2015 توسط بنجامین دلپی و وینسنت لتوکس اضافه شده است.
برای اجرای حمله‌ی DCSync ما به دسترسی‌های زیر بر روی Domain Object نیاز داریم:
- Replicating Directory Changes (DS-Replication-Get-Changes)
- Replicating Directory Changes All (DS-Replication-Get-Changes-All)
- Replicating Directory Changes In Filtered Set (DS-Replication-Get-Changes-In-Filtered-Set) (this one isn’t always needed but we can add it just in case)
به صورت کلی اعضای گروه‌های Administrators، Domain Admins، Enterprise Admins و همین‌طور DC Computer Accounts در Active Directory، به صورت پیش‌فرض دارای دسترسی‌های فوق هستند. اگر می‌خواهید به سرعت هر کاربر دیگری را پیدا کنید که بتواند حمله DCSync را خارج از این مجوزهای پیش‌فرض ذکر شده انجام دهد، اسکریپت PowerShell زیر به شما کمک می‌کند. این اسکریپت همان‌طور که در تصویر زیر مشاهده می‌کنید همه مجوزهای سطح Domain را استخراج کرده و دسترسی‌های پیش‌فرض را Exclude می‌کند.
#Get all permissions in the domain, filtered to the two critical replication permissions represented by their GUIDs
Import-Module ActiveDirectory
cd ‘AD:DC=ehsan,DC=local’
$AllReplACLs = (Get-AcL).Access | Where-Object {$_.ObjectType -eq ‘1131f6ad-9c07-11d1-f79f-00c04fc2dcd2’ -or $_.ObjectType -eq ‘1131f6aa-9c07-11d1-f79f-00c04fc2dcd2’}
#Filter this list to RIDs above 1000 which will exclude well-known Administrator groups
foreach ($ACL in $AllReplACLs)
{
$user = New-Object System.Security.Principal.NTAccount($ACL.IdentityReference)
$SID = $user.Translate([System.Security.Principal.SecurityIdentifier])
$RID = $SID.ToString().Split(“-“)[7]
if([int]$RID -gt 1000)
{
Write-Host “Permission to Sync AD granted to:” $ACL.IdentityReference
}
}
در این مقاله 2 سناریو بررسی خواهد شد:
برای انجام حمله‌ي DCSync سناریوهای متعددی وجود دارد که ما در این مقاله 2 سناریوی پرکاربرد را بررسی کرده‌ایم.
سناریوی اول: فرض می‌کنیم که Hash مربوط به یک حساب کاربری عضو گروه Domain Admins را داریم.
سناریوی دوم: فرض می‌کنیم یک User Credential داریم که بر روی Domain Object دسترسی WriteDACL را دارد.
سناریوی اول
در این سناریو فرض می‌کنیم که از قبل به یک حساب کاربری عضو گروه Domain Admins دسترسی پیدا کرده‌ایم. در محیط آزمایشگاهی فرضی ما، مطابق تصویر زیر کاربری به نام Ali.Mohseni وجود دارد که عضو گروه Domain Admins است.
بنابراین اکنون می‌توانیم حمله‌ی OverPass-The-Hash را با استفاده از اسکریپت پاورشل Invoke-Mimikatz انجام دهیم و یک کنسول پاورشل جدید با دسترسی کاربر Ali.Mohseni باز کنیم.
در کنسول پاورشل جدیدی که باز شده است می‌توانیم با استفاده از اسکریپت Invoke-Mimikatz حمله‌ی DCSync را انجام دهیم.
همان‌طور که در تصویر بالا مشاهده می‌کنید توانستیم با موفقیت حمله‌ی DCSync را انجام دهیم و Hash اکانت krbtgt را بدست آوریم.
سناریوی دوم
فرض می‌کنیم که از قبل پسورد کاربری را به صورت Clear text به دست آورده‌ایم که دسترسی لازم برای انجام WriteDACL را دارد. در محیط آزمایشگاهی ما کاربری به نام Reza.Moradi تعریف شده که همان‌طور که در تصویر زیر مشاهده می‌کنید دسترسی WriteDACL را روی Domain Object دارد.
حالا از اسکریپت PowerView برای اعطای حق دسترسی DCSync به کاربر دیگری به نام user.test استفاده خواهیم کرد.
در ادامه با استفاده از دستور زیر فرایند Enumerate کردن دسترسی‌های کاربر user.test را انجام داده و مشاهده می‌کنیم که کاربر user.test دسترسی‌های لازم برای DCSync را داراست.
در انتها می‌توانیم اسکریپت Invoke-Mimikatz را مانند سناریوی قبل در یک کنسول پاورشل جدید که از طریق تکنیک OverPass-The-Hash با اعتبار کاربر user.test باز می‌کنیم را بارگذاری کرده و حمله‌ی DCSync را با موفقیت انجام دهیم.
به این نکته توجه داشته باشید که ابزارهای مختلفی برای اجرای حمله‌ی DCSync وجود دارد. مانند:
همچنین شما می‌توانید ابزار مخصوص به خود را برای اجرای این حمله پیاده‌سازی کنید.
شناسایی حمله‌ی DCSync
برای شناسایی حمله‌ی OverPass-The-Hash ، حملات مبتنی بر ACL و حمله‌ی DCSync، نیاز است تا ابتدا یک‌سری تنظیمات بر رویDomain Group Policy در قسمت Advanced Audit Policy Configuration مطابق گام‌های زیر انجام دهیم.
- Login to Domain Controller
- Open Group Policy Management Console
- Expand the Domain Object
- Expand the Group Policy Objects
- Right click on the Default Domain Policy and click on Edit (The policy that is applied to all the domain computers. It may differ in your environment)
- Follow the below path to enable Audit Logon events.
Computer Configuration –> Windows Settings –> Security Settings –> Advanced Audit Policy Configuration –> Audit Policies –> Logon/Logoff –> Audit Logon
Computer Configuration –> Windows Settings –> Security Settings –> Advanced Audit Policy Configuration –> Audit Policies –> DS Access –> Audit Directory Service Access
Computer Configuration –> Windows Settings –> Security Settings –> Advanced Audit Policy Configuration –> Audit Policies –> DS Access –> Audit Directory Service Changes - Select “Configure the following audit events:” Checkbox
- Select Success & Failure Checkbox
لازم به ذکر است جمع‌آوری لاگ در اینجا با استفاده از ابزار Sysmon انجام خواهد شد. همچنین از سامانه‌ی Splunk و چند درخواست ساده برای تشخیص این تکنیک‌ها استفاده کرده‌ایم که در ادامه شرح داده شده است.
شناسایی OverPass-The-Hash در Splunk
با استفاده از درخواست زیر می‌توان تکنیک OverPass-The-Hash را شناسایی کرد.
index=wineventlog sourcetype=”WinEventLog:Security” AND Logon_Type=9 AND EventCode=4624 AND Logon_Process=seclogo | table _time ComputerName Account_Name EventCode Logon_Type Logon_Process
در دستور بالا ما به دنبال EventID 4624 هستیم که حاوی longon_Type 9 و logon_process seclogo است.
این EventID زمانی ایجاد می‌شود که یک Logon Session ایجاد شده باشد.
همین‌طور در زمان اجرای تکنیک OverPass-The-Hash، Mimikatz سعی می‌کند به پراسس Lsass دسترسی پیدا کند. دستور زیر را اجرا کنید تا تشخیص دهید آیا پراسس Lsass با دسترسی‌های خاصی توسط Mimikatz برای استخراج Credentialهای ماشین اجرا شده است؟
index=wineventlog sourcetype=”WinEventLog:Microsoft-Windows-Sysmon/Operational” AND EventCode=10 AND GrantedAccess IN (“0x143A”,”0x1010″,”0x1038″) AND TargetImage=”C:\\Windows\\system32\\lsass.exe” | table _time ComputerName EventCode SourceImage TargetImage GrantedAccess
در ادامه با اسکریپت Get-SysmonAccessMask می‌توانیم متوجه شویم که Mimikatz با چه سطح دسترسی‌هایی بر روی فضای حافظه از پراسس lsass.exe دسترسی گرفته است.
شناسایی حمله‌ی Detect DCSync با Splunk
می‌توانیم با اجرای درخواست زیر حمله‌ی DcSync را شناسایی کنیم.
index=wineventlog sourcetype=”wineventlog:security” EventCode=4662 AND Properties=”Control Access” AND Message IN (*”1131f6aa-9c07-11d1-f79f-00c04fc2dcd2″*,*”1131f6ad-9c07-11d1-f79f-00c04fc2dcd2″*,*”89e95b76-444d-4c62-991a-0facbeda640c”*)
GUIDهایی که در دستور بالا فیلتر کرده‌ایم درواقع GUIDهای مربوط به دسترسی‌های Replication هستند که برای اجرای حمله‌ی DCSync مورد نیاز هستند.
Detect ACL Modification:
همچنین می‌توانیم از درخواست زیر برای شناسایی تغییرات ACL که برای کاربر user.test توسط اکانت کاربری Reza.Moradi انجام شده است، استفاده کنیم.
همچنین می‌توان مقدار NtSecurityDescriptor را با استفاده از دستور ConvertFrom-SddlString در پاورشل به اصطلاح ترجمه کرد تا جزییات بیشتری را بدست آوریم. یک نکته‌ی مهم این که دستور ذکر شده نمی‌تواند دسترسی‌های مورد نیاز Replication را به صورت مستقیم به ما نمایش دهد. در واقع مانند شکل زیر، در خروجی این دستور همواره مقدار WriteAttributes را مشاهده می‌کنیم.
منابع:
- https://www.alteredsecurity.com/post/a-primer-on-dcsync-attack-and-detection
- https://attack.stealthbits.com/privilege-escalation-using-mimikatz-dcsync
- https://stealthbits.com/blog/extracting-user-password-data-with-mimikatz-dcsync
- https://gist.github.com/gentilkiwi/dcc132457408cf11ad2061340dcb53c2
- https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc772673(v=ws.10)
- https://adsecurity.org/?p=1729
- https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/abusing-active-directory-acls-aces
- https://raw.githubusercontent.com/PowerShellMafia/PowerSploit/master/Recon/PowerView.ps1
- https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/convertfrom-sddlstring?view=powershell-5.1
- https://raw.githubusercontent.com/PowerShellMafia/PowerSploit/master/Exfiltration/Invoke-Mimikatz.ps1
احسان مقدمیان
ممکن است همچنین دوست داشته باشید
APT28 Campaign Against Ukraine
2 نظر
باسلام
خیلی ممنون از پست تان. در قسمت پیدا کردن mimikatz روش فالس پازیتیو داره چون آلن من mimikatz اجرا کردم و اومدم دیدم ک grant access رو 1478 زده بنظرم شناسایی mimikatz یکم مشکل هست الخصوص imphash هم تغییر کنه. در مورد شناسایی dcsync هم باز فالس پازیتیو زیاد هس اگه تونستید توی شبکه واقعی اجرا کنید و ببینید میتونید با اون روش شناسایی کنید یا نه.
خیلی ممنون
(پاسخ نویسنده‌ی مقاله)
با سلام و عرض ادب. به صورت کلی تمام رول‌هایی که در SIEMها پیاده‌سازی می‌شوند، دارای false positive هستند که کاملا به شبکه و ابزارها و سنسورهای امنیتی بستگی دارد. به عنوان مثال خود آنتی ویروس و EDR هم به فضای حافظه lsass دسترسی دارند و باید در SIEMی که استفاده می‌شوند، فیلتر شوند و نکته‌ی بعدی این که زمانی که این مجموعه ایونت‌ها را با هم در نظر بگیریم، می‌توانیم مشکوک شویم و فایل باینری آن پراسسی که بر روی فضای حافظه lsass دسترسی گرفته را آنالیز کنیم و ببینیم با چه سطح دسترسی به فضای حافظه Lsass دسترسی گرفته است. در مورد DCsync هم در سناریو دوم که کاملا مشخص است که یوزر عادی نباید دسترسی تغییر در ACL آبجکت domain را داشته باشد و در سناریو اول هم باید برای گروه های High Privilege محدودیت در نظر گرفت و با حساسیت بالا آنها رو مدیریت کرد، به صورت دوره‌ای پسوردشان را تغییر دهند، بر روی سیستم‌های clientی لاگینی را انجام ندهند و …تا به راحتی هش پسوردشان به دست افراد هکر نیفتد.