> [!NOTE]
> Premium and Enterprise (Deprecated) [service tiers](https://docs.cloud.google.com/security-command-center/docs/service-tiers)

> [!CAUTION]
> The Security Command Center Enterprise service tier will shut down on May 21, 2027. If your organization uses the Enterprise service tier, then the organization will automatically move to the Premium service tier on or after May 21, 2027. Contact your account representative or a [Google Cloud sales specialist](https://cloud.google.com/contact) if you have questions.

This document describes a threat finding type in Security Command Center. Threat findings are generated by
[threat detectors](https://docs.cloud.google.com/security-command-center/docs/concepts-security-sources#threats) when they detect
a potential threat in your cloud resources. For a full list of available threat findings, see [Threat findings index](https://docs.cloud.google.com/security-command-center/docs/threat-findings-index).

## Overview

A program was executed with an HTTP proxy environment variable that is
disallowed. This activity can indicate an attempt to bypass security controls,
redirect traffic for malicious purposes, or exfiltrate data through
unauthorized channels. Attackers may configure disallowed HTTP proxies to
intercept sensitive information, route traffic through malicious servers, or
establish covert communication channels. Detecting the execution of programs
with these environment variables is crucial for maintaining network security and
preventing data breaches.

[Container Threat Detection](https://docs.cloud.google.com/security-command-center/docs/concepts-container-threat-detection-overview) 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 `Execution: Program Run with Disallowed HTTP Proxy Env` finding as
   directed in [Reviewing findings](https://docs.cloud.google.com/security-command-center/docs/how-to-investigate-threats#reviewing_findings). The details panel for
   the finding opens to the **Summary** tab.

2. On the **Summary** tab, 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](https://docs.cloud.google.com/apis/design/resource_names) of the cluster including the project number, location, and cluster name.
3. In the detail view of the finding, click the **JSON** tab.

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 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 clusters** page.

   [Go to Kubernetes clusters](https://console.cloud.google.com/kubernetes/list)

   <br />

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 name** row in the
   **Summary** tab of the finding details. Note any metadata about
   the cluster and its owner.

4. Click the **Nodes** tab. Select the node listed in `VM_Instance_Name`.

5. Click the **Details** tab and note the
   `container.googleapis.com/instance_id` annotation.

### Step 3: Review Pod

1. In the Google Cloud console, go to the **Kubernetes Workloads** page.

   [Go to Kubernetes Workloads](https://console.cloud.google.com/kubernetes/workload)

   <br />

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

3. Filter on the cluster listed on the **Resource full name** row in the
   **Summary** tab of the finding details and the Pod namespace
   listed in `Pod_Namespace`, if necessary.

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](https://console.cloud.google.com/logs/query)
2. On the Google Cloud console toolbar, select the project listed in
   `resource.project_display_name`, if necessary.

3. Set **Select time range** to 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 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](https://console.cloud.google.com/)
2. On the Google Cloud console toolbar, select the project listed in
   `resource.project_display_name`, if necessary.

3. Click **Activate Cloud Shell**
   ![](https://docs.cloud.google.com/static/security-command-center/images/activate-cloud-shell.svg)

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`.
5. Retrieve the executed binary:

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

   Replace `local_file` with a local file path to store the
   added binary.
6. 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: [User Execution](https://attack.mitre.org/techniques/T1204/).
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 with the compromised container.
- Stop or [delete](https://docs.cloud.google.com/container-registry/docs/managing#deleting_images) the compromised container and replace it with a [new container](https://docs.cloud.google.com/compute/docs/containers).

## What's next

- Learn [how to work with threat
  findings in Security Command Center](https://docs.cloud.google.com/security-command-center/docs/how-to-investigate-threats).
- Refer to the [Threat findings index](https://docs.cloud.google.com/security-command-center/docs/threat-findings-index).
- Learn how to [review a
  finding](https://docs.cloud.google.com/security-command-center/docs/how-to-investigate-threats#reviewing_findings) through the Google Cloud console.
- Learn about the [services that
  generate threat findings](https://docs.cloud.google.com/security-command-center/docs/concepts-security-sources#threats).