Practical Malware Analysis - Chapter 7 Lab Write-up

Chapter 7. Analyzing Malicious Windows Programs

Lab 7-1

Analyze the malware found in the file Lab07-01.exe.

Question 1

How does this program ensure that it continues running (achieves persistence) when the computer is restarted?

Answer 1

By examining the main function of this program, we can see reference to a service name ‘MalService’, a call to start the Service Control Dispatcher with the service control function sub_401040, and an associated call to a subroutine.

Within this subroutine we can see references to opening the Service Control Manager (SC Manager) and evidence of a service creation which will be used for persistence.

Question 2

Why does this program use a mutex?

Answer 2

The program uses a mutex to enmsure that only one instance of the program is running at any one time. The program attempts to get a handle on the mutex ‘HGL345’, and if it succeeds the program will terminate. If not, it will create a Mutex with this name.

Question 3

What is a good host-based signature to use for detecting this program?

Answer 3

Detection of this program can be done by checking any host for the hardcoded mutex ‘HGL345’ or by checking them for any service with the hardcoded name ‘MalService’.

Question 4

What is a good network-based signature for detecting this malware?

Answer 4

By examining the looping function of this program, we can see that it uses the User Agent “Internet Explorer 8.0” and communicates with the URL “http://www.malwareanalysisbook.com” which are network-based indicators which can be used to identify execution of this program.

Question 5

What is the purpose of this program?

Answer 5

By examining the program’s execution after creating a service for persistence, we can see that it sets up a timer checking for when the year is 2100 (834h), or midnight on January 1st 2100. At this time it will create 20 (14h) threads and with them execute the subroutine pointed to by ‘StartAddress’.

This routine attempts to open the URL http://www.malwareanalysisbook.com which leads us to believe that this is some sort of Denial of Service (DoS) program, which when multiple machines have this setup will cause a DDoS against http://www.malwareanalysisbook.com

Question 6

When will this program finish executing?

Answer 6

Looking back at the looping function mentioned previously, this function has no compare statement, and is an unconditional jump statement which runs the routine again. Based on this the program will never finish executing.

Lab 7-2

Analyze the malware found in the file Lab07-02.exe.

Question 1

How does this program achieve persistence?

Answer 1

When examining the program, we can’t see any evidence of persistence being created. The program shows no evidence or strings relating to creation of common persistence mechanisms such as run keys, scheduled tasks, services, or startup files.

Question 2

What is the purpose of this program?

Answer 2

Based on the program executing OleInitialize, we can infer that this has execution of a COM Object, as this initialises the COM Library.

By viewing further we can see this indeed creates an object which is then passed execution of the string: http://www.malwareanalysisbook.com/ad.html

Based on this we can begin to assume this initialises a COM object (likely Internet Explorer) and uses this to open a URL with ad.html, which may infer this is associated with an advertisement. By running the executable we can confirm our assumptions are correct.

Question 3

When will this program finish executing?

Answer 3

The program finishes executing after it is run and the webpage is opened. It’s likely this is part of adware which has been dropped on a users machine, potentially as part of further bundled software or malware.

Lab 7-3

Analyze the malware found in the files Lab07-03.exe and Lab07-03.dll

Question 1

How does this program achieve persistence to ensure that it continues running when the computer is restarted?

Answer 1

When examining the program and associated DLL we once again cannot see any obvious evidence of persistence; however there’s some elements which raise suspicions. First off the program shows reference to the DLL supplied with it (Lab07-03.dll), in addition to a well-known Windows DLL of kernel32.dll.

By examining the rest of the application, we can see reference to a similar, yet different DLL name of kerne132.dll, and reference to the supplied Lab07-03.dll DLL being copied into a file with this name at C:\Windows\System32 before we see a reference to subdirectories within C:\.

By looking inside the function call to sub_4011E0, within this we can see a statement that indicates files are being checked within C:\* which was passed to the program.

At this point a lot of comparisons and jump statements occur; however, this is of no interest to our analysis. By searching further within this function, we can see that a comparison occurs that checks if a file is a .exe, and if not a jump occurs.

Based on this we can infer that something the file system located at C:\ is being recursively checked for .exe files, and if one is found something occurs. By checking the function sub_4010A0 which runs if the jump is not performed, we can gather what occurs when an executable file is found. 3 key calls we find are CreateFile, CreateFileMapping, and MapViewOfFile.

Based on this we can infer that if an executable file is located, it is is mapped into memory and can then be modified by this program. Looking further at the program we can see that it compares kernel32.dll to a location within the executable, and if it isnt found, it will jump and repeat the process. Where it is found it proceeds to copy a value referenced by dword_403010 over the top of it.

Looking into this IDA believes it is a DWORD value specified as ‘6E72656Bh’.

By converting this to an ASCII string using ‘A’ or Edit > Strings > ASCII, we can see that it translates to something more legible.

With this we can infer that the program searches for executables recursively within C:\, and when they’re found it will open them, and directly in memory modify the file to replace any instances of kernel32.dll with kerne132.dll for persistence. Based on this we can infer the program is a type of file infector and uses the copied kerne132.dll (Lab07-03.dll) for its main payload. A brief look into Lab07-03.dll confirms that this has some form of C2 function and is likely a malicious implant used in tandem with this executable.

Question 2

What are two good host-based signatures for this malware?

Answer 2

Two good host-based signatures for this malware include the presence of kerne132.dll on disk, and the presence of Mutex ‘SADFHUHF’ which can be found within Lab07-03.dll.

Question 3

What is the purpose of this program?

Answer 3

From what we’ve gathered in question 1, we can conclude that this program is a file infector that infects executables on the system to load a malicious remote access trojan that connects back to the IP 127.26.152[.]13. By examining Lab07-03.dll, we can conclude that this trojan takes either the command sleep, or exec, which is used to start a process of interest.

Question 4

How could you remove this malware once it is installed?

Answer 4

Due to the malware infecting every executable on disk it is very difficult to remove. You could remove the malicious kerne132.dll from disk; however, it’s likely this will be in use by every process and be unable to be removed. Further if it is removed during deadbox analysis, it is likely the system will crash when booting due to no variant of kernel32.dll being present. To remediate you’ll be able to modify kerne132.dll to be the legitimate kernel32.dll, or even change the malware actions and recompile to instead modify all executables to point to the legitimate kernel32.dll instead of kerne132.dll. As another resort it may be easier to rebuild the system or restore from backup.

This concludes chapter 7, proceed to the next chapter.