Journey Into Incident Response

Change is one of the only constants in incident response. In time most things will change; technology, tools, processes, and techniques all eventually change. The change is not only limited to the things we rely on to be the last line of defense for our organizations and/or customers. The threats we are protecting them against change too. One recent example is the Angler exploit kit incorporating fileless malware. Malware that never hits the hard drive is not new but this change is pretty significant. An exploit kit is using the technique so the impact is more far reaching than the previous instances where fileless malware has been used (to my knowledge.) In this post I'm walking through the process one can use to triage a system potentially impacted by fileless malware. The post is focused on Poweliks but the process applies to any fileless malware.

Background on Why This Matters

In my RSS feeds, I was following the various articles about how an exploit kit incorporated the use of fileless malware. The malware never gets dropped to the disk and gets loaded directly into memory. A few of the articles I'm referring to are: Poweliks: The file-less little malware that could, Angler EK : now capable of "fileless" infection (memory malware), Fileless Infections from Exploit Kit: An Overview, POWELIKS: Malware Hides In Windows Registry, and POWELIKS Levels Up With New Autostart Mechanism. Reading the articles made one thing clear: one of the most effective tools to deliver malware (exploit kits) is now using malware that stays in memory.

This change has a significant impact on multiple areas. If the malware stays in memory then the typically artifacts we see on the host will not be there. For example, when the malware is loaded into memory then it won't create program execution artifacts on the system. This means the triage and examination process needs to adjust. As I mentioned previously, this change was implemented into a widely known exploit kit (Angler exploit kit.) The systems infected with this exploit kit can be far reaching. This means we will encounter this change sooner rather than later; if you haven't faced it already. Case in point, recently the Internet Systems Consortium website was compromised and was redirecting visitors to the Angler exploit kit. The last impact is if this change provides better results for the people behind it then I can see other exploit kit authors following suit. This means fileless malware may become even more widespread and it's something that is here to stay.

I knew memory forensics is one technique we can use to find the malware in memory. (if you need a great reference on how to do this check out the book the Art of Memory Forensics.) However, the question remained what does this look like. I took the short route for a quick answer to my question by reaching out to my Twitter followers. I asked them the following: "Anyone know how Poweliks code looks from memory forensics perspective?"

The first responses I got back was from Adam over at the Hexacron blog (great blog by the way) as shown below.

Adam provided some great information; to narrow in on the dllhost.exe process and what strings to look for. Another response I got was from @lstaPee as shown below:


@lstaPee provided a few more tidbits. RunDll32.exe injects code into the Dllhost.exe and dllhost.exe should have network connections. The response I got back from Twitter was great but I really needed to address the bigger question. If and when I have to triage a system infected with Poweliks what is the fastest way to perform the triage to locate the malware and determine the root cause of the infection. A question I needed to dig in to in order to find out the answer.

Testing Environment

As much as I wanted to simulate this attack by finding a live link to an Angler exploit kit I knew it would be very difficult. Based on various articles I read, Angler is VMware aware and  it doesn't always deliverer the fileless malware. I opted to use a Powelik's dropper/downloader. I used the sample MD5 0181850239cd26b8fb8b72afb0e95eac I found on Malwr. The test system was a Windows 7 32bit virtual machine in VMware.

The test conditions were really basic. I executed the sample by clicking it and then waited for about a minute. The VM was suspended and I collected the memory and prefetch files. I then unsuspended the VM followed by rebooting the system. After reboot, I logged onto the VM and then suspended it to collect the memory and prefetch files.

My tests was to analyze the Poweliks infection from two angles. The initial infection prior to a system reboot and a persistent infection after the system reboots. My analysis had one exception. By clicking the Poweliks executable to infect the system this action created program execution artifacts. I ignored these artifacts since they wouldn't be present if the malware was loaded directly into memory. I followed my typical examination process on the memory images and vmdk files but this post only highlights the activity that directly points to Poweliks. There was other activity of interest but the activity by itself does not indicate anything malicious. This activity I opted to omit from the post.

Poweliks' Behavior

Before diving into the triage process and what to look for it's important I discuss one Poweliks' behavior. I won't go into any details how I first picked up on this but I will show the end result. What the behavior is and how it can help when triaging Poweliks specifically. The screenshot below shows partial of the Malwr's behavior analysis section showing the behavior I'm referring to.


Upon a system's initial infection, the malware calls rundll32.exe which then calls powershell.exe who injects code into the dllhost.exe process. In the image above the numbers are for the process IDs and this relevant as we dig deeper into the behavior.

