Chinese Fire Ant Buries Spy Tunnels in Cisco IOS XR

Chinese state-linked threat group Fire Ant is converting Cisco IOS XR routers into covert espionage relays by planting GRE (Generic Routing Encapsulation) tunnel interfaces that don’t appear in the device’s running configuration, BleepingComputer reported Monday. If your network runs IOS XR at the edge, check your interface inventory today.

What researchers found

Researchers identified the Fire Ant intrusion after spotting an active GRE tunnel interface on a Cisco IOS XR router that had no corresponding entry in the running configuration. That gap is the tell: standard IOS XR audits compare show running-config output against expected device state. A tunnel that doesn’t show up in the config also doesn’t show up in those checks.

GRE (Generic Routing Encapsulation) is a legitimate Cisco feature for wrapping traffic between two network endpoints. It’s common in WAN and SD-WAN deployments. As covert infrastructure, though, a GRE tunnel sitting on a border or transit router gives an attacker a persistent, low-noise egress path that looks like ordinary routing traffic from the outside and produces no process-level artifacts on internal systems.

No malware on endpoints. No suspicious process trees. No EDR alert. Just a router quietly tunneling copies of traffic somewhere it shouldn’t.

Why IOS XR

Cisco IOS XR runs on ASR 9000 series, NCS, and similar platforms used as ISP edge, carrier peering, and enterprise WAN routers. These devices sit between network segments and often pass significant volumes of east-west traffic. Compromise at this layer means visibility into communications that never touch a monitored endpoint.

This isn’t Fire Ant’s first rodeo with network appliances. China-nexus groups have targeted Cisco infrastructure repeatedly over the past year, treating routers and firewalls as long-term access points rather than one-time footholds. The FBI and DOJ’s July disruption of the QTFY espionage platform was also rooted in compromised network hardware. The pattern is consistent.

What to check now

If you run Cisco IOS XR in any environment that handles sensitive traffic, run these checks:

Compare interface state to config. On IOS XR, show interfaces brief lists all active interfaces including tunnels. Cross-reference that output against show running-config formal interface or show run | include interface. Any tunnel-ip interface that appears in show interfaces but not in show running-config warrants immediate investigation.

Audit NETCONF and RESTCONF logs. Config changes via programmable interfaces may not surface in standard CLI syslog. If your IOS XR devices support YANG telemetry or NETCONF, review the operational logs for interface creation events you didn’t authorize.

Block GRE at the ACL or policy level if you don’t use it. If your environment has no legitimate GRE use case, a service-policy or access-list blocking GRE (IP protocol 47) at perimeter points reduces the utility of this technique.

Check authentication on management plane. The initial compromise vector for this campaign hasn’t been publicly detailed yet. Keep management-plane access locked down: SSHv2 only, no Telnet, console passwords enforced, AAA with TACACS+ or RADIUS, and out-of-band management where possible.

What’s not confirmed yet

The initial access method Fire Ant used to get onto these IOS XR devices hasn’t been publicly disclosed. There’s no CVE tied to this campaign yet and no vendor advisory from Cisco as of publication. Watch for updates from Cisco’s PSIRT blog and BleepingComputer’s follow-on coverage.

The full technical write-up with indicators of compromise, if released, will be worth reviewing for your threat-intel feeds. For now, the actionable step is the interface audit above. Run it before the end of your next maintenance window.

Related: Cisco IOS XE Web UI Zero-Day: Mass Exploitation | Cisco ASA/FTD VPN Flaw Exploited, CISA Sets Aug 14 Deadline | FBI, DOJ Disrupt China QTFY Cyber Espionage Platform