Microsoft Threat Intelligence חשפה קמפיין שבו תוקפים השתמשו במסגרת AI אוטונומית כדי לחפש Secrets במאגרי GitHub ציבוריים, לנתח את הממצאים ולהמשיך מהם לפעולות תקיפה בענן. במקרה אחד, סוכן AI התקדם מאיתור Client Secret ב־GitHub להוצאת מידע מ־Azure Key Vault בתוך חמש דקות.
המחקר, שפורסם ב־5 בנובמבר 2026, מתאר שינוי משמעותי בקצב התקיפה. חיפוש ידני של מפתחות, סיסמאות ו־Tokens במאגרים פתוחים הוא טכניקה ותיקה, אבל כלי Agentic AI יכולים להריץ שאילתות בהיקף גדול, לזהות איזה Secret שייך לאיזה שירות, לנסות להתחבר ולהחליט על הצעד הבא — עם הרבה פחות זמן מקלדת של התוקף.
מה חיפשו הסוכנים?
לפי Microsoft, התוקפים חיפשו בין היתר:
- Client Secrets ואישורי OAuth של יישומים;
- אישורי Service Principal ל־Microsoft Entra ID;
- מפתחות גישה לשירותי ענן ואחסון;
- Connection Strings וקבצי תצורה;
- API Keys לשירותי AI ולמודלי Inference;
- Secrets שנשמרו בסקריפטים, בקוד וב־Commit History.
המסגרת האוטונומית שילבה את שם הארגון עם מילות חיפוש הקשורות למפתחות ולשירותי ענן. לאחר איתור Secret, הסוכן ניסה לקבוע אם הוא עדיין פעיל, לאיזה Tenant או יישום הוא שייך ומה ניתן לבצע באמצעות ההרשאות שלו.
מ־GitHub אל Entra ID ו־Azure
Microsoft החלה לראות החל מ־28 באוקטובר 2026 כניסות מוצלחות של Service Principals באמצעות אישורי יישומים שנגנבו או הודלפו. בחלק מהמקרים מדובר היה ביישום Multi‑tenant של ספק, ולכן פגיעה באישור שבבעלות הספק אפשרה לתוקף לנסות להגיע גם ל־Tenants של לקוחות downstream.
לאחר ההתחברות, הסוכנים ביצעו גילוי משאבים בענן, חיפשו אישורים נוספים ב־Azure DevOps והוציאו מידע מ־Key Vault ומ־Storage Accounts. הם השתמשו גם ב־Azure VM Run Command, יכולת שמאפשרת להריץ סקריפטים במכונה וירטואלית ועלולה לחשוף אישורים לא מוגנים, זהויות Workload ונתונים נוספים.
מחיקת ה־Secret מהקוד אינה מספיקה
זהו אחד המסרים החשובים במחקר: Secret שפורסם צריך להיחשב פרוץ גם אם ה־Commit נערך או הקובץ נמחק. הערך עלול להישאר בהיסטוריית Git, ב־Forks, ב־Caches, בארכיונים ובמערכות אינדוקס.
התגובה הנכונה היא לבטל או לסובב את האישור, לבדוק את היסטוריית השימוש שלו ולחקור כל משאב שאליו הייתה לו גישה. אם היישום קרא Secrets מתוך Key Vault, יש לסובב גם את האישורים שנשמרו בכספת ולא רק את האישור ששימש להיכנס אליה.
צעדי בלימה וחקירה
- לסרוק קוד והיסטוריה: לבדוק Repositories ציבוריים ופרטיים, Branches, Pull Requests, Issues ו־Commit History.
- להפעיל Push Protection: לחסום העלאה של סוגי Secrets נתמכים לפני שה־Commit מתקבל.
- לבטל מיד אישורים חשופים: להסיר Client Secrets, Certificates ו־Federated Credentials שלא נוצרו או אושרו כראוי.
- לבדוק Sign‑ins של Workload Identities: לחפש התחברויות חריגות, IPs לא מוכרים ויישומים שפועלים מחוץ לדפוס הרגיל.
- לסקור הרשאות: לצמצם גישה של Service Principals ל־Key Vault, Storage, VMs ו־Azure DevOps.
- לחקור Persistence: לבדוק אם נוספו Credentials חדשים, הרשאות, Applications או Scripts לאחר החדירה.
- לסובב Secrets downstream: כל אישור שהיה נגיש ליישום הפגוע דורש בדיקה וסיבוב.
עדיף Managed Identity על Secret ארוך טווח
Microsoft ממליצה להעביר יישומי Azure למנגנוני זהות שמפחיתים תלות ב־Client Secrets ארוכי טווח. Managed Identity מאפשרת ליישום לקבל Token בלי לשמור סיסמה בקוד, בקובץ תצורה או ב־Pipeline.
כאשר עדיין נדרש Secret, יש לשמור אותו בכספת ייעודית, להגדיר תוקף קצר, לבצע Rotation אוטומטי ולתעד בעלות. Azure Key Vault צריך להפיק Logs והתראות על דפוסי קריאה חריגים, גישה ממיקום חדש וניסיון לקרוא מספר גדול של Secrets בזמן קצר.
מה המשמעות לצוותי IT ו־MSP?
קמפיין כזה מסוכן במיוחד לספקי שירות וליישומי Multi‑tenant. אישור אחד של ספק עלול להפוך לנתיב אל לקוחות רבים. לכן MSP צריך לבדוק גם הרשאות Partner Center ו־GDAP, לתעד אילו יישומים חוצים Tenants ולהחזיק תהליך הודעה ללקוחות במקרה של חשיפה.
החידוש אינו עצם הדליפה, אלא מהירות המעבר מדליפה לניצול. חלון התגובה התקצר: סריקת Secrets צריכה להתרחש בכל Push, והביטול צריך להיות אוטומטי ככל האפשר.
מקורות
- Microsoft Security: Threat actors use agentic AI tooling to find and abuse exposed secrets
- Microsoft Learn: Secure your Azure Key Vault secrets
תמונה: Jakub Żerdzicki / Unsplash, ברישיון Unsplash. היוצר, דף המקור והרישיון מתועדים במדיה.
