Malware Analysis [#3]— Disk Writer
In this article I tried to analyze this malware sample that I took from Malware Bazaar with Linux machine, but eventually I needed to use windows machine for debugging and disk analysis, so let’s begin.
Sample:
- MD5:95bfd387a4105a2e940f3c50c5aa1069
- SHA256:df81fe69de455d1aeceb00e4cd4702d94edf9ab917dede008b65d0f045d75baf
General Info:
Analyzing a windows malware sample on Linux machine statically, we could use many tools to get information about the sample like pefile, strings, file …etc, or we could use Cutter to analyze the sample and that what I used here.
In the pictures below is general information about the sample:
From the strings of the sample we can see something interesting which is “\\\\.\\PHYSICALDRIVE0” and “MBR”. The first one used to get a handle of the hard drive with “CreateFile” API function, the second one is the short of “Master Boot Record” which located in the first sector of the hard drive which is responsible of pointing to where the code of the operating system is located, and has information about the partitions in the drive, also from this few lines we can expect that this sample going to get a handle to the hard drive, read the “MBR”, and write “MBR” record , so we are working with a drive writer.
In the Disassembler:
The disassembler put us at the entry point of the sample but it’s not where the malware functionality begins so first thing to look for is the main function. When analyzing C/C++ software/Malware and you start at entry point where initialization start, most of the time we do not care about what is happening there and immediately look for the main function and most of the time you will find a function with 3 pushes before calling it and they represent “argc”, “argv” and “envp” which mean environment variables:
Into the main function we find only one call to a function:
So following the call to the function we see that the first thing it’s calling is “CreateFileA” function with parameters :
- lpFileName: PHYSICALDRIVE0.
- dwDesiredAccess: (0xc).
- dwShareMode: (FILE_SHARE_READ | FILE_SHARE_WRITE).
- lpSecurityAttributes: (NULL).
- dwCreationDesposition: (OPEN_EXISTING).
- dwFlagsAndAttributes: (NULL).
- hTemplateFile: (NULL).
and if the function failed it pushes a string to a function to print it out and get last error and exit. But if the function succeed it Continues the execution to the next function which is “SetFilePointer” :
What SetFilePointer function do is moving the file pointer of the specified file, and here it takes a handle to the hard drive and the rest of parameters are(0). If the function succeed, it calls ReadFile function:
As it appear in the screenshot above the “ReadFile” function takes “nNumberOfBytesToRead” parameter 0x200 in hex and this represent the size of the “MBR” which is 512 bytes. If one of the functions failed it will push the string “read_mbr_Failed” and close the handle and exit, otherwise it will move 128 “dword” bytes which means 512 bytes from the buffer that received the data read from “MBR” to a new buffer to compare it with bytes from “.data” section from the malware sample and if they were equal it will push the string “already_infected” to be printed, and if at any point the comparison was not equal it will continue and prepare writing the “MBR”:
From the screenshot above we can see the hexdump that is compared with “MBR” of the drive, and as I mentioned if it was not equal it will start writing this to the “MBR”, also I would like to mention a digital forensics note here which is the last two bytes (55, aa) in above screenshot, they represent the end signature of the sector.
After that it start simple xoring the original “MBR” with a value from “0x442260” address in a loop until it’s less than 200 hex (512 bytes):
Then it moves the file pointer to the beginning of the third sector and write the original “MBR” if it fails it will push string “write_backup_mbr_failed” to be printed then call “CloseHandle” and exit, otherwise it will push string “Write_original_mbr” to be print out then call “CloseHanle” then push string “Write_mbr_OK” to be printed also :
In the Debugger:
We can see the malware after getting a handle to the physical drive and set a pointer to the beginning of the drive, it reads the first sector of it as it appear in the screenshot below, the left from WinHex and the right from x64dbg:
Then it write the first sector with the new data from “.data” section as it appear in the next screenshot from WinHex:
After that it start to obfuscate the original “MBR” by xoring it with “CDCDCDCDCDCDCDCDCDCDCDCDCDCDCDCD” and then write it in the third sector, and print out messages of success:
When restarting the machine we will be presented with a black screen and a red text asking us for putting a password to unlock the machine and when putting any password we will get a message saying that password is not right :
Fixing this is just simple taking the obfuscated “MBR” xor it with the value “CDCDCDCDCDCDCDCDCDCDCDCDCDCDCDCD” remove the malware MBR write the deobfuscated “MBR” back and everything should work normally.
