Showing posts with label prefetch. Show all posts
Showing posts with label prefetch. Show all posts

Malware Root Cause Analysis Dont Be a Bone Head Slide Deck

Tuesday, June 3, 2014 Posted by Corey Harrell 0 comments
Today I gave a presentation titled Malware Root Cause Analysis Don't Be a Bone Head at the New York State Cyber Security Conference. This presentation was a follow-up to the presentation I gave last year titled Finding Malware Like Iron Man. Last year I laid out a triage process to find malware and this year I went into more depth discussing how the malware got there in the first place. This post contains the following for my talk: CFP, slide deck, and video I showed.


Computer users are confronted with a reoccurring issue every day. This happens regardless if the user is an employee doing work for their company or a person doing online shopping trying to catch the summer sales. The user is using their computer and the next thing you know it is infected with malware. Even Hollywood is not immune to this issue as illustrated in the TV show Bones.  The most common action to address a malware infection is to reimage, rebuild, and redeploy the system back into production.  Analysis of the system to understand where the malware came from is not a priority or goal.

Root case analysis needs to be performed on systems impacted by malware to improve decision making. The most crucial question to answer is how did this happen since it will determine if we were targeted and more importantly what can be done to mitigate this from re-occurring. Last year, in my presentation Finding Malware Like Iron Man I explored the first step in root cause analysis, which is locating the malware. The next step in root cause analysis is to identify the malware's source.

In this technical presentation Corey will discuss the root cause analysis process to determine how malware infected a computer running the Windows operating system. The topics will include: why perform root cause analysis, how not to perform root cause analysis,  compromise root cause analysis model, attack vector artifacts, and scenarios.

Slide Deck

Malware Root Cause Analysis Don't Be a Bone Head slides viewable online

Malware Root Cause Analysis Don't Be a Bone Head slides PDF file


I chopped up the Bones TV episode The Crack in the Code (Season 7 episode 6) I purchased through iTunes. However, others have posted the segment I used in my presentation. For your viewing pleasure here is "Malware on Bone".

It Is All About Program Execution

Tuesday, January 14, 2014 Posted by Corey Harrell 6 comments
Computer users are confronted with a reoccurring issue every day. This happens regardless if the user is an employee doing work for their company or a person doing online shopping trying to catch the holiday sales. The user is using their computer and the next thing they know it is infected with malware. Then someone gets tasked with resolving the malware issue and one of the first things they need to do is to find the malware. This is a common occurrence that plays out every day to anyone who either uses a computer or is responsible for protecting a network. How the malware gets found depends on the person. Some fire off antivirus scanners, others examine memory, some follow a documented process, and others are not sure where to start. I've talked about my detailed process numerous times and I even shared one of my triage techniques last year. Regardless of the process used, there is one examination step that stands above the rest in locating malware on a system. This step is examining the program execution artifacts.

What Malware Indicators to Look For

As the name implies program execution artifacts show what programs executed on a system and at times what programs were present on the system. The significance of knowing what programs ran can be seen in my corollary to the Rootkit Paradox:

      1. They need to run
      2. They want to remain hidden

Malware wants to remain hidden on a system so it can accomplish what it was designed to do. However, in order for malware to hide on a system a program has to run. This program executes to either hide itself or another piece of malware; in the process it will leave artifacts on the system. These artifacts - program execution artifacts - can be used to find where the malware is hidden. Below are the malware indicators to look for as the program execution artifacts are reviewed (my post Triaging Malware Incidents shows how to use these indicators for triaging).

      - Programs executing from temporary or cache folders
      - Programs executing from user profiles (AppData, Roaming, Local, etc)
      - Programs executing from C:\ProgramData or All Users profile
      - Programs executing from C:\RECYCLER
      - Programs stored as Alternate Data Streams (i.e. C:\Windows\System32:svchost.exe)
      - Programs with random and unusual file names
      - Windows programs located in wrong folders (i.e. C:\Windows\svchost.exe)
      - Other activity on the system around suspicious files

Program Execution Artifacts

