ב-19 בדצמבר 2025, בשעה 18:50:05 לפי שעון UTC, עלה למאגר GitHub ציבורי קובץ שהכיל מפתח גישה ל-AWS ואת הסוד שנלווה אליו. עשר שניות אחר כך, ב-18:50:15, הופיעה ביומן הפעילות של חשבון ה-AWS פעולה שאיש מהצוות לא ביצע: צירוף מדיניות הרשאות בשם AWSCompromisedKeyQuarantineV3 למשתמש שהמפתח שייך לו. שנייה אחרי זה נשלח מייל מ-GitHub, כעבור עוד עשר שניות מייל מאמזון, ותוך פחות מדקה נפתחה בחשבון קריאת תמיכה.

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

למה דווקא מפתחות הגישה

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

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

מה קורה בעשר השניות האלה

מאז 2018 מריצה GitHub תוכנית שבה ספקי שירות רושמים אצלה חתימות של פרטי האימות שלהם. GitHub סורקת כל דחיפה למאגר ציבורי, וכשהיא מזהה מחרוזת שתואמת לחתימה של ספק מסוים היא לא מסתפקת בהתראה לבעל המאגר, אלא פונה ל-endpoint שאותו ספק רשם מראש ומעבירה לו את הממצא. הספק מחליט מה לעשות. בתיעוד של GitHub כתוב במפורש שסודות של שותפים מדווחים ישירות לספק ואפילו לא מוצגים כהתראה במאגר עצמו. אמזון הצטרפה לתוכנית ב-2020, ולפי Unit 42 התיעוד של GitHub מונה היום יותר מ-500 חתימות של למעלה מ-200 ספקים.

השרשרת בניסוי נראתה כך. ב-18:50:05 הדחיפה הושלמה. ב-18:50:15 נרשם ביומן צירוף המדיניות. ב-18:50:16 יצא המייל של GitHub, ב-18:50:17 נפתחה בקונסולה התראת בריאות בשם Risk IAM quarantine, ב-18:50:26 הגיע המייל של אמזון, וב-18:50:59 נפתחה קריאת התמיכה שמפרטת איזה מפתח נחשף. מעניין לא פחות מה לא קרה: פתיחת התראת הבריאות ופתיחת קריאת התמיכה לא הותירו שום רישום ביומני CloudTrail, שירות התיעוד שרושם כברירת מחדל את פעולות הניהול בחשבון ושומר אותן 90 יום.

מדיניות שכל תוכנה שלה היא רשימת איסורים

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

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

הגרסה הראשונה, מ-11 באוגוסט 2020, אסרה 28 פעולות בחמישה שירותים בלבד: ניהול זהויות, מכונות וירטואליות, ניהול ארגונים, פונקציות ללא שרת ו-Lightsail. הגרסה שבתוקף היום אוסרת 100 פעולות ב-21 שירותים, לפי ספירה בדף הרשמי של אמזון.

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

בגרסה הראשונה כבר נאסרו יצירת תפקיד הרשאות ויצירת פונקציה ללא שרת. Unit 42 מקשרת את זה לקמפיין כריית מטבעות שאמזון עצמה תיעדה, שבו התוקפים יצרו תפקיד חדש, חיברו אותו לפונקציה שהם יצרו, והריצו דרכה כרייה על חשבון הקורבן. בגרסה השנייה, מ-21 באפריל 2021, נוספה מחיקת אובייקטים מאחסון האובייקטים של אמזון, הרשאה שרלוונטית לתבנית סחיטה מוכרת: התוקף מוציא את הנתונים ואז מוחק אותם מהמקור כדי להגדיל את הלחץ לשלם. ובעדכון האחרון של אותה גרסה נוספו חמש הרשאות של Bedrock, שירות המודלים המאורחים של אמזון. את השינוי הזה מייחסת Unit 42 למחקר של Permiso, שתיאר איך תוקפים שמשיגים מפתחות גישה משתמשים בהם כדי להריץ קריאות למודלים על חשבון הקורבן, בין היתר כדי להפעיל שירותי צ'אט לא מסוננים. בדיקה שערכנו מול הדף הרשמי מאשרת שחמש ההרשאות האלה אכן נמצאות ברשימה, ו-InvokeModel ביניהן.

(ואגב, לפי הדוח נוצרה הגרסה השנייה של V3 אחת-עשרה דקות אחרי המקבילה לה בגרסה הקודמת, עם אותן הרשאות בדיוק.)

מה היומן לא מספר לכם

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

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

ומה עם כל מה שלא נאסר?

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

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

המפתח נשאר חי. רק חלק מהדלתות ננעלו.

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

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