Archive for June 6th, 2019

GoldBrute Botnet Brute Forcing 1.5 Million RDP Servers, (Wed, Jun 5th)

RDP, the remote desktop protocol, made the news recently after Microsoft patched a critical remote code execution vulnerability (CVE-2019-0708). While the reporting around this “Bluekeep” vulnerability focused on patching vulnerable servers, exposing RDP to the Internet has never been a good idea. Botnets have been scanning for these servers and are using weak and reused passwords to gain access to them. The latest example of such a botnet is an ongoing malicious campaign we are refering to as “GoldBrute”. This botnet is currently brute forcing a list of about 1.5 million RDP servers exposed to the Internet. Shdoan lists about 2.4 million exposed servers  [1]. GoldBrute uses its own list and is extending it as it continues to scan and grow.

The GoldBrute botnet is controlled by a single command and control server (104[.]156[.]249[.]231). Bots are exchanging data with it via AES encrypted WebSocket connections to port 8333. 

An infected system will first be instructed to download the bot code. The download is very large (80 MBytes) and includes the complete Java Runtime. The bot itself is implemented in a Java class called “GoldBrute”.

Initially, the bot will start scanning random IP addresses to find more hosts with exposed RDP servers. These IPs are reported back to the C&C server. After the bot reported 80 new victims, the C&C server will assign a set of targets to brute force to the bot. Each bot will only try one particular username and password per target. This is possibly a strategy to fly under the radar of security tools as each authentication attempt comes from different addresses. 

Take a look at the diagram below and the following description to better understand the threat’s modus operands.

Once the attacker successfully brute-force an RDP target (1), it downloads a big zip archive containing the GoldBrute Java code and the Java runtime itself. After uncompressing, it then runs a jar file called “bitcoin.dll”. The “dll” extension is possible to disguise unsuspecting users, but I suspect the “bitcoin” part call more attention than a “.jar” extension would.

Next, the new bot will start to scan the internet for open RDP servers they call “brutable”’ (3) which are sent to the C2 server through WebSocket connection (4). Once the bot reaches 80 brutable RDP servers, it starts the brute-force phase.

In the brute-force phase, the bot will continually receive and brute-force “host + username + password” combinations (5 and 6).  

In the end, the attacker/group behind GoldBrute will have access to all valid combinations (7).

Inside GoldBrute code

In the following code snippet from “” file, we can see the hardcoded C2 address, some timeout parameters, and GoldBrute initialization. 


In the next, from “”, we have many additional parameters, including C2 traffic AES encryption parameters and a hardcoded initial IP range to brute.  

Most of those initial parameters may be changed by C2. The snippet from “” below shows how a “config” packet is identified and treated by the bot to update configurations like TEST_SERVER addresses.


The Numbers

Analyzing the GoldBrute code and understanding its parameters and thresholds, it was possible to manipulate the code to make it save all “host + username + password” combinations on our lab machine. 

After 6 hours, we received 2.1 million IP addresses from the C2 server from which 1,596,571 are unique. Of course, we didn’t execute the brute-force phase.

With the help of an ELK stack, it was easy to geolocate and plot all the addresses in a global world map, as shown below.


Files (SHA256)

af07d75d81c36d8e1ef2e1373b3a975b9791f0cca231b623de0b2acd869f264e (bitcoin.dll)


104[.]248[.]167[.]144 (Zip download)
104[.]156[.]249[.]231:8333 (C2 server)



Renato Marinho
Morphus Labs| LinkedIn|Twitter

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Time is (partially) on our side: the new Exim vulnerability, (Thu, Jun 6th)

Yesterday details about a new locally and remotely exploitable vulnerability in Exim (CVE-2019-10149) was published by Qualys.

The vulnerability is critical: it allows a local user to easily run commands as root due to an issue in the deliver message code – a local user apparently can just send an e-mail to the address ${run{…}@localhost (where localhost is one of Exim’s local domains) and get the command executed as root.

According to Qualys, it is possible to exploit the vulnerability remotely as well – but there is a caveat (which I really like): “To remotely exploit this vulnerability in the default configuration, an attacker must keep a connection to the vulnerable server open for 7 days (by transmitting one byte every few minutes).”

While the details about exploitation have been removed from the initial advisory, the full advisory should be published soon.
In other words – if you run Exim: PATCH. While it would appear that you have 7 days for remote attackers, the vulnerability actually existed since Exim version 4.87 which was released back in April, 2016. Additionally, a patch that fixes the vulnerability was released in February 2019, but it wasn’t marked as a security issue, so it wasn’t included in most OS updates.

If we see any exploitation attempts, we’ll update the diary – so far it looks quiet, so use that time to patch your systems!


(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →