THREAT-NetworkTap-RogueSPANExfil Elastic Security · Elastic

Detect Unauthorized On-Premises SPAN/RSPAN/ERSPAN Configuration for Passive Traffic Exfiltration in Elastic Security

The base T1020.001 technique detection focuses on cloud-native traffic mirroring APIs (AWS Traffic Mirroring, Azure vTAP, GCP Packet Mirroring), which cover cloud estates well but leave on-premises network infrastructure largely unmonitored. Adversaries with compromised network device credentials, or malicious insiders with switch/router administrative access, can configure a local SPAN or RSPAN session, or an ERSPAN tunnel, on a Cisco IOS/IOS-XE or Juniper Junos device to passively copy production traffic to a destination they control — either an internal collector planted on the network or, more dangerously, an external IP reached via a GRE-encapsulated ERSPAN tunnel that egresses the corporate perimeter. Because this is a control-plane configuration change rather than a data-plane anomaly, it produces no alert in traditional DLP or proxy-based exfiltration monitoring; the only telemetry is the device's own configuration-change logging (TACACS+/RADIUS command accounting, or syslog CFGLOG entries) and, if the destination is external, a subsequent GRE (IP protocol 47) flow to that address. This scenario targets that specific on-premises control-plane + data-plane correlation, which is a materially different detection surface from the cloud API monitoring the base technique file already covers, and closes a real blind spot for organizations running hybrid or fully on-premises network infrastructure.

MITRE ATT&CK

Tactic
Exfiltration

Elastic Detection Query

Elastic Security (Elastic)
eql 
sequence by destination.ip with maxspan=1h
  [any where event.dataset == "network_device.syslog" and
     message : ("*monitor session*", "*erspan-source*", "*erspan-id*", "*port-mirroring*") and
     message : "*destination ip address*"]
  [network where event.type == "connection" and network.transport == "gre"]
high severity medium confidence

Elastic EQL sequence keyed on the destination IP extracted from a SPAN/ERSPAN configuration syslog message, requiring a subsequent GRE-transport network connection event to that same IP within one hour — mirrors the control-plane-to-data-plane correlation used in the KQL/SPL queries. Requires the destination IP to be normalized into destination.ip at ingestion time via a syslog processing pipeline.

Data Sources

Network device syslog ingested via Elastic Agent custom log integrationNetwork flow data (NetFlow/IPFIX via Elastic Agent netflow integration)

Required Tables

logs-network_device.syslog-*logs-netflow.log-*

False Positives & Tuning

  • Network operations staff configuring approved SPAN/RSPAN sessions for legitimate NDR/IDS sensor deployment under an active change ticket
  • ERSPAN tunnels to a legitimate internal security-tooling collector

Other platforms for THREAT-NetworkTap-RogueSPANExfil

Microsoft Sentinel (KQL) Splunk (SPL) IBM QRadar (QRadar) Sumo Logic CSE (Sumo) Google Chronicle (YARA-L) CrowdStrike LogScale (LogScale) All platforms (combined) →

Testing Methodology

Validate this detection against 2 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 1Simulate Cisco IOS ERSPAN Configuration to External Destination via Syslog

    Expected signal: Syslog entries tagged CISCO-IOS containing CFGLOG_LOGGEDCMD messages with 'monitor session', 'erspan-source', 'destination ip address 198.51.100.77', and 'erspan-id'. In a real deployment these would also generate matching TACACS+ accounting records.

  2. Test 2Simulate GRE Flow to ERSPAN Destination

    Expected signal: A synthetic flow log entry showing protocol=47 (GRE) traffic from the internal device IP to the previously configured external destination. In production this would be sourced from actual NetFlow/IPFIX/sFlow export from the network device or an upstream collector.

Last updated: 2026-07-16 Research depth: deep
References (4)

Response Playbook

Triage

  1. Retrieve the full configuration command sequence from the TACACS+ accounting log or syslog CFGLOG entries — identify the source interface being mirrored and the exact destination IP or ERSPAN ID.
  2. Determine whether the destination IP is internal (and if so, what device/subnet it belongs to) or external — an external destination is a near-certain indicator of active exfiltration.
  3. Check the authenticated username/session that made the configuration change against the change management system for a corresponding approved ticket and maintenance window.
  4. Review the source interface or VLAN being mirrored — is it a high-value segment (finance, engineering, domain controllers) or a low-sensitivity segment (guest Wi-Fi, printer VLAN)?
  5. If a GRE flow to the destination has been observed, estimate total bytes transferred to gauge exfiltration volume and duration.
  6. Check whether the same administrative account or source IP has made other unusual configuration changes recently (ACL modifications, new local accounts, logging/AAA changes suggesting an attempt to cover tracks).

Containment

  1. Remove the unauthorized SPAN/RSPAN/ERSPAN session immediately via the device CLI (e.g., `no monitor session <id>` on Cisco IOS) or equivalent Junos deactivation.
  2. Block the destination IP at the perimeter firewall if external, and specifically filter GRE (protocol 47) traffic to that destination.
  3. Disable or rotate the credentials of the account used to make the configuration change; if TACACS+/RADIUS shared secrets are suspected compromised, rotate those as well.
  4. Audit AAA/TACACS+ authorization policies to confirm which roles should be permitted to issue `monitor session`/`port-mirroring` commands, and tighten command authorization sets if the acting account should not have had this privilege.
  5. Preserve the device's running-config, startup-config, and full accounting/syslog history before making further changes, to support forensic timeline reconstruction.
  6. If device firmware or OS integrity is in question (e.g., signs the change bypassed normal AAA logging), escalate to a full device compromise investigation rather than treating this as a simple misconfiguration.

Evidence Collection

  1. TACACS+/RADIUS accounting records showing the exact commands issued, the authenticated identity, source IP of the management session, and timestamps
  2. Device running-config and configuration archive/versioning history (if using a config management tool such as RANCID, Oxidized, or a vendor NCCM) showing the diff introduced
  3. NetFlow/IPFIX/sFlow records for GRE (protocol 47) traffic between the mirrored source and the configured destination
  4. Device syslog CFGLOG entries (%PARSER-5-CFGLOG_LOGGEDCMD on Cisco IOS) capturing the full command sequence with user attribution
  5. Management-plane access logs (SSH/Telnet session logs, jump-host/bastion audit logs) covering the session in which the change was made
  6. Any packet capture available from the mirror destination itself, if the collector or its logs are recoverable, to determine what was actually captured

Escalation Criteria

  • !The mirror/ERSPAN destination is confirmed external to the organization's IP space
  • !The mirrored source interface/VLAN carries traffic for domain controllers, financial systems, or other high-value assets
  • !No change ticket, maintenance window, or documented authorization exists for the configuration change
  • !The acting account shows signs of compromise (unusual login time/location, concurrent unrelated suspicious activity) rather than being a known network engineer performing sanctioned work
  • !Evidence that logging or AAA configuration was also modified around the same time, suggesting deliberate concealment
  • !The same pattern (SPAN/ERSPAN configuration followed by GRE flow to an external destination) is observed on multiple devices, indicating a broader campaign against network infrastructure rather than an isolated incident.

Investigation Guide

Related Techniques

T1020.001 — Traffic Duplication (parent technique)T1020 — Automated ExfiltrationT1040 — Network Sniffing (mirrored traffic enables passive credential/session sniffing)T1557 — Adversary-in-the-Middle (traffic redirection is a related but distinct capability from passive mirroring)T1078 — Valid Accounts (compromised or misused network device administrative credentials enable the configuration change)T1601.001 — Patch System Image (firmware tampering could enable mirroring that bypasses normal configuration logging)T1590 — Gather Victim Network Information (reconnaissance of network topology typically precedes selecting a high-value segment to mirror)

Forensic Artifacts

  • >Cisco IOS: `show monitor session all` output at time of discovery, and configuration archive diffs from RANCID/Oxidized/NCCM tooling
  • >Cisco IOS syslog: %SYS-5-CONFIG_I (configured from console/vty) and %PARSER-5-CFGLOG_LOGGEDCMD entries with the full command text and authenticated user
  • >Juniper Junos: `show configuration forwarding-options port-mirroring` and commit log (`show system commit`) entries with the committing user and timestamp
  • >TACACS+ accounting records (start/stop/watchdog) for the administrative session, including source IP of the management connection
  • >NetFlow/IPFIX records showing GRE (protocol 47) flows from the mirrored device to the configured destination, with byte counts for volume estimation
  • >SNMP trap or syslog records of interface/VLAN monitoring state changes coincident with the configuration event

Tuning Guidance

Build and maintain an authoritative inventory of every legitimate SPAN/RSPAN/ERSPAN session and its destination (security tooling collectors, NDR sensors, packet brokers) sourced from your network configuration management system, and use it as a standing allowlist keyed on device + destination IP pair. Any configuration change producing a destination IP outside that allowlist should page immediately rather than being queued for routine triage, since legitimate business reasons for an unlisted mirror destination are rare and typically involve a missed inventory update rather than genuine ad-hoc need. The GRE-to-external-IP hunting query is the single highest-value complementary check: internal, RFC1918-only GRE traffic is common and low-risk, but any GRE flow crossing the perimeter should be treated as a near-automatic escalation regardless of whether the originating configuration change was separately detected. Where TACACS+ command authorization is available, the strongest preventive control is restricting `monitor session`/`port-mirroring` command sets to a small, audited group of network engineering roles rather than relying on detection alone.

Hunting Queries

Inventory all SPAN/RSPAN/ERSPAN/port-mirroring configuration changes across the network device fleet over the past 30 days, grouped by device and administrator. Use this to build the baseline of known, authorized mirror sessions and quickly spot new or unexpected changes by comparing against change management records.

