GoldBrute Botnet Brute Forcing 1.5 Million RDP Servers
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
Getting (proper) value out of security assessments
When purchasing (or performing) a security assessment, knowing exactly what you want (and what you provide) is very important. With a myriad of various engagements, it can be challenging in deciding on what is best for your organization.
That’s why I decide to write this diary as a small guide on how to decide which security assessment you want, and (what’s even more important) what you should expect to receive.
From technical point of view, I generally categorize security assessments into the following three categories: vulnerability scanning (assessments), penetration tests and red team exercises. Deciding what you want to perform/purchase should go in exactly that order, and depend on your organization’s security maturity level. Let’s see what each of these is about.
Vulnerability scanning (assessments) is something that we should be doing regularly. The goal of vulnerability scanning is to find low hanging fruit – vulnerability scanners will do a great job in enumerating installed patches, finding default accounts and misconfigurations. This is the first step in vulnerability management, and no matter how big (or small) your organization is, you should be doing this regularly.
While majority of organizations will perform vulnerability scanning on their own (with their own tools), sometimes I see clients that ask me to do this on their behalf and provide them with a shortened executive summary – one problem that vulnerability scanners might have is with false positives.
Penetration testing is the next step. When deciding on a penetration test, scoping is very important: the goal of a penetration test is to find all (well, as many as possible) vulnerabilities in the target scope. The target scope can be a set of IP addresses or networks (when we talk about a network penetration test), a web application, web services and so on.
Since a penetration tester is normally limited in time (typically penetration tests last between 5-15 work days), it’s obvious that the whole process should be as efficient as possible. This means that the scope should be define as good as possible, and that obstacles should be removed. For example, if you are testing a mobile application, it would be beneficial to provide a build without obfuscation for your penetration tester: we know what obfuscation can be circumvented and by providing such a build, the penetration tester will not waste time on deobfuscation, but on finding vulnerabilities.
Additionally, a penetration test will also test for vulnerabilities that a vulnerability scanner cannot find – one example of such vulnerabilities are logic vulnerabilities. As we still do not have AI capable vulnerability scanners (hey, I mentioned AI, now I just need to put in this diary machine learning and blockchain and we have everything covered :), logic vulnerabilities are always missed by automated scanner. Let me give you one easy example: you are using your Internet banking mobile application to perform a transaction of -100 EUR. Vulnerability scanners will normally miss such vulnerabilities since they lack understanding of the context.
The result of a penetration test is a report that should detail all identified vulnerabilities, with recommendations on how to fix them. All listed vulnerabilities should be verified by the penetration tester – there should be no false positives there!
As you can see, penetration tests require a lot of manual work – that’s why they last long(er) and are typically more expensive.
Finally, a red team exercise is the ultimate test of your defenses. In a red team exercise, the attacker(s) are given a final goal and they can typically use anything they want to achieve they goal. They might be writing new exploits, using social engineering, moving laterally …
You will see the main difference between a red team exercise and a penetration test: with a red team exercise there is one ultimate goal, while a penetration test aims to find all vulnerabilities in the defined scope. A red team exercise might miss some vulnerabilities and never report them, but it will show you how you stand against a real attacker. Quite often at the same time blue teams are tested – this will show how good you are in detecting attacks and potentially preventing them while they are happening.
To wrap this up – depending on what you have done to manage vulnerabilities in your organization and ramp up defenses, pick which offensive engagement suits you the most. If you have never performed a vulnerability scan, or you do not regularly test for vulnerabilities, it makes not sense to run a red team exercise – you are wasting money if a red team (or a penetration tester) comes in and obtains a domain administrator’s account in 30 minutes. So go step by step, and slowly improve your defenses.
Do you have your own war stories or want to share comments? Let us know!
--
Bojan
@bojanz
Comments