DLL Sideloading (T1574.001)

מה זה DLL sideloading?

מתקפת DLL sideloading היא מצב שבו תוקף שותל DLL זדוני (ספריית קישור דינמי, Dynamic Link Library) במקום שבו תוכנה לגיטימית וחתומה טוענת אותו, כך שהמטען רץ בתוך תהליך מהימן. כיום MITRE ATT&CK מסווגת אותה תחת T1574.001, יחד עם Search order hijacking, DLL redirection, phantom hijacking ו-DLL substitution. המזהה T1574.002 כבר לא קיים.

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

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

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

תסבירו לי כמו לילד בן 10

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

מה קרה ל-T1574.002

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

• הכתובת הישנה ריקה. בקשה לדף הטכניקה של T1574.002 מחזירה תגובה בלי תוכן. אין שם דף.
• רשימת טכניקת האב לא כוללת אותה. רשימת תת-הטכניקות של T1574 מכילה כעת 12 רשומות. המזהים עוברים מ-.001 ישר ל-.004, וגם .002 וגם .003 חסרים.
• הערך שנשאר קיבל לתוכו את כל התוכן. T1574.001 נקרא כעת "DLL" בלבד, בגרסה 3.0 שעודכנה לאחרונה ב-12 במאי 2026. הגוף שלו מתאר כעת יחד, במקום אחד, את sideloading, redirection, phantom hijacking ו-substitution.

מיפוי הטקטיקות השתנה באותה גרסה, והמשמעות של זה חורגת מטכניקה אחת בלבד. T1574.001 ממופה כעת אל חשאיות (Stealth) והרצה (Execution). הטקטיקה שנקראה בעבר התחמקות מהגנה (Defense Evasion) נקראת כעת חשאיות, ותיאורה: תוקף "מנסה להסתיר ולהעלים את פעולותיו, ונראה כהתנהגות רגילה". טקטיקה נפרדת, פגיעה באמצעי הגנה (Defense Impairment), נמצאת כעת לצידה ברשימת הטקטיקות של Enterprise. לא נמצא מקור שמסביר את הסיבה לפיצול, ולכן העמוד הזה מדווח על השינוי ולא מנחש מה עומד מאחוריו.

שום דבר שבניתם לא הפסיק לעבוד

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

שום דבר לא התקלקל. שינוי מספור לא משפיע על כלל זיהוי שמזהה תהליך חתום שטוען DLL מתיקייה לא סטנדרטית. אותו דבר נכון גם לגבי כלל שמתריע על טעינת מודול מנתיב שמשתמשים יכולים לכתוב אליו, או על יצירת קובץ ואחריה טעינה של קובץ באותו שם. המזהה השתנה. ההתנהגות לא. זו מסקנה מתוך התיעוד, לא קביעה של MITRE עצמה, אבל היא נובעת ממנו בצורה ישירה: המנגנונים שמפורטים בגרסה 3.0 של T1574.001 הם אותן ההתנהגויות ששני המזהים הישנים תיארו. הנחיות הזיהוי מתבססות על יצירת קובץ, טעינת מודול, שינוי ב-Registry ויצירת תהליך - אף אחד מהם לא תלוי במספר שתחתיו הם מתועדים.

מה באמת צריך לעדכן

מה שכן דורש תשומת לב הוא צר יותר ומשעמם יותר. מזהה ATT&CK הוא טקסט שמופיע בתוך פריטים - ב-metadata של כלל זיהוי, במטריצת כיסוי, בתבנית דוח, ובמודל איומים שמישהו יפתח ברבעון הבא. אלה המקומות שבהם T1574.002 עדיין נמצא, וזה מה שצריך ללכת ולתקן.

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

זה sideloading או hijacking? תת-טכניקה אחת, כמה מנגנונים

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

