PMA - CH 7-3
Analysis of Lab07-03.exe and Lab07-03.dll
Last updated
Analysis of Lab07-03.exe and Lab07-03.dll
Last updated
Looking at Lab7-3.exe in PEStudio we see some interesting strings/functions being called:
Looking at the strings we can see Kernel32.dll and what appears to be a fake kernel32 (spelled with a 1 kerne132.dll). Looking at the functions we can assume that this program will be looking through our file directory listing.
Looking at our DLL (Lab7-03.dll) in PEStudio we see:
Looking at the functions called we can assume that it will be reaching out over sockets using ws2_32.dll. The strings only reassure our guess we can see an IP address. We can see that a Mutex is going to be created or checked before execution (make sure there is only one sample running on the system)
Looking at DLL main the first function call is OpenMutexA and CreateMutexA
We can see the string "SADFHUHF" being pushed onto the stack before each call to CreateMutex and OpenMutex. After the Mutex check, it calls WSAStartup to initialize the use of Winsock.
The DLL then calls socket, reviewing MSDN, The relevant two parameters is our address family, in this case, the value 2 which is AFINET (IPv4 address family). Our second parameter specifies the type of socket in this case our value 1 is equal to SOCK_STREAM (TCP).
Following is a call to inet_addr which converts a string IP address into an IPv4 dotted address. Then we see 50h being pushed which is 80 (port 80). Finally, a call to connect which its first parameters hold the socket information in ESI.
The file now calls send to our socket information with the buffer "hello". Following a call to shut down which disables sends on our socket. We then call recv which reads incoming data.
We then begin a loop sequence comparing two strings "sleep" and "exec" if sleep is passed the program waits and compares a string again. If exec is passed the DLL calls CreateProcessA, which after it begins all over. (COME BACK AND REVIEW!!!)
Looking at the EXE file we can see it is much more complicated than the DLL file. I am going to focus on the function calls and will leave the rest for dynamic analysis.
Looking at main we can see a command line check for 2 parameters the loop is comparing ESI and EAX
We next see calls to CreateFileA, CreateFileMappingA, and MapViewOfFile called twice the first is being called on kernel32.dll and the other file is Lab7-03.dll. Which maps the entire file into memory space and the program can read or write the file without any more function calls.
The malware then proceeds to make a lot of complicated move instructions while also calling two different functions sub_401040 and sub401070. Both of these functions are relatively small and only call sub_401000, which again doesn't call any functions. I am going to skip these functions as analyzing them would take too long and is much too complicated for me.
Moving right along, we don't see any more function calls until the end of the program. It makes two calls to CloseHandle and looking at the parameters passed we can see that they are the handles to the files that were opened previously by CreateFileA.
The next function call is CopyFileA and the two parameters pushed are "C:\Windows\System32\kerne132.dll" and "Lab7-03.dll". Lab7-03 is being copied into a new file called "kerne132.dll" made to look like kernel32.dll.
Before we move on let's recap. The program opens two files and maps them into memory kernel32.dll and Lab7-03.dll, we can assume that something is happening to these files while there in memory. We will come back and find out during dynamic analysis. After the calls to CloseHandle we know that the malware is finished editing those files.
After CopyFile we see the malware push the string C:\\* before calling sub4011E0 which I have renamed searching_drive (soon find out why). Entering this call we see a call to FindFirstFile which we can assume this malware is searching through the C drive
Following are more complicated comparisons that I will leave for later. The first call we see is to sub_4011E0 which calls itself. The next function call is stricmp which compares two strings we can see that one of the parameters is ".exe". We can now assume that the malware is recursively searching the C drive for executable files.
Next, the malware calls sub_4010A0, however, if we finish looking at this function we can see it will call FindNextFile and then make an unconditional jump and loopback.
Looking at the calls within sub_4010A0 we can see CreateFile, CreateFileMapping, and MapViewOfFile (which we know already will map the entire file into memory). The program then calls IsBadReadPtr which I had to look at MSDN and it basically just verifies if a pointer is valid. Next, it calls stricmp again this time passing kerenl32.dll as one of the arguments. At this point, I was unsure what was actually happening to the file that was being mapped into memory and had to refer to the handy dandy lab guide. But before we do let's recap what we know! Function 4011E0 recursively searches our C drive for executable files once found it calls function 4010A0 which will map the exe into memory.
Looking at the lab guide it states that the assembly instructions repne scasb (scans a string and compares it to the current value pointed to by EDI) and rep movsd (copies data from ESI to EDI) are functionally equivalent to strlen and memcpy (something I did not know). EBX is loaded with the value that is passed to stricmp. With this knowledge let's take a look at the code again to see if we can figure out what's going on. We can see that the string kerne132.dll is passed into ESI and we now know that rep movsd copies data from ESI into EDI.
We can determine that the malware copies kerne132.dll and replaces kernel32.dll. Once again recapping...we know that function 4011E0 recursively searches our C drive for executable files once found it calls function 4010A0 which will map the exe into memory and replaces the string kernel32.dll with kerne132.dll.
Now we now can go back and fill in the gaps that we missed. Starting at main we can see the comparison check for the string "WARNINGTHISWILLDESTORYYOUR_MACHINE". which is stored in EAX and is being compared against ESI. It will compare two characters and then loop.
Next, the malware will open two files kernel32.dll and Lab07-03.dll into memory and we can verify this by looking at the memory map in xdbg.
We can now determine what the malware is doing to these files. After all the comparisons we can that Lab07-03.dll now appears to have all exports of kernel32.dll.
We can also confirm that the malware creates a file keren132.dll
We then move on to sub40111E0 which is searching through our C directory for the extension ".exe" we can see the malware store the value of the extension into EBX. Which is being pushed to stricmp call. Once found we go into sub4010A0
After running the malware we can confirm that the malware searches through the C drive for executable files. If we look at the imports on a file we can see kerne132.dll instead of kernel32.dll. Checking kernel32.dll MD5 before and after and we can see that the malware did not touch kernel32.dll. However, looking at our kerne132.dll we can now see that the export section is filled with all the exports that you would find in kernel32.dll. This means the overall effect will be the same besides DLLMain which will launch the remote connection.
Michael Sikorski and Andrew Honig. Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software (Kindle Locations 4944-4949). No Starch Press.
