/

Malware deletes MBR , files and folders  from verisions newer than XP

Malware deletes MBR , files and folders from verisions newer than XP

[Total: 0    Average: 0/5]

 

Identification

MD5: 0a8032cd6b4a710b1771a080fa09fb87

SHA256: 510f83af3c41f9892040a8a80b4f3a4736eebee2ec4a7d4bfee63dbe44d7ecff

Detection ratio: 49 / 56 virus total.

Malware names:

 Win32:DarkSeoul-C

 Trojan.Win32.EraseMBR.b

 

Executive summary

This malware deletes the MBR from the hard drives connected to the system, and it deletes files and folders on windows versions newer than XP.

The malware doesn’t modify registry to achieve persistence as the infected machine won’t survive the next reboot.

There are no network actives.

 

Static analysis

The sample imports only two dlls (kernel32, ntdll) these are mandatory libraries which are loaded by most of the executables and doesn’t give a hint about the functionality of the sample.

But kernel32 library contains functions that allow any executable to load libraries not in the import table, these functions are (LoadLibrary , GetProcAddress )simply the technique works as follow :

 

  1. First the executable sends the name of the required library as an argument to LoadLibrary function which returns a handle to the loaded module if it succeeded.
  1. When the library is successfully loaded in memory the executable then calls GetProcAddress function with the required function in the loaded library and the module handle as arguments.
  1. Then the executable can call the function using the address which was returned by GetProcAddress function.

This technique is used to hide the functionality of the malware, as it cannot be seen during static analysis, especially if the names of the library and the function are obfuscated or encrypted.

 

Dynamic analysis

The code starts with unusual non malicious code-the third instruction calls the fourths instruction and the address saved by the call function which is the address of the fourth instruction is put in EAX.

The code then enters a loop to calculate some addresses and store them in the memory (calculating the addresses at runtime hides information from static analysis as the addresses called are not known until the sample is running).

The sample calculates 27 addresses and are stores them in memory starting from memory location 004026CC.

The code then calls one of the 27 addresses (004023A0).

60

This function access the FS segment register to reach the TEB.

TEB is the thread environment block which contains information about the current running thread.

