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.

URI abuse by Hoaxcalls

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.

Use of /GponForm/diag_Form?images/ by Hoaxcalls

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.

Use of /GponForm/diag_Form?images/

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.

Use of /spywall/timeConfig.php by Hoaxcalls

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.

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 5th 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 7th, 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

Intezer Code Reuse of Hoaxcalls Payload

Attack vectors: UDP Flood, HEX Flood, DNS Flood

IRC: #hellroom

IOC — Domains:

IOC – 19ce033f.ngrok.io

sh457e7bf08f6169ee028622fb4e57c44eee7acb2ec31e5a923e18a2b0eb72afbd5
i6867668366d8d45d175086dd268a885532acf4f434a6ea619548e66aee61eeaff99
i586fe691185d2d2f0d78d470209422a33ae59c3f4291bd13c3bdf60abe18c6fa3e2
i486152186d3ae01164fcb54b4172a1efeda92d27515518d617e2030150c57a850d3
m68k414f1d316431c1d122470dbce1b9a68305a6e0a39277322f9ee1b8417bb9470b
ppc4400a94d8f24c02dcdcf25bbd65dd4ac09261f68ef0d9a8bf7a7dc19d82e1129aee
ppc2e58ec95033a9652ee9ebdaa05372ef0bfa1391eeadbdc6ec361627f9cae30de
ppc146a746b3115e412825f9b9550e155ccee3f9e57794986526e788db246a1a732
ppca7335e9f576e56fab8c8e33979f436314e4bfc60835a93aed02edba4ec95a600
spc76c4d9d2b94fe8a655dde41e042f80e67d23197c7a6a2c917c2a57e20d8b3dfd
spc5b75246cd4ade8145492bee419a7e226736f27f3573ff05f44ad3c15fe2f2a66
spcb092b20ddb099f75056c9e742e1748bb76758060ae2c7b550438a3ea35908f47
x86c923d2a61aff262b809ba32b5ca8fa22557aa9a9dc0236c3c926c4ea85c66d2b
x865868382e102d983b09febfa28a8c6feb4a36ef00154c86456a2c8104ca7c837d
x862e122fd7f35ca49742b6ad65916898ecdd745d1d7d1e64d45a19c654967e9941
mpslfa8fb368e297ce13db143547750bca6ed86bf62f55db61ff04596553853a87c1
mpslb6846183322f521cb5240e571cc8e9e4b398acde511bad37be93cb5c7fac3a06
mpslf2762aeefe77f51471ce383906e7a891b5290a0eb0ecc847743b87da6babacd5
mipsf41516f17ade8e51b880fa2606c4a3fb46b60647818af3f0cf1f1f9132022674
mips8977a7e1a11c32354c6f0fde12e14c9cd5bbc4807be2720c65a51689ec72491d
mips78b21930b0ea6a322021a0423f3ed8313e9f901ae728e7316c46e85ff81dc49c
arm5313c946e5c14a76cb5a4755fe229e2d38ffa9519d0cf352c7bbe38458fb697e2
arm5b5048031f27a72f90a62fd63215e9a9db05642b091e445888158994381502da9
arm5430108bc6966f3d61e32a10867569fed01e865a8e9ceeeefe023d26486887a2b
arm697934691fa7fb012f29cb49adf0d907b06e3c105835965673d93ad2aac814d66
arm666a7e2accf89ce024be8a844f50b1df6886d3f8d22a248719f5f1b33d21d188d
arm656b3dc6f0b8f258f5ee4238e269b507d35e04ce3b214c0866ef2b8db99bdb28f
arm7b9b18cf5b1ed1a0a9530479e072fdd2f79096266577081506f9107282ba73509
arm77842265e32aaca4b2ccd1aa65010a85ae6d2d2e4a2909abd0e7d45d9113c63c8
arm75e5c1b7a6240a234b643e2ae595f08ea407093ab14edac47c3b4e23cec8ae4da

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

i6867668366d8d45d175086dd268a885532acf4f434a6ea619548e66aee61eeaff99
i486152186d3ae01164fcb54b4172a1efeda92d27515518d617e2030150c57a850d3
mpslfa8fb368e297ce13db143547750bca6ed86bf62f55db61ff04596553853a87c1
mpslb6846183322f521cb5240e571cc8e9e4b398acde511bad37be93cb5c7fac3a06
mpslf2762aeefe77f51471ce383906e7a891b5290a0eb0ecc847743b87da6babacd5
mipsf41516f17ade8e51b880fa2606c4a3fb46b60647818af3f0cf1f1f9132022674
mips8977a7e1a11c32354c6f0fde12e14c9cd5bbc4807be2720c65a51689ec72491d
mips78b21930b0ea6a322021a0423f3ed8313e9f901ae728e7316c46e85ff81dc49c
arm7b9b18cf5b1ed1a0a9530479e072fdd2f79096266577081506f9107282ba73509
arm77842265e32aaca4b2ccd1aa65010a85ae6d2d2e4a2909abd0e7d45d9113c63c8
arm75e5c1b7a6240a234b643e2ae595f08ea407093ab14edac47c3b4e23cec8ae4da

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

arm79ed3d91d879ecb13ff1e650d1dba02c1c28e1b204a00e07eabe999d16cbf470e

Download Radware’s “Hackers Almanac” to learn more.

Download Now

Daniel Smith

Daniel is the Head of Research for Radware’s Threat Intelligence division. He helps produce actionable intelligence to protect against botnet-related threats by working behind the scenes to identify network and application-based vulnerabilities. Daniel brings over ten years of experience to the Radware Threat Intelligence division. Before joining, Daniel was a member of Radware’s Emergency Response Team (ERT-SOC), where he applied his unique expertise and intimate knowledge of threat actors’ tactics, techniques, and procedures to help develop signatures and mitigate attacks proactively for customers.

Contact Radware Sales

Our experts will answer your questions, assess your needs, and help you understand which products are best for your business.

Already a Customer?

We’re ready to help, whether you need support, additional services, or answers to your questions about our products and solutions.

Locations
Get Answers Now from KnowledgeBase
Get Free Online Product Training
Engage with Radware Technical Support
Join the Radware Customer Program

CyberPedia

An Online Encyclopedia Of Cyberattack and Cybersecurity Terms

CyberPedia
What is WAF?
What is DDoS?
Bot Detection
ARP Spoofing

Get Social

Connect with experts and join the conversation about Radware technologies.

Blog
Security Research Center