JadePuffer/Storm-3168: שחקן סוכני מוחק את האחסון של דייר Azure בהתפרצות הרסנית בת 7 דקות

דיווחה Microsoft Security Research ב-25 בספטמבר 2026 כי שחקן שהשתמש בשני service principals שנפרצו פעל בתוך tenant של Azure שאינו מזוהה בשמו בראשית יוני 2026, החל ביותר מ-15 שעות של איסוף מודיעין, ולאחר מכן, בתוך כשבע דקות, ניסה למחוק יותר מ-100 חשבונות אחסון והצליח לגבי רובם, ומחק Azure Key Vault, Function App ותוכנית App Service. Microsoft מייחסת את החדירה לשחקן שהיא מכנה Storm-3168, שאותו מכנה חברת האבטחה Sysdig JADEPUFFER ותיעדה ביולי 2026 כמבצע כופרה הראשון שהופעל מקצה לקצה על ידי מודל שפה גדול. Microsoft מסרה שלא נמצא מכתב כופר ולא אישרה שחולצו נתונים. הארכיון רושם את הקמפיין הזה כתקרית בחומרה גבוהה עם מעורבות AI מאושרת ונזק ממשי, והערך המלא בארכיון תקרי ה-AI של Orca כולל את מקורותיו, את דירוג החומרה ואת הערכת רמת הביטחון.

שם הקורבן לא נמסר. הדוח של Microsoft מתאר דייר Azure יחיד, שני service principals שנפרצו והשתייכו לו, וחלוקת עבודה ביניהם: אחד מהם עסק באיסוף מודיעין במשך כ-15 שעות ו-30 דקות וביצע יותר מ-300 פעולות קריאה מוצלחות שכללו מנייה של מכונות וירטואליות, מנויים, קבוצות משאבים ומשאבים; השני ביצע גילוי, את הפעולות ההרסניות ואת איסוף פרטי הגישה. Microsoft לא ציינה כמה ארגונים נפגעו, ולא הצליחה לקבוע כיצד נפרצו ה-service principals לראשונה.

מה שהטלמטריה מראה, לפי הסדר

הגורם הראשי השני החל לפעול כ-90 דקות לאחר שהראשון החל, ומיפה מכונות וירטואליות וקבוצות משאבים בשתי מנויים בכחמש שניות, לפי מיקרוסופט. שתי הזהויות השתמשו בתשתית שמיקרוסופט מקשרת ל-Storm-3168, חלקו את אותה טביעת אצבע רשתית והציגו את אותו user agent, python-requests/2.34.2. מיקרוסופט מסרה כי התזמון וחלוקת העבודה "מעידים בעוצמה על הרצה אוטומטית או מתוסרטת".

כ-16 שעות לאחר מכן, הזהות השנייה בדקה מאגרי תצורה של Azure App Service לאיתור אישורי גישה חשופים וחיפשה, ללא הצלחה, את Azure OpenSearch. שבעים שניות לאחר מכן, היא ניסתה לבצע פעולת ListKey מול חשבון אחסון שלא היה קיים. פחות משנייה לאחר הקריאה הכושלת הזו, החל ההרס. במהלך 35 הדקות הבאות Microsoft ספרה יותר מ-150 פעולות הרס או איסוף אישורי גישה; שלב ההרס העיקרי נמשך כ-שבע דקות.

שבע הדקות, והבקרות שהחזיקו

Microsoft אומרת שרוב חשבונות האחסון שהתוקף כיוון אליהם נמחקו בהצלחה. התוקף גם מחק Azure Key Vault, Function App ותוכנית App Service שהיו באותה קבוצת משאבים ונראו כתומכות ב-Function App. היעד לא היה מוגבל לאחסון: Microsoft תיעדה ניסיונות מרובים למחוק מנעולי Azure Site Recovery ומנעולי הגנה של Azure Backup, ודיווחה שהניסיונות הללו נכשלו.

{{1}}Microsoft אומרת שלא כל המחיקות הצליחו, והסיבות שונות באופן שחשוב למגנים.{{/1}} כמה חשבונות אחסון שרדו משום ש{{2}}נעילות משאבים של Azure והגנת מחיקה ברמת חשבון האחסון{{/2}} חסמו את הפעולה. הניסיונות המקבילים למחוק מסדי נתונים של Azure SQL נכשלו מסיבה אחרת: {{3}}כולם השתמשו בגרסת API שאינה נתמכת{{/3}}. Cloud Security Alliance תיארה זאת {{4}}כשגיאה תפעולית ולא כפעולה חסומה{{/4}}. Microsoft סיכמה את השילוב של מחיקת משאבים, ניסיונות להפריע לשחזור ואיסוף פרטי גישה כ{{5}}"תואם לטקטיקות שיכולות לתמוך בפעולות של תוכנות כופר וסחיטה"{{/5}}.

