בקובץ טקסט אחד על שרת ההורדות של התוקפים ישבו 170 אלף כתובות של אתרים. מישהו שם הבין שסריקה של רשימה כזאת בבת אחת תיקח נצח, אז פיצל אותה ל-17 קבצים של כ-10,000 כתובות כל אחד וסימן כל אחד מהם באות w, קיצור של התו הסיני 萬 שמשמעותו עשרת אלפים. הרשימה, יחד עם כל ארגז הכלים של הקבוצה, ישבה בספריית הורדות פתוחה לרווחה.

חוקרי Cisco Talos הגיעו לשם אחרי שראו מחשב נגוע מדבר עם אותה כתובת, ופרסמו ב-20 באוגוסט שני דוחות על הקבוצה, שאותה הם מסמנים UAT-10147. מה שמצאו בפנים לא היה רק סקריפטים, אלא גם מסמכים שאף אדם לא כתב: מדריך תפעולי בן תשעה פרקים להרצת קוד על שרתי IIS, ארבעה סקריפטים נלווים ב-Python, ויומן ממצאים מסודר. נעבור על מי הקבוצה הזאת, איך היא נכנסת, מה בדיוק ה-AI כתב לה, ומה נשאר על המכונה אחרי שהיא בפנים.

מי היא UAT-10147, ולמה דווקא שרתי אינטרנט

Talos איתרה את הקבוצה בתחילת 2026, ומתארת אותה כקבוצת פשיעה דוברת סינית עם מניע כספי. שני מקורות ההכנסה שלה הם גניבת מידע והונאת SEO, וההונאה שווה הסבר: התוקפים משתילים בשרת רכיב שבודק מי שלח את הבקשה. אם זה סורק של מנוע חיפוש, השרת מגיש לו תוכן מפוברק שנועד להזיז דירוגים; אם זה גולש שהגיע מהחיפוש, הוא מקבל הפניה או JavaScript זדוני. לרכיב הזה, בגרסה שרצה כמודול של IIS, קוראים BadIIS, ו-Talos כבר תיעדה שהוא נמכר כשירות.

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

הכניסה: חולשות מוכרות שאיש לא סגר

אין כאן חולשות יום-אפס. Talos מתעדת ניצול של CVE-2022-27925, הרצת קוד ללא אימות ב-Zimbra Collaboration; של CVE-2021-23758 ב-AjaxPro; ושל CVE-2021-29441 ו-CVE-2021-29442 ב-Nacos. הניצול של Nacos מעניין דווקא בגלל מה שקורה אחריו: המטען פותח shell מקומי, מזהה בעצמו אם הוא רץ על לינוקס או על Windows, ושולח את פרטי הזיהוי של המכונה אל שרת קונפיגורציה של Nacos שבשליטת התוקפים. במקום להחזיק חיבור חוזר פתוח מול כל קורבן, הם נכנסים מדי פעם לשרת שלהם ובודקים מי ענה, והתעבורה נראית כמו ניהול תצורה שגרתי.

בלינוקס הכניסה נגמרת ב-web shell, ומשם מסלימים הרשאות עם ארסנל של חולשות ותיקות: Dirty Pipe (CVE-2022-0847), Baron Samedit ב-sudo (CVE-2021-3156), חולשה במנגנון watch_queue של הליבה (CVE-2022-0995), ועוד שלוש שהעתיקה שבהן היא CVE-2010-3904 בפרוטוקול RDS, בת שש-עשרה שנה. (ולראיה, היא עדיין עובדת מספיק פעמים כדי להצדיק מקום בארסנל.) ברגע שהושגו הרשאות root מגיעים השתלים, בהם Meterpreter, Noodle RAT ו-SPECTRE.

המדריך שה-AI כתב, פרק אחרי פרק

עמוד ASP.NET שומר את המצב שלו בשדה נסתר שהדפדפן מחזיר לשרת בכל שליחה של טופס. השדה מכיל אובייקט שעבר סריאליזציה, והשרת מפרסר אותו ובונה ממנו בחזרה אובייקט חי בזיכרון. כדי שלא כל אחד יוכל לשתול שם מה שבא לו, השדה חתום במפתח סודי מהגדרות השרת. אם המפתח דלף, כל מה שנשאר לתוקף הוא לחתום אובייקט משלו ולשלוח אותו, והשרת יריץ אותו בשמחה. השדה נקרא __VIEWSTATE, המפתח נקרא MachineKey, והחולשה הזאת מוכרת שנים.

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

הפרק השני הוא החלק החכם במסמך: איך לבדוק בשקט אם מפתח גנוב מתאים לשרת חי, בלי להריץ עליו שום פקודה. שולחים ViewState פגום בכוונה ומסתכלים על הודעת השגיאה. כשל באימות החתימה אומר שהמפתח לא נכון; חריגת המרה אומרת שהמפתח דווקא כן נכון, כי כדי להגיע לשלב ההמרה השרת כבר פענח את האובייקט. שתי התשובות חוזרות כשגיאת HTTP 500, וזו נקודה עיוורת אמיתית: מערכות ניטור שמתריעות על שגיאות 5xx מייצרות רעש כל היום, והצלחת התוקף חולפת בתוכו בלי להרים ראש.

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

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

ארבעה סקריפטים, ובקרת איכות על הניצול

