סיפורי שטח: תקלות אמיתיות

משתמשים בסניף מתלוננים שסיסמה חדשה "לא עובדת" — אבל רק בסניף. במרכז הכול תקין.

1. 1repadmin /replsummary — DC אחד בסניף עם שגיאות מזה 14 יום.
2. 2ביומן Directory Service: אירוע 1988 — Lingering Object.
3. 3בירור: אותו DC היה כבוי חודשיים בזמן שיפוץ ואיש לא שם לב.
4. 4בדיקה מול הניטור — אף אחד לא התריע על רפליקציה.

DC שהיה מנותק מעבר ל־Tombstone Lifetime החזיק אובייקטים שכבר נמחקו, ו־AD חסם ממנו רפליקציה.

הורדנו את ה־DC, ניקינו מטא־דאטה (ntdsutil metadata cleanup) והקמנו אותו מחדש נקי. שינויי סיסמה חזרו לזרום תוך שעה.

ניטור רפליקציה חשוב לא פחות מניטור "שרת למעלה". DC שעונה ל־ping יכול להיות מת מבחינת AD.

מנהל אחד נעול כל בוקר ב־08:10. שחרור עוזר לשעתיים, ואז שוב.

1. 1ב־PDC Emulator חיפשנו 4740 — Caller Computer Name הצביע על שרת טרמינל.
2. 2בשרת: אירועי 4625 עם Logon Type 3 מדי כמה דקות.
3. 3בדקנו סשנים פתוחים: סשן RDP מנותק בן שלושה שבועות תחת אותו משתמש.

הסשן הישן החזיק את הסיסמה הקודמת ושלח אותה שוב ושוב אחרי שהמשתמש החליף סיסמה.

סגרנו את הסשן, והוספנו מדיניות שמנתקת סשנים מנותקים אחרי 8 שעות. הנעילות נעלמו.

נעילה חוזרת היא תמיד סימפטום. אל תשחרר בלולאה — מצא את Caller Computer Name.

אחרי החלפת ראוטר בסניף, המשתמשים גולשים אבל לא מצליחים להתחבר בלי "רשת" ומקבלים GPO ישנים.

1. 1ipconfig /all על תחנה: DNS = 192.168.1.1 (הראוטר).
2. 2nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.local — אין תשובה.
3. 3ביומן System: אירוע 1058 — לא ניתן לקרוא SYSVOL.

הראוטר החדש חילק DHCP משלו עם DNS של עצמו, ולכן התחנות הפסיקו למצוא את ה־DC.

כיבינו DHCP בראוטר, החזרנו את ה־Scope לשרת ה־Windows עם DNS = DC, ואז ipconfig /renew.

בדומיין, DNS של לקוחות תמיד מצביע ל־DC. "יש אינטרנט" לא אומר שהדומיין עובד.

ה־SOC קיבל התראה: משתמש רגיל ביקש 40 כרטיסי שירות ב־3 דקות, כולם ב־RC4.

1. 1אירועי 4769 עם Encryption Type 0x17 מאותו חשבון — חתימה קלאסית של Kerberoasting.
2. 2בדקנו אילו חשבונות עם SPN קיימים: נמצא svc_backup עם PasswordLastSet משנת 2017.
3. 3אירוע 4672 הראה שבתוך שעה svc_backup התחבר לשרת קבצים עם הרשאות גבוהות.

סיסמה קצרה וישנה על חשבון שירות עם SPN — התוקף שבר אותה אופליין תוך דקות.

החלפנו לסיסמה של 30 תווים, ואז העברנו את השירות ל־gMSA, וכיבינו RC4 בדומיין בהדרגה.

כל חשבון שירות עם SPN הוא סיסמה שאפשר לתקוף אופליין. gMSA פותר את זה לתמיד.

אחרי "תיקון" בווירטואליזציה, חלק מהמשתמשים לא מצליחים להתחבר וכמה שרתים איבדו אמון עם הדומיין.

1. 1אירועי 5722/5723 ביומן ה־DC — סיסמאות חשבונות מחשב לא תואמות.
2. 2repadmin הראה USN rollback על אחד ה־DC.
3. 3בירור מול צוות הווירטואליזציה: שוחזר Snapshot בן שבועיים.

שחזור Snapshot מחזיר את מסד ה־AD אחורה ויוצר USN Rollback — מצב שבו שינויים חדשים לא משוכפלים לעולם.

הורדנו את ה־DC הפגוע, ניקינו מטא־דאטה והקמנו מחדש. תחנות תוקנו ב־Test-ComputerSecureChannel -Repair.

DC לא משחזרים מ־Snapshot. משתמשים ב־Windows Server Backup / VM-Generation ID או פשוט מקימים DC חדש.

ב־SIEM נראתה שתיקה פתאומית משרת אחד, ולמחרת ביומן שלו יש רק אירוע אחד: 1102.

1. 1משכנו את הלוגים מה־Forwarder — שם ההיסטוריה נשמרה.
2. 2חצי שעה לפני: 4624 Type 3 ממחשב לא מוכר, ואז 7045 — שירות חדש עם שם אקראי.
3. 3אחר כך 4728 — הוספה ל־Domain Admins.

תוקף נכנס דרך תחנה עם סיסמה חלשה, התקדם לשרת, קיבל הרשאות אדמין וניקה את היומן כדי לטשטש.

בידוד, איפוס krbtgt פעמיים, החלפת סיסמאות פריבילגיות, וכפיית העברת לוגים בזמן אמת מכל השרתים.

לוג שנשמר רק על המכונה אינו ראיה. העבר לוגים החוצה — זו ההגנה הזולה ביותר שיש.