Netcat File Transfer or Listener Detected via Defend for Containers

This rule detects an established netcat file transfer or listener running inside a container. Netcat is a utility used for reading and writing data across network connections, and it can be used for malicious purposes such as establishing a backdoor for persistence, exfiltrating data or file transfer.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2023/04/26"
  3integration = ["cloud_defend"]
  4maturity = "production"
  5min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
  6min_stack_version = "9.3.0"
  7updated_date = "2026/01/15"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12This rule detects an established netcat file transfer or listener running inside a container. Netcat is a utility
 13used for reading and writing data across network connections, and it can be used for malicious purposes such as
 14establishing a backdoor for persistence, exfiltrating data or file transfer.
 15"""
 16false_positives = [
 17    """
 18    There is a potential for false positives if the container is used for legitimate tasks that require the use of
 19    netcat, such as network troubleshooting, testing or system monitoring. It is important to investigate any alerts
 20    generated by this rule to determine if they are indicative of malicious activity or part of legitimate container
 21    activity.
 22    """,
 23]
 24from = "now-6m"
 25index = ["logs-cloud_defend.process*"]
 26interval = "5m"
 27language = "eql"
 28license = "Elastic License v2"
 29name = "Netcat File Transfer or Listener Detected via Defend for Containers"
 30note = """## Setup
 31
 32## Triage and analysis
 33
 34> **Disclaimer**:
 35> 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.
 36
 37### Investigating Netcat File Transfer or Listener Detected via Defend for Containers
 38
 39Netcat is a versatile networking tool used for reading and writing data across network connections, often employed for legitimate purposes like debugging and network diagnostics. However, adversaries can exploit Netcat to establish unauthorized backdoors or exfiltrate data from containers. The detection rule identifies suspicious Netcat activity by monitoring process events within containers, focusing on specific arguments that indicate a listening state, which is a common trait of malicious use. This proactive detection helps mitigate potential threats by flagging unusual network behavior indicative of compromise.
 40
 41### Possible investigation steps
 42
 43- Review the container ID associated with the alert to identify the specific container where the Netcat listener was established. This can help in understanding the context and potential impact.
 44- Examine the process name and arguments to confirm the presence of Netcat and its listening state. Look for arguments like "-l", "--listen", "-p", or "--source-port" to verify the listener setup.
 45- Check the parent process of the Netcat instance to determine how it was initiated. This can provide insights into whether it was started by a legitimate application or a potentially malicious script.
 46- Investigate the network connections associated with the container to identify any unusual or unauthorized connections that may indicate data exfiltration or communication with a command and control server.
 47- Analyze the container's recent activity and logs to identify any other suspicious behavior or anomalies that could be related to the Netcat listener, such as unexpected file modifications or other process executions.
 48- Assess the container's security posture and configuration to determine if there are any vulnerabilities or misconfigurations that could have been exploited to establish the Netcat listener.
 49
 50### False positive analysis
 51
 52- Development and testing activities within containers may trigger the rule if Netcat is used for legitimate debugging or network diagnostics. Users can create exceptions for specific container IDs or process names associated with known development environments.
 53- Automated scripts or tools that utilize Netcat for routine network checks or health monitoring might be flagged. To mitigate this, users can whitelist these scripts by identifying their unique process arguments or execution patterns.
 54- Containers running network services that rely on Netcat for legitimate communication purposes could be mistakenly identified. Users should document and exclude these services by specifying their container IDs and associated process arguments.
 55- Security tools or monitoring solutions that incorporate Netcat for legitimate scanning or testing purposes may cause false positives. Users can manage this by excluding these tools based on their known process names and arguments.
 56
 57### Response and remediation
 58
 59- Immediately isolate the affected container to prevent further unauthorized access or data exfiltration. This can be done by stopping the container or disconnecting it from the network.
 60- Conduct a thorough review of the container's logs and process history to identify any unauthorized access or data transfers that may have occurred.
 61- Remove any unauthorized Netcat binaries or scripts found within the container to eliminate the backdoor.
 62- Rebuild the container from a known good image to ensure no residual malicious artifacts remain.
 63- Update container images and underlying host systems with the latest security patches to mitigate vulnerabilities that could be exploited by similar threats.
 64- Implement network segmentation and firewall rules to restrict unauthorized outbound connections from containers, reducing the risk of data exfiltration.
 65- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other containers or systems within the environment."""
 66risk_score = 47
 67rule_id = "a52a9439-d52c-401c-be37-2785235c6547"
 68severity = "medium"
 69tags = [
 70    "Data Source: Elastic Defend for Containers",
 71    "Domain: Container",
 72    "OS: Linux",
 73    "Use Case: Threat Detection",
 74    "Tactic: Execution",
 75    "Resources: Investigation Guide",
 76]
 77timestamp_override = "event.ingested"
 78type = "eql"
 79query = '''
 80process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
 81  process.name in ("nc","ncat","netcat","netcat.openbsd","netcat.traditional") or
 82  (
 83    /* account for tools that execute utilities as a subprocess, in this case the target utility name will appear as a process arg */
 84    process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox") and
 85    process.args in (
 86      "nc", "/bin/nc", "/usr/bin/nc", "/usr/local/bin/nc",
 87      "ncat", "/bin/ncat", "/usr/bin/ncat", "/usr/local/bin/ncat",
 88      "netcat", "/bin/netcat", "/usr/bin/netcat", "/usr/local/bin/netcat",
 89      "netcat.openbsd", "/bin/netcat.openbsd", "/usr/bin/netcat.openbsd", "/usr/local/bin/netcat.openbsd",
 90      "netcat.traditional", "/bin/netcat.traditional", "/usr/bin/netcat.traditional", "/usr/local/bin/netcat.traditional"
 91    ) and 
 92    /* default exclusion list to not FP on default multi-process commands */
 93    not process.args in (
 94      "which", "/bin/which", "/usr/bin/which", "/usr/local/bin/which",
 95      "man", "/bin/man", "/usr/bin/man", "/usr/local/bin/man",
 96      "chmod", "/bin/chmod", "/usr/bin/chmod", "/usr/local/bin/chmod",
 97      "chown", "/bin/chown", "/usr/bin/chown", "/usr/local/bin/chown"
 98    )
 99  )
100) and
101process.args like~ (
102  /* bind shell to specific port or listener */
103  "-*l*","-*p*",
104  /* reverse shell to command-line interpreter used for command execution */
105  "-*e*",
106  /* file transfer via stdout/pipe */
107  ">","<", "|"
108) and process.interactive == true and container.id like "*"
109'''
110
111[[rule.threat]]
112framework = "MITRE ATT&CK"
113
114[[rule.threat.technique]]
115id = "T1059"
116name = "Command and Scripting Interpreter"
117reference = "https://attack.mitre.org/techniques/T1059/"
118
119[[rule.threat.technique.subtechnique]]
120id = "T1059.004"
121name = "Unix Shell"
122reference = "https://attack.mitre.org/techniques/T1059/004/"
123
124[rule.threat.tactic]
125id = "TA0002"
126name = "Execution"
127reference = "https://attack.mitre.org/tactics/TA0002/"

Setup

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 Netcat File Transfer or Listener Detected via Defend for Containers

Netcat is a versatile networking tool used for reading and writing data across network connections, often employed for legitimate purposes like debugging and network diagnostics. However, adversaries can exploit Netcat to establish unauthorized backdoors or exfiltrate data from containers. The detection rule identifies suspicious Netcat activity by monitoring process events within containers, focusing on specific arguments that indicate a listening state, which is a common trait of malicious use. This proactive detection helps mitigate potential threats by flagging unusual network behavior indicative of compromise.

Possible investigation steps

  • Review the container ID associated with the alert to identify the specific container where the Netcat listener was established. This can help in understanding the context and potential impact.
  • Examine the process name and arguments to confirm the presence of Netcat and its listening state. Look for arguments like "-l", "--listen", "-p", or "--source-port" to verify the listener setup.
  • Check the parent process of the Netcat instance to determine how it was initiated. This can provide insights into whether it was started by a legitimate application or a potentially malicious script.
  • Investigate the network connections associated with the container to identify any unusual or unauthorized connections that may indicate data exfiltration or communication with a command and control server.
  • Analyze the container's recent activity and logs to identify any other suspicious behavior or anomalies that could be related to the Netcat listener, such as unexpected file modifications or other process executions.
  • Assess the container's security posture and configuration to determine if there are any vulnerabilities or misconfigurations that could have been exploited to establish the Netcat listener.

False positive analysis

  • Development and testing activities within containers may trigger the rule if Netcat is used for legitimate debugging or network diagnostics. Users can create exceptions for specific container IDs or process names associated with known development environments.
  • Automated scripts or tools that utilize Netcat for routine network checks or health monitoring might be flagged. To mitigate this, users can whitelist these scripts by identifying their unique process arguments or execution patterns.
  • Containers running network services that rely on Netcat for legitimate communication purposes could be mistakenly identified. Users should document and exclude these services by specifying their container IDs and associated process arguments.
  • Security tools or monitoring solutions that incorporate Netcat for legitimate scanning or testing purposes may cause false positives. Users can manage this by excluding these tools based on their known process names and arguments.

Response and remediation

  • Immediately isolate the affected container to prevent further unauthorized access or data exfiltration. This can be done by stopping the container or disconnecting it from the network.
  • Conduct a thorough review of the container's logs and process history to identify any unauthorized access or data transfers that may have occurred.
  • Remove any unauthorized Netcat binaries or scripts found within the container to eliminate the backdoor.
  • Rebuild the container from a known good image to ensure no residual malicious artifacts remain.
  • Update container images and underlying host systems with the latest security patches to mitigate vulnerabilities that could be exploited by similar threats.
  • Implement network segmentation and firewall rules to restrict unauthorized outbound connections from containers, reducing the risk of data exfiltration.
  • Escalate the incident to the security operations team for further investigation and to assess the potential impact on other containers or systems within the environment.

Related rules

to-top