GoBrut is malware written in Golang that is utilized to bruteforce servers running Content Management Systems (CMS) and technologies such as SSH and MySQL. Once infected, the host will join the GoBrut botnet and request work from the C2 (Command and Control) server. After work is received, the infected host will proceed to bruteforce the targets detailed in the work request sent by the botnet owner. This botnet has been associated with the Magecart group, another set of actors which we have been tracking and discussed on this blog about defending against Magecart.
ELF on the Shelf
At present, the majority of discussion in the public domain concerns GoBrut samples which target Windows systems. Whilst researching GoBrut, Alert Logic Research have discovered a new ELF variant of the family, which would be able to target Unix systems. As a significant portion of the internet runs open-source Linux technology stacks, this significantly increases the proportion of the internet at risk. This is backed up by our internal telemetry – in which we have observed attacks from ~11,000 compromised servers originating from approximately 1568 WordPress sites.
The ELF sample in question contacts similar C2 servers as the windows variants, but adds an additional persistence stop of a cronjob.
> 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.
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 – e.g. 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.
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 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. 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.
Who Is Your Server & What Does it Do?
Earlier in the blog, 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.
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 three 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