Threat Detection

ARMO Platform's Cloud Application Detection & Response (CADR) feature enables users to have visibility into the runtime environment and respond to threats in real-time. Using eBPF probes together with Kubernetes and cloud context, Kubescape effectively monitors the runtime environment for any suspicious activity.

Navigate to the Threat Detection page, and you should see the following screen

In the top right corner, you have an indication of the clusters and accounts being monitored in your environment.
Below, you can find the different filters you can apply to narrow down the results.

Search incidents

You can search and filter incidents using a wide range of parameters to quickly find what you need. Standard filters include Account, Region, Cluster, Namespace, Workload, Severity, Threat, and more.

In addition, you can perform searches based on incident entities such as Process, File, DNS, Network, HTTP, or CloudAPI. To search by entity, use the free-text search with the format Entity:value
For example, entering File: wget will return incidents involving the wget file.

Free-Text Search by Incident Entities

In addition to filters such as Account, Region, Cluster, and Severity, you can search incidents by specific entities using the format:

Entity:value

Below are examples for each supported entity type:

• Process

  • process:bash → finds incidents where the bash process was executed

• File

  • file:wget → finds incidents involving the wget binary
  • file:/etc/passwd → finds incidents where the /etc/passwd file was accessed.

• DNS

  • DNS:evil.com → finds incidents where a DNS query was made to evil.com
  • DNS:api.example.com → finds incidents contacting api.example.com

• Network

  • network:192.168.1.10 → finds incidents with connections to/from this IP
  • network:443 → finds incidents involving traffic on port 443

• HTTP

  • HTTP:GET /login → finds incidents with HTTP GET requests to /login
  • HTTP:POST /api/v1/data → finds incidents with HTTP POST requests to /api/v1/data

• CloudAPI

  • CloudAPI:ec2:StartInstances → finds incidents where AWS EC2 instances were started
  • CloudAPI:s3:ListBuckets → finds incidents involving S3 bucket listing

Group Runtime Incidents by Context

Improve your investigation flow by organizing runtime incidents the way you need. Incidents can be automatically grouped by:

• Threat type
• Account
• Host
• Cluster
• Namespace
• Workload

You can also switch to an ungrouped (flat list) view whenever you want full visibility and granular control.

Why it matters
Grouping helps you quickly recognize attack patterns, isolate affected areas, and perform batch actions. This reduces triage time and makes incident response more efficient.

Manage Incident Status Lifecycle

Security incidents evolve as they are investigated and addressed. To help teams stay aligned, every runtime incident in the ARMO Platform has a lifecycle status that indicates where it stands in the response process. Keeping incident statuses up to date ensures better prioritization, ownership, and reporting.

Available Statuses

New incidents automatically start in the Open state.

How to update incident status

You can change an incident’s status from:

• The incident details view
• The incidents table (single or bulk edit)

Simply select Change Status and choose the appropriate lifecycle stage. Updates take effect immediately.

Filtering by status

Use the status filter in the incidents table to focus on what matters most:

• Keep attention on Open and Investigating incidents by default
• Explicitly filter for Resolved or Dismissed incidents when needed

Dismissed and resolved incidents are hidden from the default view to reduce noise and help analysts prioritize active work.

Why it matters

This lifecycle approach gives security teams a consistent method to:

• Prioritize high-impact issues
• Track progress across response efforts
• Avoid duplicate work across analysts
• Improve auditability of security operations

Keeping statuses updated strengthens communication and ensures the right incidents receive the right attention.

Bulk Edit Runtime Incidents

Managing a high volume of incidents should not slow down your investigations. You can now update the status of multiple incidents at once, helping you streamline triage and response.

What you can do

• Select one or more incidents directly from the table
• Apply a bulk action such as updating status to Active, Investigation, Resolved, or Dismissed
• Perform bulk updates in both grouped and ungrouped views
• Receive clear confirmation or error feedback after each action

How it works

• Use the checkboxes next to each incident to select multiple items
• A bulk action bar appears once at least one incident is selected
• Choose Change Status and select the desired state
• Confirm the update and the changes are applied instantly

Why it matters

This capability saves valuable time during investigations and improves operational efficiency. Analysts can focus on the incidents that matter most instead of repetitive manual updates.

Investigating an incident

Once you click on one of the incidents, you will see a screen similar to this:

In the graph, you see the flow of the attack and where it occurred, all the way up to the specific process.
You can click on the threat information to view more details about the threat and browse the various events related to the attack in the events list. Each event is clickable and will open a side panel with the relevant details.

How it works

The runtime threat detection engine is divided into three main detection components:

• Anomaly detection 🔎
• Behavior analysis 🧠
• Malware scanning 🐛

Anomaly Detection

The anomaly detection part is responsible for detecting any abnormal behavior in the runtime environment. It does this by recording the normal behavior of the application and comparing it to the current state. If any deviation is detected, the engine will raise an alert.

ARMO Platform observes containers during a customizable learning phase to understand the application's typical behavior. It then stores this information persistently in objects called ApplicationProfiles (see here) , capturing details such as file access, network connections, system calls, and other relevant data. This profile, stored as a Kubernetes Custom Resource (CR), serves as a benchmark for normal behavior. Once the learning phase concludes and the profile is established, ARMO Platform compares real-time application events coming from eBPF for deviations from this norm, triggering alerts upon detecting anomalies.

