Fire Ant Evolves: From Hypervisors to Trusted Infrastructure

Key Observations

• First reported in 2025, Fire Ant remained active into 2026, expanding from hypervisor-level compromise into the trusted infrastructure layer that routes, authenticates, connects, and manages high-value environments.
• The compromise impacted both the direct and third-party environments. Its trusted infrastructure relationships created potential reachability into connected external environments, including high-value networks and critical infrastructure. Fire Ant appeared to use this trusted position to explore access paths beyond the initially compromised environment. Compromised routers became operational platforms. Fire Ant used router infrastructure for covert connectivity, traffic collection, command-output manipulation, and suppression of logging.
• Fire Ant targeted authentication chokepoints. The actor compromised TACACS infrastructure to intercept authentication flows, collect credentials, and weaken confidence in administrative audit trails.
• Fire Ant built a resilient access layer. The actor deployed long-lived implants across Linux management infrastructure, including Medusa-related components, custom SSH backdoors, Zabbix-masquerading malware, and packet-triggered backdoors.
• Fire Ant manipulated the evidence layer itself. Across routers, TACACS servers, and Linux hosts, the actor modified or bypassed telemetry sources defenders normally rely on, reinforcing the need to validate logs against memory, disk, network, authentication, and configuration evidence.

Executive Summary

Fire Ant, first reported in 2025, remained active in 2026 and expanded its operations beyond hypervisors into the trusted infrastructure that routes traffic, authenticates administrators, manages access, and records activity. The main finding is that the actor was no longer targeting only individual systems, it was targeting the infrastructure layer that controls how entire environments connect and operate both within and across organizational boundaries.

This created a “target behind the target” risk. By compromising routers, authentication systems, and Linux management hosts, Fire Ant gained strategic positions from which it could collect traffic and credentials, maintain covert access, and explore paths toward connected high-value environments, including critical infrastructure. The compromise therefore had implications beyond the systems directly affected.

The actor also manipulated the evidence sources defenders depend on. It suppressed router logging, altered command output, captured administrative credentials, tampered with host logs, and deployed multiple persistent backdoors. As a result, investigators could not rely on any single source of telemetry to accurately reconstruct the activity.

The key implication for organizations is that routers, authentication servers, hypervisors, jump hosts, and management appliances must be treated as first-class security and forensic assets. These systems require the same level of monitoring, hardening, and incident-response readiness as traditional endpoints and servers. When trusted infrastructure is compromised, an attacker can gain both a path into connected environments and the ability to obscure how that access was used.

From Hypervisors to Trusted Infrastructure

Fire Ant’s earlier activity showed that hypervisors can be more than platforms that host workloads. In the hands of an advanced actor, they can become privileged vantage points from which to reach guest systems, bypass segmentation and operate under the line of sight of many endpoint controls.

The 2026 activity expands this same principle to network and management infrastructure. The actor did not only pursue servers and workstations. It targeted systems that other systems depend on: edge routers, TACACS servers, Linux jump hosts and virtualized management servers. These are the systems that decide who can reach what, which credentials are trusted and which logs exist after the fact.

This is the continuity from 2025 to 2026. The technology changed, but the strategy remained consistent: operate from layers that are trusted, privileged and difficult to inspect.

The Target Behind the Target

Highly interconnected environments are strategically valuable because they sit between systems and network zones. They provide routing, managed connectivity, authentication paths, and operational access across connected networks. A compromised infrastructure layer can become a bridge to other environments.

This is the key difference from prior Fire Ant activity. The actor appeared to use the compromised environment as an infrastructure platform from which it could explore reachability into connected high-value networks, including critical infrastructure. In this model, routers, TACACS servers and jump hosts are not peripheral assets. They are the path to the target behind the target.

For defenders, this distinction matters. If the investigation focuses only on the initially compromised systems, it may miss the broader operational objective. If the investigation treats the network and management infrastructure as a trusted connectivity layer, the scope expands to connected routes, administrative paths, shared authentication infrastructure and the systems that control segmentation.

