Seeping through cracks in Security

BLOG

Security & Reverse Engineering

Practical Malware Analysis - Lab 11-3

Lab 11-3 Setup:


While the executables in Practical Malware Analysis are considered safe, best practice will be used for the environment. This means the virtual machines will be ran without a network connection. The malware used in this lab can be found here: https://practicalmalwareanalysis.com/labs/

Virtual Machine Specifications:

  • Windows XP Service Pack 3 (32 Bit) - Ran windows updates
  • 20 GB HDD
  • 2GB Ram

Malware Analyzed

  • lab11-03.exe
  • Lab11-03.dll

The labs in Practical Malware Analysis were developed for study on Windows XP. All analysis will be performed on the lab VM

 

PMAImage.jpg

Guiding Questions

  1. What interesting analysis leads can you discover using basic static analysis?
  2. What happens when you run this malware?
  3. How does Lab11-03.exe persistently install Lab11-03.dll
  4. Which Windows system file does the malware infect?
  5. What does Lab11-03.dll do?
  6. Where does the malware store the data it collects?

Basic Static Analysis


 PEiD Output of Lab11-03.exe

PEiD Output of Lab11-03.exe

Checking if the malware is packed or obfuscated

As seen in the image to the left, after loading the executable into PEiD, it was found that the executable was not packaged or obfuscated. The Entropy of the file is 4.97.

As a result, it is possible to continue forward to analyze both the .dll and .exe files in Strings.

 

 

 

Strings Analysis

After running a strings analysis on both the Lab11-03.exe and Lab11-03.dll, clues to what their functions are were gathered.

Starting with the Lab11-03.dll seen to the right in Strings Output 1 & 2, the first thing that is interesting is all of the date and time strings along with sleep, WriteFile, GetWindowTextA, KERNAL32.dll, USER32.dll. These together hint that something may be scheduled to pull information from a window and write it to a file.

In Strings Output 3 & 4, it can be seen that there are more functions for writing and saving files as well as interacting with the windows environment. Strings related to memory and mutexes were also discovered.

Strings Output 5 & 6 are the results of running the string on the executable file lab11-03.exe. There are more strings relating to the windows environment as well as strings relating to opening, editing, and saving files. Strings relating to comparison are also apparent.

In Strings output 6, information on what system files may be affected are seen. cisvc.exe is mentioned as well as a command to start it. C:\WINDOWS\System32\inet_epar32.dll is seen and so is the Lab11-03.dll. The command net start cisvc is likely important as well as it appears to be a command that will start a service relating to the malware.

Overall, looking at the strings from both the executable and the .dll file, it appears that it is pulling information from the windows environment and saving the information to a file. This could indicate that the malware seen in Lab11-03 is a keylogger. The executable has strings that relate to comparison and writing as well as .dll files that may be used or hijacked by the malware. Based on the guiding questions, it is likely they will be used for editing registry keys / system files to make the malware persistent.

 

Advanced Static Analysis (IDA)


Lab11-03.exe IDA Analysis

When opening Lab11-03.exe in IDA and taking a look at the main function, several interesting actions appear almost immediately.

NewFileName is pushed to the stack containing the name: C:\\WINDOWS\System32\inet_epar32.dll and then ExistingFileName of Lab11-03.dll is pushed to the stack as well. Then the malware calls the function CopyFileA to use theses values stored in the stack to copy them. It appears that the malware immediately changes the Lab11-03.dll into inet_epar32.dll to attempt to blend in as a normal system file.

After this is completed, the malware pushes offset aCisvc_exe and C:\\WINDOWS\\System32\\% to the stack before calling function _sprintf. It appears that this is creating a file in System32 called cisvc.exe and then writing to it once sub 401070 is called.

Diving into this subroutine results in a lot of confusing code. While it is above my skills in deciphering assembly, based on the function calls and keys, it is possible to infer what may be happening.

Seen to the right in Sub 401070 Part 1 to the right, function calls CreateFileA, GetFileSize, and CreateFileMappingA are seen. This is pretty straight forward that the subroutine is being used to create a file and map it.

In Part 2, the function ViewMappedofFile is called and then the subroutine branches out into several comparisons and jumps seen in Part 2 and 3. While this is a bit confusing, later in part 4, functions CloseHandle and UnmapViewOfFile are called.

What is likely happening, based on the actions before following the subroutine in main, the Lab11-03.exe is creating a service called cisvc.exe to run and then use the Lab11-03.dll's imports disguised as inet_epart32.dll to avoid suspicion.

 

Lab11-03.dll IDA Analysis

Diving into the Lab11-03.dll, there is not much going on initially in the main function that grabs attention. However, when searching for some of the strings found during the string analysis, more starts to become clear.

Searching for the string CreateFileA immediately returned an interesting result as seen to the right. It shows that the dll creates a file named kernel64x.dll located in the System32 folder. Then it sets the pointer using SetFilePointer before calling sub_10001380.

Following sub_10001380 through its calls lead to loop that includes Sleep as well as WriteFile as seen to the right in "Write File / Sleep".

Examining this loop closer, we see a call to sub_10001030. When investigating this further, we see another loop that includes the functions GetAsychKeyState with the included comment "Determine whether a key is up or down". 

Overall, after examing the subroutines and their contained function, it appears this .dll creates a file in system32 and then acts as a keylogger recording key presses to that file in a loop. This supports the initial suspicion after the strings analysis.

 

 

 

Dynamic Analysis


When running the malware, several actions are observed in Process Monitor.

The Lab11-03.exe creates the inet_epar.dll as well as the cisvc.exe as expected. This can be seen in the screenshots to the right. These files were both found when looking in the the System32 folder as well. However, for some reason the malware was unable to create a file kernel64.dll where it would have been logging keystrokes.

Digging deeper into process monitor to figure out why it could not execute, the results were filtered by Lab11-03.exe and then by cmd.exe. Since it was known from the static analysis that the system should attempt to start the key logger by using /c net start cisvc.exe. When looking for this, process monitor does say it was successful, however there is no evidence of the command returning as successful as cisvc.exe did not start, nor create a file kernel64.dll

Reverting the snapshot of the VM back to its original start resulted in the same outcome. It is possible that since the VM is patched to the most recent version, the malware written for the book may not work. It would be possible to attempt to run the keylogger on fresh version of Windows XP SP1 to see if an update in between when the book was released and when patching occurred maybe causing an issue.

Conclusion & Summary


Overall, Lab11-03.exe and Lab11-03.dll worked together. When executed Lab11-03.exe would copy Lab11-03.dll into a new file called inet_epar32.dll and it would be used to create cisvc.exe. Once this process ran, it would act as a keylogger in order to log the user's keystrokes to a file kernel64x.dll in the user's System32 folder.

Reverse engineering the executable and the .dll file resulted in a rewarding manner. However, the dynamic analysis fell short when the cisvc.exe failed to launch, thus failing to launch the keylogger. With Lab11-03 as well as the previous Lab11-01 both failing the dynamic analysis, the environment the malware is being tested in should be examined. It's hypothesized that the most recent service pack may be at fault, or another error is present. This is will be reexamined for Lab 13.