The image below shows activity that occurs shortly after the rundll32.exe process starts. As can be seen, rundll32.exe attempts to load a module into its own address space with the LdrLoadDll function. The module being loaded is actually javascript; this behavior is well documented for Poweliks such as in the article Poweliks – Command Line Confusion. Notice the activity following the LdrLoadDll function call is trying to locate the address for the RunHTMLApplication function. Here's the keyword Adam pointed out.


The images below shows activity that occurs just prior to powershell.exe process exiting. Powershell.exe creates the dllhost.exe process in the suspended state. Code gets injected into this suspended dllhost.exe process and then it is resumed. This technique is process hollowing and when the suspended process is resumed it executes the injected code.

Triaging System Infected with Poweliks

Triage is the assessment of a security event to determine if there is a security incident, its priority, and the need for escalation. As it relates to potential malware incidents, the purpose of triaging may vary. In this instance, triage is being used to determine if an event is a security incident or false positive by identifying  malware on the system. Confirming the presence of malware allows for a deeper examination to be completed. The triage process I'm outlining is to confirm the presence of the Poweliks fileless malware.

Triaging with Host Artifacts

Normally, triaging a system using artifacts on the host is an effective technique to identify malware. This is especially true when leveraging program execution artifacts. However, loading malware directly into memory has a significant impact on the artifacts available on the host. There are very little artifacts available and if the malware doesn't remain persistent then there will be even less. Triaging a system infected with Poweliks is no different. Most of the typically artifacts are missing but it can still be identified using prefetch files and autorun locations.

Prefetch Files

Previously I outlined the Poweliks behavior where the rundll32.exe process runs, which then starts a powershell.exe process before injecting code into the dllhost.exe suspended process. This behavior is apparent in the prefetch files at the point of the initial infection. The image below shows the activity.


The prefetch files show the sequence of rundll32.exe executing followed by powershell.exe before dllhost.exe. Furthermore, the dllhost.exe prefetch file is missing the process path. The missing process path indicates process hollowing was used as I outlined in the post Prefetch File Meet Process Hollowing. The prefetch files contain references to files accessed during the first 10 seconds of application startup. The dllhost.exe prefetch file contains revealing ones. It contains a reference to wininet.dll for interacting with the network and files associated with Internet Explorer as shown below.


This specific prefetch file sequence only occurs upon the initial infection. Future system restarts where Poweliks is loaded into the dllhost.exe process only shows the dllhost.exe prefetch file. The file references in this prefetch still show references to files located in the user profile.

Autoruns

The prefetch files contain a distinctive pattern indicating a Poweliks infection. Depending on the sample, autoruns can reveal even more. I mention depending on the sample because Poweliks has changed its persistence mechanism. Initially it used the Run registry key before moving on to a CLSID registry key. I thought one article mentioned Poweliks may not try to remain persistent at all times. If Poweliks does try to remain persistent then its mechanism can be used to find it. Keep in mind, Poweliks has taken self protection measures to prevent this mechanism from being located on a live system. The easiest method to bypass these measures is to access the system remotely with a forensic tool like Encase Enterprise, mount the drive, and then run Regripper across the hives.

The image below shows the Run key from the user account on my test system. The sample I used was older since the Run key was used but it still is a tell-tale sign for a Poweliks infection.

...snip....

Memory Analysis Triage

Fileless malware may leave very little artifacts available on the host's hard drive but it still has to reside in memory. The most effective technique to identify a fileless malware infection is memory forensics. A Poweliks infection is not an exception since it stands out in memory whether if the memory is examined after the initial infection or a system reboot.

Network Connections

One area with malware indications is network activity are for unusual processes. @lstaPee alluded to this in their tweet about Poweliks. The Volatility netscan plug-in does show network activity for  the dllhost.exe process involving the IP address 178.89.159.35 on port 80 for HTTP traffic. dllhost.exe is not a process typically associated with web traffic so this makes it a good indicator pointing to Poweliks.

Process Listing

Another area with malware indications is the process listing showing unusual ones or ones with unusual commands. The Volatility pslist, psscan, and pstree -v plugins did not reveal anything that could definitely be used as an indicator but they did show the dllhost.exe process running. I checked a few clean systems to see if dllhost.exe normally runs but the process was not running by default.  This doesn't mean it can be used as an indicator because there could be other reasons for dllhost.exe running besides Poweliks. The screen below is from the pstree plug-in showing the command-line for launching dllhost.exe (notice there are no other options used in the command.)

