חדשות סייבר יומיות - 20 באוקטובר 2026

מה קרה

קבוצת התקיפה APT28, המקושרת לרוסיה (מכונה גם Swallowtail, Fancy Bear, Forest Blizzard ו-BlueDelta), פרצה לארגונים בשתי מדינות חברות בנאט"ו. בין היעדים: מספנה ימית, יצרן מנועי מטוסים צבאיים וסוכנות אכיפת חוק.

צוות Symantec Threat Hunter דיווח על שימוש בדלת האחורית HOOKEDGE, שנמסרה דרך מסמכי Word עם מאקרו, ועל reflective loader שלא תועד בעבר (ld.exe) שמפענח ומריץ payload מוצפן בזיכרון בלבד, ורק כשמסופק לו מפתח קריפטוגרפי ב-runtime. בפריצה למספנה בסוף יולי 2026 המפעילים ביצעו פעילות hands-on-keyboard לאורך שבוע, גנבו פרטי הזדהות בשתי שיטות (דחיפת מפתח SSH פרטי למנהרה מתמשכת ולכידת NTLM ב-PowerShell על loopback), ופתחו מנהרת SSH אל הרשת הפנימית. וריאנטים של HOOKEDGE עברו מ-C2 ב-webhook.site ל-IP ייעודי למשימות ולהוצאת נתונים (exfiltration).

מי מושפע

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

HOOKEDGE שימשה בעבר נגד יעדים ממשלתיים ודיפלומטיים ברומניה, ספרד וטורקיה.

למה זה חשוב

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

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

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

נטרו אינדיקטורים של HOOKEDGE, כולל תהליכי דפדפן Edge מחוץ למסך, C2 ב-webhook או ב-IP חריג (כמו 185.82.218.119), ו-reflective loaders מסוג ld.exe עם מפתחות runtime. אכפו בקרת אפליקציות, השביתו מאקרו או השתמשו ב-Protected View, דרשו Phishing-resistant MFA, ואתרו מנהרות SSH בלתי צפויות או לכידות NTLM על loopback.

בצעו סגמנטציה לרשתות קריטיות, בצעו רוטציה לפרטי הזדהות אחרי כל חשד לגישה, והחילו כללי EDR ל-reflective loading ולתבניות פעילות hands-on. הורידו תוכנה רק ממקורות מאומתים ועדכנו כלי הגנה מול ה-TTPs של APT28.

מה קרה

עותקים של Rank Math PRO (תוסף SEO בתשלום ל-WordPress) שהורדו מ-rankmath.com או סופקו כעדכונים בין 20:02 UTC ב-15 באוקטובר 2026 ל-07:12 UTC ב-16 באוקטובר 2026 הכילו נוזקה. Rank Math אישרה חדירה לשרשרת האספקה שפגעה בתת-קבוצה של חבילות גרסה 3.0.123.

הנוזקה מתקינה דלת אחורית שמשחזרת את עצמה ויוצרת את עצמה מחדש בביקורי אתר. היא יכולה להטמין דלתות אחוריות ב-PHP בתוספים, בערכות עיצוב וב-mu-plugins, ליצור חשבונות admin זדוניים, להוסיף קובצי core מזויפים, לשנות .htaccess להרצת PHP מתוך .cache, לשתול משימות מתוזמנות ומפתחות SSH, ולשלוף פרטי הזדהות, סודות מסד נתונים ומפתחות API. Wordfence הקצתה את CVE-2026-111862 עם CVSS 9.8. גרסה נקייה 3.0.124 שוחררה; עדכון בלבד לא מסיר ארטיפקטים קיימים של הנוזקה.

מי מושפע

אתרי WordPress שהתקינו והפעילו חבילות Rank Math PRO 3.0.123 שהתקבלו במהלך חלון של כ-11 שעות. תוסף Rank Math החינמי ב-WordPress.org לא מושפע. אתרים שהורידו בלבד בלי להתקין או להפעיל אינם מסומנים כחשופים לחדירה על סמך האירוע הזה לבדו.

ההיקף מוגבל ללקוחות PRO שהשתמשו בערוץ ההורדה/העדכון של הספק באותה תקופה; מיליונים משתמשים בגרסה החינמית, אבל PRO הוא תת-הקבוצה בתשלום.

למה זה חשוב

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

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

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

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

