Many heartfelt thanks to the contributors of the blog, this adventure would have been very different without the help of each one of you. Nor do we want to forget each of the readers who have decided to use their precious time to read us post after post.

The post sudo systemctl hibernate appeared first on S3lab.

The post apt-get install summer appeared first on S3lab.

The post document.write(‘blog 1461 days’) appeared first on S3lab.

The post Turning off server room coolers appeared first on S3lab.

The post Under “Summer” Construction appeared first on S3lab.

Malware analysis sandboxes execute samples in a controlled environment in order to monitor their behavior, but generally these systems do not provide information about how the sample is protected / packed. If we remember from previous posts, malware authors generally protect their creations in order to avoid detection and hinder reverse engineering. A packed program contains a routine that will decompress or decrypt a protected memory region and execute it afterwards. In many cases the authors use several protection layers in order to conceal the original code, as well as heavy obfuscation, anti-debugging or anti-sandboxing techniques.

Typically, the malware analyst will need to perform a deep static analysis of the malicious code in order to get a good understanding of the sample. For this, she will need to unpack the sample first in order to dump the original code of the binary. There are several alternative approaches: specific unpackers target the most common packers, allowing the analyst to easily unpack some commonly used protections. Generic unpackers generally use certain heuristics to detect the appropriate moment to dump the memory. Nevertheless, these heuristics are not always effective. As a last resort, the analyst will need to manually unpack the sample, and figure out how it protects the original code.

While there are many sandboxes that allow to extract behavioral indicators of malicious samples, there are no widely available tools that focus on the packer itself. PackerInspector tries to fill this gap, offering a detailed report about different static and dynamic characteristics of the packer. These features (number of layers, interaction between layers, number of processes and interaction between them, structure of the layers…), allow us to categorize the structure of the packer into 6 levels of structural complexity. For instance, UPX, one of the most simple packers available, has a Type-I complexity, while Armadillo (when CopyMem protection is activated), has a Type-VI structural complexity.

This graph corresponds to a packer with one process (P0) and 4 layers (0 to 3). Each layer contains a set of regions (memory areas written and executed). For instance, if a given region Ra  is written by another region (Rb) in layer 1, and Ra is afterwards executed, then Ra will be part of layer 2. Each region shown in the graph has a first line of text with the memory type (M (module), S (stack), H (heap)), and the start address for the memory area. A second line shows the size of the region. The third line shows three values separated by “#”, where the first one corresponds to the total number of API function calls, the second number shows the number of different functions called, and finally the third one indicates the presence of calls to certain families of API functions, commonly used in the bootstrap code inserted by compilers. Finally, the fourth line shows the number of frames (whenever a region has been written and executed at different times). The colour of the regions show certain properties. For instance, red means that it was the last region executed in our sandbox.

This packer first decrypts a first layer, and afterwards executes the memory located at 0x401000. Afterwards, the routine located at 0x4079b1 in layer 1 decrypts the second layer, which decrypts a third layer containing the original code. The gray connectors indicate that there is only 1 execution transition between each pair of layers, while green and red connectors indicate the number of bytes written by a region to some other region in the next layer (it will be red whenever this write operation is followed by an execution transition). Finally, we observe that the red region in the last layer shows a higher number of API calls, as well as API calls related to compiler inserted bootstrap code. All these facts indicate us that the original code is located in this layer.

If you want to learn more about how our system works, you can visit our reference page. In our original study we measured the structural complexity of malware samples collected by the Anubis sandbox throughout several years. Today, with the publication of this service, we continue this measurement study by collecting statistics on the submitted samples.

PackerInspector allows to send samples both publicly or privately. In order to make private submissions you will need to log in with a Google account (OpenID). We do not store your email or any other registration data except a unique code that identifies your account. For public submissions, the analysis result will be available to anyone in possession of the report url. In contrast, if you submit the sample privately, only you will have access to the generated report. Also, if you are logged in, you will be able to follow the status of your submissions and list your previous submissions. Also, you will be able to use our public API for automated submission and result collection.

Happy reversing!

The post PackerInspector: Our sandbox for packers appeared first on S3lab.