Data/Locales/checks/he/ADTradecraftChecks.json
|
{ "_family": "ADTradecraftChecks.json", "ADTRADE-001": { "name": { "value": "שאריות cpassword של Group Policy Preferences ב-SYSVOL", "status": "machine-draft" }, "description": { "value": "בין 2008 למאי 2014, Group Policy Preferences אפשרו למנהלים לדחוף משימות מתוזמנות, סיסמאות משתמש מקומיות, כונני רשת ממופים ושירותים באמצעות שדה 'cpassword', המוצפן במפתח AES-256 ש-Microsoft תיעדה בפומבי. התיקון ב-MS14-025 השבית את שדה ה-cpassword בהעדפות חדשות אך הותיר את הקיימות ב-SYSVOL ללא שינוי. כל התקשרות של צוות אדום עדיין מוצאת אותן. כל משתמש דומיין מאומת יכול לקרוא את SYSVOL, לתפוס את ה-cpassword ולפענח אותו במצב לא מקוון. אם מצאת כאן משהו, התייחס לכל פרט הזדהות חשוף כאל פרוץ והחלף אותו.", "status": "machine-draft" }, "recommendedValue": { "value": "אפס תכונות cpassword בכל מקום תחת \\\\domain\\SYSVOL\\domain\\Policies\\**\\*.xml.", "status": "machine-draft" }, "remediationSteps": { "value": "סרוק את SYSVOL: Get-ChildItem -Path \\\\<domain>\\SYSVOL\\<domain>\\Policies -Recurse -Include *.xml | Select-String 'cpassword'. עבור כל התאמה: (1) החלף את הסיסמה של החשבון שפרט ההזדהות שלו חשוף (שם המשתמש נמצא באותו XML), (2) בקר יומנים לגבי שימוש בפרט הזדהות זה מאז יצירת ההעדפה, (3) מחק את העדפת ה-GPP לאחר שפרט ההזדהות החדש במקומו. המסמך KB2962486 של Microsoft מכיל את הנחיות הניקוי.", "status": "machine-draft" } }, "ADTRADE-002": { "name": { "value": "אינדיקטור DCShadow (שרתים סוררים במחיצת התצורה)", "status": "machine-draft" }, "description": { "value": "DCShadow (Vincent LE TOUX / Benjamin Delpy, BlueHat IL 2018) רושם מארח בשליטת תוקף כבקר דומיין על ידי כתיבת אובייקטי nTDSDSA + server תחת CN=Sites,CN=Configuration. בקר הדומיין המזויף משמש לאחר מכן להזרקת נתוני שכפול זדוניים (SID history, גיבובי סיסמאות) מבלי להיות אי פעם בקר דומיין אמיתי. הערה: בדומיינים ותיקים אובייקט server ללא התאמה הוא לעתים קרובות הרבה יותר מטא-נתונים משוירים של בקר דומיין (בקר דומיין שהוסר ללא 'ntdsutil metadata cleanup') מאשר התקפת DCShadow אמיתית, ולכן דירוגו High ולא Critical. חקור את חותמת הזמן whenCreated כדי להבחין בין אובייקט שנוצר לאחרונה (חשוד) לבין מטא-נתונים ישנים ומיושנים.", "status": "machine-draft" }, "recommendedValue": { "value": "כל אובייקטי ה-server תחת CN=Sites,CN=Configuration תואמים לבקרי דומיין אמיתיים הרשומים במלאי. אין אובייקטי server שנוצרו לאחרונה שאינם תואמים לבקר דומיין ידוע.", "status": "machine-draft" }, "remediationSteps": { "value": "מנה: Get-ADObject -Filter {objectClass -eq 'server'} -SearchBase \"CN=Sites,$((Get-ADRootDSE).configurationNamingContext)\" -Properties whenCreated, dNSHostName | Sort whenCreated. הצלב מול מלאי בקרי הדומיין שלך (Get-ADDomainController -Filter *). כל אובייקט server שאינו תואם לבקר דומיין אמיתי, במיוחד כזה שנוצר לאחרונה, מחייב תגובה לאירוע מיידית. DCShadow הוא פרימיטיב ברמת השתלטות על דומיין. נטר אירועי 5137 / 5141 במכל הסכימה כאות לזמן זיהוי.", "status": "machine-draft" } }, "ADTRADE-003": { "name": { "value": "מפתחות שחזור מיושנים של BitLocker", "status": "machine-draft" }, "description": { "value": "מפתחות שחזור של BitLocker מאוחסנים ב-AD כאובייקטי צאצא מסוג msFVE-RecoveryInformation של המחשב שגיבה אותם. כאשר מחשב מוצא משירות אך אובייקט ה-AD נותר תלוי, מפתחות השחזור נותרים ניתנים לתשאול על ידי כל בעל הרשאות שחזור של BitLocker, בדרך כלל קבוצה רחבה יותר מ-'Tier-0'. מפתחות מיושנים משמעם שכוננים שנזרקו ניתנים לפענוח אם ישוחזרו ממשפץ או מפח האשפה.", "status": "machine-draft" }, "recommendedValue": { "value": "כל אובייקטי msFVE-RecoveryInformation שייכים למחשבים שהיו פעילים ב-90 הימים האחרונים. אין מפתחות יתומים לחשבונות מחשב מושבתים או כאלה ששונו לאחרונה ואז התיישנו.", "status": "machine-draft" }, "remediationSteps": { "value": "מנה את מידע השחזור: Get-ADObject -Filter {objectClass -eq 'msFVE-RecoveryInformation'} -Properties whenCreated. עבור כל אחד, עלה אל אובייקט המחשב האב ובדוק את lastLogonTimestamp / Enabled שלו. עבור מחשבים שאינם פעילים יותר מ-90 ימים: ודא שהכונן נמחק או הושמד, ולאחר מכן מחק את אובייקט המחשב ב-AD (מה שמפעיל מחיקה מדורגת של מידע השחזור). עבור מחשבים בשימוש פעיל אך עם מפתחות שחזור ישנים מאוד: החלף באמצעות Backup-BitLockerKeyProtector. ודא שלקבוצת השחזור של BitLocker חברות מצומצמת.", "status": "machine-draft" } }, "ADTRADE-004": { "name": { "value": "היגיינת Password Replication Policy של RODC", "status": "machine-draft" }, "description": { "value": "Read-Only Domain Controllers שומרים במטמון סיסמאות עבור המשתמשים הרשומים ב-Password Replication Policy (PRP) שלהם. אם חשבון Tier-0 (Domain Admin, Enterprise Admin, krbtgt) נגיש דרך ה-PRP של RODC, ישירות או דרך קינון קבוצות, פריצת ה-RODC פורצת את החשבונות האלו. קבוצת ברירת המחדל 'Denied RODC Password Replication Group' צריכה להכיל במפורש DA / EA / SA / Schema Admins / krbtgt; חלק מהסביבות מתאימות אישית את המדיניות ומסירות בטעות שלילות אלו.", "status": "machine-draft" }, "recommendedValue": { "value": "לכל ה-RODC בדומיין יש Password Replication Policy שבו Domain Admins, Enterprise Admins, Schema Admins, krbtgt ו-Account Operators הם חברים בצד ה-Deny. אין חשבונות בעלי הרשאות גבוהות שהם חברים בצד ה-Allow.", "status": "machine-draft" }, "remediationSteps": { "value": "עבור כל RODC: Get-ADDomainController -Filter {IsReadOnly -eq $true} | ForEach-Object { Get-ADDomainControllerPasswordReplicationPolicy -Identity $_ -Allowed; Get-ADDomainControllerPasswordReplicationPolicy -Identity $_ -Denied }. ודא שרשימת ה-Denied מכילה את הקבוצה המובנית 'Denied RODC Password Replication Group'. אם בסביבה שלך אין RODC בדיקה זו אינה רלוונטית (N/A), PASS. מדריך התכנון של RODC מבית Microsoft מכיל את תבנית ה-PRP הקנונית.", "status": "machine-draft" } }, "ADTRADE-005": { "name": { "value": "החלפת מפתח של חשבון מחשב Entra Seamless SSO (AZUREADSSOACC$)", "status": "machine-draft" }, "description": { "value": "כאשר Entra (Azure AD) Seamless Single Sign-On מופעל עבור זהות היברידית, AD יוצר חשבון מחשב בשם AZUREADSSOACC$. הסיסמה שלו היא מפתח ה-Kerberos המשותף ש-Entra משתמש בו לאימות כרטיסי SSO. Microsoft מתעדת שמפתח זה אינו מוחלף אוטומטית; על המנהלים להחליף אותו. אם תוקף מחלץ את מפתח AZUREADSSOACC$ (מדובר בגיבוב NT רגיל הניתן לקריאה באמצעות DCSync או מבקר דומיין), הוא יכול לזייף Kerberos Silver Tickets עבור שירות Azure AD ולאמת בשם כל משתמש היברידי מסונכרן, ללא כל אינטראקציה נוספת, כל עוד המפתח נותר תקף. מפתח שלא הוחלף במשך יותר מ-90 ימים מרחיב באופן דרמטי את החלון הזה.", "status": "machine-draft" }, "recommendedValue": { "value": "מפתח ה-Kerberos של AZUREADSSOACC$ מוחלף לפחות כל 90 ימים (החלף אותו פעמיים בכל החלפה כדי לבטל את המפתח הקודם).", "status": "machine-draft" }, "remediationSteps": { "value": "החלף את מפתח ה-Seamless SSO במכונה עם מודול Entra Connect / Azure AD: Import-Module 'C:\\Program Files\\Microsoft Azure Active Directory Connect\\AzureADSSO.psd1'; New-AzureADSSOAuthenticationContext; Update-AzureADSSOForest. בצע את ההחלפה פעמיים (החשבון מאחסן את המפתח הנוכחי + הקודם) ותזמן אותה על בסיס חוזר. אם Seamless SSO אינו בשימוש עוד, השבת אותו ומחק את אובייקט AZUREADSSOACC$.", "status": "machine-draft" } }, "ADTRADE-006": { "name": { "value": "Shadow Credentials (msDS-KeyCredentialLink) על משתמשים מורשים", "status": "machine-draft" }, "description": { "value": "התכונה msDS-KeyCredentialLink מחזיקה מפתחות ציבוריים המשמשים לכניסת Windows Hello for Business / PKINIT ללא סיסמה. תוקף בעל גישת כתיבה לתכונה זו ביעד יכול להוסיף את זוג המפתחות שלו עצמו (Whisker / pyWhisker) ולאחר מכן לבקש Kerberos TGT בשם אותו חשבון באמצעות המפתח הפרטי התואם, טכניקת התמדה והתחזות חמקנית הידועה בשם 'shadow credentials'. יש להתייחס לכל פרט הזדהות מפתח בלתי צפוי על אובייקט Tier-0 (מנהל דומיין, בקר דומיין או כל חשבון adminCount=1) כאל דלת אחורית פוטנציאלית עד שיוכח שמדובר ברישום WHfB לגיטימי.", "status": "machine-draft" }, "recommendedValue": { "value": "אין ערכי msDS-KeyCredentialLink בלתי מזוהים על משתמשים מורשים/Tier-0; כל מפתח ממופה לרישום WHfB/ללא סיסמה ידוע.", "status": "machine-draft" }, "remediationSteps": { "value": "עבור כל משתמש שסומן, בדוק את פרטי ההזדהות של המפתחות (Get-ADObject -Properties msDS-KeyCredentialLink, או ה-cmdlet Get-ADKeyCredential של DSInternals) ותאם כל מפתח מכשיר לרישום Windows Hello for Business לגיטימי. הסר כל רשומה שאינך יכול לייחס לרישום מאושר. הגבל מי יכול לכתוב ל-msDS-KeyCredentialLink (בקר את Key Admins / Enterprise Key Admins ואת ה-DACL של ה-OU/אובייקט המעניקים כתיבה זו). אפס את החשבונות המושפעים אם קיים חשד לפריצה.", "status": "machine-draft" } }, "ADTRADE-007": { "name": { "value": "משטח הסלמה של מיגרציית dMSA (BadSuccessor)", "status": "machine-draft" }, "description": { "value": "Windows Server 2025 הציג delegated Managed Service Accounts (dMSA, מחלקת אובייקט msDS-DelegatedManagedServiceAccount) עם תכונת מיגרציה: ניתן לסמן dMSA כמחליף חשבון קיים, ולאחר מכן הוא יורש את ההרשאות ואת מפתחות ה-Kerberos של אותו חשבון. הטכניקה 'BadSuccessor' שנחשפה ב-2024 מנצלת זאת: משתמש שיכול רק ליצור dMSA ב-OU (CreateChild על מחלקת ה-dMSA, או write/GenericAll רחבים על ה-OU) יכול ליצור אחד, להפנות אותו לחשבון מורשה ולרשת את מפתחותיו, ובכך להסלים אל אותו חשבון מבלי להחזיק בהרשאות עליו ישירות. בדיקה זו עורכת מלאי של OU שבהם משתמש שאינו Tier-0 מחזיק ביכולת זו.", "status": "machine-draft" }, "recommendedValue": { "value": "אף משתמש שאינו Tier-0 אינו יכול ליצור או לכתוב delegated MSA (msDS-DelegatedManagedServiceAccount) באף OU.", "status": "machine-draft" }, "remediationSteps": { "value": "בכל OU שסומן, הסר CreateChild (עבור מחלקת msDS-DelegatedManagedServiceAccount), GenericAll, WriteDacl ו-WriteOwner ממשתמשים שאינם מנהלים. בקר את הרשאות ה-OU המואצלות באופן רחב; אותם ACE המאפשרים BadSuccessor מאפשרים גם ניצולי יצירת אובייקטים אחרים. עד לתיקון/הפחתה, נטר יצירת אובייקטי msDS-DelegatedManagedServiceAccount (אירועי 4662/5137). בדיקה זו מדלגת (SKIP) ביערות שהסכימה שלהם קודמת ל-Server 2025.", "status": "machine-draft" } }, "ADTRADE-008": { "name": { "value": "חברות בקבוצות Key Admins / Enterprise Key Admins", "status": "machine-draft" }, "description": { "value": "לקבוצות Key Admins (domain RID 526) ו-Enterprise Key Admins (RID 527) מוענקת הזכות לכתוב את התכונה msDS-KeyCredentialLink על פני הדומיין/היער. הדבר הופך כל חבר לפרימיטיב shadow-credential בהיקף כל הדומיין: חבר יכול לשתול פרטי הזדהות של מפתח בכל חשבון ולאמת בשמו באמצעות PKINIT. קבוצות אלו מסופקות ריקות וצריכות להישאר ריקות אלא אם תהליך עבודה ספציפי להקצאת מפתחות של Windows Hello for Business דורש אותן באופן מוכח. כל חבר הוא נתיב הסלמה שיש להצדיקו.", "status": "machine-draft" }, "recommendedValue": { "value": "קבוצות Key Admins ו-Enterprise Key Admins ריקות (אין חברים קבועים).", "status": "machine-draft" }, "remediationSteps": { "value": "בחן כל חבר ב-Key Admins וב-Enterprise Key Admins. הסר כל חשבון שאין לו צורך מתועד ומתמשך להקצות מפתחות של Windows Hello for Business. אם הקצאת מפתחות WHfB דורשת הרשאות מואצלות, הגבל אותן לחשבון שירות ייעודי עם ההרשאות הצרות ביותר האפשריות במקום חברות בקבוצות אלו בהיקף כל הדומיין. התייחס לחברים בלתי צפויים כאל מנגנון התמדה פוטנציאלי.", "status": "machine-draft" } }, "ADTRADE-009": { "name": { "value": "חברות בקבוצת Cert Publishers", "status": "machine-draft" }, "description": { "value": "חברי קבוצת Cert Publishers (domain RID 517) מורשים לפרסם אישורים למאגר NTAuth ולאובייקטי משתמש/מחשב. כברירת מחדל הקבוצה מכילה רק את חשבון(ות) המחשב של Enterprise CA. חשבון משתמש או שירות המוצב בקבוצה זו מקבל את היכולת להשפיע אילו אישורים מהימנים לאימות, מה שמהווה אבן דרך בכמה נתיבי הסלמה של AD CS (התקפות ממחלקת ESC) ויכול לאפשר התחזות מבוססת אישורים. חברות של חשבון מחשב (מארחי ה-CA עצמם) צפויה; כל חבר שאינו מחשב מהווה ממצא.", "status": "machine-draft" }, "recommendedValue": { "value": "Cert Publishers מכילה רק את חשבון(ות) המחשב של Enterprise CA, ללא חשבונות משתמש או שירות.", "status": "machine-draft" }, "remediationSteps": { "value": "הסר כל חשבון משתמש או שירות מקבוצת Cert Publishers; רק חשבונות מחשב של Enterprise CA שייכים לשם. בחן את תוכן מאגר NTAuth (certutil -viewstore -enterprise NTAuth) לגבי אישורי CA בלתי צפויים. הקשח את AD CS באופן רחב: בקר את הרשאות הרישום של תבניות אישורים ואת משטח התצורה השגויה של ESC1-ESC8.", "status": "machine-draft" } }, "ADTRADE-010": { "name": { "value": "מצב אבטחה וחשיפת סיסמה של group Managed Service Account (gMSA)", "status": "machine-draft" }, "description": { "value": "group Managed Service Accounts (gMSA) מחזיקים סיסמאות באורך 240 סיביות ש-AD מייצר ומחליף אוטומטית, ומבטלים Kerberoasting של סיסמאות חשבון שירות חלשות ואת הטרחה של החלפה ידנית. שני עניינים במצב האבטחה: (1) האם gMSA משמשים בכלל לזהויות שירות, ו-(2) מי מורשה לאחזר את הסיסמה המנוהלת, הנשלט על ידי מתאר האבטחה msDS-GroupMSAMembership (PrincipalsAllowedToRetrieveManagedPassword). אם מתאר זה מעניק גישה למשתמש רחב (Everyone, Authenticated Users, Domain Users) או למשתמש שאינו מורשה, אותו משתמש יכול לשחזר את סיסמת ה-gMSA בטקסט גלוי (למשל GMSAPasswordReader) ולהתחזות במלואו לשירות.", "status": "machine-draft" }, "recommendedValue": { "value": "זהויות שירות פועלות כ-gMSA; msDS-GroupMSAMembership מוגבל רק למארחים הספציפיים שחייבים להריץ את השירות (אין משתמשים רחבים או שאינם מורשים).", "status": "machine-draft" }, "remediationSteps": { "value": "עבור כל gMSA, הגדר את PrincipalsAllowedToRetrieveManagedPassword בדיוק לחשבונות המחשב (או לקבוצה מוגבלת בהדוקות) שמריצים את השירות: Set-ADServiceAccount -Identity <gmsa> -PrincipalsAllowedToRetrieveManagedPassword <hosts>. הסר את Everyone / Authenticated Users / Domain Users מהרשימה. במקומות שבהם חשבונות שירות עדיין משתמשים בסיסמאות חשבון משתמש סטטיות, העבר אותם ל-gMSA כדי לזכות בהחלפה אוטומטית ובעמידות ל-Kerberoasting.", "status": "machine-draft" } } } |