ניתוח פורנזי לאחר אירוע אבטחה

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

היכולות שלנו:

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1359
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

כיצד אנו מבצעים ניתוח פורנזי לאחר אירוע

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

בפורנזיקה דיגיטלית, הכלל פשוט: שמרו קודם, חקרו אחר כך. המהנדסים שלנו, עם ניסיון משולב של למעלה מ-10 שנים ו-40+ חקירות, פעלו לפי עיקרון זה מההתחלה. אנו מבטיחים שרשרת מסירה וסודיות. ניתוח פורנזי יעיל פי 3 מתגובה לאירוע סטנדרטית: החיסכון בקנסות יכול להגיע לכמה מיליוני דולרים, וההסתברות לשחזור מלא של ציר הזמן של ההתקפה היא 95%.

תהליך איסוף הראיות שלב-שלב

  1. לכידת נתונים נדיפים: dump זיכרון, חיבורי רשת, רשימת תהליכים.
  2. יצירת תמונת דיסק bit-for-bit עם hashing (SHA-256).
  3. איסוף לוגים של מערכת ההפעלה, auditd, לוגים של התקני רשת.
  4. בידוד artifacts בסביבה מאובטחת לקריאה בלבד.

מדוע סדר האיסוף חשוב

artifacts דיגיטליים נעלמים בסדר הנדיפות: מ-RAM ועד גיבויים קרים. הפרת הסדר מובילה לאובדן נתונים מרכזיים—התוקף עלול לזהות עקבות ולהשמיד אותם. הטבלה מציגה את ההיררכיה האופיינית:

רמה דוגמאות ל-artifacts מהירות דעיכה
1 (הכי נדיף) רגיסטרים של CPU, RAM, טבלאות ניתוב שניות
2 חיבורי רשת, תהליכים, קבצים פתוחים דקות
3 דיסק (עותק bit-for-bit) שעות–ימים
4 לוגים ו-audit trails ימים (רוטציה)
5 גיבויים מחוץ לאתר שבועות

סדר הנדיפות (RFC 3227) הוא תקן שאנו מקפידים עליו בקפדנות. ב-70% מהאירועים, ראיות קריטיות נמצאות ב-RAM, שחי רק שניות לאחר אובדן חשמל. לכן, האיסוף מתחיל ב-dump זיכרון: עיכוב של 30 שניות מפחית את הסיכוי לזהות IOCs ב-40%.

כיצד נאספות הראיות

האיסוף מתחיל ב-dump של RAM. אנו משתמשים ב-LiME—מודול kernel שמורכב לגרסת המערכת היעד. במקביל, אנו לוכדים את מצב הרשת והתהליכים:

# Дамп памяти через LiME
insmod /path/to/lime-$(uname -r).ko "path=/mnt/evidence/ram.lime format=lime"
# Volatile data
ss -tulpn > /mnt/evidence/network_connections.txt
ps auxf > /mnt/evidence/processes.txt
netstat -anp > /mnt/evidence/netstat.txt

לאחר מכן אנו לוקחים תמונת דיסק bit-for-bit עם hashing:

# Создание образа с хешированием
sha256sum /dev/sda > /mnt/evidence/sda-hash-before.txt
dd if=/dev/sda of=/mnt/evidence/sda.img bs=4M conv=noerror,sync status=progress
sha256sum /mnt/evidence/sda.img > /mnt/evidence/sda-hash-image.txt

לסביבות ענן (AWS), אנו יוצרים snapshot דרך API:

INSTANCE_ID="i-0abc123def456"
VOLUME_ID=$(aws ec2 describe-instances --instance-ids $INSTANCE_ID \
  --query 'Reservations[*].Instances[*].BlockDeviceMappings[*].Ebs.VolumeId' \
  --output text)
aws ec2 create-snapshot --volume-id $VOLUME_ID \
  --description "FORENSICS: Security incident - DO NOT DELETE"

כיצד מובטחת שרשרת המסירה

כל artifact שנאסף עובר hashing (SHA-256) ומתועד ביומן. הגישה לתמונה היא לקריאה בלבד, העברה דרך SSH עם הצפנה. דוגמה לרישום:

EVIDENCE LOG ============
Incident: INC-XXXX-001
Date: [дата инцидента]
Analyst: John Smith
14:32 UTC - RAM dump collected from prod-web-01
File: /evidence/ram.lime
Size: 16106127360 bytes
SHA256: a3f5b2c1d4e6f789...
Collected by: John Smith, witnessed by: Jane Doe

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

כיצד מנותחים ה-artifacts

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

# Монтируем образ read-only
mount -o ro,noexec,nodev /mnt/evidence/sda.img /mnt/analysis
# Строим filesystem timeline
find /mnt/analysis -printf '%T@ %Tc %p\n' | sort -n > /mnt/evidence/filesystem-timeline.txt
# Восстанавливаем удалённые файлы
fls -r -d /mnt/evidence/sda.img > /mnt/evidence/deleted-files.txt
mactime -b /mnt/analysis/bodyfile.txt -d > /mnt/evidence/mactime-timeline.csv

לוגים וחיבורי רשת משחזרים את שרשרת האירועים. מ-auditd אנו מחלצים פקודות של משתמש ספציפי, מ-Zeek—שאילתות DNS וחיבורי HTTP לדומיינים חשודים. חותמת הזמן של כל artifact נבדקת מול ציר הזמן של האירוע. ב-95% מהמקרים, אנו משחזרים את תמונת ההתקפה המלאה תוך 48 שעות.

מה כלול

  • דוח מפורט עם ציר זמן מלא של התוקף, רשימת משאבים שנפגעו ו-IOCs.
  • תמונות עם hashing של RAM ודיסקים עם שרשרת מסירה ניתנת לאימות.
  • המלצות לתיקון פרצות ומניעת הישנות.
  • ייעוץ על התוצאות עם אפשרות לעדות בבית משפט.
  • הבטחת סודיות—כל הנתונים מועברים בערוצים מאובטחים, נחתם NDA.

יתרונות של ניתוח פורנזי בזמן

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

טעויות נפוצות באיסוף ראיות

אתחול המערכת לפני איסוף נתונים נדיפים—מאבד זיכרון ותהליכים. שימוש בכלים סטנדרטיים שעלולים לשנות מטא-דאטה של קבצים (למשל, tar במקום dd). חוסר hashing בזמן האיסוף—שרשרת המסירה הופכת לבלתי ניתנת לאימות. איסוף לוגים ללא שמירת חותמות הזמן המקוריות של המערכת. שגיאות אלו נמנעות באמצעות שימוש ב-playbook מוכח ומומחים מוסמכים.

לוחות זמנים משוערים

היקף לוח זמנים
שרת יחיד שנפרץ 2–5 ימים
אירוע המערב מספר מערכות 1–3 שבועות
אירוע מורכב עם דרישות משפטיות 3–6 שבועות

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