לצד המדריך היו ארבעה סקריפטים ב-Python. הראשון, check_paths.py, נועד לענות על שאלה אחת: למה ה-web shell לא נכתב לדיסק. הוא מריץ חמש בדיקות רצופות: שההרצה עובדת בכלל, מה הרשאות הכתיבה על תיקיית האתר, ומהם הנתיבים הפיזיים האמיתיים לפי כלי הניהול של IIS. השני, deploy_implant.py, מוריד את השתל SPECTRE, ממתין שש שניות ובודק שהקובץ אכן נחת, ואם ההורדה נכשלה מנסה שוב בשיטה אחרת.

השלישי, deploy_shell.py, מתמודד עם מגבלה אמיתית: החולשה מאפשרת להריץ פקודות, לא להעלות קבצים. הפתרון דו-שלבי, כתיבת מטפל העלאה זמני לתיקיית האתר ואז העלאת ה-web shell הסופי דרכו. שם גם נמצאה ההחלקה שסגרה את המעגל עבור החוקרים: נתיב מקומי קשיח על מחשב התוקף, שחושף את שם המשתמש dajiba. הרביעי, exfil.py, מוציא מידע בשלושה שלבים ומסווה את היציאה כתעבורת HTTPS רגילה.

היומן שנמצא לצדם סוגר את התמונה: יותר מ-12 פניות חוזרות מהשרת הקורבן, ארבע שרשראות gadget שרצו בהצלחה על .NET בגרסה 4.8.4797.0, והרשאת SeImpersonatePrivilege דלוקה, כלומר דרך פתוחה להסלמה ל-SYSTEM. על שרת הניהול Talos מצאה גם את PentestGPT, שהופעל כדי לסרוק שרתים ולהריץ מולם exploit-ים מוכנים.

SPECTRE: מה נשאר על המכונה

עד כאן הכניסה. מה שנשאר על השרת אחריה הוא נושא הדוח השני, ובמרכזו השתל SPECTRE. בגרסת Windows יש לו 45 פקודות, 24 גלויות בקוד ו-21 מוצפנות ומפוענחות רק ברגע ההפעלה. לפני הכול הוא מנקד את הסביבה לפי שמות תהליכים, כמות זיכרון, מספר ליבות ושמות מארחים אופייניים למעבדות ניתוח, ואם הניקוד מגיע ל-50 הוא מסיים את עצמו.

היכולת המעניינת נוגעת למוצרי ההגנה. מנועי EDR רואים מה קורה במערכת בעזרת פונקציות שהם רושמים בליבת Windows, שמופעלות בכל יצירת תהליך או טעינת ספרייה. SPECTRE מוריד דרייבר לגיטימי וחתום כהלכה שיש בו חולשה ידועה, RTCore64.sys של MSI (CVE-2019-16098) או DBUtil_2_3.sys של Dell (CVE-2021-21551), מתקין אותו כשירות זמני ומשתמש בחולשה שבו כדי לכתוב לזיכרון הליבה. לטכניקה הזאת קוראים BYOVD. משם הוא ניגש לטבלת היסטים קשיחה שמכסה 13 גרסאות Windows ומנתק את הרשומות של מוצרי ההגנה מהרשימות שבהן הן יושבות. מאותו רגע ועד האתחול הבא, CrowdStrike Falcon, SentinelOne ו-Microsoft Defender פשוט לא רואים יצירת תהליכים חדשה.

בלינוקס התמונה שונה. שם יש לשתל 29 פקודות בלבד וללא הצפנה, אבל נלווה אליו rootkit של ליבה בשם Specter, שנטען כמודול בשם acpi_pad.ko, שמו של מודול לגיטימי לניהול צריכת החשמל של המעבד. שימור האחיזה נעשה דרך יחידת systemd מזויפת בשם hardware-monitor.service, שמוגדרת לעלות לפני sysinit.target, כלומר לפני כלי האבטחה של המערכת. ה-rootkit לא נוגע בטבלת קריאות המערכת אלא משתמש ב-ftrace, ממשק ניפוי באגים לגיטימי. השליטה בו יצירתית: התוקף שולח אות למספר תהליך שלא קיים, 31337, וכל מספר אות הוא פקודה אחרת, מהסתרת תהליך ועד הרמת הרשאות ל-root.

אז איך יודעים בכלל שה-AI כתב את זה?

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

השלישית היא המשכנעת מכולן. בקוד יש שלוש שיטות שונות לאותה מטרה, מסומנות בהערות מפורשות Method 1, Method 2 ו-Method 3. אדם שכותב rootkit לליבה מסוימת בוחר את השיטה שעובדת ומיישם אותה; מודל שמתבקש להיות יסודי מחזיר את כל השיטות שהוא מכיר. Talos מכנה את זה רפלקס השלמות, והחתימה חוזרת גם במקום פחות צפוי: כלי הסלמת ההרשאות שהקבוצה קימפלה בעצמה, EfsPotato ו-RustPotato, נושאים נתיבי בנייה שבהם התיקייה נקראת פשוט AI.

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

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

אף אחת מדרכי הכניסה כאן אינה חדשה, וזה בדיוק מה שכדאי לקחת מהסיפור: שרת Zimbra שלא עודכן מאז 2022, רכיב AjaxPro ישן ומופע Nacos חשוף הם עדיין הדרך הקצרה פנימה. אם אתם מריצים IIS, ה-MachineKey הוא הנכס שצריך לשמור עליו, אז ודאו שהוא לא הועתק מדוגמת תצורה פומבית, החליפו אותו אם יש ספק, וזכרו שהוא משויך לאתר, לא לשרת. בצד הניטור, שתי אנומליות שוות בדיקה: הוספה של תיקיות inetsrv לרשימת ההחרגות של Windows Defender, ומודול ליבה בשם acpi_pad על שרת לינוקס שאין סיבה שיטען אותו.