אדמין מריץ Get-MpPreference על מכונה חשודה, מסתכל ברשימת ההחרגות של Microsoft Defender Antivirus ורואה רשימה ריקה. אין תיקייה שהוצאה מהסריקות, אין סיומת מוחרגת, הכול נראה בסדר. בפועל יש שם החרגה, והיא פשוט לא מוצגת לו. לא בגלל שחסרות לו הרשאות, אלא בגלל ערך בודד ברג'יסטרי שמישהו הדליק לפני כן.

את המקרה הזה מתאר ג'ונתן ג'ונסון מצוות ה-endpoint של Huntress, בסקירה שפורסמה ב-30 בספטמבר. הנושא שלה הוא לא חולשה חדשה אלא יכולת שמיקרוסופט חושפת בכוונה: רשימת ההחרגות של Defender, שמאפשרת למי שיש לו הרשאות אדמין להוציא קבצים, תיקיות וסיומות מהסריקה. "זיהינו שהחרגות MDAV נמצאות בשימוש יותר ממה שהנחנו בתחילה", כותב ג'ונסון. בהמשך נראה למה החרגה עדיפה לתוקף על כיבוי האנטי-וירוס, לאן בדיוק היא נכתבת, ומה המתג שמעלים אותה גם ממשתמש SYSTEM.

למה החרגה עדיפה לתוקף על כיבוי

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

ג'ונסון מונה ארבעה סוגי החרגה שממשק ההגדרות של Defender חושף. Process מפסיק סריקה בזמן אמת של קבצים שתהליך מסוים פותח, Path מוציא נתיב שלם, Extension מוציא סיומת קבצים באשר היא, ו-IpAddress מפסיק בדיקת תעבורה שנכנסת מכתובת מסוימת. לפי Huntress, שתי ההחרגות השימושיות לתוקף הן Path ו-Extension, מסיבה פשוטה: הן מוציאות את מה שתואם להן גם מסריקות מתוזמנות, גם מסריקות לפי דרישה וגם מההגנה בזמן אמת. התיעוד של מיקרוסופט מחדד את ההבדל מהצד השני, ומציין שהחרגות Process הן החריג: הן תקפות רק להגנה בזמן אמת, לא לסריקות מתוזמנות או לפי דרישה.

ארבע דרכים, ובסוף אותו רג'יסטרי

יש ארבע דרכים להכניס שורה לרשימה הזאת, וג'ונסון עקב אחרי כל אחת מהן. כשמגדירים החרגה מ-PowerShell, דרך Set-MpPreference או Add-MpPreference, הקריאה עוברת במחלקת ה-WMI בשם MSFT_MpPreference, משם ממשיכה ב-COM וב-RPC, ובסוף ההרצה מגיעה ל-MsMpEng.exe, הקובץ הריצה של Defender עצמו. הוא זה שכותב את ההחרגה תחת המפתח HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions.

החרגה שמגיעה מ-GPO הולכת במסלול אחר לגמרי. היא עוברת במופע ה-gpsvc של svchost ונכתבת למפתח שונה, תחת HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Exclusions. שני מפתחות נפרדים, וכששואלים את המערכת מה מוחרג היא מחזירה את התוכן של שניהם, מה שאומר שהחרגה שנכתבה דרך מדיניות נראית בשאילתה כמו כל החרגה אחרת.

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

המתג שמעלים את ההחרגות גם מ-SYSTEM

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

מיקרוסופט מתעדת אותו בעצמה, באותו עמוד הגדרה, כאמצעי להגן על החרגות מנוהלות. היא כותבת שהוא אינו מוחק החרגות קיימות מהמכונה, שההחרגות "אינן נראות ב-Get-MpPreference או ב-Registry Editor", ושהערך המקביל HideExclusionsFromLocalUsers נדלק אוטומטית יחד איתו. (וההיפוך כאן לא חסר הומור: מתג שנבנה כדי להגן על ההחרגות מפני אדמין מקומי סורר הוא גם המתג שמסתיר אותן מהאדמין שמחפש פריצה.)

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

