חדשות סייבר יומיות - 28 בספטמבר 2026

מה קרה

Citrix פרסמה תיקונים לשמונה פגיעויות ב-NetScaler ADC וב-Gateway, ואישרה ש-CVE-2026-88771 ו-CVE-2026-88772 נוצלו כ-zero-days במשך שבועות כדי לשתול webshells במכשירים שלא תוקנו.

פגיעות CVE-2026-88771 (CVSS 9.8) נובעת מאימות קלט לקוי ומאפשרת לתוקף ללא הזדהות להריץ פקודות מרחוק, בתצורות ברירת מחדל וללא אינטראקציה מצד המשתמש. פגיעות CVE-2026-88772 (CVSS 8.1) היא גלישת זיכרון שמובילה להרצת קוד מרחוק או למניעת שירות, וניתנת לניצול מרחוק כש-DTLS מופעל (ברירת המחדל בשרתי VPN וירטואליים). שתיהן נמצאות ב-CISA KEV וניתן לנצל כל אחת מהן בנפרד. נראה שמאחורי ההתקפות עומד גורם בעל משאבים, וייתכן שמדובר בפעילות ברמת מדינה לצורכי ריגול.

מי מושפע

פריסות Citrix NetScaler ADC ו-NetScaler Gateway בניהול לקוח: v14.1 עד לפני 14.1-73.37, v13.1 עד לפני 13.1-64.23, וכן וריאנטים של FIPS ו-NDcPP עד לפני ה-builds שצוינו. גם פריסות Secure Private Access Hybrid שמשתמשות ב-NetScaler מושפעות.

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

למה זה חשוב

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

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

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

עדכנו מיד ל-builds המתוקנים (14.1-73.37, 13.1-64.23, או גרסאות FIPS/NDcPP המקבילות). לאחר העדכון, בדקו כל מכשיר לאיתור webshells וסימני חדירה לפי הנחיות Citrix ואינדיקטורים ב-NetScaler Console.

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

מה קרה

פגיעות CVE-2026-65660, הזרקת קוד שמאפשרת הרצת קוד מרחוק ב-Microsoft SharePoint, מנוצלת בפועל כשישה שבועות אחרי תיקון Patch Tuesday מאוגוסט 2026, וימים אחרי שנחשפו הפרטים הטכניים.

Microsoft אישרה ראיות אמינות לתקיפות, נכון ל-25 בספטמבר 2026. CISA הוסיפה אותה לקטלוג KEV באותו יום, עם מועד יעד פדרלי לתיקון ב-28 בספטמבר. Previdian זיהתה ניסיונות ניצול ב-24 בספטמבר וניסיונות יצירת webshell ב-25 בספטמבר, בהתאם לפרטים מחוקרי Viettel Security. ציון ה-CVSS הוא 8.8. הפגיעות דורשת גישה מאומתת ברמה נמוכה וללא אינטראקציה מצד המשתמש; כדי להגיע ל-RCE ללא הזדהות נדרש שרשור עם עקיפת אימות נפרדת.

מי מושפע

ארגונים שמריצים Microsoft SharePoint Server on-premise בגרסאות שתוקנו בעדכוני אוגוסט 2026 (Subscription Edition, 2019 ו-builds של 2016). סביבות SharePoint החשופות לאינטרנט או עם סגמנטציה לקויה, שבהן קיימים משתמשים מאומתים עם הרשאות נמוכות, נמצאות בסיכון הגבוה ביותר.

קטלוג CISA KEV מונה כעת 16 פגיעויות SharePoint בסך הכל, מה שמדגיש מיקוד מתמשך בפלטפורמה.

למה זה חשוב

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

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

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

החילו מיד את עדכוני האבטחה של SharePoint מאוגוסט 2026 אם עדיין לא עשיתם זאת (KBs ו-builds ספציפיים ל-SE, 2019 ו-2016). ודאו את רמת התיקון וצודו אחר webshells או פעילות מאומתת חריגה.

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

מה קרה

חוקרים חשפו את בוטנט Carbonato, שתוקף daemons של Docker חשופים וללא אימות בפורט 2375 כדי לפרוס את מסגרת Hermes Agent AI בקוד פתוח תחת שליטת התוקף.

