Your Logs Are Not Evidence If The Infrastructure That Produces Them Can Rewrite The Record

The evidence layer is not a byproduct of your infrastructure — it is infrastructure, and on August 30, Sygnia documented what happens when the evidence layer is captured along with everything else. Fire Ant, a China-nexus threat actor Sygnia has tracked since 2025, spent this year moving past the VMware hypervisors it was previously known for and into the systems that route, authenticate, and manage the environments those hypervisors sit inside: Cisco IOS XR routers, TACACS authentication servers, and the Linux hosts that administer them.

This is not another story about a state actor compromising network equipment. The unusual part is what happened to the evidence. “Fire Ant didn’t just compromise systems. It compromised the trust layer those systems depend on,” said Asaf Perlman, Sygnia’s Director of Incident Response — and the trust layer he’s describing is the same one your incident response process depends on every time it opens a log file and treats what’s written there as fact.

What Actually Happened

Sygnia’s investigation started with a router that lied about its own configuration. A Cisco IOS XR device was running an active GRE tunnel interface with no entry in the running configuration and no commit history to explain how it got there — the kind of discrepancy that shouldn’t be possible on a device where configuration state is supposed to be the source of truth. Tracing that tunnel led to a legacy Linux management host, and from there into TACACS infrastructure and a wider set of connected environments Sygnia describes as a “target behind the target”: Fire Ant wasn’t just after the systems it had already reached, it was using them to reconnoiter administrative and service ports on other high-value networks, including ones tied to critical infrastructure.

The TACACS compromise is the part worth sitting with. Sygnia found a credential-collection toolset it tracks as TacTap, built from an injector — /usr/sbin/acppid — that loads a malicious shared library, /lib/libseconfd.so, directly into the running tac_plus authentication daemon. Once loaded, the library hooks the accept and accept4 system calls the daemon uses to take new TACACS connections, giving Fire Ant a live view of every authentication session passing through it. The injector then removes the library from disk after loading it into memory. A filesystem inspection can still show the tac_plus binary as intact, because the component doing the interception was injected into the running process rather than replacing the binary on disk.

That’s the architectural fact the rest of this post is built on: in-memory interception, combined with removal of the on-disk artifact after injection, means conventional filesystem inspection is not sufficient to detect the compromise. The telemetry that would normally expose the compromise is itself part of the attack surface.

TacTap wasn’t the only tool. Sygnia also identified BridgeAgent, a second implant that persists on the compromised Linux host by masquerading as a zabbix_agent.service systemd unit — running as root, configured to restart automatically, disguised as the monitoring infrastructure an operations team would normally trust by default. Between the two, Fire Ant had authentication interception on one axis and persistence-as-legitimate-monitoring on the other, and layered a third pattern on top of both: deliberate manipulation of the record itself. Sygnia’s own report describes this directly — the actor “manipulated the evidence layer” by suppressing router logs, hiding commit activity, filtering AAA requests, suppressing SNMP traps, and filtering command output. On the compromised Linux hosts, it went further: disabling SELinux, rewriting login-history records, and removing entries for privileged commands from system logs — the wtmp, utmp, and btmp artifacts investigators normally treat as a reliable account of who did what, when.

One additional detail worth including without overclaiming it: the TACACS credentials TacTap captured were obfuscated with a single-byte XOR key of 0xEF — the same key Mandiant previously documented in UNC3886’s TACACS-focused tooling, LOOKOVER. Sygnia treats this as tooling overlap that strengthens its assessment that Fire Ant’s activity strongly overlaps with UNC3886, not as independent proof the two are the same actor. Tooling similarity is corroborating evidence. It isn’t attribution.

The Assumption Underneath “Check The Logs”

Every incident response playbook, including the ones built into most data protection and recovery programs, treats telemetry as an observation of the system rather than as another system that can itself be compromised. A log file is data about an event. A router is infrastructure. Those feel like different categories, and the entire discipline of “go check the logs” depends on that distinction holding.

Fire Ant’s TACACS compromise collapses it. The router that generates the log, the authentication daemon that records the session, and the management host that stores the history are not neutral instruments standing outside the incident, observing it from a safe distance. They’re infrastructure — the same category of thing as the servers and workloads they’re supposedly reporting on — and infrastructure can be compromised. Once it is, the assumption that its output is a faithful record of what happened stops being a technical fact and becomes something closer to a hope.

