!

Computer Security & Forensics
 Forensics Practical Two : Volatility!

This practical walks you through the forensic analysis process used to solve an online forensics challenge. It uses the volatility tool and some standard command line applications to inspect and analyse the memory captured from a PC that was suspected of being compromised via a PDF exploit. Static analysis of a suspect machine can be very useful since we can take our time over the analysis process and can do it on a separate uninfected computer. Ideally your first action on examining a live suspect computer will be to take a snapshot of the memory and save it to removable media. You can then proceed to perform a more dynamic analysis with the knowledge that you have an alternative to fall back on should anything go wrong. !

! !

Operating System Version! You have learnt about checksums and viewing files with a hex editor in the previous practical, we will now move on to analysing a sample memory dump. !

!

One of the first things you will want to check is the type and version of the operating system that your sample was taken from. Open up a command prompt and change directory to your forensics folder that you created last week. Make sure you have a connection to the networked drive \\wsv.cs.stir.ac.uk\Security (it is assumed that you mapped the ’S’ drive in the following examples). Now type the following to extract the version information (it may take a couple of minutes):!

! tools\volatility imageinfo -f S:\forensics\lab.mem > lab-info.txt !

The ‘> lab-info.txt’ part of this command will redirect the output into the file lab-info.txt so that you do not have to keep regenerating it. If you view your home forensics directory in Explorer, you should see this file listed there and can open it with a text editor (e.g. Notepad). You should observe that the image is from a Windows XP machine running service pack 3 and aimed at an x86 architecture. !

!

The syntax for the volatility command is reasonably straightforward, you type volatility followed by the particular scan command you wish to run (e.g. imageinfo) and then indicate the file that is to be scanned via the -f option. If you type volatility on its own, you will get a list of the types of actions that this tool can perform. If you wish to save the output to a text file, just add > textfilename.txt at the end where textfilename.txt is the name of a file you wish to save the results to.!

!

Viewing Processes! The next step is to look at the processes that were running on the PC at the time the memory snapshot was taken. This may enable us to spot if anything unusual was running at the time we obtained our snapshot. To get this list of processes, type:!

! tools\volatility pslist -f S:\forensics\lab.mem > lab-pslist.txt !

This will produce a list of the processes that were running on the machine at the time the snapshot was taken (at least those that were recorded in the kernel process list). !

! !

1

! !

A sample of the output is shown below and you will see that it includes the memory offset of each process, its name, ID, its parent process ID (i.e. the process that started it - a very useful piece of information) and the time it was started (again very useful if you want to trace a chain of events such as cross checking a process starting with communication over the network). You can also see the number of internal threads initiated by a given process and a count of the handles it has on OS resources.!

!

Offset(V) ---------0x81bcaa00 0x8193ab10 0x81929b10 ...!

Name PID PPID Thds Hnds Time -------------------- ------ ------ ------ ------ ----System 4 0 72 300 1970-01-01 00:00:00 smss.exe 612 4 3 19 2011-08-31 09:45:09 csrss.exe 664 612 13 435 2011-08-31 09:45:11

!

We can display the above information in a more structured way using the pstree option which will show you the process hierarchy. This makes it easier to see which processes own and started other processes and also the sequence which led to each one starting. Type:
 
 tools\volatility pstree -f S:\forensics\lab.mem > lab-pstree.txt

! and look at the output, a sample of which is shown below:! ! Name 0x81BCAA00:System . 0x8193AB10:smss.exe .. 0x81929B10:csrss.exe .. 0x8198B020:winlogon.exe ... 0x81894DA0:lsass.exe ... 0x8188D628:services.exe ...!

Pid 4 612 664 688 744 732

PPid 0 4 612 612 688 688

Thds Hnds Time 72 300 1970-01-01 00:00:00 3 19 2011-08-31 09:45:09 13 435 2011-08-31 09:45:11 22 602 2011-08-31 09:45:12 22 354 2011-08-31 09:45:12 16 359 2011-08-31 09:45:12