רכיב ה-implant מפעיל קונטיינר עם הרשאות מוגברות, מקים persistence ומנהרות SSH הפוכות (relay בקוסטה ריקה), ואז מתקין את Hermes Agent ללא שינוי ודורס את קובץ ה-persona SOUL.md שלו בפרומפט בן 39 שורות. הסוכן (בשם GH0ST) מבצע משימות שהתקבלו ב-Telegram דרך gateway של LLM, מתעדף גניבת מפתחות API של AI ופרטי הזדהות, וסורק רשתות שכנות כל חמש דקות לצורך התפשטות דמוית תולעת. ThreatDown מצאה ראיות דרך registry ציבורי של Docker ללא אימות, שמעידות על פעילות לאורך חודשים.

מי מושפע

כל ארגון או אדם שמריץ מארחי Docker עם ה-API של ה-daemon חשוף לאינטרנט ללא אימות בפורט 2375. סביבות ענן, self-hosted ופיתוח עם Docker בקונפיגורציה שגויה הן היעדים העיקריים.

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

למה זה חשוב

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

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

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

לעולם אל תחשפו את ה-API של Docker daemon (פורט 2375/2376) לאינטרנט ללא אימות חזק, TLS ובקרות רשת. השתמשו בחומות אש, VPN או באימות המובנה של Docker. העדיפו הגדרות rootless או הרשאות מינימליות.

סרקו וסגרו daemons חשופים, נטרו הפעלות של קונטיינרים עם הרשאות מוגברות ומנהרות הפוכות בלתי צפויות או persistence מסוג cron/watchdog, ובצעו רוטציה לכל פרטי הזדהות או מפתחות API של AI במארחים שעלולים להיות מושפעים. חפשו ארטיפקטים של Hermes Agent ואת ה-persona המותאם ב-SOUL.md.

מה קרה

גורם האיום JADEPUFFER (שמסומן ב-Microsoft כ-Storm-3168) השתמש בשני service principals של Azure שנפרצו באותו tenant כדי לבצע איסוף מידע (reconnaissance) ואז פעולות הרסניות שנמשכו כ-18 שעות בתחילת יוני 2026.

ה-service principal הראשון ביצע יותר מ-300 פעולות קריאה שמיפו VMs, subscriptions, resource groups ועוד במשך כ-16 שעות. השני ביצע discovery יחד עם יותר מ-150 פעולות הרס ואיסוף פרטי הזדהות תוך כ-35 דקות, ומיקד Storage Accounts, מסדי נתונים SQL, Key Vaults, Function Apps, recovery locks, VMs ו-App Services. Microsoft כינתה זאת התפתחות ב-tradecraft של הגורם. הגישה הראשונית התבססה על פרטי הזדהות של service principal (client ID, secret, tenant ID) שנחשפו בהיסטוריית העריכה של issue ציבורי ב-GitHub. הגורם נקשר בעבר לכופרה agentic דרך CVE-2025-3248 ב-Langflow.

מי מושפע

tenants של Azure שבהם נפרצו service principals או זהויות workload, במיוחד כאלה עם תפקידים רחבים מדי כמו Contributor או Storage Account Contributor ועם סודות שנחשפו במאגרים ציבוריים או בקבצי לוג.

כל ארגון שמשתמש ב-service principals של Azure לאוטומציה חשוף פוטנציאלית אם היגיינת הסודות והרשאות המינימליות חלשות.

למה זה חשוב

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

זה מדגים כיצד tradecraft agentic ואוטומטי יכול להסלים במהירות מאיסוף מידע לנזק בלתי הפיך (אחסון שנמחק, מסדי נתונים, הגנות שחזור). מפעילי ענן חייבים להתייחס לזהויות workload באותה קפדנות כמו לחשבונות admin אנושיים.

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

החילו הרשאות מינימליות על service principals ועל managed identities. הימנעו מתפקידי Contributor רחבים. אחסנו סודות ב-Key Vault או במקבילה, לעולם לא בקוד או ב-issues ציבוריים ב-GitHub (כולל היסטוריית עריכה).

הפעילו הגנות של Microsoft Defender for Cloud, נטרו פעילות חריגה של service principal (קריאות המוניות ואחריהן מחיקות), הגנו על recovery locks ועל תכונות soft-delete, ובצעו רוטציה מיידית לכל פרטי הזדהות שנחשפו. סקרו ונקו את היסטוריית המאגרים הציבוריים מסודות client שדלפו.

מה קרה

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

