Command and Control: Piped Encoded Code Execution

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

סקירה כללית

‫Command and Control: Piped Encoded Code Execution מזהה מתי הפלט של פקודה base64 --decode מועבר ישירות לפרשן של מעטפת כמו python,‏ perl,‏ php,‏ ruby או ssh.

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

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

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

איך מגיבים

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

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

  1. פותחים Command and Control: Piped Encoded Code Executionממצא לפי ההוראות במאמר בדיקת ממצאים. חלונית הפרטים של הממצא נפתחת בכרטיסייה סיכום.

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

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

  3. בתצוגת הפרטים של הממצא, לוחצים על הכרטיסייה JSON.

  4. שימו לב לשדות הבאים ב-JSON.

    • resource:
      • ‫project_display_name: השם של הפרויקט שמכיל את האשכול.
    • finding:
      • processes:
      • binary:
        • ‫path: הנתיב המלא של הקובץ הבינארי שהופעל.
      • ‫args: הארגומנטים שסופקו במהלך ההרצה של הקובץ הבינארי.
    • sourceProperties:
      • ‫Pod_Namespace: השם של מרחב השמות של ה-Pod ב-Kubernetes.
      • ‫Pod_Name: השם של ה-Pod ב-GKE.
      • ‫Container_Name: השם של הקונטיינר המושפע.
      • ‫Container_Image_Uri: השם של קובץ האימג' בקונטיינר שפורס.
      • ‫VM_Instance_Name: שם הצומת ב-GKE שבו הופעל ה-Pod.

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

שלב 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. מגדירים את בחירת טווח זמן לתקופה הרצויה.

  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

  1. אחזור הקובץ הבינארי שהופעל:

    kubectl cp \
      POD_NAMESPACE/POD_NAME:PROCESS_BINARY_FULLPATH \
      -c CONTAINER_NAME \
      LOCAL_FILE

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

  2. מריצים את הפקודה הבאה כדי להתחבר לסביבת הקונטיינר:

    kubectl exec \
      --namespace=POD_NAMESPACE \
      -ti POD_NAME \
      -c CONTAINER_NAME \
      -- /bin/sh

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

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

  1. כדאי לעיין בערכים של מסגרת MITRE ATT&CK לגבי סוג הממצא הזה: Command and Control (שליטה וניהול).
  2. כדי לפתח תוכנית תגובה, משלבים את תוצאות החקירה עם מחקר של MITRE.

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

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

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

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