Windows Systems and Artifacts in Digital Forensics, Part II
Публикувано: 2018-09-29 16:15:26
For Part I of these series, please visit this page: https://resources.infosecinstitute.com/windows-systems-and-artifacts-in-digital-forensics-part-i-registry/
This article begins with event logs and discusses their headers’ structure and the structure of their building blocks—the headers of the event records. It mentions some open source tools that can parse event logs and briefly explores event logs on versions of Windows below and above Windows Vista, along with an exploration of their characteristics. Links to pages of the MSDN are provided for further reference on event logging.
Then the article continues with a brief examination of the three computer sleep modes (sleep, hibernation, and hybrid sleep) and their significance for forensic analysts. To enable you to picture this point, an explanation is given about what happens to information that is deleted from the computer with the standard “Delete” button or through the contextual menu. This explanation is useful in the context of the discussion as writing the data on the HDD makes it useful to forensic analysts beyond the point of deletion.
Finally, we have provided a list of quick ways to remove artifacts from your Windows system. Removal of objects such as thumbs.db, hiberfil.sys, pagefile.sys, metadata, Index.dat is discussed in this chapter and it concludes with mentioning the names of a few programs that claim to permanently remove data from your computer.
Event logs have headers for the particular file and headers for the particular entries and both have the unique identifier (signature) “LfLe” included in their structure. Their length can be viewed as variable. Figure 1 reveals the structure of an entry header.
Figure 1: This illustrates the structure of an event log’s entry header. It is based on the one provided by Jeff Hamm in his paper “Carve for Records, Not Files.” Available at: https://computer-forensics.sans.org/summit-archives/2012/carve-for-record-not-files.pdf
Windows NT, 2000, XP, and 2003 use a logging system called event logging. The MSDN site contains information concerning the structures that make up event logs (https://msdn.microsoft.com/en-us/library/windows/desktop/aa363652(v=vs.85).aspx). These structures are all well-known and it is not difficult to write tools that parse the event records that these logs contain in a binary form and also extract them from the unallocated space. Parsing a binary form is valuable because the header clusters of the event log files may output a number of event records in the particular file, whereas if you parse it in a binary form extra event records may be produced. The Event Log file extension is “.evt.”
Event log headers are 48 bytes long, marking the beginning of the event log, and they can contain very useful data for forensic examiners. The header can be used to validate the file; it includes starting and ending offsets, which contain data pinpointing where the most aged event record is situated to the Microsoft API and data showing where the ending record is situated, respectively. Records contained within event logs all have a unique identifier referred to by Microsoft as a signature; this identifier is “LfLe” and 0x654c664c in the hexadecimal notation.
We mentioned previously that the headers of event log files are 48 bytes in size and that is additionally specified in the 4-byte DWORD value that brackets the header record (it can be located both in the record’s start and in its ending); in the given case, the value is 48 or 0x30, which is valuable to know because the event record’s header, as opposed to the event log file’s header, has a size of 56 bytes and does not have any of the real subject-matter of the file embedded in it. Event records are bracketed by size values as well.
Offsets pointing to the strings, the lengths of strings, UserSID, where appropriate, and data input in the event entry are all parts of the event record’s structure and they reveal data about the entry itself. Furthermore, two time stamps are inserted in the event record’s header: one pinpointing when the particular event was generated or “came to life” and another showing when the event was written to the .evt. The gmtime() function in Perl can effortlessly transform the 32-bit Unix times of the time stamps into legible dates.
One can make use of evtparse.pl, an open source tool, to parse the information from the relevant .evt files. Evtparse.pl simply extracts the data and outputs the event record information, while evtrtp.pl not only produces the event record data but also scans this data and outputs information concerning the regularity of different SIDs, sources for the event records, and the data range of all entries located in the file as well (statistics). Such information comes in handy when an analyst is searching for a bustle that happened on the machine at a given time. For instance, if an analyst parses an event log in search of a particular event ID or a specific event, he/she can see whether it is present within the file or whether the date range of the accessible event entries includes the exposed window or whether events of interest exist within the given time frame when the incident occurred and can save himself/herself a substantial amount of time by moving to a different source of data if the search brings no results.
The latest editions of Windows (Windows Vista and later versions) resort to the Windows event log mechanism, which entirely replaces the event logging mechanism of the previous Windows versions, such as Windows NT, 2000, XP, and 2003. The Windows event log mechanism is much more complicated; specifics can be examined at the MSDN Windows Event Log Reference (https://msdn.microsoft.com/en-us/library/windows/desktop/aa385785(v=vs.85).aspx). Partially, the change that was done to the new Windows event log scheme is that the structure of the recorded events and the way they are recorded was modified. A tool based on the Perl high-level programming language was developed to parse Windows event logs on versions of Windows Vista and beyond, named evtxparse.pl.
Modes of Computer Sleep and Deleted Data
Computers, just like humans, need time to rest; alternatives to shutting the machine down are sleep and hibernation. From a user perspective, sleep/hibernation saves a considerable amount of energy and allows users to resume all processes and applications from where they left them off. Furthermore, sleep/hibernation may be safer than leaving the computer on when you are taking a lunch or a coffee break because, when the computer is awakened from its rest, it may be set to prompt for a username and password, although a simple log off would have the same effect if you decide to leave it on.
When the computer is sleeping, it needs extremely small amounts of power to maintain and if a laptop’s battery gets critically low this sleep will be “transformed” to hibernation. There is an extremely large difference in the evidence that can be collected from the two states.
Hibernation and hybrid sleep are considered “deep sleep” modes because they store the data related to the processes and applications running on the computer on the hard disk, instead of storing it in the main memory (sleep mode).
There are three different modes of rest that computers can immerse into: sleep, hibernation, and hybrid sleep.
Explanation: Deleted Data
To get a picture of why sleep and hibernation differ enormously in importance for forensic examiners we will briefly discuss what happens when a user deletes data from his hard drive:
- User deletes a file(s).
- The computer receives the input from the relevant input device (keyboard/mouse, etc.)
- The computer marks the space that the file(s) occupied as available.
- The “removed” file(s) remain(s) untouched until a new one take its/their place and overwrites it/them
Basically, what happens is that the file moves from the allocated space to the unallocated space.
Allocated space can be explained as being all the files that we can view and execute in Windows. All files located in the allocated space cannot be overwritten as the section of the hard drive where they are located is reserved for them; new files can only be stored in the unallocated space (on standard computers).
Thus, if you have a 1 TB HDD with 500 GB of allocated space and you delete an incriminating document that holds 5 MB of space, you will be left with 523.999023 GB unallocated space on raw calculations and 523.475024 GB if you take into account the fact that HDDs start with 99.9% unallocated space, which means that a very long period of time may pass before the 5 MB that held the incriminating document gets overwritten by new files.
Usually, files in the unallocated space are identified by means of their distinctive features. Examples of these distinctive features (or signatures) are file headers and footers that may identify files and signal both their beginning and end. The process of extracting data from the unallocated space is called “file carving” and it is usually performed via tools but it can also be performed manually. However, we will discuss file carving in a separate article.
Microsoft likens sleep to “pausing a DVD player” (Microsoft’s Windows sleep and hibernation FAQ), as its function is to resume the processes and programs running on the computer as promptly as possible (besides conserving energy). What happens in sleep mode is that a minute amount of power gets constantly fed to the main memory, which conserves the data unimpaired. However, the main memory (or RAM) is a volatile memory, so the data vanishes as soon as the power is removed. Therefore, sleep is not a great source of evidence for forensic examiners.
Hibernation uses the least amount of power of the three sleep modes. In hibernation, the computer creates a snapshot of all the data in RAM and writes it on the HDD. Nevertheless, it is mostly designed for laptops, not desktops.
MoonSols Windows Memory Toolkit enables forensic analysts to read and write the Windows hibernation file.
It can be inferred from its name that hybrid sleep is a mixture of the modes “sleep” and “hibernation”; it is intended for desktops rather than laptops. In this mode, the computer preserves insignificant amounts of power applied to the machine’s RAM (to maintain the data and the applications present before the hybrid sleep) and writes this data to the HDD. Suspects might miss these hibernation files and the page file(s) as they are unknown to many computer users and are frequently neglected during last minute “delete-a-thons.”
Erasing Windows Artifacts
In this section, we provide a few methods of erasing artifacts.
Thumbs.db, which is a cache in Windows that stores thumbnail images of all graphics files and is a valuable Windows artifact, can be disabled by clicking Start -> Control Panel -> Folder Options -> View -> check the button “Always show icons, never thumbnails” in the Files and Folders section -> Apply -> OK. This action will stop thumbs.db from reappearing after being deleted (this procedure for disabling it is for Windows Vista and Windows 7). Thumbs.db can also be deleted in Windows XP by clicking on My Computer -> Tools -> Folder Options -> View -> check “Do not cache thumbnails” -> OK. However, performance will drop when you browse through your hard drive’s partition’s contents. There are numerous thumbs.db files scattered across your computer and you will only see them if you enable the “Show Hidden Files and Folders” option in Windows.
Also, the evidence that may be piled up in the hibernation’s file hiberfil.sys (all processes, programs, applications and files opened in a given session are written to the hard drive when you put your computer in hibernation) may be removed without the file coming back by disabling the hibernation function. You disable it by opening the command prompt with administrative privileges and typing “powercfg.exe –h off” (for Windows Vista, Windows 7, and Windows XP).
Furthermore, free programs such as Index.dat Analyzer can remove all Index.dat files present on the computer until Windows recreates them. Index.dat is an invaluable source of data for forensic analysts, as it stores data on each website you open. Websites offering services like search engines and online banking are kept in such files, as well as e-mails that you have sent through Microsoft Outlook and Microsoft Outlook Express. Index.dat files are cloaked and not hidden, so you will be unable to access them through the Windows built-in “Find” or “Search” option and they are not shown because cloaked files are handled in a different way than hidden files. Furthermore, files with the index.dat name are being constantly utilized while Windows is in use, so it is impossible to remove them without leaving Windows first. The deletion options embedded in IE do not enable you to remove index.dat files and the only other option to deleting index.dat outside of Windows is killing the explorer.exe process and starting a command shell.
Figure 2: Index.dat Analyzer’s interface.
In Figure 2, we see Index.dat Analyzer ready to remove entries in an IE’s index.dat file. Index.dat Analyzer can remove an entry or numerous entries if you check them in the box on the left of the screen, or it can delete the whole index.dat file. Importantly, you can also view separate entries stored in the file, and you can add other index.dat files to the list of entries. In this particular picture, we see that each Skype contact’s avatar is stored in the index.dat file. This particular index.dat file has 5209 entries although IE has been left largely unused on the given machine. There may be index.dat files that are not related to Internet Explorer but to other programs and there may be several index.dat files for IE, depending on whether their purpose is storing the browser’s history, cache, or cookies. After deletion, index.dat will be created again but its contents would start from blank so any sensitive data on it would be lost.
Figure 3 – A view of an entry of Index.dat’s cache of an image originating from Facebook
Pagefile.sys is a hidden file that is used when the user has used up the existing RAM on his machine; it serves as a virtual memory file. It is basically resorted to when Windows needs more memory, in which case it turns to the HDD in the form of pagefile.sys for more space and, because the hard drive is much slower than the RAM, running many programs at once would cause the system to slow down. What it does is that, when an application is taking too much memory, most unused processes in RAM get placed into pagefile.sys so there may be more memory for the programs that you are actually working with. Thus, once you get rid of it and you have insufficient RAM, the processes and programs that you are running are going to break down without giving you time to save or do anything, among other issues that may arise. You may try is disable pagefile.sys, delete it, and enable it again to recreate the pagefile.sys but this is somewhat pointless, as explained below. Similarly to hiberfil.sys, pagefile.sys stores the processes that were running in your RAM at a given time, though the difference is that pagefile.sys does not store everything that was in your RAM at a given moment. To disable paging go to Start -> Control Panel -> Systems -> Advanced System Properties -> click on the Advanced tab -> Performance -> Settings Performance options -> go to another tab “Advanced” -> Virtual Memory -> Change -> pick a system drive and choose no paging file followed by the OK/Apply button. Finally, restart the machine.
Note that pagefile.sys is quite important for the decent performance of the system and there might be no need to reset its contents as pagefile.sys is going through constant changes as you use your computer.
Furthermore, users can minimize metadata. The process is easy for MS Office applications like Excel, PowerPoint, and Word. The user simply clicks File -> Check for Issues -> Inspect Document, inspects it for metadata, and deletes the parts that he wants to get rid of.
Figure 4: Checking a Word document for available metadata
Figure 5: Using MS Word’s Document Inspector to remove the file’s metadata
Lastly, there are gazillions of tools that promise to remove permanently data from your HDD by overwriting it numerous times. Examples are Eraser, Sdelete, and Evidence Eliminator, among many others.
We have restrained ourselves in this point to discussing the removal of several artifacts, but others can also be removed, to some extent, by cyber-criminals.
It can be concluded from our discussion so far that Windows users leave a lot of tracks on their machine when they perform their daily chores. These tracks can be extracted by forensic analysts and utilized as evidence. Fortunately, few cyber-crooks manage to erase all of them from their machine and even fewer know about all of these potential tracks.
Lastly, it can be inferred from the context of our discussions that even people who sell their second-hand computers on eBay should be cautious because sensitive information can easily be leaked to curious buyers.
- Cory Altheide and Harlan Carvey, “Digital Forensics with Open Source Tools,” 2011
- John Sammons, “The Basics of Digital Forensics,” 2012
- Windows, “Sleep and hibernation: frequently asked questions.” Available at: https://windows.microsoft.com/en-us/windows7/sleep-and-hibernation-frequently-asked-questions
- Where is your data, “What is unallocated space?” Available at: https://whereismydata.wordpress.com/2008/10/03/what-is-unallocated-space/
- Wikipedia, “Hibernation.” Available at: https://en.wikipedia.org/wiki/Hibernation_(computing)
- rhiannon, “What are Thumbs.db Files and Can I Delete Them?” Available at: https://www.techsupportalert.com/content/what-are-thumbsdb-files-and-can-i-delete-them-windows.htm
- Bill Detwiler, “Delete Hiberfil.sys by disabling Windows Hibernate function.” Available at: https://www.techrepublic.com/blog/tr-dojo/delete-hiberfilsys-by-disabling-windows-hibernate-function/
- Wikipedia, “Index.dat.” Available at: https://en.wikipedia.org/wiki/Index.dat
- n|u – The Open Security Community, “Windows Forensic Artifacts.” Available at: https://www.slideshare.net/null0x00/windows-forensic-artifacts
- Lifehacker.com, “Understanding the Windows Pagefile and Why You Shouldn’t Disable It.” Available at: https://lifehacker.com/5426041/understanding-the-windows-pagefile-and-why-you-shouldnt-disable-it
- Jeff Hamm, “Carve for Records, Not Files.” Available at: https://computer-forensics.sans.org/summit-archives/2012/carve-for-record-not-files.pdf
Ivan is a student of IT and Information Security. He is currently working toward a Master's degree in the field of Informatics in Sweden. He is also a freelance web developer engaged in both front-end and back-end coding and a tech writer. Whenever he is not in front of an Interned-enabled device, he is probably reading a print book or traveling.