אל התקן BeyondTrust Remote Support אחד הגיעה בסוף אוגוסט בקשת POST לכתובת שנראית כמו שגיאת הקלדה: app_84304470%2Ephp. כ-11 דקות אחר כך נרשמה במערכת הקבצים יצירה של קובץ חדש בתיקיית ה-web של ההתקן, בשם mangoapi.php. את הקובץ שאליו פנתה הבקשה הראשונה חוקרי Mandiant לא הצליחו לשחזר. את כל מה שבא אחריו הם כן שחזרו, כמעט צעד אחר צעד, מתוך יומנים ששכנו על מחיצה מוצפנת בתוך ההתקן.

ב-15 באוקטובר פרסמה BeyondTrust את החולשה שאיפשרה את זה, CVE-2026-102764, ובאותו יום פרסמו Google Threat Intelligence Group ו-Mandiant את הניתוח של מה שקרה על ההתקן אחרי הפריצה. החולשה קיבלה ציון CVSS 9.3, והיא נוצלה כחולשת יום-אפס מול לקוח אמיתי כחודש וחצי לפני שהחולשה פורסמה. בהמשך נראה מה בעצם עושה ההתקן הזה ולמה הוא מטרה שווה כל כך, איך התוקף עלה ממשתמש חסר הרשאות ל-root, ומה הוא עשה כדי שהגישה שלו תשרוד גם אתחול וגם איפוס הגדרות.

מה בעצם עושה ההתקן, ולמה דווקא הוא

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

הרכיבים הפנימיים של ההתקן מחליפים ביניהם הודעות, ולפי הרשומה הרשמית של היצרן הם לא בדקו כראוי מאיפה ההודעות האלה הגיעו. בניסוח של BeyondTrust עצמה, "בתנאים הנכונים" זה מאפשר לתוקף לבצע פעולות על קבצים בהתקן. Mandiant מנסחים את התוצאה בפשטות: ניצול מוצלח מביא להעלאת קבצים שרירותית. אין צורך בשם משתמש, אין צורך בסיסמה, ואין צורך שמישהו בצד השני ילחץ על משהו. לפי GTIG החולשה קיימת בכל גרסאות Remote Support הנתמכות עד 26.2.3 ועד בכלל.

הציון 9.3 חושב בתקן CVSS 4.0, ובזמן הכתיבה הרשומה ב-NVD עדיין מסומנת כ"התקבלה", כלומר הניתוח העצמאי של NVD לא הושלם. גם בקטלוג החולשות המנוצלות של CISA היא לא מופיעה עד כה, למרות שהניצול בפועל מתועד בדוח. (וזאת, אגב, הפעם השנייה השנה שאותו מוצר של BeyondTrust מקבל תיקון חירום על חולשה שנוצלה בשטח: הקודמת, CVE-2026-1731, נכנסה לאותו קטלוג בפברואר.)

מ-404 מזויף להרשאות root

הקובץ mangoapi.php הוא מה ש-Mandiant קוראים לו SAWFLY: סקריפט PHP קטן ומעורפל שנשאר יושב בתיקיית ה-web ומחכה לפקודות. הוא בודק בכל בקשת POST שמגיעה אליו אם היא כוללת פרמטר אחד מסוים, בשם מבולבל. אם הפרמטר חסר, הסקריפט מחזיר 404 ונסגר. זה לא באג, זו ההסתרה: סורק אבטחה אוטומטי או crawler שעוברים על ההתקן מקבלים בדיוק את אותה תשובה שהם מקבלים מכל נתיב שלא קיים, וממשיכים הלאה.

כשהפרמטר כן מופיע, ה-webshell מפרסר את התוכן שלו, מפענח אותו בשני שלבים (קידוד Base32 בגרסה משל התוקף, ומעליו הצפנת RC4 במפתח בן 32 בייט שמוטבע בקוד עצמו) ומריץ את הקוד שיוצא מזה. התשובה חוזרת באותו צינור, מוצפנת ומקודדת חזרה. כך נראה שרת שליטה ובקרה (C2, הערוץ שדרכו התוקף שולח פקודות לתוכנה הזדונית ומקבל בחזרה תוצאות) כשהוא מוסתר בתוך תעבורת HTTPS רגילה אל התקן שאמור לקבל תעבורה כזאת ממילא.

