הפקודות אל ה-web shell לא מופיעות בכתובת ה-URL ולא בגוף הבקשה. הן נוסעות בתוך header של HTTP בשם X-windchill-req, שדה אחד מיני רבים בבקשה שנראית כמו תעבורה רגילה לגמרי של האפליקציה, והתשובה חוזרת דחוסה ב-GZIP בדיוק כמו כל תוכן שהשרת מגיש ממילא. מערכת ניטור שבודקת נתיבי URL ופרמטרים לא רואה כאן שום דבר.

חוקרי ReliaQuest, ג'ון דילגן וקונור שורט, פרסמו ב-18 באוגוסט ניתוח של ה-web shell הזה, שמותקן על שרתי PTC Windchill ו-FlexPLM אחרי ניצול של החולשה CVE-2026-12569, ומייחסים אותו בסבירות גבוהה לקבוצת הסחיטה Clop. מה שמייחד אותו הוא לא רשימת היכולות אלא ההתאמה: הוא נכתב מול המחלקות הפנימיות של Windchill, מכיר את סכמת מסד הנתונים שלה, את ה-keystore שלה ואת מבנה מחסני הקבצים, ומגיע עם כל מה שצריך לגניבת מידע כבר ברגע ההתקנה. "ה-web shell נותן לתוקפים נתיב ישיר לגניבת פרטי אימות ולהוצאת מידע בהיקף גדול, בלי צורך בכלים נוספים", כתבו החוקרים.

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

מה מחזיק Windchill, ולמה תוקף כלכלי רוצה דווקא אותו

Windchill היא מערכת לניהול מחזור החיים של מוצר (PLM), כלומר המקום שבו יצרנית מרכזת את שרטוטי ההנדסה, קבצי התכן, המפרטים, רשימות הרכיבים והגרסאות של כל מה שהיא מייצרת. PTC, שמפתחת אותה, מדווחת על יותר מ-30 אלף לקוחות ברחבי העולם, מהם למעלה מ-1,500 מותגים וקמעונאים שמשתמשים ב-FlexPLM. מבחינת תוקף שמתפרנס מסחיטה, שרת אחד כזה שווה יותר מעשרות תחנות עבודה: הוא מרכז את הקניין הרוחני של החברה במקום אחד, מסודר ומתועד.

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

הציונים שניתנו לחולשה נבדלים לפי השיטה: NVD נותן לה 9.8 בסולם CVSS 3.1, בעוד PTC עצמה דירגה אותה 9.3 בסולם CVSS 4.0 החדש יותר. ההבדל הוא חשבונאי ולא מהותי. PTC התחילה לשחרר תיקונים ב-17 ביוני, וכעבור שמונה ימים החולשה כבר נכנסה לקטלוג ה-KEV של CISA, שמסמן חולשות שנוצלו בפועל. CISA נתנה לסוכנויות הפדרליות מועד יעד של 28 ביוני, שלושה ימים בלבד מרגע ההוספה, וסימנה את החולשה כמשמשת בקמפיין כופרה ידוע.

פקודה אחת שמחזירה את כל הסיסמאות בטקסט גלוי

כאן מתחיל החלק שבאמת מבדיל את הכלי הזה מ-web shell רגיל. פקודה בודדת, שהחוקרים מסמנים כ-"S", מפעילה פונקציה פנימית בשם gs ומחזירה את פרטי האימות שהאפליקציה מחזיקה, בטקסט קריא. הפונקציה עובדת בשלושה שלבים: היא קוראת את קובץ ההגדרות ieStructProperties.txt, מפענחת מתוך ה-keystore של האפליקציה את סיסמת מנהל ה-LDAP, ואז עוברת על שאר הערכים המוצפנים ומפענחת גם אותם, כולל פרטי חשבונות ניהול, פרטי גישה לאחסון האובייקטים והמפתחות של כל מנהלי האתר. פקודה נפרדת מוציאה את התוצאה החוצה.

חילוץ סיסמת מנהל ה-LDAP הוא הנקודה שבה האירוע מפסיק להיות בעיה של שרת אחד. ספריית ה-LDAP היא בדרך כלל אותה ספרייה שמאמתת משתמשים מול Active Directory, מול הדואר הארגוני ומול ה-VPN, כך שפרטי האימות שנשלפו מ-Windchill פותחים דלתות במערכות שאין להן קשר ל-Windchill. ReliaQuest מנסחים את זה כמעבר מפריצה של אפליקציה אחת לפריצת פרטי אימות ברמת הארגון כולו, והמסקנה המעשית שלהם מתאימה לכך: בכל שרת שנחשד כפרוץ צריך להניח שכל תוכן ה-keystore כבר בידי התוקף.

מפה מוכנה של קבצי ההנדסה, ומסד נתונים שלא מתלונן