Injected Code

Looking for processes with injected code is an effective technique to locate malware on a system. This is the one technique that absolutely reveals Poweliks on a system. The Volatility malfind plug-in showed the dllhost.exe process with injected code. This matches up to the articles about the malware and behavior analysis showing code does get injected into the dllhost.exe process. The image below shows the partial output from malfind.


Extracting the injected code and scanning it with antivirus confirms it is Poweliks. The image below shows the VirusTotal results for the injected code. Microsoft detected the code as Trojan:Win32/Powessere.A which is their classification for Poweliks.

Strings

The last area containing indicators pointing to Poweliks are the strings in the dllhost.exe process. The method to review the strings is not as straight forward as running a single Volatility plug-in. The strings command reference walks through the process and it's the one I used. The only thing I did different was to grep for my process ID to make the strings easier to review. The dllhost.exe strings revealed URLs such as one containing the IP address found with the netscan plug-in.


The most significant string found was the command used to make rundll32.exe inject code into the dllhost.exe process as shown below. The presence of this string alone in the dllhost.exe process indicates the system is infected with Poweliks.

Wrapping Things Up

The change introduce by the Angler exploit kit creator(s) is causing us to make adjustments in our processes. The effective techniques we used in the past may not be as effective against fileless malware. However, it doesn't mean nothing is effective preventing us from triaging these systems. It only means we need to use other processes, techniques, and tools we have at our disposal. We need to take what artifacts do remain and use it to our advantage. This post was specific to the Poweliks malware but the techniques discussed will apply to other fileless malware. The only difference will be what data is actually found in the artifacts.

Christmas is in the rear view mirror and you may be left wondering about the gift you didn't find under the tree. The gift loaded with DFIR goodness to bring you into the new year. A gift you can use to improve your knowledge and skills. A gift to help you get to the next level in digital forensics, incident response, or malware analysis. You didn't get any DFIR goodness so it's a great opportunity to reward yourself with a gift of your own choice; one to accomplish what the previous sentences alluded to. If you fit this description then the book The Art of Memory Forensics is what you should be looking for. Even if the description doesn't fit and you don't already own this book then you should seriously check it out. This post is my review of the book The Art of Memory Forensics.

Three in One

The book addresses memory forensics on the following three operating systems: Windows, Linux, and Mac. This makes it an outstanding book since it addresses the most commonly faced operating systems. Furthermore, the content not only addresses memory forensic techniques but goes into detail about operating system internals. The majority of the systems I encounter are Windows systems so my focus was on the Windows portion of the book. (I did skim the other sections but I took my time in the Windows section.) The content went deep into the various Windows data structures and function calls. This makes the book an outstanding reference to better understand operating system internals. I easily envision myself using this book as a reference for years to come.

Not Just Words but Hands-on

One thing I tend to look for in a technical security book is how easy is it for the reader to take the content/techniques then apply it elsewhere. This is another area where the Art of Memory Forensics shines. The book's website provides additional materials that accompany the book. The items include lab questions, lab answers, and memory images for each chapter. This allows the reader an opportunity to do the hands-on labs to re-enforce that chapter's content. It's a great way to learn since you are actually performing memory forensics on an image after reading about it. Furthermore, to explain concepts the book uses - for the most part- memory images freely available on the Internet. As you read the book you can follow along by performing the same activities on the same memory images. At times the authors don't explicitly say what memory image they are using but the name of the memory images is pretty revealing. For example, in the Detecting Registry Persistence section (Kindle version page 4626) the Volatility handles plug-in is ran against a memory image named "laqma.mem". On the SampleMemoryImages webpage you can see a Laqma memory image is available and this is the one used in the book. This occurs frequently in the book as well as the authors specifically mentioning the memory image they are using.

The one area I thought that could make this book even better would be for the authors to explicitly state the memory image being used in the examples. This would make it easier for others (especially people who are not aware about the available memory images) to follow along in the book doing the same examples.

Memory Forensics in Toolbox

The last point I wanted to touch on about why I think so highly of this book is memory forensics is a process we need to have in our toolbox. This is true regardless if the work involves incident response or malware analysis. In incident response, there are times when you need to examine the volatile data on a system to obtain an answer. For example, a system is making network connections to a known malicious domain, which is setting off alerts. To tie the network connections to an actual process on the system requires memory forensics. The need for this in incident response is even more so with the recent increase of an exploit kit leveraging fileless malware. In malware analysis, there are times when memory forensics can provide additional information about a sample under examination. Does it open a socket, make network connections, inject code, hook functions, etc.. Memory forensics is now a process we need available in our toolbox and this book can help put it there.

