חדשות סייבר יומיות - 23 באוגוסט 2026

מה קרה

מתקפת שרשרת אספקה מנצלת אפליקציית עדכון לגיטימית של DoFun בשם TWCore ביחידות מולטימדיה מבוססות Android ברכב, כדי להפיץ נוזקה שהופכת את המכשירים לצומתי בוטנט פרוקסי או לכלי הונאת מודעות.

Kaspersky קישרה את הפעילות לקבוצת MoYu, שקושרה בעבר לבוטנט BadBox. האפליקציה מושכת הוראות דרך שרת MQTT בכתובת cardoor[.]cn ופורסת APK שקט בשם JarService. הרכיב מפענח loader בשלב שני, מתחבר לשרת C2, ומושך payload מוצפן שמדווח על פרטי המכשיר (דגם, רזולוציה, SSID של Wi-Fi, MAC) ומקבל פקודות לביצוע בקשות HTTP, הרצת JS ב-WebView, טעינת קוד, פעולות clipboard, deeplinks ובדיקות host.

החוקרים מכנים זאת שרשרת ההדבקה המתועדת הראשונה שנבנתה במיוחד ליחידות מולטימדיה ברכב. הנוזקה נמנעת ממערכות בקרת הרכב ומתמקדת בהונאה ובשימוש כפרוקסי ביתי.

מי מושפע

בעלים וציים שמשתמשים ביחידות מולטימדיה גנריות מבוססות Android של DoFun (Shenzhen Driving Control Technology Co., Ltd.), ספקית סינית של תוכנה לרכב, שירותי ענן וחומרה שמשמשת כמרכז הבידור וההגדרות.

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

למה זה חשוב

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

וקטור שרשרת האספקה דרך מעדכן מערכת חתום מאפשר הדבקה בלי אינטראקציה של המשתמש ובלי sideloading. המפעילים מאבדים נראות על קישוריות הרכב ומסתכנים בניצול משני של זהות הרשת של הרכב.

איך אפשר היה למנוע את זה

בצעו מיפוי של יחידות מולטימדיה מבוססות Android ואמתו את הספק ואת ערוץ העדכונים. העדיפו יחידות שמאפשרות השבתה או שליטה הדוקה באפליקציות עדכון צד שלישי ובנקודות קצה של MQTT.

חסמו או נטרו תעבורה לדומיינים זדוניים ידועים כמו cardoor[.]cn בקצה הרשת. שמרו על קושחת יחידת המולטימדיה מעודכנת מה-OEM, בצעו סגמנטציה בין רשתות הרכב לבין משאבים רגישים ארגוניים או ביתיים, והתייחסו לקישוריות הרכב כלא מהימנה עד לאימות.

אם עולה חשד לפריצה, בצעו איפוס יצרן ליחידה מתמונה נקייה ושנו את החשבונות המשויכים.

מה קרה

חברות אבטחה פרטו השבוע שלוש משפחות פעילות של טרויאני בנקאות שממשיכות להתפתח: Manic (Android), Grandoreiro (Windows) ו-ToxicPanda 2.0.

ThreatFabric מתארת את Manic כטרויאן בנקאות ל-Android בתוספת רוגלה, שמשמש בעיקר נגד אוקראינה (בנקים, ממשל, מסרים) אך גם נגד יעדים רוסיים, אירופיים, קריפטו, פינטק ומסרים צבאיים. הוא מגיע דרך אתרים זדוניים ו-droppers, תומך ב-keylogging, בשכבות פישינג (overlays), בשליטה מרחוק, בגניבת התראות, במעקב מיקום, באיסוף קבצים, ובממסר mesh offline דרך Wi-Fi Direct או Bluetooth כש-C2 לא נגיש.

Acronis מדווחת שטרויאן הבנקאות Grandoreiro, טרויאן ברזילאי ותיק ל-Windows, נשאר פעיל עם מיקוד כבד לאחרונה במקסיקו, תוך שהוא ממשיך לפגוע באמריקה הלטינית, באירופה ובצפון אמריקה. דגימות חדשות מנצלות את האפליקציה הלגיטימית Duplicate Files Finder באמצעות DLL sideloading וכוללות anti-analysis נרחב (בדיקות sandbox/VM).

הטרויאן ToxicPanda התרחב לגרסה 2.0 עם יכולות רחבות יותר לגניבת פרטי הזדהות ולהונאה.

מי מושפע

