Introducing PE_unmapper

Recently I wrote a small tool, that can be used as a helper in malware analysis.
Various malware types unpack their core modules in memory, load them and run.
In order to unpack them fast, we can let the malware do all the operations and then just dump the result. However, the dumps are in virtual format – so, we may have problems running them independently and viewing by typical tools.
PE_unmapper allows to convert those dumps into their raw format. The tool is totally independent, so it is up to you by which way you prefer to make dumps. You only need to know the base where the module was loaded, in order to relocate it properly.

download-icon-png-5 The tool is open-source, available on my github:
https://github.com/hasherezade/malware_analysis/tree/master/pe_unmapper

youtube-512 See it in action on YouTube:

*TURN ON SUBTITLES FOR MORE INFO*

Posted in Malware, Tools, Tutorial | 1 Comment

Princess Locker decryptor

[UPDATE: 28th Nov 2016] – unfortunately, recently I got an information that there is some new variant around that is not decryptable at the moment. If generating the key takes more than few minutes,  it probably means that you has been infected by the new version of Princess. Please upload your malware sample on Virus Total and send me the link if you want me to take a look at your case. Research is in progress, stay tuned.


Recently I made a decryptor for Princess Locker ransomware (tested on sample: 14c32fd132942a0f3cc579adbd8a51ed):

princess_banner.png

Ransom note example:

princess_ransom_note

In this thread you will find all the information and updates about the progress.

Currently I prepared a set of two EXPERIMENTAL tools: keygen and decryptor.

download-icon-png-5.png  You can download the full package from here.

youtube-512   See it in action on YouTube: https://www.youtube.com/watch?v=Ted84CoOPvg

Use the keygen first in order to find your key. If this operation went successful, you can use decryptor to decrypt your other files.

The tools are protected with PE-Lock (special thanks to Bartosz Wójcik).


HOW TO USE

In order to use the keygen you must find one file, that you can provide in both forms: unencrypted and encrypted. You also need to supply the added extension. It is beneficial (but not required) to supply the unique ID from your ransom note.
Usage:

PrincessKeygen.exe [encrypted file] [original file] [added extension] [*unique id]

* – optional parameter

Example:

Read the data from your ransom note:

ransom_id

And supply them to the keygen:

PrincessKeygen.exe "square1.bmp.xauwk" "square1.bmp" xauwk ujivtjf25pwt

What if you don’t have any original file?

In case if you don’t have the original copy of any of your encrypted files, you can use an encrypted file of one of the following formats:

doc, png, gif, pdf, docx, xlsx, ppt, xls

Then, instead of the original file, supply the preprepared header – you can find the set here. However, this method may, in some rare cases, produce invalid results – so, supplying the original file is recommended.

Example:

princess_keygen

What if you don’t have the ransom note?

It’s OK. Just supply the extension – but be warned that cracking may take a bit longer.

no_note


Check if your output file is valid. If so, save the key and use it to decrypt rest of your files, with the help of PrincessDecryptor.

Usage:

PrincessDecryptor.exe [key] [ransom extension] [*file/directory] 

* – optional parameter – default is current directory

Posted in Malware, Malware Decryptor, Tools | 8 Comments

How to turn a DLL into a standalone EXE

During malware analysis we can often encounter payloads in form of DLLs. Analyzing them dynamically may not be very handy, because they need some external loaders to run. Different researchers have different tricks to deal with them. In this post I will describe some of my tricks for patching DLLs, so that they can run as independent executables.

Usually we can encounter 2 cases:

  1. meaningful code starts in one of the exported functions
  2. meaningful code starts in DllMain

To illustrate those cases with real-life examples I will use 2 malware samples.
First case – represented by Bunitu Trojan (b0a91e1f91078bad48252edc989e868e) and second case: represented by Petya/Mischa dropper (c8e4829dcba8b288bd0ed75717214db6).

