ההודעה בטימס מגיעה ממי שנראה כמו התמיכה הטכנית של הארגון. שם התצוגה מתאים, שם ה-tenant שממנו היא נשלחה בנוי סביב שם החברה, ואחרי ההודעה מגיעה גם שיחה. בצד השני מסבירים למשתמש שיש תקלה שצריך לטפל בה, מבקשים ממנו לפתוח את Quick Assist, הכלי של Windows לשיתוף שליטה מרחוק, ולהקריא את הקוד שמופיע לו על המסך. הוא מקריא. מכאן לתוקף יש ידיים על המקלדת.

ב-30 באוקטובר פרסמו חוקרי Microsoft Threat Intelligence ניתוח של שתי חקירות שהתחילו בדיוק כך. את הדוח כתבו Sagar Patil, Jesse Birch ו-Tal Tzhori. בשתיהן הגיעו התוקפים מאותה שיחה אל אותו רכיב בדומיין, השרת שמנפיק תעודות דיגיטליות, ושם הם הוציאו לעצמם תעודות אימות בשם חשבונות בעלי הרשאות גבוהות. וזה מה שהופך את שתי החקירות למעניינות: תעודה כזאת ממשיכה לעבוד גם אחרי שמאפסים את הסיסמה של החשבון, וגם אחרי שמתקינים מחדש את העמדה שדרכה נכנסו. נעבור על הדרך מההודעה בטימס ועד DCSync, על שני המסלולים השונים שהתוקפים לקחו בשרת התעודות, ועל החרגה אחת בהגדרות התגובה האוטומטית שהשאירה דרך פתוחה לשרת הקבצים.

למה תעודה שווה לתוקף יותר מסיסמה

כמעט בכל ארגון שמריץ Active Directory יש גם שרת שמנפיק תעודות דיגיטליות למשתמשים ולמחשבים שבדומיין, בשביל התחברות ל-VPN, חתימה על דואר, אימות של מכשירים. הרכיב הזה נקרא Active Directory Certificate Services, ובקצרה AD CS. חלק מהתעודות שהוא מנפיק הן תעודות שאפשר להזדהות איתן, כלומר מי שמחזיק בתעודה כזאת מתחבר לדומיין בשם הזהות שכתובה בתוכה, בלי להקליד סיסמה בכלל.

כאן נכנסת לתמונה הבעיה שמיקרוסופט מנסחת ישר ולעניין: איפוס הסיסמה של המשתמש שנפרץ, או התקנה מחדש של העמדה הראשונה, לא מבטלים תעודה שכבר הונפקה ולא מבטלים כרטיסי Kerberos שכבר יצאו. במונחים של תגובה לאירוע זה אומר שהצעדים הראשונים שכל צוות עושה, איפוס והתקנה, פשוט לא נוגעים בנכס שהתוקף לקח. שני מסלולי ההסלמה שהחקירות נגמרו בהם מוכרים בשמות ESC1 ו-ESC8, והקיצורים האלה לא באו ממיקרוסופט אלא ממחקר Certified Pre-Owned של SpecterOps, שמיפה בשעתו את דרכי ההסלמה דרך AD CS ומנה אותן.

ההודעה, ה-Quick Assist, והארכיון שנפתח בתיקיית הפרופיל

שתי הפריצות התחילו בהודעות ובשיחות בטימס שהתחזו לאנשי תמיכה. לפי מיקרוסופט נעשה שם שימוש בשמות tenant מסוג onmicrosoft.com שנבנו סביב שם הארגון המותקף, ובשמות תצוגה שנשמעים כמו מוקד תמיכה. טימס עצמו מסמן שיחות כאלה בתגיות External ו-Scam suspected, והחוקרים מדגישים שהתגיות האלה הן סימן חשוב למשתמש ברגע האמת. מה שכן, מיקרוסופט אומרת במפורש שבשתי החקירות לא נוצלה שום חולשה בטימס, אלא רק הנדסה חברתית והגדרות מתירניות מדי ב-AD CS.

הרגע המכריע הוא אישור השליטה מרחוק. מיד אחרי שהמשתמש אישר, התוקף השתמש בחיבור כדי להניח ארכיון בתיקיית ההורדות שלו. פקודות שרצו באותו חיבור יצרו תיקיית הכנה עם שם שמתחיל ב-KB תחת תיקיית הפרופיל של המשתמש, פרקו לשם את הארכיון, והריצו את המטען בעזרת סביבת הרצה ניידת של Python, של Bun או של Java. באחת הגרסאות נמצא קובץ הרצה ששמו שונה אבל פרטי הגרסה שבתוכו עדיין זיהו אותו כ-Bun, סביבת ההרצה ל-JavaScript, והוא זה ששיגר את הטוען. בגרסה אחרת הורדה סביבת Java שהריצה קובץ קוד מקור של Java.

