חקירת מתקפת כופרה מתחילה בשאלה פשוטה: מאיזו מכונה יצאו הפקודות. בחקירה שפירסמה חברת Bitdefender ב‑ 3 בנובמבר 2026 התשובה נמצאה מהר, אך היא גם זו שחוסמת כל שאלה אחרת. הפקודות יצאו ממכונה פנימית אחת באשכול בתי ספר בבריטניה, מכונה שלא נוהלה ולא הורץ עליה סוכן האבטחה של Bitdefender, כלומר מכונה שישבה מחוץ לטלמטריה של מי שחקר את האירוע. כל פעולה של התוקף שהחוקרים ראו יצאה משם. המכונה הזו מילאה שלושה תפקידים בבת אחת. היא הייתה נקודת המוצא לתנועה, היא קלטה את הקבצים שנאספו מהארגון, עליה רץ העמוד שקיבל אותם בפועל – ערוץ הפיקוד והשליטה של התוקף. ממנה הושגה גישה לכ‑ 50 מכונות, מתוכן כ‑ 37 הוצפנו בבוקר 19 בספטמבר.
מכאן גם הגבול של המחקר. מכיוון שאותה מכונה לא הייתה מנוהלת, המידע עליה פשוט אינו קיים: אין דרך לקבוע איזה מודל שפה הופעל, אם הופעל מרחוק או מקומית, או אם בכלל רץ שם לופ אוטומטי במקום אדם שהעתיק הוראות ותוצאות הלוך ושוב מול חלון צ'אט. הפער הזה אינו מסביר כיצד המתקפה הצליחה, שכן דרך הכניסה הראשונית נותרה בלתי ידועה. מה שהוא כן עושה הוא להסתיר מהחוקרים את התשובה לשאלה שהפכה את האירוע הזה לראוי לדיווח מלכתחילה.
את החדירה מייחסים החוקרים לשלוחה של קבוצת הכופרה 3AM, המכונה גם ThreeAM. הייחוס הזה מאושר לדבריהם. הקבוצה עובדת במודל של כופרה כשירות: גרעין שמפתח את המצפין ומחכיר אותו למבצעים חיצוניים שמתחלקים איתו בתמורה. מעקב ציבורי מתאר אותה כמי שנראתה לראשונה בפברואר 2023.
הסביבה שהותקפה מנתה 47 מערכות. 21 מהן בקירוב היו שרתים, שמונה מהם בקרי דומיין – אותם שרתים שמנהלים את ספר החשבונות של הארגון ומכריעים מי מצליח להתחבר ולאן. עשר עמדות עבודה המשיכו לרוץ על Windows 10 אחרי שהגרסה יצאה מתמיכה באוקטובר 2025, בקר דומיין אחד רץ על Windows Server 2012 R2, השאר על Windows 11. במקור נבנתה הסביבה כמה דומיינים נפרדים של Active Directory, בלי חיבור ביניהם.
הפעילות שתועדה נמשכה בין 10 ל‑ 19 בספטמבר. לפניה מופיעים בטלמטריה שני אירועים שהחוקרים בחרו לציין בלי לקבוע לגביהם דבר: הפעלת מצב Restricted Admin על ארבע מכונות ב‑ 23 בינואר 2026, לצד מושב עבודה אינטראקטיבי שהוקלד בידי אדם ב‑ 5 ביוני 2026. זיקתם לאירוע של ספטמבר אינה מאושרת.
לתוקף דרושים ארבעה דברים כדי להגיע מהמכונה הזו אל 37 מכונות מוצפנות: אישורי התחברות, טווח, שקט ועיוורון של המגננה. שלושה מהם סופקו לו בידי הסביבה עצמה. את השקט הוא לא קיבל. הוא גם לא ניסה במיוחד.
האישורים: שרת הגיבוי כספת סיסמאות
הפעולה הראשונה שתועדה בספטמבר לא הייתה הצפנה ולא פריצה, אלא שאילתה. בין 10 ל‑ 11 בספטמבר רצה על שלושה שרתי גיבוי גרסה מותאמת של כלי ציבורי בשם Veeam-Get-Creds.ps1. הכלי שולף את אישורי ההתחברות שתוכנת הגיבוי שומרת במסד הנתונים שלה. אחר כך הוא פותח אותם בעזרת DPAPI.
שווה לעצור על המנגנון הזה, מכיוון שבו נעוץ כל ההמשך. DPAPI הוא השירות של Windows שמאפשר לתוכנה לאחסן סיסמה בלי לכתוב אותה בטקסט גלוי: המערכת מצפינה אותה בצורה שנפתחת רק בהקשר של החשבון שיצר אותה ורק על אותה מכונה. ההיגיון הזה מגן מפני מי שמעתיק את מסד הנתונים לעצמו, אך הוא אינו מגן על כלום מפני מי שכבר מריץ קוד על השרת עצמו ובהקשר הנכון. מי שהגיע לשרת הגיבוי אינו צריך לשבור הצפנה. הוא צריך לבקש מהמערכת לפתוח אותה בשבילו.
ההתאמה שהתוקף עשה בכלי הציבורי מלמדת משהו נוסף. הגרסה הפתוחה מאתרת לבדה את שם שרת מסד הנתונים, את שם המופע ואת שם המסד מתוך הרגיסטרי. בגרסה שרצה כאן שלושת הערכים האלו הוקשו ישירות בקוד, כלומר מי שכתב אותה ידע מראש בדיוק לאיזו התקנה הוא פונה. שאר הסקריפט נותר כשהיה.
ההרצה הגיעה בשיטה שמותירה חתימה מוכרת. התוקף השתמש בכלי הרצה מרוחקת מסוג Impacket – ערכת קוד פתוח שמריצה פקודות על מכונות Windows דרך הערוצים שהמערכת עצמה חושפת. הפקודה הראשונה נשלחה דרך WMI, שתי הבאות נרשמו כשירות עם services.exe כתהליך האב, שזו ההתנהגות של מודולי ההרצה שמבוססים על שירות. מאותה סדרה הועתק גם קובץ Login Data של Chrome, זה שמחזיק את הסיסמאות השמורות בדפדפן, משרת טרמינל שמשרת משתמשים רבים.
כאן מתברר מה בדיוק הושג. שרת הגיבוי אינו רק המקום שממנו משחזרים, הינו גם ריכוז של זהויות: כדי לגבות שרת צריך להתחבר אליו, לפיכך אם תוכנת הגיבוי מחזיקה אישורים לשרתים שהיא מגבה, מי שקורא את המסד שלה מקבל מפת כניסה מוכנה. החוקרים מנסחים את התובנה הזו מהכיוון של התכנון: רוב תכניות הגיבוי נבנות מול תקלה ולא מול כוונת זדון. הם גם מצביעים על כך שהתוקף נגע בשכבת הגיבוי פעמיים, בשני הקצוות של האירוע – גניבת אישורים בפתיחה, מחיקת גיבויי מצב מערכת תחת ההצפנה.
איסוף הזהויות נמשך ב‑ 14 בספטמבר. מתוך בקר הדומיין שרץ על 2012 R2 נשמרו עם reg save מפתחות הרגיסטרי SECURITY ו‑ SYSTEM, שמכילים תמציות סיסמאות וסודות מערכת. פרט קטן באותו רצף הוא עדות מקדימה לכל מה שיבוא אחר כך: אותה פקודת שמירה בדיוק הורצה שוב 40 שניות לאחר מכן, בתוספת הפניית שגיאות אחת. מי שהריץ אותה לא ראה את הפלט שציפה לו, אז שינה דבר אחד קטן.
בהמשך אותו יום הורץ Mimikatz, כלי חילוץ אישורים מוכר, תחת השם sysmon64.exe כדי להיראות כבינארי ניטור שגרתי. בחקירה הוא נמצא גם כ‑ svcstat.exe, כשני קבצי .tmp.exe בשמות מקריים וכעותק שהושתל בתיקיית יישום בשם buzzypdf. בוצע ניסיון לשלוף את תוכן הזיכרון של LSASS, התהליך שמחזיק את האישורים של המשתמשים המחוברים כרגע. תוצאת הניסיון אינה ידועה. צוות הפורנזיקה ראה גם שליפה של מפתחות SAM ו‑ SECURITY ממכונה אחרת ברשת, דרך הצינור הייעודי שמשמש לגישה מרוחקת לרגיסטרי.
הטווח: חשבון בכל דומיין, אחר כך חיבור רשמי
ההפרדה בין הדומיינים הייתה הגבול המבני היחיד בסביבה הזו, זה שהתוקף טיפל בו בשיטתיות. הנקודה שראוי לשים אליה לב היא שהוא לא שבר אותו.
בשלב הזה כבר היו בידיו האישורים משרתי הגיבוי. באמצעותם נוצרו שני חשבונות מנהל דומיין משלו, בשתי דרכים נפרדות. הראשון, library, נוצר ב‑ 14 בספטמבר ב‑ 19:06 מתוך ההקשר של עבודת הגיבוי של מערכת ניהול בית הספר. השני, svc_bkpmon, נוצר חמש שעות אחר כך, ב‑ 00:03 בשעון 15 בספטמבר, דרך WinRM. הכפילות הזו אינה בזבוז אלא ביטוח: שתי דרכי חזרה שאינן תלויות זו בזו. שני השמות נבחרו כך שלא יבלטו ברשימת החשבונות של מוסד חינוכי.
ההכנה לחיבור נעשתה ב‑ 13 בספטמבר. מתוך בקר דומיין נמנו יחסי האמון שהיו קיימים. במקביל נסרקה SYSVOL. זו תיקייה שבקרי הדומיין משתפים אוטומטית ומשמשת להפצת סקריפטים ומדיניות למשתמשים. שתי תכונות שלה חשובות כאן: הקריאה בה פתוחה לכל חשבון בדומיין; מעבר לכך היא מכילה בדרך כלל סקריפטים שנכתבו לפי המיפוי האמיתי של הארגון. התוקף חיפש בה שמות ותחומי כתובות של בתי ספר אחרים באשכול. סריקה כזו אינה סריקה גנרית של סביבה, היא סריקה של מי שיודע באיזה סוג ארגון הוא נמצא.
החיבור עצמו נבנה ב‑ 18 בספטמבר, בחלון שבין 15:39 ל‑ 18:37 בשעון UTC. לפני שניתן לבנות יחס אמון בין שני דומיינים הם צריכים להצליח לאתר זה את זה, לפיכך הפקודה הראשונה הגדירה הפניה מותנית ב‑ DNS, כלל שמעביר שאילתות על השם של הדומיין האחר אל שרתי השמות שלו. אחר כך נבנה יחס האמון הדו‑כיווני בין שלושה דומיינים, בעזרת שני כלים שמגיעים עם המערכת. הבנייה בוצעה בשני חצאים נפרדים, ב‑ 16:09 מצד אחד וב‑ 16:16 מהצד השני.
הנתון שחשוב לכל מי שמנהל יותר מדומיין אחד נמצא בשורת הפקודה עצמה: פקודות בניית האמון הזדהו בשם library בשלושה דומיינים שונים, בשם svc_bkpmon בלפחות אחד. כלומר החשבונות היו קיימים בכל אותם דומיינים עוד לפני שהאמון נבנה. זה מה שאיפשר לבנות אותו, שכן יצירת יחס אמון דורשת הרשאות מנהל בכל אחד מהצדדים. מקור הכוח לא היה יחס האמון אלא האישורים שנשלפו משרתי הגיבוי. יחס האמון רק הרחיב את הטווח שבו אפשר להשתמש בהם.
יחס אמון מאפשר לחשבון להזדהות בדומיין אחר, אך הוא אינו מחלק הרשאות. לכן נדרש שלב נוסף: מ‑ 16:36 הופץ דרך משימות מתוזמנות סקריפט בשם grant_lib.ps1 אל כ‑ 40 מכונות, בפער של 3 עד 50 שניות ביניהן, כדי להעניק לחשבון האחורי גישה בכל מקום. מכונות שלא נענו בסבב הראשון טופלו שוב ב‑ 17:07 וב‑ 17:22.
סביב דחיפת הגישה רצו ארבע בדיקות אבחון. שלוש מהן, בשמות diag_member, diag_nl ו‑ lmhosts_test, רצו בין 16:26 ל‑ 16:31, לפני הדחיפה. הרביעית, wb_probe, רצה ב‑ 17:23 ואימתה את יחס האמון בשני הכיוונים בין שניים מהדומיינים. ב‑ 18:36 הופעל מחדש Netlogon, השירות שמתחזק את התקשורת המאובטחת בין דומיינים. תוכן הסקריפטים האלו לא הגיע לידי החוקרים, לפיכך אין דרך לדעת מה הבדיקות החזירו או אם הניסיון הראשון לבנות את האמון הצליח בכלל. ההצפנה שחצתה בפועל בין דומיינים מלמדת שהאמון עבד, אך החוקרים מתייחסים לכך כאינדיקציה ולא כהוכחה.
ב‑ 15 בספטמבר נאסף גם המידע עצמו, במסלול חריג. ניסיון שני להגיע לאישורי תוכנת הגיבוי רץ דרך ממשקי הניהול המרוחקים של Windows, כשהוא מחזיר את תוצאותיו לא ברשת אלא דרך הרגיסטרי של המכונה המרוחקת, תחת HKLM\SOFTWARE\VC31. תוצאת הניסיון הזה אינה ידועה. באותה שיטה רוכזו 40 קבצים משיתוף של מחלקת הכספים, שנבחרו לפי סיומת ולפי גודל של פחות מ‑ 700 קילובייט, אחר כך הוזרקו כערכים בתוך הרגיסטרי. במקביל, לא בהמשכו, רצו מסלולי העתקה אחרים: ב‑ 05:19 הועתקו קבצים עם robocopy אל המכונה הלא מנוהלת בשם החשבון library. ב‑ 05:24 הועתקו קבצים אל SYSVOL של דומיין אחר בשם החשבון svc_bkpmon. ב‑ 05:27 נדחס ארכיון – ישירות משיתוף הכספים ומתיקיית הפלט, לא מהעתקים שכבר נוצרו – ונשלח בבקשת HTTP POST אל העמוד rcv.aspx. הודעות מצב קצרות המשיכו להישלח לאותו עמוד. החוקרים מסמנים את השימוש ברגיסטרי כאפיק העברה כבחירה חריגה ששווה לחפש אותה באופן יזום. ראוי גם לשים לב להיכן המידע הגיע: כל יעד מתועד נמצא בתוך הארגון, בראשם אותה מכונה לא מנוהלת. לפי הפקודות שתועדו, מי שמביט על גבול הרשת בלבד לא היה רואה תנועה יוצאת.
ב‑ 19 בספטמבר נסגר המעגל. ניסיון להסיר את הגנת הקצה רץ בשרת הקבצים ב‑ 00:27 כ‑ av_remove.ps1, שוב ב‑ 00:34 כ‑ av_remove2.ps1. גרסה שלישית, av_remove3.ps1, מוכרת מתמצית הגיבוב שלה ואינה מופיעה ביומן הפקודות כלל, כך שהורצו שתי גרסאות ולא שלוש. הסקריפטים כוונו אל Sophos ואל Bitdefender. מנגנוני ההגנה מפני שינוי חסמו את ההסרה. במקביל פותח על עמדת עבודה אחת טוען סקריפטים, דרך גרסאות שנשמרו זו לצד זו, כאשר רק הפריסה שלו הייתה מכנית: הוא הופץ לכ‑ 40 מכונות בקבצים בשמות מקריים, בסדר קבוע, בקצב של כ‑ 101 שניות למכונה ובחזרה של בערך פעם בשעתיים. מצפין הכופרה של ThreeAM, קובץ בשם host.exe, רץ בין 05:07 ל‑ 05:33 בקצב של 12 עד 13 שניות למכונה. תחת ההצפנה נמחקו גיבויי מצב המערכת.
השקט שלא היה: מה מעיד על מודל שפה ומה אינו מעיד
כאן מגיע החלק שבגללו האירוע הזה פורסם, כאן גם נדרשת הזהירות הרבה ביותר. נוח להתחיל דווקא מהצד שנוטה ליפול מהדיווחים, כלומר מהראיות שמצביעות לכיוון ההפוך.
המצפין הינו בינארי מסחרי שגרתי. הכלים כולם ציבוריים וזמינים. בשום מטען שנכתב במיוחד לאירוע הזה ושהחוקרים הצליחו לקרוא אין הערות בשפה טבעית, אין תיעוד פנימי ואין טקסט שמסביר את עצמו – והיעדר הזה נושא משקל, מכיוון שבמקרה JadePuffer דווקא הערות כאלו היו אחד מעמודי הראיות. אף מחזור החלטה בשלב העבודה הידנית לא רץ מהר יותר מ‑ 40 עד 60 שניות בקירוב. הקטעים שכן נראים מהירים, כ‑ 101 שניות למכונה בהפצת הטוען ו‑ 12 עד 13 שניות למכונה בהצפנה, הם פריסה דרך משימות מתוזמנות: תור שרץ מראש, לא סדרת החלטות. אפילו שגיאת כתיב בודדת שנמצאה ביומן, wevutil במקום wevtutil, אינה מלמדת דבר לשום כיוון, כך שהחוקרים נמנעים מלהסיק ממנה.
מה כן נמצא. הראיה החזקה ביותר אינה בקצב ואינה בכלים, היא באופי השגיאות. מדובר בשגיאות של מי שכותב מתוך היכרות כללית עם הכלי במקום מתוך התיעוד שלו. הדוגמה הנקייה ביותר היא פנייה לממשק הווב של תוכנת הגיבוי: הפנייה הופנתה לפורט 9392 עם אימות HTTP Basic, אל הנתיב הנכון של האישורים, בשעה שהתיעוד של Veeam מראה פורט 9419 ואימות שדורש אסימון OAuth2. הנתיב נכון, הפורט ושיטת האימות שייכים למקום אחר. החוקרים מוסיפים שלא ניתן היה לאמת אם המשאב הזה מחזיר סיסמאות בכלל.
הדוגמה השנייה מכנית יותר. פקודה שנועדה לשלוף את זיכרון LSASS הפעילה לולאה על פלט של tasklist בפורמט CSV, ביקשה ממנה את השדה השני – בלי לציין שהפסיק הוא התו שמפריד בין שדות. ברירת המחדל מפרידה ברווחים, לפיכך הפקודה קיבלה פיסת טקסט מאמצע מספר, אז העבירה אותה הלאה במקום שבו הייתה אמורה לעמוד זהות התהליך. פקודה כזו נראית תקינה לגמרי בקריאה, נכשלת מיד בהרצה.
לכך מצטרף הרגל אחד ועוד סימן חלש. ההרגל הוא רצפי בריחה בסגנון Bash שהופיעו בתוך פקודות PowerShell במרכאות כפולות, בשלושה תאריכים נפרדים – 14, 15 ו‑ 19 בספטמבר. חזרה בשלושה מועדים שונים אינה פליטת קולמוס. הסימן החלש הוא שלוש פקודות שהשתמשו בתחביר של מערכות Unix להשלכת פלט שגיאה, בתוך שורות פקודה של Windows. שלושתן התרכזו בחלון של 51 דקות ב‑ 13 בספטמבר ולא חזרו אחר כך. החוקרים מציינים במפורש שלבדו זה סימן חלש.
סגנון העבודה מוסיף שכבה. כל צעד נבדק לפני שסמכו עליו: מחרוזות בדיקה וקבצי אישור בשמות כמו test123, TASK-OK, psexec-ok, da_proof.txt ו‑ wmi_test.txt, לצד משימה מתוזמנת שנוצרה אך ורק כדי לבדוק אם אפשר ליצור משימה מתוזמנת. סקריפט אחד ניהל לעצמו יומן התקדמות ממוספר. פלט ההתקדמות והאזהרות הושתק, במקומו נוספו מפרידים שמכריזים על כל חלק בתשובה, כך שמה שחוזר הוא טקסט קצר ומסודר. גרסאות ממוספרות של אותה מטלה חוזרות לאורך כל האירוע. כאשר גרסה לא עבדה נוצר קובץ חדש במספר הבא ולא תיקון של הקודם. תמציות גיבוב מגלות שהיו גרסאות נוספות שלא נתפסו ביומן הפקודות בכלל. שתי גרסאות שונות של אותו סקריפט הופצו באותו שם. החוקרים מדגישים ששתי הקריאות אפשריות כאן: גם מודל שמתקן את הפלט של עצמו וגם אדם שמשכתב ביד. מה שמצטרף לצד המודל הוא הפרט הצורני, שכן לופ שמייצר טקסט חדש בכל סבב מייצר גם קובץ חדש בכל סבב.
הקצב הוא העדות ההתנהגותית המרכזית. דווקא עליו החוקרים נזהרים יותר מכל. ברצף אחד על בקר דומיין ב‑ 13 בספטמבר רצה פקודה ב‑ 02:50:18, רצה שוב ללא שינוי של תו אחד 41 שניות אחר כך, שונתה בקריאה אחת בלבד 49 שניות מאוחר יותר. כעבור 47 שניות נוספות הוחלפה כליל לטובת wmic – הכלי הוותיק שמבצע את אותה מטרה משורת הפקודה. זה שכתוב מלא שהגיע באותו פרק זמן שבו הגיעו קודם שינויים זעירים. בתשעה ניסיונות חזרה הפער נע בין 40 ל‑ 101 שניות, בלי קשר לגודל השינוי, בעוד שמעבר למטלה חדשה ארך דקות: באותו יום הפערים בין מטלות היו 5, 2, 14, 16 ו‑ 3 דקות.
הפירוש המתבקש הוא חלוקת עבודה, אדם שבוחר את הצעד הבא ומודל שמטפל בניסיונות החזרה. הפירוש הזה אינו הממצא היחיד שמתיישב עם הנתונים, כפי שהחוקרים מציינים במפורש: גם מודל שפשוט מתכנן מטלה חדשה לאט יותר היה מייצר את אותה תמונה. אין בטלמטריה דבר ששולל אחת מהקריאות. נוסף על כך היומן מכיל רק אירועים שזוהו, לפיכך ייתכן שחסרים ניסיונות וכל פער הוא גבול עליון ולא מדידה.
מדידה אחת עדיין מחדדת. על פני 60 צעדים נפרדים של עבודה ידנית אורך הפקודות נחלק לשתי קבוצות ברורות. ב‑ 13 וב‑ 15 בספטמבר הפקודות ארוכות, חציון של 365 עד 493 תווים, כשכל פקודה אורזת בתוכה סיור וטיפול בשגיאות. ב‑ 12 וב‑ 14 בספטמבר הן קצרות, 46 עד 86 תווים, כלי אחד בכל פקודה. על אותה מטלה בדיוק, גילוי דומיינים, החציון היה 683 תווים ביום אחד מול 80 ביום אחר. מכאן עולה שהיו שני סגנונות כתיבה, אך לא בהכרח שני כותבים: שגיאות מהסוג שתואר למעלה מופיעות בשתי הקבוצות.
על בסיס כל זה מפרידים החוקרים בין שלוש טענות שונות לחלוטין, שנוטות להתמזג בדיווחים על כופרה מבוססת AI. שמודל שפה חיבר את הפקודות – טענה שתוכן הפקודות תומך בה היטב. לופ אוטומטי (agentic loop), כלומר תוכנה שמחזירה למודל את הפלט של כל פקודה ומריצה את מה שחוזר, הוא שבחר כל פעולה הבאה – כאן ההתנהגות מתאימה, אך אדם שמעביר פלט ידנית מול חלון צ'אט מפיק אותו דפוס בדיוק, לפיכך המכניזם נשאר פתוח. הטענה השלישית, שלא היה אדם מעורב בשלב ההרצה, אינה נתמכת כלל. אין בטלמטריה דבר שנוגע בשאלה. הקריאה ההיברידית, מציינים החוקרים, הינה מודל עבודה שראוי להיערך מולו ולא עובדה מבוססת. הכתבה ב‑ Dark Reading מוסיפה הערה ביקורתית משלה: הדוח אינו מראה יכולת שה‑ AI איפשר לתוקף ושלא הייתה לו ממילא.
רועש ואיטי: מה נגזר מכאן להגנה
המסקנה המעשית של המחקר הופכת את ההנחה הנפוצה. מרטין זוגץ', מנהל פתרונות טכניים ב‑ Bitdefender, ניסח אותה ל‑ Dark Reading: "לופ אג'נטי אינו הופך מתקפה לשקטה, הוא הופך אותה לחזרתית: אותה פקודה מורצת מחדש, שינויים קטנים, סקריפטים ממוספרים וקבצי בדיקה שנשארים על הדיסק. אפילו ניסיונות החזרה המהירים ביותר ארכו 40 שניות ויותר. 'מהירות מכונה' היא בעיקר מושג שיווקי שמתאר אירועים יקרים מאוד; במתקפות אמיתיות, בעיקר עם מודלים מקומיים, אנחנו מצפים לתבנית איטית ורועשת יותר. המהירות אינה הסימן המזהה, החזרתיות היא".
את ההיגיון הכלכלי הוא ניסח, גם זאת ל‑ Dark Reading, בשורה אחת: "מודל היברידי הינו סביר יותר עבור עבריינים ממונעי כסף, טכנית וכלכלית, ממתקפה אוטונומית לחלוטין". החוקרים מעריכים שמתקפות היברידיות כאלו יהיו נפוצות יותר ב‑ 2027.
מידת הפרופורציה מגיעה מהחוקרים עצמם. לדבריהם זהו מקרה אחד, אנקדוטה ולא מגמה, בעוד שרוב החקירות שהם מבצעים בשטח נראות עדיין כפי שנראו לפני מודלי השפה. נוזקה שנכתבה כולה בידי מודל מהווה כ‑ 0.07 אחוז מדגימות הנוזקות שהם אוספים בכל חודש. על המתקפה הזו הם כותבים שלא הייתה מהירה, שלא הייתה חדשנית בשום מובן, שלא נדרשו לה מיומנות או הוצאה שלא היו בידי התוקפים ממילא.
הנחיית ההגנה שהם גוזרים מכך נושאת כותרת משלהם, "למנוע ולא להתחרות". בגוף הדברים: "זיהוי שתלוי בכך שיבחין במספר מספיק של אירועים במהירות מספקת מפסיד למשהו שמנסה שוב בכל דקה… עדיף לבחור בקרות שעובדות ללא תלות בנפח ובקצב, מכיוון שהן עוצרות פעולה בפעם הראשונה ובפעם המאה".
ההקשר הרחב מצטרף לאותו כיוון. בניתוח קודם של החברה על כ‑ 700 אלף אירועי אבטחה, 84 אחוז מהמתקפות בחומרה גבוהה כללו שימוש בכלים שמגיעים עם מערכת ההפעלה. ארבעה מתוך חמשת הכלים שנוצלו הכי הרבה באותו ניתוח מופיעים גם בחדירה הזו.
הסיכון האמיתי לארגון שלכם
ארבעה דברים באירוע הזה אינם תלויים בשאלה אם מודל שפה היה שם, כולם רלוונטיים לארגון ישראלי בינוני אשר מנהל יותר מרשת אחת.
ראשית, שרת הגיבוי הינו נכס זהות ולא רק נכס שחזור. אם תוכנת הגיבוי שלכם מחזיקה אישורי התחברות לשרתים שהיא מגבה, קריאה אחת של המסד שלה מספקת לתוקף מפת כניסה לסביבה. באירוע הזה כך נפתחה כל שרשרת ההרשאות: שלושה שרתי גיבוי נקראו בפתיחה, גיבויי מצב מערכת נמחקו בסיום. שתי הפעולות נגעו באותה שכבה שתוכנית גיבוי רגילה אינה מתכננת מולה.
שנית, ההפרדה בין דומיינים מהווה גבול רק כל זמן שאין חשבון אחד שמחזיק הרשאות בכולם. התבנית שראוי לבחון בישראל היא זו של ספק IT חיצוני או אינטגרטור שמנהל כמה סביבות ומחזיק חשבון מנהל יחיד שעובד בכולן, כמו גם של קבוצה שגדלה דרך רכישות או של רשת מוסדות שכל אחד מהם הוקם בנפרד. באירוע הזה התוקף לא פרץ את הגבול בין הדומיינים, אלא יצר לעצמו חשבון בכל אחד מהם ואחר כך חיבר אותם רשמית. בניית יחס אמון דורשת הרשאות מנהל בכל צד, לפיכך השרשרת האמיתית התחילה באישורים שנשלפו משרתי הגיבוי.
שלישית, מכונה שאינה מנוהלת אינה פער בכיסוי, היא בסיס פעולה. מכונה אחת כזו מספיקה. היא נוצרת בדרכים מוכרות: שרת קבצים ותיק שאין לו בעלים, עמדת בדיקות, מכונה של קבלן חיצוני או ציוד שחובר לרשת בלי לעבור בתהליך. באירוע הזה המכונה הזו החזיקה את המידע שנאסף, הריצה את ערוץ הפיקוד והשליטה ושימשה נקודת מוצא לכל פעולה שהחוקרים ראו.
רביעית, מערכות שיצאו מתמיכה אינן חוב תיאורטי. בסביבה הזו רצו עשר עמדות על Windows 10 אחרי אוקטובר 2025. מתוך בקר הדומיין שרץ על 2012 R2 נשמרו מפתחות הרגיסטרי שמחזיקים תמציות סיסמאות. ראוי לומר במדויק מה הדוח כן קובע ומה לא: שמירת המפתחות האלו דורשת הרשאות מנהל ועובדת באותה צורה על כל גרסת Windows. אין בדוח קשר בין גיל המערכת לאופן שבו הדבר נעשה. דרך הכניסה הראשונית נותרה בלתי ידועה, לפיכך אין לטעון שמערכת לא מעודכנת הייתה הפתח לאירוע.
לסקטור יש משקל משלו. הסריקה בתוך SYSVOL חיפשה שמות ותחומי כתובות של בתי ספר אחרים. שמות החשבונות האחוריים נבחרו כדי להיראות טבעיים ברשימת חשבונות של מוסד חינוכי. מוסדות חינוך מחזיקים מידע על קטינים. בישראל הנושא אינו תיאורטי: ב‑ 12 באוקטובר פורסם כאן מבזק על דליפת מידע רפואי של 21,439 תלמידי חינוך מיוחד דרך קישור משותף, אירוע מסוג אחר לגמרי שאינו כופרה, אבל כזה שמראה איזה מידע יושב ברשתות האלו.
010 הגנה על מידע
לפני מיפוי השירותים ראוי לציין כי מתוך חמש ההמלצות שהחוקרים כותבים בסוף הדוח, שתיים אינן נענות בידי שירות מהרשימה הזו. האחת היא הגבלת הרצה מרוחקת ושיתופי מנהל – ממשקי הניהול של Windows, גישה לרגיסטרי מרוחק, יצירת משימות מתוזמנות והשיתוף המנהלי הסמוי שאליו נכתבו הפלטים – למכונות ניהול מוכרות בלבד. זו בדיוק התשתית שעליה נעה כל החדירה הזו, שהחוקרים מכנים אותה מרקם התנועה של התוקף. השנייה היא חסימת מפרשני שפות ומעטפות על מכונות שאינן זקוקות להם, גם לה יש עיגון באירוע: על שתי עמדות עבודה הושתלה הפצה נישאת של Python 3.11 כדי להריץ סקריפט אחד. אלו בקרות תצורה פנימיות. הדרך הכשרה להציג אותן היא כהמלצה של החוקרים ולא כשירות. גם ההמלצה הראשונה שלהם, להעמיד יחסי אמון וחשבונות מנהל דומיין תחת בקרת שינויים ולהפריד אישורים מורשים בין דומיינים, נענית כאן רק בחלקה: סקר ממפה מי מחזיק מה, ניטור מתריע על שינוי שהופיע בלי אישור, אך בקרת השינויים עצמה הינה תהליך ארגוני.
מכאן לשירותים שיש להם גשר עובדתי אל האירוע.
גיבוי והמשכיות עסקית הינו החיבור הישיר ביותר, אך לא במובן המקובל. העבודה כאן היא תכנון השכבה כך שאישורי ההתחברות שמאוחסנים בתוכנת הגיבוי לא יהוו מפתח יחיד לסביבה, בעוד שהעתקי השחזור יישמרו באופן שחשבון דומיין אינו יכול למחוק. ההמלצות שהחוקרים מנסחים הן לתחום חשבונות גיבוי לכל דומיין בנפרד, לבודד את שרתי הגיבוי ולשמור עותקים בלתי ניתנים לשינוי שאף חשבון דומיין אינו יכול למחוק. זו הנדסה של השכבה ולא נפח האחסון שלה.
SIEM/SOC נוגע כאן בנקודה מדויקת, לא בנקודה שהיה נוח למכור. מתקפה שמנסה שוב כל 40 עד 100 שניות אינה מאתגרת את מהירות התגובה, היא מייצרת רעש. לכן הערך אינו בקצב אלא בעובדה שמדובר באירועים נדירים שראוי להתריע עליהם בפעם הראשונה: קריאת אישורים ממסדי הנתונים של תוכנת הגיבוי ושמירת מפתחות הרגיסטרי SECURITY, SYSTEM או SAM, בשני המקרים בידי תהליך שאינו עבודת גיבוי או ניהול מוכרת; יצירת יחס אמון חדש בין דומיינים, שינוי בעל הרשאה גבוהה שסביבה בריאה כמעט אינה מבצעת; החזרת תוצאות של פקודה דרך הרגיסטרי, שהחוקרים מצביעים עליה כאפיק חריג ששווה לחפש באופן יזום. לכך מצטרפים קבצי הבדיקה והאישור שנשארו על הדיסק. בלשון החוקרים הסימן הזה עובד על מכונות שלא אמורות לראות קבצים כאלו מעולם, שכן על שרת ייצור הוא כמעט לעולם אינו תקין. פריסת סוכן ניטור על כל מכונה היא חלק מהשירות, זו גם ההמלצה החמישית של החוקרים: המכונה שהחזיקה את התשובה לשאלה המרכזית של המחקר היא זו שלא היה עליה סוכן.
הגנה אקטיבית מכופרה מקבלת כאן ממצא מדויק ומוגדר. ניסיון הסרת הגנת הקצה רץ פעמיים, בשתי גרסאות. מנגנוני ההגנה מפני שינוי חסמו אותו. יש להוסיף מיד שההגנה עמדה בפני ההסרה, אך ההצפנה בוצעה בכל זאת על כ‑ 37 מכונות. כלומר האירוע מראה שמנגנון הגנה עצמית עמד מול חשבון מנהל, לא שהוא מנע את התוצאה.
סקר סיכונים עונה על רשימת המצאי שהאירוע הזה חושף: אילו מכונות מחוברות לרשת בלי סוכן, אילו חשבונות מחזיקים הרשאות בכמה דומיינים, אילו מערכות עברו את תום התמיכה, מה בדיוק מאוחסן במסדי הנתונים של תוכנת הגיבוי, מה ניתן לקרוא מתוך SYSVOL בידי כל חשבון בדומיין. הסקר ממפה את התנאים האלו ומדרג אותם. הוא אינו הבטחה למנוע אירוע.
מודיעין סייבר רלוונטי מכיוון שמדובר בשחקן מוכר ולא בתעלומה. מודל הכופרה כשירות של ThreeAM מתועד, כמו גם היסטוריית השלוחות שלה. חברת Bitdefender פירסמה את מערך האינדיקטורים של החקירה הזו במאגר GitHub ציבורי. התפקיד של שירות מודיעין הוא להפוך מערך כזה לבדיקה בפועל מול הסביבה שלכם, לא לקריאה בלבד.
עדכוני תוכנה ואבטחה מצטרף כאן בכוונה מוצהרת ולא כמסקנה מהאירוע, שכן דרך הכניסה אינה ידועה. מה שהאירוע כן מראה הוא את עלות ההחזקה של מערכות מעבר לתום התמיכה שלהן. ראוי לדייק שזו בקרת מחזור חיים ולא קצב התקנת עדכונים: עמדה על Windows 10 אחרי אוקטובר 2025 ובקר דומיין על 2012 R2 אינם בעיה של עדכון חסר אלא של החלפה שנדחתה.
מניעת דלף מידע (DLP) נוגעת לשלב האיסוף: בחירה של 40 קבצים משיתוף של מחלקת הכספים לפי גודל וסיומת, ריכוזם במקום אחד ושליחתם כארכיון דחוס אל מכונה פנימית. התבנית של איסוף סדרתי משיתוף רגיש היא מה ששירות כזה מחפש. האירוע מוסיף דרישה מפורשת: גם תנועה פנימית צריכה להיחשב, שכן כל יעד מתועד של המידע הזה היה בתוך הארגון, שם גם נגמר המסלול שתועד.
סינון דוא"ל ומודעות עובדים לסייבר מופיעים כאן בזכות ההיסטוריה של הקבוצה ולא בזכות האירוע, שניהם באותו מצב ראיות בדיוק. לפי דיווח BleepingComputer, שלוחות של ThreeAM נצפו בעבר מגיעות לרשתות ארגוניות דרך הצפת דוא"ל ודרך שיחות מתחזות לתמיכה טכנית. הצפת דוא"ל שייכת לסינון דוא"ל, השיחות המתחזות שייכות למודעות עובדים. דרך הכניסה באירוע הזה אינה ידועה, לפיכך שני השירותים אינם נגזרים ממנו. הם מוזכרים כהקשר על בסיס ההיסטוריה של התוקף.
לסיום: שתי רשימות מאותו יום
במקרה של עיתוי, המחקר הזה ראה אור באותו יום שבו השיקה הסוכנות המקבילה בבריטניה את הדוח השנתי שלה. המרכז הלאומי לאבטחת סייבר של בריטניה (NCSC) פירסם ב‑ 3 בנובמבר את "מצב אומת הסייבר". מנכ"ל הסוכנות ריצ'רד הורן נאם בהשקה בלונדון. לפי הדוח, סביר מאוד שנוזקה מבוססת AI תשמש עד 2028 במתקפות כופרה של תוקפים ממונעי כסף נגד תחנות כוח, נמלי תעופה ובתי חולים בבריטניה. באותה נשימה קובע הדוח שה‑ AI צפוי להרחיב ולהגדיל טקטיקות קיימות יותר מכפי שימצא פגיעויות חדשות לגמרי.
את הסיבה תלה הורן במקום אחר לגמרי מהטכנולוגיה. בדבריו, כפי שדווחו ב‑ Infosecurity Magazine, הסיכון גדל "לא מכיוון שה‑ AI המציא דרכים חדשות לתקוף אותנו, אלא מכיוון שפגיעויות שנסבלו הרבה יותר מדי זמן ניתנות כעת לגילוי ולניצול בהיקף שלא היה מתקבל על הדעת בעבר". הוא מנה ארגונים רבים מדי שמסתפקים ב"טכנולוגיה בזול". בין היתר אמר: "מערכות בתום חיים שממשיכות לרוץ רק עוד שנה אחת, שדרוגים נחוצים שנדחים בשם התייעלות… העמדנו טכנולוגיה ואז לא השקענו בה לאורך מחזור החיים שלה, נתנו גישה היכן שהיה נוח ולא היכן שהיה נחוץ ולא הצבנו את הניטור הדרוש כדי לזהות מתי דברים משתבשים". בגרסה שהפיצה סוכנות AP הוא הוסיף שמנהלים שהסתדרו עם "טכנולוגיה בזול" יצטרכו להסביר, אם לא ישקיעו באבטחה ולא יחליפו תשתית מיושנת, למה "אין מזון על המדפים, האורות אינם דולקים ועסקים נסגרו". לשם קנה מידה, הסוכנות שלו הוציאה 110 אלף התרעות יזומות לארגונים בריטיים בעקבות פגיעויות PHP, אותו אשכול שעליו פורסם כאן מבזק ב‑ 29 באוקטובר.
הסמיכות הזו אינה קשר שמישהו מהמקורות טוען אותו. שני הפרסומים יצאו באותו יום ועוסקים בשני דברים שונים. ההשוואה היא של הכתבה הזו. עם זאת היא עומדת: שני פריטים מהרשימה של הורן מופיעים בסביבה הזו במפורש. מערכות בתום חיים שהמשיכו לרוץ, לצד זו שלא הוצב בה הניטור שמזהה מתי דברים משתבשים – המכונה הלא מנוהלת שממנה יצא הכל. יתר הפריטים ברשימתו אינם נבדקים באירוע הזה, לפיכך לא נאמר עליהם דבר.
מה שכן ראוי לקחת מכאן נוגע לשאלת ה‑ AI עצמה. מודל השפה שחיבר את הפקודות לא שינה מה עובד נגד ארגון כזה, גם לא נדרש לו דבר שלא היה בידי התוקף ממילא. כפי שהחוקרים מסכמים: "מה שמודל משנה אינו מה עובד, אלא איך נראות העקבות". דווקא בכך נמצאת הבשורה הטובה היחידה בסיפור, מכיוון שהעקבות שתוארו כאן – אותה פקודה שוב ושוב, קובץ ממוספר אחרי קובץ ממוספר, קבצי בדיקה שנשארים מאחור – הן הדבר הקל ביותר לזהות בכל האירוע, בתנאי אחד: שיש מי שמסתכל.
למקור הידיעה ולקריאה נוספת לחצו כאן
