{"id":925,"date":"2026-09-02T06:57:41","date_gmt":"2026-09-02T06:57:41","guid":{"rendered":"https:\/\/allcloudhost.net\/blogs\/?p=925"},"modified":"2026-08-28T01:34:45","modified_gmt":"2026-08-28T01:34:45","slug":"evooo1bot-linux-botnet-vps-security","status":"publish","type":"post","link":"https:\/\/allcloudhost.net\/blogs\/evooo1bot-linux-botnet-vps-security\/","title":{"rendered":"A New Linux Botnet Is Turning Unpatched Routers and Servers Into Proxy Networks"},"content":{"rendered":"

A botnet built almost entirely from vulnerabilities that already have patches<\/h2>\n

Security researchers documented a previously unknown Linux botnet in July 2026 named Evooo1Bot. The primary concern for VPS and dedicated server operators is not the malware’s sophistication, but its reliance on unpatched vulnerabilities. Evooo1Bot weaponizes at least ten known CVEs ranging from a 2007 Alcatel OmniPCX flaw to a 2025 D-Link DIR-868L router vulnerability, alongside an exploit module targeting eight additional flaws in platforms like Atlassian Confluence, WSO2, and Kubernetes. The CVE list it draws on turned out to be the more newsworthy part of the finding than the malware’s own code. This isn’t a zero-day story. It’s a story about how much damage a botnet can still do purely by targeting infrastructure nobody got around to patching, sometimes for the better part of two decades.<\/p>\n

Evooo1Bot Capabilities and Architecture<\/h2>\n

Evooo1Bot builds upon the public source code of the Mirai botnet from 2016 while introducing distinct operational features. The malware integrates encrypted Command-and-Control infrastructure to remain harder to detect at the network level, pairs with an SSH brute-force scanner that actively hunts for weak credentials on reachable systems, incorporates credential theft functions to extract sensitive access tokens, and utilizes a SOCKS5 relay module that turns infected devices into attacker proxies, on top of the separate exploit module targeting the eight additional flaws in Confluence, WSO2, and Kubernetes mentioned above, which extends the botnet beyond consumer network gear into self-hosted developer and orchestration tooling as well. Once a device is infected, that module routes other traffic through it, letting the attacker conduct follow-on operations while evading detection, in the researchers’ own framing, meaning the compromised server becomes the source IP address behind whatever the attacker does next, not the attacker’s own infrastructure.<\/p>\n

The primary targets documented so far are internet-facing edge devices: routers and firewalls from NETGEAR, Tenda, D-Link, and Telesquare, along with industrial equipment from Mitsubishi Electric and video systems from Hikvision. That list matters for a hosting-industry reader specifically because it overlaps with exactly the kind of network edge equipment a lot of small businesses run in front of their own office network or, in some cases, self-managed server setups, not just consumer routers sitting untouched in someone’s living room.<\/p>\n

VPS and Dedicated Server Risk Factors<\/h2>\n

Independent industry research on the broader botnet landscape backs up why this pattern deserves attention beyond routers specifically: recent tracking of the SystemBC botnet found that close to 80% of the compromised systems in that network were VPS instances, not consumer devices, exploiting servers running with unpatched vulnerabilities, sometimes dozens or hundreds of them accumulated over time. A VPS is a genuinely different risk profile than a router sitting behind a home network’s own firewall. It has a public IP address by design, it’s reachable directly from the internet, and unlike a managed shared hosting plan where the hosting provider handles OS-level patching, a VPS customer is usually responsible for their own operating system updates, which means the patching gap that makes a botnet like this possible is squarely the customer’s responsibility to close, not something a host handles automatically in the background.<\/p>\n

That’s worth being explicit about for anyone comparing VPS hosting plans<\/a>: the flexibility of a VPS, full root access, your own OS configuration, is also exactly what makes ongoing patching the customer’s job rather than the provider’s. A managed shared hosting plan trades away some of that flexibility for a host that handles the patching layer; a VPS keeps the flexibility and keeps the responsibility along with it. Neither trade-off is objectively better, but a business should know which one it actually signed up for before, not after, a compromise like this one surfaces.<\/p>\n

Server Patching and Hardening Best Practices<\/h2>\n

A handful of specific, low-effort habits close most of the gap this kind of botnet depends on. Automated security updates are the single highest-leverage step: unattended-upgrades<\/code> on Debian and Ubuntu, or dnf-automatic<\/code> on RHEL and Fedora, apply security patches without requiring someone to remember a manual update schedule, which matters because the CVEs Evooo1Bot exploits range across nearly two decades, meaning the gap it’s exploiting usually isn’t a brand-new zero-day nobody could have prepared for, it’s a patch that’s been sitting unapplied.<\/p>\n

SSH deserves specific attention since it’s the most commonly targeted entry point on any internet-facing Linux server: switching from password authentication to key-based authentication removes the brute-force attack surface almost entirely, and running a tool like Fail2ban to automatically block IP addresses after repeated failed login attempts closes off the slower, lower-volume brute-force attempts that key-based authentication alone doesn’t fully prevent on its own. Changing the default SSH port doesn’t stop a targeted attacker, but it meaningfully cuts down the volume of automated, opportunistic scanning traffic a server has to deal with day to day.<\/p>\n

Outbound traffic monitoring is the step most self-managed VPS owners skip entirely, and it’s specifically relevant to this kind of SOCKS5 proxy botnet, since a compromised server doing proxy work for someone else generates outbound connections to destinations the actual server owner never initiated. Periodically checking for unrecognized processes consuming unusual CPU or bandwidth, and reviewing outbound connections for unfamiliar IP ranges, is a basic check that catches exactly this kind of compromise, one that a server owner might otherwise not notice for months because the server itself keeps running normally from the owner’s own perspective; the resource being stolen is bandwidth and IP reputation, not the server’s ability to run the owner’s own applications.<\/p>\n

Indicators of Compromise (IOCs)<\/h2>\n

Because Evooo1Bot and SOCKS5 proxy botnets avoid drawing attention by keeping server applications running normally, administrators should review systems for concrete indicators rather than assuming everything is fine because nothing looks broken. Warning signs include unexpected outbound connections appearing in netstat<\/code> or firewall logs directed to unfamiliar IP addresses or ports, unfamiliar processes consuming steady CPU or bandwidth during idle application states, new or modified SSH authorized_keys<\/code> entries not added by the administrator, and unexplained bandwidth usage on hosting account metering caused by external traffic relaying. None of these checks require specialized forensics tooling; a server owner who has never run netstat<\/code> before can learn the handful of commands that matter in under an hour, and checking them periodically is a habit worth building alongside patching itself, not a one-time incident-response skill to learn only after something already looks wrong.<\/p>\n

Shared Hosting vs. VPS Security Responsibilities<\/h2>\n

It’s worth being precise about where responsibility actually splits, since “my host handles security” is true for some layers and false for others, and that split varies significantly by which hosting plan a customer is actually on. On shared hosting, the provider manages the underlying server OS, patches web server software, and isolates customer accounts. On VPS hosting, the customer owns the operating system layer outright; the host secures physical infrastructure and networking, but OS patching, SSH hardening, and internal compromise monitoring remain the customer’s responsibility.<\/p>\n

Managed VPS plans, where the provider explicitly includes OS patching and monitoring as part of the service, close this gap for a business that wants the resources of a VPS without taking on the ongoing patching workload personally, and it’s worth asking directly whether a given plan includes that or leaves it to the customer before assuming either way.<\/p>\n

None of these steps require security expertise most VPS owners don’t have. They require treating patching as a recurring task rather than a one-time setup step, which is the actual gap Evooo1Bot is built to exploit: not sophisticated evasion, just infrastructure nobody got around to updating. A botnet built from a two-decade span of already-patched CVEs is, in a real sense, a botnet built entirely out of postponed maintenance, and closing that gap is a schedule problem far more than it’s a technical one.<\/p>\n

Source: The Hacker News<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

A botnet built almost entirely from vulnerabilities that already have patches Security researchers documented a previously unknown Linux botnet in July 2026\u2026<\/p>\n","protected":false},"author":2,"featured_media":924,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":0,"rank_math_title":"Evooo1Bot: Why Unpatched Servers Become Proxy Networks","rank_math_description":"A newly discovered Linux botnet, Evooo1Bot, exploits 10+ known CVEs to turn devices into SOCKS5 proxies. Here's what VPS owners specifically need to check.","rank_math_focus_keyword":"VPS botnet security, SOCKS5 proxy malware, patch VPS server security","rank_math_canonical_url":"","rank_math_robots":[],"footnotes":""},"categories":[10],"tags":[],"class_list":["post-925","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-security"],"_links":{"self":[{"href":"https:\/\/allcloudhost.net\/blogs\/wp-json\/wp\/v2\/posts\/925","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/allcloudhost.net\/blogs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/allcloudhost.net\/blogs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/allcloudhost.net\/blogs\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/allcloudhost.net\/blogs\/wp-json\/wp\/v2\/comments?post=925"}],"version-history":[{"count":2,"href":"https:\/\/allcloudhost.net\/blogs\/wp-json\/wp\/v2\/posts\/925\/revisions"}],"predecessor-version":[{"id":1120,"href":"https:\/\/allcloudhost.net\/blogs\/wp-json\/wp\/v2\/posts\/925\/revisions\/1120"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/allcloudhost.net\/blogs\/wp-json\/wp\/v2\/media\/924"}],"wp:attachment":[{"href":"https:\/\/allcloudhost.net\/blogs\/wp-json\/wp\/v2\/media?parent=925"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/allcloudhost.net\/blogs\/wp-json\/wp\/v2\/categories?post=925"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/allcloudhost.net\/blogs\/wp-json\/wp\/v2\/tags?post=925"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}