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

כך מתארים חוקרי Confiant קמפיין פרסום זדוני (malvertising, קניית שטחי פרסום לגיטימיים כדי לדחוף אליהם אתרים זדוניים) שהם מכנים SourTrade. בפוסט שפרסם החוקר Michael Steele ב-23 ביולי הם מפרקים את מה שנראה כמו טכניקת חמיקה חדשה: להזיז את הרכבת הנוזקה מהשרת אל תוך הדפדפן, כך שברשת אף פעם לא עובר קובץ זדוני שלם שאפשר לתפוס. בהמשך נראה מה בדיוק הקורבן רואה, איך הדפדפן מרכיב את הקובץ בעצמו, ולמה זה שובר את שיטת הזיהוי הנפוצה ביותר.

מה זה SourTrade, ולמי הוא מכוון

המבצע פועל, לפי Confiant, מאז סוף 2024, והוא מתחזה לשמות מוכרים בעולם המסחר והקריפטו: TradingView, Solana ו-Luno. הקהל הוא סוחרים קמעונאיים ומשקיעי מטבעות קריפטו, והפריסה רחבה במיוחד, 12 מדינות ב-25 שפות, עם דגש על אסיה-פסיפיק ואמריקה הלטינית (יפן, תאילנד, קוריאה הדרומית, טייוואן, ברזיל, ניגריה, טורקיה ואוסטרליה, בין היתר). התוקפים משתמשים במערכות הפרסום של גוגל, מטא וגם X כדי לכוון תנועה ולמדוד המרות, בדיוק כמו מפרסם אמיתי.

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

הנוזקה שיושבת בקצה השרשרת אינה חדשה. The Hacker News מציין שמדובר במשפחה ש-Check Point עוקבת אחריה בשם JSCEAL, ו-WithSecure מכנה WeevilProxy. מה שחדש כאן הוא לא המטען, אלא צורת ההגעה שלו.

איך הדפדפן בונה את הנוזקה בעצמו

כשקורבן נוחת על דף הפרסום, קורים שם כמה דברים שהוא לא רואה. קודם כול הדף רושם רכיב בשם ServiceWorker (סקריפט שיושב בין הדף לרשת ויכול ליירט בקשות ולהחזיר תשובות, כולל להשתלט על מה שנראה כמו הורדה רגילה). מיד אחריו נוצר SharedWorker, וזה הרכיב שמתפקד כמנוע ההרכבה של הנוזקה. כדי שהערוץ הזה לא ייסגר באמצע התהליך הארוך, הדף שולח הודעת keep-alive כל 25 שניות. ה-SharedWorker פונה לכתובת פנימית בשם config/ ומקבל בתגובה לא קובץ הרצה, אלא מתכון.

המתכון הזה בנוי משלושה חלקים. הראשון הוא כתובת להורדת Bun נקי, סביבת הרצה לגיטימית ל-JavaScript שאפשר להוריד בתור קובץ הרצה עצמאי. השני הוא זרע (seed) אקראי וגודל, ייחודיים לכל הפעלה. השלישי הוא שורת הוראות, מערך template שמתפקד כמתכון להעתקת בייטים: מאיפה למשוך כל טווח בייטים ובאיזה סדר להדביק אותם. חלק ממקטעי ה-PE, בהם הכותרת וטבלת המקטעים של הקובץ, מגיעים כבר בתוך תשובת config/ מקודדים ב-base64.

מכאן הדפדפן עושה את העבודה. הוא מוריד את Bun ומפרק את הדחיסה, מייצר מקומית זרם בייטים פסאודו-אקראי בעזרת הצפנת AES-CTR על בסיס הזרע והגודל שקיבל, ולוקח את מקטעי ה-PE הזדוניים שהגיעו מקודדים ב-config/. שלושת המקורות האלה, רכיב Bun הנקי, זרם ה-AES והמקטעים הזדוניים, נתפרים יחד בייט אחר בייט לפי ה-template, עד שיוצא קובץ הרצה שלם. הקוד הזדוני עצמו יושב במקטע PE בשם bun. בתור bytecode של JavaScriptCore, ו-Bun הלגיטימי הוא זה שמריץ אותו כשהקובץ רץ. במילים אחרות, התוקף לא שולח נוזקה, הוא שולח הוראות איך להרכיב אותה, ו-Bun הכשר הוא זה שמריץ אותה בפועל.

למה קובץ לכל קורבן שובר את הזיהוי

כאן נכנס לתמונה הרעיון המרכזי של SourTrade. הזרע והגודל משתנים בכל הפעלה, ולכן זרם ה-AES-CTR שונה בכל פעם, ולכן חתימת ה-hash של הקובץ הסופי ייחודית לכל קורבן. רוב מנועי האנטי-וירוס מזהים נוזקות ידועות לפי hash של קובץ, ומול קובץ שאף פעם לא נראה קודם, הרשימה השחורה פשוט חסרת תועלת.

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

והחלק המחוכם ביותר הוא איך הקובץ מגיע לדיסק. הקובץ המורכב נמסר בחזרה ל-ServiceWorker, ו-iframe נסתר מנווט לכתובת באותו origin שמפעיל את מנגנון ההורדה של הדפדפן. התוצאה: סימון ה-Mark of the Web, אותו תג שחלונות מצמידה לקבצים שהורדו מהאינטרנט, מתעד את הקובץ כאילו הגיע מאותו מקור שהמשתמש גלש אליו, למרות שרכיביו הגיעו מדומיינים אחרים. זה לא פרט טכני זניח: מנגנונים כמו SmartScreen שוקלים מאיפה הגיע קובץ כשהם מחליטים אם להזהיר את המשתמש, וכשהמקור נראה כמו האתר שאליו נכנס מרצונו, ההתראה נחלשת. "אף נוזקה מוגמרת לא קיימת ברשת בשום שלב", מסכם Steele את העיקרון. אין קובץ יחיד שאפשר לחסום, לתייג או להעלות לניתוח.

מה הנוזקה עושה אחרי ההרצה

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

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

מבט קדימה

SourTrade הוא דוגמה טובה למגמה שחוקרים רואים יותר ויותר: העברת שלב ההרכבה של הנוזקה אל צד הלקוח, תוך שימוש ברכיבים לגיטימיים לחלוטין. סביבת הרצה כשרה כמו Bun, ממשקי דפדפן תקניים כמו ServiceWorker, ומערכות פרסום אמיתיות, כולם מצטרפים לשרשרת שבה כל חלק בנפרד נראה תמים. Confiant מציינים שגרסאות מוקדמות של המבצע השתמשו בספריית StreamSaver, ומאז אפריל 2026 הוא עבר לשיטת ה-ServiceWorker באותו origin, סימן שהמפעילים משפרים את הטכניקה תוך כדי תנועה.

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