הדגימות נראות אותנטיות ומכילות גם שמות, כתובות, מספרי טלפון, מספרי תג, תפקידים ומידע על בני זוג. הקבוצה טוענת שיש לה גישה ל-FBI MedLink (רשומות רפואיות), ל-FBI BEAST (בדיקות רקע) ולמערכות קשורות, ומצהירה על נתונים של כ-60,000 עובדים נוכחיים וקודמים וכן מועמדים. המניע אינו כספי: דרישה שה-FBI תמשוך advisory ממאי שהקבוצה מכנה שקרי. ה-FBI אישרה אירוע שפגע במערכות הקשורות ל-FBIJobs ובודקת אותו, בלי אישור מלא של היקף הנתונים הרפואיים.

מי מושפע

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

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

למה זה חשוב

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

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

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

מי שנפגע: עקבו אחרי FBI.gov לקבלת הנחיות רשמיות, החליפו סיסמאות שנעשה בהן שימוש חוזר (במיוחד חשבונות FBIJobs), הפעילו אימות רב-שלבי (MFA) בכל מקום אפשרי, והיזהרו מפישינג ממוקד או מסחיטה.

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

מה קרה

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

הוא תומך באימייל/סיסמה, magic links, passkeys, התחברות חברתית (יותר מ-10 ספקים), קודים חד-פעמיים ל-MFA, SAML 2.0 ו-OpenID Connect. הרשאות ברזולוציה עדינה מגיעות ממנוע OpenFGA מובנה (בסגנון Zanzibar). שרת MCP מובנה חושף פונקציות לקריאה בלבד של פרופיל ובדיקת הרשאות עבור סוכני AI דרך stdio מקומי בלבד, כך שסוכן שפועל בשם משתמש מקבל רק את החיתוך בין ההרשאות שלו לבין אלה של המשתמש. זה מטפל ישירות בעוזרי AI שמבצעים חיפוש וקטורי בלי בדיקות הרשאה מוקדמות.

מי מושפע

צוותי פיתוח שבונים יישומי web או מובייל ורוצים auth באירוח עצמי בלי vendor lock-in או תמחור לפי משתמש, במיוחד כאלה שמשלבים סוכני AI שצריכים לכבד הרשאות ברמת מסמך או ברמת משאב.

תומך ביותר מ-13 מסדי נתונים, כולל PostgreSQL, MySQL, MongoDB ו-DynamoDB.

למה זה חשוב

אימות self-hosted שומר את נתוני הזהות במסד הנתונים של הצוות עצמו ועוקף בעיות תמחור SaaS ו-data residency. ממשק ה-AI-agent מסייע למנוע מצ'אטבוטים עם הרשאות יתר לשלוף מסמכים שמשתמש לא אמור לראות.

מפתחים שמוסיפים copilots או צינורות RAG מקבלים דרך מעשית לאכוף הרשאות לפני השליפה, ומצמצמים מקור נפוץ לדליפת מידע בפיצ'רים מבוססי AI.

מה קרה

בורסת הקריפטו Bitget חידשה משיכות Bitcoin לאחר שהשעתה אותן בעקבות פריצה שבה האקרים החשודים כצפון קוריאנים גנבו כ-387.5 מיליון דולר מארנקים חמים ופושרים (hot and warm wallets).

התוקפים פרצו למערכת backend קריטית בתשתית הארנקים, זייפו נתוני עסקאות והפעילו העברות לא מורשות על פני מספר chains (Ethereum, XRP Ledger, Arbitrum, Avalanche, Optimism, BSC, Base ואחרות), בלי לגנוב מפתחות פרטיים. ההערכה הראשונית עמדה על 351.6 מיליון דולר. מעקב on-chain העלה אותה ל-387.5 מיליון דולר. המנכ"לית גרייסי צ'ן (Gracy Chen) ציינה תבניות IP והתנהגות on-chain העולות בקנה אחד עם קבוצות תקיפה של DPRK. האירוע מוכל, יתרות המשתמשים נשארות מכוסות על ידי קרן ההגנה (Protection Fund), ותוכנית bounty לשחזור פעילה.

מי מושפע

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

חידוש מדורג: תחילה BTC, אחר כך רשתות ETH, USDT, ובהמשך יתר הנכסים, פיאט ו-P2P.

למה זה חשוב

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

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

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

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

משתמשים: הפעילו את כל מאפייני האבטחה הזמינים בחשבון, משכו ל-self-custody כשאפשר, ועקבו אחרי ערוצי הסטטוס הרשמיים בזמן אירועים. מעקב on-chain ותוכניות bounty מסייעים לשחזור אך אינם מחליפים מניעה.