Program execution artifacts have been well documented over the years. For example, Harlan put together a post explaining how to determine what programs executed on a system. The key to finding malware is to look for the above indicators in the program execution artifacts and to review all of the artifacts since each one provides different information. To illustrate why the reviewing program execution artifacts examination step stands above the rest I'll walk through the step against a system I infected with malware.

Parsing Program Execution Artifacts

The purpose of this post is to show how just the program execution artifacts can reveal malware on a system as opposed to the tools one should use. However, for completeness I'm sharing the tools I use to parse these artifacts. I use the autorip script along with RegRipper to parse the majority of the artifacts and Nirsoft Winprefetchview to parse the prefetch files.

RecentFileCache.bcf File

The first artifact to review on Windows 7 systems is the recentfilecach.bcf file. This file shows programs that executed on a system and the majority of the time these programs are new to the system. The programs listed here executed recently; within the last 24 hours or when the ProgramDataUpdater task last ran. The RecentFileCache.bcf on my test system showed the following:

c:\program files\common files\java\java update\jusched.exe
c:\users\lab\appdata\local\microsoft\windows\temporary internet files\content.ie5\i87xk24w\n6up2014[1].com
c:\program files\common files\java\java update\jucheck.exe

The one program that stands out is the n6up2014[1].com program since it's located in the temporary Internet files folder.

Prefetch Files

The next artifact to review to identify malware quickly on a system are the Windows prefetch files. Prefetch files show a wealth of information: program's file path, last run time, run count, and files accessed during start-up. Furthermore, the prefetch file's creation date can indicate when the program first ran. Sorting the parsed prefetch files on my test system by the program's file path makes it easier to spot malware. The image below illustrates this.

Similar to the RecentFileCache.bcf, the first malware indication is a randomly named program (n6up2014[1].com) executing from a temporary folder in a user profile. The n6up2014[1].com prefetch file also provides the time of interest to help locate other malware which is 01/10/14 00:38:25 UTC. Prefetch files contain references to the files accessed during start-up and these references can point to other malware. The image below highlights the winupdates.exe program referenced in the n6up2014[1].com prefetch file.

The winupdates.exe program is suspicious since it's a program that executed from the users profile. Also, the winupdates.exe zone.identifier alternate data stream indicates the program was downloaded from a different security zone (the Internet). Furthermore, the program executed around the same time as the n6up2014[1].com program. Sorting prefetch files by last modification is a fast and simple method to find other malware on the system. The image below shows the prefetch files sorted by last modification time.

The image above didn't highlight any other potential malware but it does reveal the netsh.exe program executed around the same time as the malware. netsh.exe is a program to "administrator can use to configure and monitor Windows-based computers at a command prompt."

AppCompatCache Registry Key

The next artifact to review to identify malware on a system is the AppCompatCache registry key located in the System hive. Mandiant highlighted the significance of this artifact in their article "Leveraging the Application Compatibility Cache in Forensic Investigations." This article not only shows executables that executed on the system but it also shows executables which were present on the system. The AppCompatCache key from my test system also showed the same suspicious programs with malware indicators.

UserAssist Registry Key

Continuing on with the examination the next artifact to review is the userassist registry key located in the user account's NTUSER.DAT hive. This registry key sheds light on "what programs the user has launched via the Explorer shell." The image below shows the portion of the userassist registry key for the user account where the suspicious programs were located and the timeframe of when they executed.

As can be seen, the image doesn't reveal other malware but it does show the user executed their web browser prior to the infection. This information about the potential source of the malware isn't a surprise since the n6up2014[1].com file was located in the temporary Internet files folder and the winupdates.exe had a zone.identifier alternate data stream.

MUICache Registry Key

Continuing on with the examination is reviewing the muicache registry key located in the user account's NTUSER.DAT (for Windows XP) or UsrClass.dat (for Windows 7) hive. The muicache shows programs that ran under the context of the user account and is another area to look for malware indicators. The muicache from my test system didn't reveal any useful information as shown below.

AppCompatFlags Registry Key

