במהלך חקירת אירוע אבטחה, חוקר של Check Point נתקל בדרייבר קרנל שנראה בדיוק כמו כלי של תוקף: שם אקראי בן שמונה אותיות תחת system32\drivers, שירות זמני שנוצר רגע לפני אתחול, שגרות הצפנת RC4 בקוד, קריאה מקובץ נלווה חבוי (Alternate Data Stream), וניקוי עצמי אחרי הריצה. כל סימן מצביע על נוזקה. אבל הדרייבר היה חתום דיגיטלית על ידי מיקרוסופט, וההתנהגות התבררה בסופו של דבר כלגיטימית לגמרי: זו פעולת ניקוי רגילה של Windows Defender.

מה שהתחיל כחקירת התראת שווא הפך למחקר שפרסם Check Point Research ב-20 באוגוסט, וחתום עליו החוקר Jiří Vinopal. השאלה שהוא שאל פשוטה: אם הדרייבר הזה מקבל פקודות דרך קובץ מוצפן, מה מונע ממישהו לנסח את הפקודות בעצמו? התשובה, כפי שהמחקר מראה, היא שכמעט כלום. בהמשך נראה מה הדרייבר הזה עושה, איך בנוי פורמט הפקודות שלו, ולמה תזמון האתחול של Windows הופך אותו לכלי מחיקה שעוקף את מערך ההגנה של המערכת.

מה הדרייבר הזה עושה בכלל

לפעמים Defender צריך למחוק קובץ שנעול, למשל רכיב של נוזקה שרץ ברגע הזה ולא ניתן למחוק אותו בזמן שהמערכת פועלת. במקרים כאלה הוא דוחה את המחיקה לאתחול הבא. הרכיב שמבצע את זה נקרא BTR, קיצור של Boot-Time Removal Tool, והוא דרייבר קרנל שמיקרוסופט מטמיעה כמשאב פנימי בתוך הקובץ MpEngine.dll, מנוע הסריקה של Defender. כשצריך אותו, MpEngine.dll שולף את BTR.sys מתוך עצמו, כותב אותו לדיסק עם שם אקראי, ומתזמן אותו לרוץ באתחול.

זה דרייבר של "יריקה אחת": הוא נטען, מבצע רשימת פעולות, כותב דוח סטטוס, ומיד מבקש מהקרנל לפרוק את עצמו ולמחוק את עצמו מהזיכרון. הוא אפילו לא חושף ממשק פקודות רגיל (IOCTL). במקום זה הוא קורא את רשימת הפעולות שלו מקובץ נלווה מוצפן שמוצמד לדרייבר עצמו, מה שנקרא Alternate Data Stream: זרם נתונים נסתר שנתלה על קובץ קיים ב-NTFS ולא מופיע ברשימת הקבצים הרגילה. הנתיב לאותו זרם, ‎BTR.sys:changelist‎, יושב בערך רישום בשם Args תחת מפתח השירות של הדרייבר.

פורמט שאף אחד לא היה אמור לפענח

כאן מגיע החלק שהפך את הסיפור ממחקר מעניין לכלי מעשי. תוכן ה-changelist מוצפן ב-RC4 עם מפתח קבוע באורך 256 בתים שמוטמע ישירות בתוך הדרייבר, בקטע ‎.rdata‎. Vinopal חילץ את המפתח הזה, ואז גילה את הממצא המרכזי: המפתח זהה בכל 18 הגרסאות החתומות של BTR.sys שהוא אסף, לאורך כל מהדורות Windows מ-7 ועד 11. מפתח הצפנה שלא השתנה במשך יותר מ-15 שנה פירושו שמי שיודע אותו יכול להצפין ולפענח את קובץ הפקודות של הדרייבר בעצמו, בכל מחשב Windows.

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

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

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

חלון הזהב באתחול

עד כאן ראינו איך נותנים לדרייבר פקודות. הצד המעניין יותר הוא מתי הוא רץ. Vinopal מצא שאי אפשר לתזמן את BTR.sys לרוץ בשלב המוקדם ביותר של האתחול, כי הוא צריך גישה לקבצים כבר ברגע הטעינה, ובשלב הזה מערכת הקבצים עוד לא מוכנה. לכן הוא רץ מעט מאוחר יותר, בקבוצת טעינה בשם Boot Bus Extender. וכאן מסתתר הפער.

