הודעה בטימס מגורם שהציג את עצמו כתמיכה הטכנית של הארגון, שיחה קצרה, ופקודת PowerShell אחת שהמשתמש הריץ בעצמו. מה שירד למחשב נראה תמים למדי: סביבת פייתון 3.12.9 מקורית וחתומה כמו שצריך, ולצידה קובץ מהודר אחד במשקל 39 מגה-בייט. בשבועות שאחרי, שום דבר חריג לא צף ביומני ההתחברות של Microsoft 365 בארגון. לא בגלל שמישהו מחק אותם. פשוט לא היה שם מה לרשום.

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

למה היומנים של הארגון נשארו נקיים

הנוזקה אכן מתחברת ל-Microsoft 365 ואכן מושכת פקודות מ-SharePoint. רק שזה לא ה-SharePoint של הארגון הנפגע. עם פרטי אימות מוטמעים בקוד היא מזדהה מול חשבון Azure שהתוקף פתח ומשלם עליו בעצמו, ומושכת משם. וזה בדיוק ההבדל שמפיל את רוב הזיהוי: אין אירוע התחברות, אין רשומת ביקורת, ואין שום דבר לחפש ב-Entra ID של הקורבן, כי הסביבה של הקורבן איננה צד בעסקה.

התהליך pythonw.exe פונה החוצה ל-login.microsoftonline.com, ל-graph.microsoft.com ולאתר SharePoint בשם kerteransens, ובודק כל 15 שניות אם הונח שם קובץ פקודה חדש. תוצאות של פקודות, נתוני סיור ופרטי אימות שנגנבו עולים חזרה לאותו מקום. לטכניקה הזאת קוראים dead drop, תיבת דואר מתה: אף צד לא מדבר ישירות עם השני, שניהם רק כותבים וקוראים מאותה תיקייה משותפת. מבחינת מוצר האבטחה שמסתכל על התעבורה, זו גלישה ל-SharePoint.

אז איך הבקשות ל-Graph לא נראות חשודות?

כאן מגיע החלק שחוקרי Ontinue מציינים כמעניין ביותר מבחינת התחמקות מזיהוי. כלל סביר בכל ארגון אומר שאם python.exe מדבר ישירות מול graph.microsoft.com, משהו שם שגוי. הכותבים של TWINLOOT פתרו את זה בפשטות: הם לא נתנו ל-python לדבר בכלל. הנוזקה מפעילה את Microsoft Edge של המשתמש עצמו במצב headless, כלומר הרצה של הדפדפן המלא בלי חלון גלוי, בדיוק כמו שעושים בבדיקות אוטומטיות. אחר כך היא מדליקה את ממשק ה-debugging המרוחק שלו, מתחברת אליו מקומית דרך פרוטוקול Chrome DevTools, מנווטת ללשונית של graph.microsoft.com, ומריצה משם את כל קריאות ה-API כבקשות fetch() רגילות מתוך העמוד.

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

שני ערוצים, שתי מטרות

עד כאן הערוץ האיטי, זה שמעביר משימות ותוצאות. הצד השני מעניין יותר, כי הוא זה שנותן לתוקף לעבוד בזמן אמת בתוך הרשת.

במקביל ל-SharePoint מרימה הנוזקה מנהרת SOCKS5 הפוכה. התוקף מקבל על המחשב שלו מאזין מקומי בפורט 1080, וכל מה שהוא שולח אליו יוצא בפועל מהמחשב הנגוע פנימה לרשת הארגונית: פורט 445 ל-SMB, 3389 ל-RDP, 5985 ל-WinRM ו-1433 ל-MSSQL. מנקודת המבט של הרשת הפנימית, תחנת עבודה לגיטימית פונה לשרתים שהיא ממילא אמורה לפנות אליהם.

המנהרה הזאת יכולה לרוץ בשני מסלולים. הראשון הוא חיבור TLS ישיר לשרת של התוקף. השני הוא זה שהופך את המקרה לתקדים. שירותי שיחות וידאו מחזיקים שרתי ממסר שמעבירים את המדיה בין שני צדדים שלא מצליחים להתחבר ישירות, ולמיקרוסופט יש שרתים כאלה עבור טימס. TWINLOOT מקימה דרכם ערוץ נתונים של WebRTC, ומשיגה את פרטי הגישה לשרת הממסר בזמן אמת דרך הממשק שמאפשר להצטרף לפגישות טימס כאורח אנונימי. משא ומתן החיבור מוגדר כך שיעבור רק דרך הממסר, ולכן כתובת ה-IP של הקורבן לא מופיעה בשום שלב, וגם פרטי ההתקשרות עצמם נכתבים לתיקיית ה-SharePoint.

