החוקרים התחילו מההנחה המתבקשת: מכונה שנדבקה בבוטקיט שמנצל חולשה מ-2022 היא מכונה שלא עודכנה. הם בדקו את ההנחה, והיא התמוטטה. המכונות הנגועות היו מעודכנות לגמרי.

את הסיפור הזה פרסמו ב-22 באוקטובר חוקרי Kaspersky גאורגי קוצ'רין, ולדימיר נסטור ווסילי ברדניקוב, אחרי שחקרו קמפיין ריגול שפעל בתחילת 2026 נגד גופים דיפלומטיים בטג'יקיסטן, אוזבקיסטן וטורקמניסטן. על המכונות הם מצאו קוד זדוני שנטען לפני שמערכת ההפעלה עולה, ולכן שולט בכל מה שקורה אחריו, כולל במוצרי האבטחה שאמורים לתפוס אותו. לסוג הזה קוראים בוטקיט UEFI, ולזה הם קראו BlackX. הוא דומה מאוד לבוטקיט מוכר בשם BlackLotus, שנעלם מהשטח ב-2023, והצוות מייחס את הקמפיין לקבוצה הסינית APT41 בביטחון בינוני.

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

מודעה בפורום ב-5,000 דולר, וספק שהתברר כמוצדק

באוקטובר 2022 הבחין צוות GReAT של Kaspersky במודעה בפורום האקרים. מישהו הציע למכירה בוטקיט UEFI בשם BlackLotus, שלפי ההבטחה עוקף את Secure Boot, המנגנון שאמור לוודא שרק קוד חתום ומאושר נטען בשלב האתחול לפני הקרנל. המחיר היה 5,000 דולר. יכולת כזאת במחיר כזה נשמעה לא סבירה, הקהילה לא מיהרה להאמין, ובלי דגימות בשטח לא היה מה לאמת.

הספק החזיק חצי שנה. במרץ 2023 אישרה ESET שהמודעה הייתה אמיתית: החוקרים מצאו דגימות והראו שהבוטקיט אכן עוקף Secure Boot דרך חולשה שנקראת Baton Drop. ב-NVD היא רשומה כ-CVE-2022-21894, ומקבלת ציון CVSS של 4.4 בלבד. ההסבר לציון הנמוך יושב בווקטור: הניצול דורש הרשאות מנהל על המכונה המקומית. זאת לא חולשה שפותחת לתוקף את הדלת, אלא כזאת שמקבעת אותו אחרי שהוא כבר בפנים.

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

אז למה מכונה מעודכנת בכל זאת נפלה?

כדי להבין את זה צריך לדעת מה Baton Drop עושה בפועל. היא לא שוברת שום חתימה דיגיטלית. היא מאפשרת לתוקף להחזיר למכונה גרסה ישנה של ה-boot manager של Windows, גרסה שהחולשה קיימת בה אבל החתימה שלה עדיין תקפה כי מיקרוסופט חתמה עליה בעבר, ומשם להריץ קוד. Secure Boot בודק חתימה, לא גיל. את החתימות שנפסלו המערכת מחזיקה ברשימה נפרדת, DBX, ומיקרוסופט עצמה מתארת את החולשה בדיוק כך: גלילה אחורה אל boot manager-ים שאינם ב-DBX.

הניסיון לסגור את זה עבר שני סבבים. בעדכוני מאי 2023 מיקרוסופט הוסיפה מדיניות שחוסמת boot manager-ים לפי מספר גרסה, והוסיפה ל-DBX את הגרסאות שהמדיניות לא כיסתה. אחר כך התברר שיש יותר מדרך אחת לעקוף גם את החסימה הזאת, ומיקרוסופט עברה לפתרון שורשי: לפסול את התעודה שחתמה על כל ה-boot manager-ים האלה מלכתחילה, Microsoft Windows Production PCA 2011.

וכאן הבעיה. הפסילה הזאת לא קורה כשמתקינים את העדכון. היא דורשת צעד ידני, ובמסמכי מיקרוסופט הוא מופיע במפורש כצעד אופציונלי: דגל ברישום תחת HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot, ומשימה מתוזמנת בשם Secure-Boot-Update. מנהל מערכת שהתקין את העדכון וראה שההתקנה הצליחה, סיים מבחינתו את העבודה. ההוראות להפעלה בפועל קבורות עמוק באתר של מיקרוסופט, וחוקרי Kaspersky מעריכים שאיש IT ממוצע פשוט לא נתקל בהן.

