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

1. The attacker sends exploit requests for known vulnerabilities to public devices like Alcatel, NETGEAR, Tenda, Mitsubishi Electric, Telesquare, and D-Link.
2. If the exploit succeeds, it calls 91.92.40[.]118/wget.sh using a command that includes a campaign label for the specific target.
3. The loader tries download tools in this order: wget, busybox wget, curl, and tftp.
4. 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.
5. It clears the Bash history after infection.

Chain B: Evading Analysis and Establishing C2

1. It decrypts more than 60 string blocks inside the binary using AES, ChaCha20, and XOR methods.
2. It checks the filesystem, processes, services, and VM/container fingerprints to look for analysis tools, sandboxes, and honeypots.
3. If it passes these checks, it connects to an encrypted C2 server over TCP port 443.
4. 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

1. It checks SSH banners against known honeypot strings and skips matching targets.
2. It tries to log in using more than 150 username and password combinations.
3. After a successful login, it checks /proc/version, the PID 1 command line, and Cowrie/Kippo paths.
4. 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

1. It uses the !persist command to try setting up persistence via systemd, SysV init, cron, shell profiles, and rc.local all at once.
2. For SOCKS, it creates a TCP port 1080 listener in direct mode, and an outbound encrypted relay connection in reverse mode.
3. It runs multiple proxy sessions independently to use the victim IP for attack relaying or internal network access.
4. The sniffer module collects HTTP Basic Authorization and Cookie headers and saves them to /tmp/.sniff.log.
5. It runs DDoS attacks using 16 flood methods derived from Mirai.
6. 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

• 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, BusyBox wget, curl, and tftp.

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

1. Correlate exploit requests, payload callbacks, file creation, and process starts chronologically.
2. Separate scanner contact from successful compromises.
3. Check the running user, effective privileges, device model, firmware, and public management interfaces.
4. Preserve hashes, memory, open sockets, and persistence files.

Endpoint

• Check for changes in systemd, SysV, cron, profiles, and rc.local. Also check shell history, temporary paths, watchdogs, and OOM settings.
• Collect ELF architecture, hashes, parent processes, and command lines.
• Do not display the contents of /tmp/.sniff.log carelessly; treat it as sensitive data.

Authentication and Cloud

• Identify where successful SSH accounts or identical credentials are used elsewhere, and rotate those credentials.
• Check requests, authentication logs, and audit logs for Confluence, Kubernetes, WSO2, PHP-CGI, and similar applications.

Subsequent Actions

• Search for internal traffic via SOCKS, additional SSH scans, file uploads/downloads, DDoS activity, and secondary payloads.
• Investigate secondary attacks originating from the compromised device, not just the original sender.

Containment

• Make management interfaces private, isolate the host from the network, and block C2, relays, and loaders.
• Rebuild the device using updated firmware or vendor-recommended images, and change all management credentials.
• Replace end-of-life (EOL) devices and audit other devices of the same model and firmware.

Determination Categories

• Exploit Attempt Only
• Payload Downloaded
• Evooo1Bot Executed
• C2 Check-in Confirmed
• Credential Capture Suspected/Confirmed
• Proxy/Pivot Confirmed
• Propagation or DDoS Confirmed

11. Defense and Detection Ideas

Single Events

• Communication with 91.92.40[.]118
• /tmp/.sniff.log
• Apache HTTPD Cache Manager systemd unit
• curl or wget piped to a shell every 5 minutes
• TCP port 1080 listeners on network appliances

Chronological Correlation

• Exploit request or successful SSH login → wget.sh → architecture-specific ELF → history cleared → TCP port 443 C2 → persistence → SOCKS/scan/DDoS

Threat Hunting Perspectives

• Unusual long-lived outbound TCP port 443 connections from edge devices.
• TCP port 22 connections from a single device to many hosts.
• Continuous checks of /proc/version, /proc/1/cmdline, and Cowrie/Kippo paths.
• Simultaneous creation of system services and cron jobs.
• Listeners or floods starting immediately after C2 connections.

Log Gaps

• Edge device process and file telemetry.
• East-west traffic flows and SOCKS sessions.
• Shell and audit logs.
• Firmware and configuration change histories.
• Management-plane access logs.
• Packet metadata and identification of egress TLS/encrypted traffic.

