T1599 Google Chronicle · YARA-L

Detect Network Boundary Bridging in Google Chronicle

This detection identifies adversary activity consistent with MITRE ATT&CK T1599 (Network Boundary Bridging), where threat actors compromise perimeter network devices — routers, firewalls, or internal segmentation appliances — and reconfigure them to allow prohibited traffic to cross trust boundaries. Detection focuses on unauthorized ACL modifications, NAT rule changes, routing table manipulation, and firewall policy changes sourced from network device syslog and configuration audit trails ingested into SIEM. Because this technique targets network infrastructure rather than endpoints, primary telemetry comes from CommonSecurityLog (CEF-formatted device logs), Syslog, and network device AAA/TACACS+ audit streams. High-severity modifications include permit-any rules, deletion of blocking ACLs, addition of bypass NAT entries, and introduction of static routes to previously isolated segments.

MITRE ATT&CK

Tactic
Defense Evasion
Technique
T1599 Network Boundary Bridging
Canonical reference
https://attack.mitre.org/techniques/T1599/

YARA-L Detection Query

Google Chronicle (YARA-L)
yaral
rule t1599_network_boundary_bridging {
  meta:
    author = "df00tech"
    description = "Detects Network Boundary Bridging (T1599)"
    mitre_attack_tactic = "TA0043"
    mitre_attack_technique = "T1599"
    confidence = "medium"
    severity = "high"
  events:
    $e.metadata.event_type = "NETWORK_CONNECTION"
    $e.principal.ip != ""
  condition:
    $e
}
high severity medium confidence

Google Chronicle YARA-L 2.0 detection rule for Network Boundary Bridging (T1599). Uses Unified Data Model (UDM) event field mappings to detect the same behavioral patterns as the KQL rule, with Chronicle's temporal matching and entity correlation capabilities.

Data Sources

Google Chronicle SIEMChronicle UDM

Required Tables

NETWORK_CONNECTIONNETWORK_FLOW

False Positives & Tuning

  • Authorized network engineers performing scheduled maintenance during approved change windows — validate against change management system (ServiceNow/Jira)
  • Automated network management tools (Cisco DNA Center, Ansible AWX, SolarWinds NCM) pushing approved configuration templates
  • Security operations performing penetration test or red team exercises with pre-authorized network changes
  • Firewall rule cleanup projects legitimately removing outdated ACL entries as part of hygiene programs
Download portable Sigma rule (.yml)

Other platforms for T1599


Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Add iptables rule to permit forwarding between network segments on Linux firewall

    Expected signal: Syslog events showing iptables rule addition, kernel sysctl change in /proc/sys/net/ipv4/ip_forward, auditd records if audit rules on iptables binary, and Linux auth logs showing sudo elevation.

  2. Test 2Add static route to bridge isolated network segment on Linux router

    Expected signal: Auditd records of 'ip route' command execution, kernel routing table modification in /proc/net/route, syslog if routing daemon is logging, and file modification event on /etc/network/routes.

  3. Test 3Flush iptables security rules to allow all inter-segment traffic

    Expected signal: Syslog or auditd records capturing: (1) iptables -F FORWARD command execution with sudo, (2) iptables -P FORWARD ACCEPT policy change, (3) sysctl net.ipv4.ip_forward=1. If network device sends SNMP traps, a linkDown/warmStart trap may fire.

Unlock Pro Content

Get the full detection package for T1599 including response playbook, investigation guide, and atomic red team tests.

Response PlaybookInvestigation GuideHunting QueriesAtomic Red Team TestsTuning Guidance

Related Detections