Evooo1Bot Linux Botnet: Mirai-Derived Malware Turns Edge Devices Into SOCKS5 Proxies — Detection and Remediation Guide

Security researchers have disclosed a previously undocumented Linux botnet family tracked as Evooo1Bot. The malware reuses the DDoS engine from the publicly leaked Mirai source code but extends the framework with additional capabilities — most notably, the ability to convert compromised internet-facing devices into SOCKS5 proxies. It propagates by exploiting known, previously patched vulnerabilities in edge devices, which means the attack surface is not exotic zero-days — it is the long tail of unpatched routers, DVRs, cameras, and embedded Linux appliances sitting on your perimeter.

This should concern every defender for two reasons. First, a device enrolled in a SOCKS5 proxy network becomes a laundering point for criminal traffic — credential stuffing, fraud, scanning, and follow-on intrusions can be routed through your IP space, creating legal, reputational, and blocklist exposure. Second, any device that can be conscripted as a proxy node can just as easily be repurposed as a pivot point into adjacent internal networks. Compromised edge infrastructure is not an island.

If your organization runs internet-facing Linux-based appliances — and almost every organization does, whether IT acknowledges them or not — you need external attack-surface visibility, egress monitoring, and a firmware lifecycle process today, not after the next campaign disclosure.

Technical Analysis

What Evooo1Bot Is

Evooo1Bot is a Linux-targeting botnet derived from the Mirai codebase that leaked in 2016. The Mirai lineage matters because it tells us a great deal about expected behavior even where the reporting is still emerging:

• DDoS engine reuse: The core attack module is inherited from Mirai's leaked source, meaning UDP/TCP floods and application-layer attack primitives are part of the toolkit.
• Known-vulnerability exploitation for propagation: Rather than relying solely on Mirai's classic Telnet/SSH default-credential brute forcing, Evooo1Bot weaponizes publicly known flaws in edge devices. The campaign targets devices that missed patch cycles — a vulnerability-management failure, not a zero-day problem.
• SOCKS5 proxy module: The differentiating capability. Infected devices are enrolled as proxy relays, monetizing the botnet through proxy resale and providing anonymization infrastructure for other threat actors.
• Cross-architecture payloads: Like all Mirai descendants, Evooo1Bot can be assumed to ship or fetch binaries for multiple embedded architectures (MIPS, ARM, x86, PPC), targeting the heterogeneous world of consumer and SMB edge hardware.

Affected Products and Platforms

The research flags internet-facing Linux-based edge devices — routers, network video recorders, IP cameras, and similar embedded appliances — as the target class. The specific exploited flaws are known vulnerabilities, i.e., previously disclosed bugs in device firmware for which vendor fixes exist but have not been applied. No CVE identifiers were published in the initial reporting; defenders should treat this as a patch-hygiene and exposure problem across the entire edge estate, not a single-CVE event.

