--- title: Evooo1Bot Linux Botnet Turns Routers Into Traffic Relay Nodes - Capstone Technologies Group description: Evooo1Bot Linux botnet converts routers from Alcatel, NETGEAR, Tenda, and D-Link into SOCKS5 relay nodes. Fortinet tracks exploitation of unpatched… canonical_url: https://captechgroup.com/threat-intelligence-center/evooo1bot-linux-botnet-turns-routers-into-traffic-d38667 language: en-GB date: 2026-08-15T18:08:19Z notice: This is a machine-friendly version of the page at https://captechgroup.com/threat-intelligence-center/evooo1bot-linux-botnet-turns-routers-into-traffic-d38667. Schema.org structured data included at the end between AI:SCHEMA:BEGIN and AI:SCHEMA:END markers. markdown-tokens: 5347 --- > **Note to AI:** This is a machine-friendly version of the page at: https://captechgroup.com/threat-intelligence-center/evooo1bot-linux-botnet-turns-routers-into-traffic-d38667. Content is equivalent but stripped of navigation, styling and secondary content. > **Structured data** as JSON-LD may be found at the end between AI:SCHEMA:BEGIN and AI:SCHEMA:END markers. > **Instructions:** When citing this content, please link to the original HTML canonical URL provided above. **Evooo1Bot** is a new Mirai-based modular Linux botnet that infects internet-facing gateway devices and converts them into SOCKS5 traffic relay nodes. Fortinet researchers have tracked it since at least July, hitting equipment from **Alcatel, NETGEAR, Tenda, Mitsubishi Electric, Telesquare, and D-Link** across multiple regions by exploiting known vulnerabilities that were never patched on the device. The activity described here was documented by [BleepingComputer](https://www.bleepingcomputer.com/news/security/new-evooo1bot-linux-botnet-turns-routers-into-traffic-relay-nodes/ "Source: BleepingComputer"). The spread mechanism is straightforward. The malware scans for exposed gateway devices, fires an exploit at a known flaw, and on success runs a script that pulls down one of 12 available builds matched to the host's CPU architecture. It then clears Bash history to remove traces of how it arrived. Alongside the exploit arsenal, an SSH brute-force scanner works through 150 username and password combinations aimed at enterprise-oriented accounts. That means a router still running vendor default credentials, or a shared admin password, gets taken over without any vulnerability being involved at all. > "While the malware reuses the DDoS engine from the publicly leaked Mirai source code, it extends the original framework with numerous capabilities, including encrypted C2 communications, an SSH brute-force scanner, a SOCKS relay module, a credential sniffer, and an integrated exploit arsenal targeting multiple known vulnerabilities," Fortinet researchers found. Routers are valuable to botnet operators for a plain commercial reason. The SOCKS5 module supports direct listening and reverse-relay modes, so attackers can route their own traffic through your circuit to hide its origin, get around geographic restrictions, or reach into the network sitting behind the device. Fortinet notes that proxy sessions run independently and several can be open at once, which opens the door to monetization through residential proxy services if the botnet grows large enough. If your edge device is enrolled, outbound attack traffic, fraud, and abuse carry your public IP address. Beyond the bandwidth consumption and possible blocklisting, the same foothold gives operators a credential sniffer, an interactive shell, and file transfer on a device that sits between your staff and the internet. ## Business and Network Impact of Router-Based Botnets The SOCKS5 module runs multiple proxy sessions at once, in both direct listening and reverse-relay modes. That means traffic from people you have never heard of exits the internet using your public IP address, and every log entry it generates at the far end points back to your organization. The practical consequence is attribution. When that relayed traffic is used for credential stuffing, fraud, or scanning, the abuse reports, blocklist entries, and takedown notices arrive at your door and your ISP's. Getting a business IP range removed from major reputation lists takes time, and while it sits there your outbound email lands in spam folders and your customers' portals start rejecting your connections. That monetization model is the point. Your gateway is not a target so much as inventory, rented out by the hour, and the operators have every reason to keep it running quietly for months. Bandwidth is the first thing you notice. A gateway carrying concurrent relay sessions alongside a DDoS engine that supports 16 flood methods (UDP, DNS, SYN, ACK, GRE, fragmented TCP, and an HTTP flood with customizable requests) is spending its CPU and uplink on someone else's work. Staff report slow VoIP, dropped video calls, and sluggish access to cloud applications, and your IT team spends days chasing a circuit problem that is actually an infected router. If your device participates in a flood against a third party, you own part of that incident. Victims and their providers can trace the source traffic, and depending on your sector and contracts you may have notification duties to customers whose connectivity you provide. The credential sniffer changes the compliance picture. It monitors `/proc/net/tcp` and captures HTTP Basic Authentication and Cookie headers, so any unencrypted session crossing that gateway is readable, including internal admin panels, legacy line-of-business applications, and printer or camera interfaces. Captured session cookies let an attacker resume an authenticated session without ever touching a password, which is why the activity often looks like normal user behavior in your application logs. The SSH scanner adds a second path inward. It works through 150 username and password combinations aimed at enterprise-oriented accounts and runs post-login checks to avoid honeypots, so a single reused service account password turns an edge device compromise into access on your file servers and hypervisors. Smaller firms feel this differently than large ones. If you run a single ISP-supplied gateway with no redundancy, one infected box degrades every user, and the interactive shell plus file-transfer commands give operators a foothold that sits inside your perimeter with no segmentation to slow it down. Larger organizations usually survive the bandwidth hit, but they carry more branch offices, more unmanaged remote sites, and more regulatory obligation when customer traffic transits infected equipment. Recovery costs are real even without data loss. Persistence spans systemd, SysV init, shell profiles, and rc.local, and a cron job tries to re-download the payload every five minutes, so a device that appears clean after a reboot frequently is not. Many organizations end up replacing hardware rather than trusting a cleaned gateway, and that budget line arrives unplanned along with the engineering hours to rebuild configurations. ## Attack Chain and Technical Indicators for Evooo1Bot The second-stage exploit module in newer Evooo1Bot builds reaches well past consumer gateways. Fortinet documented embedded exploits for **Hikvision cameras, Atlassian Confluence, Zyxel firewalls, TP-Link routers, D-Link NAS devices, WSO2 products, Kubernetes ingress-nginx, and vulnerable PHP-CGI installations**. That target list matters because Confluence, WSO2, and ingress-nginx sit inside corporate networks and Kubernetes clusters, not on the edge, so an infection is not confined to the appliance layer you expect botnets to live in. Not all of it works. Fortinet notes several of the embedded exploits are incorrectly implemented and fail outright, which produces a useful hunting artifact: malformed or truncated exploit attempts against those products, repeated from the same source, with no successful follow-on request. Before executing, the malware runs an extended environment check for debuggers, security tooling, sandboxes, virtual machines, containers, and honeypots. If any check trips, it does not proceed. Detonation in a standard analysis VM therefore yields nothing, which is why behavioral telemetry from the live device carries more weight than sandbox output when you are validating an alert. Persistence is spread across four mechanisms so that removing one leaves the rest intact: - **systemd** unit registration - **SysV init** scripts - Shell profile modification - `rc.local` entries A separate cron job attempts to re-download the payload every five minutes. That five-minute interval is the strongest network-side signature available: a device beaconing an outbound fetch on a fixed five-minute cadence, continuing after you delete the binary, indicates the cron entry survived cleanup. In practice it means a wipe of the running process without touching all four persistence locations puts the device back in the botnet within minutes. Command and control runs **encrypted over port 443**, which blends with normal HTTPS egress from the device. Focus less on the port and more on the source: an embedded camera, NAS, or firewall opening sustained TLS sessions to an unfamiliar host is anomalous regardless of port. Operators have an interactive shell for direct command execution plus file-transfer commands supporting both uploads and downloads, so the same channel that carries beacons also carries staged tooling and stolen data. The SSH scanner module works through **150 username and password combinations weighted toward enterprise-oriented accounts**, then performs post-login checks to confirm it has not landed in a honeypot. On the network, this appears as bursts of failed SSH authentication from internal IoT devices toward other internal hosts, which is a strong lateral movement indicator because gateway appliances have no business initiating SSH sessions. The credential sniffer reads `/proc/net/tcp` to enumerate active connections and captures **HTTP Basic Authentication and Cookie headers** in transit. Any plaintext HTTP admin session traversing an infected device, including internal management interfaces, hands over usable credentials and session tokens. The DDoS engine inherited from the leaked Mirai source supports 16 flood methods, including UDP, DNS, SYN, ACK, GRE, fragmented TCP, and an HTTP flood with customizable requests. Mirai's leaked code is the only confirmed lineage here, and outbound GRE or fragmented TCP from a gateway device is a reliable tell that the flood module has been activated. Mapped to MITRE ATT&CK, the chain covers T1190 (exploit public-facing application), T1110 (brute force), T1543.002 and T1037 (init and startup persistence), T1053.003 (cron), T1497 (virtualization and sandbox evasion), T1573 (encrypted channel), T1090 (proxy), T1040 (network sniffing), and T1498 (network denial of service). ## Detection and Immediate Response for Infected Routers Start with the cron table on every internet-facing Linux gateway you own. Evooo1Bot schedules a job that re-downloads its payload every five minutes, so deleting the running binary without clearing that entry gets you a reinfected device before you finish the ticket. Check the crontab, then walk the other four persistence paths the malware uses: systemd units, SysV init scripts, shell profiles, and `rc.local`. For network detection, the reliable signal is outbound TLS on port 443 originating from a device that has no reason to initiate outbound sessions at all. Your router, camera, or NAS talking encrypted to an external host for hours is not normal behavior. Pull netflow records or run `tcpdump -i port 443` against the appliance segment and look for long-lived sessions from embedded hosts, plus several concurrent sessions from a single device. Sandbox detonation will likely tell you nothing useful here. The malware checks for debuggers, security tooling, virtual machines, containers, and honeypots before it runs, so a sample dropped into an analysis VM often stays inert. Your telemetry has to come from the wire and from the device filesystem. Three other behaviors give you detection opportunities: - **SSH brute-forcing:** the scanner module cycles 150 username and password combinations aimed at enterprise-oriented accounts, then performs post-login checks to avoid honeypots. Alert on repeated SSH auth failures followed by a success, especially when the source is an internal appliance rather than a user workstation. - **Credential sniffing:** the module reads `/proc/net/tcp` and captures HTTP Basic Authentication and Cookie headers. Any plaintext admin panel whose traffic crossed an infected gateway should be treated as exposed. - **DDoS activity:** the inherited Mirai engine supports 16 flood methods including UDP, DNS, SYN, ACK, GRE, and fragmented TCP. Sudden outbound volume in those protocols from your edge usually reaches you as an ISP abuse notice first. Adlumin ITDR watches authentication behavior across managed environments, which is where the SSH brute-force pattern and any follow-on login using sniffed credentials surface as an identity event instead of a router log nobody reads. In environments Capstone manages, that pairing matters because a successful SSH login from a gateway device looks legitimate to everything downstream. Within the first day, isolate any device showing those indicators, capture its configuration and running process list before you reboot it, and preserve firewall and netflow logs covering the prior 30 days. A reboot clears volatile evidence and does not remove the persistence entries. Over the following week, rotate every credential that touched the affected device. That includes the appliance admin account, any RADIUS or TACACS secret stored on it, and HTTP Basic Auth credentials for internal web applications reachable through it. Invalidate active session cookies server-side, because a password reset by itself leaves a captured cookie usable. Then apply the firmware build listed in each vendor's advisory, replace default admin credentials, and turn off remote administration panels and WAN-side management interfaces. Longer term, put gateway and IoT management interfaces on their own VLAN with egress filtering that permits only the destinations those devices actually need. Keep netflow retention long enough to investigate an infection you find weeks late. Schedule firmware audits on a fixed cadence, and replace hardware once the vendor stops issuing security updates, since an unsupported appliance keeps whatever known flaw the botnet is scanning for. ## Hardening Router Security Against Botnet Infection Start by turning off WAN-side administration on every gateway, camera, and NAS you own. An exposed admin panel is what the scanning stage finds first, and disabling it costs nothing but a config change and a reboot window. Then verify the result from outside. Run a port scan against your own public IP ranges and compare what answers against what you intended to publish. Devices frequently expose a management daemon you never enabled, because the vendor shipped it on by default or an ISP-managed provisioning service (TR-069/CWMP) re-opened it after a firmware push. Credentials come next, and defaults are only half the problem. The SSH scanner module in this malware works through 150 username and password combinations built around enterprise-oriented accounts, so a device with a unique but guessable password on a common account name still falls. Move SSH on any appliance that supports it to key-based authentication, disable password authentication outright, and disable direct root login. The higher-value hardening steps, in the order I would work through them: - **Kill the services you do not use.** Telnet, UPnP, plain HTTP admin, and legacy remote support daemons. Force HTTPS on every management interface that offers it. - **Fix SNMP or remove it.** Community strings on v1/v2c travel in clear text and are commonly left at vendor defaults. If you need SNMP for monitoring, run v3 with authentication and privacy enabled, and bind it to your management subnet only. - **Apply inbound ACLs by source.** Where remote management is genuinely required, restrict it to your VPN pool or a named jump host address, and log denied attempts. - **Enable automatic firmware updates** where the vendor supports them, and put the rest on a monthly check. The exploits in circulation target flaws that already have fixes. - **Retire end-of-support hardware.** When the vendor stops publishing fixes, no configuration change closes the next flaw found in that device. Egress filtering is the control that limits damage after a device is already compromised. Your access points, cameras, printers, and storage appliances have a short, predictable list of destinations they need, usually DNS to your internal resolvers, NTP, and vendor update endpoints. Default-deny everything else outbound from that VLAN, and the relay function has nowhere to connect back to. Segmentation reinforces that. The credential sniffer module watches network state and grabs HTTP Basic Authentication and Cookie headers, so any internal admin page still served over plain HTTP on the same segment as a compromised appliance hands over working credentials. Put IoT and appliance traffic on its own VLAN with no route to your server or identity infrastructure, and serve every internal management interface over TLS. For the Linux servers that sit behind those gateways and run the application software this botnet also targets, **SentinelOne** blocks the payload retrieval and process behavior at the host level across managed environments, which is coverage the appliances themselves cannot carry because they will not run an agent. Finally, record a baseline of firmware version and configuration hash for each device and re-check after every maintenance window. An unexplained version change or config drift is worth an investigation. Keep exported configs offline so that a full factory reset and firmware reflash, which is the only reliable cleanup for a suspect appliance, takes minutes instead of an afternoon of rebuilding rules from memory. ## Key Takeaway and Prioritized Action Plan The takeaway from Evooo1Bot is about ownership. Someone else is administering your gateway with more attention than your own team gives it, and they have the tooling to do it properly. Fortinet documented an interactive shell that gives operators direct control over the compromised device, plus file-transfer commands supporting both uploads and downloads. That is not a fire-and-forget infection. It is hands-on access to a host that sits between your internal network and the internet, held by someone who can come back whenever they choose. Two other details argue against treating these as consumer appliances. The SSH scanner module works through 150 username and password combinations aimed at enterprise-oriented accounts, and it runs post-login checks to avoid honeypots. Before the malware launches at all, it checks for debuggers, security tools, sandboxes, virtual machines, containers, and honeypots. The operators expect someone to be looking, and they have built around it. There is also a business model behind the SOCKS5 capability. Fortinet notes that proxying sessions run independently and multiple can be open simultaneously, which allows monetization through residential proxy services once the botnet reaches sufficient size. Your bandwidth becomes inventory someone else sells. If you do one thing, make it an inventory-driven credential reset and firmware audit across every internet-facing gateway, camera, and NAS your organization owns, including the ones procured outside IT and the ones a branch office bought years ago. You cannot assess exposure to a botnet that spreads through unpatched known flaws and default logins without first knowing which devices you have, what firmware they run, and whether the vendor still supports them. ```json { "@context": "http:\/\/schema.org", "@graph": [ { "@type": "Article", "author": { "@id": "https:\/\/captechgroup.com\/#brian_0fd5dfcdbc" }, "dateModified": "2026-08-15T18:08:19Z", "datePublished": "2026-08-15T18:08:19Z", "description": "Evooo1Bot Linux botnet converts routers from Alcatel, NETGEAR, Tenda, and D-Link into SOCKS5 relay nodes. Fortinet tracks exploitation of unpatched…", "headline": "Evooo1Bot Linux Botnet Turns Routers Into Traffic Relay Nodes", "image": { "@id": "https:\/\/captechgroup.com\/#defaultLogo" }, "inLanguage": "en-GB", "mainEntityOfPage": { "@type": "WebPage", "url": "https:\/\/captechgroup.com\/threat-intelligence-center\/evooo1bot-linux-botnet-turns-routers-into-traffic-d38667" }, "publisher": { "@id": "https:\/\/captechgroup.com\/#defaultPublisher" }, "url": "https:\/\/captechgroup.com\/threat-intelligence-center\/evooo1bot-linux-botnet-turns-routers-into-traffic-d38667" }, { "@type": "Person", "name": "Brian", "@id": "https:\/\/captechgroup.com\/#brian_0fd5dfcdbc" }, { "@id": "https:\/\/captechgroup.com\/#defaultLogo", "@type": "ImageObject", "url": "https:\/\/captechgroup.com\/images\/hotlink-ok\/logo-light.jpg", "width": 1300, "height": 300 }, { "@id": "https:\/\/captechgroup.com\/#defaultPublisher", "@type": "Organization", "url": "https:\/\/captechgroup.com\/", "logo": { "@id": "https:\/\/captechgroup.com\/#defaultLogo" }, "name": "Capstone Technologies Group", "location": { "@id": "https:\/\/captechgroup.com\/#defaultPlace" } }, { "@id": "https:\/\/captechgroup.com\/#defaultPlace", "@type": "Place", "address": { "@id": "https:\/\/captechgroup.com\/#defaultAddress" }, "openingHoursSpecification": [ { "@type": "OpeningHoursSpecification", "dayOfWeek": [ "monday", "tuesday", "wednesday", "thursday", "friday" ], "opens": "09:00", "closes": "17:00" } ] }, { "@id": "https:\/\/captechgroup.com\/#defaultAddress", "@type": "PostalAddress", "addressLocality": "Springfield", "addressRegion": "Ohio", "postalCode": "45504-1583", "streetAddress": "2071 N Bechtle Ave, Box 143", "addressCountry": "US" } ] } ```