שרת HTTP בכתובת 46.21.250.135 הגיש רשימת תיקיות בלי סיסמה ובלי שום הגדרת הרשאות. מי שהקליד את הכתובת קיבל את תיקיית העבודה החיה של מחשב לינוקס אחד: יותר מ-90 אלף קבצים בתוך כ-3,000 תת-תיקיות, מסודרים בתיקיות שנקראו בשמות הדומיינים של היעדים. בתוכן היו ערכות ניצול, פלט של סריקות, קבצי הגדרות של סוכני AI, יומני הרצה, וקבצי אקספורט של מסדי נתונים שנגנבו מקורבנות.

חוקרי SOCRadar Threat Research Unit פרסמו בשבוע שעבר את מה שמצאו בתוך התיקייה הזאת, וקראו למי שעמד מאחוריה CyberXero. הפרט שהופך את הדוח הזה למשהו אחר מעוד דוח על תוקף: היומנים תיעדו לא רק את מה שהתוקף הצליח לעשות, אלא גם כל פעם שמודל ה-AI שהפעיל סירב לבקשה שלו, ואת מה שהוא עשה אחר כך כדי לעקוף את הסירוב. בהמשך נראה מה בדיוק היה על השרת, איך עובדים שני הצינורות שהוא מפעיל במקביל, ולמה החוקרים אומרים שיומני הסוכנים עצמם הם חומר רגיש.

שמונה שרתים, מפתח SSH אחד, ופוסט בפורום

התוקף הזה לא מפעיל כופרה ולא מוכר מודעות. הוא פורץ לארגונים ואז מוכר את הגישה עצמה לפושעים אחרים, שעושים איתה מה שהם רוצים. לתפקיד הזה בשרשרת יש שם, Initial Access Broker (בקצרה IAB), והוא נפוץ מספיק כדי שיהיה לו שוק מסודר בפורומים. מה שפחות נפוץ הוא האופן שבו CyberXero בנה את העבודה שלו סביבו.

מהשרת החשוף החוקרים התקדמו לשאר התשתית. token של התקנה שהיה מוטמע בכתובות ההתקנה שימש כטביעת אצבע לכל פריסה שיצאה מאותה תשתית; שם מחשב פנימי שנשאר בתוך מפתח SSH, היסטוריות פקודות שהצטלבו, ויומני staging שתיעדו תקשורת ישירה בין צמתים השלימו את התמונה. בסך הכול מופו שמונה צמתים בשלושה ASN-ים ובשני אזורים: שולחנות עבודה, שרת provisioning ותשתית מונטיזציה באירופה, ושרת ה-C2 של Cobalt Strike (השרת שדרכו התוקף שולח פקודות למכונות שפרץ אליהן), ה-staging וצומת ניצול ה-Redis על Tencent Cloud.

הזיהוי של האדם עצמו נשען על שלושה קווים שהתכנסו. בתיקייה החשופה היה קובץ חשבון שתיעד את נתוני חשבון ה-AI שלו. היומנים תפסו אותו מנסה להוכיח למודל שהוא הבעלים של פוסט בפורום Dread, ואימות חיצוני אישר שהפוסט ההוא אכן פורסם תחת הכינוי CyberXero ומתאר בגוף ראשון בדיוק את אותה התקדמות טכניקות שנראתה בתשתית. והמנוי בתשלום על ה-AI היה קשור לאימייל אישי ולספק חיוב. מניתוח שעות הפעילות והשפה החוקרים מציבים אותו באזור הזמן של מוסקבה, עם שיא פעילות סביב 22:00. את המזהים האישיים עצמם SOCRadar השאירו בדוח המלא ולא פרסמו בפומבי.

4,708 יעדים ב-61 שניות

הצינור הראשון רחב, אוטומטי ואדיש לזהות היעד. במרכזו עומד wp2shell, חבילת Python שהתוקף פיתח בעצמו ושמנצלת את שרשרת החולשות בליבת וורדפרס שהתפרסמה ביולי: חוסר סינכרון ב-batch endpoint של ה-REST API, שמאפשר להזריק SQL (CVE-2026-60137) ומשם להגיע להרצת קוד מרחוק (CVE-2026-63030). הכלי כותב לעצמו חשבון מנהל חדש באתר ושותל webshell ממשפחת WSO שרשום כפלאגין פעיל.

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

