טוב אז אחרי שבכתבה הקודמת (קישור לכתבה) הצגנו באופן כללי את החלקים בביצוע Malware Analysis –
(Basic Static, Advanced Static, Basic Dynamic, Advanced Dynamic) המשכנו וצללנו קצת לניתוח Malware Sample שהוצג.

בניתוח ראינו: ניצול ה – AppInitDLLs Mechanism לצורך השגת Persistence, הוספת כתובת מייל של התוקף לכל מייל שישלח החוצה מעמדת הקצה, ואף ראינו שימוש ב – User-Space Rootkit במטרה להמשיך לפעול במסווה בעמדה (Stealth).
סיכמתי באמירה שאני עדיין עומד מאחוריה :”כל מי שבאמת מרגיש תשוקה לתחום ה – Malware Analysis יכול לעשות את זה ובגדול!”
כמו שאומרים: Practice Makes Perfect😉

אם נשארתם עד עכשיו, כנראה שאתם באמת אוהבים את התחום (או שאני ממש כריזמטי, אבל לא נראה לי שזו הסיבה)…בקיצור בוא נתחיל!

אז במה אני הולך לשעמם אתכם הפעם, או שלא😏?

הכתבה תסקור בקצרה את ההבדל בין Process Injection לבין Process Hollowing ותציג בקצרה גם Injection Techniques נוספות.

לאחר מכן, נצלול לניתוח שני Malware Samples – אחד המיישם Process Injection דיי Straight Forward עם Persistence Mechanism מגניב שאהבתי, ואחר המיישם Process Hollowing.

רגע לפני שמתחילים…

אם נחזור רגע ל- “קטגוריות העל” שהזכרנו בכתבה הקודמת: Persistence, Stealth,  ו- Privilege Escalation נוכל לסווג 2 שיטות אלו(Injection ו- Hollowing) גם לקטגוריית ה – Stealth וגם לקטגוריות ה – Privilege Escalation (נראה את הסיבה ממש בקרוב 😊) מה שהופך את השימוש בהן לאטרקטיבי מאוד בקרב תוקפים.
*הערה קטנה: ניתן להתייחס לקטגוריות נוספות בתור “קטגוריות על” למשל Spread/Movement אותן “כל” Malware ממוצע יממש בצורה כזו או אחרת, לעת עתה נסתפק בקטגוריות שצוינו בכתבה הזו ובכתבה הקודמת.

נו דן, תפסיק למשוך אותנו, מה התכל’ס?

Process Injection כמו שהשם מרמז זו טכניקה ל-“הזרקת” (כתיבת) קוד זדוני ל – Process אחר שרץ. בעקבות זאת, ה – Process שהוזרק יריץ את הקוד שהוזרק אליו כחלק מתהליך הריצה שלו.
כפי שצוין, תוקפים ישתמשו בשיטה זו להשגת Stealth שכן המשתמש הממוצע פשוט יראה תהליך לגיטימי שרץ אצלו בעמדת הקצה. יתרה מכך, השילוב של Malware-ים מתוחכמים ו-Security Measures רעועים בעמדת הקצה, יכולים לאפשר לפוגען אף לחמוק ממנועי AV מסוימים וקונפיגורציות שונות של אמצעי Security בעמדות הקצה השונות.

Process Hollowing (בעבר גם נקרא Process Replacement) זו בעצם Sub-Technique למימוש Process Injection.
בגדול, במקום לבצע “הזרקה” של קוד ל – Process אחר, מבצעים קודם פעולת Unmap לקוד לגיטימי של Process קיים (מכאן מגיעה המילה Hollow – מרוקנים אותו מתוכן הקוד שקיים אצלו) ובמקומו מבצעים OverWrite עם קוד זדוני.
קיימות שיטות רבות לממש Process Injection, למשל:

• DLL Injection
• PE Injection
• APC Injection
• Process Doppelgänging
• ורבים נוספים…שכנראה אקדיש להם (ולקודמים שהוצגו) כתבה משלהם בהמשך 😊

“דומה אך שונה”

כל ה – Sub-Techniques וביניהם Process Hollowing יכילו מאפיינים כלשהם שיהיו משותפים לכולם שכן כולם תת-שיטות ליישום Process Injection.
ברוב המקרים נראה את הקריאות ל – Windows API Functions הבאות: VirtualAllocEx ו- WriteProcessMemory שמטרתן לשנות את הזיכרון במרחב הכתובות של Process אחר.
בנוסף, סביר להניח שנראה קומבינציה כלשהיא של הקריאות לפונקציות הבאות:

