It starts like most cryptojacking alerts do: an exposed Redis port, a suspicious process, maybe a spike in CPU usage. Easy to ignore. Easy to wipe. Until it isn't. Because some miners aren’t just smash-and-grab operations—they’re quiet occupations.

TA-NATALSTATUS is one of them. Over the past five years, this threat actor has built a sprawling, resilient infrastructure by exploiting the same forgotten misconfigurations everyone else does—but with far more discipline and long-term vision. Their malware doesn't just mine—it hides, persists, spreads, and fortifies. And the opportunity? It's massive. Across just a handful of countries:

• Over 17% of Redis servers in the United States remain exposed
• 33% in Germany
• 27% in the United Kingdom
• 23% in France
• 41% in Finland
• And 39% in Russia

Tens of thousands of servers worldwide are vulnerable—and TA-NATALSTATUS is actively targeting them all. With rootkit-style binary swaps, process cloaking, command obfuscation, immutable file locks, and anti-rival "kill lists," this group has transformed a commodity attack vector into a robust infrastructure takeover campaign. This is the complete dossier on TA-NATALSTATUS: how they operate, how they’ve evolved, and how to hunt, confirm, and eradicate them—before your server becomes just another asset in their growing empire.

The Hunting Ground: A Playground of Exposed Servers

TA-NATALSTATUS doesn't need sophisticated zero-day exploits when their global hunting ground is this target-rich. The root cause of their success is a systemic, worldwide failure to properly secure Redis instances. The data below illustrates the sheer scale of the opportunity available to them.

‍

‍

This data reveals a critical truth: high percentages of exposed servers are not confined to one region but are a global issue, driven by developer misconfigurations and insecure default settings. This landscape of tens of thousands of vulnerable servers is precisely what allows an automated, efficient campaign like that of TA-NATALSTATUS to flourish.

The Evolution of an Adversary: From 2020 to Today

Our investigation began when CloudSEK’s BeVigil detected an open Redis instance within one of our client’s infrastructure. This exposed instance had been compromised by a cryptominer, which triggered a deeper investigation. While this incident served as the starting point, open-source intelligence helped us uncover a broader context. The tactics, techniques, and procedures (TTPs) used by the threat actor—now identified as TA-NATALSTATUS—appear to be a direct evolution of a multiplatform worm originally reported by Trend Micro in 2020.

‍

What Hasn't Changed (The Core Playbook):

• Initial Access: Abusing publicly exposed, unauthenticated Redis servers.
• Execution Method: Using the Redis CONFIG SET and SAVE commands to write malicious cron jobs.
• Structure: A modular, multi-script infection chain (init/ndt.sh, is.sh, rs.sh).

‍

What Has Changed (The 2025 Upgrades):

This is what makes them dangerous today. They have learned from years of their malware being detected and have systematically upgraded their stealth.

• Process Hijacking: They now employ a rootkit-like technique to hide their processes. By renaming system binaries like ps and top to ps.original and replacing them with malicious wrappers, they filter their own malware (httpgd) out of the output. An admin looking for the miner won't see it using standard tools.
• Command Obfuscation: They rename curl and wget to cd1 and wd1. This is a simple but brilliant method to bypass security products that monitor for malicious downloads specifically initiated by these common tool names.
• Timestomping: As observed the actor uses touch commands or other methods to alter the timestamps of their files, making them appear to be old system files to deceive forensic analysis.

‍

The Full Attack Lifecycle: Anatomy of a Conquest

The operation of TA-NATALSTATUS is not a simple "infect and mine" scheme. Instead, it is a meticulously crafted, four-stage lifecycle designed for resilience, stealth, and full dominance over compromised systems.Before diving into the four-stage architecture, it’s essential to explore the initial access vector—a deceptively simple yet highly effective method that leverages misconfigurations rather than exploits.

‍

Initial Access: "Root by Inheritance" Technique

The malware does not escalate privileges. It is born with root access by exploiting a Redis server that has been insecurely started as the root user. This attack is based entirely on legitimate Redis commands, used maliciously.