הניסוח של MITRE עצמה הוא הניסוח השימושי: קבצי ה-DLL "אינם זדוניים מטבעם", אבל אפשר לנצל אותם לרעה באמצעות DLL sideloading, Search order hijacking ו-phantom hijacking. ההבדלים שחשובים כאן הם לא עניין של סיווג אלא עניין של ראיות - כל מנגנון משאיר עקבות שונים, וזו העמודה השלישית.

יש מנגנון נוסף שכדאי לקרוא לו בשמו, כי הוא לא מופיע בשום הסבר אחר שקיים היום בתחום. מנגנון ה-remote DLL hijacking יכול לקרות כאשר תוכנה מגדירה את התיקייה הנוכחית שלה לנתיב מרוחק, כמו web share, לפני טעינת DLL.

למה התהליך עדיין נראה תקין

הנה המשפט שמסביר למה מתקפת DLL sideloading לא נתפסת בידי כלי הגנת הקצה, מתוך תיעוד הטכניקה עצמו:

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

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

משום כך, העובדה שאפשר לזהות כמעט אף פעם לא הקובץ עצמו. את השם ואת ה-hash של DLL זול לתוקף לשנות; מאיפה הוא נטען ומה טוען אותו - לא. ההבדל הזה הוא הטיעון של ה-Pyramid of Pain: מקור הטעינה חשוב יותר מהזהות של הקובץ עצמו, וכאן הוא חל על טכניקה אחת.

איך מזהים את זה

המיזוג ניכר גם בצד הזיהוי, וזה לטובתנו: אסטרטגיית זיהוי אחת מכסה כעת את כל המנגנונים שלמעלה. אסטרטגיית הזיהוי DET0201 מתארת קורלציה של "שינויים במערכת הקבצים, שינויים ב-Registry, וטלמטריית טעינת מודול, כדי לזהות התנהגות DLL חריגה בתהליכים מהימנים". כך היא מכסה טעינות בלתי צפויות מתיקיות שאינן סטנדרטיות, החלפה, הכנסת קובץ פנטום, קובצי redirection, ו-substitution, הכל בכלל זיהוי אחד.

מקורות הלוג ספציפיים:

• יצירת קובץ: אירוע Sysmon 11.
• ה-metadata של הקובץ: אירוע Sysmon 15.
• טעינת מודול: אירוע Sysmon 7. אם אתם יכולים לאסוף רק מקור אחד, זה המקור.
• שינוי במפתח ה-Registry: אירוע Windows Security 4657, וזהו מה שתופס redirection.
• יצירת תהליך: אירוע Sysmon 1, שמספק את ההקשר לכל האמור למעלה.

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

לשם כך קיימים ארבעת המרכיבים הניתנים לכוונון של כלל הזיהוי, והם החלק ששווה להעתיק לתכנון שלכם:

• נתיבי DLL מותרים - התיקיות הידועות כבטוחות, שמשתיקים את ההתראות מהן, כשהדוגמה המובנת מאליה היא C:\Windows\System32.
• רשימת אפליקציות מותרות - האפליקציות שצפויות לטעון קבצי DLL מנתיבים לא סטנדרטיים. הדוגמה של MITRE עצמה היא כלי פיתוח, וזו תזכורת טובה לכך שהמקרה התמים הוא הנפוץ, לא יוצא הדופן.
• חלון קורלציה - פרק הזמן שבתוכו יצירת קובץ, שינויים ב-Registry וטעינת מודול נחשבים לאירוע אחד ולא לשלושה.
• קו בסיס (hash baseline) - ערכי hash של קובצי ה-DLL הלגיטימיים, וזה בדיוק מה שתופס substitution, כי substitution משאיר את השם ואת הנתיב ללא שינוי.

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

איפה הטיעון של העמוד הזה נעצר

ארבעה גבולות, והראשון שבהם הוא החשוב ביותר.

