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

חוקרי Zscaler ThreatLabz חשפו ב-20 ביולי קמפיין תקיפה ממוקד נגד גופים ממשלתיים במזרח התיכון, שמפעיל שלוש משפחות נוזקה שלא תועדו קודם: TELESHIM, MIXEDKEY ו-BINDCLOAK. הפרט שהופך את הקמפיין למעניין הוא לא הנוזקה עצמה אלא איך היא מדברת עם מי שמפעיל אותה. הדלת האחורית לא פותחת חיבור לשרת חשוד אי-שם. היא שולחת ומקבלת פקודות דרך Telegram, בערוץ שנראה בדיוק כמו כל אפליקציה אחרת שמדברת עם api.telegram.org.

בהמשך נראה איך הקובץ מגיע למחשב, למה השימוש ב-Telegram מקשה כל כך על הזיהוי, וכמה עבודה הושקעה בהסתרת הקוד עצמו.

מי מותקף, ומי תוקף

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

לגבי מי שמאחורי המתקפה, החוקרים זהירים. הם מעריכים בביטחון בינוני עד גבוה שהתוקף פועל ממזרח אסיה, ומבססים את זה על שלושה סימנים: מיקום כתובת ה-IP הציבורית של התוקף, הגדרות השפה והאזור בשרת ששימש אותו, ושעות הפעילות שלו, שהתרכזו בין 7 ל-11 בבוקר לפי שעון UTC ומתאימות ליום עבודה באזור זמן מזרח-אסייתי. עם זאת הם לא מקשרים את הפעילות לאף קבוצה מוכרת. "בשלב זה איננו מייחסים את הפעילות לאף קבוצת APT ידועה", כתב סודיפ סינג, בכיר במחקר ה-APT של Zscaler. ההודאה הזאת חשובה: קל להדביק תווית של קבוצה מפורסמת על כל מתקפה, וקשה יותר להגיד שעדיין לא יודעים.

קובץ חתום עושה את העבודה המלוכלכת

נקודת הכניסה היא טריק ישן שעדיין עובד. במקום להגניב קובץ הרצה זדוני שאנטי-וירוס יחשוד בו מיד, התוקפים לוקחים קובץ הרצה לגיטימי וחתום של ASUS בשם RegSchdTask.exe, ומניחים לצידו ספרייה זדונית בשם AsTaskSched.dll. כשקובץ ההרצה החתום עולה, מערכת ההפעלה מחפשת את הספריות שהוא צריך ומוצאת קודם את הזדונית שהושתלה באותה תיקייה. לטכניקה הזאת קוראים DLL sideloading, וכוחה בכך שהקוד הזדוני רץ בתוך תהליך של קובץ חתום ואמין, מתחת לרדאר של הגנות שסומכות על החתימה.

הספרייה הזאת היא הנוזקה הראשונה בשרשרת, TELESHIM: קובץ DLL של 32 ביט שנכתב ב-C++ והודר ביולי 2026 (וריאנטים מוקדמים יותר שלו תוארכו כבר ל-2025). כדי לשרוד אתחול היא רושמת לעצמה משימה מתוזמנת בשם shimgen שרצה כל שש דקות, ומכינה את המטענים הבאים בתיקייה C:\programdata\shimgen_Data. משם היא ממתינה להוראות.

הדלת האחורית שמדברת דרך Telegram

השאלה שכל דלת אחורית צריכה לפתור היא איך התוקף שולח לה פקודות בלי שתעבורת הרשת תסגיר אותה. שרת שליטה ובקרה (C2, השרת שדרכו התוקף מעביר פקודות לנוזקה ומקבל ממנה מידע) עם כתובת קבועה וחשודה הוא בדיוק מה שמערכות הגנה מחפשות. TELESHIM פותרת את זה בכך שהיא לא מחזיקה שרת כזה בכלל. במקום זה, היא נשענת על ה-Bot API של Telegram.