בצעו רוטציה לכל הסיסמאות, לפרטי ההזדהות של מסד הנתונים, למפתחות API ולסודות. אתרו חשבונות admin זדוניים (למשל שמות משתמש wpsupport_), קבצי PHP עודפים ב-mu-plugins ובערכות עיצוב, קובצי core מזויפים, שינויי .htaccess וסמני cron. נטרו תעבורה ל-rank1cdn.com. העדיפו ערוצים רשמיים ואמתו hashes כשאפשר בהמשך.

מה קרה

מפעילי כופרה, בהם Spikey Scorpius (Qilin) ו-Tarnished Scorpius (Inc), וכן גורמים שמשתמשים בכופרה Settra, מנצלים בפועל את CVE-2026-0257, עקיפת אימות ברכיבי הפורטל וה-gateway של GlobalProtect ב-PAN-OS.

הפגיעות (CVSS 9.1, ב-CISA KEV מאז מאי 2026, EPSS 96.9%) מאפשרת לתוקפים ללא הרשאות לעקוף בקרות וליצור סשני VPN לא מורשים, ולעיתים קרובות לנטרל MFA באמצעות עוגיות Authentication Override. Unit 42 תיעדה בדיקות מתמשכות וחיבורים מוצלחים ל-gateway. לאחר הגישה הפעילות כוללת איסוף מידע (reconnaissance) עם כלי RMM, תנועה רוחבית דרך RDP/SMB, חילוץ פרטי הזדהות ופריסת כופרה. במקרה אחד הגיעו התוקפים ל-vCenter, השביתו הגנות ESXi וחילצו פרטי הזדהות של הדומיין באופן offline מתוך VMDK. חלקם משרשרים אותה עם פגיעויות נוספות כמו CVE-2023-27532 ב-Veeam.

מי מושפע

ארגונים שמריצים גרסאות PAN-OS פגיעות בפורטלים וב-gateways של GlobalProtect (הענפים המושפעים כוללים 10.2, 11.1, 11.2, 12.1 וסביבות Prisma Access מסוימות). Panorama ו-Cloud NGFW אינם מושפעים.

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

למה זה חשוב

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

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

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

עדכנו מיד לגרסאות PAN-OS המתוקנות (למשל 12.1.7, 11.2.12, 11.1.15, 10.2.18-h6 או hotfixes מקבילים) ולגרסאות Prisma Access התואמות. החילו workarounds של היצרן, כמו השבתת Authentication Override, אם העדכון מתעכב.

חפשו בקבצי הלוג של GlobalProtect אחר IOCs שפורסמו (כתובות IP ספציפיות, מזהי host ושמות מכשיר חשודים כמו aa:bb:cc:dd:ee:ff או WINDOWS-LAPTOP-001, domain ריק בקונפיגורציית הלקוח, ערכי PoC מקודדים). בודדו כל אירוע של חיבור מוצלח ל-gateway, בצעו רוטציה לפרטי הזדהות והפעילו IR. השתמשו בסורקי חשיפה ל-gateways ציבוריים ואכפו הרשאות מינימליות ב-VPN.

מה קרה

Siemens אישרה ניצול בפועל של CVE-2026-110936, פגיעות DLL side-loading ב-Siemens Software Center (כל הגרסאות לפני 4.0.9.8). התוקפים מצמידים עותק מקורי וחתום כהלכה של הכלי ל-DLLs זדוניים שמוצבים לצידו. היישום טוען קבצי עזר מתיקיית ההתקנה שלו בלי בדיקות מספקות (נצפה בגרסה 3.5.8.7).

קובץ ה-MSI הזדוני (AllMyBasic.msi) מופץ מחוץ לערוצים הרשמיים דרך קמפיין ClickFix הרב פלטפורמי Romulus. פיתויי ClickFix גורמים למשתמשים להדביק ולהריץ פקודות בעצמם (לעיתים קרובות דרך CAPTCHA מזויף או בקשות אימות). Siemens דירגה אותה ב-CVSS v4 8.4. NVD מציין 6.7. אף מערכת או ערוץ עדכונים של Siemens לא נפרצו. התיקון ב-4.0.9.8 מתעדכן אוטומטית בהפעלה הבאה.

מי מושפע

משתמשי Siemens Software Center שמריצים את המתקין הטרויאני שהושג ממקורות לא רשמיים. סביבות תעשייה, הנדסה וייצור שמסתמכות על כלי ניהול התוכנה של Siemens הן היעדים העיקריים.