Those DLLs have been unpacked from their loaders/crypters – but in order to keep things simple I am not gonna describe here the full process of unpacking.

In both cases we will start from editing the field Characteristics in the File Header and removing the flag indicating that the file is a DLL. I will do it using PE-bear:

edit_fhdr.png

I changed the value:

changed_fhdr.png

Case #1: When the meaningful code starts in the exported function

In this case, one more modification is required before we save the file.

We have to change the entry point in order to point the appropriate function from export table – the one where the execution of the meaningful code starts. We need to find the Function RVA:

exports.png

Then, follow it:

follow_rva

On the Disasm tab we can see the code of this function. Now, we should redirect Entry Point to it’s beginning:

redirect

And save the file as EXE:

save_as

In case of Bunitu Trojan, this function does not take any parameters, so we not need to fill anything more. Now, we can run the saved file like a normal executable (see the patched version at malwr).

Case #2 – meaningful code starts in DllMain

This time we not need to change the Entry Point – just after changing Characteristics in File Header save the file and load it under a debugger (I will use OllyDbg).

Similarly to the main function in typical executables, DLLs have their DllMain function that is executed automatically when they are loaded to the memory  (the same function is also executed on few more events – i.e. on DLL unloading).
Let’s recall it’s header:

BOOL WINAPI DllMain(
  _In_ HINSTANCE hinstDLL,
  _In_ DWORD     fdwReason,
  _In_ LPVOID    lpvReserved
);

As we can see, the function takes 3 arguments. The first one (hinstDLL) is the handle to the memory area where the DLL has been loaded. Second stores a value that indicates the reason why the DllMain has been triggered. Read more here.

To make our patched DLL run properly, we must take care that it’s arguments will be filled with proper values – especially important are the first two that I mentioned.
The first argument: hinstDLL – must contain the module handle (ImageBase). Second usually should be filled with 1 – to emulate DLL_PROCESS_ATTACH.

That’s how the Entry Point of the dumped executable looks:

setup_ep

Let’s add a code that will overwrite the arguments with valid values. I will utilize some free cave for this purpose. Fortunately, there is enough space at the end of the code section:

free_space.png

I am gonna do some patching  in order to redirect execution to this place. We need 5 bytes for the jump – so, let’s remove/rearrange some code in order to gain the space (if we are lacking in space, some instructions can be also moved to the cave, along with the added code):

place_to_patch

Patched – step 1:

place_to_patch2

Patched – step 2:

patched_step2

I redirected execution to the mentioned cave. We will copy aside the address that is just after the added jump, to go back to this place later.

Now let’s fill the cave with needed code.

To fill the first argument with the valid ImageBase I will copy the value from Process Environment Block (pointed by FS:[30]) . This is example of the code that do this job:

MOV EAX, [FS:0X30] ; copy to EAX handle to PEB
MOV EAX, [EAX+0X8] ; copy to EAX the field with ImageBase
MOV [EBP+0X8], EAX ; copy the content of EAX
 into the first argument

Now, let’s fill the second argument with a vale 1, emulating that the DLL is loaded:

MOV DWORD [EBP+0XC], 0X1

The third argument can be filled with NULL:

MOV DWORD [EBP+0X10], 0

Added code:

added_code

Now only returning jump is remaining:

returning_jump

And we can save the modified executable:

copy_mod

Now we can run/debug the saved file as a standalone executable.

Ending note

Of course the the described techniques are not a silver bullet that will work for all the DLL payloads that we can encounter. My goal was just to provide some examples and inspiration for experiments. However, those simple tricks worked for me in many cases making the work much easier.

Appendix

https://en.wikipedia.org/wiki/Win32_Thread_Information_Block

https://en.wikipedia.org/wiki/Process_Environment_Block

Posted in Malware, Tutorial | 5 Comments

Unpacking NSIS-based Crypter – part 2

