קובץ בשם zz-poc59310-syslog.log נחת בתיקייה /etc/cron.d/ על שרתי vCenter ברחבי העולם. הסיומת שלו היא .log, השם נראה כמו עוד קובץ יומן משעמם, והתיקייה שהוא נחת בה היא לא המקום שבו לינוקס שומר יומנים. זו התיקייה שממנה מערכת ההפעלה מריצה משימות מתוזמנות, כל דקה, בהרשאות root. חוקרי QUIRSO, חברת תגובה לאירועי סייבר גרמנית, נתקלו בקובץ הזה תוך כדי טיפול באירוע אצל לקוח, ומשם התגלגלו לספירה של 361 כתובות IP נגועות ב-47 מדינות.

לוח הזמנים הוא מה שהופך את זה למעניין. Broadcom פרסמה את התיקון ב-29 ביולי. באותו יום ממש כתבו ב-Rapid7 שאין עדות לניצול או לסריקות בשטח, ושאין בנמצא קוד exploit פומבי. חמישה ימים אחר כך, ב-3 באוגוסט, נרשמו החיבורים הראשונים משרתים נגועים אל התשתית של התוקף. ביום שאחרי נוספו 151 קורבנות חדשים, ועד ה-5 באוגוסט 343 מתוך 361 הכתובות כבר היו שם. אז מישהו בנה exploit יציב לחולשה קריטית, הקים תשתית, וסרק את האינטרנט, הכול בתוך חמישה ימים ובלי שהיה לו מאיפה להעתיק. בהמשך נראה איך שורת לוג אחת פותחת את הדלת, איך התוקף משכנע את vCenter למסור לו את פרטי האימות של עצמו, ולמה הסיפור נגמר בהצפנה של שרתי ה-ESXi.

איך שורת לוג הופכת למשימה שרצה כ-root

שרת ה-syslog של vCenter מקבל הודעות יומן ברשת וכותב אותן לקבצים, כשחלק משם הקובץ מגיע מתוך ההודעה עצמה. אם ההודעה מכילה רצף של קפיצות תיקייה אחורה, הכתיבה בורחת מתיקיית היומנים ונוחתת במקום אחר לגמרי על הדיסק. כוונו אותה אל /etc/cron.d/ ומערכת ההפעלה תריץ את התוכן כמשימה מתוזמנת, בהרשאות root, בלי שאיש יזדהה מול שום דבר. לטכניקה הזאת קוראים Path Traversal, וזו בדיוק CVE-2026-59310: ציון CVSS 9.8, ולפי העדכון של Broadcom אין לה שום דרך עקיפה חוץ מהתקנת הגרסה המתוקנת.

מה שנכתב לתוך קובץ ה-cron היה שורה אחת שעושה שלושה דברים ברצף: מורידה קובץ בשם linuxFile משרת HTTP על פורט 9861, מריצה אותו, ומוחקת את קובץ ה-cron שהריץ אותה. השורה שהפעילה את הכול מחקה את עצמה.

הקובץ עצמו העתיק את עצמו לתיקייה מוסתרת תחת /root/.local/share/, נרשם כ-service בשם sys-9436d8.service שמוגדר לעלות מחדש בכל כישלון, ופתח ערוץ WebSocket אל שרת שליטה ובקרה (C2, השרת שדרכו התוקף שולח פקודות לתוכנה הזדונית) בכתובת intel.se9ly9upbhay.shop על פורט 8080. באירועים אחרים אותה נוזקה הופיעה תחת השמות systemlog ו-linux_x86, ו-QUIRSO פרסמה עבורה חוקי YARA לזיהוי.

הדלת האחורית מתחפשת לתחזוקה של VMware

כאן מתחיל החלק שמסביר למה הקמפיין שרד כל כך הרבה זמן בלי שאיש שם לב. התוקף לא הסתפק ב-service אחד. הוא שתל שלוש משפחות של משימות מתוזמנות שנקראות על שם עבודות תחזוקה אמיתיות של VMware: vmware-vpxd-stats, vmware-perf-collect ו-vmware-perf-sync. מנהל מערכת שסורק את רשימת המשימות בשרת vCenter רואה שמות שהוא מכיר.

כל משפחה עושה משהו אחר. הראשונה מוודאת ש-SSH דולק, מזריקה את המפתח הציבורי של התוקף אל authorized_keys של root, ומכבה התחברות root באמצעות סיסמה. שימו לב לצעד האחרון: התוקף נועל אחריו את הדלת שדרכה נכנס, כדי שמישהו אחר לא ייכנס באותה דרך. שתי המשפחות האחרות שותלות webshell (עמוד קוד שרץ על השרת ומקבל פקודות דרך הדפדפן) בשם vmware-perf-update.jsp בתוך תיקיית האפליקציה של perfcharts, ומעניקות למשתמש perfcharts הרשאות sudo בלי סיסמה.

לערוץ הגישה עצמו התוקף השתמש בכלי קוד פתוח בשם reverse_ssh. בדרך כלל, כשמתחברים לשרת ב-SSH, אתם יוזמים חיבור פנימה אליו. כאן הכיוון הפוך: השרת הנגוע הוא שיוצר חיבור החוצה אל מכונה של התוקף, והתוקף רוכב חזרה על החיבור הקיים פנימה. חומת אש שחוסמת תעבורה נכנסת שלא ביקשו לא רואה בזה שום בעיה, כי מבחינתה מדובר בתעבורה יוצאת רגילה. סקריפט בשם esxi.sh רץ כל 60 שניות, זיהה את ארכיטקטורת המעבד, הוריד את הבינארי המתאים מ-185.144.28.120 על פורט 3232, וקיבע אותו כ-service בשם התמים network-manager.

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