נצפה שהפאנל Romulus מגיש payloads מרובים, כולל loaders שיכולים לגנוב נתונים מ-Chrome. ההדבקה דורשת שהמשתמש יריץ את פקודת הפיתוי.

למה זה חשוב

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

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

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

עדכנו את Siemens Software Center לגרסה 4.0.9.8 או חדשה יותר (במערכות שכבר מותקנות התיקון נמשך אוטומטית בהפעלה). הורידו תוכנות Siemens רק ממקורות רשמיים. לעולם אל תדביקו פקודות מדפי אינטרנט ל-Win+R, לחלון Run או ל-PowerShell.

חסמו תשתית Romulus ידועה ואת ה-hashes הרשומים של MSI/DLL. חפשו את SiemensSoftwareCenter.exe כשהופעל על ידי msiexec מ-AppData\Local\Programs או רשומות אתחול לא צפויות. בודדו מארחים נגועים, הסירו persistence ואפסו סיסמאות. פרסו בקרת אפליקציות שתגביל DLL-ים לא חתומים ליד בינאריים חתומים.

מה קרה

פיקוד הסייבר של צבא ארה"ב (ARCYBER) מפתח את ECHOTRIBBLE (Agentic C2 Framework Tool) יחד עם Cyber Fusion Innovation Center ו-ArCTIC. מסמכים שהגיעו לידי The Intercept מתארים סוכני AI שמיועדים לחדור לרשתות יריב, לאתר מטרות, לשכפל את עצמם למכשירים סמוכים (למשל iPad, מחשב שולחני של Apple, Windows 11), לנטרל מטרות (להשבית או למחוק), ואז למחוק את עצמם עם פיקוח אנושי מינימלי ו-beaconing מוגבל.

הודעה ב-SAM.gov ביקשה whitepapers לניווט אוטונומי בסביבות contested, air-gapped ובענן. התוכנית בעיקרה התקפית. לא אושר בפומבי קיומו של כלי מבצעי עובד. המאמץ מתנהל על רקע יוזמות רחבות יותר של הפנטגון בתחום סוכני AI, ועל רקע תקריות אחרונות של סוכנים שאיבדו שליטה בארגונים אזרחיים.

מי מושפע

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

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

למה זה חשוב

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

הדחיפה משקפת גם את העוצמה של AI agentic נוכחי וגם בעיות guardrail שטרם נפתרו, שכבר נראו בסביבות לא צבאיות. מפתחים ומפעילים צריכים לצפות לאתגרי זיהוי עתידיים מול נוזקה קלת משקל, multi-platform, עם C2 מועט, שמוחקת ראיות.

מה קרה

ConnectWise השביתה את שירותי Cloud Backup (לשעבר SkyKick), SaaS Security ו-Cloud Management לאחר שגילתה גישה לא מורשית לזהויות אפליקציה בסביבת Cloud Backup שלה, בסביבות 15 באוקטובר 2026.

תוקפים השיגו פרט הזדהות לאפליקציית ConnectWise Cloud Backup ב-Microsoft 365 והזדהו בתור האפליקציה עצמה (לא כמשתמש), וירשו את ההרשאות הרחבות שלה לדואר, OneDrive, SharePoint, Teams ולנתוני directory. MFA לא חל על התחברויות של אפליקציות. Huntress ואחרים הבחינו בשימוש בפרט ההזדהות נגד tenant-ים רבים של לקוחות; בלפחות מקרה אחד התוקף העניק הרשאת Global Administrator ושינה הרשאות של אפליקציות אחרות. ConnectWise השביתה זהויות אפליקציה ו-certificates מרובים; עד כה לא דווח על גישה מאומתת לארכיוני גיבוי של שותפים, אך החקירה נמשכת. השירותים נשארים offline עד לשחזור בטוח.

מי מושפע

שותפי ConnectWise והלקוחות שלהם שמשתמשים בשירותי הגיבוי בענן ובשירותים הקשורים שנפגעו, ובמיוחד מי שאישר את אפליקציית Cloud Backup ב-tenants של Microsoft 365. Huntress תיעדה פעילות גישה לא מורשית ביותר מ-100 tenants, ודווחו גם ניסיונות התחברות רחבים יותר.

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

למה זה חשוב

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