After publishing my short tutorial about unpacking NSIS-based crypter I got one more sample from a reader who complained that my method doesn’t work – so I decided to take a look inside. Of course cybercriminals continuously work on improving their tools, so I would not be surprised if they completely replaced the algorithm by something new. However, as we will see, in this case they added just some tiny tricks to mislead.

Before reading this article please refer to the first part for more background information.

Sample:

b9b3a9fac262f36df864fbef767f8ad2 – original sample

Used scripts:

Steps

  1. Decompress

Again we will start from decompressing the original sample. This is the content in the directory of our interest:

folder1.png

2. Find the DLL

The only DLL in this folder is named AnimGif.dll (it’s original name is ContinueAcrefoot.dll). It exports one function: __CPPdebugHook – and we can suspect that  this is the function will be used for extracting the payload:

exported_func.png

Let’s search inside the names of files that are going to be decrypted and loaded:

refered_namesOk, we got some names:

  • “Akmryote.vbkOEvgOYj”
  • “WNshery.jEcychvgOlR”

and the possible key for decrypting the payload:

“SNowcapLithoLabyrinthPerquisiteArroyo”

3. Find the referenced files in the same directory where the DLL is.

File “Akmryote.vbkOEvgOYj” does not exist, but we can suspect that it means the file “Akmryote.vbk”.

file1.png

What about about “WNshery.jEcychvgOlR”? Nothing like this exists in the unpacked directory… We can guess that the file has been renamed. We can go by the hard way and analyze the (obfuscated) unpacking function – or use the shortcut to figure out which of the dropped files is our payload.

We can start by taking a fast look on every file and eliminating those that are for sure not the payload, i.e. images, files containing text etc. We are left with some suspects – and using bytes visualization we can find out more about them.

burks.eey:

enc_burks.eey.png

burks.ujg:

enc_burks.ujg

and the already mentioned file “Akmryote.vbk” looks like this:

enc_Akaryote.vbk

Visual patterns in burks.eey suggests, that it has some padding in between – that is common in PE files – so it will be the first suspect of being the payload.

Files burks.eey and burks.ujg have not only similar names, but also similar sizes, that looks a bit suspicious.

64661 burks.eey
64267 burks.ujg

My guess is that it can be a payload divided into two parts, that is merged and saved under the referenced name, and then unpacked.

Akmryote.vbk  is too small to be the payload and visual patterns suggests that it have different content at the beginning – probably this is the element with functions that are going to be loaded (that part starts from text that is followed by code).

4. Try to crack the payload

Let’s try to crack burks.eey using the known algorithm (nsisdec.py, mode 2) and the found key: “SNowcapLithoLabyrinthPerquisiteArroyo” :

./nsisdec.py –file burks.eey –key “SNowcapLithoLabyrinthPerquisiteArroyo” –mode 2 > out.bin

No luck. The output is nothing like the beginning of the PE file.

./nsisdec.py –file burks.ujg –key “SNowcapLithoLabyrinthPerquisiteArroyo” –mode 2 > out.bin

Now it looks much better – we can see patterns suggesting that it is really a PE file, and the used algorithm is valid:

00000000  61 7a b0 00 03 00 00 00  04 00 00 00 ff ff 00 00  |az..............|
00000010  b8 00 00 00 00 00 00 00  40 00 00 00 00 00 00 00  |........@.......|
00000020  00 00 00 00 00 00 20 20  00 00 00 00 00 00 00 00  |......  ........|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 e8 00 00 00  |................|
00000040  0e 1f ba 0e 00 b4 09 cd  21 b8 01 6c ed 21 54 68  |........!..l.!Th|
00000050  69 73 20 70 72 6f 67 72  61 6d 20 63 61 6e 6e 6f  |is program canno|
00000060  74 20 62 65 20 72 75 6e  20 69 6e 20 44 4f 53 20  |t be run in DOS |
00000070  4d 4f 64 65 2e 0d 0d 0a  24 00 00 00 00 00 00 00  |MOde....$.......|
00000080  ce b7 f2 b5 8a d6 9c e6  8a d6 9c e6 8a d6 9c e6  |................|
00000090  49 d9 93 e6 89 f6 bc e6  49 d9 c3 e6 8b d6 9c e6  |I.......I.......|
000000a0  49 d9 c1 e6 88 d6 9c e6  83 ae 1f e6 89 d6 9c e6  |I...............|
000000b0  83 ae 0f e6 a9 d6 9c e6  8a d6 bd c6 05 d7 9c e6  |................|
000000c0  91 4b 33 e6 de d6 9c e6  91 4b 01 e6 8b d6 9c e6  |.K3......K......|
000000d0  52 69 63 68 8a d6 9c e6  00 00 00 00 00 00 00 20  |Rich........... |
000000e0  20 00 00 00 00 00 00 00  50 45 00 00 4c 01 04 00  | .......PE..L...|

Yet, it is not perfect… The first character of the header is always modified, so we not need to bother about it for now. But in the further part we see some invalid characters, i. e. the second character is small ‘z’ instead of capital ‘Z’ – similarly in the word “Mode” we should not have the capital ‘O’. My guess is that the second character of the key needs a tiny modification:

“SNowcapLithoLabyrinthPerquisiteArroyo” should be: “SnowcapLithoLabyrinthPerquisiteArroyo”

Let’s try!

./nsisdec.py --file burks.ujg --key "SnowcapLithoLabyrinthPerquisiteArroyo" --mode 2 > out.bin

Yes, now it looks fine:

00000000  61 5a 90 00 03 00 00 00  04 00 00 00 ff ff 00 00  |aZ..............|
00000010  b8 00 00 00 00 00 00 00  40 00 00 00 00 00 00 00  |........@.......|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 e8 00 00 00  |................|
00000040  0e 1f ba 0e 00 b4 09 cd  21 b8 01 4c cd 21 54 68  |........!..L.!Th|
00000050  69 73 20 70 72 6f 67 72  61 6d 20 63 61 6e 6e 6f  |is program canno|
00000060  74 20 62 65 20 72 75 6e  20 69 6e 20 44 4f 53 20  |t be run in DOS |
00000070  6d 6f 64 65 2e 0d 0d 0a  24 00 00 00 00 00 00 00  |mode....$.......|
00000080  ce b7 f2 b5 8a d6 9c e6  8a d6 9c e6 8a d6 9c e6  |................|
00000090  49 d9 93 e6 89 d6 9c e6  49 d9 c3 e6 8b d6 9c e6  |I.......I.......|
000000a0  49 d9 c1 e6 88 d6 9c e6  83 ae 1f e6 89 d6 9c e6  |I...............|
000000b0  83 ae 0f e6 a9 d6 9c e6  8a d6 9d e6 05 d7 9c e6  |................|
000000c0  91 4b 33 e6 de d6 9c e6  91 4b 01 e6 8b d6 9c e6  |.K3......K......|
000000d0  52 69 63 68 8a d6 9c e6  00 00 00 00 00 00 00 00  |Rich............|
000000e0  00 00 00 00 00 00 00 00  50 45 00 00 4c 01 04 00  |........PE..L...|

Let’s substitute the first character to make the valid header and preview the PE file:

preview

Headers looks good,  but the file is truncated. So, the file burks.ujg contains the first part of the payload – and burks.eey most probably contains the second part. Before the decoding, we should make a merge of both parts in a proper order. Then, we can execute the same script on the merged content:

./nsisdec.py --file merged.bin --key "SnowcapLithoLabyrinthPerquisiteArroyo" --mode 2 > out.bin

Just the first character to modify (‘a’ -> ‘M’) and we can view it again:
payload

Now the payload is complete and valid! Again it is Cerber ransomware – md5=ee927a4cdc1c82f3e9cde4298ea83211 (see also the extracted configuration file [here])

Ending note

