Container Threat Detection conceptual overview

Stay organized with collections Save and categorize content based on your preferences.

This page provides a high-level overview of Container Threat Detection concepts and features.

What is Container Threat Detection?

Container Threat Detection is a built-in service for the Security Command Center Premium tier that continuously monitors the state of Container-Optimized OS node images. The service evaluates all changes and remote access attempts to detect runtime attacks in near-real time.

Container Threat Detection detects the most common container runtime attacks and alerts you in Security Command Center and, optionally, in Cloud Logging. Container Threat Detection includes several detection capabilities, including suspicious binaries and libraries, and uses natural language processing (NLP) to detect malicious bash scripts.

How Container Threat Detection works

Container Threat Detection detection instrumentation collects low-level behavior in the guest kernel and executed bash scripts. The following is the execution path when events are detected:

  1. Event information and information that identifies the container is passed for analysis through user mode to a detector service. Event export is configured automatically when Container Threat Detection is enabled.

  2. The detector service analyzes events to determine whether an event is indicative of an incident. The content of bash scripts is analyzed with NLP to determine if executed scripts are malicious.

  3. If the detector service identifies an incident, the incident is written as a finding in Security Command Center and, optionally, to Cloud Logging.

    • If the detector service doesn't identify an incident, then finding information isn't stored.
    • All data in the kernel and detector service is ephemeral and isn't persistently stored.

You can view finding details in the Security Command Center dashboard and investigate finding information. Your ability to view and edit findings is determined by the roles you are granted. For more information on Security Command Center roles, see Access control.

Container Threat Detection detectors

Container Threat Detection includes the following detectors:

Detector Description Inputs to detection
Added Binary Executed

A binary that was not part of the original container image was executed.

If an added binary is executed by an attacker, it's a possible sign that an attacker has control of the workload and they are executing arbitrary commands.

The detector looks for a binary being executed that was not part of the original container image, or was modified from the original container image.
Added Library Loaded

A library that was not part of the original container image was loaded.

If an added library is loaded, it's a possible sign that an attacker has control of the workload and they are executing arbitrary code.

The detector looks for a library being loaded that was not part of the original container image, or was modified from the original container image.
Malicious Script Executed A machine learning model identified an executed bash script as malicious. Attackers can use bash scripts to transfer tools or other files from an external system into a compromised environment and execute commands without binaries. The detector uses NLP techniques to evaluate the content of an executed bash script. Since this approach is not based on signatures, detectors can identify known and unknown malicious scripts.
Malicious URL Observed Container Threat Detection observed a malicious URL in the argument list of a running process. The detector checks URLs that are observed in the argument list of running processes against the lists of unsafe web resources that are maintained by the Google Safe Browsing service. If a URL is incorrectly classified as phishing or malware, report it to Safebrowsing at Reporting Incorrect Data.
Reverse Shell

A process started with stream redirection to a remote connected socket.

With a reverse shell, an attacker can communicate from a compromised workload to an attacker-controlled machine. The attacker can then command and control the workload to perform desired actions, for example, as part of a botnet.

The detector looks for stdin bound to a remote socket.

What's next