התוקף מבקש מ-vCenter את פרטי האימות של vCenter

ב-vCenter יש רכיב בשם vmdir, שירות הספרייה שמנהל את זהויות המשתמשים בסביבה. הסיסמה שבה השרת עצמו מזדהה מול השירות הזה שמורה מקומית. סקריפט שרץ כ-root ניגש בדיוק אליה: הוא תשאל את מאגר ההגדרות המקומי דרך הכלי lwregshell וחיפש את המפתחות dcAccountDN ו-dcAccountPassword, וכגיבוי קרא לפונקציות של מודול ה-vmafd של VMware שמחזירות את שם המכונה, את הסיסמה שלה ואת שם הדומיין.

מכאן זה כבר לא פריצה אלא התחברות. עם פרטי האימות שחולצו, הסקריפט התחבר ל-LDAP המקומי על פורט 636 בהצפנה, עם נפילה חזרה לפורט 389 אם צריך, ויצר חשבונות מנהל בקבוצת ה-Administrators של ה-SSO. QUIRSO תיעדה שלושה: adminuser, vcadmin, וחשבון שירות שמתחיל ב-svc_ ואחריו מזהה. מרגע שקיים חשבון מנהל לגיטימי, כל הפעולות הבאות נראות בלוגים כמו עבודה שגרתית של אדמין.

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

מ-vCenter אל ה-ESXi, ומשם להצפנה

vCenter הוא הקונסולה שמנהלת את שרתי ה-ESXi, השרתים הפיזיים שעליהם רצות המכונות הווירטואליות בפועל. מי ששולט בקונסולה שולט בהם. התוקף יצר חשבון מקומי בשם adminuser על כל שרת ESXi, והשתמש בממשק ה-API של אחסון הנתונים כדי להעלות אליהם סקריפט בשם run.sh. הלוגים של vpxd מתעדים את הבקשה הזאת ב-4 באוגוסט בלילה, תחת שם המשתמש adminuser.

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

רק אז הגיע הקובץ האחרון, בינארי בשם backup. מדובר בכופרה שנגזרה מהקוד של Babuk, והיא מוסיפה לכל קובץ שהצפינה את הסיומת babyk. היא עוברת על נפחי ה-VMFS במלואם, ובקבצי הדיסק הווירטואליים היא מצפינה רק את 512 המגה-בייט הראשונים, מה שמספיק כדי להפוך אותם לחסרי שימוש והרבה יותר מהיר מהצפנה מלאה. בדרך היא הצפינה גם את יומני ה-ESXi. מי שמנסה אחר כך לשחזר מה בדיוק קרה מגלה שגם הראיות מוצפנות.

אז מי עומד מאחורי זה?

QUIRSO מייחסת את הקמפיין, ברמת ודאות בינונית בלבד, לגורם דובר סינית. הראיות שהיא מונה הן ההערה בסינית בתוך סקריפט חילוץ פרטי האימות, שימוש חוזר בשיטות שפורסמו בפרסום אבטחה סיני, הישענות על כלים מהסביבה הסינית כמו AList ו-x-ui, דפוס פעילות שמתאים לאזור זמן UTC+8, וקורבנות בעשרות מדינות בלי אף קורבן בסין עצמה. לזה נוספה מעידה תפעולית: מכונת בדיקות בשם kali.kali התחברה לתשתית הייצור תוך כדי ניסויים בגרסאות של reverse_ssh, וחשפה את הקו שבין הפיתוח לתפעול.

מה שחשוב פה הוא דווקא מה שהחוקרים סירבו לומר. "אין ברשותנו כרגע די ראיות כדי לקשור את הקמפיין לקבוצת תקיפה סינית מוכרת בשם, או לקבוע שהוא מונחה על ידי מדינת סין", כתבו ב-QUIRSO. הם כן מעריכים שהיכולת לבנות exploit אמין תוך חמישה ימים, להקים תשתית תומכת ולפגוע במאות מערכות עוד לפני שהיה PoC פומבי, מצביעה על יכולות ברמת APT.

במקביל תיעדה החברה פעילות אחרת לגמרי סביב CVE-2026-59309, חולשת עקיפת אימות בשירות הספרייה של vCenter שקיבלה גם היא ציון 9.8 באותו עדכון. ב-1 באוגוסט, יומיים לפני תחילת הניצול של החולשה השנייה, נוצר משרת יחיד חשבון מנהל בשם vcenter_admin, עם כלים שמזדהים בשמות GoodMoodle-VCProbe ו-GoodMoodle-VCFleet שלא זוהו כשום כלי מוכר. QUIRSO אומרת שלא הצליחה לקשור את השרשרת הזאת לקמפיין הראשי, וייתכן שמדובר בשחקן אחר.

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

אם יש לכם vCenter, הגרסאות המתוקנות הן 9.1.0.0300, 9.0.2.0100 ו-8.0 U3k, ואין תחליף חלקי. שרת שהיה חשוף לרשת בין ה-29 ביולי ל-5 באוגוסט ולא עודכן צריך להיבדק כאילו הוא נגוע, לא כאילו הוא בסיכון: חפשו קובצי cron בשמות של משימות VMware שלא אתם יצרתם, service שאתם לא מכירים, את ה-jsp בתיקיית perfcharts, וחשבונות מנהל ב-SSO שאף אחד לא זוכר שפתח. ה-IOC וחוקי ה-YARA פורסמו ב-מאגר של QUIRSO ב-GitHub.

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