Mr Silverlight Drive-by Meet Volatility Timelines
Sunday, May 18, 2014
I recently had the opportunity to attend the Volatility Windows Malware and Memory Forensics Training. Prior to the training, I used memory forensics (and thus Volatility) in different capacities but it wasn't a technique I leveraged when responding to security events and incidents during incident response activities. This was an area I wanted to improve upon going into the training. As the training went on and more material and labs were covered I kept thinking to myself how I intended to incorporate memory forensics into my response process. To use the technique when triaging live systems remotely over the network. The labs in the training provided numerous scenarios about using memory forensics on compromised systems but I wanted to further explore it with a simulated a security event. This post explores Volatility usage against an infected system's memory image by first determining: is the system infected and if so, how did it become infected in the first place.
Before diving into the memory image I first wanted to provide a short thought about the training. The training is not just about a single memory forensics tool named Volatility. The training goes in-depth in numerous topics including Windows internals, malware reversing, Windows data structures, how those structures are parsed, and bypassing encryption. I was looking for an in-depth course and I found it with Volatility. It walks you through exploring the Windows internals, the structures, how they can be parsed, and then actually doing it in labs. This layout results in knowing not just how to use tools for memory forensics but understanding what they are doing and what they are suppose to be doing. To top it off, the content is put into context as it relates to Digital Forensics and Incident Response (DFIR). All in all, it was a great training and I highly recommend it to anyone looking to get more memory forensics knowledge and skills. For a more detailed review refer to TekDefense's Review - Malware and Memory Forensics with Volatility (just keep in mind the content has been updated since his review.)
To set up the simulation I configured an extremely vulnerable virtual machine and then browsed to potentially malicious websites. I suspended the VM to grab the vmem file (memory) once I saw the first indication the system may be compromised. This is where the simulation starts to determine if this system is infected.
I first scanned the memory image for any previous networking activity that may be tied to malware by executing the command below:
python vol.py -f Win7.vmem --profile=Win7SP0x86 netscan
The picture below shows the partial output from netscan. A few different items jump out. The first is the process 0320.dll PID 3812 listening on the TCP ports 61779 and 8681. These ports are not typically open on Windows systems which made this a good lead. The other item to note is that Internet Explorer was active at one point in time.
The netscan plug-in provided some information but additional information is needed for PID 3812 0320.dll. I first wnated to know the command used to launch the program and I did this with pstree plug-in with the -v switch
python vol.py -f Win7.vmem --profile=Win7SP0x86 pstree -v
The program's location in the temp folder made it even more suspicious as being malicious.
To get a better understanding about how PID 3812 started I ran the pstree plug-in again without the -v switch to make it easier to see.
python vol.py -f Win7.vmem --profile=Win7SP0x86 pstree
The Internet Explorer process PID 572 spawned the PID 3812 0320.dll.
The netscan plug-in showed that this Internet Explorer was reaching out to the IP address 176.9.176.166. A search with the Malware Analysis search provided a few different hits including one to VirusTotal. The passive DNS showed this IP associated with domains flagged as malicious as well as a malicious file being downloaded from there.
To get a better idea about any processes that may had started and exited around the time PID 3812 0320.dll executed I ran the psscan plug-in.
python vol.py -f Win7.vmem --profile=Win7SP0x86 psscan
I highlighted the other processes that started around the same time but it didn't provide any more substantial leads.
0x000000007dd8f510 iexplore.exe 3600 2504 0x7d7a75c0 2014-05-11 01:38:00 UTC+0000
0x000000007e4d1030 0320.dll 3812 572 0x7d7a7540 2014-05-11 01:46:02 UTC+0000
0x000000007dad3d40 msiexec.exe 4036 492 0x7d7a7700 2014-05-11 01:46:38 UTC+0000
0x000000007e243030 dllhost.exe 2292 612 0x7d7a71e0 2014-05-11 01:46:55 UTC+0000 2014-05-11 01:47:00 UTC+0000
To see what access the PID 3812 process had on the system the getsids plug-in was used.
python vol.py -f Win7.vmem --profile=Win7SP0x86 getsids -p 3812
The lines below show 0320.dll was running in the context of the lab user account and had administrative rights to the system.
0320.dll (3812): S-1-5-21-2793522790-2301028668-542554750-1000 (lab)
0320.dll (3812): S-1-5-32-544 (Administrators)
I continued my focus on PID 3812 0320.dll to get more information about it by seeing what other items it is interacting with. To see it's handles I used the following:
python vol.py -f Win7.vmem --profile=Win7SP0x86 handles -p 3812
The only item of note in the handles output was the process's mutant; maybe it could help in researching in the malware.
0x8583b278 3812 0xd0 0x1f0001 Mutant Y7X-TYAA-X7A
The next item I explored was the process's loaded DLLs.
python vol.py -f Win7.vmem --profile=Win7SP0x86 dlllist -p 3812
Listed among the DLLs was one item located in the lab user profile; C:\Users\lab\AppData\Local\sattech.dll.
The last item I wanted to explore was to see if the process leveraged code injection with the command.
python vol.py -f Win7.vmem --profile=Win7SP0x86 malfind
The output showed the following processes had injected code into them: explorer.exe (PID 300), wmpnetwk.exe (PID 2116), iexplore.exe (PID 2504), iexplore.exe (PID 2504), iexplore.exe (PID 572), iexplore.exe (PID 3600), and msiexec.exe (PID 4036).
Volatility enabled me to quickly identify two suspicious files indicating the system is infected. The next step was to explore these files to actually confirm the infection. Both files were dumped from memory with the following commands (first one dumps 0320.dll while second dumps sattech.dll.)
python vol.py -f Win7.vmem --profile=Win7SP0x86 procdump -p 3812 -D .
python vol.py -f Win7.vmem --profile=Win7SP0x86 dlldump -p 3812 -b 0x10000000 -D .
For brevity I'm not posting everything I did to examine these dumped files. The one item I wanted to note was that the strings in 0320.dll referenced the registry key SOFTWARE\Microsoft\Windows\CurrentVersion\Run which may be its persistence. Knowing this was a simulated environment I ran both files through VirusTotal on 5/11/14 (the detections were low: 1/52 for 3020.dll and 10/52 for sattech.dll). I rescanned them while writing this post and the detections increased as can be seen in the 0320.dll VT report and sattech.dll VT report.
Memory forensics so far was able to confirm the infection, locate malware, provide clues about the malware's purpose, and extract the malware for further analysis. The next question I needed memory forensics to help me answer was how did the infection occur in the first place. An effective technique to address this question is timeline analysis and the Volatility training really opened my eyes to the additional capabilities memory provides to this technique. To fully explore Volatility timelines I'm performing timeline analysis in three separate stages. First only using the $MFT, then the timeliner plug-in (numerous time related objects), and finally the NTFS change journal ($USNJrnl).
Exploring the memory image to confirm the infection provided a few leads I leveraged in timeline analysis. There were the two files of interest: C:\Users\lab\AppData\Local\Temp\0320.dll and C:\Users\lab\AppData\Local\sattech.dll. Plus, the timeframe of interest was 2014-05-11 01:46:02 UTC+0000 since this was when the 0320.dll process started. I searched on these indicators and looked at the system activity that proceeded it and occurred after it. However, for clarity I'm presenting my timeline analysis in sequential order.
The commands below generates a timeline in bodyfile format with the $MFT records found in memory. Then the timeline is converted with mactime, grep for the date of interest, and then formatted with awk to remove unneeded columns.
python vol.py -f Win7.vmem --profile=Win7SP0x86 mftparser --output=body --output-file=mft-body
mactime -b mft-body -d -z UTC > mft_timeline.csv
cat mft-timeline.csv | grep -i "Sun May 11 2014" | awk -F, '{print $1, $3, $8}' > mft-timeline_05-11-14.csv
The image below shows the MFT timeline starting at 05/11/14 01:45:59 UTC.
The first few lines show Internet activity with files being created in Internet Explorer's temporary files cache. The last three lines shows activity for the C:\Windows\SoftwareDistribution folder (which is associated with Windows update) and file creation inside the Silverlight application folder (C:\Users\lab\AppData\LocalLow\Microsoft\Silverlight). The timeline continues as shown in the image below.
The activity for involving the SoftwareDistribution and Silverlight folders continues before the 0320.dll file is created on the system at 05/11/14 01:46:02. Solely, based on this activity it provides a clue to how the system became infected. There was Internet activity followed by Silverlight activity then malware appearing on the system. This activity points to a drive-by that targeted a vulnerability in the Silverlight application. This shows again the significance of exploring attack vector artifacts and it's an area I've been looking in to for some time (it applies to all types of attacks). I just opted to stop blogging about it and only recently posted the CVE 2013-0074 & 3896 Silverlight Exploit Artifacts documenting Silverlight exploits to provide context to the activity in this timeline. The image below continues with the $MFT timeline.
It shows that the sattech.dll file was created on the system one second after 3020.dll. The last portion of the timeline I'm discussing is shown below.
The Silverlight application activity surrounds the malware further confirming the attack vector used against the system. In addition, at 01:46:10 artifacts associated with program execution started appearing on the system. There are prefetch files showing both Silverlight application and malware executed.
The $MFT timeline created from the memory image enabled me to answer the "how" question. However, adding addition timeline data will make the events surrounding the infection more clear. The commands below generates the timeliner timeline in bodyfile format and combines it with the $MFT bodyfile. Then the timeline is converted with mactime, grep for the date of interest, and then formatted with awk to remove unneeded columns. Side note: one item I'm hoping Volalitity incorporates into the timeliner plug-in is the ability to specify what timeline artifacts to parse instead of parsing everything (this change should make timeline creation faster and more focused.)
python vol.py -f Win7.vmem --profile=Win7SP0x86 timeliner --output=body --output-file=timeline-body
cat mft-body timeline-body > timeliner-mft-body
mactime -b timeliner-mft-body -d -z UTC > timeliner-mft-timeline.csv
cat timeliner-mft-timeline.csv | grep -i "Sun May 11 2014" | awk -F, '{print $1, $3, $8}' > mft-timeliner_05-11-14.csv
The image below shows the timeliner and $MFT timeline starting at 05/11/14 01:45:59 UTC.
Right off the bat the other timeline data pulled from the memory image provided more context about what happened. Various Internet explorer processes were connecting to the freshdekor[dot]com domain. Remember the Volatility netscan plug-in output showed Internet Explorer connecting to two different IP addresses and one of them was 74.125.226.218. One of the Google searches on this IP address lead to a VirusTotal report containing passive DNS information. One of the passive domains listed for the IP address was freshdekor[dot]com. It's nice stuff how everything ties together more clearly. The image below continues with the timeline.
The activity is for the files in Internet Explorer's temporary files cache but now I know these came from the freshdekor[dot]com domain. The image below is the next portion of the timeline.
The first line shows something very cool. The Internet Explorer PID 572 is loading the coreclr.dll dll at 01:46:00. Running grep across the dlllist plug-in showed the full path to the dll which was c:\Program Files\Microsoft Silverlight\5.0.61118.0\coreclr.dll. A Google search for the dll indicated it is a Silverlight plug-in. This line is showing iexplore.exe loading the Silverlight plug-in within a second after visiting the freshdekor[dot]com domain. The third line from the top is cut off in the screenshot but it shows Internet Explorer PID 572 accessing the registry key SOFTWARE\APPDATALOW\SOFTWARE\MICROSOFT\SILVERLIGHT\PERMISSIONS for the lab user account. The rest of this timeline portion is more IE history artifacts for the domain in question. Continuing on with the timeline in the image below.
This activity is from the $MFT and was shown previously. However, now it's clear Internet Explorer loaded the Silverlight plug-in for a Silverlight application on a website. The Silverlight activity in this timeline portion was the result of a Silverlight application which was the exploit. The image below continues with the timeline.
Besides the threads it is the same activity shown previously involving Silverlight and the SoftwareDistribution folder. Continuing on with the timeline below.
This brings us to 01:46:02 which is when the 0320.dll process started. The activity shows the dlls being loaded (minus the sattech.dll dll), process created, and first thread started for 0320.dll PID 3812. This confirmed that the 0320.dll executed as soon as it was dropped onto the system. The image below shows what happened next.
The sattech.dll was created on the system and loaded by 0320.dll PID 3812 one second after the process started. The last section I'm highlighting in the timeliner/$MFT timeline is below.
The activity is from $MFT records and is the program execution artifacts mentioned previously.
The timeliner combined with the mftparser plug-in provided a wealth of information about how the system became infected. It even provide additional information about the attack that would never be found on the host. There is still yet another source of timeline data that can be added to the timeline. During the week I was taking the Volatility training, the instructors gave us the heads up that Tom Spencer released the USNParser plug-in to parse the NTFS change journal. The $USNJrnl is an excellent source to reference as I illustrated in my post Re-Introducing $UsnJrnl. To further explore memory timelines, I downloaded the plug-in and ran the commands below. It first generates the $USNJrnl in bodyfile format and then combines it with the timeliner/MFT bodyfile. The timeline is then converted with mactime, grep for the date of interest, and then formatted with awk to remove unneeded columns.
python vol.py -f Win7.vmem --profile=Win7SP0x86 usnparser --output=body --output-file=usn-body
cat usn-body timeliner-mft-body > timeline-all-body
mactime -b timeline-all-body -d -z UTC > timeline-all-timeline.csv
cat timeline-all-timeline.csv | grep -i "Sun May 11 2014" | awk -F, '{print $1, $3, $8}' > timeline-all_05-11-14.csv
The image below shows the $USNJrnl, $MFT, and timeliner timeline starting at 05/11/14 01:45:59 UTC.
The $USNJrnl didn't provide much useful in this portion of the timeline since it only shows the edb.log inside the SoftwareDistribution\DataStore\Logs folder. The timeline continues in the image below.
The first $USNJrnl activity shows the mssl.lck being referenced. This file was referenced in my CVE 2013-0074 & 3896 Silverlight Exploit Artifacts post. Even if I wasn't aware about these exploit artifacts, mssl.lck can still be tied to Silverlight by grepping for the file in the filescan plug-in output. This shows mssl.lck located in the C:\Users\lab\AppData\LocalLow\Microsoft\Silverlight folder. The image below is the next part of the timeline.
The additional information shown in this activity highlights an item that was present in the previous timelines. Prior to Internet Explorer PID 572 loading the Silverlight plug-in (coreclr.dll), the webpage stored in the temporary Internet files cache was named 8fdhe54wg1[1].htm was visited. This highlights another file to examine closer on the host to determine if it was responsible for serving up the malicious Silverlight application. The image below is the next part of the timeline.
The activity is involving the same files and domains already discussed. The timeline continues below.
Just prior to the activity for the BITFC11.tmp file in the Silverlight folder there is more activity involving the C:\Windows\SoftwareDistribution\DataStore\Logs folder. This time around it is for the tmp.edb file. The image below is the next portion of the timeline.
There is no additional items to note so the timeline continues in the image below.
Again, there isn't any additional activity of interest but I'm still posting these images for others to see the timeline in its entirely. The image below shows the next part of the timeline.
The $USNJrnl shows activity for the Silverlight application and the timeline continues below.
This portion was shown in the timeliner/$MFT timeline where the 0320.dll PID 3812 process started. The image below shows what happens next.
After the 0320.dll PID 3812 process started then there is a lot of activity for a tmp file in the Windows\Temp folder as shown below.
The $USNJrnl also reflects the sattech.dll file being created on the system. The last image of the timeline shows more information about the Silverlight application and program execution artifacts I mentioned previously.
As I went into the Volatility Windows Malware and Memory Forensics Training I wanted to leverage memory forensics more when responding to security events and incidents during incident response. The way I intend to use this technique is for analysis of live systems remotely over the network. As a method to investigate a security alert such as a system reaching out to a known malicious domain. Memory forensics could provide a wealth of information for this type of alert. Tying the specific network activity to a process and then determining where the process came from in the first place. Very similar to the simulation I did for this post. I may had started out wanting to leverage memory forensics more but I ended up with more knowledge and an improved skillset to help me hold the last line of defense for my organization.
Short Thought About the Training
Before diving into the memory image I first wanted to provide a short thought about the training. The training is not just about a single memory forensics tool named Volatility. The training goes in-depth in numerous topics including Windows internals, malware reversing, Windows data structures, how those structures are parsed, and bypassing encryption. I was looking for an in-depth course and I found it with Volatility. It walks you through exploring the Windows internals, the structures, how they can be parsed, and then actually doing it in labs. This layout results in knowing not just how to use tools for memory forensics but understanding what they are doing and what they are suppose to be doing. To top it off, the content is put into context as it relates to Digital Forensics and Incident Response (DFIR). All in all, it was a great training and I highly recommend it to anyone looking to get more memory forensics knowledge and skills. For a more detailed review refer to TekDefense's Review - Malware and Memory Forensics with Volatility (just keep in mind the content has been updated since his review.)
Is the System Infected?
To set up the simulation I configured an extremely vulnerable virtual machine and then browsed to potentially malicious websites. I suspended the VM to grab the vmem file (memory) once I saw the first indication the system may be compromised. This is where the simulation starts to determine if this system is infected.
I first scanned the memory image for any previous networking activity that may be tied to malware by executing the command below:
python vol.py -f Win7.vmem --profile=Win7SP0x86 netscan
The picture below shows the partial output from netscan. A few different items jump out. The first is the process 0320.dll PID 3812 listening on the TCP ports 61779 and 8681. These ports are not typically open on Windows systems which made this a good lead. The other item to note is that Internet Explorer was active at one point in time.
The netscan plug-in provided some information but additional information is needed for PID 3812 0320.dll. I first wnated to know the command used to launch the program and I did this with pstree plug-in with the -v switch
python vol.py -f Win7.vmem --profile=Win7SP0x86 pstree -v
The program's location in the temp folder made it even more suspicious as being malicious.
To get a better understanding about how PID 3812 started I ran the pstree plug-in again without the -v switch to make it easier to see.
python vol.py -f Win7.vmem --profile=Win7SP0x86 pstree
The Internet Explorer process PID 572 spawned the PID 3812 0320.dll.
The netscan plug-in showed that this Internet Explorer was reaching out to the IP address 176.9.176.166. A search with the Malware Analysis search provided a few different hits including one to VirusTotal. The passive DNS showed this IP associated with domains flagged as malicious as well as a malicious file being downloaded from there.
To get a better idea about any processes that may had started and exited around the time PID 3812 0320.dll executed I ran the psscan plug-in.
python vol.py -f Win7.vmem --profile=Win7SP0x86 psscan
I highlighted the other processes that started around the same time but it didn't provide any more substantial leads.
0x000000007dd8f510 iexplore.exe 3600 2504 0x7d7a75c0 2014-05-11 01:38:00 UTC+0000
0x000000007e4d1030 0320.dll 3812 572 0x7d7a7540 2014-05-11 01:46:02 UTC+0000
0x000000007dad3d40 msiexec.exe 4036 492 0x7d7a7700 2014-05-11 01:46:38 UTC+0000
0x000000007e243030 dllhost.exe 2292 612 0x7d7a71e0 2014-05-11 01:46:55 UTC+0000 2014-05-11 01:47:00 UTC+0000
To see what access the PID 3812 process had on the system the getsids plug-in was used.
python vol.py -f Win7.vmem --profile=Win7SP0x86 getsids -p 3812
The lines below show 0320.dll was running in the context of the lab user account and had administrative rights to the system.
0320.dll (3812): S-1-5-21-2793522790-2301028668-542554750-1000 (lab)
0320.dll (3812): S-1-5-32-544 (Administrators)
I continued my focus on PID 3812 0320.dll to get more information about it by seeing what other items it is interacting with. To see it's handles I used the following:
python vol.py -f Win7.vmem --profile=Win7SP0x86 handles -p 3812
The only item of note in the handles output was the process's mutant; maybe it could help in researching in the malware.
0x8583b278 3812 0xd0 0x1f0001 Mutant Y7X-TYAA-X7A
The next item I explored was the process's loaded DLLs.
python vol.py -f Win7.vmem --profile=Win7SP0x86 dlllist -p 3812
Listed among the DLLs was one item located in the lab user profile; C:\Users\lab\AppData\Local\sattech.dll.
The last item I wanted to explore was to see if the process leveraged code injection with the command.
python vol.py -f Win7.vmem --profile=Win7SP0x86 malfind
The output showed the following processes had injected code into them: explorer.exe (PID 300), wmpnetwk.exe (PID 2116), iexplore.exe (PID 2504), iexplore.exe (PID 2504), iexplore.exe (PID 572), iexplore.exe (PID 3600), and msiexec.exe (PID 4036).
Exploring 0320.dll and sattech.dll
Volatility enabled me to quickly identify two suspicious files indicating the system is infected. The next step was to explore these files to actually confirm the infection. Both files were dumped from memory with the following commands (first one dumps 0320.dll while second dumps sattech.dll.)
python vol.py -f Win7.vmem --profile=Win7SP0x86 procdump -p 3812 -D .
python vol.py -f Win7.vmem --profile=Win7SP0x86 dlldump -p 3812 -b 0x10000000 -D .
For brevity I'm not posting everything I did to examine these dumped files. The one item I wanted to note was that the strings in 0320.dll referenced the registry key SOFTWARE\Microsoft\Windows\CurrentVersion\Run which may be its persistence. Knowing this was a simulated environment I ran both files through VirusTotal on 5/11/14 (the detections were low: 1/52 for 3020.dll and 10/52 for sattech.dll). I rescanned them while writing this post and the detections increased as can be seen in the 0320.dll VT report and sattech.dll VT report.
How Did the System Become Infected?
Memory forensics so far was able to confirm the infection, locate malware, provide clues about the malware's purpose, and extract the malware for further analysis. The next question I needed memory forensics to help me answer was how did the infection occur in the first place. An effective technique to address this question is timeline analysis and the Volatility training really opened my eyes to the additional capabilities memory provides to this technique. To fully explore Volatility timelines I'm performing timeline analysis in three separate stages. First only using the $MFT, then the timeliner plug-in (numerous time related objects), and finally the NTFS change journal ($USNJrnl).
Exploring the memory image to confirm the infection provided a few leads I leveraged in timeline analysis. There were the two files of interest: C:\Users\lab\AppData\Local\Temp\0320.dll and C:\Users\lab\AppData\Local\sattech.dll. Plus, the timeframe of interest was 2014-05-11 01:46:02 UTC+0000 since this was when the 0320.dll process started. I searched on these indicators and looked at the system activity that proceeded it and occurred after it. However, for clarity I'm presenting my timeline analysis in sequential order.
$MFT Timeline
The commands below generates a timeline in bodyfile format with the $MFT records found in memory. Then the timeline is converted with mactime, grep for the date of interest, and then formatted with awk to remove unneeded columns.
python vol.py -f Win7.vmem --profile=Win7SP0x86 mftparser --output=body --output-file=mft-body
mactime -b mft-body -d -z UTC > mft_timeline.csv
cat mft-timeline.csv | grep -i "Sun May 11 2014" | awk -F, '{print $1, $3, $8}' > mft-timeline_05-11-14.csv
The image below shows the MFT timeline starting at 05/11/14 01:45:59 UTC.
The first few lines show Internet activity with files being created in Internet Explorer's temporary files cache. The last three lines shows activity for the C:\Windows\SoftwareDistribution folder (which is associated with Windows update) and file creation inside the Silverlight application folder (C:\Users\lab\AppData\LocalLow\Microsoft\Silverlight). The timeline continues as shown in the image below.
The activity for involving the SoftwareDistribution and Silverlight folders continues before the 0320.dll file is created on the system at 05/11/14 01:46:02. Solely, based on this activity it provides a clue to how the system became infected. There was Internet activity followed by Silverlight activity then malware appearing on the system. This activity points to a drive-by that targeted a vulnerability in the Silverlight application. This shows again the significance of exploring attack vector artifacts and it's an area I've been looking in to for some time (it applies to all types of attacks). I just opted to stop blogging about it and only recently posted the CVE 2013-0074 & 3896 Silverlight Exploit Artifacts documenting Silverlight exploits to provide context to the activity in this timeline. The image below continues with the $MFT timeline.
It shows that the sattech.dll file was created on the system one second after 3020.dll. The last portion of the timeline I'm discussing is shown below.
The Silverlight application activity surrounds the malware further confirming the attack vector used against the system. In addition, at 01:46:10 artifacts associated with program execution started appearing on the system. There are prefetch files showing both Silverlight application and malware executed.
Volatility Timeliner and $MFT Timeline
The $MFT timeline created from the memory image enabled me to answer the "how" question. However, adding addition timeline data will make the events surrounding the infection more clear. The commands below generates the timeliner timeline in bodyfile format and combines it with the $MFT bodyfile. Then the timeline is converted with mactime, grep for the date of interest, and then formatted with awk to remove unneeded columns. Side note: one item I'm hoping Volalitity incorporates into the timeliner plug-in is the ability to specify what timeline artifacts to parse instead of parsing everything (this change should make timeline creation faster and more focused.)
python vol.py -f Win7.vmem --profile=Win7SP0x86 timeliner --output=body --output-file=timeline-body
cat mft-body timeline-body > timeliner-mft-body
mactime -b timeliner-mft-body -d -z UTC > timeliner-mft-timeline.csv
cat timeliner-mft-timeline.csv | grep -i "Sun May 11 2014" | awk -F, '{print $1, $3, $8}' > mft-timeliner_05-11-14.csv
The image below shows the timeliner and $MFT timeline starting at 05/11/14 01:45:59 UTC.
Right off the bat the other timeline data pulled from the memory image provided more context about what happened. Various Internet explorer processes were connecting to the freshdekor[dot]com domain. Remember the Volatility netscan plug-in output showed Internet Explorer connecting to two different IP addresses and one of them was 74.125.226.218. One of the Google searches on this IP address lead to a VirusTotal report containing passive DNS information. One of the passive domains listed for the IP address was freshdekor[dot]com. It's nice stuff how everything ties together more clearly. The image below continues with the timeline.
The activity is for the files in Internet Explorer's temporary files cache but now I know these came from the freshdekor[dot]com domain. The image below is the next portion of the timeline.
The first line shows something very cool. The Internet Explorer PID 572 is loading the coreclr.dll dll at 01:46:00. Running grep across the dlllist plug-in showed the full path to the dll which was c:\Program Files\Microsoft Silverlight\5.0.61118.0\coreclr.dll. A Google search for the dll indicated it is a Silverlight plug-in. This line is showing iexplore.exe loading the Silverlight plug-in within a second after visiting the freshdekor[dot]com domain. The third line from the top is cut off in the screenshot but it shows Internet Explorer PID 572 accessing the registry key SOFTWARE\APPDATALOW\SOFTWARE\MICROSOFT\SILVERLIGHT\PERMISSIONS for the lab user account. The rest of this timeline portion is more IE history artifacts for the domain in question. Continuing on with the timeline in the image below.
This activity is from the $MFT and was shown previously. However, now it's clear Internet Explorer loaded the Silverlight plug-in for a Silverlight application on a website. The Silverlight activity in this timeline portion was the result of a Silverlight application which was the exploit. The image below continues with the timeline.
Besides the threads it is the same activity shown previously involving Silverlight and the SoftwareDistribution folder. Continuing on with the timeline below.
This brings us to 01:46:02 which is when the 0320.dll process started. The activity shows the dlls being loaded (minus the sattech.dll dll), process created, and first thread started for 0320.dll PID 3812. This confirmed that the 0320.dll executed as soon as it was dropped onto the system. The image below shows what happened next.
The sattech.dll was created on the system and loaded by 0320.dll PID 3812 one second after the process started. The last section I'm highlighting in the timeliner/$MFT timeline is below.
The activity is from $MFT records and is the program execution artifacts mentioned previously.
NTFS Change Journal, Volatility Timeliner and $MFT Timeline
The timeliner combined with the mftparser plug-in provided a wealth of information about how the system became infected. It even provide additional information about the attack that would never be found on the host. There is still yet another source of timeline data that can be added to the timeline. During the week I was taking the Volatility training, the instructors gave us the heads up that Tom Spencer released the USNParser plug-in to parse the NTFS change journal. The $USNJrnl is an excellent source to reference as I illustrated in my post Re-Introducing $UsnJrnl. To further explore memory timelines, I downloaded the plug-in and ran the commands below. It first generates the $USNJrnl in bodyfile format and then combines it with the timeliner/MFT bodyfile. The timeline is then converted with mactime, grep for the date of interest, and then formatted with awk to remove unneeded columns.
python vol.py -f Win7.vmem --profile=Win7SP0x86 usnparser --output=body --output-file=usn-body
cat usn-body timeliner-mft-body > timeline-all-body
mactime -b timeline-all-body -d -z UTC > timeline-all-timeline.csv
cat timeline-all-timeline.csv | grep -i "Sun May 11 2014" | awk -F, '{print $1, $3, $8}' > timeline-all_05-11-14.csv
The image below shows the $USNJrnl, $MFT, and timeliner timeline starting at 05/11/14 01:45:59 UTC.
The $USNJrnl didn't provide much useful in this portion of the timeline since it only shows the edb.log inside the SoftwareDistribution\DataStore\Logs folder. The timeline continues in the image below.
The first $USNJrnl activity shows the mssl.lck being referenced. This file was referenced in my CVE 2013-0074 & 3896 Silverlight Exploit Artifacts post. Even if I wasn't aware about these exploit artifacts, mssl.lck can still be tied to Silverlight by grepping for the file in the filescan plug-in output. This shows mssl.lck located in the C:\Users\lab\AppData\LocalLow\Microsoft\Silverlight folder. The image below is the next part of the timeline.
The additional information shown in this activity highlights an item that was present in the previous timelines. Prior to Internet Explorer PID 572 loading the Silverlight plug-in (coreclr.dll), the webpage stored in the temporary Internet files cache was named 8fdhe54wg1[1].htm was visited. This highlights another file to examine closer on the host to determine if it was responsible for serving up the malicious Silverlight application. The image below is the next part of the timeline.
The activity is involving the same files and domains already discussed. The timeline continues below.
Just prior to the activity for the BITFC11.tmp file in the Silverlight folder there is more activity involving the C:\Windows\SoftwareDistribution\DataStore\Logs folder. This time around it is for the tmp.edb file. The image below is the next portion of the timeline.
There is no additional items to note so the timeline continues in the image below.
Again, there isn't any additional activity of interest but I'm still posting these images for others to see the timeline in its entirely. The image below shows the next part of the timeline.
The $USNJrnl shows activity for the Silverlight application and the timeline continues below.
This portion was shown in the timeliner/$MFT timeline where the 0320.dll PID 3812 process started. The image below shows what happens next.
After the 0320.dll PID 3812 process started then there is a lot of activity for a tmp file in the Windows\Temp folder as shown below.
The $USNJrnl also reflects the sattech.dll file being created on the system. The last image of the timeline shows more information about the Silverlight application and program execution artifacts I mentioned previously.
Memory Forensics for the Win
As I went into the Volatility Windows Malware and Memory Forensics Training I wanted to leverage memory forensics more when responding to security events and incidents during incident response. The way I intend to use this technique is for analysis of live systems remotely over the network. As a method to investigate a security alert such as a system reaching out to a known malicious domain. Memory forensics could provide a wealth of information for this type of alert. Tying the specific network activity to a process and then determining where the process came from in the first place. Very similar to the simulation I did for this post. I may had started out wanting to leverage memory forensics more but I ended up with more knowledge and an improved skillset to help me hold the last line of defense for my organization.
Labels:
drive-by,
exploits,
memory analysis,
timeline
Posts
I've also started incorporating the results of the shimcache plugin to timeline creation in addition to the ones you've used in this analysis. Did you happen to run it on this image to see if any of the results correspond to what you had already discovered?
These timelines (once created) tend to be small enough to plug into Splunk for some additional correlation of events.
Great information!! Thanks for posting.
The shim cache is a great artifact since it can highlight malware that may not be present on the system. In this instance my focus was solely on memory. Trying to use it to solve the drive-by and to explore Volatility timelines. I did create a quick timeline of the host and it matched up from the quick look I did. It's definately really cool using different data sources to build timelines due to the added context they provide.
Thanks for the comment
Once again a very interisting post. There is not so much articles about using Volatily in a real case, and following your reasoning is as interesting as discovering volatility commands. Thanks for your job and time.