יש סיבה טובה לכך שהצעד ידני, והיא לא רשלנות. ברגע שמחילים את עדכון ה-DBX, המכונה מפסיקה לעלות מכל boot manager שחתום באותה תעודה משנת 2011. זה כולל מדיית שחזור קיימת, התקנה מ-USB, ואתחול מהרשת דרך PXE. מיקרוסופט מציינת ש-PXE צפוי להיפגע במיוחד, כי אי אפשר לעדכן את הקבצים שהשרת מגיש לפני שכל המכונות שתלויות בו עודכנו. אז התיקון שבאמת חוסם את החולשה הוא גם התיקון שעלול להשאיר ארגון בלי דרך לשחזר מכונה. לכן הוא נשאר אופציונלי.

לפי התוכנית המקורית זה היה אמור להיפתר מעצמו. המסמך של מיקרוסופט מגדיר "שלב אכיפה" שבו הפסילה תתבצע אוטומטית, בלי התערבות של המשתמש. השלב הזה עדיין לא התחיל, והתאריך שלו, לפי אותו מסמך, יוכרז במועד מאוחר יותר. ב-19 באוקטובר 2026, חמישה ימים לפני כתיבת השורות האלה, התעודה פגה מעצמה. הטבלה הרשמית של מיקרוסופט מציינת ליד Microsoft Windows Production PCA 2011 בדיוק את התאריך הזה, ואת התעודה שמחליפה אותה, Windows UEFI CA 2023. אבל תפוגה היא לא פסילה, וזה מה שהחוקרים מדגישים: היא לא מונעת מהקבצים הישנים להיטען כל זמן שהתעודה לא נמצאת ברשימת הפסולים.

עד כאן למה הדלת נשארה פתוחה. מה שנכנס דרכה בנוי בקפידה.

מה הבוטקיט מתקין על המכונה

התוקפים הגיעו ל-BlackX רק אחרי שכבר פרצו לרשת והשיגו הרשאות מנהל. מהשלב הזה ההתקנה היא שני קבצים: inst.exe, וקובץ בלי סיומת בשם PVMDIJGKAX2 שמוצפן ב-RC4. ההרצה נעשתה מהנתיב C:\ProgramData\Intel, והארגומנט השני של inst.exe הוא מפתח הפענוח.

החלוקה הזאת לא מקרית. קוצ'רין ועמיתיו מציינים ש-inst.exe עצמו לא מכיל שום מחרוזת זדונית ושום blob מוטמע, וכל מה שנדרש להתקנה יושב בתוך הקובץ המוצפן. זה מקשה על צוות תגובה לאירועים לשחזר את רכיבי הבוטקיט אחרי המעשה, כי מי שמצא רק את ההתקן לא מצא כלום.

ההתקנה כותבת קבצים למחיצת המערכת ולמחיצת ה-UEFI, והיעד שלה הוא התקנת מפתחות משל התוקף, Machine Owner Keys, שמאפשרים לטעון קובצי EFI שרירותיים ולתמרן את Secure Boot. ההשמשה של החולשה, לפי הדוח, דומה להפליא לזו של BlackLotus אבל לא זהה לה. קוד המקור של BlackLotus מעולם לא פורסם, ולכן Kaspersky מסיקה שהתוקפים או עשו לו הנדסה הפוכה, או קנו את הקוד מהפושעים שמכרו אותו. "בכל מקרה, זאת תצפית מעניינת, כי לעתים רחוקות אנחנו רואים שחקני APT שמשאילים רעיונות או קוד משחקני פשיעה", כתבו החוקרים.

המטען שנטען ב-UEFI עושה מה שבוטקיטים עושים: מזריק דרייבר זדוני לקרנל של Windows. הדרייבר חתום בתעודה של גוף סיני בשם Wenjiang District Mingyu Network Technology Service Studio, ונכון לפרסום הדוח התעודה נפסלה על ידי הגוף שהנפיק אותה. מה שהוא עושה אחר כך מכוון כולו למוצרי האבטחה שעל המכונה: נטרול callback-ים על תהליכים, thread-ים ורישום, ושיבוש של ספקי ה-ETW כדי שלא יוכלו לקרוא את הפלט שלהם. חלק מהשגרות רצות רק אם מותקן על המכונה מוצר של Kaspersky או של Avast, ו-Kaspersky מדווחת שבניתוח דינמי הן פשוט לא הצליחו להפריע למוצרים שלה.