Compromising Network Infrastructure

Fire Ant’s activity demonstrated that edge routers should not be treated as passive network infrastructure. In this intrusion, the actor gained access to Cisco IOS XR routers and turned them into operational platforms capable of supporting stealth, persistence, and potential reach into connected environments.

The investigation began with an anomaly that appeared, at first, to be a configuration inconsistency: a tunnel interface became operational on a Cisco IOS XR router even though no corresponding running configuration or commit history could explain its creation. The interface was associated with a specific VRF and used GRE encapsulation, but standard configuration review did not provide a reliable explanation for how it appeared. This discrepancy became a key investigative lead because it suggested that the device’s operational state could no longer be trusted to match the configuration and audit records visible to administrators.

Inside Fire Ant’s IOS XR Router Toolkit

Fire Ant’s router compromise was not built around generic Linux tooling. The malware recovered from the compromised Cisco IOS XR environment was purpose-built for the router control plane, with components that interacted directly with IOS XR logging, command execution, routing, VRF resolution, AAA, and Telnet-management functions. This distinction is important: Fire Ant was not simply running malware on a Linux-based appliance; it was modifying the systems that make the router manageable and trustworthy.

The toolkit included a boot-themed persistence script on /etc/rc.d/init.d/grub-rommon masquerading as a legitimate service.

This script monitored and launched the acpid implant from /usr/bin/acpid, using an hourly schedule that started the implant during odd-numbered hours and stopped it during even-numbered hours. The design suggests an attempt to maintain access while reducing continuous process visibility during routine inspection.

The acpid component embedded a modified IOS XR syslog library. In the modified evsyslog flow, log delivery was routed through a custom wrapper that checked for the string “Health” before calling mq_send. When the condition was not met, the wrapper returned a success-like value without forwarding the message, indicating selective manipulation of router log delivery.

The acpid component also contained shell-related indicators, including references to pseudo-terminal paths, interactive connection banners, escape-sequence handling, and a command to unset shell-history environment variables. It indicates that acpid likely supported interactive access or shell staging in addition to its telemetry-manipulation role.

Another component, masquerading as /pkg/bin/dhcpd_show_issu_status, provided outbound connectivity. The binary contained a hardcoded external IP address and Telnet client functionality, while importing IOS XR-specific routing, VRF, RIB, and Telnet-management libraries. This indicates that the actor designed the communication component to operate from within the router’s native networking context rather than relying on standard Linux networking behavior.

Fire Ant also attempted to manipulate what administrators could see from the router CLI. Reverse engineering of the recovered /pkg/bin/hd component showed that the actor modified the IOS XR command execution path to append an IOS-style “| exclude” filter to show commands before forwarding them to the normal shell_send_cmd() routine. Separately, command history from the affected device showed repeated show commands using exclusion filters that matched tunnel-related configuration elements, including the tunnel interface, VRF, tunnel source, tunnel VRF, and tunnel destination.

Taken together, these components show that Fire Ant treated routers as operational platforms. The actor built capabilities for persistence, outbound communication, syslog suppression, and command-output manipulation. In a highly interconnected environment, this level of router control is strategically significant: a compromised edge router can become a vantage point for covert connectivity, traffic observation, and access to connected networks, including critical infrastructure environments that rely on trusted routing and management paths.

Following the GRE Tunnel

The tunnel anomaly also shifted the investigation from the compromised router itself to the infrastructure it appeared to connect with. Once Fire Ant demonstrated the ability to manipulate the router’s configuration view, suppress telemetry, and potentially conceal operational state, the key question was no longer only how the tunnel was created, but where it led and what role the other side played in the operation. Tracing the far end of the GRE tunnel exposed another part of the actor’s infrastructure: a legacy Linux system.

Activity on the Linux system showed that the GRE tunnel was not only an anomalous configuration artifact; it was also an operational path. From this host, Fire Ant conducted repeated connection attempts and port probing toward connected high-value environments, including systems associated with critical infrastructure. The observed activity included attempts against common administrative and service ports such as SSH, HTTP/HTTPS, SMB/RPC-related ports and RDP. This indicates that the actor used the tunnel to extend reach beyond the compromised router and into environments reachable through the compromised network infrastructure.