זו הפעם השנייה שנצפה שימוש זדוני בשרתי הממסר של טימס, אחרי הדלת האחורית Backdoor.Turn של DragonForce שתועדה על ידי סימנטק ביוני 2026, והראשונה שמשתמשת בערוצי נתונים אמיתיים של WebRTC. שם, מציינים ב-Ontinue, המימוש היה שונה לגמרי ועבר ב-QUIC; כאן מדובר בהסבה לפייתון של מחקר TURNt של Praetorian, שהוצג ב-Black Hat USA 2025.

מסך נעילה שלא בודק שום סיסמה

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

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

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

מה שנשאר לתוקף אחרי שיש לו סיסמה הוא לוודא שהוא לא מאבד את הדריסה. בבנייה שנתפסה מנגנוני השרידות היו כבויים, אבל ארבעה מהם קיימים בקוד ומופעלים בפקודה. אחד מהם ראוי לתשומת לב: Windows טוען את הגדרות הרישום של המשתמש מקובץ שיושב בתיקיית הפרופיל, ואם קיים שם קובץ בשם NTUSER.MAN הוא מועדף על פני הרגיל. TWINLOOT בונה קובץ כזה לגמרי מחוץ לרישום החי, בעזרת ממשקים ותיקים של מערכת ההפעלה, וכותבת אותו לפרופיל במשקל 2,138,112 בתים. אין אירוע שינוי רישום שמישהו יכול לתפוס, אין צורך בהסלמת הרשאות, וההגדרה שורדת יציאה וכניסה מחדש. הטכניקה מבוססת על מחקר של Praetorian מינואר 2026, וזו לפי Ontinue הפעם הראשונה שהיא נראית בשטח.

מי מפעיל את זה

אין תשובה, וזו בפני עצמה אמירה. החוקרים כותבים במפורש שלא מצאו שום חפיפה בתשתית, בכלים או בקוד לאף שחקן או משפחת נוזקות מוכרת. מה שכן אפשר לקרוא מהתשתית זו סבלנות: שני הדומיינים בקמפיין הם דומיינים שפג תוקפם ונרכשו מחדש בהפרש שבועיים, טריק שנועד לרשת את הוותק והמוניטין שלהם מול כלים שמחשידים דומיינים חדשים. הראשון נרשם ב-7 ביוני וקיבל תעודת TLS כשמונה שעות אחר כך, השני נחטף ביום שנכנס למחיקה, ותעודה משותפת אחת שהונפקה ב-21 ביולי מוכיחה שמפעיל אחד החזיק בשניהם. המטען הודר ב-24 ביולי, וב-27 עד 30 בו נצפתה תקשורת רציפה. שרת הגיבוי יושב ברשת שתועדה על ידי GreyNoise כאחת מארבע שעמדו מאחורי יותר מתשעה מיליון ניסיונות תקיפת פרטי אימות מול שערי Palo Alto GlobalProtect בסוף 2025, ולכן ההערכה היא שהתוקף שוכר תשתית פלילית ולא מפעיל אותה.

התזמון של הדבר הזה הוא אולי החלק המדאיג. יום אחד לפני שהמטען של TWINLOOT הודר פרסמו חוקרי Cisco Talos ניתוח של msaRAT מקבוצת Chaos, שמשתמשת באותה משפחת טכניקות בדיוק, כולל הדפדפן שמשמש כערוץ תקשורת, רק דרך ספק ממסר אחר. "ההתכנסות בולטת", כתבו החוקרים ב-Ontinue, "שני שחקנים ללא קשר ביניהם הגיעו באופן עצמאי לרעיון של להסיע את התקשורת דרך הדפדפן של הקורבן עצמו, באותו חודש". והמסגרת עוד לא סגורה: הקוד כולל מודול לשליפת הגדרות מבלוקצ'יין שעדיין לא מאוכלס, סימן שיש כאן פיתוח פעיל וגרסאות שטרם נראו.

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

הזיהוי כאן לא יגיע מהענן אלא מה-endpoint ומהרשת, כי בענן של הארגון פשוט אין מה לראות. שווה להגדיר התרעה על תחנות מנוהלות שפונות לאתרי SharePoint שאינם של הארגון, ולהתייחס לפייתון שרץ מנתיבים שמשתמש רגיל יכול לכתוב אליהם, כמו ProgramData או AppData, כאל ממצא שדורש בדיקה. הצעד הזול ביותר הוא שתי מדיניות של Edge: חסימת מצב headless וחסימת ה-debugging המרוחק בתחנות סטנדרטיות, למעט תחנות פיתוח שבאמת צריכות את זה. די באחת מהשתיים כדי לשבור את הערוץ. ומי שנתקל במסך נעילה שביקש סיסמה ואז נעלם, כדאי שיחליף סיסמה ושיבטלו לו את ה-token-ים הפעילים, כי ההנחה צריכה להיות שהיא כבר אצל מישהו אחר.