• CreateRemoteThread
• SuspendThread
• SetThreadContext
• ResumeThread
• QueueUserAPC
• NtQueueApcThread

שימו לב, שאמרתי “לרוב” ו-“סביר להניח” שכן:

1. “סביר להניח”- כי קיימים Malware-ים שונים ומגוונים out-there שיכולים להיות ממומשים בצורות שונות ומגוונות ולכן אל לנו להיות מקובעים ונצטרך לבדוק כל מקרה לגופו.
2. “ברוב” – כי ה – Malware Sample שנראה בקרוב מממש Process Injection,ובדיוק הוא, לא משתמש ב – Windows API Functions האלו😉.

אז בואו נתחיל לרברס🤩

Process Hollowing

במימוש הגנרי תתבצע קריאה ל – Windows API Functions מסוימות שעתה נסקור.
במקרים רבים ה – Malware יבצע Obfuscation/Encoding ושיטות נוספות על מנת להסוות את התהליך ולהפוך את הזיהוי כי אכן מדובר ב – Process Hollowing ליותר מורכב.

חידוד קטן: מניתוח קודם גילינו כי ה – Process עליו יתבצע Process Hollowing הוא svchost.exe.
זיהינו זאת ע”י אינומרציה של Process ID-ים (PID-ים) שה – Malware עושה בחיפוש אחר Process היעד.
החיפוש האיטרטיבי אחר ה – Process לא מוצג כאן לצורך הפשטות.

נסביר קצת על השלבים שמתרחשים 🙂

1.  ה – Malware קודם יוצר Process חדש (CreateProcess) על מנת להוות מעין “Container” עבור הקוד הזדוני (שעתיד להיכתב) ב – Suspended Mode (מאפשר כתיבה ושינוי של Process קיים, בקוד למעלה ניתן לראות כי הפרמטר 0x4 מועבר לפונקציה לצורך השגת מצב זה).
2. ה – Thread הראשי של ה – Process נוצר במצב של suspended mode ולא ימשיך לרוץ עד שתתבצע קריאה לפונקציה ResumeThread.
3. תתבצע קריאה ל – GetThreadContext על מנת להחזיר את התוכן של ה – Thread המדובר, בו מתבצע השינוי.
4. כעת, נראה קריאה לאחת מהפונקציות ZwUnmapViewOfSection או NtUnmapViewOfSection,
   פונקציות אלו משחררות את כל הזיכרון שקיים בזיכרון של ה – Process הנוכחי ב – Section הנוכחי.
   
5. עתה, כשהזיכרון שוחרר, תתבצע קריאה ל – VirtualAllocEx, בה ה – Loader יקצה זיכרון חדש עבור הקוד הזדוני (בתצלום מעלה).
   
6. תתבצע קריאה ל – WriteProcessMemory על מנת לכתוב את ה – section-ים של ה – Malware ל – Process היעד.
7. לבסוף ,תתבצע קריאה ל – SetThreadContext, על מנת לשנות את ההצבעה ל – Entrypoint שיצביע לקוד הזדוני שזה עתה נכתב.
8. תתבצע קריאה ל – ResumeThread (כפי שהזכרנו בהתחלה) על מנת להוציא את ה – Process ממצב Suspended וחזרה לריצה רגילה.

חידוד קטן – נשים לב כי אנחנו לא רואים במפורש קריאה ל – NtUnmapViewOfSection, שכן אנחנו רק רואים ש – IDA Pro זיהה את המקום בו מתבצע reference לפונקציה זו והשמת label מתאים (string).
עם זאת, אנחנו כן רואים קריאה לפונקציה שמתרחשת באמצעות Dynamic-Linking בכתובת 0x00401206 (מסומן בכחול מעלה).
על מנת אכן לאמת כי מתבצעת הקריאה ששיערנו, נריץ את הפוגען באמצעות OllDbg ונראה איזה פונקציה באמת נקראת.
# חשוב לעשות זאת שכן תוקפים מנוסים, מטרתם להוליך שולל את החוקר, בניסיון למנוע ממנו להבין מה באמת קורה.
זאת במטרה, לשמר את שרידות ה – Malware בעמדה או להסוות פונקציונאליות נוספות.
הרצת הפוגען והשמת Breakpoint על הכתובת המדוברת, אכן מאמתת את ההשערה שלנו, כפי שניתן לראות בתצלום מטה:

Process Injection – תצורה הגנרית + הפתעה קטנה😉

ראשית, אתן סקירה קצרצרה אודות מה מצאנו בשלבי חקירה קודמים (מדובר בחקירה נפרדת מהקובץ הקודם) שכן בהתבסס עליהם העלנו השערות וכיווני גישה לחקירה.
1. ראינו כי הקובץ ינסה לחפש את ה – winlogo.exe – Process.
2. בנוסף ראינו בשלב ה – Basic Static Analysis קיום של המחרוזת CreateRemoteThread אנחנו יכולים לשער שכנראה יתבצע Injection ל- Process הזה.
ננסה למצוא הוכחה שאכן כך הדבר.

כיוון שמדובר במימוש דיי Straight Forward של Process Injection נצפה לראות את רצף הקריאות הבא:

1. VirtualAllocEX – ה – Malware יקצה זיכרון ב – Host Process אליו תתבצע “ההזרקה”.
2. ה – Malware יבצע קריאה ל – WriteProcessMemory על מנת לכתוב את הקוד הזדוני.
3. על מנת להריץ את ה – Process לאחר ביצוע השינויים, תתבצע קריאה ל – CreateRemoteThread /NtCreateThreadEx/ RtlCreateUserThread או יעשה שימוש ב – shellcode.
   
   #בעיקרון תתבצע העברה של הכתובת של LoadLibrary (הכתובת של הספרייה בה שמור הקוד הזדוני אותו נרצה לכתוב) לאחת מפונקציות ה – API שצוינו מעלה על מנת ש – Remote Thread יבצע את הכתיבה/ריצה.
   #השימוש ב – CreateRemoteThread מצריך קיום של DLL זדוני בעמדת הקצה – מנגנוני הגנה רבים יכולים לזהות זאת ולכן תוקפים מתוחכמים ישתמשו לרוב בשיטות אחרות.
   נראה איך זה בא לידי ביטוי בקוד ה – Assembly:

בקטע הקוד אנחנו רואים קיום של כמה קריאות מעניינות ואי-קיום של כמה קריאות חסרות:

• אין שום זכר לפונקציה – WriteProcessMemory כפי שהיינו מצפים – מוזר ומצריך עוד מחקר.

• בתחילת הקוד רואים קריאה לפונקציה – sub_4010FC שמקבלת בתור פרמטר את -SeDebugPrivilege.
  מה שאנחנו רואים כאן זה בעצם מימוש ה – Privilege Escalation שציינתי קודם.

—————————–

בקצרה – Process-ים שרצים ע”י המשתמש לא יכולים פשוט לגשת לכל משאב שהם רוצים או למשל לקרוא לפונקציות כמו TerminateProcess או CreateRemoteThread על Process-ים אחרים.

Malware-ים שונים ינסו להשיג גישה לפונקציות אלו ע”י שינוי ההגדרות של ה – Access Token.

Access Token- אובייקט שמכיל מידע, או בשפה המקצועית, Security Descriptor אודות Process, הוא בעצם מתאר את הרשאות הגישה של ה – Process.
אפשר לשנות את ה – Access Token ע”י קריאה ל – AdjustTokenPrivileges.

SeDebugPrivilege בעצם מאפשר System-Level-Debugging אך תוקפים משתמשים בו לקבלת הרשאות גישה חזקות ל – System-Level-Process.
*תהליך ה – Privilege Escalation מתרחש בתוך פונקציה זו, בחרתי שלא להעמיק בניתוח שלו על מנת שנתמקד בנושא הכתבה.
—————————–

