CySCA 2013 Memory Forensic Writeup
A solution guide for a memory challenge released during a past CTF event
This blogpost contains the writeup for the memory forensic challenge in the Cyber Security Challenge Australia 2013 capture the flag event. We were given a URL before the event started to where we could download an archive containing the memory.dmp file for the memory forensic challenge, this archive was password protected so we couldn’t extract the memory dump before the challenge started.
Preparing Work Environment
We were also told before the competition started that we should use volatility for the memory forensic questions. As part of working with volatility is you need to profile for volatility to work properly. If i know the profile for the memory dump I could specify using the argument “–profile=(profile name)” but since I don’t know I need to determine the profile. The first part of this is using the “file” command to determine the architecture of the dump file.
root@Phlegethon:~/CySCA2013/volatility-read-only# file ../Memory-forensic/MEMORY.DMP
../Memory-forensic/MEMORY.DMP: MS Windows 64bit crash dump, full dump, 524174 pages
From the above output I can see that the operating system is MS Windows based and is a 64bit architecture system. Using the following command I set the profile to work with:
python vol.py -f ../Memory-forensic/MEMORY.DMP kdbgscan --profile=Win7SP0x64
Question 4.1 – 1 point
Identify the malicious process on the computer.
- What is the PID of the initial malicious process?
To answer this question I used the pstree argument instead of the pslist argument was because it allows me to answer question 4.1.c as well without any other commands need.
root@Phlegethon:~/CySCA2013/volatility-read-only# python vol.py -f ../Memory-forensic/MEMORY.DMP --profile=Win7SP0x64 pstree
Volatile Systems Volatility Framework 2.3_alpha
Name Pid PPid Thds Hnds Time
-------------------------------------------------- ------ ------ ------ ------ ----
. 0xfffffa8001d1c060:thunderbird.ex 2724 1492 27 330 2013-01-21 00:33:09 UTC+0000
.. 0xfffffa8001a0fb30:iexplore.exe 2496 2724 11 358 2013-01-21 00:37:00 UTC+0000
... 0xfffffa8003a50b30:iexplore.exe 2780 2496 14 390 2013-01-21 00:37:00 UTC+0000
.... 0xfffffa8002941b30:svc.exe 1640 2780 6 141 2013-01-21 00:37:03 UTC+0000
..... 0xfffffa800201e060:cmd.exe 2448 1640 0 ------ 2013-01-21 00:39:16 UTC+0000
From the above output from vol.py I can see all the processes running at the time of the dump, I noticed that the thunderbird.exe process was running cmd.exe which I thought to be quite strange, I did a Google search on svc.exe which was running cmd.exe to find that it is most likely malware, Spyware.W32.ClientMan, this means the initial malicious process to be executed is executed and the pid of the process is 1640.
- At what date and time did the malicious process initially execute?
This was found from the above output to be 2013-01-21 00:37:03
- What is the parent PID of the malicious process?
The parent process is again found from the above output which is shown in the ppid section of the output for the svc.exe line, the ppid is 2780.
Example answer format: [1234] [2010-01-23 23:34:56] [4321]
[1640][2013-01-21 00:37:03][2780]
Question 4.2 – 1 point
- What IP address is the malicious process communicating with?
I found a plugin in the volatility wiki command list called netscan which checks the memory dump for network connects, using the following command:
python ./vol.py -f ../Memory-forensic/MEMORY.DMP –profile=Win7SP0x64 netscan |grep "1640"
root@Phlegethon:~/CySCA2013/volatility-read-only# python ./vol.py -f ../Memory-forensic/MEMORY.DMP --profile=Win7SP0x64 netscan |grep "1640"
Volatile Systems Volatility Framework 2.3_alpha
0x7fbd3a90 TCPv4 10.10.31.219:49257 10.10.31.210:81 ESTABLISHED 1640 svc.exe
The above output from the command piped into grep to display the line that contains the value “1640” which is PID of the process svc.exe shows that the IP address that the malicious process is communicating with is 10.10.31.210.
- What is the name of the mutex used by the malicious process?
Using Google I was able to find this http://computer.forensikblog.de/en/2009/04/searching-for-mutants.html which I learnt from that mutex in a Windows environment is called a by a mutant. Looking at the plugin list for volatility, I saw there was a plugin called mutantscan, this didn’t give me output that was useful for me. Looking at the plugin list again I saw another plugin called handles with the following description “Print list of open handles for each process”. Looking at the options for the handle plugin I saw I can specify the PID I want to search for, running the plugin search for items relating to the PID “1640” this gave me a lot of output, I ran the command again but piped it into grep looking for Mutants which I had already learnt are used to call mutex in Windows.
root@Phlegethon:~/CySCA2013/volatility-read-only# python ./vol.py -f ../Memory-forensic/MEMORY.DMP --profile=Win7SP0x64 handles -p 1640 |grep "Mutant"
Volatile Systems Volatility Framework 2.3_alpha
0xfffffa8001a83430 1640 0x2c 0x1f0001 Mutant
0xfffffa8001db11b0 1640 0x98 0x1f0001 Mutant Sys322
0xfffffa8001d36700 1640 0xec 0x1f0001 Mutant
0xfffffa800398b380 1640 0xf4 0x1f0001 Mutant
The above output gave me 4 items which were Mutants relating to the pid “1640”, three which were un-named but one was named which was Sys322.
Example answer format: [127.0.0.1] [mutex1]
[10.10.31.210][Sys322]
Question 4.3 – 1 point
Locate and decode the key logger data file created by the malicious process.
- What is the file location of the key logger data file?
Another option that can be used with the handle plugin is the “-t” which allows the user to specify the object to list (this could’ve been used to answer the last part of the previous question). Since a data file is being searched for I can use the object type “file” relating to the malicious process.
root@Phlegethon:~/CySCA2013/volatility-read-only# python ./vol.py -f ../Memory-forensic/MEMORY.DMP --profile=Win7SP0x64 handles -p 1640 -t File
Volatile Systems Volatility Framework 2.3_alpha
Offset(V) Pid Handle Access Type Details
------------------ ------ ------------------ ------------------ ---------------- -------
0xfffffa8001ab8410 1640 0xc 0x100020 File \Device\HarddiskVolume2\Windows
0xfffffa8001a0f070 1640 0x14 0x100020 File \Device\HarddiskVolume2\Users\rmaclean\Desktop
0xfffffa8001a14f20 1640 0x10c 0x12019f File \Device\HarddiskVolume2\Program Files (x86)\Common Files\logg.dat
0xfffffa8001fe5370 1640 0x114 0x100020 File \Device\HarddiskVolume2\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7600.16385_none_ebf82fc36c758ad5
0xfffffa8001ff5be0 1640 0x120 0x120089 File \Device\HarddiskVolume2\Windows\SysWOW64\en-US\msvfw32.dll.mui
0xfffffa8001ff5830 1640 0x124 0x120089 File \Device\HarddiskVolume2\Windows\SysWOW64\en-US\avicap32.dll.mui
0xfffffa8001ff5490 1640 0x194 0x120089 File \Device\HarddiskVolume2\Windows\Fonts\StaticCache.dat
0xfffffa8001d7ea10 1640 0x1e4 0x100080 File \Device\Nsi
0xfffffa8001ff4b10 1640 0x200 0x16019f File \Device\Afd\Endpoint
0xfffffa8001fe5970 1640 0x4c0 0x16019f File \Device\Afd\Endpoint
0xfffffa8002085df0 1640 0x570 0x16019f File \Device\Afd\Endpoint
0xfffffa8001ff43c0 1640 0x63c 0x16019f File \Device\Afd\Endpoint
From the above output, the following line stands out as the possible key logger data file.
0xfffffa8001a14f20 1640 0x10c 0x12019f File \Device\HarddiskVolume2\Program Files (x86)\Common Files\logg.dat
- At what date and time was the key logger data file created?
In the NTFS metadata about files are stored in the MFT (Master File Table), there is a plugin in volatility called mftparser which allows the user to search the MFT data of a file.
root@Phlegethon:~/CySCA2013/volatility-read-only# python ./vol.py -f ../Memory-forensic/MEMORY.DMP –profile=Win7SP0x64 mftparser –output-file=../Memory-forensic/MEMORY-mft.txt
The above command dumps the metadata about files from the memory dump into a file called “MEMORY-mft.txt”, once the command had finished being ran. I used cat to display the information in the text file and piped into grep looking for entries of “logg.dat”.
root@Phlegethon:~/CySCA2013/volatility-read-only# cat ../Memory-forensic/MEMORY-mft.txt |grep "logg.dat"
2013-01-21 00:37:07 UTC+0000 2013-01-21 00:37:07 UTC+0000 2013-01-21 00:37:07 UTC+0000 2013-01-21 00:37:07 UTC+0000 Program Files (x86)\Common Files\logg.dat
2013-01-21 00:37:07 UTC+0000 2013-01-21 00:37:07 UTC+0000 2013-01-21 00:37:07 UTC+0000 2013-01-21 00:37:07 UTC+0000 Program Files (x86)\Common Files\logg.dat
The above information shows two entries both which contain identical information, the creation time of the data file is the following “2013-01-21 00:37:07 UTC+0000”.
Example answer format: [\Device\HarddiskVolume2\foldername\filename.ext] [2010-01-23 23:34:56]
[\Device\HarddiskVolume2\Program Files (x86)\Common Files\logg.dat][2013-01-21 00:37:07 UTC+0000]
Question 4.4 – 2 points
Determine the application name, username and password that have been captured in the key logger data file.
As part of the information dumped into the text file with the above command data is also dumped into the text file, I found at line 423315 of my output file the following information.
$DATA
0000000000: 88 85 88 85 b7 ad ab ac ae a8 ab ac a8 ad ac 9b ................
0000000010: ac ac b5 ae b2 b9 b7 ce e6 f4 eb e0 b9 88 85 ed ................
0000000020: ea dd a9 e8 de e7 e0 dc e9 ac b3 f6 cf dc dd f8 ................
0000000030: c4 dc e8 dc f2 e0 ee ea e8 e0 ac ad ae 88 85 88 ................
0000000040: 85 88 85 b7 ad ab ac ae a8 ab ac a8 ad ac 9b ac ................
0000000050: ac b5 ae b2 b9 b7 ce e6 f4 eb e0 9b a8 9b ed ea ................
0000000060: dd a9 e8 de e7 e0 dc e9 ac b3 b9 88 85 c3 e4 9b ................
0000000070: c5 ea e3 e9 a7 9b e8 f4 9b de ea e8 eb f0 ef e0 ................
0000000080: ed 9b e5 f0 ee ef 9b de ed dc ee e3 e0 df a9 9b ................
0000000090: bc ed e0 9b f4 ea f0 9b dc dd e7 e0 9b ef ea 9b ................
00000000a0: e3 e0 e7 eb 9b e8 e0 9b ea f0 ef ba 88 85 88 85 ................
00000000b0: 88 85 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b ..\{\{\{\{\{\{\{\{\{\{\{\{\{\{
00000000c0: 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b \{\{\{\{\{\{\{\{\{\{\{\{\{\{\{\{
00000000d0: 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b \{\{\{\{\{\{\{\{\{\{\{\{\{\{\{\{
00000000e0: 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b \{\{\{\{\{\{\{\{\{\{\{\{\{\{\{\{
00000000f0: 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b \{\{\{\{\{\{\{\{\{\{\{\{\{\{\{\{
0000000100: 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b \{\{\{\{\{\{\{\{\{\{\{\{\{\{\{\{
0000000110: 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b \{\{\{\{\{\{\{\{\{\{\{\{\{\{\{\{
0000000120: 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b 7b \{\{\{\{\{\{\{\{\{\{\{\{\{\{\{\{
0000000130: 7b \{
NOTE: the { have been escaped due to a build error when rendering the page in jekyll
From the above output of $DATA this data looks like it obfuscated, my reasoning for this conclusion is because of the “0x7B” and you would either expect “0x00” (a string of null bytes) or “0x90” (a NOP slide), since all the bytes in the dump are greater then “0x7B” I assume that in fact the bytes are “0x00” with would make the key byte for de-obfuscation would be “0x7B”. As all the bytes are equal or greater then “0x7B” I assume that the obfuscation process simply added “0x7B” to the original number, I copied the hex bytes from the $DATA section into a hex editor and using a hex calculator subtracted “0x7B” from the obfuscated hex.
<span style="text-decoration: underline;">Original Hex Bytes:</span>
88858885b7adabacaea8abaca8adac9bacacb5aeb2b9b7cee6f4ebe0b98885edeadda9e8dee7e0dce9acb3f6cfdcddf8c4dce8dcf2e0eeeae8e0acadae888588858885b7adabacaea8abaca8adac9bacacb5aeb2b9b7cee6f4ebe09ba89bedeadda9e8dee7e0dce9acb3b98885c3e49bc5eae3e9a79be8f49bdeeae8ebf0efe0ed9be5f0eeef9bdeeddceee3e0dfa99bbcede09bf4eaf09bdcdde7e09befea9be3e0e7eb9be8e09beaf0efba8885888588857b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b7b
<span style="text-decoration: underline;">De-obfuscated Hex Bytes:</span>
0D0A0D0A3C323031332D30312D32312031313A33373E3C536B7970653E0D0A726F622E6D636C65616E31387B5461627D49616D617765736F6D653132330D0A0D0A0D0A3C323031332D30312D32312031313A33373E3C536B797065202D20726F622E6D636C65616E31383E0D0A4869204A6F686E2C206D7920636F6D7075746572206A75737420637261736865642E2041726520796F752061626C6520746F2068656C70206D65206F75743F0D0A0D0A0D0A00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Which when transferred into ASCII gives you the following output:
….<2013-01-21 11:37><Skype>..rob.mclean18{Tab}Iamawesome123……<2013-01-21 11:37><Skype – rob.mclean18>..Hi John, my computer just crashed. Are you able to help me out?……………………………………………………………………………………………………………………
Example answer format: [application name] [username] [password]
[Skype][rob.mclean18][Iamawesome123]
Question 4.6 – 2 points
Provide the registry key that contains the stubpath value and allows the malicious software to persist after powering or reboot the system.
In volatility I found a plugin called procexedump which allows the user to dump the executables associated with a process, using the following command below I was able to dump the binary used by the malicious process.
root@Phlegethon:~/CySCA2013/volatility-read-only# python ./vol.py -f ../Memory-forensic/MEMORY.DMP --profile=Win7SP0x64 procexedump --dump-dir=../Memory-forensic/ --output-file=svc.exe
Once the executable has been dump, I used the string command to inspect the executable to identify if any strings match a registry entry.
s8SOFTWARE\Microsoft\Active Setup\Iwnstalled Components\% A
However the above registry entry found with the strings command embedded within the svc.exe executable was not the complete registry path. To do this I needed to get a better understanding the format to a registry path and key, I found the following information to be very useful in this answering this question. The registry structure is broken into the following:
A main key (Hive) > A Key > A Subkey (any number of subkey’s) > Values
The main key is broken up into the following categories:
- HKEY_CURRENT_USER (HKCU) – Contains preferences and settings specific to the currently logged in user.
- HKEY_LOCAL_MACHINE (HKLM) – Contains preferences and settings for the actual machine.
- HKEY_CLASSES_ROOT (HKCR) – Contains relate to the user interface.
- HKEY_USERS (HKU) – Contains information about every user who has logged into the machine.
- HKEY_CURRENT_CONFIG (HKCC) – Contains information about the current hardware settings for the machine (this hive is linked to HKLM).
- HKEY_DYN_DATA (HKDD) – This is an old main key found in Windows 95\98\ME which contains information about plug and play devices.
The Keys are organizational units for the registry, which can contain further subkeys, keys can be thought of a directory as in this can have either more subkeys (which are more directorys) or files (which are values). And finally Values contain the actual data being stored in a key or subkey.
An example of a registry key:
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\Start Page
HKEY_CURRENT_USER – This is the hive.
Software – This is the key.
Microsoft – This is the subkey.
Internet Explorer – This is the subkey.Main – This is the subkey.
Start Page – This is the value.
I then began searching the internet for the registry key found above with the “strings” command on executable.1640.exe which was found to be quite commonly used in malware code. With this information I can begin looking for the complete registry key used by the malicious process, I learnt that the “vaddump” plugin in Volatility allows the user to dump the contents of the each VAD (Virtual Address Descriptors) segment of a specific process, VADs record the virtual addresses usage of a process, I found this http://computer.forensikblog.de/en/2007/05/walking-the-vad-tree.html by Andreas Schuster which I found to be useful for this section.
python ./vol.py -f ../Memory-forensic/MEMORY.DMP --profile=Win7SP0x64 vaddump -p 1640 -D ../Memory-forensic/1640/
root@Phlegethon:~/CySCA2013/volatility-read-only# strings -af ../Memory-forensic/1640/* |grep "Installed Components"
../Memory-forensic/1640/svc.exe.7ef41b30.0x0000000000090000-0x000000000018ffff.dmp: SOFTWARE\Microsoft\Active Setup\Installed Components\{E92B03AB-B707-11d2-9CBD-0000F87A369E}
../Memory-forensic/1640/svc.exe.7ef41b30.0x0000000000090000-0x000000000018ffff.dmp: SOFTWARE\Microsoft\Active Setup\Installed Components\{21EAF244-B318-8F6C-E0B6-7A9935DE2F8D}
../Memory-forensic/1640/svc.exe.7ef41b30.0x0000000010000000-0x0000000010012fff.dmp: SOFTWARE\Microsoft\Active Setup\Installed Components\%s
../Memory-forensic/1640/svc.exe.7ef41b30.0x0000000010000000-0x0000000010012fff.dmp: SOFTWARE\Microsoft\Active Setup\Installed Components
From the vaddump output I used the “strings” command to search for registry keys while grepping the output to only display keys that contains “Installed Components” in the key. From the above output I was able to identify two possible registry path for the key, I then began attempting to determine which was actually the correct key used by the process for persistence.
python ./vol.py -f ../Memory-forensic/MEMORY.DMP --profile=Win7SP0x64 hivelist
Volatile Systems Volatility Framework 2.3_alpha
Virtual Physical Name
------------------ ------------------ ----
0xfffff8a00000f010 0x000000002cd3d010 [no name]
0xfffff8a000024010 0x000000002cf48010 \REGISTRY\MACHINE\SYSTEM
0xfffff8a00004e010 0x000000002d072010 \REGISTRY\MACHINE\HARDWARE
0xfffff8a0000f1420 0x000000002b7a8420 \Device\HarddiskVolume1\Boot\BCD
<strong>0xfffff8a0010b4010 0x0000000028e29010 \SystemRoot\System32\Config\SOFTWARE #HKLM</strong>
0xfffff8a0012ba010 0x0000000020422010 \SystemRoot\System32\Config\SECURITY
0xfffff8a00130a010 0x0000000020c30010 \SystemRoot\System32\Config\SAM
0xfffff8a001465010 0x00000000231b2010 \??\C:\Windows\ServiceProfiles\NetworkService\NTUSER.DAT
0xfffff8a0014f0010 0x0000000068f13010 \??\C:\Windows\ServiceProfiles\LocalService\NTUSER.DAT
<strong>0xfffff8a001de4010 0x000000005ddbb010 \??\C:\Users\rmaclean\ntuser.dat # HKCU</strong>
0xfffff8a001e06010 0x000000005de8e010 \??\C:\Users\rmaclean\AppData\Local\Microsoft\Windows\UsrClass.dat
0xfffff8a002308010 0x000000004102b010 \??\C:\System Volume Information\Syscache.hve
0xfffff8a005ae4010 0x000000000ba1d010 \SystemRoot\System32\Config\DEFAULT
Using the hivelist plugin I was able to identify the location of the registry hives in the dump, the output is shown above. Using the printkey plugin I can search virtual memory location for the process for the registry key. I made the mistake of just doing the initial search for key using the parameter “SOFTWARE\Microsoft\Active Setup\Installed Components” but because the application is 32-bit running on a 64-bit Operating System so I missed the key in both HKLM and HKCU hives, I had to add “Wow6432Node” to the location resulting as “Software\Wow6432Node\Microsoft\Active Setup\Installed Components”. Searching the first location for the two registry keys found during the vaddump search, “{E92B03AB-B707-11d2-9CBD-0000F87A369E}” & “{21EAF244-B318-8F6C-E0B6-7A9935DE2F8D}”.
root@Phlegethon:~/CySCA2013/volatility-read-only# python ./vol.py -f ../Memory-forensic/MEMORY.DMP --profile=Win7SP0x64 printkey -o 0xfffff8a0010b4010 -K "Wow6432Node\\Microsoft\\Active Setup\\Installed Components\\{21EAF244-B318-8F6C-E0B6-7A9935DE2F8D}"
Volatile Systems Volatility Framework 2.3_alpha
Legend: (S) = Stable (V) = Volatile
----------------------------
Registry: User Specified
Key name: {21EAF244-B318-8F6C-E0B6-7A9935DE2F8D} (S)
Last updated: 2013-01-21 00:37:07 UTC+0000
Subkeys:
Values:
REG_EXPAND_SZ stubpath : (S) C:\Program Files (x86)\Common Files\svchost.exe s
Above output from the “printkey” plugin shows that the “{21EAF244-B318-8F6C-E0B6-7A9935DE2F8D}” key is located in the HKLM hive.
Example answer format: [HKLM\Software\subkey\subkey\subkey]
[HKLM\Software\Wow6432Node\Microsoft\Active Setup\Installed Components\{21EAF244‐B318‐8F6C‐E0B6‐7A9935DE2F8D}]
Question 4.5 – 1 point
Determine the file location where the malicious process stored a copy of itself.
This location was found during the final part of the above question, Question 4.6, in the output from the “printkey” which revealed the malicious process also stored a copy of itself at “C:\Program Files (x86)\Common Files\svchost.exe”
Example answer format: [\Device\HarddiskVolume2\foldername\filename.ext]
[C:\Program Files (x86)\Common Files\svchost.exe]
Question 4.7 – 2 points
Determine the file location of where the stolen documents have been archived and what password was used to encrypt the archive.
Using the “psscan” plugin for Volatility I am able to search processes that have been run on the system which gave me the following output.
root@Phlegethon:~/CySCA2013/volatility-read-only# python ./vol.py -f ../Memory-forensic/MEMORY.DMP --profile=Win7SP0x64 psscan |grep "1640"
Volatile Systems Volatility Framework 2.3_alpha
0x000000007ef41b30 svc.exe 1640 2780 0x000000001d2fc000 2013-01-21 00:37:03 UTC+0000
0x000000007f61e060 cmd.exe 2448 1640 0x0000000077ebf000 2013-01-21 00:39:16 UTC+0000 2013-01-21 00:39:18 UTC+0000
Using the “psscan” plugin and grepped for the process ID of “1640” because I had revealed that was the PID of the malicious process, the output showed that the malicious process executed cmd.exe, so I performed the search again grepping the PID of cmd.exe, returning the following output.
root@Phlegethon:~/CySCA2013/volatility-read-only# python ./vol.py -f ../Memory-forensic/MEMORY.DMP --profile=Win7SP0x64 psscan |grep "2448"
Volatile Systems Volatility Framework 2.3_alpha
0x000000007f61e060 cmd.exe 2448 1640 0x0000000077ebf000 2013-01-21 00:39:16 UTC+0000 2013-01-21 00:39:18 UTC+0000
0x000000007f6a2b30 Rar.exe 2176 2448 0x00000000750d3000 2013-01-21 00:39:16 UTC+0000 2013-01-21 00:39:18 UTC+0000
I have now identified that the malicious process svc.exe launched cmd.exe which in turned launched rar.exe and the timing of all launches but I still need to determine where the location the stolen files are being archived too, this can be done by looking at the Master File Table (MFT) records to identify what files where created during this time. I exported the MFT information from the MEMORY dump file using the “mftparser” plugin to a file and then used mactime to organize the file in order of UTC.
root@Phlegethon:~/CySCA2013/volatility-read-only# python ./vol.py -f ../Memory-forensic/MEMORY.DMP --profile=Win7SP0x64 mftparser --output=body --output-file=../Memory-forensic/mftparser_body.txt
root@Phlegethon:~/CySCA2013/volatility-read-only# mactime -b ../Memory-forensic/msfparser_body.txt -z UTC > ../Memory-forensic/mac_mftparser.txt
Mon Jan 21 2013 00:39:00
544 macb ---a----------- 0 0 61082 [MFT FILE_NAME] Users\rmaclean\commands.bat (Offset: 0x43741800)
472 .a.b ---a----------- 0 0 61408 [MFT STD_INFO] Users\rmaclean\__rar_tmp0.003\__RAR_~1.328 (Offset: 0x46b3d000)
360 m.c. ---a----------- 0 0 61480 [MFT STD_INFO] Users\rmaclean\rar.rar (Offset: 0x2bf23000)
Mon Jan 21 2013 00:39:18
472 m.c. ---a-------I--- 0 0 23391 [MFT STD_INFO] Windows\Prefetch\CMDEXE~1.PF (Offset: 0x73388c00)
The above is a sample output from the mftparser plugin which shows that as soon as the rar.exe was launched the file rar.rar was created which means the rar.rar contains the stolen files which means the archive is located at “Users\rmaclean\rar.rar”. Now I need to find the password used to encrypt the archieve I decided since the commands.bat file is containing the instructions for stealing the files and archiving the them I would attempt to look at $DATA for the Users\rmaclean\commands.bat for the password, I performed the same process I used in an earlier question to look at the $DATA for the commands.bat file for an earlier question.
$FILE_NAME
Creation Modified MFT Altered Access Date Name/Path
------------------------------ ------------------------------ ------------------------------ ------------------------------ ---------
2013-01-21 00:39:00 UTC+0000 2013-01-21 00:39:00 UTC+0000 2013-01-21 00:39:00 UTC+0000 2013-01-21 00:39:00 UTC+0000 Users\rmaclean\commands.bat
$DATA
0000000000: 40 65 63 68 6f 20 6f 66 66 0d 0a 65 63 68 6f 20 @echo.off..echo.
0000000010: 52 69 50 77 6e 20 76 31 2e 33 0d 0a 63 64 20 25 RiPwn.v1.3..cd.%
0000000020: 75 73 65 72 70 72 6f 66 69 6c 65 25 0d 0a 6d 6b userprofile%..mk
0000000030: 64 69 72 20 77 69 6e 0d 0a 64 69 72 20 2f 42 20 dir.win..dir./B.
0000000040: 2f 73 20 2a 2e 64 6f 63 20 2a 2e 64 6f 63 78 20 /s.*.doc.*.docx.
0000000050: 2a 2e 70 64 66 20 2a 2e 74 78 74 3e 20 63 6d 64 *.pdf.*.txt>.cmd
0000000060: 73 0d 0a 66 6f 72 20 2f 66 20 22 64 65 6c 69 6d s..for./f."delim
0000000070: 73 3d 22 20 25 25 69 20 69 6e 20 28 63 6d 64 73 s=".%%i.in.(cmds
0000000080: 29 20 44 4f 20 63 6f 70 79 20 22 25 25 69 22 20 ).DO.copy."%%i".
0000000090: 22 2e 2f 77 69 6e 2f 22 0d 0a 72 61 72 2e 65 78 "./win/"..rar.ex
00000000a0: 65 20 61 20 2d 64 77 20 2d 68 70 41 40 65 73 30 e.a.-dw.-hpA@es0
00000000b0: 6d 33 65 52 72 3f 71 56 23 32 76 20 2d 72 20 72 m3eRr?qV#2v.-r.r
00000000c0: 61 72 2e 72 61 72 20 2d 6d 35 3d 4c 5a 4d 41 32 ar.rar.-m5=LZMA2
00000000d0: 20 22 2e 2f 77 69 6e 22 0d 0a 64 65 6c 20 2f 46 ."./win"..del./F
00000000e0: 20 2f 51 20 63 6d 64 73 20 0d 0a 0d 0a ./Q.cmds.....
***************************************************************************
Example answer format: [\Device\HarddiskVolume2\foldername\filename.ext] [password]
[\Device\HarddiskVolume2\Users\rmaclean\rar.rar][A@es0m3eRr?qV#2v]
Question 4.8 – 3 points
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.
- What is the file location of the backdoor?
Looking at the mac_mftparser.txt created in the last question I looked to see what else is created around the time the malicious process is executed.
Mon Jan 21 2013 00:38:44 400 macb ---a----------- 0 0 61038 [MFT FILE_NAME] Windows\ntshrui.dll (Offset: 0x47c3a800)
Around the time the process is launched the ntshrui.dll is created, I perform an internet search regarding this .dll file to find that the first hit in google, link, stated that this .dll is commonly used in persistence mechanisms outside the registry.
- Name the process that is responsible for loading this backdoor?
Example answer format: [\Device\HarddiskVolume2\foldername\filename.ext] [process name]
[\Device\HarddiskVolume2\Windows\system32\ntshrui.dll][]
Question 4.9 – 2 points
Investigate the initial attack vector.
- What is the URI of the website that was responsible for the initial exploitation of the computer?
At the beginning of this blogpost in question 4.1 I identified that the iexplore.exe > svc.exe > cmd.exe was the malicious process tree with 2780 being the PID of iexplore.exe, using the wintree plugin which allows the enumeration of all windows visible and/or invisible to the user.
root@Phlegethon:~/CySCA2013/volatility-read-only# python ./vol.py -f ../Memory-forensic/MEMORY.DMP --profile=Win7SP0x64 wintree |grep "2780"
Volatile Systems Volatility Framework 2.3_alpha
...http://news.cloudwatch.net/CloudCompetition - Windows Internet Explorer (visible) iexplore.exe:2780 TabWindowClass
- What is the sender’s email address that sent the malicious link to the CEO’s laptop?
The above out reveals the URL news.cloudwatch.net/CloudCompetition which is most likely the webserver that hosted the malware, this attack is most likely a client-side attack in which the victim is spear-phished in some manner to go to the URL http://news.cloudwatch.net/CloudCompetition which browsed to downloads the svc.exe malware to the victim machine. As part of this question I need to identify the initial exploitation of the computer, since the iexplorer.exe 2790 process is a child process of the thunderbird.exe 2724, so I redid the above command grepping for “2724”.
root@Phlegethon:~/CySCA2013/volatility-read-only# python ./vol.py -f ../Memory-forensic/MEMORY.DMP --profile=Win7SP0x64 wintree |grep "2724"
.2013 Cloud Product Winners Announced - Mozilla Thunderbird (visible) thunderbird.ex:2724 MozillaWindowClass
This looks like the subject line for an email, so honing in on this could possible reveal the sender’s email address. Again like in 4.6 I used vaddump to have a look at the memory for this process and then search for the strings relating to “2013 Cloud Product Winners Announced”.
root@Phlegethon:~/CySCA2013/volatility-read-only# python ./vol.py -f ../Memory-forensic/MEMORY.DMP --profile=Win7SP0x64 vaddump -p 2724 -D ../Memory-forensic/2724/
strings -af ../Memory-forensic/2724/* |grep -5 "2013 Cloud Product Winnders Announced"
thunderbird.ex.7fb1c060.0x0000000008e00000-0x0000000008efffff.dmp: References:
thunderbird.ex.7fb1c060.0x0000000008e00000-0x0000000008efffff.dmp: Message-ID: <1358470828.75369.YahooMailNeo@web160305.mail.bf1.yahoo.com>
thunderbird.ex.7fb1c060.0x0000000008e00000-0x0000000008efffff.dmp: Date: Thu, 17 Jan 2013 17:00:28 -0800 (PST)
thunderbird.ex.7fb1c060.0x0000000008e00000-0x0000000008efffff.dmp: From: Cloud Computing News <rian.malado@yahoo.com>
thunderbird.ex.7fb1c060.0x0000000008e00000-0x0000000008efffff.dmp: Reply-To: Cloud Computing News <rian.malado@yahoo.com>
thunderbird.ex.7fb1c060.0x0000000008e00000-0x0000000008efffff.dmp: Subject: 2013 Cloud Product Winners Announced
thunderbird.ex.7fb1c060.0x0000000008e00000-0x0000000008efffff.dmp: To: "RobMcLean@lavabit.com" <RobMcLean@lavabit.com>
The output from strings show that the spear-phishing attack came from the email address “rian.malado@yahoo.com”.
Example answer format: [http://sub.domain.com/website][email@domain.com]
[http://news.cloudwatch.net/CloudCompetition][rian.malado@yahoo.com]