This shifted the role of the Linux host from a passive tunnel endpoint to an active staging and reconnaissance node. On this system, investigators identified a suspicious binary named zabbix_agent. Although the name appeared to imitate a legitimate Zabbix monitoring component, the binary did not align with expected Zabbix behavior. Instead, it functioned as a backdoor that supported actor-controlled access and command execution from the Linux management host. The legitimate Zabbix agent is typically named zabbix_agentd, making the zabbix_agent filename a likely attempt to blend into a monitoring environment.

BridgeAgent

Sygnia tracks this Zabbix-masquerading implant as BridgeAgent, reflecting its role on the GRE-connected Linux host as a bridge for actor-controlled access into connected environments.

BridgeAgent is configured for persistence through a zabbix_agent.service systemd unit, set to run as root with automatic restart behavior. Once executed, BridgeAgent changed its apparent command line to resemble /usr/bin/gnome-shell, loaded encrypted configuration from /opt/.ICEauthority, and performed periodic HTTPS polling to retrieve controller-supplied configuration.

BridgeAgent stored its runtime configuration in encrypted form under /opt/.ICEauthority. Static analysis of the binary identified an embedded AES key used to decrypt this configuration. This design allowed the implant to keep C2 parameters out of plaintext on disk while still retrieving them locally at runtime.

Using the recovered AES key, Sygnia decrypted the .ICEauthority configuration file and recovered the implant’s runtime settings, including controller host, port, polling interval, host identifier, and reverse-shell parameters.

BridgeAgent’s runtime logs showed repeated attempts to establish TLS-based outbound connectivity to actor-controlled infrastructure over port 443. The logs also showed the implant processing controller-supplied configuration and attempting to launch reverse-shell functionality, indicating that the malware was designed to operate as an outbound command-and-control backdoor rather than as a normal monitoring agent.

Additional journal evidence showed BridgeAgent launching a secondary binary named ntfsfixed. The child process connected to actor-controlled infrastructure and included the magic string KS2ow2232ssww2342234323 in its command line. This suggests that BridgeAgent acted not only as a backdoor, but also as an execution mechanism for additional actor tooling on the Linux host.

BridgeAgent’s role was therefore broader than simple backdoor access to a Linux host. The implant was positioned on infrastructure connected to the GRE tunnel and gave the actor an operational foothold at the boundary between the compromised environment and connected networks. From this position, Fire Ant could receive commands from external infrastructure, execute additional tooling, and use the tunnel path to explore reachability beyond the immediate victim environment.

Routers as Collection Points

After establishing access to router infrastructure, Fire Ant used the network layer as an intelligence source. The actor was observed capturing traffic from multiple Cisco routers and uploading the resulting PCAP files to external FTP infrastructure. This behavior shifts the router’s role from a transit device to a collection platform. once the actor controlled the router, the device became a vantage point for observing traffic moving through trusted network paths.

The activity was performed through router-administration workflows using a legitimate administrative account. Traffic captures were generated from multiple router interfaces and uploaded to external FTP servers. The observed activity involved several routers, indicating that the actor was not collecting from a single point of access but was selecting network vantage points from across the environment.

Router-based PCAP collection is especially valuable for infrastructure-focused actors. Packet captures from routers can expose internal topology, management connections, authentication flows, routing relationships, and traffic patterns between connected environments. Unlike endpoint collection, which gives visibility into a single host, router collection can provide a broader view of how systems, administrators, and connected networks interact.

The timing and preparation of the external FTP infrastructure also stood out. One of the FTP services used for the uploads appeared to have been installed on the same day the router PCAP upload activity occurred, suggesting that the actor prepared external collection infrastructure close to the operational window.

Additional router commands observed around the same administrative activity included access to command-history-related paths and traceroute activity toward unusual external domains. The pattern is consistent with an actor using routers for both collection and network reconnaissance.