• המזהה השתנה, לא ההתנהגות. זה חוזר כאן כי זו הנקודה הכי סבירה לפרשנות שגויה: מדובר בעדכון מזהה, לא באירוע אבטחה. אם כללי הזיהוי שלכם מבוססים על התנהגות, הם עדיין עובדים. זו מסקנה שמוסקת בבירור מהתיעוד, לא הצהרה של MITRE - המסגרת תיעדה מיזוג. היא לא התייחסה לכללי הזיהוי של אף אחד.
• קבצי ה-DLL הם לא הבעיה. גם התוכנה היא לא הבעיה. MITRE אומרת במפורש שקבצי ה-DLL לא זדוניים מטבעם. אפליקציה שעלולה להיות חשופה ל-DLL sideloading היא לא רשלנית בגלל זה. סדר החיפוש הוא התנהגות של Windows. השימוש הלגיטימי בספריות קישור דינמי הוא הסיבה היחידה לכך שהמנגנון קיים.
• המקרה התמים נפוץ. כלל הזיהוי מגיע עם רשימת אפליקציות מותרות, כי תוכנה תקינה אכן טוענת קבצי DLL מנתיבים לא שגרתיים. מי שמתייחס לנתיב טעינה בלתי צפוי כזדוני מטבעו יבזבז שבוע שלם בסגירת קריאות שירות (tickets).
• למקורות של העמוד הזה יש מגבלות משלו. כדאי לציין אותן. הטענה על העדכניות שהוצגה למעלה מבוססת על ארבעה עמודי הסבר קריאים שנבדקו ביום אחד. זה מספיק כדי לדווח ביושר, אך לא מספיק כדי לאפיין את כל התחום. תוצאה אחת נראתה כאילו כוללת תוכן אמיתי על הנדסת זיהוי, אבל אי אפשר היה לקרוא אותה בכלל. האתר מגיש מעטפת JavaScript, ולכן שום דבר כאן לא מתאר את התוכן שלו. גם נתון תפוצה לא מופיע בשום מקום למעלה - לא נמצא נתון כזה בצורה ששווה לצטט.

שאלות נפוצות

מה מזהה ה-ATT&CK הנוכחי של מתקפת DLL sideloading?

הטכניקה T1574.001, שנקראת "DLL", נמצאת בגרסה 3.0 ועודכנה לאחרונה ב-12 במאי 2026. היא ממופה לטקטיקות חשאיות והרצה. המזהה T1574.002 כבר לא מפנה לשום דבר.

האם DLL sideloading ו-DLL hijacking הם אותו דבר?

שני המונחים כבר לא מתארים שתי טכניקות נפרדות. מתקפת DLL sideloading היא אחת המנגנונים בעלי השם בתוך T1574.001, לצד search order hijacking, redirection, phantom hijacking ו-substitution. ההבדל המעשי ביניהם הוא העקבות שכל מנגנון משאיר אחריו, לא הקטגוריה שהם משתייכים אליה.

מה ההבדל בין DLL sideloading ל-DLL injection?

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

האם הכללים הקיימים שלי עדיין עובדים?

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

איזה מקור לוג בודד מציג את המתקפה הכי טוב?

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

מה כדאי לבדוק

המנגנון שכבר הכרתם עדיין נכון. המזהה הצמוד אליו כבר לא נכון.

שתי בדיקות, והשנייה קשה יותר.

1. עשו Grep למזהה שהוצא משימוש. חפשו את T1574.002 במערך הכללים, במטריצת הכיסוי, בתבניות הדוח ובכל מודל איומים, ומה שנמצא הפנו מחדש אל T1574.001. כשאתם כבר שם, תווית הטקטיקה באותם הפריטים כנראה אומרת התחמקות מהגנה.
2. בדקו אם ארבעת המרכיבים הניתנים לכוונון קיימים. נתיבי DLL מותרים, רשימת אפליקציות מותרות שטוענות באופן לגיטימי מנתיבים חריגים, חלון קורלציה, וה-hashes של קבצי ה-DLL הלגיטימיים. ברוב הסביבות יש טלמטריה, אבל אין ארבעת המרכיבים הניתנים לכוונון. זו הסיבה שבדרך כלל אפשר לזהות את הטכניקה הזו בתאוריה, אבל היא לא מפעילה התראה בפועל.

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