ב-14 ביולי הוסיפה CISA את CVE-2026-56164, פגיעות ב-SharePoint Server שמאפשרת לתוקף לא מזוהה להסלים הרשאות ברשת, לרשימת הפגיעויות המנוצלות בפועל שלה (KEV), עם דדליין ל-17 ביולי לתיקון בגופים פדרליים אמריקאיים. זו לא פגיעות בודדת. היא השלישית השנה בשרשרת של חולשות SharePoint שמנוצלות באותו דפוס בדיוק, דפוס שהחל לפני שנה במה שהפך לאחת הקמפיינים הגדולות של 2025.

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

SharePoint Server המקומי (on-premises, בניגוד לגרסת הענן SharePoint Online) הוא בדיוק סוג המטרה שתוקפים אוהבים. הוא משמש כמאגר מסמכים מרכזי בארגונים גדולים, מחובר לרוב לתשתית האימות הפנימית של החברה (Active Directory), ולעיתים קרובות חשוף לאינטרנט כדי לאפשר גישה מרחוק לעובדים ולשותפים. שרת אחד שנפרץ יכול לשמש קרש קפיצה לכל הרשת הארגונית, ולכן הוא יעד קבוע אצל קבוצות ריגול וקבוצות כופרה כאחד.

מ-ToolShell ל-2026: אותה שרשרת חוזרת

ביולי 2025 ניצלה קבוצת תקיפה בשם Storm-2603 (המוכרת גם כ-GOLD SALEM) שרשרת פגיעויות ב-SharePoint שכונתה ToolShell (CVE-2025-49706, CVE-2025-49704 ועוד) כדי לפרוץ מאות שרתים ולפרוס עליהם כופרת Warlock. מיקרוסופט קישרה את הקמפיין לשלושה שחקנים סיניים, לינן טייפון (Linen Typhoon, פעילה מ-2012 בגניבת קניין רוחני מממשלות וארגוני ביטחון), ויולט טייפון (Violet Typhoon, מתמקדת בריגול נגד גורמי ממשל לשעבר וארגוני מחקר) וסטורם-2603 עצמה, שהצטרפה לניצול הפגיעויות להפצת כופרה. צ'ק פוינט תיעדה באותו גל מעל 4,600 ניסיונות פריצה ב-300 ארגונים, ומיקרוסופט דיווחה על יותר מ-400 קורבנות בסקטורים של ממשל, תוכנה, טלקום ופיננסים.

המנגנון הטכני של ToolShell היה פשוט להפליא. תוקף שולח בקשת POST זדונית לנקודת הקצה ToolPane.aspx, רכיב לגיטימי ב-SharePoint, ומצרף לה מטען מסודר (serialized payload) שמנצל פגיעות דה-סריאליזציה. השרת מפרש את המטען כפקודה ומריץ אותה בהרשאות תהליך ה-IIS שמריץ את SharePoint (w3wp.exe). התוצאה: קובץ בשם spinstall0.aspx נכתב לתיקיית האתר, ומשמש כ-web shell, דלת אחורית מבוססת דף אינטרנט שמאפשרת לתוקף להריץ פקודות נוספות דרך בקשות GET רגילות.

גניבת מפתח שהופכת תיקון לפתרון חלקי

החלק הקריטי ביותר בשרשרת אינו הפריצה עצמה אלא מה שקורה מיד אחריה. ה-web shell מיועד בעיקר לשלוף את מפתחות ה-machine key של ASP.NET, זוג מפתחות הצפנה (validationKey ו-decryptionKey) שהשרת משתמש בהם כדי לחתום ולהצפין את ה-ViewState ואת אסימוני האימות של המשתמשים. מי שמחזיק במפתחות האלה יכול לזייף אסימון אימות תקף לכל משתמש בשרת, גם בלי לדעת סיסמה, ולהריץ קוד מרחוק דרך דה-סריאליזציה של ViewState מזויף.

זו הסיבה שתיקון הפגיעות המקורית לא מספיק. אם התוקף כבר גנב את המפתחות לפני שהתיקון הותקן, הם עדיין תקפים אחרי ההתקנה, אלא אם מישהו מחליף אותם באופן יזום. מיקרוסופט עצמה ציינה זאת בהנחיות התיקון: לקוחות צריכים להחליף את מפתחות ה-ASP.NET machine key בשרת ה-SharePoint ולהפעיל מחדש את שירותי ה-IIS גם לאחר ההתקנה. כפי שניסח זאת חוקר אבטחה שעקב אחרי הגל הנוכחי, שרת שתוקן אך נפרץ קודם לכן נשאר שרת פרוץ.

מפריצה לכופרה תוך שעה וחצי

ברגע שיש לתוקף דריסת רגל ומפתחות גנובים, ההתקדמות מהירה. תיעוד של הקמפיין המקורי מראה רצף אופייני: קודם סיור באמצעות פקודת whoami לבדיקת הרשאות המשתמש, אז השבתת Windows Defender דרך שינוי ברישום שמופעל דרך services.exe, לאחר מכן שאיבת אישורים מזיכרון LSASS באמצעות הכלי Mimikatz, ותנועה רוחבית ברשת דרך PsExec וערכת הכלים Impacket. בשלב הסופי, סטורם-2603 משנה מדיניות קבוצתית (GPO) כדי להפיץ את כופרת Warlock לכל השרתים בדומיין. מתחילת הפריצה ועד להצפנת הקבצים חולפות לעיתים 60 עד 90 דקות בלבד, חלון זמן קצר מכדי שרוב צוותי האבטחה יספיקו להגיב בזמן אמת.

