Back to Intelligence

Evooo1Bot Linux Botnet: Detecting and Remediating Mirai-Variant SOCKS5 Relay Infections on Routers and IoT Devices

SA
Security Arsenal Team
August 15, 2026
11 min read

Introduction

A new modular Linux botnet dubbed Evooo1Bot — built on leaked Mirai source code — is actively compromising internet-facing gateway devices, routers, and embedded Linux systems, and converting them into SOCKS5 traffic relay nodes. Rather than using infected devices purely for DDoS floods like classic Mirai, this operation monetizes compromised edge hardware by selling or renting proxy capacity — meaning your routers may be laundering someone else's attack traffic, obscuring C2 infrastructure, and consuming bandwidth right now.

This matters for three reasons. First, edge devices (routers, VPN gateways, IP cameras, NAS appliances) sit at the network perimeter with no EDR coverage — they are effectively invisible to most SOC telemetry pipelines. Second, SOCKS5 relay abuse means your IP space can end up associated with fraud, scanning, or attack traffic, creating reputational and blocklist consequences. Third, the Mirai lineage means the infection vector is almost certainly a combination of default/credential brute-forcing and known IoT exploit kits — attacks that are entirely preventable with basic hygiene.

Every organization with internet-facing Linux or embedded devices should treat this as an active-threat remediation exercise, not a future consideration.

Technical Analysis

Threat Overview

AttributeDetail
Malware familyEvooo1Bot (Mirai-derived)
ArchitectureModular, multi-stage Linux botnet
Primary targetsInternet-facing routers, gateways, IoT/embedded Linux devices
End stateDevice enrolled as SOCKS5 traffic relay node
LineageMirai source code base — brute-force/Telnet-style propagation plus exploit modules
Detection difficultyHigh — edge devices typically lack endpoint agents and logging

