שתי דקות לשימור אחיזה, ארבעה ימים לדומיין שלם: CyberStrikeAI, המסגרת שבה מודל שפה מחליט מה הצעד הבא
שתי דקות אחרי שהסוכן נחת על המכונה הוא כבר דאג שיעלה מחדש אחרי אתחול וסיים למפות את המחשב. חמש השעות שלאחר מכן הלכו על מיפוי הדומיין. אחרי הפסקה של כמה ימים הגיע הסבב האחרון, והוא נגמר בתוך שעה: תנועה רוחבית, חילוץ פרטי אימות מכמה מכונות, וייצוא של מסד נתונים שלם. לוח הזמנים הזה מרשים, אבל לא זה החלק המעניין. את סדר הפעולות לא קבע אדם.
חוקרי Securelist של קספרסקי, קיריל אנטונוב, ולדיסלב ולסוב ודמיטרי צ'יז'מק, פרסמו ב-2 בנובמבר ניתוח של קמפיין שפגע במוסדות חינוך בכמה מדינות באפריקה ובאמריקה הלטינית. התוקפים נעזרו ב-CyberStrikeAI, מסגרת תקיפה שבה מודל שפה על שרת השליטה הוא זה שמחליט מה הפקודה הבאה. לפי קספרסקי זה אחד התיאורים הפומביים הראשונים של פריצה אמיתית שמודל שפה ניהל בתוכה. בהמשך נראה איך המסגרת בנויה, מה המודל עשה בפועל על המכונות, למה הייחוס נעשה כאן קשה במיוחד, ולמה החוקרים עצמם אומרים שלצד המגן זה כמעט לא משנה.
איפה בדיוק יושב ה-AI
כדי להבין את חלוקת העבודה נתחיל מהצד של הקורבן. על המכונה הנגועה רץ רכיב קטן שכתוב ב-Go, שפונה כל פרק זמן לשרת, שואל אם יש לו משהו לעשות, מריץ פקודות shell ומחזיר את התוצאה. אין בו מפתחות API, אין בו קריאות לשירותי AI, ואין בו לוגיקה שמחליטה משהו בעצמה. כל השכבה החושבת יושבת בצד השני, על שרת השליטה והבקרה (C2, השרת שממנו התוקף שולח פקודות לתוכנה הזדונית), ושם רץ מודל שפה שמקבל את יכולות ה-C2 כסדרת כלים דרך MCP, מנתח את מה שחזר מהמכונה ומחליט מה לבקש אחר כך.
מבחינת המגן זה נראה כמו עוד חיבור מרוחק רגיל, מעל HTTP/S, TCP או WebSocket. המודל לא משנה את צורת התקשורת, רק את מי שמנסח את מה שעובר בה: האופרטור מגדיר את המשימה, והמודל בוחר את הפקודות ואת סדרן.
CyberStrikeAI עצמה לא נבנתה לקמפיין הזה. זו מסגרת קוד פתוח מודולרית לבדיקות חדירה, זמינה לכל אחד ב-GitHub, שפותחה בתוך קהילת הסייבר הסינית ומוכרת שם היטב. התוקפים כאן לא פיתחו כלום. הם לקחו כלי מהמדף.
איך נכנסו, ומה קרה בשבועיים שבאמצע
השלב הראשון היה ידני לגמרי ולא מיוחד. האופרטור הגיע לרשת דרך שרת SQL Server פרוץ (גרסה 16.0.1000), אסף מידע בסיסי, העלה כלים וסרק את הרשת. הפקודות הראשונות יצאו מתוך התהליך sqlservr.exe, מה שמצביע גם על דרך הכניסה וגם על ההקשר שבו קיבלו הרצת קוד. כל זה לקח כמעט יום, ואז הכול נעצר לשבועיים.
החזרה נראתה אחרת. עכשיו הותקן סוכן CyberStrikeAI, ומכאן המודל נכנס לתפקיד. התוקפים בדקו בסקריפט PowerShell אם הסוכן כבר קיים, ומהבדיקה הזאת חילצו החוקרים את נתיבי ברירת המחדל של המסגרת: C:\Windows\Temp\, C:\Windows\, C:\ProgramData\ ו-C:\Temp. את הקובץ אפשר להסוות בשם של תהליך מערכת, ובמקרה שקספרסקי מתארת הוא נקרא svchosts.exe, בתוספת s ל-svchost.exe האמיתי. הפקודות נשלחו מקודדות ב-Base64, כדי שלא ייתפסו בחיפוש מילות מפתח בשורת הפקודה.
שימור האחיזה, כלומר הדאגה של התוקף להישאר על המכונה גם אחרי אתחול, נעשה דרך משימה מתוזמנת בשם SystemUpdate, ובקוד המסגרת יש חלופה: ערך באותו שם תחת מפתח ה-Run ברישום. בלינוקס קיימות שתי דרכים מקבילות, שורת @reboot ב-crontab של המשתמש או שורה בקובץ bashrc שמפעילה את הסוכן בכל פתיחה של shell. מה שכן, ההחלטה באיזו דרך להשתמש היא של המודל ולא של האופרטור. קספרסקי מדגישה שיש במסגרת מנגנון human-in-the-loop, כך שפקודות שהמודל מייצר יכולות לדרוש אישור או תיקון ידני לפני ההרצה.
אז מה המודל בעצם עשה שם?
כאן מתחיל החלק שממחיש למה הדוח מעניין. הסוכן ייצר סקריפטים שמחפשים מסלולים להסלמת הרשאות: בדיקה של SCCM, ובדיקה של מפתח AlwaysInstallElevated שמאפשר להתקין חבילות MSI בהרשאות גבוהות. הוא גם מנה שירותים שרצים תחת חשבונות דומיין ומשימות שרצות תחת SYSTEM, בדיוק הרשימה שממנה בונים מסלול הסלמה. בין פעולה לפעולה הוא גם בדק אם Microsoft Defender זיהה משהו.
לסריקת הרשת הסוכן לא הוריד nmap או fscan. הוא השתמש ביכולות המובנות של PowerShell כדי למצוא מכונות זמינות, ובשאילתות LDAP מול Active Directory כדי לבנות מפה של הדומיין, ובהן השאילתות שמספקות את החומר ל-Kerberoasting ול-AS-REP Roasting, שתי טכניקות לפיצוח סיסמאות של חשבונות שירות מחומר מוצפן שהדומיין מחזיר. הוא גם בדק אם מותקן LAPS ואם יש שימוש ב-Azure, בין השאר דרך חיפוש התיקייה .azcopy בתיקיות הבית. עוד בשלב הידני, כדי לבדוק אם למכונה יש גישה לאינטרנט, התוקפים נעזרו בשירות הסיני dnslog[.]cn, שמייצר דומיין רנדומלי ומדווח על כל ניסיון לתרגם אותו.
עד כאן מיפוי. מכאן מתחיל החלק שבו הדומיין עובר ידיים.
בחילוץ פרטי האימות אין שום חידוש. הסוכן הוציא עותקים של ענפי הרישום שמחזיקים פרטי אימות בעזרת reg.exe, והוציא dump מתהליך lsass.exe דרך פונקציית MiniDump שבספרייה comsvcs.dll. פרט קטן שם מלמד על הכוונה: במקום שם התהליך הוא נקב במזהה המספרי שלו, כדי שחתימות שמחפשות את השם בשורת הפקודה לא יתפסו אותו. ברגע שהיה בידיו חשבון מנהל דומיין מובנה, הוא ביצע DCSync ו-Golden Ticket בעזרת גרסה של mimikatz ששמה שונה.
התנועה הרוחבית הסתמכה על מה שכבר היה במערכת: WMIExec מתוך חבילת Impacket, ואחר כך תיקיות שיתוף מנהלתיות ברשת להפצת הקבצים ופרוטוקול WMI להרצתם בצד השני. אחד מהם, p1.ps1, היה reverse shell שמתחבר לשרת בכתובת 185.186.245[.]144 בפורט 5501. במכונות עם חשבון מנהל הסוכן נטה ליצור משימה מתוזמנת במקום להריץ ישירות, כדי שהמטען ירוץ בהרשאות SYSTEM.
שלב האיסוף הוא ההדגמה הטובה ביותר למה שהמודל מוסיף. הסוכן ייצר בעצמו שאילתות SQL ו-LDAP שמותאמות למשימה, במקום להריץ רשימה מוכנה, ולפני שניגש לנתונים בדק אילו הרשאות יש לחשבון שדרכו התחבר. הקבצים עצמם עברו בערוץ המוצפן הרגיל של הסוכן, מקודדים ב-Base64 בתוך תשובות ה-JSON שלו. גם צילומי מסך נלקחו שם, לפי פקודה שבאה מהמודל. בכל המקרים שקספרסקי זיהתה האיסוף היה הסוף. אחריו לא נראתה פעילות נוספת.
למה הייחוס נעשה כאן קשה במיוחד
העקבה הטובה ביותר שנשארה לחוקרים היא דווקא תוצר של רשלנות בבנייה. התוקפים קימפלו את המטען מתוך עותק Git מקומי של הפרויקט, וקומפיילר Go מטמיע במצב כזה בתוך הבינארי את גיבוב הקומיט, את זמנו, ואת הדגל vcs.modified=true שמעיד על שינויים מקומיים שלא נשמרו. השדות האלה יחד מייצרים טביעת אצבע של בנייה ספציפית, ולפיה הדגימות מתחלקות לשתי קבוצות. בכל קבוצה המטען ל-Windows והמטען ל-Linux נבנו מאותו עותק עבודה, אבל בין הקבוצות אין חיבור: אין שרתי שליטה משותפים, ועל השרתים רצות גרסאות שונות של CyberStrikeAI.
וכאן מגיעה הנקודה שהופכת את זה לבעיה ולא רק לפרט טכני. קספרסקי אומרת במפורש שאין בידיה די מידע כדי לקשור את הפעילות לקבוצה מוכרת, ולא כדי לקבוע שאותו אופרטור עומד מאחורי שתי הקבוצות. סיבה אחת היא שהכלי פתוח, ולכן אופרטורים שונים יכלו להקים אותו בנפרד בתנאים דומים. השנייה עמוקה יותר: את הפקודות מנסח מודל, לא אדם. ניתוח התנהגותי נשען על ההרגלים של אופרטור ועל הניסוחים שהוא חוזר אליהם, וכשמודל מייצר את אותה פקודה מחדש בכל פעם היא נראית אחרת, אבל גם מפסיקה להעיד על מישהו מסוים. הגיוון עולה, וערך המדד יורד.
מה שכן, כמה סימנים עדיין מצביעים לכיוון אחד. בחלק מהסקריפטים יש הערות בסינית, השירות שנעזרו בו לבדיקת הגישה לאינטרנט הוא סיני, והמסגרת עצמה יצאה מקהילת הסייבר הסינית. נוסף לכך, תעודת ה-TLS שהמסגרת מייצרת לעצמה נוצרת בזיכרון מחדש בכל הפעלה, כך שהשדה not_before מתעד את רגע העלייה של התהליך ואפשר לשחזר ממנו את זמני ההפעלה של שרתי השליטה. לפי החוקרים רובן נפלו בשעות עבודה באזור הזמן UTC+8. (אותו טריק עובד מול Cobalt Strike, ומשמש חוקרים כבר שנים.)
המקום של זה בנוף
קספרסקי ממסגרת את CyberStrikeAI כסימן לשינוי במשפחת מסגרות ה-C2, לא כמשהו ייחודי: כלים כמו HexStrike AI מכסים את שלב המצא ושבור, Sliver, Mythic ו-Havoc מכסות את ההיאחזות והשליטה, ו-CyberStrikeAI סוגרת את השרשרת כולה בתוך תהליך שרת אחד. זו גם לא הופעתה הראשונה בשטח. BleepingComputer דיווח בתחילת מרץ שחוקרי Team Cymru, ובראשם ויל תומס, זיהו 21 כתובות IP שעליהן רצה המסגרת בין 20 בינואר ל-26 בפברואר 2026, רובן בסין, בסינגפור ובהונג קונג. רק אחת מהן נקשרה ישירות לקמפיין נגד ציוד FortiGate, דרך באנר שירות בפורט 8080.
ההערכה המעניינת בדוח היא דווקא זו שמורידה את הלחץ. החוקרים כותבים שהכנסת ה-AI לשרשרת התקיפה לא מציבה בשלב הזה אתגרי זיהוי חדשים מהיסוד, כי כל העבודה החכמה נשארת בצד התוקף, ועל המכונה הנגועה מתרחשות פעולות מוכרות: Kerberoasting, AS-REP Roasting, dump של lsass, DCSync ו-Golden Ticket. החידוש הוא במהירות ובקלות. "תזמור ה-AI הוריד את דרישות המקצועיות מהאופרטור, אבל לא הוציא את המתקפה מגבולות מה שמגנים כבר מכירים ומסוגלים לזהות", כתבו החוקרים. ככל שהמודלים ישתפרו, הם מעריכים, תפקיד האופרטור יזוז מהגדרת משימות לפיקוח על מה שהמודל עושה.
מה זה אומר בפועל
לוגיקת הזיהוי שצריכה לתפוס את הקמפיין הזה כנראה כבר קיימת אצלכם. משימה מתוזמנת בשם SystemUpdate, dump של lsass דרך comsvcs.dll, שורת פקודה אופיינית של WMIExec ו-PowerShell מקודד ב-Base64 הם דברים שכלי EDR סבירים מתריעים עליהם, ואף אחד מהם לא השתנה בגלל שמודל שפה בחר בו. מה שהשתנה הוא תקציב הזמן: בין התקנת הסוכן להשתלטות על מנהלי הדומיין עברו שלושה עד ארבעה ימים, וכמה מהשלבים המכריעים נדחסו לשעות בודדות. התראה שמחכה לטיפול עד הבוקר עלולה לחכות יותר מדי. ומכיוון שהכניסה הייתה דרך שרת SQL Server פרוץ, שווה לבדוק מי יכול להגיע אליו מבחוץ ובאילו הרשאות רץ חשבון השירות שלו.
תגובות