משתמשי Android באוקראינה ויעדים משניים ברוסיה ובאירופה, וכן יעדי קריפטו, פינטק ומסרים צבאיים ברחבי העולם; משתמשי Windows במקסיקו, באמריקה הלטינית הרחבה, באירופה ובצפון אמריקה; וקורבנות הקמפיינים המורחבים של ToxicPanda 2.0.

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

למה זה חשוב

הטרויאנים האלה משלבים פישינג של פרטי הזדהות, שליטה מרחוק במכשיר וגניבת נתונים כדי לרוקן חשבונות ולאפשר הונאה בקנה מידה רחב. רשת ה-mesh offline של Manic מאפשרת לנתונים גנובים לנוע גם בלי חיבור אינטרנט ישיר ל-C2, ומסבכת את הזיהוי ואת הבידוד.

ההתמדה של Grandoreiro לאורך עשור וניצול ה-DLL sideloading מראים איך נוזקת בנקאות בוגרת שורדת השבתות בכך שהיא מתמזגת עם תוכנה לגיטימית. מפתחים ומפעילים חייבים להניח מיקוד מתמשך באפליקציות פיננסיות ומסרים.

איך אפשר היה למנוע את זה

ב-Android: בצעו sideload רק ממקורות מהימנים, השאירו את Google Play Protect פעיל, בדקו הרשאות נגישות ו-overlay, והימנעו מקישורים בהודעות לא רצויות. השתמשו באפליקציות בנק עם בקרות ביומטריות חזקות וחתימה על עסקאות.

ב-Windows: חסמו DLL sideloading ככל האפשר, הגבילו הרצה של loaders בלתי צפויים, שמרו על EDR/AV מעודכנים, והחילו allow-listing של אפליקציות בסביבות רגישות. חנכו משתמשים לגבי פיתיונות פישינג שמפיצים נוזקות בנקאות.

נטרו שימוש חריג בשירותי נגישות, חלונות overlay וחיבורים יוצאים מאפליקציות פיננסיות. בודדו מכשירים חשודים מיד.

מה קרה

Named pipes ב-Windows מאפשרים תקשורת בין-תהליכית מקומית מהירה, אך בקרת גישה חלשה מאפשרת לעיתים קרובות לתהליכים לא מהימנים להתחבר לשירותים בעלי הרשאות גבוהות ולנצל פונקציונליות חשופה.

ThreatLocker מסבירה שמפתחים נוטים להתייחס ל-pipes באותה מכונה כמהימנים מעצם טבעם. בפועל, כל תהליך שמכיר את שם ה-pipe ומחזיק בהרשאות מספיקות יכול להתחבר. שירות בעל הרשאות גבוהות (למשל כזה שרץ כ-LocalSystem) שחושף פעולות חזקות דרך pipe מציע למעשה API מקומי ליכולות האלה. עצם החיבור אינו מוכיח שהלקוח הוא הבינארי הצפוי, שהמשתמש מורשה, או שהנתונים בטוחים.

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

מי מושפע

יישומי ושירותי Windows שמשתמשים ב-named pipes ל-IPC, ובמיוחד שירותים בעלי הרשאות גבוהות שמתקשרים עם לקוחות user-mode, אפליקציות שולחן עבודה, תהליכי tray או סוכנים ברקע.

כל תחנת עבודה או שרת Windows שמריץ תוכנות צד שלישי, סקריפטים או חשבונות שעלולים להיות פרוצים נמצא בטווח. מדובר בבעיה ארכיטקטונית ולא ב-CVE בודד.

למה זה חשוב

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

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

איך אפשר היה למנוע את זה

התייחסו לכל named pipe כאל ממשק מקומי חשוף. אמתו את זהות הלקוח המתחבר (תהליך, משתמש, רמת integrity), הרשו רק פקודות נדרשות, אמתו את כל הקלט בקפדנות, והריצו את שרת ה-pipe עם הרשאות מינימליות ככל האפשר.

החילו ACLs צרים על ה-pipe כך שרק הגורמים המיועדים יוכלו לפתוח אותו. העדיפו impersonation ובדיקות מפורשות על פני אמון גורף. ThreatLocker וכלים דומים יכולים לאכוף אימות endpoint ו-allow-listing של פקודות לתעבורת pipe.

עברו על שירותים קיימים בעלי הרשאות גבוהות שמציעים APIs מבוססי pipe, והקשיחו או עצבו אותם מחדש לפני הפריסה.