DCSync — «אני גם Domain Controller»

זיוף שכפול AD: מי שיש לו הרשאות Replicating Directory Changes מבקש מה־DC את כל ה־hashes — בלי לגעת ב־NTDS.dit.

תיאוריה

Controllers מסנכרנים ביניהם את מסד הנתונים של דרך פרוטוקול השכפול (DRSUAPI). כדי לבקש שכפול צריך הרשאה מיוחדת: (ובפועל גם Replicating Directory Changes All) על אובייקט הדומיין.

מנצל את זה: התוקף מתחזה ל־DC ומבקש מה־DC האמיתי «תשכפל לי את הנתונים». בתגובה הוא מקבל את ה־password hashes של כל חשבון — כולל KRBTGT (הבסיס ל־) ו־Administrator. הכל קורה ברשת, בלי להעתיק קובץ NTDS.dit ובלי להריץ קוד על ה־DC.

מי מחזיק את ההרשאות האלה בברירת מחדל? Admins, Enterprise Admins, Administrators ו־DCs עצמם. הבעיה מתחילה כשההרשאה הודרה (delegated) בטעות לקבוצות או לחשבונות שירות — וזה קורה בהפתעה בהרבה ארגונים.

פרקטיקה — מעבדה בלבד

# DCSync עם Mimikatz — שאיבת hash של KRBTGT
mimikatz # lsadump::dcsync /domain:corp.local /user:krbtgt
# או חשבון ספציפי:
mimikatz # lsadump::dcsync /domain:corp.local /user:Administrator

powershell

# אותה פעולה מלינוקס עם impacket
secretsdump.py corp.local/attacker:'Password123'@dc01.corp.local -just-dc-user krbtgt

bash

זיהוי (Detection)

Event ID 4662 על ה־DC — גישה לאובייקט הדומיין עם GUIDs של השכפול: 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 ו־1131f6ad-9c07-11d1-f79f-00c04fc2dcd2.
החשד: 4662 עם ה־GUIDs האלה מחשבון שאינו — DCs לגיטימיים מבצעים שכפול כל הזמן, משתמשים לא.
שכפול שמקורו בכתובת IP שאינה של DC — כמעט תמיד .
קיימים Sigma rules ייעודיים — חפשו "" בקטלוג.

מיטיגציה

אודט הרשאות: מי מחזיק / All על הדומיין? ב־: קשתות GetChanges / GetChangesAll.
הסירו את ההרשאות מכל מי שאינו DC או חשבון תשתית שמוכרח — כל חשבון כזה הוא «DC נוסף» שאתם לא מכירים.
הגנו על החשבונות המורשים ב־Tiering וב־PAW — הם שקולים ל־ Admin.
אחרי חשד לפגיעה: איפוס כפול של סיסמת KRBTGT (פעמיים, בהפרש) — אחרת ה־ ממשיך לעבוד.