למה זה משנה בפועל? כי לא מעט מוצרי אבטחה שואלים את Defender מה מוחרג דרך אותו ממשק PowerShell או דרך מחלקת ה-WMI. מוצר שבונה את התמונה שלו משם מקבל רשימה ריקה ומדווח שהכול נקי.

הטכניקה הזאת מ-2019, וזה בדיוק העניין

ההחרגות לא נכנסו לארגז הכלים השבוע. בספטמבר 2019 דיווח BleepingComputer על דגימה של סוס טרויאני בנקאי בשם GootKit, שנמצאה על ידי החוקר JamesWT ונותחה בידי ויטלי קרמז. הנוזקה בדקה קודם אם Defender דלוק בכלל, ואם כן עקפה את התראת ה-UAC דרך רכיב מערכת לגיטימי של Windows, כדי להריץ בלי אישור קריאה למחלקת MSFT_MpPreference שהוסיפה את התיקייה שלה לרשימת ההחרגות. בסוף היא אימתה שההחרגה אכן נכנסה, ומחקה אחריה את ערכי הרג'יסטרי ששימשו לעקיפה.

ינואר 2022, ואותו רעיון בגרסה גסה בהרבה. הדוח של Unit 42 על WhisperGate, הנוזקה ההרסנית שתקפה ארגונים באוקראינה, מתאר סקריפט VBS שקרא ל-PowerShell והחריג את כונן C בשלמותו, ורק אחר כך ניגש למחוק ולעצור את Defender. Huntress מוסיפה לרשימה גם את Muddled Libra ב-2024, בלי לפרט שם את השיטה.

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

אז למה tamper protection לא בהכרח מכסה אתכם

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

רק שלהגנה על ההחרגות דווקא יש תנאי כניסה, והם מופיעים בעמוד נפרד. המכונה צריכה לרוץ על גרסת פלטפורמה 4.18.2211.5 מנובמבר 2022 ומעלה, ההגדרה DisableLocalAdminMerge צריכה להיות דלוקה כדי שהגדרות מקומיות לא ימוזגו עם מדיניות הארגון, המכונה צריכה להיות מנוהלת רק ב-Intune או רק ב-Configuration Manager עם חיישן Defender for Endpoint פעיל, וההחרגות עצמן צריכות להיות מנוהלות משם. ארגון שמנהל את ההחרגות שלו ב-GPO לא עומד בתנאים האלה.

הזווית של Huntress שונה, ונובעת ישירות מהמסלולים: מכיוון שכל ארבע הדרכים נגמרות בכתיבה לרג'יסטרי, צוות ה-endpoint שלה העביר את איסוף הטלמטריה לרמת פעולות הרג'יסטרי ולא לרמת הפקודה. ככה החרגה שהוגדרה ב-PowerShell, ב-WMI, ב-GPO או בכתיבה ידנית נראית אותו דבר. על זה הם הוסיפו זיהוי להחרגות על מקומות חשודים, בהם כונן C כולו, Temp ו-Downloads, וזיהוי נפרד לרגע שבו מישהו מדליק את HideExclusionsFromLocalAdmins.

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

אם יש לכם Defender בארגון, שווה להסתכל הערב ברשימת ההחרגות של כמה מכונות, ולא רק דרך Get-MpPreference: גם במפתח ה-Policies שה-GPO כותב אליו, וגם בערך HideExclusionsFromLocalAdmins. אם הוא דלוק ואף אחד אצלכם לא הדליק אותו, יש לכם נקודת פתיחה לחקירה. בדקו גם אם אתם עומדים בארבעת התנאים שמיקרוסופט מציבה להגנת שינוי על החרגות, כי בסביבה שמנוהלת ב-GPO בלבד התשובה היא כנראה לא. ומעבר לכל זה, החרגה חדשה היא שינוי שצריך להגיע אליכם כהתראה בזמן אמת, לא פרט שמתגלה אחרי שהנוזקה כבר עבדה שבועיים.