‍

Exploitation Sequence

1. The Scan
   The attacker uses tools like masscan to scan the internet for publicly exposed, unauthenticated Redis servers on port 6379.
2. The Payload
   Once a vulnerable Redis server is found, the attacker sends a sequence of configuration commands. These are not exploits, but legitimate Redis operations used to manipulate the server.

‍

The Deception (The Core Trick)
The attacker performs the following sequence:

‍

• CONFIG SET dir /var/spool/cron/: Redirects the Redis database directory to the system's cron folder.
• CONFIG SET dbfilename root: Sets the filename of the Redis database to root. On Linux, this becomes /var/spool/cron/root, the root user's crontab.
• SET backup1: Injects a malicious cron job (running every 2 minutes) that downloads and executes the malware.
• SAVE: Forces Redis to write its current in-memory dataset (containing the cron job) to disk as /var/spool/cron/root.
  
  

3. Execution Trigger
   The system's cron daemon reads the new /var/spool/cron/root file and executes the inserted cron job as the root user. This initiates the download and execution of the malware script (ndt.sh) with full privileges.

‍

Why This Works

• Redis, when run as the root user, has permission to write directly to critical system directories.
• This makes it possible for the attacker to "inherit" root privileges without any traditional privilege escalation techniques.
• If Redis were running as a non-privileged user, this attack would fail at the file-write step, as that user would lack permissions to access /var/spool/cron/.

‍

With root access gained at the very beginning, the malware is free to proceed with the remaining four stages of its lifecycle—each carefully designed to maintain persistence, perform reconnaissance, establish remote control, and finally, execute its malicious goals (such as cryptojacking or lateral movement).Understanding this initial breach method is key to appreciating the actor's disciplined, pragmatic, and technically efficient approach.

‍

Stage 1: Implantation - The Silent Takeover (ndt.sh / nnt.sh)

This initial stage goes far beyond just launching a payload. It's a systematic dismantling of the host's defenses for long-term occupation.

• Systemic Sabotage: Before any payload is dropped, the script performs a series of "hostile sysadmin" actions, including disabling SELinux (setenforce 0), massively increasing the file descriptor limit (ulimit -n 65535), and tearing down host firewalls (iptables -F).
• Behavioral Evasion - The ps Hijack: The script renames the legitimate ps binary to ps.original and replaces it with a malicious wrapper that executes the original command but pipes the result through grep -v explicitly filtering out the names of its own miner (httpgd) and scanner (pnscan). The administrator's primary tool for process visibility is now actively lying to them.
• The "Lock-the-Door-Behind-You" Technique: After compromise, the actor adds an iptables rule to block all future external connections to the Redis port (6379), effectively closing the door they used to get in and preventing rivals from using the same vulnerability.
• The Turf War: The script executes its massive "kill list" (see Appendix), terminating dozens of processes associated with competing cryptojacking campaigns like Kinsing and DDG to ensure 100% of the host's CPU resources are dedicated to their miner.

‍

‍

Stage 2: Preparation - Forging the Weapons (is.sh)

A conquered host is only useful if it can be used to find new victims. The is.sh script is a dedicated "war-prepper" designed to arm the host. In a key resilience tactic, if tools like ‘masscan’ or ‘pnscan’ cannot be installed via the package manager, the script downloads their source code directly from the C2 server and compiles them from scratch on the victim machine.

‍

Stage 3: Propagation - Unleashing the Horde (rs.sh)

Once armed, the host is turned into a soldier for the botnet, using a sophisticated, multi-pronged scanning strategy. The most critical element is the use of ‘masscan --shard’. Each bot is assigned a random slice of the entire IPv4 address space to scan. This distributed model allows the botnet as a whole to cover the internet incredibly quickly without any single bot generating enough traffic to trigger network-level blocks.

‍

Stage 4: Persistence - The Unkillable Cockroach (nnt.sh & chattr)

