question4.tex

\lstset{basicstyle=\tiny}

\chapter{Question 4 - Memory Dump Analysis}

\section{Preparation}
Preparation for this part of the challenge focused on familiarisation with the recommended tools, IDA, Ollydbg, and Volatility. Having no previous experience with any of these tools or with malware analysis in general, we sought to develop a general understanding of the process. We downloaded several memory samples infected with known pieces of malware and were able to gain some experience using the recommend tools to attempt to analyse these samples. However, malware analysis requires not only a strong understanding of the tools, but also of the underlying operating system architecture, of assembly language and of the common techniques and tools used by malware developers. With a relatively short time for preparation, we focused mainly on learning these tools as well as general research of common malware behaviour. 

\section{Given Information}
All teams were given a memory dump file prior to the competition: MEMORY.7z\\
We were given the decryption key to the file upon commencement of the
competition.

\section{Question 4.1}
\textbf{Identify the malicious process on the computer.
\\\\
a) What is the PID of the initial malicious process?
\\b) At what date and time did the malicious process initially execute?
\\c) What is the parent PID of the malicious process?
\\\\
Example answer format: [1234] [2010-01-23 23:34:56] [4321]}
\subsection{Approach}
Our first challenge in answering this question lay in identifying some necessary information about the origin of the supplied memory dump. In order for Volatility, the memory dump analysis tool we were using, to properly parse and inspect the memory dump, we needed to specify the desired profile. Volatility supports many target operating system profiles and address spaces, including most versions of Windows XP, 2003, 2008, Vista and 7 in both x86 and x64. Volatility also has limited support for several version of Mac OSX and some distributions of Linux.

Our first attempt to determine the memory dump origin was to use the "imageinfo" plugin for Volatility. The imageinfo plugin is designed to easily indentify the target operating system. Unfortunately, the imageinfo plugin was unable to determine any valuable information about the dump. However, by supplying a suggested profile argument to the imagineinfo plugin, we could effectively brute-force this information by trying all possible profiles. If the suggested profile matched the originating operating system, then Volatility would return a variety of information about the dump. 

Given that we were trying to indentify a malicious process in this memory dump, and knowing that the majority of malware is designed to operate on the Windows platform, we restricted our choices to those Windows based profiles that Volatility supports. We used a small bash script to run Volatility against the dump with each of the available profiles, and record the output to a file.
The script took about 10 minutes to complete, and we could see that Volatility had succeeded when specifying a Windows 7 x64 profile. For all future use of Volatility, we specified this profile.

Volatility has several plugins that allow us to inspect in the processes that were running at the time of the memory dump. We used the pslist plugin to dump a list of all running processes, including their name, process id, parent process id, and the time at which that process started and exited. 

The majority of processes in the list appear innocuous, however one process, svc.exe stands out. This process is supicious because, while svc.exe is not the name of any Windows inbuilt process, it's name bares a similarity with svchost.exe, which is a generic service hosting process for DLL's \cite[p11]{winint}. This could be an attempt by the creator to have the process go unnoticed by nontechnical users who may be viewing the processes running on their system (for instance when trying to determine which processes are hogging resources). Our suspicions are raised further when we notice in the process list that cmd.exe (a windows command line) has just been started and then exited within 2 seconds. The PPID of this cmd.exe process is the PID of our suspect process, which is unusual behaviour.Our final confirmation came from a quick google for "svc.exe" which uncovered a number of different viruses using the svc.exe process name.

While we were quite certain at this point that svc.exe was our culprit, which would make our final answer "[1640] [2013-01-21 00:37:03] [2780]", we waited until we had completed Question 4.2 and 4.3 before we submitted this answer, which was correct.

\subsection{Retrospective Approach}
Although brute-forcing the correct profile as we have done here is neither elegant nor efficient, in this case it was a perfectly suitable solution. We were unable to find any other method of identifying the supplied memory dump within the set of tools that were recommended for the challenge.
\section{Question 4.2}
\textbf{a) What IP address is the malicious process communicating with?
\\b) What is the name of the mutex used by the malicious process?
\\\\
Example answer format: [127.0.0.1] [mutex1]}
\subsection{Approach}

Volatility has several modules for enumerating open connections and sockets, however only one such plugin, netscan, is compatible with 64 bit memory dumps. By using this plugin we obtained a list of all open TCP and UDP connections. This information includes the remote and local address, and the PID of the initiating process. We identified a connection in this list with the same PID as our previously identified process. 

