As part of Unit 42’s efforts to proactively monitor threats circulating in the wild, I recently came across new Hoaxcalls and Mirai botnet campaigns targeting a post-authentication Remote Code Execution vulnerability in Symantec Secure Web Gateway 184.108.40.206, which is a product that became end-of-life (EOL) in 2015 and end-of-support-life (EOSL) in 2019. There is no evidence to support any other firmware versions are vulnerable at this point in time and these findings have been shared with Symantec. They confirmed the currently exploited vulnerability is no longer present in Symantec Web Gateway 5.2.8. Symantec also wanted to emphasize the point that this vulnerability does not impact Secure Web Gateway solutions, including ProxySG and Web Security Services.
The first instance of this vulnerability being exploited surfaced on April 24th, 2020 as part of an evolution of the Hoaxcalls botnet that was first discovered earlier that same month. This latest version of Hoaxcalls supports additional commands that allow an attacker greater control on the infected devices, such as the possibility to proxy traffic through them, downloading updates, maintaining persistence across device restarts, or preventing reboots, and a larger number of DDoS attacks that can be launched. The use of the exploit in the wild surfaced only a few days after the publication of the vulnerability details, highlighting the fact that the authors of this particular botnet have been pretty active in testing the effectiveness of new exploits as and when they are made public.
Following that, in the first week of May, I also came across a Mirai variant campaign involving the use of the same exploit, though in this campaign, the samples themselves don’t contain any DDoS capabilities. Instead, they serve the purpose of propagation using credential brute force and exploitation of the Symantec Secure Web Gateway RCE vulnerability This blog post provides any noteworthy technical details on these two campaigns.
Palo Alto Networks customers are protected from this attack: WildFire correctly identifies all related samples as malicious and Threat Prevention blocks all exploits used by this variant. In addition, AutoFocus customers can track this exploit using the tag SymantecWebGateway_RCE.
The Hoaxcalls botnet, an offshoot of the Bashlite/Gafgyt malware family, was first discovered in April 2020, exploiting recently disclosed vulnerabilities in certain models of Grandstream business telephone IP PBX systems, and Draytek Vigor routers.
A few weeks later, the botnet was found exploiting an unpatched vulnerability impacting Zyxel Cloud CNM SecuManager.
On April 24th, I observed samples of the same botnet incorporating an exploit targeting the EOL’d Symantec Secure Web Gateway v220.127.116.11, with an HTTP request in the format:
POST /spywall/timeConfig.php HTTP/1.1
As seen in the snippet above, some samples reach out to a URL for a public file upload service (plexle[.]us) where the post-exploitation payload is hosted.
A comprehensive list of indicators of compromise (IOCs), along with a timeline of this activity can be found at the end of this post.
While the new version of the Hoaxcalls botnet is very similar to the initial version, to the point that it even uses the same encryption scheme with the exact same keys, it supports additional commands that allow an attacker greater control on the infected devices such as the possibility to proxy traffic through them, downloading updates, maintaining persistence across device restarts or preventing reboots, and a larger number of DDoS attacks that can be launched. These have been detailed below.
|SYMANTEC||scan and infect Symantec Secure Web Gateway devices using the RCE described just above.|
|FASTFLUX||proxy traffic from the device to an address specified by the attacker|
|UNINSTALL||kill the running malware process|
|KILLTELNET||kill the telnet service on the device (this is probably to make maintenance of an infected device trickier for administrators)|
|LOCKDEVICE||setup a cronjob to ensure the binary is running and maintain persistence across device restarts|
|UPDATE||delete the existing bot binary, and download an update from 164[.]132.92.180/sh using either wget or tftp (The update URL was serving a script as seen in Fig 1 below)|
|MOVE||switch IRC server|
|IOCTL||disable the watchdog timer to prevent reboots|
|HTTPCONN||launch HTTP CONNECTION request flood against specified target|
|HTTPOPTIONS||launch HTTP OPTIONS request flood against specified target|
|HTTPTRACE||launch HTTP TRACE request flood against specified target|
|HTTPDELETE||launch HTTP DELETE request flood against specified target|
|HTTPPUT||launch HTTP PUT request flood against specified target|
|HTTPPOST||launch HTTP POST request flood against specified target|
|HTTPHEAD||launch HTTP HEAD request flood against specified target|
|HTTPGET||launch HTTP GET request flood against specified target|
|URG||launch URG flood against specified target|
|PSH||launch PSH flood against specified target|
|ACK||launch ACK flood against specified target|
|FIN||launch FIN flood against specified target|
|RST||launch RST flood against specified target|
|SYN||launch SYN flood against specified target|
|TCP||launch TCP flood against specified target|
|VSE||launch VSE flood against specified target|
Table 1. New Flooder commands
The URL contacted for the update serves a shell script that downloads and executes binaries from attacker-controlled URLs.
Other bot and flooder commands in common with the previous version of the Hoaxcalls botnet have been described in detail previously.
Samples of this campaign surfaced early May, built on the Mirai source code, and are packed with a modified version of UPX by using a different 4-byte key with the UPX algorithm.
Another deviation from the Mirai source-code is the use of all of ten 8-byte keys that are cumulatively used for a byte-wise string encryption scheme.
0xDEADBEEF, 0x85DAB8BF, 0xDEEDEEBF, 0xDEABBEAF, 0xDBBD45BF, 0x246584EF, 0x85BFE8BF, 0xD68395BF, 0xDBAAAAAF, 0x0DAABEEF
This is similar to the scheme used by the Hoaxcalls botnet, and has been seen used in previous variants too. However, as has been clear with previous implementations too, the use of multiple keys does not imply greater encryption complexity, and in this case this essentially amounts to a byte-wise XOR encryption with 0x5a.
In this campaign, the samples themselves don’t contain any DDoS capabilities, but rather serve the purpose of propagation using credential brute force and exploitation of the Symantec Secure Web Gateway RCE vulnerability.
Speculation on Exploitation Success
It is worth mentioning that the botnets’ success at exploitation and infection is limited by the following two facts:
- The Symantec Secure Web Gateway RCE vulnerability being exploited is a post-authentication vulnerability implying the exploit is only effective for authenticated sessions.
- The devices being targeted are EOLDproducts from 2012, and installations with newer firmware would not be vulnerable.
In the case of both campaigns, one can assume that their success with this exploit is limited by the post-authentication nature of the Symantec Secure Web Gateway RCE vulnerability.
Palo Alto Networks customers are protected by:
- WildFire, which detects all related samples with malicious verdicts
- Threat Prevention, which blocks all exploits used by this variant.
The exploit can be tracked in AutoFocus using the tag SymantecWebGateway_RCE
Palo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. For more information on the Cyber Threat Alliance, visit www.cyberthreatalliance.org.
Indicators of Compromise