חדשות סייבר יומיות - 13 בנובמבר 2026

מה קרה

פורסם קוד אקספלויט proof-of-concept ציבורי בשם SignDrop, שטוען שמשתמש Windows מקומי יכול להסלים הרשאות ל-SYSTEM באמצעות ניצול מנהל ההתקן Common Log File System (CLFS).

האקספלויט מכוון לפיצ'ר אימות לוגים שנוסף בעדכונים מסוף 2025. משתמש רגיל מכין לוג CLFS וקונטיינר בנתיבים מבוקרים. כשתהליך בעל הרשאות (כמו שירות האנטי-נוזקה של Defender) פותח אותו, מנהל ההתקן clfs.sys יוצר קובץ שחזור .cnpf נלווה בהקשר בעל ההרשאות. קישורי Object manager symbolic link מפנים את היצירה כך שהמשתמש יכול לכתוב קובץ בבעלות SYSTEM ולשרשר ממנו ל-shell.

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

מי מושפע

מערכות Windows 11 25H2/26H1/26H2 (כולל builds ניסיוניים) ו-Windows Server 2025 שבהן מצב ה-registry של אימות CLFS הוא 0 (enforced) או 1 (learning). במערכות שכבר מותקנות זמן רב המצב עובר בדרך כלל ל-enforced אחרי 90 יום, כך שקונפיגורציות ברירת המחדל נמצאות בטווח.

מערכות ישנות יותר או כאלה שבהן המיטיגציה מבוטלת (מצב 2 או 3) נמצאות מחוץ למשטח התקיפה הספציפי הזה, אך מאבדות את ההגנה מפני בעיות memory-corruption קודמות ב-CLFS. נדרשת גישה מקומית מאומתת.

למה זה חשוב

ל-CLFS יש היסטוריה ארוכה כיעד להסלמת הרשאות, עם פגיעויות קודמות רבות בקטלוג known-exploited של CISA ועם שימוש בכופרה. הפיכת פיצ'ר אבטחה שנועד לחזק את טיפול הלוגים לנתיב LPE מעניקה לתוקפים מסלול אמין ממשתמש רגיל ל-SYSTEM ב-builds עדכניים של Windows שעודכנו במלואם.

PoC ציבורי מוריד את רף הניצול בנוזקה, בכופרה או בכלי post-compromise. מפעילים שמריצים endpoints או שרתים של Windows צריכים להתייחס ברצינות להסלמות מקומיות לא מאושרות אך מפורטות, עד ש-Microsoft תגיב.

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

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

יישמו defense-in-depth: הגבילו הרשאות משתמש מקומיות, הפעילו attack-surface reduction ובקרת אפליקציות, נטרו שימוש חשוד ב-symbolic links או אינטראקציות של שירות Defender שיוצרות קבצי .cnpf בלתי צפויים, ועקבו אחרי advisories של Microsoft ל-CVE רשמי ולתיקון. בודדו מערכות בעלות ערך גבוה והשתמשו בחשבונות שירות עם הרשאות מינימליות.

מה קרה

תוקף השתמש בפרטי הזדהות גנובים של 4,837 חשבונות GitHub כדי לשתול CI secret stealer ב-repositories שאליהם יכלו החשבונות לכתוב, לפי Aikido Security.

המתקפות החלו ב-pull requests לבדיקה בכותרת "docs: dependency audit notes" מענפים בשם wfx-docs (וענפי chore זמניים דומים) כדי לבדוק הרשאות כתיבה, ופגעו ב-61,764 repositories. לאחר מכן הוזרק כלי ה-stealer ללפחות 1,806 repos (SafeDep זיהתה commits זדוניים ב-8,093+ ענפי default ציבוריים). ברוב המקרים הוא נוסף ל-workflows קיימים, ובאחרים כ-hook של npm postinstall. השינויים בוטלו לעתים קרובות תוך דקות והלוגים נמחקו.

כלי ה-stealer אוסף secrets ופרטי הזדהות ענן שנגישים ל-workflows של CI. חשבונות שנפרצו ופתחו רק PRs לבדיקה עדיין נחשבים שרופים.

מי מושפע

כל repository ב-GitHub שניתן לכתיבה על ידי אחד מ-4,837 החשבונות שנחטפו, כולל repos ציבוריים ופרטיים (שלא נראו), פרויקטים נגישים לארגון או ל-collaborators, ומכונות מפתחים שהריצו npm install על commits מושפעים.

המספרים של SafeDep ו-Aikido מכסים רק פעילות ציבורית גלויה, וההיקף האמיתי גבוה יותר. בעלי repos שקיבלו את כותרת ה-PR לבדיקה או ענפי wfx-docs מיום שלישי ואילך נמצאים בטווח.

למה זה חשוב

pipelines של CI מחזיקים secrets בעלי ערך גבוה (מפתחות ענן, tokens, פרטי הזדהות לפריסה). קמפיין המוני לגניבת פרטי הזדהות שמזריק גונבים ומנקה את עצמו אוטומטית הופך שיתוף פעולה שגרתי ב-GitHub לוקטור של שרשרת אספקה וחדירת ענן בקנה מידה רחב.

גם נוכחות קצרה של ה-stealer יכולה לבצע הוצאת נתונים (exfiltration) של כל מה שה-workflow מגיע אליו. מפתחים וארגונים שמסתמכים על GitHub Actions או כלים דומים ניצבים בפני צורך מיידי ברוטציה של פרטי הזדהות ובסיכון לפריצות ענן בהמשך השרשרת.

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

בדקו מיד repositories לאיתור ענפים בשם wfx-docs או chore/[a-z0-9]{8} זמניים, PRs בכותרת "docs: dependency audit notes", ושינויים בלתי צפויים ב-workflow או ב-postinstall של package.json מאז תחילת האירוע. שללו tokens, הרשאות OAuth, מפתחות SSH וסשנים של כל חשבון שפתח PRs כאלה.

בצעו רוטציה לכל ה-secrets, המשתנים ותפקידי הענן שה-repo יכול לגשת אליהם. אכפו 2FA על חשבונות GitHub, סקרו הרשאות collaborators וארגון, הגבילו מי יכול לשנות workflows, השתמשו ב-OIDC ובפרטי הזדהות קצרי חיים במקום secrets ארוכי טווח כשאפשר, והתייחסו למכונות שהריצו npm install על commits חשודים כמערכות שנפרצו.

מה קרה

גורמי איום החלו לנצל zero-day חדש ב-N-able N-central, שכונה 4EverAble2Shell, שעות אחרי שחוקר פרסם קוד proof-of-concept.

הפגיעות מאפשרת לתוקפים מרחוק וללא הזדהות להשיג הרצת קוד מרחוק ברמת root על שרתי N-central. היא משלבת פגיעות ב-Apache Axis (CVE-2026-90436, CVSS 9.8) עם חור לא מפורט שקיים כש-Legacy API מופעל. השרשרת עובדת גם מול שרתים שעודכנו ל-2026.4 HF2 (build 2026.4.1.26), שתיקן בעיות Able2Shell קודמות. החוקר שון ביילס (Sean Bales) פרסם גם פגיעויות Agent2Shell קשורות שמשפיעות על סוכני Windows מנוהלים.

N-able הגיבה בהגבלת Legacy API, אינטגרציית Intune ותכונות נוספות, ועובדת עם לקוחות על אינדיקטורים לחדירה.

מי מושפע

שרתי N-able N-central שמריצים builds עדכניים, כולל כאלה עם התיקונים השבועיים האחרונים, ובמיוחד פריסות שבהן Legacy API עדיין מופעל. גם נקודות קצה מנוהלות חשופות דרך פגיעויות הסוכן הקשורות.

MSPs וארגונים שמשתמשים ב-N-central לניטור וניהול מרחוק הם האוכלוסייה העיקרית; נגישות רשת ללא הזדהות לשרת הניהול מרחיבה מאוד את רדיוס הפגיעה.

למה זה חשוב

N-central היא פלטפורמת RMM נפוצה שמחזיקה גישה בעלת הרשאות גבוהות למספר גדול של נקודות קצה של לקוחות. RCE ברמת root ללא הזדהות על השרת, יחד עם ניצול מהיר בשטח של PoC ציבורי, יוצרים נתיב מיידי לחדירה המונית של סביבות מנוהלות.

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

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

השביתו או הגבילו מיד את Legacy API ואת האינטגרציות הקשורות אם אינם נדרשים. החילו כל הנחיית חירום או נעילת תכונות שפרסמה N-able, בודדו שרתי N-central מרשתות לא מהימנות, ונטרו IoCs וסריקות שפורסמו ל-4EverAble2Shell.

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

מה קרה

גורם איום לא ידוע מיקד שערי Check Point Security Gateways שלא עודכנו, השתמש בפגיעויות PHP2Shell לגישה ראשונית ואז בפגיעות הסלמת הרשאות מקומית ב-Gaia OS כדי להגיע ל-root ולפרוס את הדלת האחורית TSGA (עם רכיב TSProxy).

