Legacy Control
Linux issues do not often pop up in my cyber news feeds, for the simple fact that there rarely are any. There might be a cross platform mention from time to time, but thatās about it. And to be honest, the article that headed my research into this topic was buried somewhat in a list of others, and is dated from a couple weeks ago. I happened upon it; it wasnāt on my dashboard. All that said, Linux operating systems provide the backbone for many enterprises and platforms, and a vulnerability in them bears the same cause for concern as in other OSās, if not more simply because of the rarity.
Two weeks ago, The Hacker News reported on Flareās research into a previously undocumented Linux botnet operation dubbed SSHStalker. The attack combines 2009-era Internet Relay Chat (IRC) botnet tactics with modern mass-compromise automation. Now this may sound like a non-issue. After all, whoās still using an OS dating back to 2009? But this attack is deployed in such a way as to exploit legacy CVEās that remain in the kernel of Linux based systems, a foundational part of the code that is part and parcel of Linuxās integral backwards compatibility. Flare describes SSHStalkerās tactics as being low value against modern stacks, but effective against 'forgotten' infrastructure and long-tail legacy environments.
They cross-referenced this attack (after attracting it through a honeypot scheme as part of normal threat detection monitoring) to see if it matched any previously recorded incursion and found its behavior to be distinct. It maintained persistent access without executing any observable impact operations, despite having the capability to launch DDoS attacks and conduct cryptomining. There is confidence that this is more of a staging, testing, or strategic access retention for future use rather than an active attack campaign. Hence the āstalkerā nomenclature.
Persistence is maintained through a ākeep-aliveā command, a red flag to me as someone who uses Linux in analysis. āKeep-aliveā is a command for keeping a connection port open with regular refreshing; every minute, in this instance. Itās not always malicious. Itās often found in logs over the course of an active session, for instance. A ping between host and client to make sure both ends are still there. But it should be a consequence of that active session, not a root executable from the get go. Another of SSHStalkerās hallmarks is the execution of C program files to clean SSH connection logs and erase traces of malicious activity from them to reduce forensic visibility. The vector of attack with SSHStalker is one of brute force, rather than stealth. Flareās research team discovered that it leaves a fairly obvious trail behind it once one knows what theyāre looking for, and has detailed the structure and stages of its behavior in their article.
The danger of this attack is that it can lead to command-and-control of the kernel through the few legacy artifacts that may be present, which subsequently gives total access and operational control to every aspect of a systemās functions. This isnāt an actor looking to create zero-days, but is ādemonstrating strong operational discipline in mass compromise workflows, infrastructure recycling, and long-tail persistence across heterogeneous Linux environmentsā, according to Flare.
They go on to point out that in todayās digital environment, the relevance of exploiting the legacy CVEās is low for fully maintained infrastructure, but not zero. Meaning it affects only a small percentage of Linux servers. But their research scans uncovered upwards of seven thousand compromised target IPās in close timeline proximity to their honeypot, half of which were here in the US, and were heavily dominated by cloud hosting providers. That indicates influence over supply chains as opposed to individuals. The exploit kit is open source, and has a lower skill level requirements, giving it a wider range of utility for āmid-tierā actors. I suspect what weāre seeing here is the beginning of a malware-as-a-service. Itāll be worth keeping an eye out for it.
Posted, 2/26/26
