Kubectl Network Configuration Modification

  1[metadata]
  2creation_date = "2025/06/19"
  3integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
  4maturity = "production"
  5updated_date = "2025/07/07"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10This rule detects potential kubectl network configuration modification activity by monitoring for process events
 11where the kubectl command is executed with arguments that suggest an attempt to modify network configurations in
 12Kubernetes. This could indicate an adversary trying to manipulate network settings for malicious purposes, such as
 13establishing unauthorized access or exfiltrating data.
 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 = "Kubectl Network Configuration Modification"
 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 Kubectl Network Configuration Modification
 31
 32Kubectl is a command-line tool for interacting with Kubernetes clusters, allowing users to manage applications and network settings. Adversaries may exploit kubectl to alter network configurations, potentially establishing unauthorized access or data exfiltration channels. The detection rule identifies suspicious kubectl usage patterns, such as port-forwarding or proxy commands, especially when executed from atypical parent processes or directories, indicating possible malicious intent.
 33
 34### Possible investigation steps
 35
 36- Review the process command line to confirm the specific kubectl command and arguments used, focusing on "port-forward", "proxy", or "expose" to understand the intended network configuration change.
 37- Examine the parent process details, including the name and executable path, to determine if the kubectl command was initiated from an unusual or suspicious location, such as "/tmp/*" or "/var/tmp/*".
 38- Investigate the user account associated with the kubectl process to verify if the activity aligns with their typical behavior or if it indicates potential compromise.
 39- Check for any recent changes or anomalies in the Kubernetes cluster's network settings or configurations that could correlate with the detected kubectl activity.
 40- Look for additional related alerts or logs that might indicate a broader pattern of suspicious activity, such as other command and control tactics or protocol tunneling attempts.
 41
 42### False positive analysis
 43
 44- Legitimate administrative tasks using kubectl port-forward or proxy commands can trigger the rule. To manage this, create exceptions for known administrative scripts or users who frequently perform these tasks.
 45- Automated scripts or cron jobs that use kubectl for network configuration changes may cause false positives. Identify these scripts and exclude their specific command patterns or parent processes from the rule.
 46- Development environments where developers frequently use kubectl for testing purposes might generate alerts. Consider excluding specific user accounts or directories associated with development activities.
 47- Continuous integration/continuous deployment (CI/CD) pipelines that utilize kubectl for deployment processes can be a source of false positives. Exclude the CI/CD tool's process names or execution paths from the rule.
 48- Temporary directories like /tmp or /var/tmp used by legitimate applications for kubectl operations can trigger alerts. Review and whitelist these specific applications or their execution contexts.
 49
 50### Response and remediation
 51
 52- Immediately isolate the affected host to prevent further unauthorized access or data exfiltration. This can be done by removing the host from the network or applying network segmentation rules.
 53- Terminate any suspicious kubectl processes identified by the detection rule to halt any ongoing malicious activity.
 54- Review and revoke any unauthorized access credentials or tokens that may have been compromised or used in the attack.
 55- Conduct a thorough audit of Kubernetes network configurations and access controls to identify and rectify any unauthorized changes or vulnerabilities.
 56- Restore any altered network configurations to their original state using backups or configuration management tools.
 57- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected.
 58- Implement enhanced monitoring and logging for kubectl activities and network configuration changes to detect and respond to similar threats more effectively in the future.
 59"""
 60risk_score = 21
 61rule_id = "877cc04a-3320-411d-bbe9-53266fa5e107"
 62setup = """## Setup
 63
 64This rule requires data coming in from Elastic Defend.
 65
 66### Elastic Defend Integration Setup
 67Elastic 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.
 68
 69#### Prerequisite Requirements:
 70- Fleet is required for Elastic Defend.
 71- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 72
 73#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 74- Go to the Kibana home page and click "Add integrations".
 75- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 76- Click "Add Elastic Defend".
 77- Configure the integration name and optionally add a description.
 78- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 79- 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).
 80- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 81- 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.
 82For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 83- Click "Save and Continue".
 84- 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.
 85For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 86"""
 87severity = "low"
 88tags = [
 89    "Domain: Endpoint",
 90    "Domain: Container",
 91    "Domain: Kubernetes",
 92    "OS: Linux",
 93    "Use Case: Threat Detection",
 94    "Tactic: Command and Control",
 95    "Data Source: Elastic Defend",
 96    "Data Source: Elastic Endgame",
 97    "Data Source: Crowdstrike",
 98    "Data Source: SentinelOne",
 99    "Resources: Investigation Guide",
100]
101timestamp_override = "event.ingested"
102type = "eql"
103query = '''
104process where host.os.type == "linux" and event.type == "start" and
105event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
106process.name == "kubectl" and (
107  process.args == "port-forward" and process.command_line like "*:*" or
108  process.args in ("proxy", "expose")
109) and (
110  process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") or
111  (
112    process.parent.executable like ("/tmp/*", "/var/tmp/*", "/dev/shm/*", "/root/*", "/home/*") or
113    process.parent.name like (".*", "*.sh")
114  )
115)
116'''
117
118[[rule.threat]]
119framework = "MITRE ATT&CK"
120
121[[rule.threat.technique]]
122id = "T1572"
123name = "Protocol Tunneling"
124reference = "https://attack.mitre.org/techniques/T1572/"
125
126[[rule.threat.technique]]
127id = "T1090"
128name = "Proxy"
129reference = "https://attack.mitre.org/techniques/T1090/"
130
131[rule.threat.tactic]
132id = "TA0011"
133name = "Command and Control"
134reference = "https://attack.mitre.org/tactics/TA0011/"