BPF filter applied using TC

Detects when the tc (transmission control) binary is utilized to set a BPF (Berkeley Packet Filter) on a network interface. Tc is used to configure Traffic Control in the Linux kernel. It can shape, schedule, police and drop traffic. A threat actor can utilize tc to set a bpf filter on an interface for the purpose of manipulating the incoming traffic. This technique is not at all common and should indicate abnormal, suspicious or malicious activity.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2022/07/11"
  3integration = ["endpoint", "sentinel_one_cloud_funnel"]
  4maturity = "production"
  5min_stack_version = "8.13.0"
  6min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
  7updated_date = "2025/01/15"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12Detects when the tc (transmission control) binary is utilized to set a BPF (Berkeley Packet Filter) on a network
 13interface. Tc is used to configure Traffic Control in the Linux kernel. It can shape, schedule, police and drop traffic.
 14A threat actor can utilize tc to set a bpf filter on an interface for the purpose of manipulating the incoming traffic.
 15This technique is not at all common and should indicate abnormal, suspicious or malicious activity.
 16"""
 17from = "now-9m"
 18index = ["logs-endpoint.events.*", "endgame-*", "logs-sentinel_one_cloud_funnel.*"]
 19language = "eql"
 20license = "Elastic License v2"
 21name = "BPF filter applied using TC"
 22references = [
 23    "https://github.com/h3xduck/TripleCross/blob/master/src/helpers/deployer.sh",
 24    "https://man7.org/linux/man-pages/man8/tc.8.html",
 25]
 26risk_score = 73
 27rule_id = "ef04a476-07ec-48fc-8f3d-5e1742de76d3"
 28setup = """## Setup
 29
 30This rule requires data coming in from Elastic Defend.
 31
 32### Elastic Defend Integration Setup
 33Elastic 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.
 34
 35#### Prerequisite Requirements:
 36- Fleet is required for Elastic Defend.
 37- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 38
 39#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 40- Go to the Kibana home page and click "Add integrations".
 41- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 42- Click "Add Elastic Defend".
 43- Configure the integration name and optionally add a description.
 44- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 45- 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).
 46- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 47- 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.
 48For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 49- Click "Save and Continue".
 50- 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.
 51For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 52"""
 53severity = "high"
 54tags = [
 55    "Domain: Endpoint",
 56    "OS: Linux",
 57    "Use Case: Threat Detection",
 58    "Tactic: Execution",
 59    "Threat: TripleCross",
 60    "Data Source: Elastic Endgame",
 61    "Data Source: Elastic Defend",
 62    "Data Source: SentinelOne",
 63    "Resources: Investigation Guide",
 64]
 65timestamp_override = "event.ingested"
 66type = "eql"
 67
 68query = '''
 69process where host.os.type == "linux" and event.type != "end" and process.executable == "/usr/sbin/tc" and
 70process.args == "filter" and process.args == "add" and process.args == "bpf" and
 71not process.parent.executable == "/usr/sbin/libvirtd"
 72'''
 73note = """## Triage and analysis
 74
 75> **Disclaimer**:
 76> 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.
 77
 78### Investigating BPF filter applied using TC
 79
 80BPF (Berkeley Packet Filter) is a powerful tool for network traffic analysis and control, often used with the `tc` command to manage traffic on Linux systems. Adversaries may exploit this by setting BPF filters to manipulate or monitor network traffic covertly. The detection rule identifies suspicious use of `tc` to apply BPF filters, flagging potential misuse by checking for specific command patterns and excluding legitimate processes.
 81
 82### Possible investigation steps
 83
 84- Review the process execution details to confirm the presence of the `/usr/sbin/tc` command with arguments "filter", "add", and "bpf" to ensure the alert is not a false positive.
 85- Investigate the parent process of the `tc` command to determine if it is a known legitimate process or if it appears suspicious, especially since the rule excludes `/usr/sbin/libvirtd`.
 86- Check the user account associated with the process execution to assess if it is a privileged account and whether the activity aligns with the user's typical behavior.
 87- Analyze network traffic logs around the time of the alert to identify any unusual patterns or connections that may indicate malicious activity.
 88- Correlate this event with other security alerts or logs to identify if this is part of a broader attack pattern or campaign, such as the use of the TripleCross threat.
 89- Review system logs for any other suspicious activities or anomalies that occurred before or after the alert to gather additional context.
 90
 91### False positive analysis
 92
 93- Legitimate use of tc by virtualization software like libvirtd can trigger the rule. To handle this, exclude processes where the parent executable is /usr/sbin/libvirtd, as indicated in the rule.
 94- Network administrators may use tc with BPF filters for legitimate traffic management tasks. Identify and document these use cases, then create exceptions for specific command patterns or user accounts involved in these activities.
 95- Automated scripts or system management tools that configure network interfaces might use tc with BPF filters. Review these scripts and tools, and if they are verified as safe, exclude their process signatures from triggering the rule.
 96- Regular audits of network configurations can help distinguish between legitimate and suspicious use of BPF filters. Implement a process to regularly review and update exceptions based on these audits to minimize false positives.
 97
 98### Response and remediation
 99