המספרים הם מה שהופך את זה לסיפור. רשימת היעדים שנמצאה על השרת מכילה יותר מ-56 אלף כתובות, והרצה אוטומטית אחת סרקה 4,708 יעדים, אישרה גישה ל-429 ממשקי ניהול ושתלה 32 shells, הכול בחלון של 61 שניות. על כל פריצה מוצלחת נשלחה הודעה בזמן אמת לבוט בטלגרם, מה שאפשר לתוקף לעקוב אחרי הקמפיין בלי להחזיק טרמינל פתוח. במקביל רצה תקיפה של Magento ופלטפורמות מסחר אחרות, בין היתר דרך SQL Injection מבוסס-זמן בפלאגין Support Board (CVE-2026-4815, ציון CVSS 8.8), שלפי SOCRadar נכנס לארסנל בתוך 30 יום מפרסום החולשה.

ואז יש את חרקוב

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

בארבעה ארגונים אוקראיניים החוקרים אישרו הוצאת מידע לפי הקבצים שנמצאו. החמור שבהם הוא ספק חימום מרכזי בחרקוב. פרטי אימות שהיו כתובים בתוך הסקריפט של התוקף עצמו נתנו גישה ישירה, וכלי חילוץ מרובה תהליכונים שלף 564,073 רשומות מנויים עם מידע אישי, כתובות בית ומספרי חשבון, ועוד 213,340 רשומות של יומן גישה עם חותמות זמן וכתובות IP. חרקוב יושבת על חזית לחימה פעילה, וזה מה שמוציא את המקרה מגדר דליפת מידע רגילה: החוקרים כותבים שהנתונים האלה מייצרים סיכון פיזי פוטנציאלי לאזרחים מזוהים בשם ובכתובת.

השרשרת המתוחכמת ביותר שנמצאה הופעלה דווקא נגד פורטל מסחר. היא שילבה SQL Injection עיוור, חילוץ של token לאיפוס סיסמה בחלון זמן מוגבל, ו-deserialization של PHP (שחזור אובייקט מתוך מידע שהגיע מבחוץ, שבתנאים מסוימים גורר הרצת קוד) כדי להגיע לשליטה מלאה במסד הנתונים.

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

51 סוכנים על שולחן עבודה אחד

ומה עם ה-AI? כאן נכנסת לתמונה שכבה שהחוקרים מתארים בשני חלקים נפרדים. על שולחן העבודה הראשי התוקף הגדיר, בתיקייה מיועדת, 51 סוכנים מתמחים ב-Claude Code, כל אחד עם תפקיד משלו: סוכנים תוקפניים בשמות כמו c2-operator, exploit-chainer, scada-attacker ו-lateral-movement, סוכני מודיעין לסריקת ווב, מיפוי תת-דומיינים ובדיקת פרטי אימות, וסוכני פוסט-אקספלויטציה להוצאת מידע. על ה-Team Server של Cobalt Strike רצה שכבה שנייה, PentAGI, מערכת קוד פתוח לבדיקות חדירה מבוססות AI, שחוברה ל-Cobalt Strike דרך API של ספק AI לצורך יצירת מטענים והרצת בדיקות.

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

אז איך הוא עקף את הסירובים?

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

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

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

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

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

מי שמפעיל וורדפרס, Magento או PrestaShop צריך לחפש שני דברים ספציפיים: חשבון מנהל ששם המשתמש שלו הוא wp2_ ואחריו שמונה תווים הקסדצימליים, ותיקיית פלאגין בתבנית wp2shell_ ואחריה אותם שמונה תווים. אם מצאתם אחד מהם, האתר כבר נפרץ, ועדכון גרסה לבד לא פותר את זה. מי שחושף Redis לאינטרנט צריך לבדוק רשומות שלא אמורות להיות שם בקובץ ~/.ssh/authorized_keys על אותם שרתים, שזה מה שטכניקת הרפליקציה המזויפת משאירה אחריה.

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