Evooo1Bot: A Multi-Functional Linux Botnet That Turns Compromised Gateways into SOCKS5 Relays, SSH Spreaders, and DDoS Tools

Evooo1Bot: A Multi-Functional Linux Botnet That Turns Compromised Gateways into SOCKS5 Relays, SSH Spreaders, and DDoS Tools 1. Basic Information - Severity: High - Title: Multi-Functional Linux Botnet “Evooo1Bot” - Publisher: FortiGuard Labs - Release Date: 2026-08-13 - Update Date: None - Original Source: FortiGuard Labs - Related Sources: BleepingComputer, The Record - Malware: Evooo1Bot, Mirai variant - Groups: Unknown in public reports - CVEs: CVE-2007-3010, CVE-2016-6277, CVE-2018-14558, CVE-2019-14931, CVE-2020-10987, CVE-2021-46422, CVE-2022-37055, CVE-2024-29269, CVE-2025-10123, CVE-2025-55583, and others - Products: Alcatel OmniPCX Enterprise, NETGEAR/Tenda/D-Link routers, Mitsubishi Electric ME-RTU, Telesquare devices, Hikvision IP cameras, Atlassian Confluence, Zyxel firewalls, TP-Link Archer AX21, PHP-CGI, Kubernetes ingress-nginx, WSO2 products 2. Summary This is a Mirai-variant botnet. It breaks into Linux gateways using known vulnerabilities and over 150 credential combinations. It deploys payloads that support 12 CPU architectures. It combines encrypted C2 communications, SOCKS5 relaying, credential sniffing, SSH spreading, persistence, and 16 types of DDoS attacks into a single package. 3. Attack Flow Chain A: Exploiting Publicly Exposed Devices - The attacker sends exploit requests for known vulnerabilities to public devices like Alcatel, NETGEAR, Tenda, Mitsubishi Electric, Telesquare, and D-Link. - If the exploit succeeds, it calls 91.92.40[.]118/wget.sh using a command that includes a campaign label for the specific target. - The loader tries download tools in this order: wget ,busybox wget ,curl , andtftp . - It chooses the correct payload from 12 binary options that match the CPU architecture, saves it to a temporary path, gives it execution rights, and runs it. - It clears the Bash history after infection. Chain B: Evading Analysis and Establishing C2 - It decrypts more than 60 string blocks inside the binary using AES, ChaCha20, and XOR methods. - It checks the filesystem, processes, services, and VM/container fingerprints to look for analysis tools, sandboxes, and honeypots. - If it passes these checks, it connects to an encrypted C2 server over TCP port 443. - It waits for operator commands and runs shell, file transfer, sniffer, SOCKS, SSH scanner, DDoS, and exploit modules as needed. Chain C: Spreading via SSH Credential Attacks - It checks SSH banners against known honeypot strings and skips matching targets. - It tries to log in using more than 150 username and password combinations. - After a successful login, it checks /proc/version , the PID 1 command line, and Cowrie/Kippo paths. - If it confirms the target is a real Linux system with no honeypot indicators, it delivers the payload. Chain D: Post-Compromise Relaying, Persistence, and Attacks - It uses the !persist command to try setting up persistence via systemd, SysV init, cron, shell profiles, andrc.local all at once. - For SOCKS, it creates a TCP port 1080 listener in direct mode, and an outbound encrypted relay connection in reverse mode. - It runs multiple proxy sessions independently to use the victim IP for attack relaying or internal network access. - The sniffer module collects HTTP Basic Authorization and Cookie headers and saves them to /tmp/.sniff.log . - It runs DDoS attacks using 16 flood methods derived from Mirai. - The exploit module scans for additional devices and enterprise applications, and delivers the same loader to vulnerable entry points. 4. Attacker's Position and Execution Location - Vulnerability exploits, SSH login attempts, and operator actions happen from external attacker infrastructure. - The loader and Evooo1Bot run on compromised Linux routers, firewalls, cameras, gateways, and similar devices. - Direct SOCKS opens a listener on the victim device, while reverse SOCKS makes an outbound connection from the victim device to a relay server. - Inference: Writing to systemd, /etc/init.d ,/etc/profile.d ,/etc/rc.local , and similar paths requires high privileges on the target. The success rate depends on the service privileges and device configuration during the initial breach. - Public reports do not mention any privilege escalation features built into Evooo1Bot itself. 5. Visibility for Victims and Administrators - No user action is required. The attack starts as an HTTP request to a public management interface or an SSH login attempt. - Administrators can see requests to known vulnerability paths, loader downloads, unknown ELF files, cleared Bash history, and continuous traffic to TCP port 443. - After infection, administrators might see a TCP port 1080 listener, outbound relay connections, many short SSH connections, proxy traffic pointing inside or outside the network, and DDoS traffic. - A systemd unit named Apache HTTPD Cache Manager or a download cron job running every 5 minutes may look like normal maintenance tasks. - Fortinet showed regional telemetry data, but did not disclose the exact number of infected organizations. 6. Conditions for Success and Failure Conditions for Success - The target device is reachable from the internet, and the matching known vulnerability is unpatched. - Or, SSH is reachable, and the built-in dictionary credentials are valid. - The device can communicate with the loader host and the C2/relay, and can execute binaries for its architecture. - Anti-analysis checks do not flag the execution environment as a sandbox or honeypot. - The malware has sufficient permissions to write to the target paths for persistence. Conditions for Failure - Management interfaces and SSH are not exposed to the internet, known vulnerabilities are patched, and default credentials are removed. - Exploit requests, loader IP addresses, unknown ELF files, and C2 traffic are blocked by IPS, EDR, or egress controls. - The CPU architecture does not match, download utilities are missing, or execution permissions are lacking, preventing the payload from starting. - Honeypot or analysis environment indicators match the checks, causing the malware or SSH scanner to stop. - Built-in exploits are implemented incorrectly. Fortinet confirmed that some entries, including the MOVEit example, cannot be exploited as-is. 7. What Happens on Success - The compromised device provides an operator shell and two-way file transfer. - It acts as a direct or reverse SOCKS5 proxy to hide attack sources, bypass regional blocks, and relay traffic into internal networks. - It may collect HTTP Basic and Cookie information. - It attempts to spread to additional targets using SSH credential attacks and CVE exploit modules. - It tries to survive reboots and re-run after logins using systemd, SysV init, cron, profiles, and rc.local . - It joins 16 types of network flood attacks. - Important: Fortinet only observed active exploitation attempts and C2 telemetry. This does not mean every request resulted in a successful compromise or that all modules were used in real environments. 8. Observable Logs - Email is not used as an initial vector in public reports. Proxy / SWG / DNS 91.92.40[.]118/wget.sh - Encrypted C2 traffic using unknown binaries over TCP port 443 (standard HTTPS has not been confirmed). - Long-lived connections to operator-specified relays and multiple sessions from the same host. - Downloads of the same payload via wget , BusyBoxwget ,curl , andtftp . Endpoint / EDR - wget.sh , unknown ELF files in temporary paths, and hashes of binaries for 12 architectures. - Cleared Bash history equivalent to history -c . /tmp/.sniff.log - Changes to /proc/self/oom_score_adj and kept open handles to/dev/watchdog . - A systemd unit named Apache HTTPD Cache Manager . - Modifications to /etc/init.d ,/etc/profile.d , and/etc/rc.local . - A download cron job running every 5 minutes. - Interactive shells using /dev/ptmx . Identity / IdP - No IdP-specific activity is mentioned in public reports. - Failed and successful SSH logins trying more than 150 username/password combinations in a short time. - Login attempts containing service account names (such as jenkins, postgres, oracle, nagios, and deploy). SaaS / Cloud - Built-in exploit requests targeting Atlassian Confluence, Kubernetes ingress-nginx, WSO2, PHP-CGI, and others. - Since some exploit table entries fail due to poor implementation, do not judge a compromise based solely on observed requests. Network - HTTP requests to vulnerable URIs. - TCP port 1080 SOCKS5 listeners or reverse relays. - SSH connections to many different destinations. - Floods of UDP, DNS, SYN, ACK, GRE, fragmented TCP, and HTTP traffic. - Sniffing targeting HTTP Basic Authorization and Cookie headers. 9. Determining Attack Success Contact Only - Exploit requests, SSH banner grabs, and failed logins only. No payload callbacks or process executions. User Interaction - Not required. No applicable stage. Initial Execution - Host evidence of loader downloads, architecture-specific ELF creation, execution, and cleared Bash history. Malware or Authentication Success - Evooo1Bot process and C2 check-in, or post-login probes and payload delivery after a successful SSH login. Data Theft or Session Compromise - Creating /tmp/.sniff.log is only the collection phase. Confirm theft only if data is transferred outward, requested by C2 commands, or received by the attacker. Subsequent Compromise Confirmation - Confirm persistence artifacts, SOCKS sessions, operator shells, payload delivery to additional hosts, or DDoS participation. 10. Investigation Playbook Trigger - Fortinet IOCs, known exploit paths, unknown ELF files connecting to TCP port 443 or TCP port 1080, 5-minute cron jobs, or /tmp/.sniff.log . Initial Checks - Correlate exploit requests, payload callbacks, file creation, and process starts chronologically. - Separate scanner contact from successful compromises. - Check the running user, effective privileges, device model, firmware, and public management interfaces. - Preserve hashes, memory, open soc