Thanks to Tad Heppner of SophosLabs for his help with this article.
Some attackers love Betabot malware but not all of them like paying for it.
Betabot is a malware family used to hijack computers and force them to join botnets. It has been used to steal passwords and banking information, and has most recently been used in ransomware campaigns.
Though attackers have found it easy to use, buying the Betabot builder from its creators isn’t cheap. To get around that, some have been using cracked builders to copy the original design without paying for it.
In a new paper, SophosLabs researcher Tad Heppner focuses on Betabot samples produced from cracked builders to dissect the malware’s capabilities and associated botnet server components. His ultimate goal: explore how to extract and decrypt the configuration data.
Specifically, Heppner explains how to use the cryptographic keys encoded in the malware’s configuration data to decode communications between the bot and the command-and-control server.
Most of the methods described in the paper focus on Betabot 1.7 malware produced using a cracked Betabot builder. It also includes information on alternate methods researchers can use to decode older Betabot versions and a related variant called Neurevt.
As malware goes, Betabot is pretty old. New variations have popped up over time as the authors continually revise and update it. The most prevalent revision found in the wild is Betabot 1.7.
The number of Betabot infections found in the wild in recent years has fluctuated. Along the way, larger campaigns have introduced new methods to pack and distribute the bot client in an attempt to circumvent antivirus.
SophosLabs has also discovered samples that attempt to connect to control servers without public domain or IP addresses, suggesting they may reside entirely within a private network.
Rumors of a 1.8 version have circulated on several hacking sites. But the majority of samples investigated have been 1.7 versions of the botnet or versions that have been slightly modified after the fact with no significant changes to the existing Betabot components.
The most significant change in 1.7 from its 1.6 predecessor was the inclusion of an additional layer of HC128 encryption on the individual command and control [CnC] server entries within the malware’s configuration data structure.
Cracked Betabot builders are all the rage
Betabot’s command-and-control (CnC) server interface is easy to use and is favored by cybercriminals who either lack the technical knowledge or desire to author a botnet framework themselves.
The Betabot malware package is advertised on black markets for around $120 USD and is typically purchased by contacting the author directly to arrange payment.
But the existence of cracked builders indicates cybercriminals are not only targeting members of the unsuspecting public, but also other malware authors with the goal of stealing their work.
The crack itself consists of a console-based builder application with the compiled Betabot template code stored as a bytes array within the data section of the builder application itself.
Though this isn’t unprecedented, the increased availability due to the use of a software crack often results in an increase in new parties using the malware family.
Betabot creators fight back
Betabot’s creators have taken steps to add some antipiracy measures to their toolkits to ensure they get paid when other cybercriminals use their malware.
Among other things, the authors have added complexity to the process for encoding the configuration data inside the bot payload. The configuration data includes the URLs of the CnC server(s) that the bot will connect to as well as encryption keys that will be used to encrypt and decrypt the information sent to the individual CnC server(s).
This configuration data is encrypted and stored within the bot itself when the payload is generated. The complexity of this packing method not only makes it difficult for antivirus and other security tools to unpack the information statically, but it also deters other criminals from attempting to encode their own configuration data containing altered information.
This way, the authors attempt to maintain control of the process to generate new bot payloads for a given CnC server. Although the method is complex, it is still technically possible to decode this information because the decryption key must somehow be made available to the bot itself when it infects a new target.
Another interesting antipiracy feature called “proactive defense” has been added to Betabot to prevent other competing bots or similar tools such as remote access trojans from installing and potentially hijacking the botnet.
When run, it allows the user to specify custom configuration information that is then encrypted and inserted into the included template code at the appropriate position. The whole PE file is then repacked in an attempt to further obfuscate the generated bot in an attempt to avoid detection by antivirus software.
Decrypting the configuration data
After exploring how Betabot and its builders work, SophosLab’s Heppner reviewed several other custom layers of obfuscation and encoding that are applied to the bot’s configuration data in an attempt to mask and deter reverse engineering.
Some of these methods seem to vary slightly with each significant update of Betabot. The structure of the config data and the use of RC4 in the primary layer seem to have remained fairly constant from version to version. However, the XOR key values, initialization vectors, and other minor variations seem to be introduced or modified with each update.
From there, he outlines various steps to decrypt and decompile Betabot.
In the final analysis, Heppner expects the Betabot family to remain popular, used to spread other malware campaigns and harvest site login credentials.
Despite the best efforts of Betabot’s authors to cut down on piracy, it remains easy pickings for copycats.
The full report is available on Sophos’ technical paper page.