בנקודה הזאת של האתחול, מסנן הקרנל של Defender כבר טעון, אבל השירות המרכזי של האנטי-וירוס, ‎MsMpEng.exe‎, עדיין לא עלה. בהרצת מבחן על Windows 11 25H2 עדכני, השירות המרכזי עלה כ-34 שניות אחרי ש-BTR.sys כבר סיים את עבודתו, ורכיב בדיקת הרשת של Defender עלה כמעט ארבע דקות אחריו. Check Point מכנים את הפרק הזה "חלון הזהב": מערכת הקבצים כבר ניתנת לכתיבה, אבל מנגנוני ההגנה ברמת המשתמש עדיין רדומים.

בתוך החלון הזה הדגימו החוקרים מחיקה של הקבצים ‎WdFilter.sys‎ ו-‎MsMpEng.exe‎ עצמם. מכיוון שקובץ השירות של האנטי-וירוס נמחק לפני שמנהל השירותים בכלל מנסה להפעיל אותו, Defender פשוט לא עולה, ואיתו נעלמת גם היכולת שלו לתקן את עצמו או לדווח לענן. בהרצה חיה, בלי אתחול, הם גם הראו מחיקה של מפתחות השירות של Defender ברישום, מה שעוקף את Tamper Protection, ההגנה שאמורה למנוע שינוי הגדרות של האנטי-וירוס. ההגנה הזאת נאכפת בעיקר מול תהליכים ברמת המשתמש, ודרייבר קרנל חתום פשוט עובר מתחתיה.

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

לפי המחקר, בעקבות דיווח אחראי השיבה מיקרוסופט (דרך MSRC) שהממצאים אינם עומדים בקריטריונים לתיקון מיידי, מכיוון שהטכניקה מסתמכת על הרשאות מנהל קיימות. כדי לטעון את הדרייבר צריך את ההרשאה SeLoadDriverPrivilege, שממילא שמורה למנהלים. במילים אחרות, מי שכבר מנהל על המכונה יכול לעשות הרבה דברים רעים, וזה אחד מהם. אין תיקון מתוכנן, והדרייבר נשאר חתום ופעיל בכל גרסה.

זה מציב את BTR.sys בקטגוריה שהחוקרים מכנים LOLDriver, קיצור של Living-off-the-Land Driver: דרייבר לגיטימי שכבר קיים במערכת ומנוצל לרעה במקום להביא דרייבר פגיע מבחוץ. ההבדל מהטכניקה המוכרת של הבאת דרייבר פגיע (BYOVD) חשוב כאן. דרייברים פגיעים מצד שלישי נחסמים לרוב על ידי רשימת החסימה של מיקרוסופט לדרייברים פגיעים, אבל BTR.sys הוא רכיב מובנה וחיוני של Windows, ולכן הוא לא ברשימה הזאת ולא ייחסם על ידה. גם מנגנון ה-ELAM, שבודק דרייברים בשלב הטעינה המוקדם, לא רלוונטי: BTR.sys רץ אחרי השלב שבו ELAM פעיל.

איך בכל זאת מזהים את זה

מכיוון שמדובר ברכיב חתום של מיקרוסופט, חסימה לפי חתימה לא תעזור, וכלי כמו BTR_CLI מחקה בכוונה את ההתנהגות של פעולת הניקוי הלגיטימית. הזיהוי, לפי Check Point, חייב להסתמך על הקשר התנהגותי. הם מציעים כמה סימנים: ניטור יצירת ה-Alternate Data Stream מסוג ‎:changelist‎ (Sysmon Event ID 15), טעינת BTR.sys כשהתהליך שהפיל אותו לדיסק אינו חלק ממערך Defender אלא ‎cmd.exe‎ או ‎powershell.exe‎ (Event ID 6), והבדל עדין באופן ההתקנה: Defender האמיתי רושם את השירות דרך מנהל השירותים ומייצר אירוע מערכת 7045, בעוד הכלי ההתקפי כותב ישירות לרישום ומדלג על האירוע הזה.

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

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

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