!

You should be able to see that in the PPid (Parent Process ID) column, there are a number of processes that were started by the same parent and you can check in the PiD column (Process ID) what that process was (easily visible via the indentation used to group processes). You should also observe that the process tree appear to broken down into two major groups - the System processes under process 4 and a group of explorer related processes that effectively belong to a login session (with a non visible parent process of 364). In this later group, you can see the terminal session that was created (cmd.exe) and the win32dd.exe process started within it to capture the memory snapshot.!

!

This process tree should enable you to understand the standard Windows boot process and what happens when a machine starts up and then a user logs on. Given that we have a relatively minimal set up in this case, you can use this lab image as a reference point in cases where you have a more complex memory image with a larger number of user processes and background services active. !

!

It is worth noting that some root kits attempt to hide themselves from the standard kernel process list by altering their links in this list such that they are bypassed. Fortunately they are still forced to maintain process data in a structure which can be searched for. There is 2

!

a volatility command called psscan which will scan for all process structures in memory, irrespective of whether they are in the main process list. This will reveal processes that have either terminated normally or have tried to hide themselves. If you compare the list that you get from running pslist with that from psscan, you can then check through the additional processes and work out if they terminated normally or are abnormal processes worthy of further investigation (see later for details on analysing process executables). Try this now for the lab.mem image by typing:!

! tools\volatility psscan -f S:\forensics\lab.mem > lab-scan.txt !

Viewing Network Connections! The next step in the analysis is to examine if there were any listening ports and open network connections at the time the memory snapshot was taken. We can achieve this with volatility via two related commands. To get the list of open network sockets, type:!

! tools\volatility connscan -f S:\forensics\lab.mem > lab-sock.txt! !

Note that this can take a long time to run (10 minutes or more), so please be patient (while you are waiting for this process to complete, you can open a second DOS window and continue on with the rest of the practical). When this process completes, it will produce a list of the open sockets, both active and listening at the time the memory snapshot was taken, saving the output in labsock.txt. This file should contain the following entries:


!

Offset ---------0x01257588 0x01257e68 0x01269cf8 0x0128ccf8 0x0128f008 0x0129f788 ...!

Local Address Remote Address Pid ------------------- --------------------127.0.0.1:1034 127.0.0.1:1033 3028 127.0.0.1:1033 127.0.0.1:1034 3028 139.153.253.116:1046 2.20.183.163:80 3028 139.153.253.116:1050 212.58.227.137:80 3028 139.153.253.116:1037 212.58.246.108:80 3028 139.153.253.116:1057 77.72.115.68:80 3028

!

The above information can often provide clues to services that are waiting to receive input and you should check them to ensure the relevant process is the type of application you would expect to see using a network connection. For example, you should be deeply suspicious of a process such as Notepad if it appears to be listening on a socket. From the above, you would be able to see on what port it was listening and the instructions below would tell you how to find information on an IP address it had made a connection to.!

! To get just the list of active connections, you can type:! !

tools\volatility connections -f S:\forensics\lab.mem > labconn.txt

!

3

This will produce output similar to the following and should enable us to examine which processes have initiated connections and the IP addresses of the source and destination of these connections. !

!

Offset(V) ---------0xff9e5dd0 0xff9e5dd0 0x81925af8 0x81aa75d0 ...!

Local Address ------------------------139.153.253.116:1069 139.153.253.116:1042 139.153.253.116:1058 139.153.253.116:1057

Remote Address Pid ------------------ -----212.58.246.91:80 3028 212.58.246.91:80 3028 77.72.115.68:80 3028 77.72.115.68:80 3028!

!

For each address you can also see the port number used to make the connection. Some of these will be standard port numbers such as port 80 (http) but you may find other ports being used that you would not expect. !

!

Port numbers below 1024 usually have predetermined services associated with them (e.g. email, telnet, http etc). Ports in the range 1024–49151 are registered ports and their usage can be less reliable. For information on standard port usage, you can refer to Wikipedia’s entry which is reasonably accurate at present:!

! http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers! !

You should find that port usage from 1024 will often exploit gaps in tables shown in the above link to provide local private services that do not interfere with standard registered services.!

!

We can usually find out the domain that an IP address corresponds to using the nslookup command that is installed with Windows XP (see http://support.microsoft.com/kb/200525 for more details). For example, you will notice that process 3028 is communicating with IP address 212.58.246.91. We can check who this is by typing the following into the terminal window:!

! nslookup 212.58.246.91! !

Using the previous process list, work out what application this process corresponds to and what the user might be doing given the above results. We can normally find more information about a particular IP address or domain name using the whois command. This is provided as standard on Unix/Linux based computers but an equivalent can be obtained via Microsoft’s SysInternalsSuite which is available via a link on the module’s resources web page at:!

! http://www.cs.stir.ac.uk/courses/CSC9YS/resources/! !

There are also web based services that provide equivalent whois and nslookup functionality if you do not have ready access to a whois program.!

!

A copy of the SysInternals suite of analysis tools has been installed within the sysi subdirectory of the module’s forensics/tools directory. We can call the relevant Sys Internals whois tool via the command:!

!

tools\sysi\whois bbc.co.uk! 4

!

This will reveal ownership information and possible contact details for the owner of a domain or IP address. You will notice that the other non-local address is 77.72.115.68 which turns out to be a large web analytics company that was being used to gather usage information for the BBC web site. This temporary address may be inactive at the time of the practical and lookups may fail to find useful information.!

!

Searching Through Process Memory! Let us assume that we think the Firefox process was being used to view the BBC website and that we would like to gather more evidence to confirm this assumption. The volatility tool allows us to capture the memory associated with a particular process so that we can then inspect its contents. The syntax for this command is as follows:!

! volatility memdump -p -f -D ! !

where is the process that we would like a memory dump for, is the complete memory image we are using and is a directory to put the results into. !

!

Before we call this command with our own particular parameters, we should create a memory dump directory which we will call processmem. Create this directory as a subdirectory of your home forensics directory. You can use the terminal to do this if you wish by just typing mkdir processmem . Check that you have successfully created it by typing dir in the terminal window. This will give you a list of your current directory’s contents. !

!

To generate the memory dump for the firefox process (PID=3028), we would type the following (do not try this). !

!

tools\volatility memdump -p 3028 -f S:\forensics\lab.mem -D processmem

!

In the case of Firefox, this would build quite a large file and take some time to complete. Rather than individually generate the process memory dump for Firefox and other processes, it is possible to use volatility and the memdump option to dump the memory contents for all the processes that were resident in memory at the time of the memory capture via the command (again, do not try this):!

! volatility memdump -f -D ! !

In this case, we have omitted the ‘-p ’ option, causing volatility to scan and create a memory dump for all processes rather than just a specified one. !

!

To save time and processing effort, the individual process images have already been captured and are available in the S:\forensics\lab-pmem directory. Please do not make local copies of these, just access them directly from the shared module directory S: \forensics\lab-pmem.!

! !

5

In the case of the Firefox process, we are interested in the file S:\forensics\labpmem\3028.dmp (since Firefox was process 3028). It is possible to scan a binary image for occurrences of sequences of viewable characters, for example web addresses (or unencrypted passwords...). The SysInternals toolkit provides the equivalent of a commonly available Unix command called strings. This will search for all occurrences of character strings of a given length or above and can be called with our particular files as follows:!

!

tools\sysi\strings -a -n 8 S:\forensics\lab-pmem\3028.dmp > labp3028.txt!

!

This will search the memory dump for process 3028 (previously saved via memdump to S: \forensics\lab-pmem\3028.dmp). It will scan for sequences of viewable characters that are 8 character or longer (the -n 8 option) that are in ASCII format (the -a option). As usual, we redirect the output to a file, in this case lab-p3028.txt. This will produce nearly 5MB of data, most of which is meaningless. !

!

Once we have the file down to this size, we can now start to use search facilities more efficiently. One option would be for you to open the file in a text editor and manually search for entries. A more useful approach is to use the Windows findstr command (an equivalent to the commonly used grep command in Unix). For example, we can search our string file above to find all the potential http links it may contain. To try this, type the following:!

! findstr http: lab-p3028.txt > lab-ff-http.txt !

Examine the output of this file with a text editor, you may be surprised how many URLs were present (particularly since Firefox only had one page open at the time of capture). We can repeat the above search to look for occurrences of just the BBC URLs in the above output by typing:!

! findstr bbc.co.uk lab-ff-http.txt > lab-ff-bbc.txt !

Although the Firefox application and its usage are normal in this case, you may become suspicious of some applications and wish to examine them further. In addition to being able to extract the memory associated with a process, we can also extract the executable that was loaded into memory. The volatility application has an option called procexedump that will attempt to extract the related executable for a given process ID. It works in a similar manner to the memdump command except we replace memdump with procexedump. Before we call this command, we should create a new directory (in this case called procexe) that will contain the extracted executable. Create this directory and then try running the following command:!

!

tools\volatility procexedump -p 3028 -f S:\forensics\lab.mem -D procexe

!

We need some method of checking if this particular file is suspicious. One possibility would be to use an anti-virus tool and get it to scan a particular file (in this case our file would be procexe\executable.3028.exe). An alternative is to use the VirusTotal web site which is a web based virus scanner. Go to the VirusTotal website by opening a web browser and entering the URL:!

!

http://www.virustotal.com/index.html! 6

!

Now use the Browse and Send File options to browse to the above .exe file and submit it for scanning. If the file has not been seen by the system before, it may take a while to get the results back from this service. If it has seen the file before (due to a matching checksum) you will be given the option to use the previously produced report and would be advised to do this if possible (please do not overload this site in the future since it is a shared resource). !

!

The site runs the suspect file against a set of anti-virus services to get a consensus of whether it is infected or not and what the likely infection agent is. In our case, we should get back minimal hits (in fact a couple of false positives turned up when this practical sheet was checked).!

!

Some virus writers are aware of tools such as volatility and the methods they use to extract executables from static memory dumps. As a result, they modify themselves in memory so that the suspicious elements ‘disappear’ from the process executables that are normally extracted from memory. A plugin called malfind has been developed for volatility that attempts to work around the virus behaviour and will deliberately hunt for suspicious sections of code in the memory dump. Malfind is used in a similar manner to the procexedump command and can be made to dump all the suspicious segments it finds via the command:!

! volatility malfind -f S:\forensics\lab.mem -D lab-mal! !

Unfortunately, the malfind plugin does not work properly with the standalone version of volatility that you are using so the output that it produces when scanning lab.mem has been placed in the directory lab-mal for you. Look through this directory and try submitting a fragment from the Firefox application to the virustotal site. You should still not find anything suspicious (at least I hope you don’t). The complete log that is produced by the malfind plugin is also available in the file lab-mal-log.txt. For certain suspicious entries, this will show the section of suspect byte code in hex and ascii, followed by a disassembly (conversion of machine code to assembly code) of this byte code. !

!

Summary! We have now gone through some of the processes and concepts behind obtaining a static memory dump of a running computer and performing an analysis of its contents. There are a number of other options available with the volatility tool which you are welcome to try out. If the output produces a large file (greater than a few megabytes), please analyze and then delete it. !

! For a more complete list of options available for volatility and examples of their use, see:! ! http://code.google.com/p/volatility/wiki/CommandReference
 


This reference also uses volatility via the python interpreter and therefore uses python vol.py in place of the volatility command that you have been using. Just substitute volatility for examples that start with python vol.py. Please note that the command reference refers to a fully configured version of volatility with all relevant plugins. To check the options available in the version you are using, type:!

!

tools\volatility -h! 7