ויש טריק אחד שראוי לציון בפני עצמו. הדרייבר מיירט בקשות קרנל לפתוח את קובצי הבוטקיט, ובמקום handle לקובץ הזדוני הוא מחזיר handle ל-calc.exe.

Google Drive ו-Yandex.Disk בתפקיד שרת שליטה

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

הראשון הוא כלי שליטה מרחוק שיכול לטעון מטענים נוספים ב-.NET. במקום להחזיק שרת שליטה ובקרה משלו (C2, השרת שממנו התוקף שולח פקודות לנוזקה), הוא משתמש בשירותי אחסון בענן, והחוקרים ראו גרסאות שעבדו מול Google Drive, OneDrive ו-Yandex.Disk. הכלי מתחבר לחשבון האחסון, עובר על הקבצים שיש שם, ומפרסר כל אחד לפי הסיומת שלו: סיומת אחת אומרת שזה קובץ .NET ושצריך להריץ ממנו מתודה מסוימת, אחרת מסמנת את התוצאה שחוזרת, ושתיים נוספות הן משימת העלאה ומשימת הורדה של קובץ. מידע המערכת הראשוני חוזר בקובץ שמסומן SSSR. מנקודת המבט של מנגנון ניטור תעבורה, כל זה נראה כמו מכונה שמדברת עם Google Drive.

המטען השני, ש-Kaspersky קראה לו OxiDLLRunner, הוא DLL זדוני שעבר עירפול בכלי OLLVM. הוא נטען דרך קובץ לגיטימי שמגיע עם הבוטקיט ושמו על הדיסק googleupdate.exe, אף שהשם המקורי שלו הוא jcef_helper.exe. הטכניקה נקראת DLL sideloading, והיא מסתמכת על כך שתוכנה לגיטימית טוענת ספרייה מהתיקייה שלה בלי לבדוק מי כתב אותה. ה-DLL מפענח קובץ בשם v8_context_snapshot.bin שיושב באותה תיקייה וקופץ לתחילת התוכן המפוענח, שם מחכים shellcode ואחריו קובץ PE, מטען שנכתב ב-Rust. המטען מדבר עם שרת ה-C2 בדומיין archivetj[.]com, ומקבל ממנו ספריות DLL שמייצאות פונקציה בשם create_plugin ומריץ כל אחת ב-thread נפרד.

למה מייחסים את זה ל-APT41, ובאיזו מידת ביטחון

כאן כדאי להיות מדויקים. Kaspersky מייחסת את הקמפיין ל-APT41 ב"ביטחון בינוני", וזה ניסוח שאומר משהו: הקשר נשען על שלושה סימנים עקיפים, לא על ראיה ישירה.

הראשון הוא מחרוזת. ביוני 2026 פורסם דוח של ESET על קבוצה בשם FishMonger, שהקהילה מקשרת ל-APT41, ובו תואר שתל קרנל שנתיב ה-PDB שלו מתחיל ב-C:\Users\xdd\Desktop. אותו דוח העלה גם אפשרות שבקמפיין שימש רכיב בוטקיט UEFI שלא זוהה, אפשר כזה שמנצל את CVE-2023-24932. את המזהה xdd מצאו חוקרי Kaspersky כמה פעמים במטענים של BlackX, ומכאן ההערכה שלהם ש-BlackX הוא בדיוק הרכיב שאליו ESET התייחסה. שני הסימנים האחרים כלליים יותר: טעינת מטענים דרך קובץ הרצה לגיטימי וקובץ מוצפן, תבנית שנפוצה אצל שחקנים דוברי סינית, והעירפול ב-OLLVM, שגם הוא מאפיין של אותה קהילה.

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

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

אם אתם מריצים Windows בארגון והנחתם ש-Baton Drop סגורה אצלכם כי העדכונים מותקנים, זאת ההנחה שכדאי לבדוק השבוע. השאלה היא לא אם העדכון הותקן, אלא אם הפסילה של התעודה הופעלה בפועל, כלומר אם הדגל ברישום והמשימה המתוזמנת קיימים ואם המכונות עברו קודם לכן לתעודת Windows UEFI CA 2023. מיקרוסופט מבקשת לעשות את זה על מכונות מדגם לפני הייצור, ומי שנכנס לזה מתחייב גם לעדכן את מדיית השחזור ואת שרתי ה-PXE. זאת עבודה אמיתית, וזאת בדיוק הסיבה שרוב הארגונים לא עשו אותה.