Who’s Viktor? Tracking down the XTC/Polaris Botnets.
In April, both Radware and Palo Alto Networks published reports about a new botnet family called ‘Hoaxcalls’. Both reports detailed the development of a new, fast-moving and relatively noisy campaign. While IoT botnet variants are very common since the publication of the Mirai source code, the samples covered by both reports highlighted not only the speed at which criminals can move during their research and development stage, but also the depth and breadth of their campaign.
The most newsworthy feature from both Hoaxcalls reports were the operator’s ability to find and leverage new vulnerabilities for the purpose of propagation. Palo Alto’s report revealed the operators’ use of CVE-2020-8518 and CVE-2020-5722, while Radware’s report detailed the addition of an unpatched vulnerability impacting ZyXEL Cloud CNM SecuManager for the purpose of propagation.
Both reports demonstrate the operators’ ability to leverage new vulnerabilities for the purpose of building and expanding the size of their botnets. Such skills, however, are not acquired overnight. Even though Hoaxcalls reuses code from botnets such as Tsunami, Gafgyt and Mirai, the tactics and methods leveraged by the operators warrants a review.
[You may also like: Cyber Security Trends in Times of Crisis]
Let me be clear. I don’t have the ability to answer all questions but I can connect a few dots with a high level of confidence. For example: the earliest known date of development is August 13th, 2019, per a submission to URLhaus by Security Researcher, @0xrb. While this is not complete attribution, it does move the starting point of the development of the XTC IRC Botnet, aka Hoaxcalls, back from March 2020 to August 2019, shedding new light and perspective on the current campaign.
In this blog, I hope to shed some light on the scope, depth and evolution of the XTC IRC Bot campaign. I hope to demonstrate that since August of 2019, the operators behind this campaign have experimented with source code from several IoT botnets and learned how to leverage current exploits for the purpose of developing a new botnet family, Hoaxcalls.
XTC
Back in December 2019, Radware Researchers started seeing a User-Agent header in the daily logs that was fairly noticeable: ‘User-Agent: xtcbot.’ User-Agent headers from malicious attempts typically try to mimic user activity and look more like this:
Typically, criminals want to blend in where they fit in, doing everything they can to avoid standing out or being detected. This highly unusual User-Agent header though, told a different story. It bared all the hallmarks of someone who is looking for attention or searching for eFame. So, with such a noticeable User-Agent, we decided to review the current sample and monitor further activity related to malicious events with User-Agent headers containing the terms ‘xtc’ and ‘xtcbot’.
The first interesting binary was captured on December 18th, 2019. It was an ordinary 32-bit ELF file, nothing atypical for IoT DDoS malware. There was nothing specifically unique either about this sample or its propagation methods. It contained only four simple DDoS attack vectors: UDP, SYN, ACK and DNS flooders. The only notable string found in the sample was a NOTICE that named the botnet and listed the authors’ handle as wells as contact information. We understood at this point the campaign was likely leveraged for criminal services such as DDoS-for-Hire and Botnet Deployment-as-a-Service.
Polaris
After a few months of monitoring the greater XTC IRC Bot campaign, Radware Researchers, while conducting unrelated research, captured a binary on February 3rd originating from IP address 164.32.92.139. That would be the early beginnings of what would prove to be a much larger campaign.
This binary, once again, was very typical for IoT DDoS malware. In fact, there was nothing about this binary that made it worth reporting on. What was unique however, was the IP address used to host the malware. Upon further inspection via URLhaus, we discovered that on the previous day, February 2nd, the same server hosted binaries related to the XTC botnet. This indicator that the XTC and Polaris campaigns could be related or ran by the same operator led me down the rabbit hole.
It was during this search that it was discovered, via submissions to URLhaus, that researchers @0xrb and @zbetcheckin had both uploaded several malware samples which included XTC and Polaris in either the binary name or the malware’s exploit User-Agent header. These submissions pushed the known timeline of the greater XTC IRC bot campaign back to August 2019.
[You may also like: Top 10 Web Service Exploits in 2019]
Upon further review, it was determined that the two campaigns were likely related due to strings that contained overlapping signatures relating to XTC Mirai, vbrxmr botnet service, and XTC IRC Bot. It also appeared that most of the variants were heavily based off of Mirai and Tsunami source code. Further research brought up the domains cnc.dontcatch.us and cbc.vbrxmr.pw, which were previously used by the same operators as malware hosts.
On February 26th, Radware researchers noticed a third domain ‘cnc.Hoaxcalls.pw’ used to host a malware sample ‘Polaris.arm4’ which was delivered through an exploit using an HTTP header ‘User-Agent: Polaris Botnet’. This would become relevant only after Palo Alto Unit 42’s report on the Hoaxcalls Botnet.
XTC IRC Bot by Polaris Security Team
At this point, both operations are assumed to be ran by the same operators. This was further proven on March 2nd when a binary from 164.132.12.44 was captured.
Notable in this sample were the eight DDoS attack vectors: SSYN, FRAG, XACK, SUDP, ZAP, RUDP, OVH, and VSE. The sample correlates with the naming conventions of #polarmalware as the IRC channel and XTC BOT as the User-Agent header for the exploit delivering the malware. The binary also contains a NOTICE ‘XTC IRC BOT BY POLARIS SECURITY TEAM ‘. But this wasn’t the most notable feature about the sample. The most striking difference between this and other samples was the exploit leveraged for propagation: Linear eMerge E30-Series command injection (CVE-2019-7256).
Here is where things really begin to get interesting…
On the same day, March 2nd, another binary was discovered by researcher @Gandylyan1 who submitted to URLhaus.
This sample had similar characteristics as the other sample, but is not identical. The new sample contained five DDoS attack vectors: XMAS, DNS, ACK, UDP, and SYN. Like the previous sample, naming conventions were consistent with #polarmalware as its IRC channel and XTC BOT as the User-Agent header for the exploit. The binary also contained the NOTICE phrase ‘XTC IRC BOT BY POLARIS SECURITY TEAM ‘. Again, this was not the most notable feature about the sample. This sample did not propagate via CVE-2019-7256, Linear eMerge E30-Series command injection, like the previous one. Instead it propagated via three different exploits: a Fritz!Box Remote Comment Execution (CVE-2014-9727), an Alcatel-Lucent OmniPCX Enterprise 7.1 Remote Command Execution (CVE-2007-3010), and a Comtrend VR-3033 Command Injection (CVE-2020-19174) exploit.
March would become a major milestone in the development of the XTC IRC Bot campaign. during the first two days of the month, the campaign leveraged four exploits. But that was only the beginning. On March 11th, Radware researchers caught another binary related to the campaign.
This sample was caught propagating via CVE-2019-16278, Nostromo RCE. Throughout the month of March, our researchers witnessed a large spike in HTTP scans with User-Agent headers ‘Polaris’ and ‘Polaris Botnet’. The scans were probing for 4 specific exploits: CVE-2017-17215, Huawei Router HG532 Arbitrary Command Execution, CVE-2014-8361, Realtek SDK Miniigd UPnP SOAP Command Execution, CVE-2018-10562 & CVE-2018-10561, GPON Routers – Auth bypass / Command Injection, and Netlink GPON Router 1.0.11 RCE which has no CVE.
The scan URIs included:
The results of these scans were later seen on March 28th when Viktor.x86 was seen spreading from 164.132.92.168 via the Netlink GPON Router 1.0.11 RCE. While this binary contained all the hallmarks of the greater XTC IRC Bot campaign, it only contained one attack vector: VSE.
Hoaxcalls
No one likes a quitter and the operators were not going to disappoint anyone during the month of March.
On March 30th, Radware researchers caught another binary from the XTC IRC Botnet spreading through HTTP exploits using two different User-Agent headers: ‘XTC’ and ‘Polaris Botnet’.
This binary featured several strings that contained new contact information for the operator’s botnet services and fits all the descriptions of Hoaxcalls prior to its disclosure by Unit 42. One notable feature about this sample, though, was it propagated via a UCM6202 1.0.18.13 Remote Command Injection vulnerability (CVE-2020-5722).
The operators were and are still nowhere closed to being finished. The following day, on March 31st, an anonymous user uploaded a sample to URLhaus that will later be referenced in Palo Alto’s Hoaxcalls report.
This sample was similar to the one captured the prior day but with two major differences: the newer sample, as reported by Unit 42, contains ‘hubnr and vbrxmr was here’ and adds a vector of propagation leveraging a DrayTek Pre-Auth Remote Root Code Execution (CVE-2020-8515).
Regardless of your feelings towards DDoS or IRC Bots, these operators have been busy! Over the last two weeks we witnessed the operators leveraging an additional two exploits in attempts to propagate their Hoaxcalls/XTC IRC Botnet faster and further.
[You may also like: Botnets: DDoS and Beyond]
On April 22nd , Radware researchers discovered a new sample of Hoaxcalls carrying 19 attack vectors and one new propagation vector. This sample leveraged an unpatched vulnerability in ZyXEL Cloud CNM SecuManager in an attempt to spread its binaries. We have also seen the operators attempting to leverage Symantec’s Web Gateway 5.0.2.8 RCE.
This brings the total of leveraged exploits in the overall XTC IRC campaign to 12 since the beginning of March:
VBRXMR and HUBNR
While I don’t want to get too deep into who the operators could be, I do want to note that throughout the campaign the operators have reused a number of strings identifying their prepared handle, bot name, and contact information. It was not very difficult using some of these data points to discover operators and related activity.
For example, in the middle of March, during the Polaris scanning, a pastebin user going by the alias 0day_of_death was seen posting exploits for GPON Router 1.0.11 RCE, CVE-2020-19174, and CVE-2019-7256. All referencing vbrxmr’s botnet services. As another example, in several binaries the contact information for Viktor was listed as pabloescobar@xmpp.si. A simple google search will present you with a YouTube video by Viktor Sanchez. The video details a stress test of a Private IRC Botnet.
However, here’s the kicker… 5 seconds into the video Viktor shows XTC’s IRC channel. In the video one can clearly see the bot’s C2 communication with its C2 server over IRC and it is not only using the same XTC string with 9 random characters, but also shows the IRC channel #hellroom. Both seen in the Radware and Palo Alto Hoaxcalls reports.
While searching a little further, one can find sock accounts created by Viktor on the forum Nulled.to where he was attempting to sell IRC DDoS malware for $300. This is presumably the Hoaxcalls/XTC code.
This Isn’t Over
If there is one thing I can tell you about this Hoaxcalls/XTC campaign, is that it isn’t over by any measure. The fact that the operators were able to incorporate 12 different exploits in a period of 60 days is fairly impressive. While I try to avoid speculating, another thing that is quite clear about the operators is that they are financially motivated to build and sell botnets or attack services. Because of this financial motivation, they will be more determined than ever to evolve and progress their botnets.
At the moment, the industry is seeing an increase in DDoS related activity and Hoaxcalls/XTC Botnet is one of the more noticeable campaigns. The operators have proven their abilities and continue to move forward with more advanced techniques. In the most recent sample, the operators have use Fast Flux, a technique used by botherders to hide their malware hosts through a series of compromised devices acting as proxies.
Until It Wasn’t Over: LeetHozer
Recently Netlab 360 published a report about a new botnet family, LeetHozer. On March 26th, their researchers captured a suspicious sample generating network traffic that grabbed their attention. Upon investigation they noted that this sample was different from the traditional Mirai variants due to its unique encryption method and use of Tor for its C2 communication protocol. This botnet was mainly observed targeting XiongMai H.264 and H.265 devices because they leave port 9530 open for customer maintenance which allows anyone to start telnetd services and remote into the device. This vulnerability was disclosed on February 4th on Habr and Github and was seen abused in the wild for the first time by LeetHozer.
Netlab 360 reports that the LeetHozer Botnet is likely a new project from the Moobot Group for two reasons. The first being LeetHozer and Moobot both using the same string ‘/bin/busybox DNXXXFF’ in their telnet exploit payload. The second due to the fact that both LeetHozer and Moobot binaries (arm, i585, i686) were seen on the same malware host on March 24th.
This is where things get interesting again. While I’m not going to connect a dot on this one, I am going to highlight a few interesting data points for consideration. While discussing the XTC IRC Botnet with our Director of Threat Intelligence for Radware, Pascal Geenens, he mentioned that he has seen a common phrase from my report in Netlab 360 blog about LeetHozer: ‘vbrxmr’, which we know as Viktor or VB from the XTC campaign.
[You may also like: Radware Threat Researchers Live: Coronavirus & FSB]
Once I reviewed Netlab 360 report I noticed the handle repeatedly used throughout the campaign. For example, Netlab 360 reported that the C2’s server for the 3rd version of LeetHozer was ‘vbrxmrhrjnnouvjf.onion:31337’. To me, this obviously looked like a vanity onion domain (first 6 characters being ‘vbrxmr’) created by Viktor and bared the hallmarks of his signature.
After this I decided to begin reviewing some of the samples listed under Netlab 360’s reported IOC’s.
While reviewing the sample with MD5 0dee2c063085d0c5466137a3c32479f2, I noticed a pattern and habits repeating from the XTC campaign: shared malware host, repeating strings, and a common threat actor ‘vbrxmr’. I’m not going to attribute LeetHozer and Moobot to vbrxmr, I will just leave it at this as a convenient coincidence.
Over the past month we have seen the XTC campaign grow in leaps and bounds in terms of technical ability. We have seen the operators leveraging multiple exploits, deploying multiple variants, and developing their own botnet family for the purpose of selling the source code and DDoS-for-Hire services. The inclusion on vbrxmr in the LeetHozer Botnet is a very interesting one and something that we will monitor going forward.
Concluding Thought
From my perspective, one thing is very clear, DDoS has evolved considerably since I first got involved in 2010. I openly blame those that wrote and publicly released the code to their malware. Because of their fine work, operators like those behind Hoaxcalls/XTC are able to change, manipulate, and combine source code from several malwares, improving and morphing them until they become unique enough to be labeled a new family of bots.
You can’t blame a child for playing with matches. You must ask: how did they get those matches? And then, you think, how can I prevent other children from burning down the house?
