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

חוקרי Mandiant ו-Google Threat Intelligence Group פרסמו ב-25 בספטמבר דיווח על גל תקיפות מחודש נגד שרתי Oracle PeopleSoft, שהם מייחסים לקבוצה שהם מסמנים UNC6240 ומכנים ShinyHunters. לפי הדיווח, הקמפיין הנוכחי הרחיב את היעדים בהרבה: web shells הושתלו על עשרות מערכות ברחבי העולם, בהשכלה גבוהה, בטכנולוגיה, בשירותי IT, בבריאות, בחקלאות, בתחבורה ובגופים ממשלתיים. בהמשך נראה למה העקיפה עובדת, איך נראית הבקשה שבודקת אם שרת חשוף בלי להשאיר עליו כלום, ומה הועלה לשרתים אחרי שהתוקפים נכנסו.

מה זה PSEMHUB, ולמה חוק ה-WAF נראה כמו פתרון

PeopleSoft היא מערכת ה-ERP של אורקל, והיא יושבת דווקא במקומות שמחזיקים את סוגי המידע שמעניינים תוקף שמתפרנס מסחיטה: טבלאות שכר, רשומות משאבי אנוש, מידע על סטודנטים. הרכיב שדרכו נכנסים נקרא Environment Management Hub, בקצרה PSEMHUB, והוא התשתית שמחלקת עדכונים ותצורה בין שרתי ה-PeopleSoft של אותו ארגון. זה רכיב שמדבר בין מכונות, לא ממשק שמשתמש אנושי מתחבר אליו.

החולשה עצמה, CVE-2026-35273, היא מהסוג הפשוט והגרוע: הרכיב לא דורש בכלל אימות לפעולה שאמורה להיות מוגנת (CWE-306). אורקל דירגה אותה 9.8 בציון CVSS, כפי שמופיע ברשומה ב-NVD, ובוקטור שאומר שהיא מנוצלת מהרשת, בלי הרשאות ובלי שמשתמש יעשה משהו. התראת האבטחה של אורקל, שיצאה מחוץ למחזור העדכונים הרגיל ב-10 ביוני, מגדירה אותה כניתנת לניצול מרחוק בלי אימות ומציינת שניצול מוצלח עלול להוביל להרצת קוד מרחוק. הגרסאות המושפעות הן PeopleTools 8.61 ו-8.62. ב-12 ביוני החולשה נכנסה לקטלוג החולשות המנוצלות בפועל של CISA, עם תאריך יעד לתיקון בגופים הפדרליים ב-15 ביוני ועם סימון שהיא בשימוש בקמפיינים של כופרה.

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

אז איך תו אחד מבטל חוק חסימה שלם?

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

זה כל התרגיל. התוקפים ביקשו /%50SEMHUB/ במקום /PSEMHUB/, כאשר %50 היא הצורה המקודדת של האות P. חוק ה-WAF, שמחפש את המחרוזת PSEMHUB כפי שהיא, לא מצא התאמה והעביר את הבקשה הלאה. WebLogic, שרת היישום של PeopleSoft, פענח את הקידוד וניתב את הבקשה בדיוק לאותו servlet חשוף. "חוקי WAF ו-proxy רבים משווים את הנתיב המילולי לפני פענוח ה-URL, בעוד שרת היישום של PeopleSoft מפענח את הבקשה ומנתב אותה ל-servlet הפגיע", כתבו החוקרים.

החולשה היא אותה חולשה מיוני. רק הדרך אליה השתנתה.

מהבדיקה השקטה אל שתי ה-JSP בתיקיית ה-WAR

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

כדי לבדוק אם שרת מסוים בכלל חשוף, התוקפים שלחו אליו בין חמש לחמש-עשרה בקשות POST לנתיב /%50SEMHUB/hub, ובתוכן אובייקט Java שהומר לרצף בייטים כדי להישלח ברשת ולהיבנות מחדש בצד השני. לתהליך הזה קוראים serialization. שרת שלא עודכן משיב עם מערכת ההפעלה של המכונה, בלי שנכתב קובץ ובלי שהשירות נפגע, וכך התוקף מאשר בשקט שהמטרה טובה. למגן זו נקודה חשובה: Mandiant מציינים שעל שרתים שהקבוצה אימתה אבל לא תקפה בהמשך, הבקשה הזאת תופיע ביומנים בלי שום פעילות עוקבת אחריה.

שתי שיטות ההרצה שנצפו מנצלות את אותה בעיה: ה-servlet של PSEMHUB מקבל את אובייקט ה-Java ומרכיב אותו בחזרה בלי לבדוק מה מותר להרכיב, וזה מה שמאפשר לתוקף להריץ קוד על השרת. לחולשה מהסוג הזה קוראים Java deserialization. בשיטה הראשונה נוצרו בעזרתה קבצי JSP חדשים בתיקיית PSEMHUB.war, כלומר web shell, עמוד שיושב בתוך היישום החוקי ומקבל דרכו פקודות. התוקפים שלחו מטח של בקשות ולא בקשה אחת, מסיבה פרקטית לגמרי: בסביבות עם איזון עומסים הם רצו שכל הצמתים יקבלו עותק. בשיטה השנייה לא נכתב קובץ בכלל. פלט הפקודה חוזר בתוך תשובת ה-HTTP, ומה שרואים על המכונה הוא תהליכי shell שנולדים מתוך תהליך ה-Java של WebLogic.

שני ה-web shells שהושתלו בנויים סביב הימנעות מזיהוי. הראשון, x.jsp, מריץ פקודות גם על Windows וגם על Linux, ומקבל אותן מקודדות בהקסדצימלי כדי שחתימות שמחפשות מחרוזות פקודה מוכרות לא יתפסו אותן; על Linux הוא אפילו בונה את הנתיב /bin/sh מתוך מערך של קודי תווים במקום לכתוב אותו כמחרוזת מפורשת. השני, u.jsp, קיים כדי להעלות קבצים: הוא מקבל אותם בחלקים של 150 קילובייט בקידוד Base64 ומחבר אותם על הדיסק. הפיצול לא נועד להסתרה בלבד, הוא עוקף מגבלות גודל של בקשות HTTP ומדלג על מנגנוני ה-FILECHUNKING של PeopleSoft עצמה.

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

מה שהועלה דרך u.jsp הוא קובץ בשם Ple64.exe במשקל 5.2 מגה-בייט, שמתחזה למתקין של נגן המדיה Light Alloy. הוא לא סתם מתחזה. הוא נשא חתימה דיגיטלית תקפה מסוג EV, שהונפקה דרך Sectigo לישות בשם Tobias Weihmann Software Development OU. לפי הדיווח, GTIG פנו ל-Sectigo כדי שהתעודה תבוטל, כלומר בזמן הפרסום היא עוד הייתה בתוקף.

Ple64.exe הוא רק הקומה הראשונה. הוא פורס ומטעין לזיכרון משגר מוגן ב-VMProtect 3, והמשגר מפענח בלוקים של נתונים שמוטמעים בתוך אותו קובץ ומעלה מהם את הדבר האמיתי: דלת אחורית בשם SIDEEYE, כתובה ב-C++, שכלל לא נכתבת לדיסק בפני עצמה. היא מדברת ב-TCP גולמי מול הכתובת 162.219.30.165, בחלוקה מסודרת בין ערוץ שליטה ב-port 3333 לערוץ נתונים ב-port 3334. מה שהיא יודעת לעשות שם זה חילוץ פרטי אימות מדפדפנים ומיישומי שולחן עבודה, ניהול תהליכים וקבצים, shell הפוך אינטראקטיבי ו-proxy הפוך.

לצד SIDEEYE נערמו על השרתים עוד שני כלים, ושניהם לגיטימיים לחלוטין בפני עצמם. הראשון הוא Neo-reGeorg, פרויקט קוד פתוח שמקים מנהרת SOCKS5 מעל HTTP ו-HTTPS; הוא הושתל בשמות tunnel.jsp ו-tunnel.jspx, ותפקידו לתת לתוקף למפות את הרשת הפנימית ולנוע בה מתוך השרת שנפרץ. השני הוא MeshAgent, כלי RMM לגיטימי לניהול מחשבים מרחוק, שנפרס על מכונות Linux כדי לשמור אחיזה גם אחרי שה-web shell נמצא ונמחק. אותו כלי נזרק ל-/tmp בלי שום הצפנה, שלושה קבצים בשמות meshagent, meshagent.msh ו-meshagent.db. תשתית השליטה שלו בספטמבר הייתה הדומיין winmanage-me.network, וקודם לכן, במאי וביולי, דומיינים שמתחזים למיקרוסופט: azurenetfiles.net, microsoft-entra.net ו-enroll.azuredevice.cloud.

מה התוקפים עשו על השרתים

כאן מתברר למה זה מדאיג יותר מ-web shell סתם. לפי Mandiant, רבע מהפקודות שהורצו על המערכות שנפרצו רצו כ-root או כ-NT Authority\SYSTEM, כלומר בשליטה מלאה על מערכת ההפעלה. השאר רצו תחת חשבונות השירות של PeopleSoft ושל WebLogic, וגם זה לא קטן: החשבונות האלה קוראים את קובץ התצורה psappsrv.cfg, את פרטי האימות של Integration Broker ואת פרטי האימות לענן שנגישים משכבת ה-web.

התמונה שמצטיירת מהפקודות היא של גניבת מידע לצורך סחיטה, לא של השתלטות לשם עצמה. החוקרים ממליצים לחפש קבצי ארכיון גדולים בסיומות tar, tar.gz ו-zst בתיקיות זמניות או בתיקיות שנגישות מהאינטרנט, ותהליכי tar, zstd, rsync, sshpass או curl שנולדו מחשבונות השירות האלה. במקביל, ביומני הביקורת של מסד הנתונים כדאי לחפש שאילתות או ייצוא בכמויות מול טבלאות של שכר, משאבי אנוש ורשומות סטודנטים, וביומני הרשת תעבורה יוצאת גדולה או מתמשכת משכבת ה-PeopleSoft, כולל rsync ב-port 873 ו-SSH.

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

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

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

אם יש לכם PeopleTools 8.61 או 8.62 בארגון, העדכון של אורקל הוא הצעד היחיד שסוגר את הסיפור, ומעליו כדאי להשבית את שירות ה-EMHub או להסיר את יישום PSEMHUB לגמרי; Mandiant מציינים שהרכיב הזה וגם ה-Integration Broker הם ממשקים בין מכונות, וחסימה שלהם מהאינטרנט הפתוח לא שוברת שום דבר בעבודה הרגילה של המשתמשים. הבדיקה שדחוף לעשות עכשיו היא ביומני הגישה של WebLogic, ולא רק על המחרוזת /PSEMHUB/: אם זה כל מה שחיפשתם בשלושת החודשים האחרונים, יומן נקי לא אומר כלום, וצריך לחפש גם כל וריאנט מקודד שלה. מי שמוצא קובץ JSP או EXE זר בתיקיית PSEMHUB.war צריך להניח שגם פרטי האימות שחשבון השירות יכול לקרוא נחשפו, ולהחליף אותם.