splunk_escuAnomaly

Cisco Isovalent - Non Allowlisted Image Use

The following analytic detects use of container images that fall outside an approved allowlist, leveraging Cisco Isovalent/Tetragon runtime telemetry (image name and workload identity). Adversaries commonly introduce untrusted or newly published images to deploy tooling, establish persistence, or abuse supply‑chain trust. This behavior may indicate image pulls from unauthorized registries, execution of unvetted software, or a drift from established deployment baselines. Extra scrutiny is warranted for namespaces and workloads that normally source images from restricted registries, and for pods that suddenly begin running images outside expected prefixes. Maintain an environment‑specific allowlist via the macro `cisco_isovalent_allowed_images` (for example, allow trusted registries/prefixes such as ImageName="gcr.io/org/*", "registry.local/*", or "myco/*") and keep it updated as new baseline images are introduced. This analytic alerts on images NOT matching the allowlist.

MITRE ATT&CK

T1204.003

Detection Query

`cisco_isovalent_process_exec` pod_name!=""
| search NOT `cisco_isovalent_allowed_images`
| stats count
        min(_time) as firstTime
        max(_time) as lastTime
    by pod_image_name pod_namespace pod_name process_name cluster_name
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| `cisco_isovalent___non_allowlisted_image_use_filter`

Author

Bhavin Patel, Splunk

Created

2026-03-10

Data Sources

Cisco Isovalent Process Exec

References

Tags

Cisco Isovalent Suspicious Activity

Raw Content

name: Cisco Isovalent - Non Allowlisted Image Use
id: 9f2b7b1d-6c2f-4f2d-9a8b-8a1d7c5f2e11
version: 3
date: '2026-03-10'
author: Bhavin Patel, Splunk
status: production
type: Anomaly
description: |
    The following analytic detects use of container images that fall outside an approved
    allowlist, leveraging Cisco Isovalent/Tetragon runtime telemetry (image name and
    workload identity). Adversaries commonly introduce untrusted or newly published
    images to deploy tooling, establish persistence, or abuse supply‑chain trust. This
    behavior may indicate image pulls from unauthorized registries, execution of
    unvetted software, or a drift from established deployment baselines. Extra scrutiny
    is warranted for namespaces and workloads that normally source images from restricted
    registries, and for pods that suddenly begin running images outside expected
    prefixes.
    Maintain an environment‑specific allowlist via the macro `cisco_isovalent_allowed_images`
    (for example, allow trusted registries/prefixes such as ImageName="gcr.io/org/*",
    "registry.local/*", or "myco/*") and keep it updated as new baseline images are
    introduced. This analytic alerts on images NOT matching the allowlist.
data_source:
    - Cisco Isovalent Process Exec
search: |
    `cisco_isovalent_process_exec` pod_name!=""
    | search NOT `cisco_isovalent_allowed_images`
    | stats count
            min(_time) as firstTime
            max(_time) as lastTime
        by pod_image_name pod_namespace pod_name process_name cluster_name
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `cisco_isovalent___non_allowlisted_image_use_filter`
how_to_implement: The detection is based on process execution data generated by Cisco Isovalent Runtime Security. Ensure that Isovalent Runtime Security is deployed and configured in your Kubernetes environment to emit process_exec events. Configure the Cisco Security Cloud TA to collect these logs via HTTP Event Collector (HEC) and normalize them into the Splunk Common Information Model. This integration ensures that all relevant pod, container, and process activity is captured for monitoring and detection of suspicious behavior. Create and maintain an environment‑specific macro named`cisco_isovalent_allowed_images` that returns true for approved images, for example:(ImageName="gcr.io/org/app:*" OR ImageName="registry.local/*" OR ImageName="myco/*"). The search alerts on images NOT matching that allowlist. Tune by namespace or team as needed.
known_false_positives: New legitimate images during rollouts or blue/green deployments may appear until the allowlist is updated. Coordinate with platform/DevOps teams to synchronize allowlist changes.
references:
    - https://dev.to/thenjdevopsguy/attacking-a-kubernetes-cluster-enter-red-team-mode-2onj
    - https://www.reddit.com/r/kubernetes/comments/l6e5yr/one_of_our_kubernetes_containers_was_compromised/
drilldown_searches:
    - name: View the detection results for - "$pod_name$"
      search: '%original_detection_search% | search pod_name = "$pod_name$"'
      earliest_offset: $info_min_time$
      latest_offset: $info_max_time$
    - name: View risk events for the last 7 days for - "$pod_name$"
      search: '| from datamodel Risk.All_Risk | search normalized_risk_object IN ("$pod_name$") starthoursago=168  | stats count min(_time) as firstTime max(_time) as lastTime values(search_name) as "Search Name" values(risk_message) as "Risk Message" values(analyticstories) as "Analytic Stories" values(annotations._all) as "Annotations" values(annotations.mitre_attack.mitre_tactic) as "ATT&CK Tactics" by normalized_risk_object | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`'
      earliest_offset: $info_min_time$
      latest_offset: $info_max_time$
rba:
    message: Non Allowlisted image [$pod_image_name$] used by pod [$pod_name$] in the cluster [$cluster_name$]
    risk_objects:
        - field: pod_name
          type: system
          score: 20
    threat_objects:
        - field: process_name
          type: process_name
tags:
    analytic_story:
        - Cisco Isovalent Suspicious Activity
    asset_type: Kubernetes
    mitre_attack_id:
        - T1204.003
    product:
        - Splunk Enterprise
        - Splunk Enterprise Security
        - Splunk Cloud
    security_domain: network
tests:
    - name: True Positive Test
      attack_data:
        - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/cisco_isovalent/cisco_isovalent.log
          source: not_applicable
          sourcetype: cisco:isovalent:processExec