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

מה קרה

גורמי איום החלו לנצל פגיעות קריטית של עקיפת אימות ב-Microsoft SharePoint זמן קצר לאחר שפורסם proof-of-concept פומבי.

CVE-2026-55040 (CVSS 9.1) היא פגיעות עקיפת מנגנון אבטחה הנובעת מאימות חלש ומפגמים בצינור ה-validation של JWT tokens. היא מאפשרת לתוקף ללא הרשאות לזייף JWT תקף (בטכניקות כמו alg:none ופתרון תעודות לא מהימן) ולהתחזות לכל משתמש או מנהל באתר SharePoint, ובכך לאפשר חשיפת קבצים ושינוי נתונים. Microsoft תיקנה אותה בעדכוני Patch Tuesday של יולי 2026.

Rapid7 פרסמה PoC ב-Python שמשרשר ארבעה פגמים ב-SPJsonWebSecurityTokenHandlerV2 ובמחלקות קשורות. טלמטריה הראתה זינוק ל-12 ניסיונות ניצול (בעיקר ב-12-13 באוגוסט) מכתובות IP בהונג קונג, יפן, הולנד, טייוואן וארה"ב לאחר פרסום ה-PoC. זו הפגיעות החמישית ב-SharePoint שמנוצלת ב-2026.

מי מושפע

ארגונים שמריצים שרתי Microsoft SharePoint Server on-premise לא מעודכנים שחשופים לרשת.

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

למה זה חשוב

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

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

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

החילו מיד את עדכוני Patch Tuesday של Microsoft ליולי 2026 עבור SharePoint ואמתו את ההתקנה בכל השרתים.

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

מה קרה

גורם APT חשוד החל בקמפיין גלובלי שמנצל פגיעות directory traversal קריטית ב-VMware vCenter ימים ספורים לאחר הגילוי.

CVE-2026-59310 (CVSS 9.8) היא פגיעות directory traversal בשרת ה-Syslog של vCenter, שמאפשרת לתוקף ללא הרשאות עם גישה לרשת להריץ קוד שרירותי. Broadcom/VMware חשפו ותיקנו אותה ב-29 ביולי 2026. הניצול החל בסביבות 3 באוגוסט.