The structure of the TEB is not documented by Microsoft, nevertheless the information we need is available online [http://www.nirsoft.net/kernel_struct/vista/TEB.html].

The function accesses offset 0x30 in the TEB, so we need to know what is at this offset

 

 The first member is a struct (NT_TIB).

o This struct contains 6 pointers (every data type starts with P is a pointer).
o Pointers in 32 bit executables have size of 4 bytes.
o It also contains a union, unions allocate the biggest size of its members, it contains an unsigned long and a pointer both of size 4 bytes.
o so the total size of NT_TIB struct is 7 * 4 = 28 bytes

 Then there is another 5 pointers (two inside CLIENT_ID structure) of size 5*4 = 20 bytes.

 20+28 = 48 bytes (0x30).

 So the offset 0x30 in the TEB is the Peb according to the unofficial documentation.

The function then accesses the offset 0x0C in the PEB structure (documentation of the structure can be found here)

 

The member at offset 0x0C is PPEB_LDR_DATA, a pointer to PEB_LDR_DATA structure
Then offset 0x14 in the PEB_LDR_DATA which is a pointer to InMemoryOrderModuleList which is a linked list of LDR_DATA_TABLE_ENTRY elements.

Offset 28 in this structure is not documented but it seems that it gets the name of the loaded module.

Then there is a loop that processes the module name to calculate a hash value that is compared with a hardcoded value after the loop.

The member at offset 0x0C is PPEB_LDR_DATA, a pointer to PEB_LDR_DATA structure

Then offset 0x14 in the PEB_LDR_DATA which is a pointer to InMemoryOrderModuleList which is a linked list of LDR_DATA_TABLE_ENTRY elements.
Offset 28 in this structure is not documented but it seems that it gets the name of the loaded module.

Then there is a loop that processes the module name to calculate a hash value that is compared with a hardcoded value after the loop.
This loop will search for the entry point of kernel32.dll (the calculated value matches the hardcode value) and then the function will return this address.
Then the function at 0x004023DD is called twice, to find the address of LoadLibraryA , GetProcAddss functions.

 

Then it will load dlls using the LoadLibraryA function, and find the addresses of the following functions using the function at 0x004023DD:

1. advapi32.OpenProcessToken
2. advapi32.LookupPrivilegeValueA
3. advapi32.AdjustTokenPrivileges
4. kernel32.OpenFileMappingA
5. kernel32.CreateFileMappingA
6. kernel32.GetWindowsDirectoryA
7. kernel32.InitializeCriticalSection
8. kernel32.CreateThread
9. kernel32.WaitForSingleObject
10. ntdll.RtlLeaveCriticalSection
11. kernel32.GetVersionExA
12. kernel32.Sleep
13. kernel32.GetDriveTypeA
14. ntdll.RtlEnterCriticalSection
15. kernel32.FindFirstFileA
16. kernel32.RemoveDirectoryA
17. kernel32.FindNextFileA
18. kernel32.FindClose
19. kernel32.CreateFileA
20. kernel32.WriteFile
21. kernel32.CloseHandle
22. kernel32.DeleteFileA
23. kernel32.SetFilePointer
24. kernel32.GetSystemDirectoryA
25. kernel32.GetDiskFreeSpaceA
26. kernel32.GetDiskFreeSpaceExA
27. kernel32.ReadFile
28. kernel32.WinExec
29. kernel32.GetCurrentProcess
30. ntdll.RtlGetLastWin32Error
31. kernel32.LoadLibraryA
32. kernel32.GetProcAddress

Then loads msvcrt.dll

1. msvcrt.strcat
2. msvcrt.memset
3. msvcrt.strcpy
4. msvcrt.memcpy
5. msvcrt.strlen
6. msvcrt.sprintf
7. msvcrt.strcmp
8. msvcrt.malloc
9. msvcrt.free

Then user32.dll
user32.ExitWindowsEx

 

The function starting at 0x004011BC tries to open a file mapping object named “JO840112-CRAS8468-11150923-PCI8273V”, if it is found the malware will exit.
If it didn’t find the file mapping object, it will create one.
Then the malware will send the following commands to kernel32.WinExec in order to be executed on the system

a. taskkill /F /IM pasvc.exe , which belongs to http://us.ahnlab.com/
b. taskkill /F /IM clisvc.exe , which belongs to ViRobot ISMS from HAURI
The function call at 00401242, checks the version of the windows system if it is older than windows vista (windows XP or windows 2003 or older) the malware will create a thread that starts execution at 0x00401AA0 otherwise it will start execution at 0x004012D5.

 

61

On windows XP.
Function call at 00401d85 clears a buffer of size 0x104 bytes and the stores the string “\\.\PhysicalDrive0 ” in the buffer.
then opens the file \\.\PhysicalDrive0 and uses kernel32.SetFilePointer function to point to the start of the drive,it then reads 512 bytes to a buffer in the heap and the it uses setFilePointer() to advance the file pointer by 0x7000 bytes.

Then it starts writing 512 bytes of the word “PR!NCPESP” ,and then sets the file pointer to the beginning of the physical drive and writes again 512 bytes of the word “PR!NCPESP”.

It loops to do the same on PhysicalDrive 1 to 9
The malware will sleep for 5 minutes and then will shut down the operating system for the last time.

On operating systems newer than windows XP, -Windows 7 for example- the malware creates another thread after destroying the MBR this thread is responsible for deleting files and folders on the hard drive
This thread works as follows:

1. it will loop to check all drives from B:\ to Y:\ if it is the drive exists, it will perform another check to see if it is the drive that contains the operating system or not.

a. If it contains the operating system then it will store the drive path for usage after the current loop.

b. If it is not the drive of the operating system it will process the drive in the loop.

2. The processing of the valid drives is the same for the drive that contains the operating system and the other valid drives, the only difference is that the malware will create a new thread for every valid drive and will process the drive that contains the operating system on the current thread.

3. The processing done on drives (function at address 0x004015ED) is that the malware will traverse the folders in the drives, using findNextFile() method and appends *.* to the current directory path.

4. It overwrites the content of every file with the word “PR!NCPESP” multiple times , and then deletes the file ,making file recovery impossible.

5. It avoids deleting files in c:/program files, c:/program data, and c:/windows.

6. it will create a thread for deep paths (3 nested folders )

After five minutes of the malware will shut down the PC using the following methods:

1. kernel32.WinExec(“shutdown -r -t 0”)
2. user32.ExitWindowsEX()

 

About The Author

ss

 

 

 

 

 

 

 

AbdelRahman Hesham, ITI Cyber Security Student.

Leave a Reply

Your email address will not be published. Required fields are marked *