• קריאה ל- LoadLibrary לצורך Dynamic Linking של הספרייה – sfc_os.dll וקריאה עוקבת ל- GetProcAddress הפעם עם Ordinal (“מספר סידורי” שקיים ל- imports) שמקבל את הערך 2 (בניגוד לפעמים קודמות שראינו, בהם התבצעה קריאה על פי שם).
• הקריאה המיוחלת ל – CreateRemoteThread עם הפרמטרים הבאים:
  
  1. hProcess שמושם ברגיסטר edx – שהוא ה – Handle (גישה לProcess ומשאבים שונים נוספים מתבצעת באמצעות החזרת Handle אחרי ריצת פונקציות ושימוש בהם הלאה בקריאות הבאות) ל- Process המדובר: winlogon.exe.
  
  2. lpStartAddress שהוא ה – Ordinal של הפונקציה לה נקרא מהספרייה sfc_os.dll -> זו בעצם הפונקציה ש”תזריק” Thread ל- winlogo.exe.

פה מגיע הקאץ’ המעניין

עם קצת מחקר בגוגל על sfc_os.dll ועל הפונקציה שלה הממוספרת כ Ordinal 2 – SfcTerminateWatcherThread, אנחנו מגלים כי הספרייה sfc_os.dll מלכתחילה נטענת ל Process – winlogon.exe!
לכן, אין צורך לטעון שוב פעם DLL זה ב – Remote Thread שה- Malware יוצר וזו הסיבה למה לא נראה אף קריאה ל- WriteProcessMemory (מטורף! 🤩).

Sfc_os.dll אחראי (בין היתר) גם על מנגנון ה – Windows File Protection ומכיל מספר Thread-ים שרצים בתוך winlogon.exe .
הפונקציה SfcTerminateWatcherThread מאפשרת לשנות Protected Windows Files (בגדול – קבצי מערכת מוגנים עם הרשאות חזקות).

אנחנו רואים שה – Malware פותח את winlogon.exe עם הרשאות PROCESS_ALL_ACCESS (מסומן בכחול בתצלום מעלה, חיפוש ב – MSDN אחר OpenProcess ואחר הערך ‘1F0FFFh’ יגלה לנו זאת).

לאחר מכן, הוא יוצר Remote Thread ב – winlogon.exe שקורא לפונקציה SfcTerminateWatcherThread – בספרייה sfc_0s.dll – זה בעצם ה – Process Injection.

ע”י הרצה של SfcTerminateWatcherThread ה – Malware בעצם עושה disable למנגנון ה – WFP (Windows File Protection) עד לביצוע reboot של המערכת.

הדובדבן שבקצפת🧐

לאחר ביצוע ה – Injection מתרחשים דברים מעניינים לא פחות (אפילו יותר 😏):

1. ה – Malware מבצע קריאות לפונקציות שמבצעות Resource Manipulation שראינו בשלב ה – Basic Static Analysis (FindResource, LoadResource ונוספים…).
2. מתבצע Extract לקובץ ששמור ב – Resource Section של ה – Malware הנוכחי שמחליף את קובץ המערכת הלגיטימי הבא: C:\Windows\System32\wupdmgr.exe.
   ————-
   מה שבפועל מתבצע זה שה – Malware משנה את השם של הקובץ הלגיטימי ל – winup.exe וקורא ל – MoveFile על מנת להעביר אותו לתיקיית ה – Temp, בעוד שהקובץ הזדוני (עם השם הלגיטימי) נכתב לנתיב המקורי: C:\Windows\System32.
   
   *הערת צד – העובדה שמלכתחילה ה – Malware יכול ליצור Windows Update Handler חדש היא רק בעקבות פעולת ה – Disable של ה – Windows Update File שראינו קודם.

בכל מצב אחר, המערכת הייתה מזהה שמדובר בקובץ שונה ומבצעת לו Overwrite חזרה לקובץ המקורי.
————-
3. ה – Malware מבצע הורדה של קובץ Malware נוסף בעזרת קריאה ל – URLDownloadToFile שבעצם מבצע Update לעצמו!

ה – Malware  בעצם משיג Persistence באופן הבא:

1. תחילה תתבצע ריצה לגיטימית של הקובץ wupdmgr.exe המקורי כך שבמידה והמשתמש ינסה לבצע Windows Update התהליך יתנהל כשורה.
2. מתבצע Trojanize לקובץ ה – wupdmgr.exe שמורכב מ:
   1. ביצוע ה – Process Injection ל – winlogon.exe.
   2. ביצוע Disable ל – WFP mechanism.