This activity reinforces one of the core observations from the investigation: when a threat actor controls routers, they do not only gain reach. They gain perspective. Fire Ant used network infrastructure to observe the environment from the inside, collecting information that could support lateral movement, credential targeting, and cross-network access planning.

Owning the Authentication Layer

Fire Ant’s activity extended beyond the routers themselves into the systems used to authenticate and record administrative access to them. This is a critical distinction: the actor was not only abusing valid credentials but also targeting the infrastructure responsible for validating those credentials and preserving the audit trail.

On the TACACS server, investigators identified a VMCI-socket-based backdoor deployed under /var/tmp/audit. The backdoor supported communication over VMware VSOCK/VMCI interfaces, providing an access path that would not necessarily appear as a normal network login to the guest operating system. This finding connected the TACACS compromise back to Fire Ant’s broader pattern of abusing virtualization-adjacent access paths.

TacTap

The investigation also identified a malicious binary, /usr/sbin/acppid. Sygnia tracks this TACACS credential-collection toolset as TacTap. TacTap should be understood as a multi-component mechanism rather than a single binary: /usr/sbin/acppid acted as the injector and collection process, while /lib/libseconfd.so operated inside the tac_plus process. Together, the components enabled library injection, accepted-session interception, Unix-socket file-descriptor handoff through /var/run/acpid.lock, and creation of the XOR-obfuscated credential artifact at /var/log/.tacplus.acct

Reverse engineering of acppid showed that the binary was designed to maintain a malicious shared object inside the TACACS daemon. The original IDA view shows that acppid retrieves optional runtime configuration from the TARGET_PROG and SO_PATH environment variables. If those values are not provided, it defaults to targeting the tac_plus process and using /lib/libseconfd.so as the shared object path.

To improve readability, the next snippet is a simplified pseudocode reconstructed from the binary. It preserves the relevant injection logic while omitting decompiled artifacts and unrelated error handling.

The injected library, libseconfd.so, was designed to operate inside the TACACS process. Reverse engineering showed that it hooked accept and accept4, placing the implant inside the TACACS session-handling path. This allowed the malicious code to interact with newly accepted TACACS client connections from within the service process itself.

The hook then forwarded accepted connection file descriptors to acppid through a local UNIX socket at /var/run/acpid.lock, using sendmsg-style file-descriptor passing. This design allowed one malicious component inside the TACACS process to hand live connection handles to another process, enabling the actor to observe or process TACACS session material from within the authentication flow.

The operational result of this access was visible in the recovered credential artifact. Investigators identified an encrypted file at /var/log/.tacplus.acct containing TACACS-related credential material. The file was encoded using a single-byte XOR scheme, indicating that the actor attempted to lightly obfuscate the harvested data while keeping it simple to recover operationally. This artifact connects the injection and session-handoff mechanism to credential collection from the authentication layer.

The recovered /var/log/.tacplus.acct file was decoded using a single-byte XOR operation with key 0xEF, revealing TACACS-related credential material. The key choice is notable because Mandiant previously documented UNC3886 TACACS credential-collection tooling in which captured credential records were also XORed with 0xEF before being written to a credential log file. In this case, however, the more significant finding is the collection mechanism itself: Fire Ant used acppid to inject libseconfd.so into the running tac_plus process, intercept accepted TACACS sessions, pass connection file descriptors back through /var/run/acpid.lock, and write the resulting credential artifact to /var/log/.tacplus.acct. To our knowledge, this specific tac_plus library-injection technique has not been publicly described before, making it a notable evolution of Fire Ant’s TACACS-focused credential collection tradecraft.

This technique is more significant than ordinary credential theft. TACACS servers sit at an administrative chokepoint: they authenticate users, authorize commands, and record activity across network devices. By compromising this layer, Fire Ant positioned itself close to the trust boundary between administrators and infrastructure. The actor could potentially harvest credentials as they were used, observe administrative activity, and create ambiguity between legitimate account use and malicious activity.

