Command and Control: Piped Encoded Code Execution

This document describes a threat finding type in Security Command Center. Threat findings are generated by threat detectors when they detect a potential threat in your cloud resources. For a full list of available threat findings, see Threat findings index .

Overview

Command and Control: Piped Encoded Code Execution detects when the output of a base64 --decode command is directly piped to a shell interpreter like python , perl , php , ruby , or ssh .

When a threat is found outside of an expected workload, such as a CI/CD pipeline, this is a strong indication of malicious activity. Attackers routinely use this method to execute obfuscated scripts or commands. The base64 encoding hides the actual code being run, and piping it directly to an interpreter allows for immediate execution without writing the decoded script to disk, making it more stealthy.

We recommend that you always take immediate action on this finding when it occurs on an unexpected workload. Benign workloads use base64 encoding primarily to safely transfer binary data or data containing special characters through text-based systems and protocols that might otherwise corrupt the data. However, any code execution can directly impact and further compromise your system, so make sure that you always treat this finding as malicious until proven otherwise.

Container Threat Detection is the source of this finding.

How to respond

To respond to this finding, do the following:

Step 1: Review finding details

1. Open an Command and Control: Piped Encoded Code Execution finding as directed in Reviewing findings . The details panel for the finding opens to the Summarytab.

2. On the Summarytab, review the information in the following sections:

   • What was detected, especially the following fields:
     • Program binary: the absolute path of the executed binary.
     • Arguments: the arguments passed during binary execution.
   • Affected resource, especially the following fields:
     • Resource full name: the full resource name of the cluster including the project number, location, and cluster name.

3. In the detail view of the finding, click the JSONtab.

4. In the JSON, note the following fields.

   • resource :
     • project_display_name : the name of the project that contains the cluster.
   • finding :
     • processes :
     • binary :
       • path : the full path of the executed binary.
     • args : the arguments that were provided while executing the binary.
   • sourceProperties :
     • Pod_Namespace : the name of the Pod's Kubernetes namespace.
     • Pod_Name : the name of the GKE Pod.
     • Container_Name : the name of the affected container.
     • Container_Image_Uri : the name of the container image being deployed.
     • VM_Instance_Name : the name of the GKE node where the Pod was executed.

5. Identify other findings that occurred at a similar time for this container. Related findings might indicate that this activity was malicious, instead of a failure to follow best practices.

Step 2: Review cluster and node

1. In the Google Cloud console, go to the Kubernetes clusterspage.

   Go to Kubernetes clusters

2. On the Google Cloud console toolbar, select the project listed in resource.project_display_name , if necessary.

3. Select the cluster listed on the Resource full namerow in the Summarytab of the finding details. Note any metadata about the cluster and its owner.

4. Click the Nodestab. Select the node listed in VM_Instance_Name .

5. Click the Detailstab and note the container.googleapis.com/instance_id annotation.

Step 3: Review Pod

1. In the Google Cloud console, go to the Kubernetes Workloadspage.

   Go to Kubernetes Workloads

2. On the Google Cloud console toolbar, select the project listed in resource.project_display_name , if necessary.

3. Filter based on the cluster specified in the Resource full namerow of the Summarytab in the finding details and, if necessary, by the Pod namespace listed in Pod_Namespace .

4. Select the Pod listed in Pod_Name . Note any metadata about the Pod and its owner.

Step 4: Check logs

1. In the Google Cloud console, go to Logs Explorer.

   Go to Logs Explorer

2. On the Google Cloud console toolbar, select the project listed in resource.project_display_name , if necessary.

3. Set Select time rangeto the period of interest.

4. On the page that loads, do the following:

   1. Find Pod logs for Pod_Name by using the following filter:
      • resource.type="k8s_container"
      • resource.labels.project_id=" RESOURCE.PROJECT_DISPLAY_NAME "
      • resource.labels.location=" LOCATION "
      • resource.labels.cluster_name=" CLUSTER_NAME "
      • resource.labels.namespace_name=" POD_NAMESPACE "
      • resource.labels.pod_name=" POD_NAME "
   2. Find cluster audit logs by using the following filter:
      • logName="projects/ RESOURCE.PROJECT_DISPLAY_NAME /logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id=" RESOURCE.PROJECT_DISPLAY_NAME "
      • resource.labels.location=" LOCATION "
      • resource.labels.cluster_name=" CLUSTER_NAME "
      • POD_NAME
   3. Find GKE node console logs by using the following filter:
      • resource.type="gce_instance"
      • resource.labels.instance_id=" INSTANCE_ID "

Step 5: Investigate the running container

If the container is still running, it might be possible to investigate the container environment directly.

1. Go to the Google Cloud console.

   Open Google Cloud console

2. On the Google Cloud console toolbar, select the project listed in resource.project_display_name , if necessary.

3. Click Activate Cloud Shell

4. Obtain GKE credentials for your cluster by running the following commands.

   For zonal clusters:

    gcloud  
   container  
   clusters  
   get-credentials  
    CLUSTER_NAME 
     
    \ 
     
   --zone  
    LOCATION 
     
    \ 
     
   --project  
    PROJECT_NAME 
    
   

   For regional clusters:

    gcloud  
   container  
   clusters  
   get-credentials  
    CLUSTER_NAME 
     
    \ 
     
   --region  
    LOCATION 
     
    \ 
     
   --project  
    PROJECT_NAME 
    
   

Replace the following:

• CLUSTER_NAME : the cluster listed in resource.labels.cluster_name
• LOCATION : the location listed in resource.labels.location
• PROJECT_NAME : the project name listed in resource.project_display_name

1. Retrieve the executed binary:

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

   Replace LOCAL_FILE with a local path to store the downloaded binary.

2. Connect to the container environment by running the following command:

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

   This command requires the container to have a shell installed at /bin/sh .

Step 6: Research attack and response methods

1. Review MITRE ATT&CK framework entries for this finding type: Command and Control .
2. To develop a response plan, combine your investigation results with MITRE research.

Step 7: Implement your response

The following response plan might be appropriate for this finding, but might also impact operations. Carefully evaluate the information you gather in your investigation to determine the best way to resolve findings.

• Contact the owner of the project that contains the compromised container.
• Stop or delete the compromised container and replace it with a new container .

What's next

• Learn how to work with threat findings in Security Command Center .
• Refer to the Threat findings index .
• Learn how to review a finding through the Google Cloud console.
• Learn about the services that generate threat findings .