מכאן המסקנה המעשית של החוקרים לגבי זיהוי: שמות קבצים הם אינדיקטור חלש, כי קובץ הרצה ששמו שונה שומר על פרטי הגרסה המקוריים שלו. מה שכן עובד הוא התבנית, סביבת הרצה ניידת שמשוגרת מתוך תיקייה חדשה שהמשתמש יכול לכתוב אליה מיד אחרי חיבור שליטה מרחוק שלא היה אמור לקרות. הרכיבים שהוכנו שאלו את גרסת Windows, את הגדרות הרשת ואת רשימת התהליכים הרצים, והעמדה התחברה לתשתית הדומיין ב-LDAPS וב-SMB. החוקרים מזכירים נקודה שמקשה על חקירה פסיבית: ה-TLS של LDAPS מסתיר את תוכן השאילתות ממי שמסתכל רק על הרשת, ולכן צריך לחזור ליומני ה-endpoint ולשרתי הדומיין כדי לדעת מה התהליך בעצם ביקש.

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

מסלול ראשון: לבקש תעודה ולכתוב בה בעצמך בשם מי היא

בארגון הראשון הייתה תבנית תעודות שבה המבקש יכול למלא בעצמו את פרטי הזהות בבקשה, ולקבל בחזרה תעודה שאפשר להזדהות איתה. כשההגדרה הזאת מצטרפת להרשאות הנפקה רחבות ולדרישות אישור חלשות, חשבון בעל הרשאות משתמש בסיסיות יכול לבקש תעודה שמייצגת זהות מנהלית. לצירוף הזה קוראים ESC1.

הגל הראשון של הודעות הטימס כוון לשלושה חשבונות משתמש והביא לפריצה לעמדה אחת, ומשם הוציא התוקף תעודות לשלושה חשבונות בעלי הרשאות גבוהות. מנגנון ה-attack disruption של Microsoft Defender הגיב והגביל את המשתמש שנפרץ ואת שלוש הזהויות שהתעודות הוצאו עבורן: התחברויות מרחוק וגישת SMB נחסמו, וחיבורים פעילים נותקו. חשבון מנהלי אחד הוחרג מהתגובה האוטומטית, ולכן ההגבלה לא חלה עליו.

כשעים דקות אחרי שהחיבור הראשון נותק הגיע גל טימס גדול יותר, הפעם אל 16 משתמשים, ואיתו פריצה לעמדה נוספת. התוקף חזר לאותה תבנית פגומה והוציא תעודות לשמונה חשבונות מנהליים נוספים. התגובה האוטומטית כיסתה גם אותם, וחסמה יותר מ-1,000 ניסיונות גישה לקבצים ב-SMB ועוד ניסיונות התחברות. אבל שניות אחרי שהתעודה הגיעה לידיו, לפני שהחסימה נכנסה לתוקף במלואה, התוקף כבר הזדהה מול בקר דומיין והריץ DCSync, בקשת שכפול שבה תוקף מתחזה לבקר דומיין ומבקש מהדומיין להעביר לו את גיבובי הסיסמאות של החשבונות. התגובה האוטומטית הגבילה המשך של פעילות השכפול, אבל הפעולה עצמה כבר התחילה.

המנגנון עבד. הוא פשוט לא כיסה את כולם.

החשבון שהוחרג, ו-SearchApp.exe שהיה Rclone

החשבון המנהלי שהוחרג בגל הראשון נשאר זמין לתוקף, והוא המשיך להשתמש בו להתחברויות רשת ולהתחברויות אינטראקטיביות מרחוק. משם הוא הגיע לשרת קבצים והריץ שם עותק של Rclone, כלי קוד פתוח להעתקה וסנכרון של קבצים בין אחסונים, כששמו שונה ל-SearchApp.exe. הפקודה העתיקה באופן רקורסיבי מידע משיתוף בשרת הקבצים אל יעד SFTP חיצוני, עם 20 העברות במקביל, והיא סיננה מה ייכנס להעתקה: קבצים בני עד שלוש שנים, בהחרגה של סוגי קבצים של הרצה, מסדי נתונים, דיסקים וירטואליים, מדיה, קבצים זמניים ויומנים. (ההחרגות האלה מספרות בעצמן מה חיפשו שם, ולא חיפשו תוכנות.)

המסר שמיקרוסופט מוציאה מהמקרה הזה הוא שהכלה חלקית של זהויות יכולה לצמצם את הפעילות ועדיין להשאיר לתוקף מסלול מנהלי שעובד. במילים אחרות, אחד-עשר חשבונות מנהליים קיבלו תעודות בשני הגלים. התגובה האוטומטית כוונה אל כולם, אבל על אחד מהם היא לא חלה, והוא זה שהספיק להוציא מידע מהארגון.

