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 "Console.java" file, we can see the hardcoded C2 address, some timeout parameters, and GoldBrute initialization. 

 

In the next, from "Config.java", 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 "ConfigPackage.java" 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.

IOCs

Files (SHA256)

af07d75d81c36d8e1ef2e1373b3a975b9791f0cca231b623de0b2acd869f264e (bitcoin.dll)

Network

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

References

[1] https://www.shodan.io/search?query=Remote+desktop

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter