DLL Sideloading (T1574.001)

מהו DLL sideloading?

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

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

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

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

הסבירו לי כאילו אני בן 10

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

מה קרה ל-T1574.002

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

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

מיפוי ה-tactics השתנה באותה גרסה, והחלק הזה חורג מטכניקה אחת. T1574.001 ממופה עכשיו ל-Stealth ול-Execution. ה-tactic שנקרא בעבר Defense Evasion נקרא עכשיו Stealth, ומתואר כניסיון של היריב "להסתיר ולהסוות את פעולותיו, ולהיראות כהתנהגות רגילה". tactic נפרד, Defense Impairment, יושב עכשיו לצידו ברשימת ה-enterprise. לא נמצא מקור שמסביר את ההיגיון מאחורי הפיצול, ולכן המאמר מדווח על השינוי ולא משער לגביו.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

וזו הסיבה שהעובדה הניתנת לזיהוי היא כמעט אף פעם לא הקובץ עצמו. שם ו-hash של DLL זולים לשינוי מצד תוקף; מאיפה הוא נטען, ועל ידי מי, זה לא. ההבחנה הזו היא כל הטיעון של pyramid of pain, מיושם על טכניקה אחת.

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

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

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

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

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

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

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

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

איפה הטיעון הזה נעצר

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

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

שאלות נפוצות

מהו מזהה ATT&CK של DLL sideloading עכשיו?

T1574.001, בכותרת "DLL", בגרסה 3.0 ועודכן לאחרונה ב-12 במאי 2026. הוא ממופה ל-tactics Stealth ו-Execution. המזהה T1574.002 כבר לא נפתר.

האם DLL sideloading זהה ל-DLL hijacking?

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

במה זה שונה מ-DLL injection?

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

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

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

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

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

מה ללכת לבדוק

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

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

1. Grep על המזהה שפרש. חפשו בסט הכללים, במטריצת הכיסוי, בתבניות הדוחות ובכל מודל איומים את `T1574.002`, והפנו מחדש את מה שמתגלה אל T1574.001. בזמן שאתם שם, תווית ה-tactic על אותם artifacts כנראה עדיין אומרת Defense Evasion.
2. בדקו האם ארבעת קווי הבסיס קיימים. תיקיות DLL ידועות כבטוחות, allowlist של אפליקציות שטוענות בלגיטימיות מנתיבים חריגים, חלון קישור, וערכי hash של ה-DLL-ים הלגיטימיים. ברוב הסביבות יש טלמטריה ואין קווי בסיס, וזו הסיבה שהטכניקה הזו נוטה להיות ניתנת לזיהוי בתיאוריה ובלי התראות בפועל.

הבדיקה הראשונה לוקחת אחר צהריים. השנייה היא מה שמחליט אם באמת תראו את זה.