השבתת השירות משבשת את פעילות ה-MSP ואת יכולות השחזור של הלקוחות. ניסיונות התמדה (סודות חדשים, שינויי תפקידים) משמעותם שגם אחרי שהכילה ConnectWise את האירוע, כל tenant בנפרד זקוק לבדיקה ולניקוי משלו.

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

נתקו את חיבורי אפליקציית ConnectWise שנפגעו ב-Entra ID / Microsoft 365 עד שהספק יפרסם הנחיות לשחזור ויאשר שבוצעה רוטציה לפרטי ההזדהות. שמרו מיד את לוגי ההתחברות ואת לוגי הביקורת.

חפשו הקצאות Global Admin בלתי צפויות, סודות אפליקציה חדשים, או פעילות Graph מזהות האפליקציה של ConnectWise או מכתובות IP חריגות. בצעו רוטציה לכל פרטי הזדהות או סודות שעלולים היו להיחשף. בדקו והחמירו את הסכמות לאפליקציות צד שלישי עם הרשאות Graph רחבות; העדיפו פרטי הזדהות מבוססי תעודה או בעלי אורך חיים קצר, ו-continuous access evaluation כשאפשר. נטרו סיכונים דומים של סודות אפליקציה בשרשרת האספקה בכלי גיבוי/MSP אחרים.

מה קרה

OpenCode אישרה פריצת אבטחה בשירות Console שלה (מוצר ה-workspace עם פרטי הזדהות משותפים) שהתרחשה בליל 16 באוקטובר 2026. גישה לא מורשית למערכת legacy שהייתה בתהליך הוצאה משימוש עלולה הייתה לחשוף מפתחות API של ספקי צד שלישי (OpenAI, Anthropic, Google Gemini) שנשמרו ב-workspaces שנפגעו.

החברה מסרה שהאירוע השפיע על 1.4% ממשתמשי Console, ספציפית אלה שקישרו ספקים חיצוניים, ושלחה להם מייל. היא תיארה את האירוע כקשור למתקפת distillation בקנה מידה גדול והודיעה לספקים. הכלי open-source המרכזי OpenCode עצמו לא דווח כנפרץ; רק מפתחות שנשמרו ב-Console. חלק מהמשתמשים ראו שימוש וחיובים בלתי צפויים. הספקים ביטלו או חסמו רבים מהמפתחות שנפגעו, והחלו החזרים על הוצאות לא מורשות.

מי מושפע

כ-1.4% ממשתמשי OpenCode Console שקישרו ל-workspaces מפתחות API משלהם של OpenAI, Anthropic או Google. OpenCode מדווחת על עשרות מיליוני משתמשים פעילים בחודש בסך הכל, אבל רק קבוצת המשנה של Console עם מפתחות חיצוניים נמצאת בטווח ההשפעה.

משתמשים שמריצים את OpenCode מקומית בלי לשמור מפתחות ב-Console, או שלא קיבלו מייל, מחוץ להשפעה שצוינה. גם מפתחות שהוסיפו מנהלי workspace נמצאים בסיכון עבור אותם workspaces.

למה זה חשוב

מפתחות ספקי AI גנובים מאפשרים שימוש לא מורשה במודלים באופן מיידי, חיובים בלתי צפויים, הוצאת נתונים (exfiltration) פוטנציאלית דרך prompts, או שימוש לרעה נוסף במפתחות בשירותים אחרים. מתקפות בסגנון distillation יכולות לנצל מפתחות גנובים כדי לאמן מודלים מתחרים בזול.

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

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

אם קיבלתם את המייל מ-OpenCode (נושא בערך "Action Required: Potential provider key breach"), או ששמרתם אי פעם מפתחות ספק ב-Console, צרו מיד מפתחות חדשים ב-OpenAI, Anthropic ו-Google, ואז בטלו את הישנים. בדקו שימוש וחיובים אצל הספקים מ-16 באוקטובר ואילך לאיתור חריגות.

עדכנו את כל סודות ה-CI/CD, קבצי הסביבה, קונפיגורציות מקומיות ומכונות הצוות במפתחות החדשים לפני שתוציאו את הישנים משימוש לחלוטין. העדיפו מפתחות בהיקף פרויקט עם מגבלות הוצאה והגבלות IP או referrer. הימנעו משמירת מפתחות ספק לטווח ארוך ב-consoles של צד שלישי כשקיימות חלופות מקומיות או בעלות אורך חיים קצר. בדקו את רשימות מנהלי ה-workspace ב-Console ואת לוגי הביקורת.