cd ../reverse_engineering_malware


8 minutes read

SHA256 of sample.exe: 98199294da32f418964fde49d623aadb795d783640b208b9dd9ad08dcac55fd5

Today I’m trying to analyze #CoinMiner, the sample is very interesting because it injects 64-bit process from a 32-bit process, also uses some anti-disassemble and anti-RE techniques.

You can download the sample from hybrid-analysis.

Let’s open in VM, after executing it creates folder under %LOCALAPPDATA% and writes an executable inside it, uses RunOnce reg key as persistence method, creates notepad.exe process with following arguments: -a cryptonight -o stratum+tcp:// -u 4JUdGzvrMFDWrUUwY3toJATSeNwjn54LkCnKBPRzDuhzi5vSepHfUckJNxRL2gjkNrSqtCoRUrEDAgRwsQvVCjZbS3d2ZdUYfaKLkAbBLe -p x -t 2.

(click here to view larger version)

Seem like it copies itself to %LOCALAPPDATA% folder, executes notepad.exe with arguments and injects some third-party code. That’s interesting, the malware itself is 32-bit and notepad.exe under the 64-bit system is 64-bit.

Let’s dive in deep.

At the beginning it decrypts embedded PE file, using the following routine:


byte_882040 points to 4JUdGzvrMFDWrUUwY3toJATSeNwjn54LkCnKBPRzDuhzi5vSepHfUckJNxRL2gjkN.

After decryption, it patches decrypted PE file:


Decompiled version:

(click here to view a larger version)

After this, it manually maps decrypted PE file into the memory of the current process and jumps into it with call instruction.:


It allocates space, copies headers and sections, corrects import table and relocation table:


(click here to view a larger version)

Start analyzing of sample2.exe which is extracted from sample.exe.

We can extract decrypted file after patching.

SHA256 of decrypted PE sample2.exe: f558e28553c70a0c3926c8c77e91c699baa3491922ab9cdfb29aa995138d5a08

You can download the file from hybrid-analysis.

From the beginning of the executable, we see patched strings from the previous executable:


Identfies %LOCALAPPDATA% folder using SHGetKnownFolderPath system call:


(click here to view larger version)

It allocates a buffer, writes data into it from the file and writes data from the buffer into newly created file under %LOCALAPPDATA%


(click here to view larger version)

Deletes Zone.Identifier of the file:


According to MSDN it’s stream name and used to identify file downloaded from the internet, 3 is internet zone, for more information about ADS visit MSDN.


Constructs command line arguments and starts searching for a program to inject:


Based on IsWow64Process call it chooses notepad.exe or explorer.exe on x64 systems and wuapp.exe or svchost.exe on x32 systems:


(click here to view a larger version)

On my x64 Windows 10 there is notepad.exe under C:\Windows and it chooses notepad.exe to inject.

It chooses to inject a 32-bit process or a 64-bit one based on IsWow64Process:


Injecting into 32-bit process it relatively straightforward, there are our old friends GetThreadContext, ReadProcessMemory, WriteProcessMemory, SetThreadContext and ResumeThread, it’s a typical process hollowing:


(click here to view larger version)

But my system is 64-bit, so it chooses to inject into the 64-bit process.

Checks if there is taskmgr.exe process and loops until closing it:


It creates notepad.exe process with arguments:


(click here to view larger version)

It calls getNtdll (I renamed it), but there is an anti-disassemble technique known as Return Pointer Abuse and even IDA pro can not identify functions bounders correctly, we should change this using ALT+P and set correct end address of the function.


After correcting bounders and patching call $+5; mov; retf; instructions, which are just jumping to next addresses, at some point it checks modules and gets an address of ntdll.dll, this is 64-bit dll loaded by notepad.exe. ESI:EDI contains the address of ntdll.dll, to prove this we can use vmmap:


(click here to view larger version)

It uses getFunction (I renamed it) to get addresses of functions exported by ntdll.dll:


Inside that function it uses LdrProcedureAddress call to get address of desire function, it passes LdrProcedureAddress to call_ebp_8 function:


call_ebp_8 calls function at first and second parameters (first:second), also all required parameters are pushed. this way it calls functions exported by ntdll.dll. In this case call_ebp_8 calls LdrProcedureAddress and gets address of requested function:


The malware uses getNtdll to get address of 64-bit ntdll.dll, call_ebp_8 to call functions exported by ntdll.dll and getFunction to get addresses of desire function from ntdll.dll, getFunction uses call_ebp_8 with LdrProcedureCall as a function argument.


Using this functions it calls NtGetContextThread, NtReadVirtualMemory, NtAllocateVirtualMemory, NtWriteVirtualMemory and ResumeThread, as we know this functions are essential for process hollowing. After setting of CONTEXT it resumes thread:


Everything this happens in a loop, if we close notepad.exe process it creates one again.

We can easily extract 32-bit and 64-bit PE files, which are injected into a target process. We can extract it before calling to NtWriteVirtualMemory:


Both 32-bit and 64-bit versions are packed using UPX. After unpacking it, we can disassemble it:


It’s cpuminer: A CPU miner for Litecoin, Bitcoin, and other cryptocurrencies, the application to use CPU power to compute hashes and "mine" cryptocurrency:


The malware uses following arguments: -a cryptonight -o stratum+tcp:// -u 4JUdGzvrMFDWrUUwY3toJATSeNwjn54LkCnKBPRzDuhzi5vSepHfUckJNxRL2gjkNrSqtCoRUrEDAgRwsQvVCjZbS3d2ZdUYfaKLkAbBLe -p x -t 2

-a - specify the algorithm to use.

-o - URL of mining server.

-u - username.

-p - password.

-t - number of miner threads.

The malware heavily uses anti-RE techniques which make analysis harder.

I know, I overlook many things related to the malware, due to my limited knowledge, if you find something interesting please contact me.

I’m new to reversing malware and any kind of feedback is helpful for me..

Twitter: @_qaz_qaz