All in All

If you are looking for a gift loaded with DFIR goodness, looking to improve your knowledge/skills, or looking for help to get to the next level in DFIR then this book is for you. The Art of Memory Forensics is a hefty book loaded with excellent content. It's an outstanding book and for those who don't already own it should seriously consider making it their next DFIR purchase. Just make sure to get your money's worth by grabbing the labs, memory images, and then putting hands to the keyboard as you read along.

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.

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.

When responding to a potential security incident a capability is needed to quickly triage the system to see what's going on. Is a rogue process running on the system, whose currently logged onto the system, what other systems are trying to connect over the network, or how do I document the actions I took on the system. These are valid questions during incident response whether the response is for an actual event or a simulation. One area to examine to get answers is the systems' volatile data. Automating the collection of volatile data can save valuable time which in turn helps analysts examine the data faster in order to get answers. This post briefly describes (and releases) the Tr3Secure volatile data collection script I wrote.

Tr3Secure needed a toolset for responding to systems during attack simulations and one of the tools had to quickly collect volatile data on a system (I previously discussed what Tr3Secure is here). However, the volatile data collection tool had to provide dual functions. First and foremost it had to properly preserve and acquire data from live systems. The toolset is initially being used in a training environment but the tools and processes we are learning need to be able to translate over to actual security incidents. What good is mastering a collection tool that can’t be used during live incident response activities? The second required function was the tool had to help with training people on examining volatile data. Tr3Secure members come from different information security backgrounds so not every member will be knowledgeable about volatile data. Collecting data is one thing but people will eventually need to know how to understand what the data means. The DFIR community has a few volatile data collection scripts but none of the scripts I found provided the dual functionality for practical and training usage. So I went ahead and wrote a script to meet our needs.

Practical Usage

These were some considerations taken into account to ensure the script is scalable to meet the needs for volatile data collection during actual incident response activities.

        Flexibility

Different responses will have different requirements on where to store the volatile data that’s collected. At times the data may be stored on the same drive where the DFIR toolset is located while at other times the data may be stored to a different drive. I took this into consideration and the volatile data collection script allows for the output data to be stored on a drive of choice. If someone prefers to run their tools from a CD-ROM while someone else works with a large USB removable drive then the script can be used by the both of them.

        Organize Output
 
