Suspicious Interactive Shell Spawned From Inside A Container
This rule detects when an interactive shell is spawned inside a running container. This could indicate a potential container breakout attempt or an attacker's attempt to gain unauthorized access to the underlying host.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2023/04/26"
3integration = ["cloud_defend"]
4maturity = "production"
5updated_date = "2025/01/15"
6
7[rule]
8author = ["Elastic"]
9description = """
10This rule detects when an interactive shell is spawned inside a running container. This could indicate a potential
11container breakout attempt or an attacker's attempt to gain unauthorized access to the underlying host.
12"""
13false_positives = [
14 """
15 Legitimate users and processes, such as system administration tools, may utilize shell utilities inside a container
16 resulting in false positives.
17 """,
18]
19from = "now-6m"
20index = ["logs-cloud_defend*"]
21interval = "5m"
22language = "eql"
23license = "Elastic License v2"
24name = "Suspicious Interactive Shell Spawned From Inside A Container"
25risk_score = 73
26rule_id = "8d3d0794-c776-476b-8674-ee2e685f6470"
27severity = "high"
28tags = [
29 "Data Source: Elastic Defend for Containers",
30 "Domain: Container",
31 "OS: Linux",
32 "Use Case: Threat Detection",
33 "Tactic: Execution",
34 "Resources: Investigation Guide",
35]
36timestamp_override = "event.ingested"
37type = "eql"
38
39query = '''
40process where container.id: "*" and
41event.type== "start" and
42
43/*D4C consolidates closely spawned event.actions, this excludes end actions to only capture ongoing processes*/
44event.action in ("fork", "exec") and event.action != "end"
45 and process.entry_leader.same_as_process== false and
46(
47(process.executable: "*/*sh" and process.args: ("-i", "-it")) or
48process.args: "*/*sh"
49)
50'''
51note = """## Triage and analysis
52
53> **Disclaimer**:
54> 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.
55
56### Investigating Suspicious Interactive Shell Spawned From Inside A Container
57
58Containers are lightweight, portable units that encapsulate applications and their dependencies, often used to ensure consistent environments across development and production. Adversaries may exploit containers by spawning interactive shells to execute unauthorized commands, potentially leading to container escape and host compromise. The detection rule identifies such threats by monitoring for shell processes initiated within containers, focusing on specific process actions and arguments indicative of interactive sessions.
59
60### Possible investigation steps
61
62- Review the alert details to identify the specific container ID where the interactive shell was spawned. This will help in isolating the affected container for further analysis.
63- Examine the process executable and arguments, particularly looking for shell types and interactive flags (e.g., "-i", "-it"), to understand the nature of the shell session initiated.
64- Check the process entry leader to determine if the shell process is part of a larger process tree, which might indicate a more complex attack chain or script execution.
65- Investigate the user context under which the shell was spawned to assess if it aligns with expected user behavior or if it indicates potential unauthorized access.
66- Analyze recent logs and events from the container and host to identify any preceding suspicious activities or anomalies that might have led to the shell spawning.
67- Correlate the event with other security alerts or incidents to determine if this is part of a broader attack pattern or campaign targeting the environment.
68
69### False positive analysis
70
71- Development and testing activities may trigger this rule when developers intentionally spawn interactive shells within containers for debugging or configuration purposes. To manage this, create exceptions for specific user accounts or container IDs frequently used in development environments.
72- Automated scripts or orchestration tools that use interactive shells for legitimate tasks can also cause false positives. Identify these scripts and exclude their associated process names or arguments from the rule.
73- Some container management platforms might use interactive shells as part of their normal operations. Review the processes and arguments used by these platforms and add them to an exception list if they are known to be safe.
74- Regular maintenance tasks that require interactive shell access, such as system updates or configuration changes, can be excluded by scheduling these tasks during known maintenance windows and temporarily adjusting the rule settings.
75
76### Response and remediation
77
78- Immediately isolate the affected container to prevent further unauthorized access or potential container escape. This can be done by stopping the container or disconnecting it from the network.
79- Capture and preserve forensic data from the container, including logs, process lists, and network activity, to aid in further investigation and understanding of the attack vector.
80- Conduct a thorough review of the container's configuration and permissions to identify and rectify any misconfigurations or vulnerabilities that may have been exploited.
81- Patch and update the container image and any associated software to address known vulnerabilities that could have been leveraged by the attacker.
82- Implement stricter access controls and monitoring on container environments to prevent unauthorized shell access, such as using role-based access controls and enabling audit logging.
83- Escalate the incident to the security operations team for further analysis and to determine if the threat has spread to other parts of the infrastructure.
84- Review and enhance detection capabilities to identify similar threats in the future, ensuring that alerts are tuned to detect unauthorized shell access attempts promptly."""
85
86
87[[rule.threat]]
88framework = "MITRE ATT&CK"
89[[rule.threat.technique]]
90id = "T1059"
91name = "Command and Scripting Interpreter"
92reference = "https://attack.mitre.org/techniques/T1059/"
93[[rule.threat.technique.subtechnique]]
94id = "T1059.004"
95name = "Unix Shell"
96reference = "https://attack.mitre.org/techniques/T1059/004/"
97
98
99
100[rule.threat.tactic]
101id = "TA0002"
102name = "Execution"
103reference = "https://attack.mitre.org/tactics/TA0002/"
Triage and analysis
Disclaimer: 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.
Investigating Suspicious Interactive Shell Spawned From Inside A Container
Containers are lightweight, portable units that encapsulate applications and their dependencies, often used to ensure consistent environments across development and production. Adversaries may exploit containers by spawning interactive shells to execute unauthorized commands, potentially leading to container escape and host compromise. The detection rule identifies such threats by monitoring for shell processes initiated within containers, focusing on specific process actions and arguments indicative of interactive sessions.
Possible investigation steps
- Review the alert details to identify the specific container ID where the interactive shell was spawned. This will help in isolating the affected container for further analysis.
- Examine the process executable and arguments, particularly looking for shell types and interactive flags (e.g., "-i", "-it"), to understand the nature of the shell session initiated.
- Check the process entry leader to determine if the shell process is part of a larger process tree, which might indicate a more complex attack chain or script execution.
- Investigate the user context under which the shell was spawned to assess if it aligns with expected user behavior or if it indicates potential unauthorized access.
- Analyze recent logs and events from the container and host to identify any preceding suspicious activities or anomalies that might have led to the shell spawning.
- Correlate the event with other security alerts or incidents to determine if this is part of a broader attack pattern or campaign targeting the environment.
False positive analysis
- Development and testing activities may trigger this rule when developers intentionally spawn interactive shells within containers for debugging or configuration purposes. To manage this, create exceptions for specific user accounts or container IDs frequently used in development environments.
- Automated scripts or orchestration tools that use interactive shells for legitimate tasks can also cause false positives. Identify these scripts and exclude their associated process names or arguments from the rule.
- Some container management platforms might use interactive shells as part of their normal operations. Review the processes and arguments used by these platforms and add them to an exception list if they are known to be safe.
- Regular maintenance tasks that require interactive shell access, such as system updates or configuration changes, can be excluded by scheduling these tasks during known maintenance windows and temporarily adjusting the rule settings.
Response and remediation
- Immediately isolate the affected container to prevent further unauthorized access or potential container escape. This can be done by stopping the container or disconnecting it from the network.
- Capture and preserve forensic data from the container, including logs, process lists, and network activity, to aid in further investigation and understanding of the attack vector.
- Conduct a thorough review of the container's configuration and permissions to identify and rectify any misconfigurations or vulnerabilities that may have been exploited.
- Patch and update the container image and any associated software to address known vulnerabilities that could have been leveraged by the attacker.
- Implement stricter access controls and monitoring on container environments to prevent unauthorized shell access, such as using role-based access controls and enabling audit logging.
- Escalate the incident to the security operations team for further analysis and to determine if the threat has spread to other parts of the infrastructure.
- Review and enhance detection capabilities to identify similar threats in the future, ensuring that alerts are tuned to detect unauthorized shell access attempts promptly.
Related rules
- Container Management Utility Run Inside A Container
- File Made Executable via Chmod Inside A Container
- Interactive Exec Command Launched Against A Running Container
- Netcat Listener Established Inside A Container
- AWS Credentials Searched For Inside A Container