החשבון של Microsoft מתאר הקצאות תפקיד רגילות של Azure ולא ניצול לרעה של Azure עצמו. הוא מצא שתפקיד Storage Account Contributor שהוענק לקבוצה אפשר את השמדת האחסון, תפקיד Contributor ישיר אפשר את מחיקת שלושת משאבי האפליקציה ושליפת מפתח נוספת, ותפקיד SQL DB Contributor ישיר אפשר את ניסיונות ה-SQL הכושלים. Microsoft הבחינה בחמישה אסימונים ייחודיים שהונפקו עבור ה-service principal השני: ארבעה תמכו במחיקה והחמישי טיפל במלאי האחסון ובשליפת מפתחות. שניים מאסימוני המחיקה היו פעילים במהלך אותה תקופה של 70 שניות. הדוח גם מציין שחשבונות אחסון עם שמות בנושא terraform ו-backup היו בין היעדים, ייתכן כדי לפגוע ביכולת השחזור.

ההחזר עבור מפתחות אחסון

כ-30 דקות לאחר שההשמדה הסתיימה, אותו פרינסיפל חזר. הוא ערך מלאי של חשבונות אחסון וביצע יותר מ-30 בקשות ListKeys מוצלחות, כולל כנגד אחסון המקושר ל-Site Recovery. חשבון אחסון בשם דומה באותה קבוצת משאבים נותר ללא פגע במהלך שלב המחיקה, ולאחר מכן בוצעה בו בהצלחה פעולת ListKeys. Microsoft לא הבחינה בהודעת כופר ולא אישרה דליפת נתונים מוצלחת, אך ציינה שהמפתחות שנאספו יכולים לתמוך בדליפה עתידית.

הרצף הזה משנה את משמעות ההתאוששות, לפי רוס פיליפק, מנהל אבטחת המידע הראשי ב-Corsica Technologies, ששוחח עם CSO Online על התקרית. שחזור נכסים שנמחקו אינו מספיק, לדבריו, משום שהבקשות המאוחרות יותר למפתחות אחסון עלולות ליצור נתיב נוסף לנתונים; על המגיבים לקבוע אילו זהויות ומפתחות נגעו בהם ולבחון את השימוש בהם לפני שיבטחו בשירותים המשוחזרים. "ברגע שתוקפים מחזיקים בזהות של יישום, הפעילות שלהם יכולה להיראות כמו ניהול ענן שגרתי", אמר פיליפק ל-CSO Online.

כיצד פרטי ההתחברות נחשפו

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

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

מיקרוסופט תיארה גם בדיקות נרחבות יותר של תשתית המקושרת ל-Storm-3168 מאז תחילת 2026 נגד Azure App Services בניהול WordPress, PHP-CGI, נקודת הקצה של Langflow /api/v1/validate/code, ונתיבים דמויי webshell. היעדים הללו לא חפפו למנויים של הקורבן, ומיקרוסופט לא מצאה נתיב מ-App Service אל אישורי Azure Resource Manager. הדוח מפרט שלושה אינדיקטורים: 45.131.66[.]106 עבור בדיקות ובקשות ARM זדוניות, ו-34.153.223[.]102 ו-64.20.53[.]230 עבור בדיקות App Service.

אותו שחקן, פעולה אחרת

הדוח של Sysdig מ-1 ביולי 2026 הוא הסיבה שהמילה "agentic" נקשרת לתוקף הזה בכלל. Sysdig תיארה את JADEPUFFER כמקרה המתועד הראשון של כופרה סוכנית — "מבצע סחיטה שלם שהונע מקצה לקצה על ידי מודל שפה גדול" — ואמרה שהיכולות שלו הגיעו מסוכן בינה מלאכותית ולא מערכת כלים המופעלת בידי אדם. בחדירה ההיא, התוקף ניצל CVE-2025-3248 במופע Langflow החשוף לאינטרנט, הצפין 1,342 פריטי תצורה של Nacos באמצעות פונקציית AES_ENCRYPT() המובנית של MySQL, הפיל את הטבלאות המקוריות, והשאיר טבלת README_RANSOM עם כתובת ביטקוין ואיש קשר ב-Proton Mail. Sysdig דיווחה על יותר מ-600 מטענים נפרדים, קוד שמתאר את עצמו, ומטען מתקן רב-שלבי שהופיע לאחר התחברות Nacos שנכשלה בתוך 31 שניות. Sysdig גם אמרה שלא הייתה לה ראות אל פרומפט המערכת או תצורת הסוכן.

קמפיין Azure הוא פעולה נפרדת של אותו גורם, ולא חזרה על החדירה ביולי: הוא עסק במחיקה ובאיסוף מפתחות, לא בהצפנה, ומיקרוסופט לא מצאה פתק כופר. הקשר בין השניים נשען בחלקו על תשתית. Cloud Security Alliance ציינה בהערת מחקר מ-28 בספטמבר ששתיים מכתובות ה-IP שמיקרוסופט מפרטת, 45.131.66[.]106 ו-34.153.223[.]102, הופיעו בדיווח של Sysdig מיולי. באותה הערה הוזהר כי שימוש חוזר ב-IP לבדו אינו יכול לשלול אחסון משותף של צד שלישי.

