Evooo1Bot: The Defensive Playbook for the Mirai Botnet Turning Edge Devices Into Proxies

Evooo1Bot is another Mirai descendant, and the interesting question isn't what it does (routers, cameras, firewalls turned into DDoS bots and proxies, we've seen the shape before) but whether your edge is exposed and how you'd know. FortiGuard Labs' Yi Ping Lin documented it on August 13; it's been active since July 2026, it spreads through a stack of known device CVEs, and its standout feature is turning compromised edge hardware into persistent SOCKS5 relays for anonymizing attacker traffic and pivoting into internal networks. This is the defensive version of the writeup: the IOCs to hunt for, the exposure check to run, and how to make your edge devices a bad target, because the one thing every Evooo1Bot infection has in common is an internet-facing device running a patch that was available years ago.

Why This One Matters More Than a Plain DDoS Bot

Mirai variants are a dime a dozen, so be specific about what elevates this one. ⚠️ The SOCKS5 proxy module is the real story, and Fortinet calls it the most operationally significant capability. A traditional Mirai bot is a disposable DDoS cannon. Evooo1Bot turns an infected router or firewall into a persistent SOCKS5 relay, which means:

• The attacker routes traffic through your IP, so their malicious activity looks like it originates from your network, not theirs.
• It's a pivot point: an edge device sitting between the internet and your internal network becomes an attacker's doorway into that network.
• At scale, the operator monetizes the fleet as a residential/enterprise proxy service, which is why they want persistence, not just a quick DDoS burst.

That shift, from disposable bot to reusable infrastructure, is the modern edge-threat pattern. An infected edge device isn't just attacking others; it's a foothold on your perimeter and a laundering point for someone else's crime attributed to your IP.

Beyond the proxy, the toolkit is genuinely more capable than baseline Mirai: encrypted C2 on port 443, a 28-command remote interface, a credential sniffer that intercepts HTTP Basic-Auth and Cookie headers off the wire, an SSH brute-forcer with 150 enterprise-oriented credential pairs and honeypot-evasion checks, multi-vector DDoS, and multi-layer string obfuscation (AES-256-CTR and ChaCha20 with keys XOR-split across .data and reassembled at runtime). ⚠️ One honest calibration the hype omits: Fortinet notes some embedded exploits are non-functional as shipped, so the "arsenal" is less complete than the CVE count suggests. That's not reassurance, the working ones are plenty, but it's the accurate read.

Are You Exposed? The Two Questions

Exposure comes down to two things, and both are checkable.

1. Do you have any of the targeted devices reachable from the internet? Evooo1Bot's initial-access CVEs hit specific vendors. The propagation set:

Its secondary exploit dispatcher also targets Hikvision cameras (CVE-2021-36260), Atlassian Confluence (CVE-2022-26134), WSO2 (CVE-2022-29464), Zyxel (CVE-2022-30525), TP-Link Archer (CVE-2023-1389), PHP-CGI (CVE-2024-4577), D-Link NAS (CVE-2024-10914), and Kubernetes ingress-nginx (CVE-2025-1974).

⚠️ The Kubernetes and Confluence/WSO2/PHP-CGI targets are the ones relevant if you run servers, not just consumer routers. CVE-2024-4577 (PHP-CGI argument injection) in particular hits Windows PHP setups and some CGI configs, and ingress-nginx CVE-2025-1974 is a cluster-level RCE. If you run any of those internet-facing, you're in the secondary target set even without an old router.

⚠️ Nearly all the initial-access flaws are years old (one is from 2007). If you've patched your edge devices in the last few years, most of these can't touch you. The victims are unpatched, often end-of-life, consumer and SMB gear that nobody updates. The single best defense is knowing what you have exposed and whether it's current.

2. Is anything already talking to the C2? The infection is noisy if you know the IOCs.

Hunt for It: The IOCs

The loader and C2 are known. Check whether any host has touched them.

⚠️ The C2/loader IP is 91.92.40.118 and the loader script is wget.sh. On any Linux host or gateway you can inspect, check for connections and traces:

grep -rE '91\.92\.40\.118|wget\.sh' /var/log/ 2>/dev/null; ss -tnp | grep -E '91\.92\.40\.118'

⚠️ At the network edge, block and alert on that IP now (it may rotate, but block the known one):

sudo iptables -A OUTPUT -d 91.92.40.118 -j DROP; sudo iptables -A INPUT -s 91.92.40.118 -j DROP

On-host infection signs, since the malware has tells:

• ⚠️ Bash history cleared or truncated, the loader wipes ~/.bash_history to erase traces. An empty or suspiciously short history on a box that's been running a while is a flag:

for h in /root/.bash_history /home/*/.bash_history; do [ -f "$h" ] && printf '%s: %s lines\n' "$h" "$(wc -l < "$h")"; done

• Outbound port 443 to non-web destinations. The C2 uses 443 deliberately to blend with HTTPS. Look for persistent 443 connections to IPs that aren't legitimate services:

ss -tnp state established '( dport = :443 )' | grep -vE 'known-good-ranges'

• A process holding /dev/watchdog open and an adjusted OOM-killer score, Evooo1Bot keeps a watchdog device open and lowers its oom_score_adj to survive memory pressure:

grep -l . /proc/*/oom_score_adj 2>/dev/null | while read f; do p=$(dirname "$f"); score=$(cat "$f"); [ "$score" -lt -500 ] 2>/dev/null && echo "PID ${p#/proc/}: oom_score_adj=$score ($(cat $p/comm 2>/dev/null))"; done; lsof /dev/watchdog 2>/dev/null

• Unexpected SOCKS listeners or outbound relay sessions, the proxy module either listens directly or maintains a reverse relay. Unexplained listening sockets or persistent outbound sessions to one host are suspect:

ss -tlnp | grep -vE ':(22|80|443|53|25|3306|5432)\b'

• The evooo1 string, the family is named for a hardcoded string in every binary. If you've captured a suspect binary in a sandbox:

strings suspect_binary | grep -i 'evooo1'

Harden the Edge So You're Not a Target

The infection depends on reachable, unpatched, weakly-authenticated devices. Remove any one of those and you're out of scope.

1. ⚠️ Inventory what's actually internet-facing. You can't defend what you don't know is exposed. From outside your network, scan your own public ranges for management interfaces that shouldn't be reachable:

nmap -Pn -p 22,80,443,8080,8443,37215,52869 YOUR.PUBLIC.IP.RANGE/24

(Those high ports are common on the targeted Tenda/NETGEAR gear.) Anything answering that you didn't intend to expose is your first fix.

2. Patch or retire the targeted devices. Every initial-access CVE has a fix or the device is EOL and should be replaced. A router the vendor stopped updating is a permanent liability on your perimeter.
3. ⚠️ Get device management off the public internet. No router, camera, or firewall admin interface should be reachable from the internet. Put management behind a VPN or a bastion, the same principle as never exposing a database port. This single control neutralizes most of the CVE list regardless of patch status, since the exploit can't reach an interface it can't route to.
4. Change default credentials and kill password SSH. The credential sniffer hunts for unchanged defaults, and the SSH brute-forcer runs 150 common enterprise pairs. Key-only SSH with no password auth defeats the brute-force module entirely, the SSH hardening basics are the direct counter here.
5. Egress filtering. Edge devices and servers rarely need arbitrary outbound. Blocking unexpected outbound (especially to fresh IPs on 443) breaks C2 registration and the proxy relay, the same egress-control principle from the serverless metadata hardening applied to your perimeter.
6. For the server-side CVEs, patch ingress-nginx (CVE-2025-1974), Confluence, WSO2, and PHP-CGI if you run them exposed. These are the ones that hit real infrastructure, not just consumer routers, and they're the reason this botnet is relevant to a server operator and not just a home-router story.

If You Find It

⚠️ A compromised edge device is a compromised device, treat it as fully owned, not "clean the binary and move on." For a consumer router or camera, factory-reset, update firmware to current, change all credentials, and only then reconnect, and if it's EOL with no firmware fix, replace it. For a Linux host, this is the same burn-and-rebuild discipline as any server compromise: the credential sniffer means anything that authenticated through or near that device should be considered exposed and rotated, and the persistence and C2 access mean you can't fully trust the host, so rebuild over known-good. Preserve the binary and the C2 logs first if you want IOCs for the rest of your fleet.

Bottom Line

Evooo1Bot isn't novel in what it does, it's a capable Mirai variant, but its SOCKS5 persistence turns your edge device into someone's proxy and your perimeter into their pivot. The entire attack depends on internet-facing devices running years-old unpatched firmware with default or weak credentials, so the defense is unglamorous and effective: inventory what's exposed, get management interfaces off the public internet, patch or retire the targeted gear, kill password SSH and default creds, and block the known C2 (91.92.40.118). Hunt for the cleared bash history, the port-443 C2, the watchdog-holding process, and unexpected SOCKS listeners. The victims of this botnet are, without exception, devices someone forgot to patch or expose-check, don't be the forgotten device.

References

• The Hacker News: Evooo1Bot Linux Botnet Exploits Known Flaws to Turn Edge Devices Into SOCKS5 Proxies (source)
• FortiGuard Labs: Multi-Functional Linux Botnet Evooo1Bot (by Yi Ping Lin)
• BleepingComputer: New Evooo1Bot Linux Botnet Turns Routers Into Traffic Relay Nodes
• The Record: New Mirai Variant Adds Stealth Capabilities
• CISA: Known Exploited Vulnerabilities Catalog