The lesson is clear: when the authentication layer is compromised, defenders can no longer ask only “which account performed the action? They must also ask whether the system recording that action can still be trusted.

Building the Access Layer

Fire Ant did not rely on a single foothold. Across Linux management infrastructure, the actor built a durable access layer using Medusa-rootkit, custom SSH backdoors, masqueraded binaries, credential capture, and host-level configuration changes. The objective was not only to compromise Linux hosts, but to convert them into reusable operational infrastructure.

A key feature of this access layer was its duration. Several Linux access components were deployed in 2025 and remained available into 2026, when Fire Ant was later observed using them for hands-on activity. This shows that the actor treated Linux management hosts as long-lived staging and access nodes, not temporary footholds.

The long-lived nature of this access layer was visible in the Linux bodyfile timeline. Several Medusa-rootkit-related and custom SSH backdoor artifacts were created in 2025, including files under /usr/lib/locate and binaries such as /usr/sbin/cupsdd and /usr/sbin/smartdd. These artifacts remained relevant into 2026, when Fire Ant later launched hands-on activity through the same access layer

The names cupsdd and smartdd appear designed to blend in with legitimate Linux service names: cupsd, the CUPS printing daemon, and smartd, the smartmontools storage-health daemon.

One example of this reuse was the custom SSH backdoor /usr/sbin/cupsdd. The process tree below reflects 2026 operator activity launched through the prepositioned access layer, rather than initial deployment. Through cupsdd, Fire Ant staged and executed additional tooling from /var/tmp, including client and se.py, to support reverse-shell and tunneling activity. Because this access path operated outside the normal SSH service flow, it likely reduced the forensic footprint expected from a conventional SSH session.

Fire Ant also reinforced this access layer with credential capture. The file /var/log/remote.txt contained harvested SSH credentials from user sessions, providing the actor with a credential-based fallback alongside its implants. This meant that even if an implant was removed or a backdoor was discovered, the actor may still have retained reusable credentials for future access.

The actor also used process masquerading to make malicious tooling appear legitimate. Fire Ant staged a binary named /var/tmp/ping, renamed it to resemble the endpoint security software, SentinelOne, moved it into a directory associated with the security agent, modified timestamps to match legitimate SentinelOne files, and executed it from that trusted-looking path. In another case, the same style of masquerading was observed under a Cybereason-like path.

Even after the executable was removed from disk, the process remained active in memory. This demonstrates how Fire Ant combined trusted naming, timestamp manipulation, and deleted-but-running execution to hinder defender analysis and reduce the value of disk-only triage.

The deleted executable was later recovered from memory for analysis. Analysis showed that the binary initially staged as /var/tmp/ping and later disguised under an endpoint-security path was not a simple reverse-shell launcher. Instead, it was a packet-triggered backdoor that inspected raw network traffic for embedded activation markers before establishing operator access.

The binary showed strong functional and code-level overlap with REPTILE-style tooling publicly associated with UNC3886. Similar to REPTILE, it created a raw Layer-2 packet socket, parsed received packets directly, and searched for magic strings before activating. Notably, the sample reused the “hpaVAj2FJ“ kill marker, which has been publicly documented as a REPTILE kill marker. However, the sample was not identical to the previously reported REPTILE implementation: its primary activation marker was “sxcdewqaz!@#” rather than “mznCvqSBo”, and its packet-decoding logic differed from the date-derived XOR routine described in earlier reporting.

The ping binary also showed operational linkage to the earlier se.py activity through the same magic string, “sxcdewqaz!@#”, which was observed in the actor’s connect-back workflow. This suggests that the actor reused a common activation or session-control marker across multiple access components, while adapting the underlying implementation and filenames.

Packet triggered function

Analysis showed that the malware is a raw packet triggered remote-access controller, that listens on the network interface for TCP packets destined for ports 443, 541, 8443, or 10443, and UDP packets sent from source port 40443 and destination port 500. The malware looks for network packets with two magic strings within the packet.