100- Immediately isolate the affected system from the network to prevent further manipulation or monitoring of network traffic by the adversary.
101- Terminate the suspicious `tc` process to stop any ongoing malicious activity related to the BPF filter application.
102- Conduct a thorough review of network traffic logs to identify any unauthorized data exfiltration or communication with known malicious IP addresses.
103- Restore the affected system from a known good backup to ensure that no malicious configurations or software persist.
104- Implement network segmentation to limit the potential impact of similar threats in the future, ensuring critical systems are isolated from less secure areas.
105- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are compromised.
106- Update and enhance endpoint detection and response (EDR) solutions to improve monitoring and alerting for similar suspicious activities involving `tc` and BPF filters."""
107
108
109[[rule.threat]]
110framework = "MITRE ATT&CK"
111[[rule.threat.technique]]
112id = "T1059"
113name = "Command and Scripting Interpreter"
114reference = "https://attack.mitre.org/techniques/T1059/"
115[[rule.threat.technique.subtechnique]]
116id = "T1059.004"
117name = "Unix Shell"
118reference = "https://attack.mitre.org/techniques/T1059/004/"
119
120
121
122[rule.threat.tactic]
123id = "TA0002"
124name = "Execution"
125reference = "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 BPF filter applied using TC

BPF (Berkeley Packet Filter) is a powerful tool for network traffic analysis and control, often used with the tc command to manage traffic on Linux systems. Adversaries may exploit this by setting BPF filters to manipulate or monitor network traffic covertly. The detection rule identifies suspicious use of tc to apply BPF filters, flagging potential misuse by checking for specific command patterns and excluding legitimate processes.

Possible investigation steps

  • Review the process execution details to confirm the presence of the /usr/sbin/tc command with arguments "filter", "add", and "bpf" to ensure the alert is not a false positive.
  • Investigate the parent process of the tc command to determine if it is a known legitimate process or if it appears suspicious, especially since the rule excludes /usr/sbin/libvirtd.
  • Check the user account associated with the process execution to assess if it is a privileged account and whether the activity aligns with the user's typical behavior.
  • Analyze network traffic logs around the time of the alert to identify any unusual patterns or connections that may indicate malicious activity.
  • Correlate this event with other security alerts or logs to identify if this is part of a broader attack pattern or campaign, such as the use of the TripleCross threat.
  • Review system logs for any other suspicious activities or anomalies that occurred before or after the alert to gather additional context.

False positive analysis

  • Legitimate use of tc by virtualization software like libvirtd can trigger the rule. To handle this, exclude processes where the parent executable is /usr/sbin/libvirtd, as indicated in the rule.
  • Network administrators may use tc with BPF filters for legitimate traffic management tasks. Identify and document these use cases, then create exceptions for specific command patterns or user accounts involved in these activities.
  • Automated scripts or system management tools that configure network interfaces might use tc with BPF filters. Review these scripts and tools, and if they are verified as safe, exclude their process signatures from triggering the rule.
  • Regular audits of network configurations can help distinguish between legitimate and suspicious use of BPF filters. Implement a process to regularly review and update exceptions based on these audits to minimize false positives.

Response and remediation

  • Immediately isolate the affected system from the network to prevent further manipulation or monitoring of network traffic by the adversary.
  • Terminate the suspicious tc process to stop any ongoing malicious activity related to the BPF filter application.
  • Conduct a thorough review of network traffic logs to identify any unauthorized data exfiltration or communication with known malicious IP addresses.
  • Restore the affected system from a known good backup to ensure that no malicious configurations or software persist.
  • Implement network segmentation to limit the potential impact of similar threats in the future, ensuring critical systems are isolated from less secure areas.
  • Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are compromised.
  • Update and enhance endpoint detection and response (EDR) solutions to improve monitoring and alerting for similar suspicious activities involving tc and BPF filters.

References

Related rules

to-top