As I was looking out for new malwares appearing online, i saw another PE32 executable malware and just decided to check it out, this malware was actually pretty simple. The purpose of the malware is use as much resource (RAM, CPU) as possible by copying itself and creating new process of itself. But honestly it was good malware to help me improve myself.
Simple demonstration of malware's capability:
By just looking at it, it is obvious what type of API calls are made: NtReadFile NtCreateFile NtWriteFile CreateProcessW
When uploading malware to DIE (detect it easy), it shows .text section is packed or compressed. Which is not really our problem because the dangerous part of malware starts at 0x00429EA6. I wouldn't look at each assembly instruction starting from that address, but at 0x0042A34F things get a little bit interesting.
This part writes full path name of malware to data and moves data address to eax, result will be something like that:
as you can see x32dbg shows what eax points to at the moment.
In this malware, internal functions within the VBA runtime environment have been called, which sadly didn't help me a lot, I couldn't get information about some functions like this one:
But one thing I know about this function is, it actually calls NtReadFile, which will copy our malicious binary into heap: (First 4 bytes are file's handle which was returned by NtOpenFile but I didn't specify it, as it didn't matter a lot)
As you can see in stack, data will be copied to 0x55C1B0:
Later, the malware will create a full name for copying itself into that binary, which I didn't go deep into the creation process but that's how it looks:
C:\\Users\\eyes\\Desktop\\Malware\\Unicorn-17737.exe
The part we have to check right now is: 0x0042A5DB-0x0042A614. Why? Because this is the part where data will be written into the "full path name" malware created:
We have a __vbaPutOwner3 function which will call NtWriteFile, it makes sense as __vbaGetOwner3 called NtReadFile.
File handle is 0x210 it was created when NtOpenFile was called (didn't specify it), Offset is 0x0 Size is 0x75005 (which is whole binary size) and 0x5DC1B0 is heap address where data resides.
Now one last thing is left, CreateProcessW, The call starts from 0x0042A614 to rtcShell which later Creates process.
The address is "string data" address of new created binary's full name:
And that's it, it will create new process and that process will create new one, it will continue forever.