The search for malware indicators should continue by reviewing the AppCompatFlags registry key. This artifact contains information about program execution and is more relevant for Windows 8 systems compared to Windows 7. This registry key hasn't been created on my Windows 7 test system as shown below.

Tracing Registry Key

It may be tempting to stop the examination and follow up on the programs already identified but doing so may result in overlooking other malware. The next artifact to review is the tracing registry key located in the System hive. This key may contain program execution for programs with networking capabilities. The tracing registry key from my test system didn't reveal any useful information as shown below.

Legacy Registry Keys

The last program execution artifact to review is the legacy registry keys located in the System hive. These keys can be helpful to locate malware which installs itself as a Windows service. The legacy registry keys from my test system didn't reveal any useful information as shown below (notice the lack of entries for my timeframe of interest).

Wrapping Things Up

Solely focusing on examining the program execution artifacts identified malware on the test system. Specifically, the following malware was identified:

C:\Users\lab\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\I87XK24W\n6up2014[1].com

In addition to locating malware it was also determined the netsh.exe program executed around the same time as the infection. The activity identified in the program execution artifacts matches the activity observed when analyzing the n6up2014[1].com program. n6up2014[1].com creates on the system and executes the winupdates.exe program while netsh.exe is used to modify the Windows firewall.

Knowing the information discovered by reviewing program execution artifacts will empower anyone who is tasked with resolving a malware issue. This is the same technique I have been using for years to find malware on systems extremely fast. Normally I can find malware in minutes; in less than 10 minutes. This is why I stand by my comment examining program execution artifacts stands above the rest of the examination steps in locating malware on a system. This is why my response to anyone asking for help in locating malware is to start by examining the program execution artifacts.

NTOSBOOT Prefetch File

Wednesday, December 5, 2012 Posted by Corey Harrell 9 comments
Knowing the programs that executed on a system can answer numerous questions. The answers can help on a range of cases from acceptable use policy violations to investigations to intrusions to malware. One program execution artifact is prefetch files which have been well documented including in the article Decoding Prefetch Files for Forensic Purposes and on the Prefetch Wiki page. The purpose of this post is to explore the NTOSBOOT prefetch file and how it is relevant for malware investigations.

What is the NTOSBOOT Prefetch File

The Windows operating system enables prefetching to make system boots or applications startups faster. Windows Internals, Part 2: Covering Windows 2008 Server R2 and Windows 7 states “the prefetcher tries to speed the boot process and application startup by monitoring the data and code accessed by boot and application startups and using that information at the beginning of a subsequent boot or application startup to read in the code and data”. Prefetch files are what store the information required for faster startups.

The NTOSBOOT prefetch file stores the information related to the boot process. The information in this prefetch file reflects the files accessed during system startup. Specifically, the files accessed, according to the Windows Internals, “from system start through the 30 seconds following the start of the user’s shell (typically Explorer) or, failing that, up through 60 seconds following Windows service initialization or through 120 seconds, whichever comes first”.

Relevance for Malware Investigations

