ברוב מתקפות הסייבר שאנחנו מכסים כאן, הנוזקה שמגיעה למחשב מתחילה לעבוד. במתקפה הזו היא מחכה. חברת המחקר הישראלית Dream פרסמה ב‑ 8 באוקטובר 2026 דוח על גל פעילות שנצפה בין אוגוסט לאוקטובר והיה פעיל בעת הפרסום. החוקרים הצליחו לעשות דבר נדיר: לקרוא את מחסני הפיקוד של התוקף מבפנים. מה שהם מצאו שם אינו רשימת קורבנות. הם מצאו תור. כעשרה מחשבים שונים נרשמו אצל התוקף ודיווחו על עצמם. רק שניים מהם קיבלו בפועל את הדלת האחורית המלאה. אצל כל השאר היא נשארה על הדיסק, מוצפנת, ממתינה להחלטה שלא הגיעה.
אחד מהשניים הינו דמות בכירה בישראל הקשורה למגזר הביטחוני. השני הוא גוף ממשלתי באזור כורדיסטן שבעיראק, שהסביבה שנפגעה אצלו קשורה לתשתית ענן; שם אומתה גם גניבת פרטי גישה וגם הוצאה של 1GB לפחות של מידע.
מי הם DarkBlinders
הקבוצה האחראית לפעילות מכונה DarkBlinders. לפי Group‑IB היא פעילה מאז ספטמבר 2024. בתקופה הזו נרשמו לה שבעה קורבנות ארגוניים מאומתים בשתי מדינות, בשני מגזרים: תעופה ותקשורת, בעיראק ובאיחוד האמירויות. זו אינה קבוצה שמודדים אותה בהיקף. Group‑IB מתארת אותה כמי שמעדיפה סבירות על נפח: מעט פיתיונות מוקפדים, תשתית מותאמת לאזור והשתלות שקטות שנבנו לשרוד זמן ארוך ולאסוף מידע באופן מתמשך, לא לשבש.
פאלו אלטו, שמסמנת את האשכול הזה CL-STA-1178, קובעת שהוא תוקף תשתיות בעלות ערך גבוה, בהן תקשורת, תעופה וגופים קריטיים אחרים, בעיראק, בישראל ובאיחוד האמירויות. לישראל יש אפוא מקום קבוע ברשימת היעדים של הקבוצה הזו, לא הופעה חד‑פעמית.
שני דוחות, שני גלים — וזה חשוב
לפני שנכנסים למנגנון, צריך להפריד בין שני דברים שהתקשורת המקצועית נוטה למזג.
הדוח של Unit 42 בפאלו אלטו, שפורסם ב‑ 6 באוקטובר, מתעד מתקפה שהחברה מכנה Blinder Tunnel. התשתית שלה הועמדה ונבדקה כבר בנובמבר 2025, נשארה רדומה אך תפעולית, עד שהופעלה בסוף מרץ 2026 נגד יעד בודד במגזר התשתיות הקריטיות בעיראק. שם מופיע מסלול אתגר הקוד.
הדוח של Dream מתעד גל מאוחר ונפרד, מאוגוסט עד אוקטובר 2026. שם מופיעים אפליקציית הווידאו המזויפת, ארכיטקטורת שני המחסנים והקורבנות הישראלי והעיראקי. שני הגלים משתמשים באותה משפחת כלים ואף באותם שמות קבצים, אך לא באותם תפקידים: קובץ שמשמש בגל אחד להעלאת טביעת אצבע של המחשב משמש בגל האחר להורדת חומר ההפעלה מהמפעיל. מי שקורא תיאור מנגנון של הקבוצה הזו ולא שואל מאיזה גל הוא מגיע, יקבל שרשרת שמעולם לא רצה כך בשום מקום.
מה שמתואר להלן בחלק ההרצה הוא הגל של Unit 42. מה שמתואר בחלק הפיקוד הוא הגל של Dream.
ההרצה שמקדימה את ההידור
נתחיל מהסוף. Unit 42 מנסחת את התוצאה במשפט אחד: הנוזקה נפרסה, העתיקה את עצמה והופעלה ברקע בזמן שהמפתח עוד קרא את קובץ ה‑ Readme המתחזה.
לא הידר. קרא.
ההסבר נמצא בהתנהגות שגרתית לחלוטין של סביבת הפיתוח. פתיחת פרויקט ב‑ Visual Studio מפעילה ברקע בנייה בזמן תכנון, שתפקידה לפתור תלויות ולהכין את הסביבה לעבודה. במהלך האתחול הזה נקרא יעד בנייה בשם GetFrameworkPaths. התוקפים הגדירו בקובץ הפרויקט שלהם יעד נושא בדיוק את השם הזה. ההגדרה שלהם דרסה את זו של מיקרוסופט. מרגע זה, הפעולה שמפעילה את הקוד הזדוני אינה פעולה של התוקף אלא של הכלי: msbuild.exe עושה את מה שהוא תמיד עושה. בדרך הוא מריץ הוראות זרות. הסיווג המקצועי לטכניקה הזו הוא הרצה בתיווך כלי פיתוח מהימנים. Unit 42 מנסחת בזהירות שהיא יכולה להיות יעילה — בדיוק מפני שההפעלה נשענת על התנהגות צפויה ולגיטימית.
אין כאן פגיעות שממתינה לעדכון. יש כאן כלי שעובד כמתוכנן.
משם נמשכת השרשרת בשני צעדים נוספים, שניהם נועדו להקטין את הנראות. בצעד הראשון, MSBuild מפעילה קובץ אירוח חתום ולגיטימי של Visual Studio, שהתוקפים שינו את שמו ל‑ RuntimeBroker.exe. דרך קובץ התצורה הנלווה לאותו קובץ הרצה הם מחליפים את מנהל האתחול של היישום בגרסה משלהם, כך שהשליטה בהרצה עוברת לנוזקה עוד לפני שיישום המאחסן עולה. בתוך אותו קובץ תצורה, בכמה שורות XML, הם גם מכבים את מנגנון מעקב ההרצה של Windows. בלשון הזהירה של Unit 42, הדבר עלול לפגוע ביכולת הזיהוי, מפני שהמנגנון הזה קריטי לניטור הרצה ולאיתור איומים שפועלים בזיכרון. בצעד השני הקובץ החתום, שחשוף לחטיפת סדר חיפוש של ספריות, טוען לזיכרון את הספרייה של התוקף.
כאן ראוי לציין מה שעצר את הדבר הזה בפועל, גם אם זה לא נוח לנו: במקרה שתיעדה Unit 42, מערכת הגנת הקצה של החברה סימנה את קובץ ה‑ slnx של הפתרון כאיום בדרגת חומרה גבוהה ומנעה את ההרצה לפני כל אינטראקציה של המשתמש. ההמלצה שהחברה גוזרת מכך היא לנטר קבצי הרצה שטוענים ספריות לא מוכרות או לא תקניות מחוץ לתיקיות המערכת.
הגיוס כמסלול תקיפה
מי שפתח את הפרויקט הזה לא חשב שהוא בודק קוד של זר. הוא חשב שהוא עובר מיון לעבודה.
לפי הערכת Unit 42, היעד הוא מפתח תוכנה שיושב בעיראק; החברה מנסחת זאת כהערכה ולא כעובדה, בהתבסס על פרופיל תפעולי ועל ראיות טכניות. התוקפים הציגו את עצמם כמחלקת מערכות המידע של Dubai Airports, חברת ההפעלה של נמלי התעופה בדובאי. הם פנו אליו בהצעה לתפקיד פיתוח. בשלב הראשון הוא התקין קובץ בשם Dubai Airport Careers, שהעמיד על המחשב שלו פורטל קריירה עצמאי ללא תקשורת חוצה‑רשת. בו הוא התחבר בפרטי גישה שקיבל מה"מגייסים" ומילא שאלון משאבי אנוש בן עשר שאלות.
השאלון לא עשה דבר. לא הוציא מידע, לא פנה לשרת ולא הריץ קוד זדוני. Unit 42 מסבירה שזו בדיוק המטרה: שלב שאין בו שום סימן רע בונה אמינות ומרפה את הדריכות של היעד, לקראת המטען שיגיע אחריו.
הוא הגיע בדמות מטלה מקצועית. באפריל 2026 נחשף לחוקרים, דרך הגשה נוספת לאותו שירות ציבורי לבדיקת קבצים, ארכיון פרויקט Visual Studio שהוצג כמבחן קוד ונשא את השם DubaiAirport_Carrers_IT_Test.zip, שגיאת הכתיב באנגלית במקור. בתוכו פרויקט C# לניהול טיסות וקובץ הוראות אישי, שנכתב בשם מנהל בכיר באותה מחלקת מערכות מידע. בקוד הושתל באג מכוון בשיטה פנימית, לולאה שמדלגת על האיבר האחרון. היעד נתבקש לבנות ולהריץ את הפרויקט כדי למצוא אותו ולתקנו. Unit 42 מעירה שזו מטלה שמפתח מנוסה פותר בלי קושי.
נקודה שחייבת להיאמר במפורש: Unit 42 מציינת שאינה מודעת לשום פריצה, השתלטות או פגיעות בתשתיות או במערכות של Dubai Airports. השם של החברה שימש לתחפושת. אין טענה שמשהו אצלה נפגע.
ערוץ הפיקוד: מחסן קוד ציבורי
בגל שתיעדה Dream, הפיקוד והשליטה אינם יושבים על שרת של התוקף אלא על חשבון GitHub. פאלו אלטו קוראת לשיטה הזו living off the cloud, שבעברית אפשר לקרוא לה "מחייה מן הענן": פנייה של מחשב ארגוני אל ממשק התכנות של GitHub אינה נראית חריגה בשום ארגון שכותב קוד, לפיכך התעבורה הזדונית מתמזגת בתעבורה הרגילה.
חשוב לא להגדיל את הטענה הזו מעבר למה שהיא. זה ערוץ המשימות של ההשתלה, לא כלל התשתית של הקבוצה. Group‑IB מתעדת לצד ערוץ ה‑ GitHub גם שכבת פיקוד רגילה מעל HTTPS עם כתובות משל עצמה; Unit 42 מתעדת נקודת קצה ייעודית למינהור בגל שלה; Dream עצמה מתעדת שני ערוצים נוספים — שירות ישיר בכתובת משל התוקף ומתווך גיבוי שרץ כפונקציה בשירות ענן ציבורי. לפני שההשתלה מסכימה להשתמש במתווך הזה היא בודקת שהתשובה שחוזרת ממנו באמת נראית כמו תשובה של GitHub, לפי מבנה ה‑ JSON וכותרת מזהה בקשה אופיינית.
בתוך החשבון עצמו יש הפרדת תפקידים שהיא לב העניין. מחסן אחד מקבל את הדיווחים מהמחשבים הנגועים. מחסן שני מעביר פקודות ומחזיר תוצאות, אך הוא נפתח רק למי שנבחר.
מה שהמחשב מספר על עצמו
הדיווח הראשוני אינו שורה אחת. ההשתלה מחשבת לעצמה מזהה ייחודי מגיבוב של מחרוזת קבועה יחד עם מזהה האבטחה של המשתמש, שם המכונה ושם המתחם. תחתיו היא כותבת קובץ שמצייר למפעיל תמונה שלמה של הסביבה שאליה הגיע.
התמונה הזו עשויה משני סוגים של מידע. יש בה פרטי זהות וסביבה — מי המשתמש, באיזה מתחם, מול איזה שרת הזדהות, באיזה אזור זמן ובאיזו שעה מקומית, באיזו שפת ממשק ואילו פריסות מקלדת מותקנות והאם ההשתלה הצליחה להשתרש. יש בה גם דבר שני, מעניין יותר: תוצאות של בדיקות שההשתלה מריצה על עצמה כדי להעריך האם היא יושבת במעבדה. היא בוחנת סימנים של מכונה וירטואלית, מחפשת תהליכים של כלי ניתוח, שוקלת כמה זיכרון ומעבד יש במכונה וכמה תהליכים רצים בה, מודדת חריגות תזמון, מסתכלת על קידומת כתובת החומרה, על שם המשתמש ושם המכונה, על גיל כונן המערכת ועל זהות התהליך שהפעיל אותה.
הנה הפרט שהופך את הרשימה הזו מסקרנות טכנית לתובנה: הבדיקות האלו אינן עוצרות את ההרצה. הן רק נרשמות. כלומר, הן אינן הגנה עצמית של הנוזקה מפני חוקרים, אלא דוח מצב עבור אדם שיקרא אותו ויחליט.
ההחלטה
כעשרה מחשבים הגיעו עד לנקודה הזו. שניים קיבלו את השלב השני.
Dream עצמה מנסחת את הפער הזה בזהירות, כמתיישב עם בחירה מכוונת של המפעיל, לא כמסקנה מוכחת. ראוי גם לדייק בספירה: אחד מאותם כעשרה מחשבים הינו, להערכת החוקרים, מכונה וירטואלית של המפעיל עצמו — הפנייה הראשונה שנרשמה, עם פריסת מקלדת פרסית — ולכן "עשרה" אינו מספר קורבנות.
מבחינה הנדסית ההפרדה הזו פשוטה. השלב השני יושב על הדיסק מוצפן. את המפתח לפענוחו מספק המפעיל בנפרד לכל מחשב. בלי המפתח אין דלת אחורית. עם המפתח, הקוד נפתח ונטען ישירות לזיכרון בלי להיכתב לדיסק כקובץ קריא.
דווקא ההפרדה הזו היא מה שאפשר לחוקרים להיכנס. בתוך הטוען נמצא אסימון גישה מוטבע ל‑ GitHub, שדרכו קיבלו החוקרים גישת קריאה למחסן הדיווחים. אסימון שני, זה שפותח את מחסן הפקודות, היה מוטבע דווקא בשלב השני המוצפן. את אותו שלב שני הם חילצו מהיסטוריית הגרסאות של המחסן: ההשתלה מוחקת את חומר ההפעלה מהקובץ אחרי השימוש, אך גרסה קודמת של אותו קובץ נשמרה בהיסטוריה, שממנה נגזר מפתח הפענוח. Dream מציינת שבאותה עת לא נמצאה דגימה גלויה מתאימה בשירות בדיקת הקבצים הציבורי, לפיכך נדרשו גם היסטוריית המחסן וגם שחזור מקומי של תהליך הפענוח כדי לבחון את הדלת האחורית. החוקרים מדגישים שפעולתם היתה קריאה בלבד, בלי לשנות תוכן ובלי לשלוח פקודה לאף השתלה.
שלוש בחירות עיצוב שכל מרכז ניטור צריך להכיר
- ראשית, הרצת PowerShell אינה פותחת powershell.exe. ההשתלה נושאת בתוכה ספרייה שיוצרת מרחב ריצה של PowerShell בתוך התהליך הקיים. בניסוח של Dream, הדבר מגביל את הנראות עבור זיהויים שמסתמכים על תהליך הבן הזה — וזיהוי כזה הוא מה שמוגדר ברוב הארגונים.
- שנית, קצב. בגל של Dream, בדיקת ההשתרשות הראשונה מתבצעת 121 שניות לאחר העלייה וחוזרת מדי שעה. הדלת האחורית מבקשת פקודות כל 63 שניות בקירוב, מנקה את הקובץ לאחר הקריאה וכותבת את התוצאות בשמות שמסדרים את החדשות לפני הישנות. קצב כזה הוא טביעת אצבע של מכונה, לא של אדם.
- שלישית, המחוכמת מכולן: מה קורה אם GitHub מבטלת את האסימון. בשני השלבים הוטמע מנגנון שמחליף לבד את פרטי הגישה. הוא מתעורר מדי שעה, גם בעקבות סירוב גישה. אחר כך הוא מחפש בפתיחות סוגיה במחסן ציבורי עמוס במיוחד של מיקרוסופט את מחרוזת התאריך של אותו יום, קורא טקסט שמוסתר בתוך הערה בלתי נראית בגוף התגובה, מפענח אותו חמש פעמים ברצף ומחליף את חשבון הפיקוד שלו. כך מפעיל יכול להעביר את כל ההשתלות לכתובת חדשה בלי לגעת באף מחשב נגוע, באמצעות תגובה בפרויקט קוד פתוח.
שני נתיבי הכניסה ומה שלא שוחזר
Dream מתעדת בגל שלה שני נתיבי הגעה:
- האחד הוא דפים מתחזים, שיש להם שני שימושים: קציר פרטי גישה והגשת קבצים. בצד קציר פרטי הגישה שוחזרו דפי הזדהות של Outlook Web App על מתחמים שהתחזו למשרד החוץ של כווית ולמזכירות הכללית של מועצת שיתוף הפעולה במפרץ, כולל הפניה לרכיבים שנראים אותנטיים מאתר אמיתי. אין בדפים האלו נוזקה ואין הורדה. מכאן גם המסקנה המעשית: לפי Dream, הזדהות מוצלחת בדף כזה יכולה לחשוף שירותי ענן מקושרים, קבצים משותפים, אנשי קשר ודואר, בלי לייצר שום התראת נוזקה בנקודת הקצה. בצד הגשת הקבצים נבנו דפים שמחקים קישור שיתוף של Google Drive, בהם מתחמים בנושאי הממשל האזורי של כורדיסטן ומשרד החשמל שלו; דף כזה מציג ארכיון, מודיע שאי אפשר להציג אותו בתצוגה מקדימה ומציע להוריד. כשל תצוגה מקדימה של ארכיון אינו מעורר חשד אצל מישהו. זה בדיוק מה שהופך אותו לכלי.
- הנתיב השני הוא אפליקציית פגישות מזויפת בשם StarkMeet, במתקין רגיל למראה ובמיתוג שאול מעולם מארוול. התצוגות המקדימות של המצלמה, המיקרופון ושיתוף המסך פועלות מקומית, אך כל ניסיון להצטרף לפגישה נכשל בהודעת שגיאה קבועה. האפליקציה הנראית והרכיבים הזדוניים מותקנים בנפרד, לפיכך מי שמוחק את האפליקציה אינו מוריד את ההשתלה.
מה שלא נמצא חשוב כאן לא פחות: Dream מציינת שלא שוחזרו לא הארכיון של StarkMeet עצמו ולא הודעת המסירה שהביאה אותו ושדואר דיוג או הזמנה לפגישה נשארים נתיב מסירה סביר אך לא מאומת.
מה שלא נקבע: הייחוס
כאן ראוי לדייק בדיוק כפי שהחוקרים דייקו, מפני שהם אינם מסכימים ביניהם על היקף הייחוס:
Dream מעריכה בביטחון בינוני עד גבוה שהפעילות שייכת לאותו אשכול תפעולי שמסומן UNC5795 ו‑ Dust Specter. בביטחון בינוני היא מעריכה שהאשכול המשולב הזה ו‑ UNC5187 עשויים להיות תתי‑אשכולות קשורים בתוך APT34. Unit 42 מצמצמת יותר: היא קובעת בביטחון גבוה שהפעילות מתיישבת עם גורם בזיקה איראנית, אך כותבת במפורש שהמודיעין הציבורי מתייחס ל‑ Blinder Tunnel כפעילות עצמאית שאינה משויכת לקבוצה מוכרת ושההתאמות לקבוצות איראניות מבוססות אינן חזקות דיין כדי לשייך את האשכול לאחת מהן. Group‑IB זהירה מכולן ומעריכה בביטחון נמוך בלבד שמדובר באשכול חדירה שקשור קשר הדוק לפעילות APT בזיקה איראנית. היא מנמקת: אין ראיה מכרעת שמקשרת את הקבוצה לגורמים שתועדו קודם.
שני הסימנים שמצביעים על זיקה איראנית מוצגים בדוח של Dream כתמיכה הקשרית בלבד, שאינה מבססת ייחוס בפני עצמה: מתחם של אפליקציית הווידאו המזויפת השתמש בשרתי שמות של ספק איראני והפנייה הראשונה שנרשמה במחסן הגיעה ממכונה עם פריסת מקלדת פרסית.
הסיכון האמיתי לארגון שלכם
כדאי להתחיל ממה שאומת בפועל, לא ממה שנוח להסיק. שתי הפגיעות המאומתות הן סביבת ענן של גוף ממשלתי ואדם בכיר במגזר הביטחוני. מהסביבה הממשלתית נגנבו פרטי גישה והוצא מידע. אצל האדם הבכיר נבחר המחשב לקבל את השלב השני. בשני המסלולים המתועדים נקודת הפתיחה לא היתה שרת שפונה לאינטרנט ולא מערכת שלא עודכנה, אלא אדם ועמדת הקצה שלו.
מכאן והלאה, ארבע נקודות. השלישית והרביעית הן הערכה שלי ולא ממצא של הדוחות:
- עמדת מפתח אינה עמדה רגילה. היא מריצה כלי בנייה בכל יום, מורשית להתקין חבילות, מחזיקה מפתחות וסיסמאות של סביבות עבודה ולעיתים דווקא בה מוסרות מגבלות הרשאה כדי שהעבודה תזרום. המתקפה הזו לא ביקשה מהיעד לעשות דבר חריג. היא ביקשה ממנו לפתוח פרויקט ולתקן באג.
- התעבורה. ערוץ הפיקוד יוצא אל ממשק התכנות של GitHub. בארגון שמפתח תוכנה זו הנורמה. חוקי זיהוי שמחפשים מתחם חדש או כתובת חשודה אינם מתמודדים עם ערוץ שרוכב על שירות שהארגון שלכם משתמש בו ממילא.
- להערכתי, תהליך הגיוס הינו משטח תקיפה שאינו מנוהל. בחברות ישראליות בתחומי הביטחון וההיי‑טק עובר קוד בשני הכיוונים בין גורמים שלא חתמו זה לזה על דבר: מועמד מקבל מטלת בית ומריץ על מחשבו קוד שנשלח אליו ומראיין פותח פרויקט שהגיע ממועמד. אין בדוחות ממצא על ישראל בעניין הזה. יש בהם מתקפה שהמסלול שלה עובר בדיוק שם.
- זה אירוע שלא מכריז על עצמו. אין הצפנה, אין דרישת כופר ואין נזק נראה לעין. גל הפעילות הזה נצפה לאורך כשלושה חודשים והיה פעיל בעת הפרסום. Group‑IB מתארת את ההשתלות של הקבוצה כהשתלות שנבנו לשרוד זמן ארוך ולאסוף מידע באופן מתמשך. אף מקור אינו נוקב בזמן השהייה בפועל אצל קורבן.
010 הגנה על מידע
מודיעין סייבר הוא השירות המרכזי כאן, אך גם זה שהאירוע מראה היכן הוא מועיל והיכן הוא מתיישן. סימני הזיהוי פורסמו בשני הדוחות, אך הדוח של Dream מתעד גם שרשרת של חשבונות GitHub שהתחלפו זה אחר זה לאורך 2025 ו‑ 2026 עד לחשבון הנוכחי. מכאן שרשימת חסימה שנכתבת פעם אחת מתיישנת מעצמה. Dream גם מזהירה במפורש מפני התגובה האינטואיטיבית: מפני ש‑ GitHub ושירותי הענן הם פלטפורמות משותפות, יש להתאים את החסימה לחשבון, למחסן, לשם המתווך ולנתיב המדויקים ולא לחסום את השירות כולו. זו בדיוק עבודה של מודיעין שעוקב אחרי אשכול ומעדכן את הסימנים כשמתפרסם מחקר חדש, לא של חוק חסימה חד‑פעמי.
SIEM/SOC — וכאן אני מפריד בין מה שנפגע לבין מה שנשאר, מפני שבמתקפה הזו חלק מאותות הזיהוי מכובים בכוונה. מה שנפגע: מנגנון מעקב ההרצה של Windows מכובה בקובץ תצורה בשרשרת שתיעדה Unit 42; PowerShell רץ בתוך התהליך הקיים בגל שתיעדה Dream, לפיכך זיהוי שמסתמך על powershell.exe כתהליך בן אינו רואה אותו; ההרצה מתבצעת בתוך קובץ חתום של מיקרוסופט; הפיקוד רוכב על שירות לגיטימי. מה שנשאר: כתיבה של ערך בשם MicrosoftRuntime למפתח ההרצה האוטומטית של המשתמש, שמצביע על קובץ הרצה תחת תיקיית נתוני היישומים המקומיים; הקצב הקבוע שתואר למעלה; בקשת חיפוש חריגה במיוחד אל מחסן הקוד הציבורי של מיקרוסופט, שכמעט שום תהליך לגיטימי אינו מייצר; פנייה אל שם המתווך בשירות הענן שמופיע בסימני הזיהוי; עמדה שאינה עמדת פיתוח שמתחילה לדבר עם ממשק התכנות של GitHub — אות שגם CybersecurityNews וגם Unit 42 ממליצות עליו במילים שלהן, האחת כתעבורת GitHub שאינה מתאימה לעבודת פיתוח רגילה והשנייה כניטור תעבורת ענן חריגה.
שתי הערות חובה על השירות הזה, כדי לא למכור יותר ממה שיש. ההמלצה המפורשת היחידה שנגזרת מהדוחות, לנטר קבצי הרצה שטוענים ספריות לא מוכרות מחוץ לתיקיות המערכת, היא המלצת ניטור בנקודת הקצה, שמרכז ניטור יכול לעבוד איתה רק אם טלמטריית קצה נאספת. איסוף כזה אינו שירות נפרד ברשימה שלנו. במקרה שתיעדה Unit 42, מה שעצר את ההרצה בפועל היתה מערכת הגנת קצה, לא מרכז ניטור. ניטור מרכזי מחבר בין אותות חלשים. זה שווה הרבה במתקפה שמכבה אותות. זו אינה ערובה.
מודעות עובדים לסייבר רלוונטית כאן ישירות, מפני שכל הכניסה היא הנדסה אנושית. אך התוכן שצריך להיכנס להדרכה אינו "אל תלחצו על קישור חשוד". השלב הראשון כאן היה תמים לחלוטין במתכוון ובמתועד. לכן המשפט שראוי ללמד הוא אחר: תהליך שמתנהל כמה שלבים בלי שום סימן רע הינו תהליך שבנוי לבנות אמון, בעוד ששלב שאינו מזיק אינו עדות לכך שהשלב הבא בטוח. לצד זה כלל מעשי אחד: קוד שהגיע מגורם חיצוני אינו נפתח בסביבת הפיתוח שבה יושב קוד הארגון. גם כאן ראוי לומר את הגבול — המשימה שהתוקף ביקש נראתה בדיוק כמו המשימה שהמפתח עושה בכל יום, לפיכך מודעות לבדה אינה פתרון.
סקר סיכונים הוא השירות שממפה את מה שהמתקפה הזו ניצלה. הוא בודק מה עמדות הפיתוח בארגון מורשות לעשות, האם קוד חיצוני נפתח באותה סביבה שבה יושב קוד הארגון, מי מריץ מטלות קוד של גורם חיצוני ועל איזה מחשב, איזו תעבורה יוצאת מעמדות שאינן עמדות פיתוח. במסגרתו מטופלות גם בקרות שאינן מוצר בפני עצמו, כמו הפרדה בין סביבות.
מניעת דלף מידע (DLP) שייכת לכאן בגלל מה שהוצא בפועל, עם גבול שחייב להיאמר באותה נשימה. מה שכן: דפי קציר פרטי הגישה מובילים אל דואר, אנשי קשר, קבצים משותפים ושירותי ענן מקושרים, בפרטי גישה תקפים של משתמש אמיתי ובלי שום התראת נוזקה — וזה בדיוק סוג התנועה שבקרת דלף מידע מסתכלת עליה. מה שלא: ההוצאה שאומתה מסביבת הענן העיראקית בוצעה דרך אותו ערוץ GitHub שתיארתי למעלה כערוץ שמתמזג בתעבורה רגילה. אין בדוחות בסיס לקבוע שבקרת דלף מידע היתה רואה אותה.
שני דברים ראוי לומר: עדכוני תוכנה ואבטחה אינם הסיפור כאן, לכן איני מחבר אותם ישירות אל האירוע: אף אחת מהטכניקות בשרשרת ההרצה אינה מתחילה בפגיעות שממתינה לטלאי, אלא בשימוש בכלי פיתוח לגיטימיים ומעודכנים בדיוק כפי שנועדו לעבוד. סינון דוא"ל — כאן דווקא יש בסיס, אף שבגל של Dream הודעת המסירה לא שוחזרה: Group‑IB ו‑ The Hacker News מתעדות שהקבוצה מסתמכת בעיקר על דיוג ממוקד בדואר. במתקפות על מגזר התקשורת בכורדיסטן תועד אף דיוג פנימי שנשלח מחשבונות עובדים שנפרצו אל עובדים אחרים, משתלב בשרשורי דואר קיימים. סינון של מתחמים מתחזים לדפי הזדהות הוא אפוא בקרה אמיתית מול נתיב המסירה האופייני של הקבוצה. אין בסיס לומר שהיה חוסם את המסלול שתיעדה Unit 42.
לבסוף, הבקרה המתבקשת ביותר מול דפי קציר פרטי הגישה היא אימות רב‑גורמי עמיד לדיוג, שהיא בדיוק ההמלצה שגוגל מסרה ל‑ Unit 42 לצד הקריאה לאמת כתובות לפני הזדהות.
למקור הידיעה ולקריאה נוספת לחצו כאן