Attack Chain (Defender's View)

Based on the Mirai-derived architecture and the reported capabilities, the intrusion lifecycle follows a well-understood pattern:

1. Internet scanning: The botnet scans for internet-exposed devices with known-vulnerable services or weak/default management credentials.
2. Exploitation: A known flaw in the device's web management interface or exposed service is exploited to achieve remote command execution, or default credentials are used against Telnet/SSH.
3. Payload staging: Post-exploitation, the device is instructed to download the bot binary — typically via wget, curl, or tftp — into a writable, often memory-backed location such as /tmp, /var/tmp, or /dev/shm. Mirai-family loaders frequently chain through busybox when standard utilities are absent.
4. Execution and entrenchment: The binary executes, connects outbound to command-and-control, and may attempt persistence via cron, /etc/rc.local, init scripts, or systemd units where the filesystem permits. Mirai descendants also routinely kill competing malware processes and close the very services (Telnet/SSH) they entered through to lock out rivals.
5. Monetization: The node begins operating as a SOCKS5 proxy listener, relaying arbitrary third-party TCP traffic, and remains available for DDoS tasking.

Exploitation Status

This is confirmed in-the-wild activity. Evooo1Bot is an operational botnet actively compromising devices, not a proof-of-concept. As of this writing there is no CISA KEV entry specific to this campaign and no CVEs were named in the disclosure; the exploited flaws are described as known vulnerabilities in edge-device firmware. The correct defensive posture is to assume any unpatched, internet-exposed embedded Linux device in your estate is a candidate target.

Detection & Response

The observable behaviors below are the high-fidelity signals for Mirai-family infections generally and proxy-capable descendants specifically. These are the detections worth running; they are tuned to behaviors that have almost no legitimate reason to occur on an edge device or embedded Linux host.

Sigma Rules

---
title: Mirai-Family Payload Staging via Download Utility on Linux
description: Detects download utilities fetching executable payloads into writable staging directories typical of Mirai-derived botnets such as Evooo1Bot. Edge devices and servers rarely legitimately download and immediately execute binaries from the internet into /tmp, /var/tmp, or /dev/shm.
references:
  - https://attack.mitre.org/techniques/T1105/
  - https://thehackernews.com/2026/08/evooo1bot-linux-botnet-exploits-known.html
author: Security Arsenal
status: experimental
date: 2026/08/15
id: 3c9f2a71-8b4d-4e6a-b1f2-9d7c5e0a3418
tags:
  - attack.command_and_control
  - attack.t1105
logsource:
  category: process_creation
  product: linux
detection:
  selection_downloader:
    Image|endswith:
      - '/wget'
      - '/curl'
      - '/tftp'
      - '/busybox'
  selection_staging:
    CommandLine|contains:
      - '/tmp/'
      - '/var/tmp/'
      - '/dev/shm/'
  selection_exec_chain:
    CommandLine|contains:
      - '; chmod'
      - 'chmod +x'
      - '&& chmod'
      - '; sh '
      - '| sh'
      - '| bash'
  condition: selection_downloader and (selection_staging or selection_exec_chain)
falsepositives:
  - Legitimate firmware update scripts on managed appliances
  - Configuration management tooling (Ansible pull, provisioning scripts)
level: high
---
title: Botnet Persistence and Rival-Killing Behavior on Linux
description: Detects command patterns associated with Mirai-family bots establishing persistence or killing competing processes, including writes to cron and init persistence locations and bulk process termination of download/scanning utilities.
references:
  - https://attack.mitre.org/techniques/T1053/003/
  - https://attack.mitre.org/techniques/T1037/
  - https://thehackernews.com/2026/08/evooo1bot-linux-botnet-exploits-known.html
author: Security Arsenal
status: experimental
date: 2026/08/15
id: 8e1d4b62-2f7a-4c59-a3e8-6b0f1d9c2457
tags:
  - attack.persistence
  - attack.t1053.003
  - attack.t1037.004
logsource:
  category: process_creation
  product: linux
detection:
  selection_persist_write:
    CommandLine|contains:
      - '/etc/crontab'
      - '/etc/cron.d/'
      - '/var/spool/cron/'
      - '/etc/rc.local'
      - '/etc/init.d/'
    CommandLine|contains:
      - 'echo '
      - 'printf '
      - 'tee '
      - '>>'
  selection_rival_kill:
    CommandLine|contains:
      - 'kill -9'
      - 'pkill'
      - 'killall'
    CommandLine|contains:
      - 'telnetd'
      - 'upnp'
      - 'mirai'
      - '/tmp/'
      - '/dev/shm/'
  condition: 1 of selection_persist_write* or 1 of selection_rival_kill*
falsepositives:
  - System administrators modifying cron or init configuration
  - Legitimate package post-install scripts writing init entries
level: medium

KQL — Microsoft Sentinel / Defender

Linux edge devices and servers forwarding syslog or CEF into Sentinel are huntable. This query looks for the two highest-value behavioral pairs: download-and-execute staging chains, and unexpected listeners or high-egress processes consistent with SOCKS5 proxy operation.

// Hunt 1: Mirai-family payload staging chains in Syslog process events
Syslog
| where TimeGenerated > ago(7d)
| where ProcessName in~ ("wget", "curl", "tftp", "busybox", "chmod", "sh")
| where SyslogMessage has_any ("/tmp/", "/var/tmp/", "/dev/shm/")
  and SyslogMessage has_any ("chmod", "wget", "curl", "tftp", "http://", "ftp://")
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), Count=count(), SampleCommands=make_set(SyslogMessage, 5)
  by Computer, ProcessName
| order by LastSeen desc;

// Hunt 2: DeviceNetworkEvents — unexpected listening or proxy-like egress from Linux hosts
// (requires Defender for Endpoint onboarding of Linux servers/appliances)
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where DeviceType =~ "Linux" or InitiatingProcessFolderPath has_any ("/tmp", "/var/tmp", "/dev/shm")
| where InitiatingProcessFolderPath has_any ("/tmp", "/var/tmp", "/dev/shm")
   or InitiatingProcessName in~ ("wget", "curl", "tftp", "busybox")
| summarize Connections=count(), RemoteIPs=make_set(RemoteIP, 20), Ports=make_set(RemotePort, 20)
  by DeviceName, InitiatingProcessName, InitiatingProcessFolderPath
| order by Connections desc;

Velociraptor VQL

On a suspected compromised Linux device, Velociraptor (via the Linux collector) can enumerate running processes and network state to surface bot processes and SOCKS5 listeners.

-- Identify suspicious processes running from staging paths and their network connections
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Exe =~ '^/(tmp|var/tmp|dev/shm)/'
   OR CommandLine =~ '(/tmp/|/dev/shm/|busybox|tftp|wget|curl)'
   OR Name =~ '(watchdog|upnp|telnetd)'

-- Correlate with active network connections to expose proxy listeners and C2 channels
SELECT Pid, Name, Family, Type, Status, LocalAddress, RemoteAddress
FROM netstat()
WHERE Status =~ 'LISTEN|ESTABLISHED'
  AND Name !~ '(sshd|systemd|snmpd|ntpd|cron|dnsmasq)'