הוקם, נבחן, ועדיין פתוח

המכניקה של החדירה ל-Azure מתועדת היטב. האוטונומיה אינה מתועדת לאותו סטנדרט, וההבדל הוא ההסתייגות החשובה ביותר ברשומה הזו.

כפי שעולה מהטלמטריה של Microsoft: שני service principals שנפרצו בדייר אחד; יותר מ-300 פעולות קריאה מוצלחות במשך כ-15 וחצי שעות; יותר מ-100 ניסיונות למחיקת חשבונות אחסון, שרובם הצליחו; מחיקה של Key Vault, Function App ותוכנית App Service; מחיקות של מסדי נתונים SQL שנכשלו כולן עקב גרסת API לא נתמכת; חשבונות אחסון שניצלו בזכות נעילות משאבים והגנת מחיקה; יותר מ-30 בקשות ListKeys מוצלחות לאחר ההרס; אישורי התחברות של service principal בטקסט גלוי בנושא GitHub ציבורי ובהיסטוריית העריכות שלו; לא נצפה פתק כופר; ולא אומתה הברחת נתונים.

להערכת Microsoft: כי הפעילות שייכת ל-Storm-3168; כי השילוב של מחיקה, הפרעה לשחזור ואיסוף מפתחות עולה בקנה אחד עם כופרה וסחיטה; כי סביר שההרצה הייתה אוטומטית או מתוסרטת; וכי ייתכן שהמפתחות שנאספו יתמכו בדליפה עתידית. הדוח הפומבי של Microsoft אינו מתאר סוכן אוטונומי שמנמק את השלבים הספציפיים ל-Azure.

פתוח: כיצד ה-service principals נפרצו לראשונה; זהות הקורבן ומספר הארגונים שנפגעו; האם נתונים כלשהם יצאו מה-tenant; והאם סוכן AI, ולא סקריפט, הנחה את פעולות ה-Azure עצמן.

ארגון Cloud Security Alliance הציג במדויק את הפער הראייתי בהערתו מ-28 בספטמבר: כך נכתב שם, האפיון ה״agentic״ נשען כיום ״על הדיוק, הקצב וחלוקת העבודה בין זהויות״, ולא על עקבות חשיבה של סוכן שנלכדו. הראיות שבהן השתמשה Sysdig ביולי — מטענים המתארים את עצמם ומחזור מהיר של אבחון ותיקון — נעדרות מהרשומה הציבורית של קמפיין Azure. ניק טאוסק מחברת האבטחה Swimlane אמר ל-CSO Online כי הראיות מ-Azure מראות ״אוטומציה מתואמת במקום להוכיח ש-AI הנחה כל שלב״.

הסיקור של החשיפה השתמש במסגור החזק יותר. הכותרת של BleepingComputer תיארה "התקפות AI אגנטיות" נגד Azure, וזו של Dark Reading תיארה "שחקן AI" שפרץ לדייר Azure; הדוח של Microsoft עצמה אומר שהתזמון וחלוקת העבודה "מצביעים בחוזקה על ביצוע אוטומטי או מתוסרט" ואינו מייחס את השלבים הבודדים ב-Azure לסוכן.

הארכיון מדרג רשומה זו בדרגת ודאות A ואינו מסמן אותה כשנויה במחלוקת. תווית מעורבות ה-AI "המאומתת" של הרשומה נשענת על הייחוס ל-JADEPUFFER, השחקן ש-Sysdig תיעדה כמונע על ידי LLM; אין זו טענה ש-Microsoft לכדה את הנמקת הסוכן במהלך המחיקות ב-Azure. הנזק מבוסס, האוטומציה מבוססת, והאוטונומיה מוסקת.

מה שמיקרוסופט אומרת שצריך להשתנות

ההמלצות של Microsoft הן אופרטיביות, והן נובעות ישירות מאופן פעולת החדירה הזו. הן דורשות מהמגנים להפעיל את תוכניות Microsoft Defender for Cloud הרלוונטיות עבור Resource Manager, Storage, Key Vault, App Service ו-Databases; להרחיק פרטי התחברות של service principal, מפתחות אחסון, מחרוזות חיבור וסודות אחרים מקוד מקור, מתצורה, ממאגרים ומנושאים; להשתמש ב-Microsoft Entra Workload ID במקום בסודות ארוכי-טווח; ליישם הרשאה מינימלית ולבחון הקצאות Azure RBAC עבור זהויות עומס עבודה; ולהגביל ולנטר משאבי גיבוי ושחזור, כולל ניסיונות לשנות את בקרות ההגנה שלהם.

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