חברת ה-IR הגרמנית QUIRSO זיהתה את הקמפיין במהלך מענה לאירוע: התוקפים השתמשו בפגיעות לגישה ראשונית, ואז התקינו cron job זדוני שמריץ reverse_ssh לצורך C2 יוצא מתמשך. הפעילות פגעה ב-361 כתובות IP ייחודיות של קורבנות ב-47 מדינות (עם מיקוד כבד בארה"ב, גרמניה, צרפת, טורקיה ואיראן). תיקון לבדו עשוי שלא להסיר persistence קיים של reverse_ssh.

מי מושפע

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

vCenter פרוס בהרחבה כמישור הניהול המרכזי לסביבות וירטואליות; כל appliance לא מעודכן נמצא בסיכון גבוה לחדירה מלאה.

למה זה חשוב

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

vCenter נשאר יעד בעל ערך גבוה הן לפשיעי סייבר והן לגורמי מדינה בגלל רדיוס הפגיעה שלו.

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

החילו מיד את התיקונים של Broadcom/VMware עבור CVE-2026-59310 ואמתו שכל סביבות vCenter מעודכנות.

בצעו בדיקות פורנזיות לאיתור reverse_ssh, cron jobs בלתי צפויים או חיבורים יוצאים לתשתית התוקף. בודדו את ממשקי הניהול של vCenter באמצעות סגמנטציית רשת, הגבילו קישוריות יוצאת, ונטרו פעילות directory traversal או Syslog חריגה. השתמשו בכלל ה-YARA שפרסמה QUIRSO לזיהוי reverse_ssh.

מה קרה

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

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

השופט וולטר ספיידר ג'וניור (Walter Spader Jr.) הוציא החלטת סנקציות שמתחה ביקורת על הניסיון. בית המשפט אינו משתמש ב-AI לעיבוד הגשות. ההזרקות זוהו על ידי עורך הדין ברנדן פאלפרימן (Brendan Palfreyman) ואומתו על ידי 404 Media.

מי מושפע

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

במקרה הספציפי הזה הושפע תיק אזרחי אחד בקונטיקט (Matthew Elliott נגד New York Bariatric Group), אך לטכניקה יש השלכות רחבות יותר על מערכי עיבוד מסמכים.

למה זה חשוב

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

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

מה קרה

חוקרי Group-IB חשפו את WindRelay, נוזקת Android חדשה שנבנתה במיוחד כדי ללכוד נתוני כרטיסי תשלום חיים דרך NFC ולהעביר אותם בזמן אמת למסופים בשליטת התוקף.

היא פועלת יחד עם טרויאני השליטה מרחוק SpyNote. ההונאה מתחילה בשיחת טלפון של הנדסה חברתית שבה המתקשר מתחזה לבנק של הקורבן. הקורבן מונחה להתקין אפליקציית SpyNote מותאמת אישית (שמסומנת בשמו). ברגע שהטרויאני SpyNote מספק שליטה מרחוק, הנוכל מתקין בשקט את WindRelay. הקורבן נשאר על הקו בזמן שהתוקף משתמש בטלפון כממסר NFC, משדר נתוני כרטיס למסוף סוחר מזויף, ואף יכול לקחת הלוואות דרך גישה מרחוק לאפליקציות בנקאות - תוך שימוש ב-PIN שהקורבן עצמו מקליד.

23 דגימות של WindRelay הופיעו ב-VirusTotal (נובמבר 2025 - יולי 2026), עם מיקוד בצ'כיה, סלובקיה וסלובניה. זוהו ארבע כתובות IP של C2.

מי מושפע

משתמשי Android, בעיקר במרכז אירופה (צ'כיה, סלובקיה וסלובניה), שעונים לשיחות התחזות לבנק ומתקינים אפליקציות.

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

למה זה חשוב

השילוב של הנדסה חברתית חיה, השתלטות על המכשיר וממסר NFC בזמן אמת מאפשר הונאה בזמן שהקורבן עדיין מחזיק בכרטיס ונשאר על הקו. זה עוקף רבות מבקרות ה-card-not-present המסורתיות ומהנחות של החזקה פיזית.

גישת הנוזקה הכפולה (RAT + ממסר ייעודי) מראה שמפעילי הונאה מודרניים משלבים יכולות כדי לבצע מימושים והלוואות בהצלחה גבוהה ובחיכוך נמוך.

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

אל תתקינו אפליקציות ואל תעקבו אחרי הוראות משיחות בנק לא יזומות; נתקו ופנו לבנק דרך הערוצים הרשמיים. הפעילו את Google Play Protect, הגבילו התקנה ממקורות לא ידועים, ובדקו הרשאות אפליקציות (במיוחד NFC, נגישות ואנשי קשר).

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

מה קרה

Jamf Threat Labs זיהתה נוזקה חדשה לגניבת מידע ב-macOS, מרובת שלבים ומבוססת Rust, בשם AmnesiaStealer, שמופצת דרך פיתיונות הנדסה חברתית מסוג ClickFix.

הקורבנות מופנים לדף הורדה מזויף של GitHub עם תיבת "התקנה ב-Terminal". לחיצה על העתקה מייצרת פקודת base64 שכשמדביקים ומריצים אותה שולפת סקריפט קצר שמוחק את עצמו ומפעיל את הבינארי של AmnesiaStealer. הנוזקה משתיקה את צלילי המערכת (כדי להסתיר צלילי העתקה של Finder), אוספת נתונים מ-Apple Notes ומ-Telegram תוך הימנעות מ-prompts של TCC, מבקשת את סיסמת המשתמש לפתיחת קבצי keychain, מארגנת ומבצעת הוצאת נתונים (exfiltration) של פרטי הזדהות, נתוני דפדפן ומידע מערכת, ואז פורסת מודול בשלב שני.

השלב השני מעניק למפעילים שליטה מרחוק חשאית על פרופיל דפדפן Chromium משובט (Chrome, Brave, Edge, Arc, Opera, Vivaldi, Chromium), כך שניתן לגנוב סשנים מאומתים פעילים ו-cookies באופן בלתי נראה. הוא כולל לוגיקה מסועפת לפי גרסת מערכת ההפעלה, שמכוונת ל-bypasses ב-macOS שכבר תוקנו בעבר.

מי מושפע

משתמשי macOS שנופלים בפיתיונות ClickFix, ובמיוחד מי שמבקרים בדפי הורדה מזויפים ומדביקים פקודות ב-Terminal.

כל Mac שמריץ דפדפנים נתמכים ומחזיק פרטי הזדהות, הערות או נתוני Telegram הוא יעד פוטנציאלי; הקמפיין ממחזר תבניות פיתיון שנראו גם אצל stealers אחרים ל-macOS.

למה זה חשוב

ClickFix עוקף הגנות מסורתיות רבות כי המשתמש עצמו מריץ את הפקודה. החשאיות של AmnesiaStealer (השתקת צלילים, הימנעות מ-TCC, שיבוט פרופילים לשליטה בלתי נראית בדפדפן) והעיצוב מרובה השלבים מקשים על זיהוי ותגובה, ובמקביל מאפשרים גניבת סשנים ופרטי הזדהות בעלי ערך גבוה.

הנוזקה מרחיבה את אקוסיסטם ה-infostealer ל-macOS שגדל, ומראה שתוקפים משכללים יכולות הפצה ופעילות post-infection ספציפית לפלטפורמות של Apple.

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

אמנו משתמשים לעולם לא להעתיק, להדביק ולהריץ פקודות מדפי אינטרנט או ממקורות לא יזומים. אכפו allowlisting של אפליקציות, חסמו הרצות Terminal לא מוכרות כשאפשר, והשאירו את macOS והדפדפנים מעודכנים במלואם.

פרסו זיהוי endpoint שמסמן סקריפטים מפוענחי base64, גישה לא צפויה ל-keychain, השתקת צלילים ושיבוט חריג של פרופילי דפדפן. נטרו פיתיונות בסגנון ClickFix והשתמשו בבידוד דפדפן או בחשבונות עם הרשאות מינימליות לעבודה יומיומית.

מה קרה

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

מודלים כמו GLM-5.2 של Z.ai, Grok 4.5 של xAI, Opus 4.7 של Anthropic, Muse Spark 1.1 של Meta, ובמיוחד GPT-5.5 של OpenAI, מטפלים כעת בזרימות עבודה agentic מורכבות למדי של ניצול, שבהן התקשו רק לפני שישה חודשים. GPT-5.5 הציג תוצאות חזקות בבדיקות white-box ו-black-box של אפליקציות web, קיצץ דרמטית את שיעורי הפספוס (10% מול 40% ל-GPT-5), וביצע טוב יותר בלי גישה לקוד מקור - קרוב יותר לנקודת המבט של תוקף אמיתי.

מכיוון שהמודלים האלה זולים יותר, מפעילים יכולים להריץ אותם שוב ושוב או לאופקים ארוכים יותר, מה שמאפשר להם לעקוף מודלי frontier יקרים יותר במשימות רבות.

מי מושפע

צוותי אבטחה, red teams וארגונים שחוששים ממתקפות בסיוע AI, וגם קובעי מדיניות שעוקבים אחרי ספי יכולות ה-AI.

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

למה זה חשוב

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

מגנים חייבים להתכונן לעולם שבו איסוף מידע (reconnaissance) וניצול מונעי AI אינם עוד מוגבלים לגורמי איום עתירי משאבים בלבד.

מה קרה

ספקית ה-CRM Beacon דיווחה שמפתח גישה ל-AWS שנפרץ היה ככל הנראה הגורם השורשי לפריצה שפגעה בנתונים של כ-1,500 עמותות בבריטניה.

המפתח נחשף כנראה ב-build artifacts ציבוריים של JavaScript במהלך הפיתוח. התוקף השתמש בפרטי ההזדהות התקפים כדי לגשת ולהוריד את כל הנתונים בפלטפורמת ה-CRM, כולל קבצים מצורפים. הפעילות הזדונית נמשכה כשעה ו-27 דקות החל מ-27 ביולי 2026 בשעה 01:20 UTC, במקביל לזינוק בהורדות. הנתונים הוצפנו במנוחה, אך AWS פיענח אותם בעת הורדה מורשית.

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

מי מושפע

כל בסיס הלקוחות של Beacon, כ-1,500 עמותות בבריטניה, והאנשים שנתוניהם האישיים הוחזקו אצל אותן עמותות (שמות, כתובות אימייל, מספרי טלפון ורשומות תרומות).

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

למה זה חשוב

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

התקרית ממחישה איך פרט הזדהות ענן בודד שנחשף ב-build artifacts יכול להוביל להוצאת נתונים (exfiltration) המונית של בסיס לקוחות multi-tenant שלם.

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

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

הפעילו CloudTrail, GuardDuty וזיהוי חריגות בעלות ובשימוש; דרשו MFA וגישה מותנית לתפקידים רגישים. בצעו רוטציה למפתחות מיד עם כל חשד לחשיפה, וערכו סקירות גישה קבועות. ספקיות SaaS צריכות לבודד נתוני tenant בצורה הדוקה יותר ולנטר תבניות של הורדות המוניות.