During my researches I found the next file.
| MD5 | 5e81bd134168d7d8c91b96d88b5e0fd0 |
| SHA1 | a632371b2aa54709d4bf6b0f28cb1904cb8864bc |
The file is the HashCalc application made by SlavaSoft company (or no).
It works as its definition into SlavaSoft homepage:
A fast and easy-to-use calculator that allows to compute message digests, checksums and HMACs for files, as well as for text and hex strings. It offers a choice of 13 of the most popular hash and checksum algorithms for calculations.
And the binary has all features described in its description.
After a static analysis, I did not find anything interesting, just in the ".text" section there is permission to write, but this is typical in some packers.
When I analyzed the binary dynamically, no suspicious behavior was detected, I tried almost all features.
At this point, I was confused, it seems a legitimate binary, if there have not enough time to analyze the file, every people (including me) will say that the binary is goodware.
Before starting to debug the program, I thought to download the file from its homepage and compare it with my binary. But usually when a file is been analyzed we can not get the original file for comparing. In those cases, there are two choices, finish the analysis or to debug the full binary. If the binary is too big, we can spend a very long time to debug it, some times will be almost impossible if we want to have an immediate response(+100MB).
In this case I have the original file but, is there some hidden feature in the program I am analyzing? let's see.
They have the same entry point.
The MD5 value of all sections are equal, except in one case, ".text" section.
Comparing ".text" section we can found the differences between both files at the last bytes of the section.
If we decompile those bytes with hiew, we can read some ASM instrucctions.
I am going to put a breakpoint at the first instruccion, I want to debug that code. Maybe the code is executed or maybe no. Maybe it is not a code.
After put the breakpoint, the application runs well and it does not stop its execution. The images below show me testing some features of the application without stopping its execution.
In the next image, when I try to get the hash signatures from a file, the application stops its execution.
Now we are at the first instruction of the code seen previously. This code tries to decrypt itself. This image is the encrypted shellcode.
Function for decrypt the shellcode. (It is a simple XOR with 7 value).
Decrypted shellcode.
There are some interesting strings into decrypted shellcode:
- SLAVA
- kernel32
- ANNA (Anna Chapman???)
- CreateEventA
- \\.\PhysicalDrive0
- ALISA
- KATI
- ntdll
The shellcode looks like:
The shellcode does the next steps:
1. The code decrypts itself.
2. Adjusts Privileges (SeDebugPrivilege).
3. It creates a event named SLAVA. If the event is not created yet, it returns to original code, so this code is waiting for this event. (An event created by who?, It is too easy to create a legitimate program to create an event...)
4. The shellcode overwrites the first 512 bytes from "\\.\PhysicalDrive0" (boot sector). When this sector is overwritten the computer will never boot.
5. The code encrypts itself. It does this to hide the malicious code
6. It returns to original code.
If you remember the first image of this post, the file is detected only by one AV :O.
Conclusions: In these cases, is difficult to find the malicious code (It only is activated when a specific feature is used), think in a binary with +50MB. Maybe if we have the original file we can focus our analysis in the differences, but in some times this is not possible. We have to spend a lot of time (or money) to find malicious code. This file could be an APT waiting for third party event(Who did make this file? Why? Are they using a tool to make this?). So, if we have the oportunity, we must compare the file with the original file. But, What happen when we can not get the original file?
Author: @D00RT