• sxcdewqaz!@# -> Start of packet
• hpaVAj2FJ-> End of packet/kill marker of the listener child process

The code below shows that the implant monitored raw IPv4 Ethernet traffic and accepted activation data through:

• TCP destination ports 443, 541, 8443, and 10443
• UDP source port 40443 to destination port 500
  
  0x9DFB is decimal 40443

A second magic string, ;7(Zu9YTsA7qQ#vw, appeared to mark command completion, file-transfer completion, or control-session termination.

Interactive PTY Shell

The malware creates a PTY pair; the master side is for controlling process to send and receive data while an interactive shell is attached to the slave side. By setting the HISTFILE value to null, the bash history logging is disabled. Hence, the commands executed by the threat actor could not be seen from the .bash_history file. However, analysts can rely on other log sources such as journal log and EDR telemetry.

The malware also handled terminal settings from the remote peer, including terminal type and window dimensions. This allowed applications launched inside the remote shell to behave as though they were connected to an operator-controlled terminal.

Fire Ant reconfigured the configurations of the compromised Linux management hosts so that they could sustain and relay access rather than simply running an isolated malware. The actor weakened or disabled SELinux, modified iptables rules governing SSH, redirected selected inbound connections from port 22 to port 443, and enabled IPv4 forwarding. These changes turned the Linux management hosts into covert access and tunneling nodes capable of receiving traffic on an alternative port and forwarding it onward into the environment.

This design provided Fire Ant with an independent fallback channel that did not depend on the host’s legitimate SSH service or a continuously listening application port. The process could remain dormant until a valid trigger arrived, while support for ICMP, TCP, and UDP gave the actor several possible paths through network controls. Combined with masquerading as legitimate files, timestamp manipulation, deleted-but-running execution, cupsdd, Medusa-related persistence, and reverse-tunneling tools, the implant strengthened Fire Ant’s layered access architecture: removing one binary or closing one service would not necessarily eliminate the actor’s ability to return.

Making the Infrastructure Lie

Across the observed activity, Fire Ant repeatedly targeted the reliability of telemetry itself. The actor did not just seek to remain unseen. It modified, bypassed or removed the systems defenders normally use to reconstruct an intrusion.

On network devices, the actor manipulated the evidence layer by hiding logs, hiding commit activity, suppressing AAA requests, suppressing SNMP traps and filtering command output. On Linux systems, the actor deleted files after execution, left processes running from deleted paths, disabled SELinux, tampered with logs and modified firewall rules. On access appliances and management paths, incomplete command and authentication telemetry created ambiguity around how specific SSH sessions were established.

The result is a fundamental investigative problem: the environment may contain evidence, but the evidence sources may no longer be fully reliable. For this class of actor, defenders cannot simply collect logs and assume they represent ground truth. They must validate logs against memory, disk, network telemetry, authentication records, configuration state, and independent external observations.

Fire Ant anti-forensic activity on the Linux management hosts was selective. The actor replaced the Cisco router’s IP address with an internal IP address within three authentication artifacts, /var/log/wtmp, /var/log/utmp and /var/log/btmp.

Fire Ant removed sudo-related entries from /var/log/messages and /var/log/secure, reducing the reliability of standard Linux audit artifacts.

By disabling or weakening SELinux, the actor reduced a host-level control that could otherwise constrain post-exploitation behavior, even for privileged processes.

Threat Intelligence Context

Fire Ant’s activity should be understood in the broader context of infrastructure-focused espionage tradecraft. Public reporting from Mandiant and Google Cloud describes UNC3886 as a China-nexus espionage cluster with a sustained focus on virtualization platforms, edge devices and network infrastructure. Sygnia assesses that Fire Ant activity strongly overlaps with this public reporting.

The overlap is strongest at the level of durable behavior. Public reporting has described VMCI-based backdoors, TACACS credential theft, Medusa-rootkit usage, custom SSH access, and router-focused operations. Sygnia’s 2026 observations contain the same operational themes: virtualization-adjacent access, credential capture from authentication infrastructure, Linux rootkits, custom SSH backdoors, router compromise, and deliberate telemetry suppression.

The differences are also important. Several filenames, paths and deployment details differ from public reporting. This should not be treated as a contradiction. For mature actors, atomic indicators often change after exposure, while the operating model remains stable. In this case, the stronger correlation comes from how the actor uses infrastructure, not from whether every path or filename matches a previous report.

Fire Ant’s Objective

The new intelligence value from Sygnia’s observations extends the model into a highly interconnected environment where routers, TACACS servers and Linux management hosts were used as part of a broader access and collection layer. This reinforces the view that Fire Ant/UNC3886-like operations are not endpoint-centric campaigns. They are infrastructure-control-plane campaigns.

From a threat intelligence perspective, this also clarifies the likely objective behind the activity. In a highly interconnected environment, routers, TACACS servers, virtualization platforms, and Linux management hosts are not only internal systems; they are part of the trusted infrastructure layer that connects, authenticates, and manages access across connected networks. Compromising this layer can provide an actor with more than just persistence inside the immediate victim. It can create a bridge toward other high-value environments, including critical infrastructure that depends on trusted routing, authentication and management relationships.

This reinforces the “target behind the target” concept introduced earlier in this report. Fire Ant’s interest in the compromised organization should be understood not only as an attempt to compromise a single environment, but as an effort to control infrastructure that may enable visibility, collection, and potential access beyond the immediate victim. The strategic value lies in the trust relationships the organization maintains with connected environments.

Fire Ant’s Operating Model

The findings can be summarized as a four-part operating model. Fire Ant first seeks control over infrastructure systems, then uses those systems to collect intelligence and credentials, builds durable access, and conceals activity by manipulating the evidence layer.

This model is useful because it moves defenders beyond isolated IOCs. A single filename may change. A path may vary. A hash may disappear after remediation. The actor’s operational requirements, however, remain consistent: reach privileged infrastructure, understand routes and trust relationships, harvest credentials, maintain covert access, and weaken the reliability of telemetry.

Figure 35: Fire Ant operating model and defender implications.

When Trusted Infrastructure Becomes the Target

Fire Ant’s recent activity shows that mature espionage actors are no longer focused only on endpoints, servers, or cloud workloads. They are increasingly targeting the infrastructure that sits between environments: routers, hypervisors, TACACS servers, access appliances, Linux management hosts, and the systems that create trust, reachability, and visibility.

In this campaign, the compromised environment was not only a victim. By compromising infrastructure that routes traffic, authenticates administrators, manages access, and records activity, Fire Ant turned the environment into a potential access path toward connected high-value networks, including critical infrastructure. This position allowed the actor to explore reachability beyond the initially compromised environment while also weakening the evidence sources defenders rely on to understand what happened.

The central lesson is that defenders must protect more than the systems that store sensitive data. They must protect the infrastructure that makes other systems reachable, trusted, and observable. When that layer is compromised, the impact extends beyond a single organization: the actor may gain a vantage point for collection, a path toward connected targets, and the ability to make trusted infrastructure tell an incomplete story.

Threat Hunting and Detection Opportunities

Hunting Fire Ant requires defenders to prioritize behaviors and asset roles over atomic indicators. The most important question is not simply whether a known file exists. It is whether infrastructure systems are exhibiting behavior consistent with control-plane abuse, credential capture, collection or evidence manipulation.

The following hunting guidance is organized around the systems most relevant to the actor’s operating model.

Figure 36: Fire Ant threat hunting and detection opportunities

Indicators of Compromise

The following indicators are selected for defensive use and have been sanitized to remove victim-specific identifiers. Organizations should treat them as starting points for hunting rather than as complete detection logic.

Yara Rules

rule FIREANT_BridgeAgent_Backdoor
{
    meta:
        description = "Detects Fire Ant BridgeAgent Linux backdoor"
        author = "Sygnia"
        sha256 = "110e6fb23be00d2ed251a445ee5b65aadf23b48b8db7419900d64539ad90c5a3"

    strings:
        $s1 = "[+] ########## GetRemoteCfg ##########" ascii
        $s2 = "[+] ########## ParseJson ##########" ascii
        $s3 = "[+] reverse_shell..." ascii
        $s4 = "If you want me to fake your argv, you need to call the program with a longer name." ascii
        $s5 = "/message/" ascii
        $s6 = "thread: running timeout" ascii
        $s7 = "fMDJLBukHuXgtFsCW68o5Zs1qGf" ascii
        $s8 = "2y7b4BSVukszyZz2vuZMppaA4" ascii
        $aes_key = { 07 FA AA 79 67 F1 3F 26 22 8F 5E 9A C9 0B F1 54 }

    condition:
        uint32(0) == 0x464C457F and
        5 of ($s*) and
        $aes_key
}

rule FIREANT_BridgeAgent_Systemd_Unit
{
    meta:
        description = "Detects the companion systemd service from the analyzed sample"
        author = "Sygnia analysis"
        sha256 = "251c7a2684542c29ae2c1e1282b780163bf9f844179ef0759094b2b7e2f62f0f"

    strings:
        $a = "Description=Service for zabbix hosted on PVE" ascii
        $b = "Type=forking" ascii
        $c = "ExecStart=/usr/sbin/zabbix_agent 60" ascii
        $d = "Restart=always" ascii
        $e = "User=root" ascii

    condition:
        all of them
}

rule FIREANT_TACTAP_LIBSECONFD_1 {
    meta:
        author = "Sygnia"
        description = "Detects TacTap injected TACACS library component"
        family = "TacTap"
        component = "libseconfd.so"
        sha1 = "955cd45a2f6f226a2fdf44b329af1c8dde90cb38"
    strings:
        $lib_name = "libseconfd.so" ascii
        $old_accept = "old_accept" ascii
        $old_accept4 = "old_accept4" ascii
        $lib_main = "_lib_main" ascii
        $accept_filter = "accept_filter" ascii
        $accept4_filter = "accept4_filter" ascii
        $plthook1 = "plthook_open_by_address" ascii
        $plthook2 = "plthook_replace" ascii
        $sendmsg = "sendmsg" ascii
        $proc_maps = "/proc/self/maps" ascii

        $acpid_lock_stack = {
            48 BE 2F 76 61 72 2F 72 75 6E
            48 89 30
            48 B9 2F 61 63 70 69 64 2E 6C
            48 89 48 08
            C7 40 10 6F 63 6B 00
        }

    condition:
        uint32(0) == 0x464c457f and
        uint8(4) == 2 and
        uint8(5) == 1 and
        uint16(16) == 3 and
        uint16(18) == 0x3e and
        filesize < 64KB and
        all of them
}

rule FIREANT_TACTAP_ACPPID_1 {
    meta:
        author = "Sygnia"
        description = "Detects TacTap acppid TACACS injector component"
        family = "TacTap"
        component = "acppid"
        sha1 = "36005f5e4398a1c62a2a9271eddfcc1b44b1ad00"

    strings:
        $target_prog = "TARGET_PROG" ascii
        $so_path_env = "SO_PATH" ascii
        $target_proc = "tac_plus" ascii
        $so_path = "/lib/libseconfd.so" ascii
        $socket_path = "/var/run/acpid.lock" ascii
        $proc_maps = "/proc/%s/maps" ascii
        $proc_comm = "/proc/%s/comm" ascii
        $dlopen = "__libc_dlopen_mode" ascii
        $attach_err = "waitpid error while attaching: %s" ascii

    condition:
        uint32(0) == 0x464c457f and
        uint8(4) == 2 and
        uint8(5) == 1 and
        uint16(16) == 2 and
        uint16(18) == 0x3e and
        all of them and
        @target_prog < @so_path_env and
        @so_path_env < @target_proc and
        @target_proc < @so_path and
        (@so_path - @target_prog) < 0x100
}