הקוד של התוקף רץ לפני שהמפתח לחץ על Build: קמפיין איראני תקף תשתיות בעיראק דרך מבחן תכנות מזויף של נמל התעופה בדובאי
ההודעה שהגיעה למפתח העיראקי נראתה כמו תהליך גיוס רגיל. מחלקת ה-IT של נמל התעופה בדובאי מחפשת מפתח, יש שאלון מקדים, ואחריו מבחן תכנות בבית. השאלון עצמו היה תמים לחלוטין: עשר שאלות HR בממשק שהותקן על המחשב, בלי שום פנייה לשרת ובלי שום קוד זדוני, בדיוק כדי שהתהליך ירגיש אמיתי. המבחן, שהגיע חודש אחרי זה, היה פרויקט C# שהריץ את הקוד של התוקף ברגע שנפתח בסביבת הפיתוח.
חוקרי Unit 42 פרסמו ב-6 באוקטובר את הניתוח של הקמפיין, שהם קוראים לו Blinder Tunnel ומשייכים לאשכול פעילות שמסומן CL-STA-1178. לפי הדוח מדובר בגורם איראני המקושר למדינה, שתוקף חברות תקשורת, תעופה ותשתיות קריטיות בעיראק, בישראל ובאיחוד האמירויות. הקמפיין הופעל נגד מטרה בתשתיות העיראקיות במרץ 2026, אבל התשתית שלו הוקמה ונבדקה כבר בנובמבר 2025, ו-GitHub הסירה אותה מאז. בהמשך נראה למה פתיחת פרויקט בסביבת פיתוח היא כבר הרצת קוד, איך ערוץ השליטה מתחבא בתוך תעבורה שנראית לגיטימית לחלוטין, ואיפה ישראל נכנסת לתמונה.
המבחן שלא בדק כלום
בסוף מרץ 2026 התוקפים פנו למטרה בודדת, כנראה מהנדס תוכנה, עם הצעת עבודה. השלב הראשון היה קובץ בשם Dubai Airport Careers, מתקין Inno Setup שהתקין אתר קריירה עצמאי שעובד לגמרי מקומית. כדי להיכנס אליו המטרה נדרשה להזדהות עם פרטי אימות שה"מגייסים" שלחו לה, ואז קיבלה שאלון של עשר שאלות. Unit 42 בדקו ומצאו שהאפליקציה הזאת לא עושה כלום: היא לא מוציאה מידע, לא מדברת עם שרת ולא מריצה קוד. וזאת הייתה הפואנטה. פיתיון תמים שמבסס אמינות לפני שמגיע החלק האמיתי.
החלק האמיתי הגיע באפריל 2026, מאותו מגיש ל-VirusTotal שדיווח על אתר הקריירה, מישהו שיושב בעיראק. הפעם זה היה ארכיון של פרויקט Visual Studio בשם DubaiAirport_Carrers_IT_Test.zip, עם שגיאת כתיב ב-Carrers. בתוכו חיכה קובץ Readme.md שפנה למטרה בשמה המלא, בשם "מנהל בכיר" במחלקת ה-IT של נמל התעופה, והנחה לפתוח פרויקט C# של מערכת ניהול טיסות בסביבת הפיתוח. כדי שיהיה למה לפתוח אותו, התוקפים השתילו בקוד באג מכוון: לופ שמדלג על האיבר האחרון. מהנדס מנוסה מתקן את זה בכמה דקות. Unit 42 מדגישים שזה שונה מהקישורים והמסמכים הזדוניים של קמפייני Dream Job האיראניים שתיעדה ClearSky, ומבהירים שאין להם אינדיקציה לפריצה או לחולשה בנמל התעופה בדובאי עצמו. השם שלו רק שימש כתחפושת.
למה הקוד רץ לפני ה-Build?
כשמפתח פותח פרויקט C#, סביבת הפיתוח לא מחכה שילחץ על Build. היא מריצה ברקע בנייה קצרה משל עצמה כדי לפענח תלויות ולהפעיל חלק מהיכולות של העורך, וזה קורה בשנייה שהפרויקט נטען. בתוך הבנייה הזאת רצה פקודה בשם GetFrameworkPaths. התוקפים הגדירו בקובץ ה-csproj שלהם יעד XML מותאם עם בדיוק אותו שם, וכך דרסו את ההתנהגות הרגילה של מיקרוסופט. פתיחת הפרויקט בעורך הפעילה את ההוראות שלהם, בלי אישור ובלי קליק.
מה שההוראות עשו היה פשוט: יצרו תיקייה בשם RuntimeBrokers תחת ספריית היישומים המקומית של המשתמש, העתיקו לשם קבצים מוסתרים מתיקיית ה-Resources של הפרויקט, והפעילו קובץ בשם RuntimeBroker.exe. לטכניקה הזאת MITRE קוראת Trusted Developer Utilities Proxy Execution, והיא עובדת דווקא בגלל שהכל תקין: ההרצה רוכבת על msbuild.exe, כלי חתום ומוכר שאמור לרוץ בדיוק ברגע הזה. הקוד רץ בזמן שהמפתח עוד קרא את ה-Readme.
MSBuild הפעיל תהליך אירוח לגיטימי וחתום של Visual Studio, vshost.exe, שקיבל את השם RuntimeBroker.exe. כאן נכנס לתמונה השלב השני. סביבת ההרצה של .NET קוראת קובץ הגדרות שמונח ליד קובץ ההפעלה, והתוקפים השתמשו בקובץ RuntimeBroker.exe.config כדי להחליף את מנהל האתחול הרגיל של היישום באחד משלהם. התוצאה היא שהשליטה עוברת לקוד שלהם לפני שהיישום המקורי בכלל עולה. לטכניקה קוראים AppDomainManager hijacking, ולפי Unit 42 היא נעשית נפוצה יותר בקרב קבוצות איראניות.
באותו קובץ הגדרות נוספה גם שורה אחת שעשתה משהו אחר. ל-Windows יש זרם אירועים פנימי שמערכות הגנה נשענות עליו כדי לראות מה נטען ומה רץ בזיכרון, ושורת ההגדרה הזאת כיבתה אותו עבור התהליך. בשפה המקצועית זה ETW, והכיבוי שלו פוגע ביכולת לזהות איומים שחיים בזיכרון בלבד. השלב השלישי היה הטעינה עצמה: RuntimeBroker.exe, קובץ מיקרוסופט תמים שרק שמו שונה, חשוף לחטיפת סדר חיפוש של ספריות, וכך נטען לזיכרון RuntimeBroker.dll. זאת הנוזקה שחוקרי Unit 42 קוראים לה ShelbyLoader V2.
עד כאן איך הקוד נכנס. הצד המעניין יותר הוא איך הוא מדבר הלאה.
ערוץ שליטה שנראה כמו תעבורת GitHub רגילה
ShelbyLoader V2 הוא גרסה חדשה של נוזקה ש-Elastic Security Labs תיעדה בדוח The Shelby Strategy ממרץ 2025, והוא עובד על שני טיימרים. הראשון, כל 63 שניות, מריץ את לב התקשורת: הנוזקה מזדהה מול ה-API של GitHub עם token קבוע שמוטמע בקוד, מעלה טביעת אצבע של המכונה לקובץ Lic.txt במחסן peakyblinders-tm/myLic, ואז מושכת שוב ושוב קובץ Inf.txt באותה תיקייה ומחפשת בו פקודה מקודדת Base64. מזהה המכונה שקובע באיזו תיקייה מדובר נגזר מ-16 התווים ההקסדצימליים הראשונים של גיבוב SHA-256 על המחרוזת Peaky Blinders 2.1 יחד עם טביעת האצבע. אם GitHub מחזירה שגיאת 403 בגלל הגבלת קצב, הנוזקה נרדמת לשעה.
הטיימר השני, כל 120 שניות, מטפל בשימור האחיזה במכונה: ערך בשם MicrosoftRuntime נכתב למפתח ההרצה האוטומטית של המשתמש ומצביע על הקובץ שבתיקיית RuntimeBrokers. הנוזקה מדווחת לשרת באיזה מארבעה מצבים היא נמצאת, מ"כבר שרדה" ועד "קובץ ההפעלה לא נמצא". לפני כל זה היא בודקת שהיא לא רצה בסביבה מבוקרת: סימני וירטואליזציה ב-WMI, בתהליכים, ברג'יסטרי ובקבצים, בדיקת מעבד וזיכרון, ואימות שהיא הופעלה דווקא מתוך explorer.exe.
והחלק שהופך את ההסרה של GitHub לפחות מועילה: אם ה-token נשלל והשרת מחזיר שגיאת 401, הנוזקה עוברת לערוץ חלופי. היא בונה שאילתה ל-API החיפוש של GitHub Issues לפי התאריך הנוכחי בפורמט yyyymmdd ומזהה המחסן, עוברת על התגובות של כל תקלה תואמת, ומחלצת טקסט שהוחבא בין סימני ההערה של HTML. הטקסט מוצפן ב-AES-256-CBC, והמפתח נגזר מגיבוב MD5 של מחרוזת התאריך יחד עם מזהה המכונה. אחרי הפענוח הנוזקה מפרסרת את התוצאה ומעדכנת לעצמה את שם הבעלים, נתיב המחסן וה-token, כלומר מחליפה שרת שליטה בלי שאף אחד נגע בה. Unit 42 מעריכים שתגובה שהתוקפים השאירו ב-16 באפריל 2026 שימשה בדיוק לזה, ומציינים שאת הטקסט שהושתל אי אפשר לפענח בלי מזהה המכונה של קורבן ספציפי.
מה הם עשו עם הגישה
מערכות הגנה מחפשות בעיקר את powershell.exe כשהוא עולה. המודול שהתוקפים השתמשו בו, PsProxy.dll, לא מפעיל אותו בכלל: הוא טוען את מנוע ה-PowerShell עצמו לתוך התהליך החטוף ופותח בו מרחב הרצה עצמאי, כך שהסקריפט רץ בלי תהליך חדש ובלי קובץ שנכתב לדיסק. מעל זה יושב ה-RAT המרכזי, RuntimeBrokerApi.dll, שהחוקרים קוראים לו ShelbyC2 V2. הוא הגיע מוצפן בספרייה של הנוזקה, והמפתח לפענוח נגזר מקובץ הרישוי שנשלף בזמן אמת מה-C2. בלי הערוץ, הקובץ שעל הדיסק לא שווה כלום.
הכלי שסוגר את הסיפור נקרא Blackwood. ב-1 במאי 2026 התוקפים פתחו מחסן ציבורי נוסף תחת אותו חשבון, ובו ארכיון שהכיל את Blackwood.dll לצד קובץ מיקרוסופט חתום וקובץ ההגדרות שלו, כלומר אותו מהלך סידלואד מהשלב הראשון. Blackwood הוא עטיפה לכלי המנהור הפתוח Chisel, שמקים מנהרות TCP מוצפנות מעל HTTP עם תמיכת SOCKS5. כל קבצי ה-.NET בקמפיין עורפלו ב-Obfuscar. הקובץ של Chisel עצמו, 8.4 מגהבייט שנבנו ב-Go, הוחבא בתוך הטוען כמשאב עם שם XML תמים ונטען לזיכרון בלי לגעת בדיסק. ההגדרות הורו למכונה להתחבר לשרת 91.107.156.29 ולהקים נגדו proxy SOCKS הפוך על פורט 10999, גשר שמנתב תעבורה של התוקף אל תוך הרשת הפנימית.
מאיפה מגיע הקישור לאיראן, ואיפה ישראל נכנסת
Unit 42 מעריכים בביטחון גבוה שמדובר בגורם איראני המקושר למדינה, ומפרטים על מה ההערכה נשענת. כתובת ה-C2 הראשונה של Blackwood יושבת אצל ספק אינטרנט איראני בשם TOSE'EH ERTEBATAT NOVIN ARIA, ושרת מנהור משני שמתארח ב-Hetzner מפנה לדומיינים בפרסית שנרכשו כנראה דרך משווק איראני. ובקובץ mp3 שהתוקפים השאירו במחסן הציבורי, שיר הנושא של Peaky Blinders שהטמיעו ב-README, נשארו נתוני מטא שמפנים ל-MusicDel.ir, אתר מוזיקה איראני. את החיבור לקבוצות האיראניות המוכרות הדוח מסמן במפורש כחיבור בביטחון נמוך: פיתיונות בתחום התעופה והכיבוי של ETW דרך קובץ הגדרות דומים ל-Screening Serpens, שמוכרת גם כ-UNC1549, והשימוש ב-GitHub בתור תיבת דואר מתה ובעטיפות PowerShell בזיכרון דומה ל-Agent Serpens, שמוכרת גם כ-APT35.
הקשר הישראלי התגלה דווקא מרשלנות. ניתוח של קבצי ההגדרות של Blackwood שהועלו ל-VirusTotal חשף תשתית נוספת שפעלה במאי ויוני 2026, ואחד השרתים שימש גם לגישה לרשתות פנימיות וגם לאיסוף פרטי אימות. דרכו החוקרים הגיעו לקמפיין פישינג שכוון לגוף ישראלי באותם חודשים, עם פיתיונות בנושא הלחימה ועם דומיינים שמתחזים לשירותי גוגל, בהם cloud.g-drive.cam ו-googelmeet.online. Unit 42 מציינים שדווקא השילוב של תשתית הפישינג ותשתית המנהור על אותו שרת הוא מה שחשף את הקשר. את זהות הגוף הישראלי הדוח לא חושף, וגם לא אומר אם הקמפיין הזה הצליח.
מה זה אומר בפועל
הגבול בקמפיין הזה עובר בתחנת העבודה של המפתח, לא בשער הרשת. אם אתם מפתחים, פתיחת ארכיון פרויקט או מחסן קוד שקיבלתם ממגייס היא אירוע הרצה לכל דבר, ולא קריאה של קוד, אז מקומה היחיד הוא מכונה וירטואלית שאפשר לזרוק. ולמי שמגן על ארגון יש כאן שלושה דברים ששווה לחפש: תעבורה ל-API של GitHub מתחנות שאין להן סיבה לדבר איתו, קבצי config שצצים ליד קבצי הפעלה חתומים מחוץ לספריות המותקנות, וערכים חדשים במפתח ההרצה האוטומטית שמצביעים לתוך ספריית היישומים המקומית.
(אגב, Elastic כתבו בדוח המקורי שכל מי שמשיג את ה-token המוטמע יכול להשתלט על המכונות הנגועות. ב-V2 הוא עדיין מוטמע בקוד.)
תגובות