CVE-2026-59310: מה חושפת המתקפה על VMware vCenter

CVE-2026-59310 כבר אינה רק משימת תיקון בעדיפות גבוהה. מדובר בחולשה קריטית בשרת Syslog של VMware vCenter, שנחשפה ותוקנה על ידי Broadcom ב-29 ביולי 2026 — אך חוקרים זיהו ניצול פעיל שלה החל מ-3 באוגוסט, חמישה ימים בלבד לאחר פרסום התיקון. הקמפיין כלל 361 כתובות IP שנצפו ב-47 מדינות, והשתמש ב-Reverse SSH כדי לשמור על גישה למערכות שנפרצו. בעקבות זאת קבעה Shadowserver כי מערכות שבהן אותר מנגנון זה צריכות להיחשב כמחויבות לחלוטין.

מה מאפשרת CVE-2026-59310?

Broadcom וה-National Vulnerability Database, מאגר החולשות הלאומי של ארצות הברית, מתארים את CVE-2026-59310 כחולשת מעבר ספריות בשרת Syslog של vCenter. תוקף עם גישה לרשת אל vCenter אינו נדרש להזדהות, ויכול לנצל את החולשה כדי להריץ קוד שרירותי במערכת. החולשה קיבלה ציון CVSS של 9.8 — רמת חומרה קריטית.

במונחים מעשיים, vCenter חשוף עלול להפוך לנקודת כניסה להתבססות בתוך התשתית הווירטואלית ולהרחבת הגישה למערכות נוספות. חלק מהדיווחים מתארים הרצת קוד בהקשר הרשאות root, אך התיאורים הסמכותיים ביותר של Broadcom ושל מאגר NVD מבססים בעיקר את הסיכון להרצת קוד שרירותי, ולא מספקים תמונה מלאה לגבי ההרשאות בכל חדירה.

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

ציר הזמן: תיקון ב-29 ביולי, ניצול ב-3 באוגוסט

Broadcom חשפה את CVE-2026-59310 ופרסמה תיקונים ב-29 ביולי. QUIRSO דיווחה על סימנים לניצול פעיל החל מ-3 באוגוסט, ולאחר מכן על התרחבות מהירה של הקמפיין.

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

היקף הקמפיין

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

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

מדוע החוקרים חושדים בזיקה לסין?

QUIRSO העריכה בסבירות בינונית כי לקמפיין יש זיקה לסין. בין הסימנים שצוינו: ממצאים בשפה הסינית, כלי תקיפה ומחקר שפורסם בעבר ונעשה בו שימוש חוזר, פעילות שתאמה לשעות עבודה באזור UTC+08:00, וכן דפוס קורבנות שנראה כי אינו כולל את סין היבשתית.

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

שרשרת החדירה שדווחה

לפי הדיווחים, הקמפיין השתמש ב-CVE-2026-59310 לצורך הרצת קוד ראשונית, ולאחר מכן התקין כמה שכבות של התמדה וגישה:

1. מעבר ספריות: בקשות מעוצבות לשרת Syslog שימשו ליציאה מהנתיב המיועד ולכתיבת תוכן שבשליטת התוקפים.
2. התמדה באמצעות cron: התוקפים יצרו, לפי הדיווחים, רשומות cron פגומות שאפשרו להפעיל פקודות המשך.
3. העברת דלת אחורית: הפקודות curl או wget הורידו דלת אחורית בשם linuxFile, שהשתמשה ב-WebSocket ובערפול באמצעות XOR.
4. Reverse SSH: התוקפים התקינו כלי Reverse SSH שיצר חיבור יוצא אל תשתית שבשליטתם. Shadowserver דיווחה שמנגנון זה הופיע אצל כל הקורבנות שנכללו בדוח המיוחד שלה.
5. ניצול חשבונות והרשאות: החוקרים דיווחו על חשבונות מנהל מערכת לא מורשים ב-vCenter וב-ESXi, וכן על שימוש לרעה בהרשאות של VMware Directory Service.
6. פריסת כופרה: לפחות חלק מהדיווחים קישרו את הפעילות לגרסת כופרה שמקורה ב-Babuk ומוסיפה לקבצים את הסיומת .babyk.