The main task is done, but just to be precise let’s take a look at the remaining file: “Akmryote.vbk” and see if it’s structure/method of packing changed. We will use nsisdec.py in mode 1. Casual key for those files is their name (often truncated to some random length).

./nsisdec.py --file Akaryote.vbk --key "Akaryote.vbk" --mode 1 > out.bin

Output:

00000000  43 72 65 61 47 77 5e 47  61 2c 52 7a 79 41 0a 4e  |CreaGw^Ga,RzyA.N|
00000010  47 47 60 58 6f 3f 61 60  6f 77 4f 66 60 77 6d 41  |GG`Xo?a`owOf`wmA|
00000020  67 20 59 03 5c 69 72 74  46 73 62 74 62 23 58 6a  |g Y.\irtFsbtb#Xj|
00000030  4f 78 0a 56 5a 60 7a 40  6f 23 76 65 66 6f 63 0a  |Ox.VZ`z@o#vefoc.|

Beginning (first 4 characters) looks fine, but then the content started to be invalid. For sure key must be truncated (keylen <= 4). After few attempts we can see that the valid length is 3.

./nsisdec.py --file Akaryote.vbk --key "Akaryote.vbk" --mode 1 --maxkey 3 > out.bin
00000000  43 72 65 61 74 65 50 72  6f 63 65 73 73 41 0a 4e  |CreateProcessA.N|
00000010  74 55 6e 6d 61 70 56 69  65 77 4f 66 53 65 63 74  |tUnmapViewOfSect|
00000020  69 6f 6e 0a 56 69 72 74  75 61 6c 41 6c 6c 6f 63  |ion.VirtualAlloc|
00000030  45 78 0a 56 69 72 74 75  61 6c 41 6c 6c 6f 63 0a  |Ex.VirtualAlloc.|
00000040  57 72 69 74 65 50 72 6f  63 65 73 73 4d 65 6d 6f  |WriteProcessMemo|
00000050  72 79 0a 47 65 74 54 68  72 65 61 64 43 6f 6e 74  |ry.GetThreadCont|
00000060  65 78 74 0a 53 65 74 54  68 72 65 61 64 43 6f 6e  |ext.SetThreadCon|

Conclusion

There are various mutation of this packing technique – but many of them follow the same general idea. Sometimes we need to fiddle around a bit to find out the familiar patterns.

 

Posted in Malware, Tutorial | 2 Comments

Unpacking NSIS-based Crypter – step by step

Nowadays we can encounter many malware samples packed by a crypter using installer scripts. We can distinguish them by a NSIS tag on Virus Total:nsis_tag

Often, (but not always) they come with a standard NSIS icon:

icon

They may look difficult to unpack, but if you know how to approach them, it takes just few minutes…

Analyzed samples

  1. d0f6cfb56f9b23eedce0f2ac30233fd1
  2. 17fcd7a7162298225b06d85d1d5a90ea

Steps

  1. Decompress the package – you can use 7zip under Windows or a standard archive manager under Linux
  2. Find a DLL and the exported function, that will be used for unpacking. See the referenced strings – you will get names of the files that are opened.
  3. Find those files. One of them will be your searched payload (encrypted by a simple XOR-based algorithm)
  4. Try to find the key and the encryption algorithm (XOR based). In some cases, it is not a pure XOR, but usually you can figure out the modifications by looking at the output. In some (rare) cases, you will need to analyze the function in the DLL, that is used for unpacking, to find out the correct algorithm.

Details

1. Decompress

After decompressing the executable you will see two directories – one of them contains standard NSIS elements (just skip it, nothing to see here):

dir_nsis

The other directory contains the stuff of our interest. In the best case [1], no rubbish is added and we can easily see the  files containing valuable data:

dir_interesting

But often it looks like this [2] (junk files were added for the purpose of obfuscation), and we need to figure out which of the files contain the payload:

dir_interesting2