בפועל זה עובד ככה: בתוך הקוד מוצפנים token של בוט Telegram ומזהה צ'אט. הנוזקה פונה שוב ושוב לכתובת של Telegram, api.telegram.org, ושואלת אם יש פקודות חדשות (מנגנון polling רגיל שכל בוט משתמש בו). Telegram מצידו לא יודע שמדובר בנוזקה, ומחזיר את ההודעות שהתוקף שלח לאותו בוט. כל התעבורה הזאת היא HTTPS מוצפן אל שרת פופולרי לגמרי. עבור מערכת ניטור ברשת ארגונית, מחשב שמדבר עם api.telegram.org נראה בדיוק כמו עובד שפתח את Telegram בדפדפן. דווקא בפרט קטן הנוזקה מסגירה את עצמה: היא מתחזה בבקשות שלה לדפדפן ישן על מחשב Mac, מזהה שכמעט לא תואם למחשב Windows ממשלתי, ומי שיודע לחפש את חוסר ההתאמה הזה יכול לתפוס אותה.

הפקודות עצמן מגיעות בשני סוגים. הראשון מריץ פקודות מערכת: הנוזקה מזהה כל מחשב נגוע לפי כתובת ה-MAC של כרטיס הרשת, ומריצה את הפקודות דרך cmd.exe. בשלב הזה נצפו פקודות סיור שגרתיות, net user, tasklist, ipconfig /all ו-netstat, שנועדו למפות מי המשתמש, מה רץ ולאן המחשב מחובר. הסוג השני מוריד ומריץ קבצים נוספים דרך אותו ערוץ Telegram, כך שהתוקף יכול לשלוח שלבים נוספים של הנוזקה מבלי לחשוף אף שרת נוסף.

למה קשה כל כך לנתח את זה

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

הנוזקה גם בודקת אם היא רצה בתוך סביבת מחקר. היא מבצעת מבחן עומס שכותב כג'יגה-בייט לדיסק, בודקת דרך CPUID אם היא רצה מעל hypervisor (סימן למכונה וירטואלית), ושואלת דרך WMI מה מהירות ה-RAM. אם התשובה 0, כפי שקורה לעיתים במכונות וירטואליות, היא פשוט מפסיקה לרוץ. חוקר שמריץ אותה בארגז חול נקי עלול לא לראות שום דבר.

MIXEDKEY עצמה היא מטעין רפלקטיבי (reflective loader, קוד שטוען נוזקה נוספת ישירות בזיכרון בלי לכתוב אותה לדיסק). היא מפענחת את השלב הבא באמצעות מפתח שנגזר מהמספר הסידורי של אמצעי האחסון במחשב הקורבן. המשמעות המעשית: אם מריצים את הנוזקה על מחשב אחר מזה שהותקף, הפענוח נכשל והמטען לא נחשף כלל. השלב האחרון, BINDCLOAK, הוא ה-C2 implant המלא שיוצר קשר עם השרת cert.hypersnet[.]com, ו-Zscaler שומרת את הניתוח המלא שלו לחלק השני של הדוח.

מה שרואים מעבר לקמפיין הזה

הבחירה ב-Telegram אינה מקרית, והיא לא ייחודית לקמפיין הזה. יותר ויותר תוקפים מעבירים את התקשורת שלהם דרך שירותים לגיטימיים ופופולריים, בין אם Telegram, Discord, שירותי ענן או יומני Google, כי חסימה גורפת שלהם בארגון אינה מעשית והתעבורה אליהם נבלעת ברעש היומיומי. זה מעביר את נטל הזיהוי מ"האם היעד חשוד" ל"האם ההתנהגות חשודה", וזו שאלה הרבה יותר קשה למערכת אוטומטית. הקמפיין הזה מחבר את הרעיון הזה עם קובץ חתום, ISO כעטיפה, ושכבות עירפול כבדות, וכל אחד מהמרכיבים לבדו מוכר. הצירוף שלהם הוא מה שהופך את הזיהוי לקשה.

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

לארגונים, ובמיוחד לגופים ממשלתיים באזור, יש כאן כמה סימנים ששווה לחפש. קובץ ISO או IMG שמגיע כצרופה במייל הוא דגל אדום, במיוחד כשהוא נושא שם של מסמך תמים. מחשב שאין לו שום סיבה לדבר עם api.telegram.org ופתאום עושה את זה בקביעות ראוי לבדיקה. וקובץ הרצה חתום ולגיטימי שרץ מתיקייה חריגה, עם ספריית DLL לא מוכרת לצידו, הוא בדיוק הדפוס שהקמפיין הזה נשען עליו. הכלים ישתנו בקמפיין הבא, אבל שלוש הנקודות האלה חוזרות על עצמן.