Remediation and Triage Script

Run the following on a suspected Linux edge device (or fleet-wide via your orchestration tooling) to triage for Evooo1Bot-class infection and harden the device. On read-only embedded firmware, several steps will fail — that itself is a signal to replace or reflash the device.

#!/usr/bin/env bash
# Evooo1Bot / Mirai-family triage and hardening script for Linux edge devices
# Run as root. Review output before taking destructive actions.

echo "=== [1] Processes executing from staging paths ==="
ls -l /proc/*/exe 2>/dev/null | grep -E '/tmp|/var/tmp|/dev/shm' || echo "None found"

echo "=== [2] Unexpected listening sockets (possible SOCKS5 proxy) ==="
ss -tlnp 2>/dev/null || netstat -tlnp 2>/dev/null

echo "=== [3] High-volume outbound connections ==="
ss -tnp state established 2>/dev/null | head -50

echo "=== [4] Cron and init persistence review ==="
cat /etc/crontab 2>/dev/null; ls -la /etc/cron.d/ /var/spool/cron/ 2>/dev/null
grep -rE '/tmp|/dev/shm|wget|curl|tftp' /etc/rc.local /etc/init.d/ 2>/dev/null
systemctl list-unit-files --state=enabled 2>/dev/null | grep -viE 'ssh|cron|network|syslog|dbus|getty' || true

echo "=== [5] Suspicious files in staging directories ==="
find /tmp /var/tmp /dev/shm -type f -executable 2>/dev/null -exec ls -la {} \;

echo "=== [6] Hardening: disable Telnet, restrict management interfaces ==="
# Kill and mask telnet if present — a primary Mirai-family ingress vector
pkill telnetd 2>/dev/null
systemctl disable --now telnet 2>/dev/null; systemctl mask telnet 2>/dev/null
# Block inbound Telnet and common bot management ports at the host firewall
iptables -A INPUT -p tcp --dport 23 -j DROP 2>/dev/null
iptables -A INPUT -p tcp --dport 2323 -j DROP 2>/dev/null
# Restrict egress: devices like cameras/NVRs rarely need arbitrary outbound TCP
# Uncomment and adapt for your device role:
# iptables -A OUTPUT -p tcp -m state --state NEW -d 0.0.0.0/0 -j LOG --log-prefix "EGRESS-DENY "

echo "=== [7] Credential hygiene check: accounts with password auth ==="
awk -F: '($2 != "!" && $2 != "*" && $2 !~ /^!/) {print $1}' /etc/shadow 2>/dev/null

echo "=== Triage complete. If findings exist in steps 1-5, isolate the device, ==="
echo "=== capture volatile data, and reflash firmware from vendor media.       ==="

Remediation

There is no single patch for Evooo1Bot because there is no single vulnerability — the botnet rides on known, unpatched flaws in edge-device firmware. The remediation is programmatic:

1. Inventory and patch the edge estate. Enumerate every internet-facing router, NVR, camera, VPN appliance, and embedded Linux device. Apply the current vendor firmware on each. Where the vendor has ended support, the remediation is replacement — an unpatchable internet-facing device is a standing liability. Consult vendor security advisory portals and the CISA Known Exploited Vulnerabilities catalog for the specific flaws affecting your hardware models.
2. Remove management interfaces from the internet. Web admin panels, Telnet, and SSH on edge devices should be reachable only from a management VLAN or via VPN. This single change breaks the exploitation step for the entire Mirai family.
3. Rotate every credential on exposed devices. Default and vendor-shipped credentials are the classic Mirai ingress and remain a fallback for descendants. Enforce unique, strong credentials and disable password-based SSH where key auth is supported.
4. Constrain egress. Edge devices have a narrow set of legitimate outbound destinations (NTP, vendor update servers, cloud telemetry). Deny-all egress with explicit allowlists neutralizes both C2 channels and SOCKS5 proxy relaying — a proxy that cannot reach arbitrary internet destinations is worthless to the operator.
5. Segment. Place IoT/edge devices on isolated VLANs with no route to internal user or server segments. Even a fully compromised proxy node should have nowhere to pivot.
6. Monitor for the behaviors above. Deploy the Sigma rules to your Linux log pipeline, run the KQL hunts in Sentinel, and alert on unexpected listeners and egress spikes from device subnets.
7. Rebuild, don't clean. If a device is confirmed infected, do not attempt in-place malware removal on embedded firmware. Reflash from known-good vendor media or replace the unit, then change all credentials the device touched.

The broader lesson of Evooo1Bot is one this industry keeps relearning: botnet operators do not need zero-days. They need your unpatched, internet-exposed, default-credentialed edge devices. Attack-surface management and firmware lifecycle discipline are the controls that actually move the needle here.

Related Resources

Security Arsenal Red Team Services AlertMonitor Platform Book a SOC Assessment pen-testing Intel Hub