מסלול שני: לגרום לבקר הדומיין להזדהות מול התוקף

בארגון השני תבנית התעודות הפגומה לא הייתה שם, אז התוקף עבד אחרת. הוא שלח לבקר הדומיין בקשות בפרוטוקול EFSRPC, הפרוטוקול המרוחק של מערכת הקבצים המוצפנת של Windows, כדי לגרום לבקר עצמו לפנות למערכת בשליטת התוקף ולהזדהות מולה עם חשבון המכונה שלו. לטכניקה הזאת קוראים PetitPotam. את ההזדהות הזאת, שמגיעה בפרוטוקול NTLM, הוא מיחזר הלאה אל ממשק הרשת של AD CS להנפקת תעודות, Web Enrollment, שקיבל NTLM בלי הגנה מספקת נגד מיחזור. זה ESC8, והתוצאה היא שהתוקף ביקש וקיבל תעודה בתבנית Domain Controller בשם בקר הדומיין, בלי לדעת את הסיסמה שלו. נתיבי השליחה והאיסוף של הבקשה יושבים תחת /certsrv.

את התעודה החדשה הוא ניצל ל-PKINIT, ההזדהות ל-Kerberos באמצעות תעודה במקום סיסמה, וקיבל כרטיס TGT בשם בקר הדומיין. בנקודה הזאת הזדהות NTLM ממוחזרת הפכה לזהות Kerberos מגובה בתעודה, וזה כבר שווה ערך למפתחות של הדומיין. החוקרים מצביעים על הסימן שהיה אמור להקפיץ את החקירה: שרת ה-AD CS אימת את חשבון המכונה של בקר הדומיין, אבל החיבור הגיע ממכשיר אחר לגמרי. אי-ההתאמה בין הזהות למקור היא, לדבריהם, נקודת הפתיחה הטובה לחקירה, ומשם מצליבים את חשבון המכונה, המכשיר השולח, בקשת ה-Web Enrollment, רשומת ההנפקה של ה-CA והפעילות ב-Kerberos שבאה אחריה.

אז למה האירוע הזה נגמר אחרת? Defender הוציא התראות שקושרו ל-ESC8, הלקוח בודד את העמדה שממנה רצו ההנפקה והפעילות ב-Kerberos, ולפי הדוח לא נצפתה התקדמות נוספת אחרי הבידוד. ההפרש בין שתי החקירות הוא לא בתחכום של התוקף, שעשה בשני המקרים בדיוק את מה שהסביבה אפשרה לו, אלא בכיסוי של התגובה: במקרה אחד הוחרג חשבון ונשאר שימושי, ובשני נותקה נקודת ההרצה הפעילה. מיקרוסופט מציינת שהפעילות בשתי החקירות לא יוחסה לקבוצת תקיפה מסוימת.

מה זה אומר בפועל

אם אתם מריצים AD CS, שתי הבדיקות ששוות את הזמן שלכם השבוע הן התבניות וממשק האינטרנט. עברו על התבניות שאפשר להזדהות עם התעודות שלהן וחפשו את השילוב שאיפשר את ESC1, פרטי זהות שהמבקש ממלא בעצמו יחד עם הרשאות הנפקה רחבות ודרישות אישור חלשות, והסירו הרשאות שאין להן צורך. במקביל עשו רשימה של נתיבי ה-Web Enrollment וה-Certificate Enrollment Web Service שפתוחים אצלכם, הורידו את מה שלא נדרש, ועל מה שנשאר דרשו HTTPS ואכפו EPA, אותו קישור בין החיבור להזדהות שמונע את המיחזור. ההנחיות נמצאות ב-KB5005413 של מיקרוסופט, ול-Defender for Identity יש בדיקות מוכנות שמסמנות תבניות חשופות ל-ESC1 ונתיבי IIS לא מאובטחים שקשורים ל-ESC8.

שתי נקודות תפעוליות שהחקירות האלה מחדדות שוות הקפדה נפרדת. החרגה של חשבון או מכשיר מהתגובה האוטומטית היא החלטה באירוע, לא הגדרה ששוכחים, ומי שמחריג צריך לשבץ במקומה פעולה ידנית ולוודא שהיא בוצעה. וביטול תעודה לא מבטל למפרע כרטיסי Kerberos שכבר הונפקו, כך שאחרי אירוע כזה צריך לעבור על הכרטיסים הפעילים בנפרד מרשימת התעודות. ולמשתמשים עצמם יש כאן מסר אחד פשוט: פנייה מהתמיכה שלא ביקשתם מאמתים בערוץ פנימי מוכר לפני שמשתפים מסך ולפני שמקריאים קוד חיבור, כי ברגע שהקוד נאמר בקול, כל השאר הוא רק עניין של זמן.