Kubernetes Scanning by Unauthenticated IP Address

SPLUNK detection rule by Patrick Bareiss, Splunk · Apache-2.0

The following analytic identifies potential scanning activities within a Kubernetes environment by unauthenticated IP addresses. It leverages Kubernetes audit logs to detect multiple unauthorized access attempts (HTTP 403 responses) from the same source IP. This activity is significant as it may indicate an attacker probing for vulnerabilities or attempting to exploit known issues. If confirmed malicious, such scanning could lead to unauthorized access, data breaches, or further exploitation of the Kubernetes infrastructure, compromising the security and integrity of the environment.

name: Kubernetes Scanning by Unauthenticated IP Address
id: f9cadf4e-df22-4f4e-a08f-9d3344c2165d
version: 10
creation_date: '2023-12-20'
modification_date: '2026-05-13'
author: Patrick Bareiss, Splunk
status: production
type: Anomaly
description: The following analytic identifies potential scanning activities within a Kubernetes environment by unauthenticated IP addresses. It leverages Kubernetes audit logs to detect multiple unauthorized access attempts (HTTP 403 responses) from the same source IP. This activity is significant as it may indicate an attacker probing for vulnerabilities or attempting to exploit known issues. If confirmed malicious, such scanning could lead to unauthorized access, data breaches, or further exploitation of the Kubernetes infrastructure, compromising the security and integrity of the environment.
data_source:
    - Kubernetes Audit
search: |-
    `kube_audit` "user.groups{}"="system:unauthenticated" "responseStatus.code"=403
      | iplocation sourceIPs{}
      | stats count values(userAgent) as userAgent values(user.username) as user.username values(user.groups{}) as user.groups{} values(verb) as verb values(requestURI) as requestURI values(responseStatus.code) as responseStatus.code values(responseStatus.message) as responseStatus.message values(responseStatus.reason) as responseStatus.reason values(responseStatus.status) as responseStatus.status
        BY sourceIPs{} Country City
      | where count > 5
      | rename sourceIPs{} as src_ip, user.username as user
      | `kubernetes_scanning_by_unauthenticated_ip_address_filter`
how_to_implement: The detection is based on data that originates from Kubernetes Audit logs. Ensure that audit logging is enabled in your Kubernetes cluster. Kubernetes audit logs provide a record of the requests made to the Kubernetes API server, which is crucial for monitoring and detecting suspicious activities. Configure the audit policy in Kubernetes to determine what kind of activities are logged. This is done by creating an Audit Policy and providing it to the API server. Use the Splunk OpenTelemetry Collector for Kubernetes to collect the logs. This doc will describe how to collect the audit log file https://github.com/signalfx/splunk-otel-collector-chart/blob/main/docs/migration-from-sck.md. When you want to use this detection with AWS EKS, you need to enable EKS control plane logging https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html. Then you can collect the logs from Cloudwatch using the AWS TA https://splunk.github.io/splunk-add-on-for-amazon-web-services/CloudWatchLogs/.
known_false_positives: No false positives have been identified at this time.
references:
    - https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/
drilldown_searches:
    - name: View the detection results for - "$user$"
      search: '%original_detection_search% | search  user = "$user$"'
      earliest_offset: $info_min_time$
      latest_offset: $info_max_time$
    - name: View risk events for the last 7 days for - "$user$"
      search: '| from datamodel Risk.All_Risk | search normalized_risk_object IN ("$user$") | 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: 7d
      latest_offset: "0"
intermediate_findings:
    entities:
        - field: user
          type: user
          score: 20
          message: Kubernetes scanning from ip $src_ip$
threat_objects:
    - field: src_ip
      type: ip_address
analytic_story:
    - Kubernetes Security
asset_type: Kubernetes
mitre_attack_id:
    - T1046
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: cloud
security_domain: network
tests:
    - name: True Positive Test
      attack_data:
        - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1046/kubernetes_scanning/kubernetes_scanning.json
          sourcetype: _json
          source: kubernetes
      test_type: unit

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

95d8e47b-b073-4449-a871-159e7920fbff

Propose edits, view related rules, and engage with the community through comments.

Executable code, not a declarative rule

This submission is arbitrary [[ currentRule.format ? currentRule.format.toUpperCase() : '' ]] code, not a declarative detection rule — review it as you would any script before running it, and note that it cannot be safely aggregated or auto-executed alongside YARA/Sigma/Suricata/CRS rules.

Rejected pattern present

[[ reason ]]

What does this mean?

Format & documentation suggestions

Not a security issue — this rule is valid and was accepted as-is. These are optional fields/conventions its own format recommends, mainly affecting its quality score and how well it documents itself for other reviewers.

[[ reason ]]

What do these messages mean?

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

[[ currentRule.title ]]

Community Discussion