Ghosting Bots: The Story of Hoaxcalls Failures

Ghosting: A term used to describe the practice of ceasing all communication and contact with a partner, friend or bot.

The operators of the Hoaxcalls Botnet, also known as the XTC IRC Botnet, have been developing this new family of botnets since at least August 2019. While the threat actors have had a good run so far, developing many variants and leveraging numerous exploits, they have experienced some degree of failure. Chalk it up to trial and error.

Those who follow DDoS news and trends want to see breaking news about current and growing campaigns. Occasionally, if we’re lucky, we get a story about how the good guys took out an active campaign that has not matured into attacks, but only IF the story has appeal. What about the day-to-day wins over smaller operations? We also almost never hear about what happens to the remaining bots after a malware host or C2 is taken down.

Well, the Hoaxcalls campaign has provided researchers with a number of opportunities over the last several months to explore the trials and errors in researching, developing, and building a botnet campaign and the abandoned infrastructure that are left behind. Like derelict satellites that orbit the earth, these bots skim and crawl vulnerable internet devices without a real objective.

[You may also like: Who’s Viktor? Tracking down the XTC/Polaris Botnets]

Testing Exploits

While most amateur bot herders will stick with the basics of brute forcing over SSH and Telnet, some will branch out and incorporate exploits into their botnets so they can capture additional devices. But this doesn’t guarantee them uncontested devices for the taking.

Bot herders also have to compete with each other for their share of vulnerable resources. If there are only 400 vulnerable devices for a given exploit, it's first come, first serve. Those that leverage recent or undisclosed exploits stand a better chance of infecting more devices than those that do not.

Back in February, the group behind the Hoaxcalls campaign began to escalate their efforts in an attempt to capture more devices. Their efforts, to date, have resulted in the use of 12 different exploits since March 2020, for the purpose of propagating their malware and infecting more devices. But this process is a bit like trial and error, and while the number seems impressive, not every attempt was a successful or fruitful one.

[You may also like: Botnets: DDoS and Beyond]

The game of testing exploits for the purpose of propagating botnets is a fast pace, full contact sport. Those that cannot develop or discover their own exploits must rely on public disclosures. Once a Proof-of-Concept (PoC) is posted, the race is on to become the first to actively leverage the exploit. Some will not be able to figure out how to properly leverage the exploit, while those who do might discover the attempt was not worth their time in the first place.

With Hoaxcalls, we can see through graphs what exploits were deemed worthy of the operator’s time and what exploits didn’t pan out. When considering the graph that puts the count of different exploit URI’s over time from the campaign, one can see that Hoaxcalls has favored 4 specific exploits over the last 90 days: 

Two of the more common exploits are targeting Grandstream UCM6200 and Draytek Vigor devices via CVE-2020-8515 and CVE-2020-5722 and were covered by Radware and Palo Alto’s Unit 42. The operators have also seemed to be favoring the Netlink GPON Router 1.0.11 RCE and the Symantec Web Gateway 5.0.2.8 Post-auth RCE, both of which do not have CVE’s.

When looking at the same visualization we also see what exploits did not work out for the campaign. Exploits do not guarantee additional devices. They can fail for one reason of another. Some of these reasons include the threat actor’s inability to properly leverage an exploit, a limited number of devices to target or oversaturation due to competition.

For example, the /GponForm/diag_Form?images/, CVE-2018-10562 & CVE-2018-10561, GPON Routers – Auth bypass / Command Injection exploit was only seen used a handful of times over the last 90 days by the Hoaxcalls operators.

The group likely abandoned this exploit for propagation because of its popularity with other, competing bot herders. The CVE’s for the GPON Authentication bypass and command injection were posted back in May 2018. Because this exploit is widely known, it is over-saturated with botherders looking to capture or hijack what remains of devices are left on the internet. Below is a graph that represents the total number of attempts at leveraging this exploit by operators other than those behind the Hoaxcalls campaign.

We can also see other mild failures for the Hoaxcalls operators. The Symantec Web Gateway 5.0.2.8 Post-auth RCE, for example. The group first started using this exploit towards the end of April as seen in the graph below, but it has tapered off over the last two weeks.

This drop is not related to over-saturation of botherders as seen with CVE-2018-10562 & CVE-2018-10561. In fact, from my perspective, Hoaxcalls is really the only campaign attempting to use this exploit. As noted in Palo Alto’s latest blog from Unit 42, this vulnerability likely saw limited success by the operators due to the post-authentication nature of the Symantec Secure Web Gateway RCE.

Ghosting

Overall, the greater Hoaxcalls/XTC campaign has been underway since August 2019. Along the way, there has been a large amount of infrastructure used and abused by the operators. One of the subjects I feel most reports miss, is what happens to the bots after the take-down. In the case of the Hoaxcalls botnet, the operators have lost several servers to take-down requests, giving us plenty of examples to examine.

[adbutler zone_id="276005"]

So, what happens to the bots after their C2 infrastructure or malware host is taken down? Typically, when the malware host is taken down, the scanners have nothing left to load once they have discovered and compromised a vulnerable device. In the event the C2 infrastructure is taken down, the bots will have nothing left to communicate with. This holds true for most of the activity observed, with the exception of a few, more advanced, bot herders. In general, once a take-down occurs, the bots are lost, the infrastructure is abandoned and a new one is rebuilt from scratch.

For example, consider the case of the Hoaxcalls malware host 19ce033f.ngrok.io. This server was first seen on April 5^th in a Hoaxcalls payload. Over the next several days, researchers around the world would discover this activity and file abuse reports, subsequently resulting in the take-down of the malicious subdomain from ‘Ngrok.io’. However, after the take-down, the infected devices continued to scan the internet for more devices to compromise. On April 7^th, there were 183 IP addresses attempting to distribute Hoaxcalls payloads.  At the time of this writing, a total on 340 IP’s have been observed attempting to propagate Hoaxcalls payloads.

The take-down of this specific malware host essentially resulted in the ‘ghosting’ of the infected devices attempting to scan and propagate the Hoaxcalls payloads. Taking down the malware host resulted in the operators abandoning their current infrastructure and resuming on another server with IP 178.32.148.5, but it did not stop the currently infected devices from attempting to spread the malware samples.

Over a month after the take-down, the number of devices scanning has subsided, likely due to customer reboot or devices being re-owned by newer, smarter bots.

Connecting Dots

Hashes for binary samples hosted at 19ce033f.ngrok.io were also found hosted at 178.32.148.5. The hash for the first arm7 sample hosted at 178.32.148.5 was actually identical to the last sample hosted at irc.hoaxcalls.pw.

Abuse of Ngrok

One of the things that stood out about this part of the Hoaxcalls campaign is the use of Ngrok.com. Ngrok is a service that provides users with real-time web UI’s where they can inspect all HTTP traffic running through their tunnels. This allowed the operators to experiment a bit with loading by installing software on their server that connected to the ngrok cloud service. Requests to 19ce033f.ngrok.io for binaries from compromised devices or researchers could have been inspected by the operators.

You will find a number of results If you search URLhaus for IOC’s related to Ngrok.io.

[You may also like: Top 10 Web Service Exploits in 2019]

Resources & IOCs

Attack vectors: UDP Flood, HEX Flood, DNS Flood

IRC: #hellroom

IOC - Domains:

• 19ce033f.ngrok.io
• 178.32.148.5
• Irc.hoaxcalls.io

IOC - 19ce033f.ngrok.io

IOC – Matching SHA256’s from 19ce033f.ngrok.io @ 178.32.148.5

IOC – Matching SHA256 from 178.32.148.5/arm7 @ irc.hoaxcalls.pw/arm7