ב-31 ביולי, מה שהגיע ל-N-able לא היה התראת פריצה. זה היה גל של שגיאות רישוי מלקוחות שמריצים את שרת הניהול אצלם, on-prem. מישהו במחלקת התמיכה משך בחוט, ובקצה השני חיכתה תמונה הרבה פחות שגרתית: תוקפים שכבר ישבו עם הרשאות מנהל על שרתי N-central של לקוחות, דרך חולשה שהחברה הייתה בטוחה שסגרה חודשיים קודם.

החולשה המקורית, CVE-2026-18556, תוקנה בגרסה 2026.2. אלא שהתיקון לא סגר את כל הדלתות. התוקפים מצאו נתיב חלופי שמוביל לאותה עקיפת אימות בדיוק, וזו קיבלה מספר משלה, CVE-2026-18577, עם ציון CVSS 8.2. N-able הוציאה תיקון חירום, גרסה 2026.3.1.7, באותו יום שבו אישרה שהחולשה מנוצלת בשטח, ה-2 באוגוסט. בהמשך נראה מה בדיוק דלף מהתיקון הראשון, מה התוקפים עשו אחרי שנכנסו, ולמה שדרוג של השרת לבדו לא מספיק כדי לגרש אותם.

מה זה N-central, ולמה שרת אחד שווה מאות רשתות

N-central הוא כלי RMM (ראשי תיבות של Remote Monitoring and Management), פלטפורמה שספקי שירות מנוהל, מה שנקרא בענף MSP, מפעילים כדי לנטר, לעדכן ולהתחבר מרחוק לשרתים ולתחנות של כל הלקוחות שלהם ממקום אחד. אצל MSP טיפוסי, קונסולת N-central אחת מנהלת עשרות לקוחות ואלפי מכשירים. זה בדיוק מה שהופך אותה למטרה כל כך שווה: מי ששולט בקונסולה לא שולט במחשב בודד, אלא בכל צי ה-endpoint-ים של כל הלקוחות שתלויים באותו שרת.

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

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

הדלת שהתיקון הראשון השאיר פתוחה

עקיפת אימות (authentication bypass) נשמעת כמו מונח מאיים, אבל הרעיון פשוט: יש בדיקה שאמורה לוודא שאתם מי שאתם טוענים שאתם, ומצאו דרך להגיע למה שמאחוריה בלי לעבור אותה. החולשה המקורית אפשרה בדיוק את זה, השתלטות על חשבון מנהל בלי פרטי אימות תקינים. N-able תיקנה אותה בגרסה 2026.2, וזה היה אמור להיות סוף הסיפור.

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

הסימן הראשון לא היה בכלל אבטחתי. ב-31 ביולי החברה ראתה עלייה בשגיאות רישוי אצל לקוחות שמריצים את השרת אצלם, תופעת לוואי של מה שהתוקפים חוללו על המכונות. רק ב-2 באוגוסט היא אישרה שמדובר בניצול פעיל של CVE-2026-18577, ובאותו אחר צהריים שחררה את התיקון. לפי SecurityWeek, הניצול בשטח החל עוד בסוף יולי, כלומר עוד לפני שמישהו ידע שיש בכלל דלת שנייה.

איך התוקפים נשארים גם אחרי שמגרשים אותם

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

אחרי שהשיגו הרשאות מנהל, הם השתמשו ב-Take Control, הפיצ'ר המובנה של N-central לשליטה מרחוק, כדי להתחבר אל ה-endpoint-ים המנוהלים עצמם. על כל מכשיר כזה הם רשמו service חדש: מנהרת Cloudflare Tunnel.

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

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

מה בדיוק ראו החוקרים

עד כמה זה נפוץ? כאן הדיווחים נזהרים. N-able מסרה שרק "מספר מצומצם של לקוחות זוהו כמושפעים", בלי לנקוב במספר. Huntress, שצופה בטלמטריה של הלקוחות שלה, תיעדה מופע ספציפי אחד של N-central בהתקנה עצמאית שממנו נפגעו תשעה ארגונים, endpoint אחד בכל אחד. הפעילות שנצפתה שם הייתה מדודה: התוקפים ספרו את התהליכים שרצים על התחנה ואז התנתקו, מה שמרמז יותר על סיור מקדים מאשר על מתקפה שכבר הבשילה.

שש כתובות IP תוקפות פורסמו כסימני זיהוי (IOC), וחוקרי Huntress זיהו שלפחות ארבע מהן הן צמתי יציאה של שירותי VPN מסחריים, Mullvad ו-NordVPN, שכבת הסתרה זולה וזמינה. לצד הכתובות פורסמו גם שלושה דומיינים ששימשו את התוקפים, ביניהם mousears.synology.me. מי שמריץ N-central יכול לחפש בלוגים של הגישה מרחוק חיבורים מהכתובות האלה, ולסרוק בתחנות את תיקיית הלוגים C:\ProgramData\GetSupportService_N-Central\Logs\ אחר סשנים חשודים. אזהרה של Huntress מ-3 באוגוסט ציינה שחלק גדול מהארגונים עדיין לא התקינו את התיקון, כלומר החלון עדיין פתוח.

למה זה קמפיין נגד השרשרת, לא נגד לקוח בודד

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

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

מה זה אומר בפועל

מי שמפעיל N-central צריך לעשות שני דברים נפרדים, ולא להתבלבל ביניהם. הראשון: לשדרג מיד ל-2026.3.1.7, לאכוף אימות דו-שלבי על כל חשבונות הקונסולה, ולהגביל את הגישה אליה מאחורי firewall או VPN במקום לחשוף אותה לאינטרנט הפתוח. השני, והחשוב לא פחות: לצוד באופן יזום מנהרות Cloudflare לא מוכרות שנרשמו כ-service על התחנות המנוהלות. השדרוג סוגר את הדלת שדרכה נכנסו, אבל הוא לא מפנה את מי שכבר הספיק להתמקם בצד השני שלה.