Sygnia’s writeup on the group it calls Velvet Ant describes the kind of incident that should make anyone responsible for a Linux fleet quietly close their laptop and go for a walk. The attackers backdoored PAM and OpenSSH on a target network and stayed for the better part of a decade. The network was isolated. The defenders weren’t asleep. They were doing what the cybersecurity industry has been selling for fifteen years: patching, monitoring, segmenting, hardening.
None of it mattered, because the thing that decides who gets to log in had already been rewritten.
A decade inside the door

The shape of the attack is older than most defenders care to admit. PAM, the pluggable authentication modules layer, is the per-process decision point for “should this account be allowed to do this thing right now.” If you modify the right .so file under /lib/security or quietly add a module to /etc/pam.d/, every credential check on that box runs through code you wrote. Add a similar tweak to a vendored OpenSSH binary and you own SSH key handling, session establishment, and the audit messages that come out the other side.
What’s striking about the Velvet Ant story is the dwell time. Close to ten years of full visibility into administrative activity on a segmented network. Every privileged session. Every audit log entry coming out of a tampered binary. Every “successful” login that the SOC saw and waved through.
Authentication is Tier 0, and almost nobody treats it that way. You can have a beautiful firewall topology, a competent EDR rollout, and a working SIEM, and still ship a build of sshd that smiles at one specific key fingerprint. Patching faster wouldn’t have helped here. Patching the wrong layer never does.
The thing watching auth has its own unauth bug
Splunk shipped a fix this week for CVE-2026-20253, a 9.8 unauthenticated flaw in Splunk Enterprise that lets a remote attacker create or truncate arbitrary files and, in practice, execute code. The product is, for many organizations, the one that watches authentication. Watches sshd. Watches sudo. Watches every event the PAM stack emits.

Pre-auth code paths on the platform that ingests your auth logs deserve the same paranoia you (hopefully) apply to your VPN concentrator. If a Velvet-style implant inside your auth stack would already be hard to spot, a compromise of the log aggregator above it removes the second pair of eyes entirely. Defense in depth means assuming the watcher gets popped too.
None of this is theoretical. The Splunk bug is the kind of thing that gets a public exploit inside a week and turns into “we found weird files in /opt/splunk” inside a month, if you’re lucky enough to notice. If you run Splunk Enterprise, your patch window for CVE-2026-20253 is “yesterday.”
The cybersecurity work most teams skip
Most authentication hardening guides stop at “enable MFA and rotate passwords.” That’s a useful baseline. It is not, on its own, threat detection for an attacker who has rewritten the function that decides what MFA even is.
If you want to make a Velvet-style implant harder to land and easier to find, the work is unglamorous and concrete:
- Inventory the PAM stack on every Linux host. Hash every .so under /lib/security and /lib64/security, every file in /etc/pam.d/, the sshd binary, the OpenSSH client libraries, and any vendored libpam fork. File integrity monitoring on these paths should alert on change, not summarize daily.
- Compare those hashes against the distribution’s signed package contents. Mismatches are not “noise.” They are either drift you should fix or implants you should hunt.
- Treat any change to /etc/nsswitch.conf, root or service-account authorized_keys, or sudoers as a high-severity event in your incident response workflow, even on systems “managed” by configuration tools.
- Enforce brute-force controls and rate limiting at sshd, at the bastion, and at the identity provider. None of these would have stopped Velvet Ant, but they raise the cost of the noisier initial-access work that lets a similar group get a foothold in the first place.
- Pull SSH session and sudo telemetry off the host. Auth logs that live only on a box you’ve already lost are not logs. They are creative writing.
- Segment your log aggregator. Patch it like an edge appliance. Apply the same security hardening you would to your domain controllers, because compromise of the log platform is compromise of every detection downstream of it.
For the cyber security teams already doing most of this: when did you last verify it on the long tail? The dev cluster nobody owns. The jump host the contractor set up in 2019. The legacy box still running the build for that one customer. Velvet Ant did not pick its target because the SOC was bad. It picked it because the auth stack on an isolated network is exactly where nobody’s looking.
Attribution is not a control
This week also brought a Ukrainian national pleading guilty to Conti involvement and Google filing a civil suit against a Chinese smishing network that was abusing Gemini for phishing kit generation. Both are good outcomes. Neither one removes a single backdoored sshd from a single production box.
The gap between “we know who they are” and “they’re no longer in our environment” is measured in years, sometimes decades. The Conti operator pleading guilty in 2026 was active in 2021. Velvet Ant’s implant was sitting in PAM since roughly 2016. By the time the news cycle catches up, the controls you needed were the ones you should have built when nobody was watching.
Programs that lean on upstream wins, law enforcement takedowns, vendor lawsuits, or attribution reports as their threat-protection strategy are programs that fail quietly. The thing that catches the next Velvet Ant on your network is going to be a junior analyst noticing that a .so file under /lib/security has a different hash this week than last week, and being empowered to chase it. Build the program that produces that analyst and that workflow. Everything else is theater.
Sources
- Chinese hackers hijack auth flow, spy on isolated network for a decade
- China-Linked Hackers Backdoored Linux Login Software to Hide for Nearly a Decade
- Critical Splunk Enterprise Flaw Lets Attackers Run Code Without Authentication
- Ukrainian national pleads guilty to role in Conti ransomware operation
- Google Sues Chinese Smishing Network Accused of Using Gemini AI in Phishing
Take Control of Your Server Security
Don't let brute-force attacks slow you down. Try IPBan Pro risk-free for 30 days.
Secure. Automated. Lightweight.
Take Control of Your Server Security
Don't let brute-force attacks slow you down. Try IPBan Pro risk-free for 30 days.
Secure. Automated. Lightweight.