The final stage ensures the actor's control is permanent. An hourly cron job calls an update script (nnt.sh) which acts as a "dead man's switch," reinstalling the entire malware suite if any part is removed. To finalize the lockdown, the script uses ‘chattr +i’ to make its core files and the SSH backdoor key immutable. This prevents the files from being deleted or modified, even by the root user, causing immense confusion for administrators attempting a cleanup.

How to Check If You Are Infected

If you suspect an infection, do not rely on ps or top alone. Perform these checks from the command line.

Check 1: Look for Hijacked Binaries
Run this command. If you see any output, you are likely compromised.

Check 2: Look for Malicious Cron Jobs
The actor hides their activity by redirecting output to /dev/null. Search all cron locations for this pattern.

Look for suspicious jobs, especially any that execute scripts like nnt.sh or ndt.sh.

‍

Check 3: Check for Immutable Files
The actor locks their files with chattr +i. Run lsattr on the common malware file paths. If you see an i attribute, it's a major red flag.

Check 4: Check for the SSH Backdoor
This is the most critical check. The actor gains permanent access with an SSH key. Check your authorized_keys file for their specific key comment, uc1.

How to Remove the Miner and Remediate 

Simply deleting the miner binary is not enough. You must dismantle the entire persistence mechanism.

⚠️ WARNING: The only 100% guaranteed safe method is to isolate the host, retrieve any necessary data, and re-image it from a known-good, trusted backup. If you cannot re-image, follow these steps at your own risk.

Step 1: Isolate the Host
Immediately remove the machine from the network by disabling its network interface or applying strict firewall rules.

Step 2: Disable the Persistence Mechanism (Unlock and Delete Cron Jobs)
Unlock the locked cron files before deleting the malicious entries.

Step 3: Kill the Malicious Processes
Since ps is hijacked, use the original binary.

Step 4: Remove the Malware and Backdoor
Unlock the immutable files before deleting them.

Step 5: Restore System Binaries
Restore ps, top, curl, and wget to their original state.

Step 6: Address the Root Cause
Finally, secure your Redis instance. Set a strong password and configure it to only listen on the local interface (bind 127.0.0.1). If you do not do this, you will be compromised again.

Primary Indicators of Compromise (TA-NATALSTATUS)

Actor Fingerprints (Unique Identifiers)
SSH Key Comment: uc1
Monero_Wallet: 84nw3MQdDJzRghGBEPWNAtLG8MA1ek1itN42Yup4dPK38wnWGY7zxSR28j2n4vyLspVPoDCFeijap2NTQJfegCTeANTrzot
Malware Directory Path: /ep9TS2/

Domains (Confirmed Malicious)

natalstatus.org

a.natalstatus.org

avspbx.com

Pyats.top

en2an.top

‍

IP Addresses (Confirmed Malicious C2 / Mining Pools)

103.79.77.16

185.19.33.145

194.110.247.97

45.89.52.41

79.137.195.151

80.211.206.105

dev.fugglesoft.me (Pool Domain)

‍

File hashes

‍

Fofa Query to identify more moning pools 

The Kill List - A View into the Cryptojacking Underworld

TA-NATALSTATUS runs an aggressive "scorched earth" policy against its rivals. This "kill list" provides a real-time snapshot of the other major players in the cryptojacking ecosystem and can be used to hunt for other infections.

Rival Malware Infrastructure (IP Addresses Targeted for Termination)

45.76.122.92

176.31.6.16

83.220.169.247

51.38.191.178

46.243.253.15

51.38.203.146

51.15.56.161

200.68.17.196

144.217.45.45

104.248.4.162

188.209.49.54

107.174.47.181

89.35.39.78

181.214.87.241

121.42.151.137

107.174.47.156

Rival Malware Families and Processes (Targeted for Termination)

‍

‍

References

• https://www.trendmicro.com/en_in/research/20/d/exposed-redis-instances-abused-for-remote-code-execution-cryptocurrency-mining.html
• https://help.aliyun.com/zh/acsg/best-practices-for-handling-mining-programs?spm=a2c4g.11186623.0.i4
• https://www.cnblogs.com/skystrive/p/18879419

‍