במסמך הזה מתואר סוג של ממצא איום ב-Security Command Center. ממצאי האיומים נוצרים על ידי מזהי איומים כשהם מזהים איום פוטנציאלי במשאבי הענן שלכם. רשימה מלאה של ממצאי האיומים הזמינים מופיעה באינדקס של ממצאי האיומים.
סקירה כללית
זוהה תהליך שמפעיל כלי קומפילציה של קוד בסביבת קונטיינר. ההתנהגות הזו מצביעה על ניסיון פוטנציאלי לפתח או לקמפל תוכנה זדונית בתוך המאגר המבודד, אולי כדי להסתיר פעילויות זדוניות ולעקוף אמצעי בקרה מסורתיים לאבטחה שמבוססים על המארח. יריבים עשויים להשתמש בטכניקה הזו כדי ליצור כלים מותאמים אישית או לשנות קבצים בינאריים קיימים בסביבה פחות מפוקחת לפני פריסתם במערכת הבסיסית או ביעדים אחרים. אם קומפיילר קוד נמצא בקונטיינר, במיוחד אם זה לא צפוי, כדאי לבדוק את זה כי יכול להיות שזה מעיד על כך שתוקף מתכונן להחדיר דלתות אחוריות קבועות או לפגוע בתוכנת לקוח באמצעות קבצים בינאריים שעברו שינוי.
המקור של הממצא הזה הוא זיהוי איומים בקונטיינר.
איך מגיבים
כדי להגיב לממצא הזה:
שלב 1: בדיקת פרטי הממצא
פותחים ממצא של
Defense Evasion: Launch Code Compiler Tool In Containerלפי ההוראות במאמר בדיקת הממצאים. חלונית הפרטים של הממצא נפתחת בכרטיסייה סיכום.בכרטיסייה סיכום, בודקים את המידע בקטעים הבאים:
- מה זוהה, במיוחד השדות הבאים:
- קובץ בינארי של התוכנית: הנתיב המוחלט של הקובץ הבינארי שמופעל.
- ארגומנטים: הארגומנטים שהועברו במהלך הביצוע של הקובץ הבינארי.
- מקור המידע שהושפע, במיוחד השדות הבאים:
- שם המשאב המלא: שם המשאב המלא של האשכול, כולל מספר הפרויקט, המיקום ושם האשכול.
- מה זוהה, במיוחד השדות הבאים:
בתצוגת הפרטים של הממצא, לוחצים על הכרטיסייה JSON.
שימו לב לשדות הבאים ב-JSON.
resource:-
project_display_name: השם של הפרויקט שמכיל את האשכול.
-
finding:processes:binary:-
path: הנתיב המלא של הקובץ הבינארי שהופעל.
-
-
args: הארגומנטים שסופקו במהלך ההפעלה של הקובץ הבינארי.
sourceProperties:-
Pod_Namespace: השם של מרחב השמות של ה-Pod ב-Kubernetes. -
Pod_Name: השם של ה-Pod ב-GKE. -
Container_Name: השם של הקונטיינר המושפע. Container_Image_Uri: השם של קובץ אימג' של קונטיינר שפורס.-
VM_Instance_Name: השם של צומת GKE שבו ה-Pod הופעל.
-
זיהוי ממצאים אחרים שהתרחשו בזמן דומה במאגר הזה. ממצאים קשורים עשויים להצביע על כך שהפעילות הזו הייתה זדונית, במקום על אי-עמידה בשיטות המומלצות.
שלב 2: בדיקת האשכול והצומת
נכנסים לדף Kubernetes clusters במסוף Google Cloud .
בסרגל הכלים של המסוף Google Cloud , בוחרים את הפרויקט שמופיע ב-
resource.project_display_name, אם צריך.בוחרים את האשכול שמופיע בשורה Resource full name בכרטיסייה Summary בפרטי הממצא. שימו לב למטא-נתונים לגבי האשכול והבעלים שלו.
לוחצים על הכרטיסייה Nodes. בוחרים את הצומת שמופיע ב-
VM_Instance_Name.לוחצים על הכרטיסייה פרטים ורושמים את ההערה
container.googleapis.com/instance_id.
שלב 3: בדיקת הפוד
נכנסים לדף Kubernetes Workloads במסוף Google Cloud .
בסרגל הכלים של המסוף Google Cloud , בוחרים את הפרויקט שמופיע ב-
resource.project_display_name, אם צריך.אם צריך, מסננים לפי האשכול שמופיע בשורה Resource full name בכרטיסייה Summary בפרטי הממצא, ולפי מרחב השמות של ה-Pod שמופיע ב-
Pod_Namespace.בוחרים את ה-Pod שמופיע ב-
Pod_Name. שימו לב לכל מטא-נתונים לגבי ה-Pod והבעלים שלו.
שלב 4: בדיקת היומנים
במסוף Google Cloud , עוברים אל Logs Explorer.
בסרגל הכלים של המסוף Google Cloud , בוחרים את הפרויקט שמופיע ב-
resource.project_display_name, אם צריך.מגדירים את Select time range לתקופה הרצויה.
בדף שנטען, מבצעים את הפעולות הבאות:
- כדי למצוא יומנים של Pod עבור
Pod_Name, משתמשים במסנן הבא:resource.type="k8s_container"resource.labels.project_id="RESOURCE.PROJECT_DISPLAY_NAME"resource.labels.location="LOCATION"resource.labels.cluster_name="CLUSTER_NAME"resource.labels.namespace_name="POD_NAMESPACE"resource.labels.pod_name="POD_NAME"
- כדי למצוא יומני ביקורת של אשכול, משתמשים במסנן הבא:
logName="projects/RESOURCE.PROJECT_DISPLAY_NAME/logs/cloudaudit.googleapis.com%2Factivity"resource.type="k8s_cluster"resource.labels.project_id="RESOURCE.PROJECT_DISPLAY_NAME"resource.labels.location="LOCATION"resource.labels.cluster_name="CLUSTER_NAME"POD_NAME
- כדי למצוא יומני מסוף של צומת GKE, משתמשים במסנן הבא:
resource.type="gce_instance"resource.labels.instance_id="INSTANCE_ID"
- כדי למצוא יומנים של Pod עבור
שלב 5: בדיקת קונטיינר שפועל
אם הקונטיינר עדיין פועל, יכול להיות שאפשר לבדוק את סביבת הקונטיינר ישירות.
נכנסים למסוף Google Cloud .
בסרגל הכלים של המסוף Google Cloud , בוחרים את הפרויקט שמופיע ב-
resource.project_display_name, אם צריך.לוחצים על הפעלת Cloud Shell.
מריצים את הפקודות הבאות כדי לקבל את פרטי הכניסה של GKE לאשכול.
באשכולות אזוריים:
gcloud container clusters get-credentials CLUSTER_NAME \ --zone LOCATION \ --project PROJECT_NAMEבאשכולות אזוריים:
gcloud container clusters get-credentials CLUSTER_NAME \ --region LOCATION \ --project PROJECT_NAMEמחליפים את מה שכתוב בשדות הבאים:
-
CLUSTER_NAME: האשכול שמופיע ב-resource.labels.cluster_name -
LOCATION: המיקום שמופיע ב-resource.labels.location -
PROJECT_NAME: שם הפרויקט שמופיע ב-resource.project_display_name
-
אחזור הקובץ הבינארי שהופעל:
kubectl cp \ POD_NAMESPACE/POD_NAME:PROCESS_BINARY_FULLPATH \ -c CONTAINER_NAME \ LOCAL_FILEמחליפים את
local_fileבנתיב לקובץ מקומי שבו רוצים לאחסן את הקובץ הבינארי שנוסף.מריצים את הפקודה הבאה כדי להתחבר לסביבת הקונטיינר:
kubectl exec \ --namespace=POD_NAMESPACE \ -ti POD_NAME \ -c CONTAINER_NAME \ -- /bin/shכדי להשתמש בפקודה הזו, צריך להתקין מעטפת במיקום
/bin/shבמאגר.
שלב 6: מחקר על שיטות תקיפה ותגובה
- כדאי לעיין בערכים של מסגרת MITRE ATT&CK לגבי סוג הממצא הזה: Obfuscated Files or Information: Compile After Delivery.
- כדי לפתח תוכנית תגובה, משלבים את תוצאות החקירה עם מחקר של MITRE.
שלב 7: מטמיעים את התגובה
תוכנית התגובה הבאה עשויה להתאים לממצא הזה, אבל היא עלולה גם להשפיע על הפעולות. חשוב לבדוק בקפידה את המידע שאספתם במהלך הבדיקה כדי להבין מהי הדרך הטובה ביותר לפתור את הבעיות.
- צריך לפנות לבעלים של הפרויקט עם מאגר התגים שנפרץ.
- צריך להפסיק את השימוש במאגר התגים שנפרץ או למחוק אותו ולהחליף אותו במאגר תגים חדש.
המאמרים הבאים
- איך עובדים עם ממצאי איומים ב-Security Command Center
- אפשר לעיין באינדקס של ממצאי איומים.
- איך בודקים ממצא דרך מסוף Google Cloud .
- מידע על השירותים שמפיקים ממצאים לגבי איומים