How the Attack Works (Defender's Perspective)

Based on the Mirai lineage and reported behavior, the Evooo1Bot infection chain follows a well-understood pattern:

  1. Discovery & Access — Internet-wide scanning identifies exposed devices with weak/default credentials (Telnet/SSH) or devices vulnerable to known router exploits. Mirai variants ship credential wordlists and exploit modules targeting consumer and SOHO gateway hardware.

  2. Payload Delivery — Once access is gained, the attacker drops a downloader/stager, typically via wget/curl/tftp to a writable, non-persistent path such as /tmp, /var/run, or /dev/shm. Architecture-specific binaries (MIPS, ARM, x86) are fetched for the target platform.

  3. Execution & Evasion — The payload executes, frequently deletes itself from disk (unlink) to live memory-resident, and may masquerade under benign-looking process names. Mirai-variants historically kill competing malware and harden the device against re-infection by closing Telnet/SSH or changing banners — an ironic but useful forensic artifact.

  4. Persistence (where possible) — On devices with writable filesystems, persistence is established via init scripts, cron, or rc.local modification. On read-only firmware devices, the bot simply survives in memory until reboot and relies on reinfection.

  5. SOCKS5 Relay Enrollment — The modular payload instantiates a SOCKS5 proxy listener, binds to a high/irregular port, and registers the node with the operator's C2. Inbound proxy traffic from arbitrary external IPs is then relayed through the device — this is the single most detectable behavioral signal.

Exploitation Status

  • Active in the wild: Confirmed. This is an operational botnet with observed infections, not a proof of concept.
  • CVE identifier: None disclosed in the reporting. Evooo1Bot follows the Mirai model — propagation via credential brute force and a rotating set of known IoT/router exploits — so defenders should focus on behavioral detection rather than a single CVE.
  • CISA KEV: No Evooo1Bot-specific entry at time of writing; treat as an active campaign requiring immediate edge-device review.

Why This Evades Traditional Controls

  • No EDR agents on routers/IoT firmware.
  • Memory-resident execution leaves minimal disk artifacts.
  • Proxy traffic looks like ordinary TCP sessions unless you baseline expected flows per device.
  • Many SOHO/edge devices ship with no syslog forwarding enabled by default — telemetry simply isn't being collected.

Detection & Response

The detection strategy for Evooo1Bot rests on three pillars: (1) payload staging behavior (downloaders writing to volatile paths), (2) anomalous listening sockets (unexpected SOCKS-style listeners on edge devices), and (3) network flow anomalies (gateway devices sourcing/relaying traffic they never should). Enable syslog forwarding on every edge device you manage today — without it, none of the KQL content below has data to work with.

Sigma Rules

YAML
---
title: Linux Shell Downloader Writing to Volatile Path
description: Detects wget/curl/tftp executions fetching payloads into /tmp, /dev/shm, or /var/run followed by execution — a classic Mirai-variant staging pattern seen in Evooo1Bot infections of embedded Linux and router devices.
author: Security Arsenal
date: 2026/04/06
status: experimental
references:
  - https://www.bleepingcomputer.com/news/security/new-evooo1bot-linux-botnet-turns-routers-into-traffic-relay-nodes/
  - https://attack.mitre.org/techniques/T1105/
logsource:
  product: linux
  category: process_creation
detection:
  selection_downloader:
    Image|endswith:
      - '/wget'
      - '/curl'
      - '/tftp'
  selection_paths:
    CommandLine|contains:
      - '/tmp/'
      - '/dev/shm/'
      - '/var/run/'
  condition: selection_downloader and selection_paths
falsepositives:
  - Legitimate package or firmware updates initiated by administrators
  - Configuration management tooling (verify source host and schedule)
level: high
---
title: Linux Payload Self-Deletion After Execution
description: Detects chmod followed by execution and rm/unlink of the same file in /tmp or /dev/shm — memory-resident Mirai-variant behavior where the binary removes itself from disk to evade forensics.
author: Security Arsenal
date: 2026/04/06
status: experimental
references:
  - https://www.bleepingcomputer.com/news/security/new-evooo1bot-linux-botnet-turns-routers-into-traffic-relay-nodes/
  - https://attack.mitre.org/techniques/T1070/004/
logsource:
  product: linux
  category: process_creation
detection:
  selection:
    Image|endswith:
      - '/rm'
      - '/unlink'
    CommandLine|contains:
      - '/tmp/'
      - '/dev/shm/'
  filter_package_managers:
    ParentImage|endswith:
      - '/apt'
      - '/apt-get'
      - '/dpkg'
      - '/yum'
      - '/dnf'
      - '/opkg'
  condition: selection and not filter_package_managers
falsepositives:
  - Application installers that clean temporary files
  - Build/CI jobs running on Linux servers (tune per host class)
level: medium
---
title: Telnet or SSH Brute Force Followed by Command Execution on Edge Device
description: Detects high-volume authentication failures against Telnet/SSH followed by a successful login and immediate shell command execution — the credential-brute-force access vector used by Mirai-lineage botnets including Evooo1Bot.
author: Security Arsenal
date: 2026/04/06
status: experimental
references:
  - https://www.bleepingcomputer.com/news/security/new-evooo1bot-linux-botnet-turns-routers-into-traffic-relay-nodes/
  - https://attack.mitre.org/techniques/T1110/
logsource:
  product: linux
  service: sshd
detection:
  selection_success:
    - 'Accepted password'
    - 'Accepted keyboard-interactive'
  condition: selection_success
falsepositives:
  - Legitimate administrative logins — correlation rule should require prior failure burst from same source IP within 10 minutes
level: medium

KQL — Microsoft Sentinel Hunt Queries

These queries assume you are forwarding edge-device syslog (via CEF or native Syslog connector) into Sentinel — if you are not, that gap is your first remediation item. The first query hunts Mirai-style staging commands in syslog process output; the second hunts anomalous relay behavior in network telemetry.

KQL — Microsoft Sentinel / Defender
// Hunt 1: Mirai-variant staging commands in forwarded syslog from Linux/edge devices
let stagingPaths = dynamic(["/tmp/", "/dev/shm/", "/var/run/"]);
let downloaders = dynamic(["wget", "curl", "tftp", "busybox"]);
Syslog
| where TimeGenerated > ago(7d)
| where ProcessName in~ (downloaders) or SyslogMessage has_any (downloaders)
| where SyslogMessage has_any (stagingPaths)
| where SyslogMessage has_any ("http://", "https://", "ftp://", ".sh", ".mips", ".arm", ".x86")
| project TimeGenerated, Computer, HostIP, ProcessName, SyslogMessage
| order by TimeGenerated desc;

// Hunt 2: Edge/gateway devices with unexpected outbound connection volume (potential SOCKS5 relay activity)
// Requires network telemetry — CommonSecurityLog (firewall/NSG) or DeviceNetworkEvents for managed Linux endpoints
CommonSecurityLog
| where TimeGenerated > ago(24h)
| where DeviceVendor has_any ("Fortinet", "Palo Alto Networks", "Cisco", "SonicWall", "Check Point")
| summarize DistinctDestinations = dcount(DestinationIP), TotalConnections = count(), DestPorts = make_set(DestinationPort)
    by SourceIP, SourceHostName
| where DistinctDestinations > 200
| order by DistinctDestinations desc;

// Hunt 3: New listening services on managed Linux endpoints (Defender for Endpoint onboarded devices)
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where ActionType == "ListeningConnectionCreated"
| where LocalPort > 1024
| where InitiatingProcessFileName !in~ ("sshd", "nginx", "apache2", "systemd", "dockerd", "containerd")
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), Listeners = make_set(LocalPort)
    by DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine
| order by FirstSeen desc;

Velociraptor VQL — Edge/Server Hunt Artifact

Deploy this hunt against Linux servers and any embedded devices where you can run the Velociraptor client or collect via offline acquisition. It combines process listing with socket enumeration to catch relay nodes even when the binary has self-deleted from disk.

VQL — Velociraptor
-- Evooo1Bot / Mirai-variant hunt: deleted-binary processes with unexpected listening sockets
SELECT Pid,
       Name,
       Exe,
       CommandLine,
       Username,
       netstat().LocalAddress AS ListenAddr,
       netstat().LocalPort AS ListenPort,
       netstat().Status AS SockStatus
FROM pslist()
WHERE (
        -- Deleted or unlinked executable (memory-resident payload)
        Exe =~ '\\(deleted\\)'
        -- Executing from volatile staging paths
        OR Exe =~ '^/(tmp|dev/shm|var/run)/'
        -- Masquerading names with no matching on-disk path
        OR Name =~ '^(kworker|kthread|systemd-|udevd)' AND NOT Exe =~ '^/(sbin|usr/sbin|lib/systemd)/'
      )
   OR (
        -- Any non-standard process holding a high-port listener
        netstat().LocalPort > 1024
        AND netstat().Status =~ 'LISTEN'
        AND NOT Name =~ '^(sshd|nginx|apache2|httpd|dockerd|containerd|node|java|postgres|mysqld)$'
      )

Remediation & Hardening Script (Bash)

Run this audit script on Linux-based edge devices, gateways, and IoT appliances with shell access. It performs read-only checks for Evooo1Bot indicators, then applies hardening. Review output before taking remediation actions on production devices.

Bash / Shell
#!/bin/bash
# evooo1bot_audit.sh — Security Arsenal edge-device audit & hardening
# Usage: sudo bash evooo1bot_audit.sh [--harden]