Priority Actions

1. Block public access to management interfaces and SSH, and maintain an asset inventory.
2. Patch targeted CVEs and replace EOL devices.
3. Remove default and service account credentials.
4. Enforce egress allowlists on edge devices.
5. Monitor systemd, cron, and configuration baselines.
6. Isolate threats during the loader or C2 phase before proxy or DDoS activities begin.

12. Facts, Inferences, and Hypotheses

Facts

• FortiGuard Labs observed active exploitation attempts from July 2026 onward targeting multiple devices that called back to the same loader URL.
• Evooo1Bot provides binaries for 12 CPU architectures and implements encrypted C2, shells, file transfers, SOCKS, SSH scanners, sniffers, DDoS, and CVE exploit features.
• The SSH scanner tests over 150 credential combinations and checks for honeypots before and after login.
• !persist attempts to configure systemd, SysV init, cron, shell profiles, and rc.local all at once.
• The DDoS engine includes 16 flood methods derived from Mirai.
• Some entries in the exploit table fail due to implementation errors.
• C2 telemetry showed activity in multiple regions, but the exact number of infected devices is not public.

Inferences

• The success of writing persistence paths depends on the permissions of the initial entry process and device limits like read-only filesystems.
• Reverse SOCKS only requires outbound communication, so closing inbound management ports cannot prevent post-compromise relaying.
• Because it has multiple modules, devices might be used only for proxy operations or credential collection even if no DDoS traffic occurs.

Hypotheses

• Correlating campaign labels with payload callbacks could help estimate success rates by vulnerability and prioritize patches.
• The short sequence of edge device events ("exploit received -> loader downloaded -> port 443 long-lived connection -> port 22 scan") may serve as a more durable detection method than relying on single IOCs.

13. MITRE ATT&CK Mapping

• T1190 Exploit Public-Facing Application — Confidence: High
• T1110.001 Password Guessing — Confidence: High
• T1105 Ingress Tool Transfer — Confidence: High
• T1059.004 Unix Shell — Confidence: High
• T1070.003 Clear Command History — Confidence: High
• T1497 Virtualization/Sandbox Evasion — Confidence: High
• T1573 Encrypted Channel — Confidence: High
• T1543.002 Systemd Service — Confidence: High
• T1053.003 Cron — Confidence: High
• T1546.004 Unix Shell Configuration Modification — Confidence: High
• T1090 Proxy — Confidence: High (direct/reverse SOCKS5)
• T1040 Network Sniffing — Confidence: High
• T1046 Network Service Discovery — Confidence: High
• T1498 Network Denial of Service — Confidence: High
• T1027 Obfuscated Files or Information — Confidence: High

14. Unknowns and Additional Research

• Confirmed infection counts, victim organizations, and operator attribution.
• Complete specifications of the C2 protocol and whether standard TLS is used.
• C2 commands for transferring sniffer data and confirming actual data theft.
• Success rates and build differences for each exploit entry.
• Running user and privileges after initial exploitation.
• Whether SOCKS relays are used for internal pivoting, selling residential proxies, or supporting other attacks.
• Architecture-specific hashes and infrastructure beyond the two public hashes.

15. Impact on SOCs and General Enterprises

Fortinet telemetry includes global regions, and targets include equipment related to operational technology (OT) environments, such as the Mitsubishi Electric ME-RTU. Security Operations Centers (SOCs) must monitor processes, configurations, and egress traffic on routers, firewalls, cameras, and OT gateways, not just servers and endpoints. It is important not to classify Mirai variants like Evooo1Bot simply as "DDoS bots," but also to investigate potential SOCKS relays, credential collection, and internal pivoting.

16. Summary by Target Audience

• For SOCs: Separate exploit contact from successful infections. Detect threats at the loader, ELF, C2, persistence, and SOCKS/scan/DDoS stages.
• For Administrators: Close public management interfaces, update firmware, remove default credentials, enforce edge egress controls, and replace EOL devices.
• For End Users: This attack requires no user interaction. If you notice strange device slowdowns or network disconnections, do not just reboot the device—contact your system administrator immediately.