You might remember ZeroAccess, one of the largest and most advanced P2P botnets that ever existed. It first appeared around 2009 in form of a kernel-mode rootkit focused on click fraud and was later used for bitcoin mining. Later versions appeared without the kernel-mode rootkit. As we found out, the developer of ZeroAccess also created legitimate tools as a freelancer. He also mentioned a self-made Windows kernel-mode debugger in one of his service offerings, but we were unable to find it at that time. I discovered it on Virustotal in 2018, and as of this year, the ZeroAccess developer itself has posted an upgraded version on GitHub. You read correctly: the ZeroAccess developer is still active today, however he most likely does no longer create malware. At least since his last public exposure in 2016, I haven’t come across any new malware samples that use his trademark.

In April, Kaspersky briefly described a new malware dubbed DreamLand in their APT trends report Q1 2023. Quote:

In March, we discovered a new malware strain actively targeting a government entity in Pakistan. We designated this malware “DreamLand”. The malware is modular and utilizes the Lua scripting language in conjunction with its Just-in-Time (JIT) compiler to execute malicious code that is difficult to detect. It also features various anti-debugging capabilities and employs Windows APIs through Lua FFI, which utilizes C language bindings to carry out its activities. This is the first time we have seen Lua used by an APT threat actor since its use by AnimalFarm and Project Sauron.

While analysing the downloader from APT29 that uses the Slack messaging service (SHA-256: 879a20cc630ff7473827e7781021dacc57bcec78c01a7765fc5ee028e4a03623), I’ve found another downloader that utilizes Google Drive. It is also delivered via an ISO file like the previous ones. I call this new .NET downloader DoomDrive in reference to the older BoomBox one. With this latest addition, there are 4 known early stage downloaders that abuse legitimate services:

You may have heard of dotnetfile, a library to extract header information from .NET assemblies. Basically, these files are made of the common language runtime (CLR) data located in the .NET header and the actual byte code, both “encapsulated” in a PE file. Compared to the PE header of an unmanaged native file, the CLR header contains much more runtime information. Some of this data can be useful for static malware detection, threat hunting and intelligence gathering as I’ll show in this blog post.

During a malware analysis, you may encounter the situation where a next stage payload is loaded or injected into another process. When this is the case, usually a raw PE file gets decrypted in memory that is used to build the memory module. The trick is to find the procedure which decrypts the raw file with a debugger and dump the memory region which contains this payload. This allows you to easily extract the original PE file from the dump for further analysis. Thus, you usually don’t need to perform contorts like dumping the memory module of the payload and rebuild its import address table.