Hunting — KQL
kql 
NetworkDeviceSyslog_CL
| where TimeGenerated > ago(30d)
| where CommandText has_any ("monitor session", "erspan-source", "port-mirroring")
| summarize ChangeCount=count(), Commands=make_set(CommandText, 20), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated) by DeviceName, Username, SourceIP
| sort by ChangeCount desc
Hunting — SPL
spl 
index=network_syslog sourcetype IN ("cisco:ios", "tacacs:accounting")
(CommandText="*monitor session*" OR CommandText="*erspan-source*" OR CommandText="*port-mirroring*")
| stats count as ChangeCount, values(CommandText) as Commands, earliest(_time) as FirstSeen, latest(_time) as LastSeen by host, Username, SourceIP
| sort - ChangeCount

Hunt for GRE flows from internal network devices to external (non-RFC1918) destinations over the past 7 days. ERSPAN's use of GRE encapsulation means legitimate internal mirroring should almost never produce GRE traffic crossing the corporate perimeter; any such flow warrants immediate investigation.

Hunting — KQL
kql 
NetworkFlowLogs
| where TimeGenerated > ago(7d)
| where Protocol == "GRE" or Protocol == "47"
| where not(ipv4_is_private(DestinationIP))
| summarize FlowCount=count(), TotalBytes=sum(Bytes) by SourceIP, DestinationIP
| sort by TotalBytes desc
Hunting — SPL
spl 
index=network_flows (protocol="GRE" OR protocol="47") NOT (dest_ip="10.0.0.0/8" OR dest_ip="172.16.0.0/12" OR dest_ip="192.168.0.0/16")
| stats count as FlowCount, sum(bytes) as TotalBytes by src_ip, dest_ip
| sort - TotalBytes

Atomic Red Team Tests

Test 1 Simulate Cisco IOS ERSPAN Configuration to External Destination via Syslog
linux

Generates syslog messages matching the expected format for a Cisco IOS ERSPAN source session configuration pointed at an external destination IP, allowing SIEM detection logic to be validated without requiring physical or virtual Cisco hardware.

Command

bash 
logger -p local4.notice -t CISCO-IOS '%PARSER-5-CFGLOG_LOGGEDCMD: User:netadmin logged command:monitor session 1 type erspan-source'
logger -p local4.notice -t CISCO-IOS '%PARSER-5-CFGLOG_LOGGEDCMD: User:netadmin logged command:source interface GigabitEthernet0/1 both'
logger -p local4.notice -t CISCO-IOS '%PARSER-5-CFGLOG_LOGGEDCMD: User:netadmin logged command:destination ip address 198.51.100.77'
logger -p local4.notice -t CISCO-IOS '%PARSER-5-CFGLOG_LOGGEDCMD: User:netadmin logged command:erspan-id 50'

Cleanup

bash 
# No cleanup required for simulated syslog events

Expected Telemetry

Syslog entries tagged CISCO-IOS containing CFGLOG_LOGGEDCMD messages with 'monitor session', 'erspan-source', 'destination ip address 198.51.100.77', and 'erspan-id'. In a real deployment these would also generate matching TACACS+ accounting records.

Expected Detection

KQL/SPL SpanConfigChange signal fires on the CommandText matching 'monitor session' and 'erspan-source'. The DestIP extraction captures 198.51.100.77 for correlation against subsequent GRE flow telemetry.

Test 2 Simulate GRE Flow to ERSPAN Destination
linux

Generates a synthetic flow-log record representing GRE (protocol 47) traffic from the network device to the ERSPAN destination configured in the previous test, completing the two-stage correlation for detection validation.

Command

bash 
logger -p local4.notice -t NETFLOW 'srcip=10.10.5.1 dstip=198.51.100.77 protocol=47 bytes=45231872 flow_start=1'

Cleanup

bash 
# No cleanup required for simulated flow record

Expected Telemetry

A synthetic flow log entry showing protocol=47 (GRE) traffic from the internal device IP to the previously configured external destination. In production this would be sourced from actual NetFlow/IPFIX/sFlow export from the network device or an upstream collector.

Expected Detection

KQL GreFlowsToDest / SPL GRE-protocol join fires when this flow's DestinationIP matches the DestIP extracted from the prior ERSPAN configuration test and falls within the correlation window, completing the full high-confidence detection.

Related Detections

Tactic Hub

TA0010Exfiltration

Detection Variants (1)

Different telemetry and tradecraft for the same technique — pick the one that matches the data you collect.

Parent Technique

T1020.001Traffic Duplication

Related Techniques

T1020.001Traffic DuplicationT1020Automated ExfiltrationT1040Network SniffingT1557Adversary-in-the-MiddleT1078Valid AccountsT1601.001Patch System ImageT1590Gather Victim Network Information

Same Tactic: Exfiltration

Popular Detections