עד כאן פרטי האימות. הצד השני, איתור המידע עצמו, מעניין לא פחות. ל-web shell יש פונקציה בשם fl ומחלקה בשם Flst1 ששולפות ממסד הנתונים של האפליקציה את מזהי הקבצים במחסן, את שמותיהם, נתיבי האחסון והגדלים, וכותבות את הכול לקובץ בשם flst.txt. התוקף מקבל אינדקס מסודר של המאגר ובוחר מתוכו מה שווה לגנוב, בלי להריץ אף פקודת חיפוש ידנית.

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

הצד הרשתי בנוי באותה רוח. כדי לראות את התעבורה של הכלי צריך שלושה דברים יחד: תיעוד של header-ים לא סטנדרטיים, פענוח של תשובות דחוסות, ופתיחה של תעבורת TLS. חסר אחד מהם, והכיסוי חלקי במקרה הטוב. ההשוואה שהחוקרים עורכים היא ל-China Chopper, אחד מה-web shell-ים הגנריים הנפוצים בעולם, שנפרס על ידי שחקנים שונים לגמרי מול טכנולוגיות שונות לגמרי, ובדיוק בגלל זה יש לו חתימות מוכרות שכלי ההגנה מחפשים. לכלי שמחקה את ההתנהגות הרגילה של האפליקציה שהוא יושב בתוכה אין חתימה כזאת.

Cldr, הרכיב שהופך את ה-web shell לדלת אחורית פתוחה

הרכיב שהחוקרים מסמנים כמסוכן ביותר הוא דווקא הקטן ביותר: מנגנון טעינת מחלקות משלו בשם Cldr. הוא מקבל ארכיון ZIP מקודד ב-Base64 שמכיל קוד ג'אווה מהודר, טוען אותו ישירות לזיכרון ומריץ אותו. טעינת מחלקות דינמית היא יכולת סטנדרטית בג'אווה ואין בה שום חידוש, אבל השימוש כאן אומר שקוד חדש של התוקף רץ בתוך תהליך האפליקציה בלי שנכתב ולו קובץ אחד לדיסק.

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

איך קשרו את זה ל-Clop, ומה היה שם קודם

הייחוס נשען על שלושה חוטים. הראשון הוא מיילים של דרישת כופר שנשלחו לארגונים שנפגעו, ובהם כתובות קשר שמופיעות באתר ההדלפות הפעיל של Clop. השני הוא ה-header המזהה X-windchill-req, שכבר נקשר לקבוצה בדיווחים קודמים על ניצול אותה חולשה. השלישי הוא דפוס העבודה: ניצול המוני של חולשה בתוכנה שמחזיקה מידע רגיש, ומיד אחריו פריסת web shell שנבנה במיוחד עבור אותה תוכנה. גם ReliaQuest נזהרים כאן ומדברים על סבירות גבוהה ולא על ודאות, וBleepingComputer דיווח ב-24 ביולי שזהות התוקף עדיין לא אושרה, אף שדפוס הפעולה תואם קמפיינים קודמים של הקבוצה.

הדפוס הזה מוכר. אחרי ניצול חולשת ה-SQL Injection ב-Accellion FTA, שסומנה CVE-2021-27101, פרסה Clop web shell בשם DEWMODE. אחרי החולשה ב-MOVEit Transfer, CVE-2023-34362, הגיע LEMURLOOT. בכל פעם מדובר בתוכנה שדרכה עוברים או שבה נשמרים קבצים של ארגונים רבים, ובכל פעם הכלי נבנה מחדש סביב אותה תוכנה. "Clop נשארת דרקון ישן, שתמיד מחפש ומתכונן לניצול המוני של חולשות בתוכנות שמחזיקות מידע רגיש", כתבו החוקרים. ההערכה שלהם קדימה היא שהניצול יתרחב לארגונים נוספים בשבועות הקרובים ברמת ביטחון גבוהה, וברמת ביטחון בינונית שגם שחקנים מחקים יאמצו את החולשה ככל שקוד ניצול פומבי יהפוך לזמין יותר.

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

אם יש בארגון שלכם שרת Windchill או FlexPLM, התיקון של PTC לחולשה הזאת יצא לפני חודשיים והמועד שבו CISA דרשה לסגור אותה חלף מזמן. מעבר לעדכון עצמו, ההמלצה של ReliaQuest היא לסרוק את ספריות הקוד של האפליקציה, ובראשן windchill/codebase/login, אחרי קבצי JSP שלא אמורים להיות שם, במיוחד כאלה עם חותמת זמן טרייה או עם התייחסות ל-X-windchill-req, ל-MethodContext, ל-WTConnection או ל-WTKeyStoreUtil. ובכל שרת שיש עליו ספק, החלפת סיסמאות היא רק חצי עבודה: צריך גם לנתק את הסשנים הפעילים של החשבונות שנחשפו, כי סיסמה שהוחלפה לא מבטלת token תקף שכבר נמצא אצל מישהו אחר.