מיקרוסופט ציינה גם סיבוך נוסף בגל האחרון: בחלק מהרשתות שנפרצו זוהה שחקן שני, לא קשור לסטורם-2603, שפעל באותה סביבה במקביל תוך שימוש בטעינת DLL זדונית (DLL side-loading) ודלתות אחוריות ייעודיות משלו. שני שחקנים שונים המנצלים את אותה פגיעות באותו שרת מקשים מאוד על חקירת האירוע ועל קביעה מי אחראי למה, ולעיתים מובילים לכך שצוות התגובה מטפל בסימני פריצה של קבוצה אחת בזמן שהשנייה כבר יושבת עמוק יותר ברשת.

חמש פגיעויות בתוך חצי שנה

הגל של 2026 כולל עד כה חמש פגיעויות נפרדות ב-SharePoint, כשהמשותף לכולן הוא אותו טכניקה של ניצול נקודת קצה ותוכן מסודר לביצוע קוד. CVE-2026-32201, פגיעות התחזות (spoofing) עם ציון CVSS של 6.5, נוצלה כבר לפני שהתיקון פורסם באפריל ונכנסה ל-KEV באותו יום. CVE-2026-45659, פגיעות דה-סריאליזציה עם ציון 8.8 שדורשת רק הרשאות חבר אתר בסיסיות, תוקנה במאי ונכנסה ל-KEV ב-1 ביולי לאחר שהוכח ניצול פעיל שלה. CVE-2026-56164, נושא הכתבה הזו, מציגה מחלוקת ציון נדירה: NIST מדרגת אותה 9.8 (קריטי) בעוד מיקרוסופט עצמה, כבעלת ה-CVE, נתנה לה רק 5.3. הדוח שחשף אותה הוגש על ידי חוקרים מ-Mandiant Incident Response, Google Cloud ו-FLARE OTF יחד עם חוקר אנונימי נוסף.

שתי פגיעויות נוספות עדיין ללא תיקון מלא. CVE-2026-55040, שגילה סטיבן פיואר (Stephen Fewer) מ-Rapid7, היא עקיפת אימות באמצעות אסימוני JWT פגומים, החצי הראשון בשרשרת דו-שלבית שמובילה יחד עם פגיעות שנייה עדיין חסויה להרצת קוד מרחוק ללא אימות בכלל. הציון שלה עצמה שנוי במחלוקת בין 5.3 ל-Rapid7 ל-9.1 ל-ZDI, מחלוקת שמזכירה את זו סביב CVE-2026-56164. הפגיעות השנייה בשרשרת צפויה להתפרסם רק בעדכון האבטחה של אוגוסט 2026. CVE-2026-58644, שדווחה על ידי Cisco Talos, היא פגיעות דה-סריאליזציה עם ציון 9.8 שטרם נוצלה בפועל נכון לפרסום העדכון, אך חולקת בדיוק את אותו דפוס ניצול.

היקף החשיפה עדיין גבוה. חברת המעקב Shadowserver מזהה כמעט 10,000 שרתי SharePoint חשופים לאינטרנט, ומעל 800 מהם עדיין לא תוקנו נגד CVE-2026-32201 ו-CVE-2026-45659, פגיעויות שהתיקון להן זמין כבר חודשים.

הפיצול בין הציונים של CVE-2026-56164 ושל CVE-2026-55040 לא מקרי. שתיהן מוגדרות כפגיעות הסלמת הרשאות או עקיפת אימות, סוג שקשה להעריך אותו לפי הנוסחה הסטנדרטית של CVSS כי ההשפעה בפועל תלויה בהקשר הספציפי של כל התקנה. מיקרוסופט, שמכירה את הארכיטקטורה הפנימית, נוטה לצייר תמונה שמרנית יותר. NIST וחוקרים חיצוניים, שמסתכלים על מה שקורה בשטח, מדרגים לפי הפוטנציאל המקסימלי לניצול. התוצאה היא שארגונים שמתעדפים תיקונים לפי הציון בלבד עלולים לדחות בטעות פגיעות שכבר מנוצלת, ולכן הימצאות ברשימת ה-KEV של CISA אמורה לגבור על הציון המספרי בכל תהליך תעדוף.

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

עדכון SharePoint לגרסה המתוקנת נשאר הצעד הראשון וההכרחי, אבל הוא לא הצעד האחרון. כל ארגון שמריץ SharePoint מקומי (on-premises) חשוף לאינטרנט צריך להניח שמפתחות ה-machine key שלו עלולים כבר להיות בידי תוקף, ולכן להחליף אותם ולהפעיל מחדש את IIS גם בלי ראיה ישירה לפריצה. שווה גם לבדוק בלוגים אם תהליך w3wp.exe הפעיל כלים חשודים או אם נכתבו קבצי aspx לא מוכרים לתיקיות האתר, אלו הסימנים הקלאסיים לניצול השרשרת הזו.