Kubernetes Direct API Request via Curl or Wget

  1[metadata]
  2creation_date = "2025/06/23"
  3integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
  4maturity = "production"
  5updated_date = "2025/07/07"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10This rule monitors for the execution of curl or wget commands that directly access Kubernetes API endpoints,
 11which may indicate an attempt to interact with Kubernetes resources in a potentially unauthorized manner. This
 12technique is often used by adversaries to gather information about the Kubernetes environment, such as secrets,
 13config maps, and other sensitive data, without using the official Kubernetes client tools such as "kubectl".
 14"""
 15from = "now-9m"
 16index = [
 17    "endgame-*",
 18    "logs-crowdstrike.fdr*",
 19    "logs-endpoint.events.process*",
 20    "logs-sentinel_one_cloud_funnel.*",
 21]
 22language = "eql"
 23license = "Elastic License v2"
 24name = "Kubernetes Direct API Request via Curl or Wget"
 25note = """ ## Triage and analysis
 26
 27> **Disclaimer**:
 28> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
 29
 30### Investigating Kubernetes Direct API Request via Curl or Wget
 31
 32Kubernetes API endpoints are crucial for managing cluster resources. Adversaries may exploit tools like curl or wget to directly query these endpoints, bypassing standard clients like kubectl, to extract sensitive data such as secrets or config maps. The detection rule identifies such unauthorized access attempts by monitoring command executions that target specific API paths, flagging potential security threats.
 33
 34### Possible investigation steps
 35
 36- Review the process details to confirm the execution of curl or wget, focusing on the process.name and process.args fields to understand the exact command used and the specific Kubernetes API endpoint targeted.
 37- Check the user context under which the curl or wget command was executed, including user ID and group ID, to determine if the action was performed by a legitimate user or an unauthorized entity.
 38- Investigate the source IP address and host information to identify the origin of the request and assess whether it aligns with expected network activity within the Kubernetes environment.
 39- Examine recent authentication and authorization logs for any anomalies or failed attempts that might indicate unauthorized access attempts to the Kubernetes API.
 40- Correlate the alert with other security events or logs from the same timeframe to identify any related suspicious activities, such as unusual network traffic or access patterns.
 41- Assess the potential impact by reviewing the specific Kubernetes resources targeted, such as secrets or config maps, to determine if sensitive data might have been exposed or compromised.
 42
 43### False positive analysis
 44
 45- Routine monitoring scripts or health checks that use curl or wget to verify the availability of Kubernetes API endpoints may trigger this rule. To manage this, identify and whitelist the specific scripts or IP addresses that are known to perform these checks regularly.
 46- Automated backup processes that access Kubernetes secrets or config maps using curl or wget could be flagged. Exclude these processes by specifying their unique command patterns or execution contexts in the detection rule.
 47- Developers or administrators using curl or wget for legitimate troubleshooting or testing purposes might inadvertently trigger the rule. Implement user-based exceptions for known and trusted personnel who require such access for their roles.
 48- Integration tools or CI/CD pipelines that interact with Kubernetes APIs using curl or wget for deployment or configuration tasks may cause false positives. Create exceptions for these tools by identifying their process names or execution environments.
 49- Security scanners or vulnerability assessment tools that probe Kubernetes API endpoints as part of their scanning routines can be mistaken for unauthorized access attempts. Whitelist these tools by their known signatures or execution patterns to prevent false alerts.
 50
 51### Response and remediation
 52
 53- Immediately isolate the affected system from the network to prevent further unauthorized access to Kubernetes API endpoints.
 54- Revoke any potentially compromised credentials or tokens that may have been used in the unauthorized API requests.
 55- Conduct a thorough review of Kubernetes audit logs to identify the scope of the unauthorized access and determine if any sensitive data was exfiltrated.
 56- Reset and rotate all secrets and config maps that may have been accessed during the incident to ensure they are no longer valid.
 57- Implement network segmentation and access controls to restrict direct access to Kubernetes API endpoints, ensuring only authorized clients can communicate with the API.
 58- Escalate the incident to the security operations team for further investigation and to assess the need for additional security measures or incident response actions.
 59- Enhance monitoring and alerting for similar unauthorized access attempts by integrating additional threat intelligence and refining detection capabilities.
 60"""
 61risk_score = 47
 62rule_id = "b53f1d73-150d-484d-8f02-222abeb5d5fa"
 63setup = """## Setup
 64
 65This rule requires data coming in from Elastic Defend.
 66
 67### Elastic Defend Integration Setup
 68Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
 69
 70#### Prerequisite Requirements:
 71- Fleet is required for Elastic Defend.
 72- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 73
 74#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 75- Go to the Kibana home page and click "Add integrations".
 76- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 77- Click "Add Elastic Defend".
 78- Configure the integration name and optionally add a description.
 79- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 80- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
 81- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 82- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
 83For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 84- Click "Save and Continue".
 85- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
 86For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 87"""
 88severity = "medium"
 89tags = [
 90    "Domain: Endpoint",
 91    "Domain: Container",
 92    "Domain: Kubernetes",
 93    "OS: Linux",
 94    "Use Case: Threat Detection",
 95    "Tactic: Execution",
 96    "Tactic: Discovery",
 97    "Data Source: Elastic Defend",
 98    "Data Source: Elastic Endgame",
 99    "Data Source: Crowdstrike",
100    "Data Source: SentinelOne",
101    "Resources: Investigation Guide",
102]
103timestamp_override = "event.ingested"
104type = "eql"
105query = '''
106process where host.os.type == "linux" and event.type == "start" and
107event.action in ("exec", "exec_event", "start", "executed", "process_started") and
108process.name in ("curl", "wget") and process.args like~ (
109  "*http*//*/apis/authorization.k8s.io/*",
110  "*http*//*/apis/rbac.authorization.k8s.io/*",
111  "*http*//*/api/v1/secrets*",
112  "*http*//*/api/v1/namespaces/*/secrets*",
113  "*http*//*/api/v1/configmaps*",
114  "*http*//*/api/v1/pods*",
115  "*http*//*/apis/apps/v1/deployments*"
116)
117'''
118
119[[rule.threat]]
120framework = "MITRE ATT&CK"
121
122[[rule.threat.technique]]
123id = "T1059"
124name = "Command and Scripting Interpreter"
125reference = "https://attack.mitre.org/techniques/T1059/"
126
127[[rule.threat.technique.subtechnique]]
128id = "T1059.004"
129name = "Unix Shell"
130reference = "https://attack.mitre.org/techniques/T1059/004/"
131
132[rule.threat.tactic]
133id = "TA0002"
134name = "Execution"
135reference = "https://attack.mitre.org/tactics/TA0002/"
136
137[[rule.threat]]
138framework = "MITRE ATT&CK"
139
140[[rule.threat.technique]]
141id = "T1613"
142name = "Container and Resource Discovery"
143reference = "https://attack.mitre.org/techniques/T1613/"
144
145[rule.threat.tactic]
146id = "TA0007"
147name = "Discovery"
148reference = "https://attack.mitre.org/tactics/TA0007/"