This isn’t a claim that logs are worthless or that logging is a wasted investment. It’s a narrower and more useful claim, and it’s a data protection architecture question, not a network-hardening one: the evidence layer is only as trustworthy as the trust boundary it sits inside, and “check the logs” is an architectural assumption about where the attacker’s authority stops, not a permanent capability of the infrastructure that produces them. The assumption holds right up until the systems generating the evidence and the systems under attack share the same trust domain — and Fire Ant’s campaign is a demonstration of exactly how far that overlap can extend before anyone notices.

The Evidence Layer Inside The Blast Radius

The mechanism behind an evidence layer failure is easiest to see as a chain, and the failure is what happens when two links in that chain stop being independent of each other.

The critical failure is at step three, not step one. Compromise is not unusual — every incident response program is built around the premise that infrastructure gets compromised. What’s structural here is that the evidence source and the compromised system occupy the same trust domain, so the telemetry produced during the incident is not independent of the incident. This is a materially different problem than a logging gap. A gap means the record is incomplete and everyone knows it. This is worse: the record can be complete, internally consistent, and still not truthful, and there’s no missing field to flag it.

There’s a related failure pattern worth distinguishing here, not merging into it: The Server Was Fixed. Persistent Access Wasn’t. documents a case where remediation actions — a full server rebuild, a credential rotation — genuinely succeeded but never touched the layer where an attacker’s access actually lived. That’s a scoping failure in the response. Fire Ant is a different problem: the infrastructure used to establish what happened in the first place is the thing that’s compromised. One is about remediation missing a layer. The other is about the evidence for the remediation decision being untrustworthy before the decision gets made.

It’s also a different failure than the one Infrastructure Needs Auditability, Not Just Idempotency names in the Modern Infrastructure & IaC pillar, and the difference is worth stating precisely because the vocabulary is close enough to invite confusion. An evidence gap — the condition that post describes — means you cannot prove what happened, because no artifact connecting execution to authorization ever existed. This is worse: you can have a complete record, every field populated, every log line present, and still be unable to establish that the record is truthful. Absence is a known problem with known mitigations. A confident, complete, false record doesn’t announce itself the same way.

Evidence Independence, Not Telemetry Redundancy

Sygnia’s own recommendation for defenders is a cross-validation standard for the evidence layer, not a bigger dashboard: routers, TACACS servers, hypervisors, and jump hosts should all be treated as first-class forensic assets, and investigators should validate what the logs say against memory, disk, network traffic, authentication records, and configuration state — rather than trusting any single telemetry source on its own.

That standard implies a distinction most data protection programs don’t draw cleanly enough: telemetry redundancy is not the same thing as evidence independence. Sending logs to a second location, keeping a longer retention window, or standing up a SIEM that ingests everything doesn’t automatically produce independent evidence — it produces more copies. If the second location, the retention system, and the source all sit under the same administrative authority, and that authority is the thing an attacker has compromised, you don’t have ten independent witnesses. You have ten copies of the same testimony, and the same person coached all of them.

The actual test is narrower and harder to satisfy: a copy of evidence is independent only if the attacker cannot exercise the same authority over both the original and the copy. That’s a trust-boundary question, not a storage-location question. A log shipped to a SIEM that authenticates through the same TACACS infrastructure Fire Ant compromised isn’t independent of that compromise — it’s downstream of it. A log shipped to a system with a genuinely separate authentication path, separate administrative control, and no traversable trust relationship back to the source infrastructure is a different thing entirely, and it’s the thing “evidence independence” actually describes.

This is where the architectural conclusion sits, and it’s deliberately not a checklist. The operational question every data protection program should be able to answer isn’t “do we log enough” — it’s “if the systems generating our evidence were compromised today, which of our evidence sources would still be independent of that compromise, and which would just be more copies of the same thing.” If the honest answer is that most of the organization’s telemetry shares an authority path with the infrastructure it’s supposed to be watching, that’s the actual gap — and it’s exactly the kind of gap the Governance & Recovery Assurance stage is built to close. Fixing it is an architecture decision about where authority boundaries sit, not a retention-policy adjustment.

The article’s own argument stays architectural, not procedural — but applying it to a specific evidence source is a worksheet question, not a paragraph one. That’s a separate artifact, not a rewrite of this section’s conclusion:

Additional Resources

About The Architect

R.M.

Senior Solutions Architect with 25+ years of experience in HCI, cloud strategy, and data resilience. As the lead behind Rack2Cloud, I focus on lab-verified guidance for complex enterprise transitions. View Credentials →