echo "=== [1/6] Processes executing from volatile paths or deleted binaries ==="
ls -l /proc/*/exe 2>/dev/null | grep -E '(deleted)|/tmp/|/dev/shm/|/var/run/' || echo "None found"

echo "=== [2/6] Files in classic Mirai staging locations ==="
find /tmp /var/tmp /dev/shm /var/run -type f -executable 2>/dev/null | head -50

echo "=== [3/6] Unexpected listening sockets ==="
ss -tlnp 2>/dev/null | awk 'NR>1 {print $4, $6}' | grep -vE ':(22|53|80|443|161|500|4500)\b' || echo "None found"

echo "=== [4/6] Persistence artifacts ==="
crontab -l 2>/dev/null; ls -la /etc/cron.d/ /etc/init.d/ 2>/dev/null | grep -vE 'total|^d'; grep -rE 'wget|curl|/tmp/|/dev/shm' /etc/rc.local /etc/init.d/ 2>/dev/null || echo "No suspicious entries"

echo "=== [5/6] Telnet exposure check ==="
(ss -tln | grep ':23 ') && echo "!! TELNET LISTENING — disable immediately" || echo "Telnet not listening"

echo "=== [6/6] Default/weak credential hygiene ==="
grep -E '^(admin|root|user|support):' /etc/passwd /etc/shadow 2>/dev/null | grep -vE ':\*|:\!' | head -10

if [ "$1" = "--harden" ]; then
  echo "=== Applying hardening ==="
  # Disable telnet if present
  systemctl disable --now telnet 2>/dev/null; killall telnetd 2>/dev/null
  # Block outbound from device to common botnet staging ports (adjust to your mgmt needs)
  iptables -A OUTPUT -p tcp --dport 23 -j DROP 2>/dev/null
  # Restrict SSH to management subnet — EDIT before use
  # iptables -A INPUT -p tcp --dport 22 ! -s 10.0.0.0/8 -j DROP
  echo "Hardening applied. Reboot device to clear memory-resident payloads, then re-run audit."
fi

echo "=== Audit complete. Reboot the device to evict memory-resident bots; if compromise is confirmed, factory-reset and reflash firmware. ==="

Remediation

There is no single patch for Evooo1Bot — remediation is about removing the access vectors Mirai-lineage malware depends on and evicting any resident infection.

Immediate actions (today):

  1. Reboot all internet-facing routers and gateway devices. Mirai-variant payloads are largely memory-resident; a reboot evicts the bot. This is triage, not a cure — the device will be reinfected within hours if the access vector remains.
  2. Disable remote management interfaces (Telnet, SSH, web admin) on the WAN side of every router/gateway. Management should be reachable only from a dedicated management VLAN or via VPN.
  3. Rotate all device credentials. Replace every default or vendor-shipped password with unique, strong credentials. Audit for accounts you don't recognize.
  4. Kill Telnet entirely. There is no defensible reason for Telnet to be listening on any device in 2026.

Short-term (this week):

  1. Patch device firmware. Apply the latest vendor firmware for all router/gateway models. Where vendors have ended support (EOL devices), replace the hardware — EOL edge devices are the primary fuel for botnets like this.
  2. Egress filtering. Edge devices have a tiny set of legitimate outbound destinations (NTP, firmware update servers, your management plane). Block everything else at the perimeter firewall — a compromised router that can't reach arbitrary internet IPs is a crippled relay node.
  3. Enable syslog forwarding from all edge devices into your SIEM/Sentinel. Without telemetry, detection content above is useless.

Structural (this quarter):

  1. Segment IoT/edge devices into restricted VLANs with no lateral access to internal server or workstation segments.
  2. Egress reputation monitoring. Alert when your public IP space appears on blocklists or when edge devices source anomalous connection volumes (see KQL Hunt 2).
  3. Inventory and lifecycle program. You cannot defend routers you don't know you own. Maintain an authoritative inventory of internet-facing devices with firmware versions and support status.

If compromise is confirmed on a device: factory reset → reflash current firmware → reconfigure from scratch (do not restore potentially poisoned config backups) → rotate all credentials that transited that device → review firewall logs for the period of suspected infection to identify what traffic was relayed.

Category

soc-mdr

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.