We then needed to find the name of the mutex being used by the malicious process. Mutexes are commonly used by malware to retain ownership over a compromised machine and ensure only a single instance of a piece of malware can run at any time. We can use the Volatility handles plugin to enumerate the open handles of a given PID. Again, by using the the PID found in 4.1, we can return all the mutants held by that process. Mutant is the term used internally by the Windows kernel for a mutex \cite[p.57]{winint}. The results show that the process with PID 1640 holds 4 mutants, with one named "Sys322" and the rest being unnamed.

Our final answer for this section is [10.10.31.210] [Sys322]

\subsection{Retrospective Approach}
Our approach to this section was appropriate and efficient, to the best of our knowledge.
\section{Question 4.3}
\textbf{Locate and decode the key logger data file created by the malicious
process.\\
\\a) What is the file location of the key logger data file?
\\b) At what date and time was the key logger data file created?
\\\\
Example answer format:
[\textbackslash{}Device\textbackslash{}HarddiskVolume2\textbackslash{}folder
name\textbackslash{}filename.ext] [2010-01-23 23:34:56]}
\subsection{Approach}

As with our identification of the mutex handles held by the process, we use the same "handle" plugin to enumerate all the file handles currently possessed by the process. The process has handles to several directories, and interestingly a handle to a file called "logg.dat". Although we can find the names of currently open files and directories, we cannot find out any other valuable file information from the handle plugin.

However, we know that our memory dump comes from a Windows 7 operating system, and so the underlying file system is guaranteed to be NTFS. Thankfully, Volatility has yet another plugin, "mftparser", which allows use to parse and output the contents of the Master File Table (MFT) of NTFS volumes.

The MFT of an NTFS volume contains one entry for every file on the volume. Each entry contains information on a files "size, time and date stamps, permissions, data content" \cite[p.443]{winint2}. If the data for a file is too large to reside in the MFT, then the MFT instead contains information about the files location.

Considering that the MFT contains information about every open file in the system, it's understandably large (nearly 500,000 lines long, in this case). The output of the "mftparser" plugin was saved to a file, and then grep was used to locate any entries that corresponded to the open file handles of the malicious process. Through this technique we were able to find the time of creation of the logg.dat file. This file was opened approximately 4 seconds after our malicious process started, another strong indication that we have found our file. Our correct answer for this question was [logg.dat] [2013-01-21 00:37:07]. 
\subsection{Retrospective Approach}
Our approach to this section was appropriate and efficient, to the best of our knowledge. 
\section{Question 4.4}
\textbf{Determine the application name, username and password that have been
captured in the key logger data file.
\\\\
Example answer format: [application name] [username] [password]}
\subsection{Approach}
Due to time constraints, and the decision to focus on what were considered to be more fruitful aspects of the challenge, the team did not succesfully complete any further questions relating to the memory dump analysis.

\subsection{Retrospective Approach}
Thankfully, the size of the logg.dat file is approximately 131 bytes. Because of this, we are able to maintain the full file contents from the "mftparser" plugin just as we did for Question 4.3. The hexadecimal representation of this file was extracted from the MFT. As is typical of malware, the data had been obfuscated, and primary consisted of non-printable characters. One of the most common forms of obfuscation used in malware is simple one or two byte XOR'ing of the data. Base 64 encoding is also a common practice \cite[p.441]{pracmal}. With this in mind, we attempted to deobfuscate the data through the use of hex editors, many of which allow the application of bitwise operations to an entire file. Unfortunately, despite many attempts we were unable to deobfuscate the file directly through XOR operations. 

A better approach to deobfuscation of malware generated files would be to directly analyse the malware code and attempt to discover directly the XOR key or other method used to obfuscate the file. A description of our attempt at such analysis is described in the next sectio

\section{Question 4.5}
\textbf{Determine the file location where the malicious process stored a copy of
itself.
\\\\
Example answer format:
[\textbackslash{}Device\textbackslash{}HarddiskVolume2\textbackslash{}folder
name\textbackslash{}filename.ext]}
\subsection{Retrospective Approach}
Due to time constraints no further attempts could be made during the competition to complete these questions. We were unable to converge on a solution to these problems even after the conclusion of the competition. We shall describe the general approach taken to the remaining questions here as attempted during the weeks following the competition.

Our next approach to the analysis was to extract the malicious executable. In order to do this we used the "procexedump" plugin for Volatility, which extracts a target executable from a memory dump into an executable file. Once the executable was extracted we could attempt to perform static and dynamic analysis of the malware.