ה-webshell רץ בהרשאות של חשבון השירות של האתר, משתמש מקומי בלי שום הרשאה מיוחדת. כאן נכנס לתמונה טריק עתיק של יוניקס. התוקף העתיק את ה-shell של המערכת, /bin/sh, לקובץ חדש בשם /usr/bin/dbus-authd, שינה את הבעלות עליו ל-root והדליק עליו דגל שאומר למערכת ההפעלה להריץ את הקובץ בהרשאות של הבעלים שלו ולא בהרשאות של מי שהפעיל אותו. לדגל הזה קוראים SUID. מהרגע הזה כל מי שיכול להריץ את הקובץ מקבל shell בהרשאות root, והשם שנבחר לו נשמע כמו עוד service משעמם של המערכת.

הכספת, היומנים, ומה ששורד אתחול

עם root ביד, הדבר הראשון שהתוקף עשה היה ללכת לכספת. בהתקן יש כלי שורת פקודה קנייני, /ns/sbin/bt-secrets, שדרכו מנהלים מנהלים את הסיסמאות, מפתחות ה-API ופרטי האימות ל-endpoints. Mandiant תיארו איך התוקף עבר שיטתית על כמה גרסאות תחביר של הכלי עד שמצא את זו שעובדת, התחיל מהכספת של חשבון השירות ובסוף פנה לכספת הגלובלית של ההתקן כולו, זו שמחזיקה את פרטי האימות של כל המנהלים. אחרי זה הוא מחק את יומן הפעולות של אותו כלי בדיוק.

זאת לא הייתה המחיקה היחידה. במהלך הפריצה נמחקו גם יומני ההזדהות, יומני ה-SSL, יומני הגישה של שרת ה-web ו-/var/log/messages. את החלק הזה כדאי לקרוא ביחד עם אחת ההמלצות בסוף הדוח: ארגון שמעביר יומנים לשרת חיצוני יכול לזהות את הפריצה דווקא לפי החור, כי פער של סשן אחד בהעברת היומנים הוא סימן חזק לכך שמישהו נגע בהם.

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

אז איך התוקף יצא מההתקן אל שאר הרשת?

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

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

הצעד השני היה צינור. התוקף הפעיל על ההתקן כלי קטן שכתוב ב-C, ש-Mandiant קוראים לו BARECLAW, שמקים proxy מסוג SOCKS5 ומעביר אותו בתוך חיבור WebSocket, כלומר בתוך מה שנראה לכל ציוד רשת בדרך כמו חיבור web מתמשך ולא כמו מנהרה. הוא הופעל כך שיאזין בפורט 19800, ידרוש token, יערבל את התעבורה ב-XOR על בסיס אותו token, ויכתוב אפס שורות ליומן.

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

למה הכול מצביע על ARMORY CASTLE

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

לקבוצה הזאת יש היסטוריה שמתאימה בדיוק למקרה. לפי GTIG היא פעילה לפחות מאוקטובר 2023, והיא התמחתה בחולשות יום-אפס בהתקני קצה ארגוניים. החוקרים כותבים שהם מעריכים "ברמת ודאות גבוהה" שהקבוצה תמשיך לנצל חולשות יום-אפס בהתקנים כאלה כדי להיכנס לסביבות, ומזהירים מתרחיש ספציפי: שאחרי הפרסום תתחיל השמשה רחבה של החולשה, בדומה למה שקרה ב-2024 אחרי שנחשפו שתי חולשות ב-Ivanti Connect Secure. GTIG לא פרסמו מספר קורבנות ולא שמות ארגונים, והראיה המתועדת בדוח היא על התקן אחד.

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

אם אתם מריצים BeyondTrust Remote Support בהתקנה מקומית, התיקון BT26-05 הוא משהו להתקין עכשיו ולא בחלון התחזוקה הבא. לקוחות SaaS כבר מכוסים: BeyondTrust החילה את התיקון על כל הדיירים ב-9 באוקטובר. מה שחשוב להבין הוא שהתיקון סוגר את הדלת ולא מנקה את מה שנכנס דרכה, ולכן ההמלצה של Mandiant היא להתייחס לכל התקן שהיה חשוף לאינטרנט בגרסה חשופה בחלון הניצול כאל התקן שאפשר שנפרץ, עד שתיערך עליו בדיקה.

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