Troy Larson posted a few lines of code from his collection script to the Win4n6 sometime ago. One thing I noticed about his script was that he organized the output data based on a case number. I incorporated his idea into my script; a case number needs to be entered when the script is run on a system. A case folder enables data collected from numerous systems to be stored in the same folder (folder is named Data-Case#). In addition to organizing data into a case folder, the actual volatile data is stored in a sub-folder named after the system the data came from (system's computer name is used to name the folder). To prevent overwriting data by running the script multiple times on the same system I incorporated a timestamp into the folder name (two digit month, day, year, hour, and minute). Appending a timestamp to the folder name means the script can execute against the same system numerous times and all of the volatile data is stored in separate folders. Lastly, the data collected from the system is stored in separate sub-folders for easier access. The screenshot below shows the data collected for Case Number 100 from the system OWNING-U on 01/01/2012 at 15:46.


        Documentation

Automating data collection means that documentation can be automated as well. The script documents everything in a collection log. Each case has one collection log so regardless if data is collected from one or ten systems an analyst will only have to worry about reviewing one log.


The following information is documented both to the screen for an analyst to see and a collection log file: case number, examiner name, target system, user account used to collect data, drives for tools and data storage, time skew, and program execution. The script prompts the analyst for the case number, their name, and the drive to store data on. This information is automatically stored in the collection log so the analyst doesn’t have to worry about maintaining documentation elsewhere. In addition, the script prompts the analyst for the current date and time which is used to record the time difference between the system and the actual time. Every program executed by the script is recorded in the collection log along with a timestamp of when the program executed. This will make it easier to account for artifacts left on a system if the system is examined after the script is executed. The screenshot below shows the part of the collection log for the data collected from the system OWNING-U.


        Preservation

RFC 3227’s Order of Volatility outlines that evidence should be collected starting with the most volatile then proceeding to the less volatile. The script takes into account the order of volatility during data collection. When all data is selected for collection, the memory is first imaged then volatile data is collected followed by collecting non-volatile data. The volatile data collected is: process information, network information, logged on users, open files, clipboard, and then system information. The non-volatile data collected is installed software, security settings, configured users/groups, system's devices, auto-runs locations, and applied group policies. Another item the script incorporated from Troy Larson’s comment in the Win4n6 group is preserving the prefetch files before volatile data is collected. I never thought about this before I read his comment but it makes sense. Volatile data gets collected by executing numerous programs on a system and these actions can overwrite the existing prefetch files with new information or files. Preserving the prefetch files upfront ensures analysts will have access to most of the prefetch files that were on the system before the collection occurred (four prefetch files may be overwritten before the script preserves them). The script uses robocopy to copy the prefetch files so the file system metadata (timestamps, NTFS permissions, and file ownership) is collected along with the files themselves. The screenshot below shows the preserved files for system OWNING-U.


        Tools Executed

The readme file accompanying the script outlines the various programs used to collect data. The programs include built-in Windows commands and third party utilities. The screenshot below shows the tools folder where the third party utilities are stored.




I’m not going to discuss every program but I at least wanted to highlight a few. Windows diskpart command allows for disks, partitions, and volumes to be managed through the command line. The script leverages diskpart to make it easy for an analyst to see what drives and volumes are attached to a system. Hopefully, the analyst won’t need to open up Windows explorer to see what the removable media drive mappings are since the script displays the information automatically as shown below. Note, to make diskpart work a text file needs to be created in the tools folder named diskpart_commands.txt and the file needs to contain these two commands on separate lines: list disk and list volume.


Mandiant’s Memoryze is used to obtain a forensic image of the system’s memory. Memoryze supports a wide range of Windows operating systems which makes the script more versatile for dumping RAM. The key reason the script uses Memoryze is because it’s the only free memory imaging program I found that allows an image to be stored in a folder of your choice. Most programs will place the memory image in the same folder where the command line is opened. This wouldn’t work because the image would be dropped in the folder where the script is located instead of the drive the analyst wants. Memoryze uses an xml configuration file to image RAM so I borrowed a few lines of code from the MemoryDD.bat batch file to create the xml file for the script. Note, the script only needs the memoryze.exe; to obtain the exe install Memoryze on a computer then just copy memoryze.exe to the Tools folder.

PXServer’s Winaudit program obtains the configuration information from a system and I first became acquainted with the program during my time performing vulnerability assessments. The script uses Winaudit to collect some non-volatile data including the installed software, configured users/groups, and computer devices. Winaudit is capable of collecting a lot more information so it wouldn’t be that hard to incorporate the additional information by modifying the script.

Training Usage

These were the two items put into the script to assist with training members on performing incident response system triage.

        Ordered Output Reports

The script collects a wealth of information about a system and this may be overwhelming to analysts new to examining volatile data. For example, the script produces six different reports about the processes running on a system. A common question when faced with so many reports is how should they be reviewed. The script’s output reports have numbers which is the suggested order for them to be reviewed. This provides a little assistance to analysts until they develop their own process for examining the data. The screenshots below shows the process reports in the output folder and those reports opened in Notepad ++.




        Understanding Tool Functionality and Volatile Data

The script needs to help people better understand what the collected data means about the system where it came from. Two great references for collecting, examining, and understanding volatile data are Windows Forensic Analysis, 2nd edition and Malware Forensics: Investigating and Analyzing Malicious Code. I used both books when researching and selecting the script’s tools to collect volatile data. What better ways to help someone better understand the tools or data then by directing them to references that explain it? I placed comments in the script containing the page number where a specific tool is discussed and the data explained in both books. The screenshot below shows the portion of the script that collects process information and the references are highlighted in red.



Releasing the Tr3Secure Volatile Data Collection Script

There are very few things I do forensically that I think are cool; this script happens to be one of them. There are not many tools or scripts that work as intended while at the same time provide training. People who have more knowledge about volatile data can hit the ground running with the script investigating systems. The script automates imaging memory image, collecting volatile/non-volatile data, and documenting every action taken on the system. People with less knowledge can leverage the tool to learn how to investigate systems. The script collects data then the ordered output and references in the comments can be used to interpret the data. Talk about killing two birds with one stone.

The following is the location to the zip file containing the script and the readme file (download link is here). Please be advised, a few programs the script uses require administrative rights to run properly.

Enjoy and Happy Hunting ...

***** Update *****

The Tr3Secure script has been updated and you can read about the changes in the post Tr3Secure Data Collection Script Reloaded

***** Update *****