Artro Botnet Anatomy Overview

Following the idea of knowledge sharing, here another article taken from my private blog and shared for our readers.

Some time ago, while talking with Roman from abuse.ch, we found it necessary to give a more in depth look of a very active Botnet named Artro ( executable commonly identified as Win32/Renos or Trojan-Downloader.Win32.CodecPack ) that registered a high peak of activity and mutability, which quickly led to a large number of infections.

According to abuse.ch the botnet has a size of over 300k unique ips per day, highest peak registered precisely 319’130 unique ips in 24h.

Drones Per Day

Source: abuse.ch

1

GeoLocation

Source: abuse.ch

2

The best approach to start a study of a so large ( in number of variants ) malware is to collect and observe its evolution, by establishing a certain number of chronological sections, where we observe the involved samples in each section.

A good, fast, and absolutely initial inspection system is given by CTPH ( Context Triggered Piecewise Hash or FuzzyHashing ) correlation.

From a group of samples taken from from different periods we have:

3

The tool that I’ve used is DeepToad. DeepToad is a tool to clusterize similar files using fuzzy hashing techniques. What emerges here is that we have files extremely similar from the same chronological capture subset.

Now we know which files are pretty similar, the next step is to achieve awareness of What are these similarities. We can use the precious indication given by CTPH hashes and inspect in depth these subgroups. From PE Geometry:

4

This is a shot of various VersionInfo resource entries, previously we adopted a well defined Taxonomy to classify samples direct consequence of this choice is that we can Assert that the first great evidence of variation is given by VersionInfo. We have also another great information from this classification, there is a Micro Variation given by the FileVersion mutation and a Macro Variation given by the mutation of whole VersionInfo Content.

Finally as should have noticed, “NiceWare” string is globally present. Let’s investigate on the first CompanyName entry: CJSC Computing Forces (Opera Software company we all know what is) that is pretty interesting according to the name.

This company produces a software called WebMoney Keeper, an application referred to WebMoney system. This last one is an international banking system, that has been often target of a wide range of malware, like ZeuS Botnet and other Password Stealers specifically designed to reveal WebMoney Client Software presence and steal banking credentials.

It’s easy to understand that CompanyName could be modified in every moment, often to mask a virus under the name of a legitimate company.

From global analysis let’s move to direct executable analysis.

5

Here are shown three call flow graphs, as you can see the samples are pretty identical at least as general structure, in the detail of the single malware what changes is essentially the code encryption.

7

EntryPoint of every sample is given by an initial Decryption Call. Encrypted data can be seen immediately below inc edx, the code decrypted is placed into a block of memory committed with EXECUTABLE rights. The fresh decrypted code does not have a proper Import Address Table, this is built on fly and stored in a custom encrypted form each entry. Code presents a good level of hostility given by junk code and various layers of encrypted code, this implies that a direct debugging approach will be really long and boring; for this reason I’ve used an ApiMonitor ( Blade ApiMonitor ) to keep trace of APIs involved into infection process.

8

API Trace clearly indicates that after code decryption ( we can say that this happens after, because before and decryption no LoadLibrary emerged ) some dlls are loaded. This allow us to assume that placing a Break on New Module debugging Event will lead us to core of infection algorithm. Execution breaks on a new module load, and after a loop of GetProcAddress finally we leave the allocated block of memory where we are; in other words finishes the Loader Phase; jump to ‘original code’ is given by a:

jmp edx

9

We have an interesting situation here, the original decrypted Artro, plus we have can know the compiler used: Microsoft VisualC++.

When msvcrt._initterm is called, we have a routine composed by two nested cycles, one that loads libraries with LoadLibraryA and an internal cycle with GetProcAddress that retrieves functions, in other words an Import Address Table is builded, here libraries involved and some function:

winiet.dll -> InternetOpenA, InternetOpenUrlA, InternetReadFileA, InternetWriteFile, HttpOpenRequestA, HttpSendRequestA, HttpQueryInfoA, InternetCrackUrlA, InternetQueryDataAvailableA

shell32.dll, snmpapi.dll, advapi32.dll, ole32.dll, kernel32.dll, user32.dll, ws2_32.dll.

finished initterm function, we can see that entire infection code is contained in a call:

10

Inside this call we have the protocol used to communicate with malicious servers, that is given by Encrypted HTTP Transactions. One of the first operations is the attempt to open from \\.\PhysicalDrive15 to \\.\PhysicalDrive0 by using CreateFileA and checking for a Valid Handle. Successively sends via DeviceIoControl ( IOCTL 2d1400h ) a IOCTL_STORAGE_QUERY_PROPERTY to retrieve Volume SerialNumber, necessary to univocally determine the infected Storage.

Artro implements also some trivial Anti Debugging and VM Awareness mechanisms, that are pretty trivial.

Via CreateFileA there attempts to open the following drivers:

\\.\SICE
\\.\NTICE
\\.\SIWVIDSTART

Pretty stupid and useless trick against SoftIce.

\\.\VMDRV -> Anti Vmware

Successively via: GetVersionA, GetNativeSystemInfo, GetInputState
it collects a certain number of information about the victim like, os version, username.

In a second step, will be carved out, browsing information about the victim.

Where is located Protocol Encryption

Artro performs an exchange of data with a set of malicious servers, communications are secured with a layer of encryption. I will not go excessively in depth here but will show the essential anatomy of Protocol Encryption Structure.

11

And here two views of String in Clean and Encrypted String:

12

Structure is a classical key=value&key=.. between data collected there are indications on os in use, admin (yes/no)

You will see this block of encrypted data in the screenshots that show network activity.

Network View

Dns Requests

13

This is the DNS flow of a week old pcap, now we have this:

14

As you can see flow changed, this because megadataonline.net is no longer reachable, infector agent has a list of servers where to send (and receive) malicious data.

HTTP View

On the HTTP side, here what happens:

15

I’ve compared a set of pcaps, from oldest to the most recent samples. What can be immediately observed is that algorithm that generates POST Request Values is always the same, reply differs a bit in the most recent samples.

16

In evidence only header and footer, to show main differences.

17

data value is pretty similar to the POST Req. seen in the previous Stream, this time reply is given by a GIF.