בתהליך זה מתבצעת כתיבה של קוד זדוני ל – wupdmgr.exe.
הקוד הזדוני שנכתב יבצע הרצה של הקובץ המקורי wupdmgr.exe על מנת לא להתגלות ע”י המשתמש (Stealth).
לאחר מכן, תתבצע הורדה של קובץ ה – Updater.exe שישמר כ – wupdmgrd.exe ויתן ל – Malware לממש את הפונקציונאליות שלו (קובץ זה לא ברשותנו ולכן לא נוכל לנתח).

תובנות תהיות ושאר ירקות:

1. הסקירה שראינו כאן כללה מספר היבטים.
   מצד אחד ראינו את ההבדלים בקוד ה – Assembly בין Process Injection לבין Process Hollowing.
   מצד שני, רציתי לקשר כל יישום לעוד נקודה קטנה שאוכל להראות ולקשר 🙂
2. המימוש של ה – Privilege Escalation הוסבר ממש בתמצות. יש עוד הרבה מה לומר על הנושא, גם בהקשר של ה – Malware Sample שניתחנו כעת וגם בהקשרים של Malware-ים רבים Out there…אני בטוח שעוד אחזור לכתוב עליו😋.
3. מנגנון ה – WFP (Windows File Protection) הוא מנגנון Security ישן שנעשה בו שימוש בעיקר במערכות Windows XP ו- Windows 2000. מערכות הפעלה חדשות כבר חסינות לחולשה זו.
   עם זאת, זה לא אומר שלא נראה וראיציה של תקיפה כזו בעתיד בהקשר של Mechanism אחר או דומה שקיים ב – Windows, לכן טוב להכיר את תהליך התקיפה הזה.
4. הזכרתי בקצרה מספר Injection Techniques (בכוונה ללא פירוט) שנעשה בהן שימוש רב בקרב תוקפים. לא פירטתי עליהם מכמה סיבות:
   1. אני מאמין שאם אתם מספיק סקרנים, אתם תרצו לקרוא עליהם בעצמכם.
   2. כל Injection כזה הוא עולם ומלואו ואני מאמין שמגיעה לו כתבה נפרדת, על מנת שנוכל לראות באמת איך הם נבדלים זה מזה בקוד ה – Assembly.
   3. אני מוסיף בקטגוריית ה – Reference כמה לינקים ממש מגניבים שתוכלו להעמיק בהם אם תרצו 😊
5. בצמד הכתבות (הכתבה הזו והכתבה הקודמת) יצא לנו לראות כבר לא מעט Really Cool Stuff🤘, ביניהם: Persistence Mechanism שממומש בעזרת AppInit_DLLs, ה – Persistence Mechanism שראינו עכשיו שממומש בעזרת Launcher שמוריד Malware נוסף, ראינו Process Injection דיי Strait Forward עם קאץ’ קטן ויצא לנו לראות User-Space Rootkit שממומש בעזרת Inline Hooking (בכתבה הקודמת) – וואלה דיי הרבה, ומכאן רק נעמיק וניחשף לעוד דברים מגניבים.

בכתבה הקודמת, הבטחתי לפרסם כתבה שתכיל יותר Fundamentals, תפרט בנוגע ל – Buzz Words שנאמרו בצמד הכתבות כ-“בדרך אגב”…לא שכחתי 😌 ואני אדם שעומד במילה שלי 😊
זה אמור להיות מעין Definition Guide שתוכלו לבצע אליו Reference בכל פעם שתיתקלו במושג חדש לכם, ולכן זה לוקח קצת זמן 😊

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

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

References

– ה – Malware Sample-ים נלקחו מתוך ספר מדהים! הנקרא: Practical Malware Analysis ונכתב ע”י Michael Sikorski ו- Andrew Honig -> לכל מי שמעוניין להתחיל את דרכו הראשונה בתחום, אני לגמרי ממליץ להתחיל מהספר הזה!

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

– לאלו מכם שלא שמעו על MITRE ATT&CK, מדובר ב – Framework שהיא בעצם Knowledge Base עצום, Well structured המכיל: שיטות תקיפה שונות + כיצד לזהות ולמגר אותן, שיטות תקיפה המאפיינות קבוצות תקיפה שונות (APT-ים למיניהם ונוספים), הצגת ה – Cyber Kill Chain עבור תקיפות שונות ושלל דברים נוספים!
ממליץ בחום, להיכנס ולשוטט שם קצת, Have Fun!