Crediting R136a1 who published malware samples a few days ago on a forum, we found these samples under development. We quickly went ahead and analyzed one, allowing us a unique view into malware at such an early development stage.
This kind of glimpse into malware development enables the security community to understand the techniques and key focus points of the malware’s authors. Accordingly, it allows enhancing the processes and technologies when dealing against such threats.
“ArdBot”, the name of this malware, is based on the name the malware authors gave to its core nefarious module.
A Malware Under Initial Stages of Development
ArdBot is in its early stages of development. Making the obvious analogy to a commercial productized product, we cannot even call ArdBot an alpha- or beta- version as the malware author was still in debugging stages:
- The malware contained many debugging strings and popped up messages when it reached certain points. The debugging strings are all written to a log file and some are also popped up to the user.
For example, ArdBot leeches on to Windows Explorer as its C&C communication channel. To do this, it injects its own nefarious code into the Windows Explorer process. Once this injection occurs, the malware shoots out a Windows-style pop up with the “Injected” message:
- The malware communicates with the machine it is installed on. Our particular sample communicates with "localhost" - the local machine, suggesting that the authors had the C&C server installed on the same machine they use to test the malware itself.
- The malware itself tended to crash when running the process. Malware authors keen that their malware remains stealthy will validate prior to deployment that their malwares are stable since a crash brutally indicates that something “bad” is happening in the user’s system.
Malware Development Practice #1: Remaining Stealthy
Despite its early stages, we can already tell that the malware author is building ArdBot with stealth in mind.
The malware author developed full sections of code from scratch. For example, the packing mechanism (a sort of protection/ encryption/ compression of the malware’s binary code) was created by custom-made code. This raises a few eyebrows as there are many commercial or freeware packers that the author could have used. It even makes sense to assume that these commercial packers provide better protections against analysis. However, security solutions typically alert on these commercial packers which leads us to believe that the ArdBot authors decided to compromise on anti-analysis in favor of avoiding detection.
In another case, the malware author decided to forego using a specific API (CreateRemoteThread) which is commonly used by other malwares. Once again, we can assume that the authors wanted to avoid being picked up by security solutions looking for this API.
Malware Development Practice #2: Maintaining Persistency
ArdBot initially adds itself to the registry Auto-Run key on the infected system.
A protector thread runs every second and continuously checks the registry and executable file combination. If either one is deleted, the malware will recreate it.
Malware Development Practice #3: Ensuring Consistent Communications
ArdBot is initially provided with a configuration file that defines its communication. Configuration includes several parameters regarding the malware’s behavior (such as communication frequency and sleep times) as well as a list of servers it should communicate with.
That said, this configuration may be updated by the C&C server at any stage. The update itself is encrypted to keep it secure. To avoid then being detected by security solutions, the malware authors created their own encryption – which could be simple enough to overcome or skip - instead of using external libraries, APIs or known methods.
Malware Development Practice #4: When All Goes Wrong, DoS
ArdBot is looks like a Launchpad to install any other malicious files. The reason is that it enables downloading and executing code in memory.
Interestingly, a few commands recognized by ArdBot are to flood a host with HTTP GET requests, TCP packets or UDP packets. In other words – commands to perform a Denial of Service (DoS) attack.
While it seems that the malware authors are intent on building a data-stealing or data-tampering malware, they recognize that it might just be that something may go wrong. As such, they put in place a plan “B” where the already-installed ArdBot can still be used – just for other purposes. In this case, for a DoS attack.
ArdBot is a malware in the making whereas its authors did not want this malware to be published – or analyzed - just of yet.
Getting our hands on such a raw sample gives us a few rare insights into how malware authors build their malware step-by-step. We can assume that the ArdBot authors will continue developing this malware, adding further building blocks along the way, or someone else will take it upon themselves to further develop. Whatever the case, it is likely we’ll see some sophisticated ArdBot-like strains in the future.