Perimeter

6/11/2015
04:40 PM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
100%
0%

Few Skills Needed to Build DDoS Infrastructure, Honeypot Project Shows

Novetta's analysis of the tactics used by attackers to exploit a flaw in Elasticsearch shows script kiddies can build DDoS attacks.

An analysis of the tactics, techniques and procedures used by attackers to exploit a vulnerability in the Elasticsearch enterprise search engine suggests that it takes very little skill these days to develop a large-scale infrastructure for launching distributed denial of service attacks.

That is the assessment of researchers at cyber analytics firm Novetta, based on data gathered from an open-source honeypot named Delilah that the company recently deployed to gain a better understanding of the threat actors exploiting the Elasticsearch flaw.

Most of the attackers exploiting the vulnerability aren’t highly skilled, says Greg Sinclair, director of malware research. Even so, “they have gone out and created a streamlined method for using this vulnerability to create an effective DDoS infrastructure,” he said.

Earlier this year, a security flaw was discovered in Elasticsearch’s Groovy scripting engine that allowed attackers to remotely execute malicious code on vulnerable Elasticearch servers. Following public disclosure of the flaw, researchers reported large-scale scanning and exploitation of the flaw, resulting in a large number of Elasticsearch servers being compromised, Novetta said in a report summarizing the results of its research.

Though the vulnerability was only discovered in February 2015, there are signs that it was being actively exploited by attackers at least since November 2014 and possibly even as early as July last year.

The flaw has been patched, but a large number of Elasticsearch servers remain unpatched and therefore vulnerable to attacks, Sinclair said.

Novetta’s investigation of the flaw via its honeypot project shows that two different malware families, dubbed Elknot and BillGates, are being installed on compromised Elasticsearch servers. Both are DDoS bots and have a shared lineage but vary greatly in sophistication, according to Sinclair.

Elknot appears to be a pretty basic DDoS bot that employs a rudimentary set of commands to generate denial-of-service attacks against specified targets. The BillGates family, on the other hand, features a more robust code base and has the ability to execute different malware programs in addition to functioning as a DDoS bot.

“It is essentially a backdoor into someone’s Elasticsearch server,” Sinclair says. “It is more persistent than Elknot and stays on the machine for longer,” using obfuscation tactics.

The command-and-control servers that are being used by attackers to communicate with compromised Elasticsearch servers contain several other malware families that can be installed just as easily on compromised systems as Elknot and BillGates. Many of the samples hosted on these servers are old exploits that can be used by attackers to move laterally across networks.

The fact that the threat actors exploiting the Elasticsearch flaw have not done that so far suggests that data theft is not a motive, Sinclair says.

“Moreover, the actors appear to have little more than 'script-kiddie' skill levels, as the tools being used by the actors are easily acquired and meant to be deployed practically off the shelf, requiring almost no customization for a victim’s machine, Novetta’s report noted. 

Even so, the large-scale scanning and continued targeting of vulnerable Elasticsearch servers shows just how easy it has become for anyone to build a DDoS attack infrastructure, it said.

A majority of the C&C servers used in the Elasticsearch exploitation campaign has addresses within the Chinese IP space. A majority of the DDoS targets were Chinese too, though Novetta observed a fair number of American companies being targeted as well. In total, during Novetta’s observation of honeypot activity, the company saw a total of 384 attack commands being directed at 95 unique IPs in China and 133 DDoS attack commands directed at 133 U.S. based IP addresses. The most commonly used attack commands were SYN Flood, UDP Flood and Ping Flood.

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
'Shift Left' & the Connected Car
Rohit Sethi, COO of Security Compass,  6/12/2018
Microsoft Fixes 11 Critical, 39 Important Vulns
Kelly Sheridan, Staff Editor, Dark Reading,  6/12/2018
Why CISOs Need a Security Reality Check
Joel Fulton, Chief Information Security Officer for Splunk,  6/13/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-12580
PUBLISHED: 2018-06-19
library/DBTech/Security/Action/Sessions.php in DragonByte vBSecurity 3.x through 3.3.0 for vBulletin 3 and vBulletin 4 allows self-XSS via $session['user_agent'] in the "Login Sessions" feature.
CVE-2018-12578
PUBLISHED: 2018-06-19
There is a heap-based buffer overflow in bmp_compress1_row in appliers.cpp in sam2p 0.49.4 that leads to a denial of service or possibly unspecified other impact.
CVE-2018-1061
PUBLISHED: 2018-06-19
python before versions 2.7.15, 3.4.9, 3.5.6 and 3.7.0 is vulnerable to catastrophic backtracking in the difflib.IS_LINE_JUNK method. An attacker could use this flaw to cause denial of service.
CVE-2018-1073
PUBLISHED: 2018-06-19
The web console login form in ovirt-engine before version 4.2.3 returned different errors for non-existent users and invalid passwords, allowing an attacker to discover the names of valid user accounts.
CVE-2018-12557
PUBLISHED: 2018-06-19
An issue was discovered in Zuul 3.x before 3.1.0. If nodes become offline during the build, the no_log attribute of a task is ignored. If the unreachable error occurred in a task used with a loop variable (e.g., with_items), the contents of the loop items would be printed in the console. This could ...