Interactive Exec Command Launched Against A Running Container

  1[metadata]
  2creation_date = "2023/05/12"
  3integration = ["cloud_defend"]
  4maturity = "production"
  5updated_date = "2025/01/15"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10This rule detects interactive 'exec' events launched against a container using the 'exec' command. Using the 'exec'
 11command in a pod allows a user to establish a temporary shell session and execute any process/command inside the
 12container. This rule specifically targets higher-risk interactive commands that allow real-time interaction with a
 13container's shell. A malicious actor could use this level of access to further compromise the container environment or
 14attempt a container breakout.
 15"""
 16false_positives = [
 17    """
 18    An administrator may need to exec into a pod for a legitimate reason like debugging purposes. Containers built from
 19    Linux and Windows OS images, tend to include debugging utilities. In this case, an admin may choose to run commands
 20    inside a specific container with kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ...
 21    ${ARGN}. For example, the following command can be used to look at logs from a running Cassandra pod: kubectl exec
 22    cassandra --cat /var/log/cassandra/system.log . Additionally, the -i and -t arguments might be used to run a shell
 23    connected to the terminal: kubectl exec -i -t cassandra -- sh
 24    """,
 25]
 26from = "now-6m"
 27index = ["logs-cloud_defend*"]
 28interval = "5m"
 29language = "eql"
 30license = "Elastic License v2"
 31name = "Interactive Exec Command Launched Against A Running Container"
 32references = [
 33    "https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/",
 34    "https://kubernetes.io/docs/tasks/debug/debug-application/get-shell-running-container/",
 35]
 36risk_score = 73
 37rule_id = "420e5bb4-93bf-40a3-8f4a-4cc1af90eca1"
 38severity = "high"
 39tags = [
 40    "Data Source: Elastic Defend for Containers",
 41    "Domain: Container",
 42    "OS: Linux",
 43    "Use Case: Threat Detection",
 44    "Tactic: Execution",
 45    "Resources: Investigation Guide",
 46]
 47timestamp_override = "event.ingested"
 48type = "eql"
 49
 50query = '''
 51process where container.id : "*" and event.type== "start" and
 52
 53/* use of kubectl exec to enter a container */
 54process.entry_leader.entry_meta.type : "container" and
 55
 56/* process is the inital process run in a container */
 57process.entry_leader.same_as_process== true and
 58
 59/* interactive process */
 60process.interactive == true
 61'''
 62note = """## Triage and analysis
 63
 64> **Disclaimer**:
 65> 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.
 66
 67### Investigating Interactive Exec Command Launched Against A Running Container
 68
 69In containerized environments, the 'exec' command is used to run processes inside a running container, often for debugging or administrative tasks. Adversaries may exploit this to gain shell access, potentially leading to further compromise or container escape. The detection rule identifies such activities by monitoring for interactive 'exec' sessions, focusing on initial processes within containers, and flagging high-risk interactions.
 70
 71### Possible investigation steps
 72
 73- Review the container.id to identify which specific container the interactive exec command was executed against and gather information about its purpose and criticality.
 74- Examine the process.entry_leader.entry_meta.type to confirm that the process was indeed initiated within a container environment, ensuring the context of the alert is accurate.
 75- Investigate the process.entry_leader.same_as_process field to verify that the process in question is the initial process run in the container, which may indicate a new or unexpected session.
 76- Analyze the process.interactive field to understand the nature of the interaction and determine if it aligns with expected administrative activities or if it suggests unauthorized access.
 77- Check for any recent changes or deployments in the container environment that might explain the interactive session, such as updates or debugging activities.
 78- Correlate the event with user activity logs to identify the user or service account responsible for initiating the exec command and assess their access permissions and recent actions.
 79- Investigate any subsequent actions or commands executed within the container following the interactive session to identify potential malicious activities or attempts at container breakout.
 80
 81### False positive analysis
 82
 83- Routine administrative tasks may trigger the rule when system administrators use 'kubectl exec' for legitimate maintenance or debugging. To manage this, create exceptions for known administrator accounts or specific maintenance windows.
 84- Automated scripts or monitoring tools that use 'exec' for health checks or logging purposes can also cause false positives. Identify these scripts and exclude their associated processes or user accounts from triggering the rule.
 85- Development and testing activities often involve frequent use of 'exec' commands for container interaction. Consider excluding specific development environments or user roles from the rule to reduce noise.
 86- Continuous integration/continuous deployment (CI/CD) pipelines might use 'exec' to deploy or test applications within containers. Exclude these pipeline processes or service accounts to prevent false alerts.
 87- If certain containers are known to require frequent interactive access for legitimate reasons, consider tagging these containers and configuring the rule to ignore interactions with them.
 88
 89### Response and remediation
 90
 91- Immediately isolate the affected container to prevent further unauthorized access or potential lateral movement within the environment. This can be done by pausing or stopping the container.
 92- Review and terminate any unauthorized or suspicious interactive sessions identified by the alert to cut off the adversary's access.
 93- Conduct a thorough analysis of the container's filesystem and running processes to identify any malicious scripts or binaries that may have been introduced during the interactive session.
 94- Revert the container to a known good state by redeploying it from a trusted image, ensuring that any potential backdoors or malicious modifications are removed.
 95- Implement network segmentation and access controls to limit the ability of users to execute 'exec' commands on containers, especially for high-risk or production environments.
 96- Escalate the incident to the security operations team for further investigation and to determine if additional containers or systems have been compromised.
 97- Enhance monitoring and alerting for similar activities by ensuring that all interactive 'exec' commands are logged and reviewed, and consider implementing stricter access controls for container management tools like kubectl."""
 98
 99
100[[rule.threat]]
101framework = "MITRE ATT&CK"
102[[rule.threat.technique]]
103id = "T1059"
104name = "Command and Scripting Interpreter"
105reference = "https://attack.mitre.org/techniques/T1059/"
106[[rule.threat.technique.subtechnique]]
107id = "T1059.004"
108name = "Unix Shell"
109reference = "https://attack.mitre.org/techniques/T1059/004/"
110
111
112[[rule.threat.technique]]
113id = "T1609"
114name = "Container Administration Command"
115reference = "https://attack.mitre.org/techniques/T1609/"
116
117
118[rule.threat.tactic]
119id = "TA0002"
120name = "Execution"
121reference = "https://attack.mitre.org/tactics/TA0002/"