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 [email protected]. 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?
*** This is a Security Bloggers Network syndicated blog from Radware Blog authored by Daniel Smith. Read the original post at: https://blog.radware.com/security/botnets/2020/05/whos-viktor-tracking-down-the-xtc-polaris-botnets/