NTOSBOOT Prefetch File

Wednesday, December 5, 2012 Posted by Corey Harrell
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 pref.pl)

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.


Summary


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.
  1. Great job, Corey! This really shows what can be achieved using various data sources...in this case, one particular Prefetch file.

    The cool thing is, this is easily automated through tools like pref.pl, which means that it can be automated via the Forensic Scanner, as well.

  2. Besides automation, I think it is important to be aware about the different artifacts available on a system and to incorporate examining them into your process. This allows for a more methodical approach to malware investigations and increases the chances of being successful.

  3. Thank you for pointing to Windows Internals for reference. Anyone doing Windows forensics ought to read it cover to cover--I guess covers to covers now. It's a requirement on my team.

    Troy

  4. Corey,

    Agreed. Automation can help to a degree, particularly when providing a means for analysts who may not know about various artifacts, or may have forgotten, to look for them. The latest version of pref.pl that I use extracts file paths that end in ".exe", ".dat", as well as extracting any path that includes "temp", to include "\Temp\" and "\Temporary Internet Files\". It is extremely useful to see the information presented separately from the rest of the contents that fly by.

    I think that this provides some for analysts who may not be familiar with this aspect of Prefetch analysis something to grasp on to...

  5. Thanks very much Corey for the article. I understood that it was important to review the ntosboot prefect file but had yet to see an example so clearly shown. Much appreciated as always.

    @harlan, the lastest version of pref.pl sounds like a worth inclusion with the extracting technique explained. i'll have to check this out.

  6. Good Job!!
    Thank you for your effort@

  7. @Sploit,

    Thanks. I posted to my blog about it:
    http://windowsir.blogspot.com/2012/03/prefetch-analysis-revisited.html

    As you can see, not a great deal of interest...I think that what you can achieve through these different analysis steps is just too much for most analysts. I'm going to be automating a lot of this in the Forensic Scanner.

  8. In your testing did you notice if the contents within NTOSBOOT changed randomly for any reason during the boot process?

    By that I mean, is it a constant set of entries every time you boot assuming you don't add any software that runs on boot, don't "touch" the box for 30 seconds, etc.

    Is it overwritten during each reboot?

    Does it change throughout the day when using programs, etc.? I know it's for boot, but just curious it is affected by other "stuff".

    It seems like if it was a fixed set of entries each time during the boot process that it would be worth making note of when building standard images to deploy across the network. Then you could perform sanity checks. If it changes randomly then it might be a bit noisy to use as a baseline, but well worth the look during an investigation.

    Good write up.

  9. @Patrick

    Excellent questions and I don't have any answers. I didn't do that kind of testing with the NTOSBOOT prefetch file. My focus was on finding traces of malware during the boot process. If you do find out those answers I would be interested in knowing about it.

Post a Comment