ממצא ה-Reverse SSH חשוב במיוחד. המסקנה המעשית של Shadowserver היא שמערכת שבה נפרס מנגנון כזה צריכה להיחשב מחויבת לחלוטין. מחיקה של קובץ בינארי או של משימת cron, בלי לבנות מחדש את האמון במכשיר ובלי להחליף סיסמאות והרשאות privileged, אינה אסטרטגיית התאוששות מספקת.

ייתכן שהכופרה שימשה גם להסתרת ראיות

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

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

התחזות לכלי ניקוי ב-GitHub

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

ההשפעה על Broadcom

מניית Broadcom ירדה בכ-5% עד 6% ב-14 באוגוסט, לאחר שהדיווחים על ניצול פעיל של החולשה ב-VMware הגיעו למשקיעים. באחד הדיווחים צוין מעבר מ-417.82 דולר ל-392.99 דולר במהלך יום המסחר.

הדיווחים הביטחוניים היו אחד הגורמים לירידה, אך לא בהכרח הגורם היחיד. סיקור מקביל הצביע גם על חששות רחבים יותר, ובהם חשיפה לחובות הקשורים לתחום הבינה המלאכותית. לכן לא ניתן לייחס את כל תנועת המניה, או סכום מדויק של שווי שוק שנמחק, ל-CVE-2026-59310 בלבד.

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

מה צריכים מנהלי vCenter לעשות עכשיו?

תיקון החולשה הוא הצעד הראשון — לא האחרון. ארגונים צריכים:

1. להתקין מיד את הגרסאות המתוקנות של Broadcom בכל מופעי vCenter הרלוונטיים, במיוחד במערכות החשופות לאינטרנט או נגישות מרשתות פנימיות רחבות. Broadcom לא מציינת מעקף זמני.
2. להניח שמערכת נפרצה כאשר מופיעים סימנים חשודים, ובהם שינויים בלתי צפויים ב-cron, שרידי Reverse SSH, הקובץ linuxFile, הורדות לא מוסברות באמצעות curl או wget, חשבונות מנהל מערכת לא מוכרים ופעילות חריגה ב-VMware Directory Service.
3. לבודד מכשירים חשודים ולשמור, ככל שניתן מבחינה תפעולית, עותקי דיסק, יומנים וראיות מזיכרון נדיף לפני בנייה מחדש.
4. להחליף הרשאות privileged, כולל vCenter SSO, VMware Directory Service, חשבונות ESXi או root, מפתחות API, חשבונות שירות והרשאות ניהול מקושרות. יש לבטל סשנים פעילים ולבדוק גם נתיבי federation.
5. לבנות מחדש מערכות שבהן אושרה התמדה, במקום להסתפק בניקוי נקודתי. יש להסיר חשבונות, משימות cron, קבצים בינאריים, מפתחות SSH ומנהרות לא מורשים כחלק מתהליך מתועד של תגובה לאירוע.
6. לבצע חיפוש רוחבי בתשתית הווירטואלית אחר פעילות עם הסיומת .babyk, חיבורי SSH או WebSocket יוצאים, חשבונות חריגים וסימנים לשינוי או הצפנה של יומני ESXi.
7. לשחזר נתונים וטלמטריה מהימנים מגיבויים תקינים ובלתי ניתנים לשינוי, במיוחד כאשר יומנים או תצורות נפגעו.
8. להפחית חשיפה עתידית באמצעות הגבלת הגישה הניהולית ל-vCenter לרשתות אדמיניסטרציה מופרדות, וניטור חיבורים יוצאים מ-vCenter ומשרתי ESXi.

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