NTDS.dit. به جایش از مکانیزم Replication خود Active Directory استفاده میکند.مهاجم باید دسترسی های خاص Replication را داشته باشد.
مثل:
DS-Replication-Get-Changes
و
DS-Replication-Get-Changes-All
بعد میتواند با استفاده از MS-DRSR درخواست Replication بفرستد و Credential Material را دریافت کند.
اینجاست که ماجرا جدی میشود.
چون اطلاعاتی که ممکن است در این فرآیند به دست بیاید شامل:
NTLM Hash
Kerberos Keys
Credentialهای Privileged Accountها
و حتی Key مربوط به KRBTGT
است اما از دید Detection، دنبال چه چیزی میگردیم؟
یکی از Eventهای مهم:
4662
اگر روی Domain Controller، این Event همراه با:
AccessMask = 0x100
و GUIDهای مربوط به Replication Rights دیده شود، باید بررسی شود که چه Accountای این دسترسی را استفاده کرده.
بعد سؤالهای مهم شروع میشوند:
این Account چه کسی است؟
از چه سیستمی آمده؟
آیا Source یک Domain Controller است؟
آیا این Account واقعاً باید Replication انجام دهد؟
آیا اخیراً Replication Permission گرفته؟
و آیا قبل از آن تغییری در ACLهای Active Directory اتفاق افتاده؟
مثلاً اگر یک User معمولی یا یک سیستم غیر-DC درخواستهای DRSUAPI داشته باشد، در حالی که در محیط شما چنین رفتاری برای آن Account تعریف نشده، این دیگر یک Event ساده نیست.
باید آن را در کنار:
4662
4624
ACL Changes
Source IP
Replication Activity
و Alertهای Identity Security
بررسی کرد.
نکته مهم اینجاست:
4662 بهتنهایی به معنی DCSync نیست.
محیط های واقعی ممکن است سرویس های Sync، Backup یا Identity Management داشته باشند که به Replication Permission نیاز دارند.
پس Detection درست یعنی:
اول Allowlist رفتارهای legitimate را بشناس.
بعد هر چیزی که خارج از آن رفتار است را بررسی کن.
در یک Attack Path واقعی، DCSync میتواند نقطهای باشد که مهاجم از یک دسترسی محدود عبور میکند و به Credentialهای سطح Domain میرسد.
برای همین، فقط اینکه «DCSync را میشناسیم» کافی نیست.
باید بدانیم در Logها چطور پیدایش کنیم.
@KavehOffSec
#Red_Team #RedTeam