On initial inspection, the malware appeared to be packed. Malware packing is the There are several indications that this malware is packed. Firstly, the binary contains only 4 human readable strings, each the name of a system call. Secondly, executable has a very small import table, with only nine imported functions \cite[p.13]{pracmal} 
Malware developers use packers to obfuscate the and make static analysis more difficult. In order to perform any further static analysis we need to unpack the executable.

There are several tools that allow for automatic unpacking of executables packed with specific packing tools. However, in order to use such a tool we would need to identify which packer was used to pack this software. Several tools also exist to identify the packer used to pack an executable. Unfortunately, as usual the automatic identification tools do not produce reliable results in this instance, and so we must resort to manual unpacking of the executable.It is possible to use static analysis to uncover the algorithm by which the executable unpacks itself. However, the easier approach is to allow the executable to do all the work for us. This approach is common, and involves disassembling the executable and attempting to locate the Original Entry Point (OEP). The OEP is the point in the code at which control flow is passed from the wrapper used to unpack the executable, and the original executable as it existed prior to packing. Once this OEP has been found, we can use a debugger to set a breakpoint at that location, and then run the executable until we arrive at the OEP. Once the OEP has been reached, the executable should have completely unpacked itself. We can then dump the memory of the process being debugged, allowing us to continue with static analysis of the new unpacked malicious executable.


We used both IDA and Ollydbg to attempt to unpack the executable. Unfortunately, we were unable to correctly identify the OEP of the executable. This meant that further static analysis was impossible, effectively precluding us from discovering the answer to questions 4.5 through 4.9.


The file location referred to in this question is highly likely to exist in the unpacked executable as a human-readable string. If we had succeeded in unpacking the executable, we could have then used IDA of Ollydbg to display all strings contained in the executable, and search those strings for filenames. If we found a promising looking filepath, we could then analysis the assembly that utilised that string to determine whether that was indeed where the process was storing a copy of itself. 
\section{Question 4.6}
\textbf{Provide the registry key that contains the stubpath value and allows the
malicious software to persist after powering or reboot the system.
\\\\
Example answer format:
[HKLM\textbackslash{}Software\textbackslash{}subkey\textbackslash{}subkey\textbackslash{}subkey]}
\subsection{Retrospective Approach}
Had we successfully unpacked the malicious executable, we would have search for references to registry keys. For any references we found, we would have used the "printkey" plugin of Volatility to retrieve the value of those registry keys and their subkeys from the original memory dump.
\section{Question 4.7}
\textbf{Determine the file location of where the stolen documents have been
archived and what password was used to encrypt the archive.
\\\\
Example answer format:
[\textbackslash{}Device\textbackslash{}HarddiskVolume2\textbackslash{}folder
name\textbackslash{}filename.ext] [password]}
\subsection{Retrospective Approach}
Again, it is expected that static analysis of the malicious process would have allowed us to gain some insight into this question. We may have been able to reduce the time required to identify the relevant area's of the process memory through the use of IDA plugins such as findcrypt, which automatically locate known cryptographic constants within an executable. This may have allowed us to hone in on the location of the encrypting function. 
\section{Question 4.8}
\textbf{An additional backdoor has been deployed to the system and is persistent
after powering or reboot. Unlike the previous persistence mechanism, this
backdoor does not use the registry.
\\
\\a) What is the file location of the backdoor?
\\b) Name the process that is responsible for loading this backdoor?
\\\\
Example answer format:
[\textbackslash{}Device\textbackslash{}HarddiskVolume2\textbackslash{}folder
name\textbackslash{}filename.ext] [process name]}
\subsection{Retrospective Approach}
We were unable to make any attempt to answer this question, as it was highly probably that it relied on some information gathered throughout the previous uncompleted questions. However, given the information we know about the malwares persistence, we would have investigated several common malware persistence mechanisms. In particular, given time we may have been able to utilise the "mbrparser" plugin of Volatility to look for indications that the malware had manipulated the master boot record \cite[p.364]{malcook}. 

\section{Question 4.9}
\textbf{Investigate the initial attack vector.
\\
\\a) What is the URI of the website that was responsible for the initial
exploitation of the computer?
\\b) What is the sender's email address that sent the malicious link to the
CEO's laptop?
\\\\
Example answer format: [http://sub.domain.com/website] [email@domain.com]}
\subsection{Retrospective Approach}
Having been unable to answer questions 4.5 through 4.8, we were unable to make any attempt to answer this question.