ביצוע: קובץ בינארי זדוני שונה הופעל

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

סקירה כללית

קובץ בינארי שהופעל, עם הקובץ הבינארי:

  • כלול בקובץ אימג' של הקונטיינר המקורי.
  • השתנה במהלך זמן הריצה של מאגר התגים.
  • זוהה כתוכן זדוני על סמך מודיעין איומי סייבר.

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

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

איך מגיבים

כדי להגיב לממצא הזה:

שלב 1: בדיקת פרטי הממצא

  1. פותחים ממצא Execution: Modified Malicious Binary Executed לפי ההוראות במאמר בדיקת ממצאים. חלונית הפרטים של הממצא נפתחת בכרטיסייה סיכום.

  2. בכרטיסייה סיכום, בודקים את המידע בקטעים הבאים:

    • מה זוהה, במיוחד השדות הבאים:
      • Program binary: הנתיב המוחלט של הקובץ הבינארי ששונה.
      • ארגומנטים: הארגומנטים שסופקו כשמפעילים את הקובץ הבינארי ששונה.
      • מאגרים: השם של המאגר שמושפע.
      • ה-URI של הקונטיינרים: השם של קובץ האימג' של הקונטיינר שנפרס.
    • מקור המידע שהושפע, במיוחד השדות הבאים:
      • שם המשאב המלא: שם המשאב המלא של האשכול, כולל מספר הפרויקט, המיקום ושם האשכול.
    • קישורים רלוונטיים, במיוחד השדות הבאים:
      • אינדיקטור של VirusTotal: קישור לדף הניתוח של VirusTotal.

  3. לוחצים על JSON ורושמים את השדות הבאים:

    • sourceProperties:
      • ‫VM_Instance_Name: השם של צומת GKE שבו ה-Pod הופעל.

שלב 2: בדיקת האשכול והצומת

  1. נכנסים לדף Kubernetes clusters במסוף Google Cloud .

    מעבר אל Kubernetes clusters

  2. בסרגל הכלים של המסוף Google Cloud , בוחרים את הפרויקט שמופיע ב-resource.project_display_name, אם צריך.

  3. בוחרים את האשכול שמופיע בשורה Resource full name (השם המלא של המשאב) בכרטיסייה Summary (סיכום) של פרטי הממצא. שימו לב למטא-נתונים לגבי האשכול והבעלים שלו.

  4. לוחצים על הכרטיסייה Nodes. בוחרים את הצומת שמופיע ב-VM_Instance_Name.

  5. לוחצים על הכרטיסייה פרטים ורושמים את ההערה container.googleapis.com/instance_id.

שלב 3: בדיקת הפוד

  1. נכנסים לדף Kubernetes Workloads במסוף Google Cloud .

    עוברים אל Kubernetes Workloads

  2. בסרגל הכלים של המסוף Google Cloud , בוחרים את הפרויקט שמופיע ב-resource.project_display_name, אם צריך.

  3. במידת הצורך, מסננים לפי האשכול שמופיע בשורה Resource full name בכרטיסייה Summary בפרטי הממצא, ולפי מרחב השמות של ה-Pod שמופיע ב-Pod_Namespace.

  4. בוחרים את ה-Pod שמופיע ב-Pod_Name. שימו לב למטא-נתונים לגבי ה-Pod והבעלים שלו.

שלב 4: בדיקת היומנים

  1. במסוף Google Cloud , עוברים אל Logs Explorer.

    כניסה לדף Logs Explorer

  2. בסרגל הכלים של המסוף Google Cloud , בוחרים את הפרויקט שמופיע ב-resource.project_display_name, אם צריך.

  3. מגדירים את Select time range לתקופה הרצויה.

  4. בדף שנטען, מבצעים את הפעולות הבאות:

    1. כדי למצוא יומנים של Pod עבור Pod_Name, משתמשים במסנן הבא:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
    2. כדי למצוא יומני ביקורת של אשכולות, משתמשים במסנן הבא:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
    3. כדי למצוא יומני מסוף של צומת GKE, משתמשים במסנן הבא:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

שלב 5: בדיקת קונטיינר שפועל

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

  1. נכנסים למסוף Google Cloud .

    פתיחת מסוף Google Cloud

  2. בסרגל הכלים של המסוף Google Cloud , בוחרים את הפרויקט שמופיע ב-resource.project_display_name, אם צריך.

  3. לוחצים על הפעלת Cloud Shell.

  4. מריצים את הפקודות הבאות כדי לקבל את פרטי הכניסה של GKE לאשכול.

    באשכולות אזוריים:

      gcloud container clusters get-credentials cluster_name --zone location --project project_name

    באשכולות אזוריים:

      gcloud container clusters get-credentials cluster_name --region location --project project_name

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫cluster_name: האשכול שמופיע ב-resource.labels.cluster_name
    • ‫location: המיקום שמופיע ב-resource.labels.location
    • ‫project_name: שם הפרויקט שמופיע ב-resource.project_display_name

  5. אחזור של קובץ בינארי זדוני שעבר שינוי:

      kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file

    מחליפים את local_file בנתיב מקומי לאחסון הקובץ הבינארי הזדוני ששונה.

  6. מתחברים לסביבת המאגר:

      kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh

    כדי להשתמש בפקודה הזו, צריך להתקין מעטפת במיקום /bin/sh במאגר.

שלב 6: מחקר על שיטות תקיפה ותגובה

  1. כדאי לעיין ברשומות של מסגרת MITRE ATT&CK לגבי סוג הממצא הזה: Ingress Tool Transfer (העברת כלי כניסה), Native API (API מקורי).
  2. כדי לבדוק את ערך הגיבוב (hash) ‏SHA-256 של הקובץ הבינארי שסומן כזדוני ב-VirusTotal, לוחצים על הקישור באינדיקטור של VirusTotal. ‫VirusTotal הוא שירות בבעלות Alphabet שמספק הקשר לגבי קבצים, כתובות URL, דומיינים וכתובות IP שעלולים להיות זדוניים.
  3. כדי לפתח תוכנית תגובה, משלבים את תוצאות החקירה עם המחקר של MITRE והניתוח של VirusTotal.

שלב 7: מטמיעים את התגובה

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

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

המאמרים הבאים