הפעילות החלה ב-30 באוקטובר 2026 נגד ארגונים ישראליים דרך פורטלי Mobile Access פגיעים, עם גל אופורטוניסטי רחב יותר ב-2 בנובמבר. PHP2Shell ממופה ל-CVE-2026-109618 ו-CVE-2026-109619 (שתיהן ב-CISA KEV ומאושרות כמנוצלות בפועל). אחרי גישה לפורטל, התוקפים ביצעו הסלמה דרך ממשק DynamicCLI, פרסו PHP web shells, ואז את TSGA (כ-slot_CPconfigdaemon). בחלק מהמקרים הם ביצעו pivot ב-SSH למארחי VMware ESXi, פרסו את ה-wiper בשם destroy_v6, והשאירו הודעות בעלות אופי פוליטי.

Check Point זיהתה ניצול של ה-LPE מול כמה עשרות לקוחות. ה-LPE תוארה כבעיית הרשאה חסרה שמאפשרת למשתמשים מקומיים מאומתים להריץ פקודות שרירותיות.

מי מושפע

Check Point Force Firewalls, Management and Log Servers, וריאנטים Multi-Domain, ו-Maestro Orchestrator בגרסאות R82.20, R82.10, R82, R81.20, R81.10 ו-R81 שנותרו ללא תיקון לפגיעויות PHP2Shell ובהן פורטלי Mobile Access חשופים.

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

למה זה חשוב

שערי אבטחה יושבים בקצה הרשת עם הרשאות גבוהות. שרשראות PHP2Shell + LPE מוצלחות נותנות לתוקפים root על המכשיר, דלתות אחוריות מתמשכות, ונקודת זינוק לתשתית פנימית כולל היפרוויזורים.

ניצול פעיל מאושר (CVEs ברשימת KEV), שימוש מהיר אחרי תיקון, התמדה באמצעות web shells, ושימוש סלקטיבי ב-wiper נגד ESXi הופכים את זה לאיום ריגול והרס גם יחד. ארגונים שמסתמכים על Check Point להגנת היקף חייבים להניח שפורטלים הפונים לאינטרנט הם יעדים בעלי ערך גבוה.

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

וודאו שכל מוצרי Check Point המושפעים מעודכנים מול CVEs של PHP2Shell (תיקונים היו זמינים בערך שבוע לפני הקמפיין שנצפה) ומול כל הנחיית LPE后续. השביתו או הגבילו היטב פורטלי Mobile Access ושירותים מיותרים אם אינם נדרשים.

נטרו IoCs שדווחו, פעילות חריגה ב-socket של DynamicCLI, web shells חדשים, תהליכים בשמות כמו slot_CPconfigdaemon, ו-pivots ב-SSH מהשערים. סגמנטציה לממשקי ניהול, אכפו אימות חזק, בצעו רוטציה לפרטי הזדהות אחרי כל חשד לגישה, וסקרו מארחי ESXi לאיתור ארטיפקטים של wiper או שינויים לא מורשים.

מה קרה

Kaspersky פרסמה את המאמר הראשון בסדרה שמסבירה איך עובדות בדיקות חדירה בענן, עם מיקוד בגבולות אמון ובבידוד דיירים בשלוש שכבות: External, Overlay ו-Underlay.

המאמר סוקר ארכיטקטורות נפוצות כמו OpenStack ו-Kubernetes, שרשראות תקיפה טיפוסיות, מודל התוקף, יעדי המחקר (הרצת קוד, גישה לנתונים ושליטה בתשתית) ודפוסי אירועים מהשטח. הוא משתמש באנלוגיה של מלון כדי להמחיש בידוד multi-tenant ואת הנקודות שבהן הגבולות עלולים לקרוס.

מי מושפע

ספקי ענן, מפעילי פלטפורמות, צוותי אבטחה בארגונים ובודקי חדירה שמעריכים או מגנים על סביבות IaaS/PaaS multi-tenant המבוססות על OpenStack, Kubernetes או מחסניות דומות.

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

למה זה חשוב

פריצות בענן נובעות לעתים קרובות מבידוד שבור או מגבולות אמון שגויים בקונפיגורציה, ולא מבריחות guest פשוטות. הבנת השכבות External (חשופה לאינטרנט), Overlay (רשת וירטואלית ובקרה של הדייר) ו-Underlay (תשתית פיזית/מארח) עוזרת למגינים לתעדף את הבקרות הנכונות ולבונים לתכנן בדיקות שתואמות מסלולי תקיפה אמיתיים.

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