2. Find the DLL in this directory and see what it exports. Usually it is just one function, responsible for unpacking the payload. Pay attention on the function’s name and RVA of it’s code:

Example 1:

exports_1

The unpacking function is named: Orchil and its code starts at RVA 0x1000

Example 2:

exports2

The unpacking function is named: Simile and its code starts at RVA 0x106E.

Enter in the function (using your favorite debugger/disassembler) and see which of the files it uses (it is especially helpful if there are junk files stored in the same directory). Example – using OllyDbg:

function2

Example 1:

read_files1

Example 2:

read_files2

3. Find the referenced files in the same directory where the DLL is:

files2

Look at their sizes. The smaller one contains encrypted functions that are loaded and used during payload injection. The bigger one contains encrypted payload. Copy the payload file aside. (In the case 2 the payload file is Postfix.3 – in the case 1 – ShopDemise.RkT.

4. Try to crack the payload

This type of crypter may use a simple XOR as well as some more complex XOR-based algorithms. Start from checking the simplest cases. If the typical algorithms does not work, you will need to analyze the unpacking function from the DLL. I already did analysis of some popular variant (read more here) and prepared a helper script:  nsisdec.py

Sometimes it is also beneficial to see the visualization of the encrypted files, so that we can guess what type of the encryption to expect. Left – Postfix.3 right – ShopDemise.RkT. In both cases we can see some patterns, like padding, that can be inside the PE file. Both visualizations suggest weak encryption – but in case of Postfix.3 it seems to be simpler.

Example [2] – file: Postfix.3
For the simplest case – XOR the payload file with any valid PE file. This trick uses the fact that all the PE files have similar headers plus the property of XOR function (applying it twice reverse the effect) – so, if we see repeating patterns at the beginning, it may be the key.

For simple XOR you can use the script dexor.py – as well as nsisdec.py in a default, 0 mode.

./nsisdec.py --file Postfix.3 --keyfile IP.dll > out.bin

Output:

00000000  6e 6f 74 6f 6f 74 6f 6f  74 6f 6f 74 6f 6f 74 6f  |notootootootooto|
00000010  6f 74 6f 6f 74 6f 6f 74  6f 6f 74 6f 6f 74 6f 6f  |otootootootootoo|
00000020  74 6f 6f 74 6f 6f 74 6f  6f 74 6f 6f 74 6f 6f 74  |tootootootootoot|
00000030  6f 6f 74 6f 6f 74 6f 6f  74 6f 6f 74 57 6f 74 6f  |ootootootootWoto|
00000040  6f 74 6f 6f 74 6f 6f 74  6f 6f 74 6f 6f 74 6f 6f  |otootootootootoo|
00000050  74 6f 6f 74 6f 6f 74 6f  6f 74 6f 6f 74 6f 6f 74  |tootootootootoot|

Seeing this, we may suspect that the key is “oot” (first character of the file is modified).
Let’s try:

./nsisdec.py --file Postfix.3 --key "oot" > out.bin

Output:

00000000  4c 5a 90 00 03 00 00 00  04 00 00 00 ff ff 00 00  |LZ..............|
00000010  b8 00 00 00 00 00 00 00  40 00 00 00 00 00 00 00  |........@.......|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 e8 00 00 00  |................|
00000040  0e 1f ba 0e 00 b4 09 cd  21 b8 01 4c cd 21 54 68  |........!..L.!Th|
00000050  69 73 20 70 72 6f 67 72  61 6d 20 63 61 6e 6e 6f  |is program canno|
00000060  74 20 62 65 20 72 75 6e  20 69 6e 20 44 4f 53 20  |t be run in DOS |
00000070  6d 6f 64 65 2e 0d 0d 0a  24 00 00 00 00 00 00 00  |mode....$.......|

At the beginning we can see that the first character is invalid, but the rest of the file looks like a perfectly normal PE file. Let’s change the “LZ” to the valid “MZ” header…
So, indeed we got a valid PE file (it’s Cerber ransomware, you can see it here).

Example [1] , file: ShopDemise.RkT

In this case after the XOR operation we cannot see the familiar patterns. It means, this sample must be handled differently. We will try another common algorithm used by this type of crypter. But let’s try to find the key first. Usually it is hardcoded in the binary and not obfuscated. Seeing all the strings and checking in the code where they are used, we can suspect that the key for this file is: “CaratSerinIntermittency”

strings

Ok, let’s apply it along with another algorithm commonly used by this crypter (mode 2):

./nsisdec.py --file ShopDemise.RkT --key "CaratSerinIntermittency" --mode 2 > out2.bin

Output:

00000000  58 5a 90 00 03 00 00 00  04 00 00 00 ff ff 00 00  |XZ..............|
00000010  b8 00 00 00 00 00 00 00  40 00 00 00 00 00 00 00  |........@.......|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 e8 00 00 00  |................|
00000040  0e 1f ba 0e 00 b4 09 cd  21 b8 01 4c cd 21 54 68  |........!..L.!Th|
00000050  69 73 20 70 72 6f 67 72  61 6d 20 63 61 6e 6e 6f  |is program canno|
00000060  74 20 62 65 20 72 75 6e  20 69 6e 20 44 4f 53 20  |t be run in DOS |
00000070  6d 6f 64 65 2e 0d 0d 0a  24 00 00 00 00 00 00 00  |mode....$.......|

Again, we see a PE file with first character invalid. Let’s change the “XZ” to the valid “MZ” header… It works! Again we got a valid executable (in this case it is also Cerber, you can see it here).

Ending note

Ok, we unpacked the payloads  – and what was in the remaining files? You can uncover their content using their name as the key and the dedicated algorithm, that you can find in the same script (mode 1). Usual key length is 10. Example:

./nsisdec.py --file NardooDeposal.W --key NardooDeposal.W --maxkey 10 --mode 1 > out.bin

They contain functions that are going to be loaded, some junk for obfuscation and the code that is used for injecting payload to the remote process. Example (beginning of the decoded file):

00000000  43 72 65 61 74 65 50 72  6f 63 65 73 73 41 0a 4e  |CreateProcessA.N|
00000010  74 55 6e 6d 61 70 56 69  65 77 4f 66 53 65 63 74  |tUnmapViewOfSect|
00000020  69 6f 6e 0a 56 69 72 74  75 61 6c 41 6c 6c 6f 63  |ion.VirtualAlloc|
00000030  45 78 0a 56 69 72 74 75  61 6c 41 6c 6c 6f 63 0a  |Ex.VirtualAlloc.|
00000040  57 72 69 74 65 50 72 6f  63 65 73 73 4d 65 6d 6f  |WriteProcessMemo|
00000050  72 79 0a 47 65 74 54 68  72 65 61 64 43 6f 6e 74  |ry.GetThreadCont|
00000060  65 78 74 0a 53 65 74 54  68 72 65 61 64 43 6f 6e  |ext.SetThreadCon|
00000070  74 65 78 74 0a 52 65 73  75 6d 65 54 68 72 65 61  |text.ResumeThrea|
00000080  64 0a 47 65 74 46 69 6c  65 53 69 7a 65 0a 52 65  |d.GetFileSize.Re|
00000090  61 64 50 72 6f 63 65 73  73 4d 65 6d 6f 72 79 0a  |adProcessMemory.|
000000a0  6e 74 64 6c 6c 2e 64 6c  6c 0a 4c 6f 63 61 6c 41  |ntdll.dll.LocalA|
000000b0  6c 6c 6f 63 0a 53 6c 65  65 70 0a 47 65 74 4d 6f  |lloc.Sleep.GetMo|
000000c0  64 75 6c 65 46 69 6c 65  4e 61 6d 65 41 0a 47 65  |duleFileNameA.Ge|
000000d0  74 43 75 72 73 6f 72 50  6f 73 0a 4e 74 52 65 73  |tCursorPos.NtRes|
000000e0  75 6d 65 54 68 72 65 61  64 0a 75 73 65 72 33 32  |umeThread.user32|
000000f0  0a 6c 73 74 72 63 61 74  41 0a 45 78 69 74 50 72  |.lstrcatA.ExitPr|
00000100  6f 63 65 73 73 0a 47 65  74 43 6f 6d 6d 61 6e 64  |ocess.GetCommand|
00000110  4c 69 6e 65 41 73 77 65  61 74 69 6e 65 73 73 0a  |LineAsweatiness.|
00000120  6b 61 6e 73 0a 67 6f 6f  64 66 65 6c 6c 6f 77 73  |kans.goodfellows|
00000130  68 69 70 0a 69 73 61 74  69 6e 0a 66 75 6e 67 69  |hip.isatin.fungi|
00000140  62 6c 65 73 0a 63 61 72  74 6f 6e 70 69 65 72 72  |bles.cartonpierr|

That’s all!

Read also Part 2

Appendix

Helper script: https://github.com/hasherezade/malware_analysis/blob/master/nsisdec.py

Read also about manual unpacking of this crypter in my post written for Malwarebytes

http://nsis.sourceforge.net – NSIS homepage

Posted in Malware, Tutorial | 5 Comments

Decoders for 7ev3n ransomware

7ev3n is yet another ransomware about which I wrote some time ago (for Malwarebytes – you can read more here). It uses custom cryptography and I managed to decrypt several variants.  In this thread you can find my decryptors (and all the updates about them).

WARNING: 7ev3n ransomware has many variants. Check your ransom note and compare with the examples given below, in order to find what is your variant. Then, download appropriate decryptor. In case of any problems, feel free to contact me.

[Python scripts – PoCs]
[sourcecode of GUI versions – assembler]


A. For sample: 52517f419e78041f8e211428b8820dfb

DECODERS:

GUI version: [download executable]
Python version: seven_decoder1.py

This variant comes with NO ransom note.

In order to use this decryptor need to know the original path, where the file was stored when it got attacked by the 7ev3n ransomware. Example:

seven2


B. For sample: 08a53eb5d54c6829cf6ea29bd61ea161

DECODERS:

GUI version: [download executable]
Python version: seven_decoder2.py

In order  to use this decryptor you need to copy your unique ID from the ransom note – FILES_BACK.txt

Ransom note example:

hello, If you have Standart locker interface (green window) on desktop for decryption follow the instructions.
If you delete it, and want to decrypt your files you need decryptor, you can buy it by contact through email
contact email : JessMalibu@protonmail.com
reserve email : martingarrix@nonpartisan.com
your unique id : 73118178525283953643921210931031
6. If you want try to decrypt your files with software from anti-malware websites please make copies of this files
 once you understand that it's not working, you will still have clear copies of the files that be decrypted after payment

And paste it in the appropriate place in the GUI:

variant_b

youtube-512  see it in action: https://www.youtube.com/watch?v=RNZvsEMBfJs


C. For samples: 7e6af09baf19bc03c4a3b9078546a7c1, 5cce8bbe88dd6e95b8a89dd78a6b082e

This variant requires knowing the original path AND the Unique ID.

Ransom note example (FILES_BACK.txt):

hello, if standart cryptolocker interface was blocked or deleted by Antivirus or Firewall
and you want back your files, contact : backcontent@contractor.net
your unique id : 49b517551928275244272ca5da1f

DECODERS:

GUI version: [download executable]
Python version: seven_decoder3.py

seven_c

youtube-512  see it in action: https://www.youtube.com/watch?v=RDNbH5HDO1E

Posted in Malware, Malware Decryptor | Tagged , , | 21 Comments

Protected: Green Petya’s decryption algorithm

This content is password protected. To view it please enter your password below:

Posted in Malware