The durations for which the node agent will monitor a running container are set using the nodeAgent.config values in the Helm installation configuration.
Here are the default values:

nodeAgent:
  config:
    maxLearningPeriod: 24h 

To customize these values, you can set them when installing the chart:

--set nodeAgent.config.maxLearningPeriod=Xh

You can also define the learning period per workload by putting the kubescape.io/max-sniffing-time label on the Pod:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql
  labels:
    app: mysql
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        kubescape.io/max-sniffing-time: "5m"
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:latest

Behavioral Analysis

Additionally, ARMO Platform uses rules designed to identify well-known attack signatures. These rules are adept at uncovering various threats, such as unauthorized software executions that deviate from the original container image. For example: detection of unpackers in memory, reverse shell activities, and more. Users have the flexibility to create 'Rule Bindings'—specific instructions that inform ARMO Platform which rules should be applied to which Pods. This level of customization ensures that security measures are tailored to the unique needs of each Kubernetes deployment, enhancing the overall security posture and responsiveness of the system.

Malware Scanning

ARMO Platform can scan the nodes for malware using ClamAV, a popular open-source antivirus engine. ClamAV supports scanning of files, directories, and volumes, and can be configured to scan the entire node or only specific directories. You can read more about ClamAV here.

To save resources, ARMO Platform uses its own virus database which is a subset of the latest ClamAV virus database release adapted to the Kubernetes environment.

Viewing Alerts

Another way to view alerts outside of ARMO Platform you can use the following supported exporters:

Prometheus (Alertmanager)

--set nodeAgent.config.alertManagerExporterUrls=localhost:9093 or localhost:9093,localhost:9094

Syslog

--set nodeAgent.config.syslogExporterURL=localhost:514

HTTP

--set nodeAgent.config.httpExporterConfig.url=http://localhost:8080
# Optional
--set nodeAgent.config.httpExporterConfig.maxAlertsPerMinute=1000

STDOUT

--set nodeAgent.config.stdoutExporter=true

Rule Binding

The CR (Custom Resource) runtimerulealertbindings.kubescape.io is used to define the rules that should be enforced by the runtime threat detection & response engine. You can customize the bindings of the rules to the workloads by editing this object.
The CRD supports Kubernetes selectors to bind the rules to specific workloads.
By default all rules are applied on all workloads.

apiVersion: kubescape.io/v1
kind: RuntimeRuleAlertBinding
metadata:
  name: all-rules-all-pods
spec:
  namespaceSelector:
    matchExpressions:
      - key: "kubernetes.io/metadata.name"
        operator: "NotIn"
        values:
        - "kube-system"
        - "kube-public"
        - "kube-node-lease"
        - "kubeconfig"
        - "gmp-system"
        - "gmp-public"
  rules:
    - ruleName: "Unexpected process launched"
    - ruleName: "Unexpected file access"
      parameters:
        ignoreMounts: true
        ignorePrefixes: ["/proc", "/run/secrets/kubernetes.io/serviceaccount", "/var/run/secrets/kubernetes.io/serviceaccount", "/tmp"]
    - ruleName: "Unexpected system call"
    - ruleName: "Unexpected capability used"
    - ruleName: "Unexpected domain request"
    - ruleName: "Unexpected Service Account Token Access"
    - ruleName: "Kubernetes Client Executed"
    - ruleName: "Exec from malicious source"
    - ruleName: "Kernel Module Load"
    - ruleName: "Exec Binary Not In Base Image"
    - ruleName: "Malicious SSH Connection"
    - ruleName: "Fileless Execution"
    - ruleName: "XMR Crypto Mining Detection"
    - ruleName: "Exec from mount"
    - ruleName: "Crypto Mining Related Port Communication"
    - ruleName: "Crypto Mining Domain Communication"
    - ruleName: "Read Environment Variables from procfs"
    - ruleName: "eBPF Program Load"
    - ruleName: "Symlink Created Over Sensitive File"
    - ruleName: "Unexpected Sensitive File Access"
    - ruleName: "LD_PRELOAD Hook"
    - ruleName: "Hardlink Created Over Sensitive File"

Supply Chain Attacks (BETA)

ARMO Platform maintains a comprehensive view of both current and historical application profiles within the system. When an application, such as a Kubernetes deployment, is updated—typically through a new version of the container image—a new application profile is generated and uploaded to ARMO Platform.

ARMO Platform employs sophisticated rules to compare the new application profile with the previous one, enabling the detection of several key changes:

• New Processes: Identification of any newly introduced processes.
• New DNS Endpoints: Detection of new DNS endpoints being accessed.
• New External Network Endpoints: Identification of new external network connections.
• New Data Access Patterns: Recognition of new data being accessed.

These capabilities are crucial for identifying potential supply chain attacks, thereby enhancing the security and integrity of the system.

Anti-Tampering

The ARMO agent includes a robust anti-tampering feature designed to safeguard the integrity and functionality of the agent. This feature protects the agent from unauthorized modifications, ensuring that its security mechanisms remain intact and operational. By implementing advanced detection and prevention techniques, the ARMO agent can identify and mitigate tampering attempts, such as unauthorized changes to the agent’s code, configuration, or operational state. This ensures that the agent consistently performs its security functions without interference, providing reliable protection for your application environments.