The NTOSBOOT prefetch file stores information about the files accessed during the boot process and in some cases 30 seconds following a user logging onto a system. Remember the Rootkit Paradox, malware wants to hide but it must run. If a piece of malware runs during the boot process then there will be a reference for the malware in the NTOSBOOT prefetch file. To illustrate this point I examined a NTOSBOOT prefetch file to show how it contains traces of malware execution. (side note: to view the file handles in prefetch files one could use Strings or Harlan’s

The NTOSBOOT prefetch file in question came from a system I infected last year by opening the attachment in a NYS Department of Motor Vehicles Uniform Traffic Ticket email. Looking through the file handles for any unusual file paths (files in temporary folders, unusual file names, etc) I came across three suspicious files as shown below.

The first file 17F7FFF4.COM was suspicious since the file was located in the All Users temporary folder. The second file KB961710.exe was suspicious because Windows updates are not stored in the application data folders. The last file SVCHOST.EXE was suspicious since not only was it located in a temp folder but the svchost.exe file is normally located in the Windows\System32 folder. I located these files by solely reviewing the file handles referenced in the NTOSBOOT prefetch file and the screenshot below confirms my suspicions.


Program execution artifacts are vital when examining a system infected with malware. Despite malware’s best efforts to hide on a system at some point for them to do their jobs they have to run. When malware eventual runs there will be traces of its execution left on a system which can be used to find its hiding spot. The NTOSBOOT prefetch file is one such artifact and the file handle information will reveal what’s hiding on a system.

Combining Techniques

Wednesday, July 11, 2012 Posted by Corey Harrell 3 comments
“You do intrusion and malware investigations, we do CP and fraud cases” is a phrase I saw Harlan mention a few times on his blog. To me the phrase is more about how different the casework is; about how different the techniques are for each type of case. Having worked both fraud and malware cases I prefer to focus on what each technique has to offer as opposed to their differences. How parts of one technique can be beneficial to different types of cases. How learning just a little bit about a different technique can pay big dividends by improving your knowledge, skills, and process that you can use on your current cases. To illustrate I wanted to contrast techniques for malware and fraud cases to show how they help one another.

Program Execution

Malware eventually has to run and when it does execute then there may be traces left on a system. Understanding program execution and where these artifacts are located is a valuable technique for malware cases. Examining artifacts containing program execution information is a quick way to find suspicious programs. One such artifact is prefetch files. To show their significance I’m parsing them with Harlan’s updated script. Typically I start examining prefetch files by first looking at what executables ran on a system and where they executed from. I saw the following suspicious programs looking at the output from the command “pref.exe -e -d Prefetch-Folder”. Last run: Fri Mar 12 16:29:05 2010 (1)
\DEVICE\HARDDISKVOLUME1\DOCUME~1\ADMINI~1\LOCALS~1\TEMP\TMP77E.EXE Last run: Fri Mar 12 16:29:07 2010 (1)

These programs stood out for a few different reasons. First I noticed the path they executed from was a temporary folder in a user’s profile. Unusual file paths are one way to spot malware on a system. The other thing I noticed is that some of the programs only executed once. This behavior resembles how downloaders and droppers work. Their sole purpose is to execute once to either download additional malware or install malware. The last dead giveaway is they all executed within a few minutes of each other. The first sweep across the prefetch files netted some interesting programs that appear to be malicious. The next thing to look at is the individual prefetch files to see what file handles were open when the program ran. The prefetch file showed something interesting as shown below (the command used was “ -p -i -f”).

Volume Creation Date: Fri Nov 2 08:56:57 2007 Z
Volume Serial Number: 6456-B1FD


EXEs found:


DAT files found:


Temp paths found:


The file handle portion to the output was trimmed to make it easier to read but I left in the intelligence provided by the script through its filters. The filters highlight file handles containing exes, dats, and temporary folders. The exe filter shows in additional to a handle to the TMP77E.EXE file there were handles to SC.EXE, NET.EXE, and ASR64_LDM.EXE. SC.EXE is a Windows program for managing services including creating new services while NET.EXE is a Windows program for doing various tasks including starting services. ASR64_LDM.EXE was another suspicious program that ran on the system after TMP77E.EXE. The file handles inside each prefetch file of interest provided additional information which is useful during a malware case.

Program execution is vital for malware cases and I saw how the same technique can apply to fraud cases. On fraud cases a typical activity is to identify and locate financial data. At times this can be done by running keyword searches but most of the time (at least for me) the actual financial data is unknown. What I mean by this is a system is provided and it’s up to you to determine what data is financial. This is where the program execution technique comes into play. The programs that ran on the system can be reviewed to provide leads about what kind of financial data may be present on the system. Using the first sweep across the prefetch files I located these interesting programs (command used was “pref.exe -e -d Prefetch-Folder”). Note: the system being looked at is not from a fraud case but it still demonstrates how the data appears. Last run: Tue Jul 10 16:42:26 2012 (42)

When I look at program execution for fraud cases I look for financial applications, applications that can create financial data, and programs associated with data spoliation. The system didn’t have any financial or data spoliation programs but there were office productivity applications capable of creating financial documents such as invoices, receipts, proposals, etc. These programs were Microsoft Office and Adobe Acrobat and this means the data created on the system is most likely Word, Excel, Powerpoint, or PDFs. The number of executions for each program is also interesting. I look to see what applications are heavily used since it’s a strong indication about what program the subject uses. Notice Adobe only ran once while Word was ran 42 times. Looking at the file handles inside individual prefetch file also contains information relevant to a fraud case. Below are a few sanitized handles I found in the prefetch file (the command used was “ -p -i -f”).

Volume Creation Date: Fri Aug 26 18:13:26 2011 Z
Volume Serial Number: E4DD-S23A


The file handles shows documents stored in the folder FORENSICS\RESEARCH\Folder\ on a different volume were accessed with Word. I think this is significant because not only does it provide filenames to look for but it also shows another storage location the subject may have used. Where ever there is storage accessible to the subject then there’s a chance that is where they are storing some financial data. Also, notice in the output how the last line shows one of the documents was downloaded from the Internet (zone identified alternate data stream).

User Activity

The program execution showed how fraud cases benefited from a technique used in malware cases. Now let’s turn the tables to see how malware cases can benefit from fraud. As I mentioned before most of the times I have to find where financial data is located whether if it’s on the system or in network shares. The best approach I found was to look at artifacts associated with user activity; specifically file, folder, and network share access. My reasoning is if someone is being looked at for committing a fraud and they are suspected of using the computer to commit the fraud then they will be accessing financial data from the computer to carry out the fraud. Basically, I let their user activity show me where the financial data is located and this approach works regardless if the data is in a hidden folder or stored on a network. There are numerous artifacts containing file, folder, and network share access and one of them is link files. To show their significance I’m parsing them with TZWorks LNK Parser Utility. When I examine link files I parse both the Recent and Office/Recent folders. This results in some duplicates but it catches link files found in one folder and not the other. I’ve seen people delete everything in the Recent folder while not realizing the Office\Recent folder exists. I saw some interesting target files, folders, and network shares by running the command “dir C:\Users\Username\AppData\Roaming\Microsoft\Windows\Recent\*.lnk /b /s | lp -pipe -csv > fraud_recent.txt”.

{CLSID_MyComputer}\E:\Forensics\Research\Folder\sanitized 2.doc
{CLSID_MyComputer}\E:\Forensics\Research\Folder\sanitized 3.doc
{CLSID_MyComputer}\C:\Atad\material\sanitized 1.pdf
\\\ share\TR3Secure

The output has been trimmed (only shows target file column) and sanitized since it’s from one of my systems. The link files show files and folders on removable media and a network share has been accessed in addition to a folder not inside the user profile. I’ve used this same technique on fraud cases to figure out where financial data was stored. One time it was some obscure folder on the system while the next time it was a share on a server located on the network.

Tracking user activity is a great way to locate financial data on fraud cases and I saw how this same technique can apply to malware cases. On malware cases it can help answer the question how did the computer become infected. Looking at the user activity around the time of the initial infection can help shed light on what attack vector was used to compromise the system. Did the user access a network share, malicious website, removable media, email attachment, or peer to peer application? The user activity provides indications about what the account was doing that contributed to the infection. On the malware infected system there were only two link files in the Recent folder shown below is the target create time and target name (command used was “dir "F:\Malware_Recent\*.lnk" /b /s | lp -pipe -csv > malware_recent.txt”).

3/12/2010 16:17:04.640 {CLSID_MyComputer}\C:\downloads
3/12/2010 16:18:59.609 {CLSID_MyComputer}\C:\downloads\link.txt

These link files show the user account accessed the downloads folder and the link text file just before the suspicious programs started executing on the system. Looking at this user activity jogged my memory about how the infection occurred. I was researching a link from a SPAM email and I purposely clicked the link from a system. I just never got around to actually examining the system. However, even though the system was infected on purpose examining the user activity on the malware cases I worked has helped answer the question how did the system become infected.

Closing Thoughts

DFIR has a lot of different techniques to deal with the casework we face. Too many times we tend to focus on the differences; the different tools, different processes, and different meanings of artifacts. Focusing on the differences distracts from seeing what the techniques have to offer. What parts of the techniques can strengthen our processes and make us better regardless of what case we are up against. If I didn’t focus on what the techniques had to offer then I would have missed an opportunity. A chance to develop a better DFIR process by combining malware and fraud techniques; a process that I think is far better than if each technique stood on their own.

Second Look at Prefetch Files

Monday, March 19, 2012 Posted by Corey Harrell 1 comments
The one thing I like about sharing is when someone opens your eyes about additional information in an artifact you frequently encounter. Harlan has been posting about prefetch files and the information he shared changed how I look at this artifact. Harlan’s first post Prefetch Analysis, Revisited discussed how the artifact contains strings -such as file names and full paths to modules that were either used or accessed by the executable. He also discussed how the data can not only provide information about what occurred on the system but it could be used in data reduction techniques. One data reduction referenced was searching on the file paths for words such as temp. Harlan’s second post was Prefetch Analysis, Revisited...Again... and he expanded on what information is inside prefetch files. He broke down what was inside a prefetch from one of my test systems where I ran Metasploit against a Java vulnerability. His analysis provided more context to what I found on the system and validated some of my findings by showing Java did in fact access the logs I identified. Needless to say, his two posts opened my files to additional information inside prefetch files. Additional information I didn’t see the first the first time through but now I’m taking a second look to see what I find and to test out how one of Harlan's data reduction techniques would have made things easier for me.

Validating Findings

I did a lot of posts about Java exploit artifacts but Harlan did an outstanding job breaking down what was inside one of those Java prefetch files. I still have images from other exploit artifact testing so I took a look at prefetch files from an Adobe exploit and Windows Help Center exploit. The Internet Explorer prefetch files in both images didn’t contain any references to the attack artifacts but the exploited applications’ prefetch files did.

The CVE-2010-2883 (PDF Cooltype) vulnerability is present in the cooltype.dll affecting certain Adobe Reader and Acrobat versions. My previous analysis identified the following: the system had a vulnerable Adobe reader version, a PDF exploit appeared on the system, the PDF exploit is accessed, and Adobe Reader executed. The strings in the prefetch file helped to validate the attack because it shows that Adobe Reader did in fact access the cooltype.dll as shown below.


The prefetch file from the Windows Help Center URL Validation vulnerability system showed something similar to the cooltype.dll exploit. The Seclists Full disclosure author mentioned that Windows Media Player could be used in an attack against the Help Center vulnerability. The strings in the prefetch file showed the application did access a Windows Media Player folder during the exploit.


Finding Malware Faster

Prefetch files provided more information about the exploit artifacts left on a system. By itself this is valuable enough but another point Harlan mentioned was using the strings inside prefetch files for data reduction. One data reduction technique is to filter on files' paths. To demonstrate the technique and how effective it is at locating malware I ran strings across the prefetch folder in the image from the post Examining IRS Notification Letter SPAM. (note, strings is not the best tool to analyze prefetch files and I’m only using the tool to illustrate how data is reduced) I first ran the following command which resulted in 7,905 lines.

strings.exe –o irs-spam-email\prefetch\*.pf

I wanted to reduce the data by only showing the lines containing the word temp to see if anything launched from a temp folder. To accomplish this I ran grep against the strings output which reduced my data to 84 lines (the grep -w switch matches on whole word and –i ignores case).

strings.exe –o irs-spam-email\prefetch\*.pf | grep –w –i temp

The number of lines went from 7,905 down to 84 which made it fairly easy for me to spot the following interesting lines.



Using one filtering technique enabled me to quickly spot interesting executables in addition to the possibly finding the initial infection vector (a malicious zip file). This information was obtained by running only one command against the files inside a prefetch folder. In hindsight, my original analysis on the prefetch files was fairly limited (executable paths, runcounts, and filenames) but going forward I'll look at this artifact and the information they contain in a different light.