Scanning - CraftedSignal Threat Feedhttps://feed.craftedsignal.io/tags/scanning/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioWed, 03 Jan 2024 10:00:00 +0000Kubernetes Scanning by Unauthenticated IP Addresshttps://feed.craftedsignal.io/briefs/2024-01-03-kubernetes-scanning/Wed, 03 Jan 2024 10:00:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-01-03-kubernetes-scanning/Detects potential scanning activities within a Kubernetes environment by identifying multiple unauthorized access attempts (HTTP 403 responses) from unauthenticated IP addresses in Kubernetes audit logs, potentially indicating vulnerability probing or exploitation attempts.This 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 within the Kubernetes infrastructure. Successful scanning may allow attackers to identify exposed services, misconfigurations, or vulnerabilities that can be further exploited to gain unauthorized access, escalate privileges, or disrupt services. The detection focuses on identifying patterns indicative of automated scanning rather than legitimate user activity.

Attack Chain

  1. Attacker identifies a Kubernetes cluster as a potential target.
  2. Attacker attempts to access various Kubernetes API endpoints without proper authentication, resulting in HTTP 403 errors.
  3. Kubernetes API server logs the unauthorized access attempts in the audit logs, including the source IP address, requested URI, and response code.
  4. The detection analytic monitors Kubernetes audit logs for multiple 403 errors originating from the same unauthenticated IP address.
  5. The analytic aggregates access attempts by source IP, country, and city, counting the number of 403 responses.
  6. If the count of 403 responses from a single IP exceeds a threshold (e.g., 5), the IP is flagged as potentially engaged in scanning.
  7. Security team investigates the flagged IP to determine the legitimacy of the activity.
  8. If the activity is confirmed as malicious scanning, appropriate actions are taken to block the IP and further investigate any potential vulnerabilities.

Impact

Unsuccessful exploitation attempts may precede successful ones. Kubernetes scanning activity often represents reconnaissance efforts to identify exploitable entry points. If successful, attackers may gain unauthorized access to sensitive data, escalate privileges, or disrupt critical services running within the Kubernetes cluster. This activity can lead to data breaches, service outages, and reputational damage.

Recommendation

  • Enable Kubernetes audit logging to capture API server requests, which is essential for this detection to function.
  • Deploy the provided Sigma rule to your SIEM and tune the threshold (count > 5) based on your environment's baseline.
  • Use the kube_audit macro to standardize your Kubernetes audit log data source for use with the Sigma rule.
  • Investigate any alerts generated by the Sigma rule to determine the legitimacy of the scanning activity and take appropriate remediation steps.
]]>mediumadvisorykubernetesscanningcloudKubernetes Access Scanning Detectionhttps://feed.craftedsignal.io/briefs/2024-01-kubernetes-access-scanning/Tue, 02 Jan 2024 12:00:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-01-kubernetes-access-scanning/This analytic detects potential reconnaissance activities within a Kubernetes environment by identifying repeated failed access attempts or unusual API requests from unauthenticated users based on Kubernetes audit logs, indicating a potential attacker's preliminary reconnaissance.This detection analytic focuses on identifying potential scanning activities targeting Kubernetes environments. It leverages Kubernetes audit logs to detect unauthorized access attempts, probing of public APIs, and potential attempts to exploit known vulnerabilities. The analytic specifically monitors for repeated failed access attempts (HTTP 403 errors) originating from unauthenticated users. The goal is to identify attackers performing preliminary reconnaissance to gather information about the Kubernetes system, which could precede more serious malicious activities. This activity is significant because successful reconnaissance can provide attackers with the information they need to gain unauthorized access to sensitive systems or data within the cluster. The detection logic uses events where "user.groups{}"="system:unauthenticated" and "responseStatus.code"=403, aggregated by source IP to identify hosts exceeding a threshold of failed requests.

Attack Chain

  1. Initial Access Attempt: An attacker attempts to access the Kubernetes API server without proper authentication, potentially using default credentials or exploiting misconfigurations.
  2. Unauthorized API Request: The attacker sends a request to a protected API endpoint, resulting in a 403 Forbidden error.
  3. Reconnaissance Scanning: The attacker repeats the unauthorized API requests across multiple endpoints or using various techniques to map the Kubernetes environment.
  4. Audit Log Generation: Each failed access attempt is logged as an audit event within the Kubernetes audit logs, recording details such as the source IP, requested URI, and response code.
  5. Log Aggregation and Analysis: Security monitoring tools, like Splunk, collect and aggregate the Kubernetes audit logs.
  6. Threshold Trigger: The analytic detects a source IP exceeding a defined threshold (e.g., 5) of failed access attempts (403 errors) from unauthenticated users within a specific timeframe.
  7. Alert Generation: An alert is triggered, indicating potential scanning activity originating from the identified source IP.
  8. Further Exploitation: If successful, the attacker leverages the information gathered during the scanning phase to exploit vulnerabilities, escalate privileges, or deploy malicious workloads within the Kubernetes cluster.

Impact

Successful Kubernetes access scanning allows attackers to map the internal structure of the cluster, identify exposed services, and discover potential vulnerabilities. This reconnaissance phase can lead to unauthorized access to sensitive data, compromise of containerized applications, and lateral movement within the cluster. Depending on the compromised application's function and data access, the attacker could steal secrets, sensitive data, or pivot to other internal systems. The impact can range from data breaches and service disruption to complete control over the Kubernetes cluster.

Recommendation

  • Enable Kubernetes audit logging to generate the required data source for this detection. Configure the audit policy to capture sufficient detail on API requests, including user identity, request URI, and response status (Kubernetes Audit).
  • Deploy the provided Sigma rules to your SIEM and tune the threshold (count > 5) based on your environment's baseline activity and acceptable false positive rate (Sigma Rules).
  • Investigate alerts triggered by the Sigma rules, focusing on the source IP address (src_ip) and the specific API requests made to determine the nature and intent of the scanning activity.
  • Block the identified scanning source IP addresses (sourceIPs{}) at your network perimeter or within your Kubernetes network policies to prevent further reconnaissance attempts.
  • Review and harden Kubernetes security configurations to minimize the attack surface and prevent unauthorized access to API endpoints (Kubernetes documentation).
]]>mediumadvisorykubernetesscanningreconnaissance