DLL Sideloading (T1574.001)

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

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

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

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

מה זה DLL, ולמה תוכנות טוענות DLL-ים?

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

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

איך Windows מחליט איזה DLL לטעון?

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

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

• התיקייה שמכילה את קובץ ההרצה של התוכנה (הקובץ שמריץ את התוכנה) - נקראת כאן תיקיית התוכנה;
• תיקיית המערכת;
• תיקיית Windows;
• התיקייה הנוכחית: תיקיית העבודה הנוכחית של התהליך. היא יכולה להיות שונה מתיקיית התוכנה, ולא פשוט המקום שבו המשתמש עובד. הגדרת ברירת מחדל שנקראת safe DLL search mode משאירה את בדיקת התיקייה הנוכחית בשלב מאוחר ברשימה.

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

איך הקובץ של התוקף בסוף נטען?

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

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

מה התוכנה צריכה לאפשר

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

שני מצבים

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

איך נראה קמפיין תקיפה אמיתי?

בדוח שפורסם ב-11 באוגוסט 2026, Check Point Research תיארה קמפיין תקיפה מתמשך שהיא מכנה Operation Dream Job, ומקשרת אותו לקבוצת Lazarus. לפי הדוח, הקמפיין מכוון לארגונים בעולם כולו, בדגש על מגזר הביטחון. באחת משרשראות המתקפה שהדוח מתאר, הקורבן משוכנע להוריד ארכיון מוצפן שמכיל שלושה קבצים: תוכנת צפייה לגיטימית בקבצי PDF, DLL זדוני, וקובץ מוצפן בסיומת PDF שמכיל את קוד התוקף.

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

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

למה חשוב שהקוד רץ בתוך תוכנה מהימנה?

שלושה דברים הופכים תוכנה מהימנה לכסות שימושית:

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

כל זה לא הופך את קובצי ה-DLL, או את התוכנה שטוענת אותם, לבעיה. תוכנה שמבקשת DLL לפי השם שלו עושה את מה ש-Windows מתעד.

איך DLL sideloading נבדלת מחטיפת DLL (DLL hijacking) ומהזרקת DLL (DLL injection)?

המסגרת MITRE ATT&CK מתעדת את ה-DLL sideloading בערך אחד, T1574.001, שכותרתו "Hijack Execution Flow: DLL" (ל-Windows). MITRE מתארת את ה-DLL sideloading כחטיפה שקובעת איזה DLL תוכנה טוענת. המילה "חטיפה" היא המילה הרחבה יותר. היא מתארת הפניה של טעינת DLL, ואילו המילה "sideloading" מדגישה תוכנה לגיטימית שטוענת קוד בשליטת התוקף. מתקפת DLL sideloading יכולה לנצל חטיפת סדר החיפוש (search order hijacking), ולכן אפשר לתאר אותה גם כ-DLL sideloading וגם כחטיפת סדר החיפוש. הערך מפרט חמישה מנגנונים קשורים שיכולים לחפוף זה לזה:

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

הזרקת DLL היא טכניקה אחרת, שמופיעה כ-T1055.001. היא מחדירה קוד מבחוץ לתוך תהליך שכבר רץ: MITRE מתארת אותה כשיטה להרצת קוד שרירותי במרחב הכתובות של תהליך נפרד ופעיל. ב-DLL sideloading, התוכנה עצמה מבצעת את הטעינה, כחלק מהריצה שלה.

מה עוצר DLL sideloading, ואיפה כל הגנה מפסיקה לעבוד?

כל הגנה פועלת בשלב אחר בשרשרת המתקפה, ולכל אחת גבול משלה.

תוכנות שמציינות איפה ה-DLL-ים שלהן נמצאים

ההנחיה של Microsoft למפתחים היא לציין נתיב מלא בעת טעינת DLL, או להגדיר את סדר החיפוש של התהליך. נתיב מלא מבטל את החיפוש אחרי אותו DLL, ולכן לעותק המוטמע אין שום סיכוי להיטען במקומו. הגבול הוא שזה עוזר רק לתוכנות שהמפתחים שלהן עושים את זה. Microsoft מציינת שהתלויות של ה-DLL (קובצי DLL אחרים שהוא עצמו צריך) עדיין נחפשות לפי שם בלבד, גם כשה-DLL הראשון נטען בנתיב מלא. ה-safe DLL search mode של Windows מזיז את התיקייה הנוכחית למקום מאוחר יותר ברשימה, ו-Microsoft אומרת שזה מגדיל את הסיכוי ש-Windows מוצא עותק לגיטימי לפני עותק זדוני. זה מגדיל את הסיכוי, אבל זה לא מוציא את תיקיית התוכנה מסדר החיפוש.

בקרת תוכנות שבודקת DLL-ים

בקרה שמאשרת רק תוכנות שמורשות לרוץ בודקת את התוכנה, וב-sideloading התוכנה לגיטימית. ההנחיה של MITRE למניעת הרצה היא, אם כך, בקרת תוכנות שיכולה לחסום DLL-ים שתוכנה לגיטימית טוענת. בכלי AppLocker של Microsoft, ה-DLL rules גורמים לו לבדוק כל DLL שתוכנה טוענת. החיסרון הוא שצריך DLL allow rule נפרד לכל DLL שכל תוכנה מורשית לרוץ טוענת, כולל קובצי המערכת של Windows. בדיקת כל DLL עלולה גם להאט מחשבים עם משאבים מוגבלים.

עדכונים וביקורת

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

זיהוי

אסטרטגיית הזיהוי של MITRE מצליבה שינויים במערכת הקבצים, שינויים ב-Registry וטלמטריית טעינת מודולים (רישומים של איזה DLL כל תוכנה טענה), כדי לאתר התנהגות DLL חריגה בתהליכים מהימנים. אין כאן כלל קבוע. תוכנות מסוימות, כמו כלי פיתוח, צפויות לטעון DLL-ים ממיקומים לא שגרתיים. בגלל זה, האסטרטגיה צריכה כוונון, והכוונון הזה כולל תיקיות ידועות ובטוחות, רשימת תוכנות מותרות שמכילה תוכנות כאלה, חלון קורלציה, וקו בסיס של ערכי hash (טביעות אצבע) של DLL לגיטימיים. חלון הקורלציה קובע כמה קרוב בזמן אירועים צריכים להיות כדי שייחשבו קשורים זה לזה. בלי הכוונון הזה, טעינות רגילות עלולות להיראות כניצול לרעה.

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