> crontab -l

* * * * * /home/produbuntu/Downloads/[file_hash]   > /dev/null 2>&1

When executed from the command line the binary outputs its version – which for this sample was 1.5.

The Hunt

Utilizing our analysis of the new ELF sample, we reviewed our internal telemetry for any attacks against CMS sites which might have originated from the botnet. Using this, we can estimate when the full botnet (ELF or Windows) came online and infer the number of compromised sites as a factor of traffic volume.

The principle IOC (Indicator Of Compromise) for this effort was the hard-coded user-agent from the samples:

Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0

This generated the graph seen below, where we are tracking the unique count of source IP addresses.

Our telemetry observed 11,788 unique hosts and peak of 2666 hosts observed in a 24 hour period starting from January 24, 2019. The average bots in operation at one time started at around 500 and has recently (from March 19, 2019) shown a 5x increase to a peak of 2666.

This suggests that the botnet is becoming increasingly successful in its ability to infect and recruit victim hosts. It is important to state that user-agents are not necessarily the most reliable indicator, since they may be changed easily or across different forks. As a result, we expect these numbers to reflect the minimum size rather than the total scale of the botnet.

In order to create more certainty around these numbers, due to the use of the user-agent, we cross-referenced the traffic behavior against data from our existing threat intelligence channels – which provided us with commands known to be executed by the botnet controllers over time. Over the time period of testing the attacker was known to be attempting 2 entry vectors:

• Magento CMS brute force attacks. Specifically against:
• phpMyAdmin brute force attacks.
  • downloader//downloader/index.php
  • /rss/catalog/notifystock/

The increases in user-agent prevalence were consistent with increases in volume in these known attack behaviors.

To Err is Wordpress

Our threat intelligence sources were furthermore able to provide a detailed breakdown of the known C2 load at given intervals – i.e. how much the botnet was being used by attackers at any one time. What was interesting was that we observed an uptick in the amount of WordPress exploitation attempts which matched this pattern – despite us knowing that the botnet is explicitly asking for Magento and phpMyAdmin work. This could be explained by visibility on our end, perhaps another C2 is in play in some chain which issues different commands?

To investigate this route, we pivoted through our data to identify related samples which may provide another C2 location and confirmed our theory – there is another C2 location which is exclusively executing WordPress brute force attempts. Once thing which stood out from the attacking behavior of this C2 was that it used a login username which was literally ‘[login]’. Cross referencing this information with our internal data showed over 9,000 identified attempts using this login username over a two month period – broken down as in the image below.

Again, this traffic profile overlapped with known load on the botnet.

Of course, it would be highly unusual for a large number of hosts across the internet to be using a login username of ‘[login]’, indicating that this is most likely a placeholder variable which is not being filled in by the attacker automation. Another example of attacker coding bugs and errors being utilized for tracking and detection of their activities – similar to our recent announcement on the Lockergoga ransomware.

Why might an error such as this exist? What source might the attackers be using in order to populate this placeholder? It would need to be a dynamic and changing list, otherwise it would make more sense to import a static list (admin, administrator etc). This suggests that the bot owners may be performing enumeration of the target site to extract lists of potentially valid usernames. There are a number of ways in which attackers could be doing this – scraping posts from the sites in question perhaps. Or utilizing known information disclosure bugs such as CVE-2017-5487 via a wp-json/wp/v2/users request.

We can further correlate this WordPress attacking behavior to estimate the size of the botnet and it broadly matches with the data from the Magento command and control host.

Note that our data indicates that the campaign became live slightly earlier than as could be inferred in the public domain. The original blog on the topic references a sample windows executable (fdc3e15d2bc80b092f69f89329ff34b7b828be976e5cbe41e3c5720f7896c140) which was available on January 25, 2019 – whereas our first sample was observed in our data dates from one day earlier.

Who is your server and what does it do

Earlier in the article we stated that there were over 11,788 unique hosts which we can identify as participating in the botnet. From open source analysis of these hosts, they all generally follow the following pattern of deployed stacks (which again matches our intelligence on the stacks the attackers are expecting):

Targeted Content Management Systems

• Bitrix
• Drupal
• Joomla
• Magento
• WordPress
• OpenCart

Databases

• MySQL
• Postgres

Administration Tools

• SSH
• FTP
• cPanel
• PhpMyAdmin
• webhostmanagement

Using Shodan, we can get information about 8,308 of the 11,788 in greater detail.

The most compromised hosting organization was Digital Ocean, followed by AWS. Note that Google Cloud comes in at fourth place.

The top exposed ports across the hosts were 80,443, 22 and 21 – which is to be expected. The top 10 can be seen in the image below. Note that absent from this list (but a target service of the botnet) are:

• Port 3306 (MySQL) available on 1,867 hosts
• Port 5432 (Postgres) available on only 88 hosts

This implies that it is less likely that Postgres is being used directly as an exploitation vector to recruit these hosts into the botnet. Of course, the database might be being impacted by secondary persistence or exploitation via web server or administration tool compromises, rather than directly to their publicly exposed ports. 

If we enumerate the known vulnerabilities present across these hosts we can see that the top CVE is CVE-2018-15473. This vulnerability could be used to improve the success of SSH brute force activities, meaning that they only have to focus on password guesses (since they can expressly find out a valid username, rather than guessing them too). Note that we only see 3 hosts explicitly vulnerable to CVE-2017-5487 (mentioned earlier as the WordPress user enumeration vulnerability). Of course, we can only speculate that these vulnerabilities may be being used by the attackers in other as-yet-unprobed aspects of the total controlling infrastructure. 

Summary

The GoBrut botnet has exhibited multiple C2 servers and has been observed reaching 2666 unique hosts in a 24hr period and has compromised at least a total of ~11,000 hosts since 24/01/2019.  It appears like the botnet is growing with one of the most compromised technologies being Wordpress websites. If the most successful initial entry vector is assumed to be brute force attacks, then website and server owners should apply access control for remote logins across all services to mitigate the threat. This includes web / database / SSH / FTP services where possible. As is standard procedure, ensuring all services and plugins are fully up to date and patched is a necessity.

IOCS

ELF GoBrut Binaries

ba9486ab4f8921344ae151b581ed6be6fdaa7e3e719b104696b07c41c7a6390 - Version 1.5

2d5d4bc04686f2afa73b46786530df61d65f47255ba8dd5cbdd654043b3beac6 - Version 2.24

C2 Servers

http://5.45.69[.]149:7000 - Version 1.5

http://5.188.86[.]29:7000  - Version 2.24