Module 4

Windows and Unix Forensics Investigation

4.1 Investigating Windows Systems - File Recovery, Windows Recycle Bin Forensics,
Data Carving, Windows Registry Analysis, USB Device Forensics, File Format
Identification, Windows Features Forensics Analysis, Windows 10 Forensics, Cortana
Forensics
4.2 Investigating Unix Systems - Reviewing Pertinent Logs, Performing Keyword
Searches, Reviewing Relevant Files, Identifying Unauthorized User Accounts or
Groups, Identifying Rogue Processes, Checking for Unauthorized Access Points,
Analyzing Trust Relationships
4.1 File Recovery
Analysis of deleted files is a key task in any type of digital forensic investigation. To
become a successful digital forensic examiner, you must know how Windows deletes files;
where such files can be located, even after they are deleted; and methods/ techniques to
investigate these files (e.g., retrieving deleted files’ metadata to support a criminal
investigation). In this section, we will list some tools and techniques to recover critically
important documents and file fragments that can help us solve the case at hand.
Windows Recycle Bin Forensics:
The Windows recycle bin—first introduced in Windows 95—contains files that have
been deleted by users but still exist within the system. For instance, when a user deletes a file
(using the standard delete button on the keyboard after selecting the target file OR selecting a
file, right-clicking it, and choosing “Delete” from the pop-up menu), Windows moves the
subject file to the recycle bin without deleting it permanently. This is the default behavior of
Windows; however, a user can configure the recycle bin settings to permanently delete files
without moving them into the recycle bin; besides, some users press and hold the Shift key
when deleting a file to delete it permanently without moving it into the recycle bin. In practice,
few people employ permanent deletion of recycled files (or even know about it); this makes it
possible for the recycle bin to hold important recycled artifacts, which are considered a valuable
source for digital evidence. As we already said, when a user deletes a file, the default behavior
of Windows is to move it into the recycle bin. Different versions of Windows have different
recycle bin file names and locations. For Windows XP (formatted using the FAT file system),
deleted files are stored in the “Recycler” folder in the root directory where Windows is installed
(usually the C:\ drive), which in turn holds another important file named “INFO2.”Both
“Recycler” and “INFO2” are hidden files: you must first display hidden files—including OS
files—to display them. Inside the “Recycler” folder, we can see one or more folders; these
folders are named according to each user’s specific security identifier (SID) (e.g., S-1-5-21-
2602240047-739648611-3566628919-501); if a system has more than one user, then each one
will have its own folder that stores the deleted files belonging to that user account. There is
also another important file inside each user recycle bin folder called “INFO2”; this file contains
an index of all the files that have been previously deleted by the user. It also contains metadata
about each deleted file like its original path, file size, and date/ time when it was deleted.
 With Vista and beyond (7, 8, 8.1, and 10), Windows has changed both the
recycle bin main folder and the way deleted files are organized. For instance, deleted files are
stored in a folder named “$[Link],” under which there is a subfolder for each user on the
system named using that user’s SID. The “$[Link]” is stored under the C:\ drive
(assuming Windows is installed there). Now, in these modern versions of Windows, when a
file is deleted, Windows will move it into the recycle bin as two files: one contains the actual
data of the recycled file (its name begins with “$R”), while the other contains the deleted file’s
metadata (its name begins with “$I”). Obviously, this discards the need for the “INFO2” file
from older Windows versions, which was used to store recycled a file’s metadata.
Now, let us experiment with deleting a file and analyzing it using Windows 10
and a free tool called $I Parse. Open a command-line prompt; use the CD command to change
the working directory into the $[Link] folder under the C:\ drive. Display the folder
contents using the DIR command followed by the /a switch (to display hidden system files).
These commands are displayed in Figure 4.1

Figure 4.1 Viewing $[Link] contents under Windows 10 using DOS prompt
As we note from Figure 4.1, the $[Link] contains four subfolders: these are SID
subfolders and correspond to the SID of the user who deleted the file. Each subfolder is created
the first time a user deletes a file that is sent to the recycle bin. Now, to learn the name of the
user account which owns a specific SID subfolder, we need to use the following command:
wmic useraccount get name,sid This will display all user accounts on the target machine, so
now we can learn which SID subfolder in the [Link] belongs to the target user (see
Figure 4.2).
 Figure 4.2 Knowing the owner of a specific SID subfolder within $[Link]
After knowing which recycle bin belongs to the target account, we can access it using
the CD command. Use the DIR command with the /a switch to display its contents (see
Figure 4.3).
 Figure 4.3 Viewing target recycle bin: contents display two deleted files.
From Figure 4.3, we can note that the target recycle bin has four files belonging to two
deleted files (see Figure 4.4). As we already said, each deleted file has two files in the recycle
bin, a metadata file and the actual data (recoverable data) of the deleted file

Figure 4.4 Two deleted files in the recycle bin

Now, let us investigate the deleted file’s metadata, also known as index files (begin
with $I), in the recycle bin of Windows Vista and later using a free tool called $I Parse. To use
this tool follow these steps:
1. Go to [Link] and download the tool and extract
its contents (if it is zipped).
2. To use this tool, we need first to extract the recycled file metadata file. To do this,
type the following in the command prompt (see Figure 7-12): copy $I*
\users\nihad\desktop\recover
 Figure 4.5 Copy recycled files’ metadata files from the recycle bin into another folder
for analysis

3. Execute the $I Parse tool, go to File menu ➤ Browse…, and select the folder
that contains metadata files.

4. From the main program menu, click the Choose… button and select where to save
the output file (a file with CSV extension that will hold parsing results) (see Figure 4.6)

Figure 4.6. Parse all metadata files in the target directory

5. Finally, click “Create CSV”; a success window will appear after parsing all files is
finished, and you are done! Now, go to where you have saved the output file (in our case, it’s
named [Link]) and open it to view a list of all recycled files names in the target recycle bin
along with all file metadata information (original path, deletion date/time, and file size) (see
Figure 4.7)

Figure 4.7 [Link] shows that information existed within subject recycled files’
metadata files
To extract information from the recycled files’ metadata files (INFO2 files) under
Windows XP (and other ancient versions of Windows like 95, NT4, and ME since 0.7.0), you
can use “Rifiuti2” ([Link]

Data Carving
 Data carving is an advanced type of data recovery, usually used in digital forensic
investigations to extract a particular file (using file’s header and footer information) from
unallocated space (raw data) without the assistance of any file system structure (e.g., MFT).
Data carving can be the only method to recover important evidence files and fragments of files
in a criminal investigation where the file system that was originally responsible for organizing
these files on the hard drive is missing or corrupted. Data carving is also needed when
extracting a file(s) from a captured network traffic stream. Data carving is an advanced
technique in digital forensics and is beyond this book’s scope. However, you should know that
expert forensic examiners can extract (recover) structured data, and hence a file like a document
or photo, out of nonstructured data or raw data using data carving techniques.
File carving can be conducted using only a Hex editor; however, there are some tools
that can aid examiners. The following are some free tools for conducting file carving:
1. Foremost ([Link]
2. Scalpel ([Link]
3. Jpegcarver ([Link]/jpegcarver)
4. List of data recovery (including some file carving) tools from forensics wiki
([Link]/wiki/Tools:Data_Recovery)

Windows Registry Analysis

The registry is considered the heart of Windows OS; it contains critical
information needed by the operating system and installed applications in order to function.
Almost every action conducted by a Windows user is stored in its registry in one way or
another; this makes the Windows registry a rich source of evidence that can be extremely
valuable for any digital forensic investigation.
Architecture of Windows Registry
The registry is a hierarchical database that stores Windows system configuration
settings for hardware, software applications, and the operating system in addition to the user’s
preferences and the computer’s and applications’ usage history. Registry data is structured in
a tree format, where each node in the tree is called a key. A key can contain other keys (subkeys)
in addition to data values (see Figure 4.8).
 Figure 4.8 Windows registry structure
The Windows registry contains five root folders (also known as hives). Hives
are the first folders in the registry and appear on the left side when you first open the registry
editor and all other keys are minimized (see Table 4.1).
Table 4.1. Windows Registry Root Folders (Hives)
 Root hives are divided into two types with regard to their data persistence: volatile and
nonvolatile. HKEY_LOCAL_MACHINE and HKEY_USERS keys are nonvolatile and are
stored on the hard drive, while the remaining hives are volatile and should be captured while
the system is running in order to acquire useful information from them. Digital forensic
investigators can examine the Windows registry using two methods:
1. The registry is contained within a forensic image. In this way, the computer forensic
program will be used to investigate registry files as you do when browsing files/folders using
Windows File Explorer.
2. Live analysis (e.g., when booting up from the suspect forensic image). In this
method, you can access the registry as you do with any computer using the Windows built-in
registry editor. If we are examining the Windows registry using a captured forensic image, it
is necessary to know where the registry files are stored. Registry hives are located in
Windows\System32\Config folder, so if your OS is installed on the C:\ drive, your registry
files will be located in the C:\Windows\System32\Config folder. After accessing this folder,
you will find many files (a separate file for each root hive and a couple of supporting files for
each one, except for the HKEY_CURRENT_USER hive, as this one is stored in your profile
folder). Windows comes equipped with a registry editor, which allows any user with
administrative privilege to view, edit, and back up the Windows registry. To access the built-
in registry editor, follow these steps:
1. Press the Windows button and the R button (Win+R) to open the Run dialog.
2. Type “regedit” and press OK.
Acquiring Windows Registry
computer forensics tools will acquire Windows registry files as a part of acquiring the
target machine’s system drive or when performing a complete hard drive acquisition. You can
also extract only the registry files from a live system and store it separately for later analysis
(this is usually referred as “Registry Image”). The following shows how we can do this using
AccessData FTK Imager.
To acquire target Windows machine registry using FTK Imager, follow these steps:
1. Download AccessData FTK Imager as we did in Chapter 5 and transfer it into your
USB thumb drive.
2. Attach the USB drive that contains FTK Imager to the suspect machine, open
FTK Image, and go to File menu ➤ Obtain Protected Files…
3. A new dialog appears; select where you want to store obtained files, and check the
option “Password recovery and all registry files” (see Figure 7-16). Finally, click
the “OK” button.
4. A progress window will appear showing registry files’ export progress; upon
finishing, the window will disappear without announcing any success message.

Figure 4.9 Using FTK Imager to acquire target Windows registry database

Go to the directory where you have saved your registry files to see the resultant
files; you should see the five files and one folder (see Figure 4.10)
 Figure 4.10 A registry forensic image captured with AccessData FTK Imager

Now that we have successfully exported our target machine registry, we can use
different forensics tools to analyze it.
Registry Examination
Most computer forensics suites have the ability to investigate the Windows
registry from the acquired forensic image. There are also many programs
specializing in analyzing Windows registry files alone. In this section, we will
assume that we have booted up using a suspect forensic image to perform various
forensic analyses on it. Some dedicated tools for investigating specific areas within
the registry will get covered too where applicable.

Automatic Startup Locations

Windows has a feature that allows programs to launch automatically as it
boots; this feature is necessary for some applications like antivirus software that
must run first to stop any malicious software before Windows gets booted
completely. Malicious software like keyloggers and botnets can add entries to
the Windows registry in order to launch automatically with each Windows boot.
The Windows registry stores a record of every program boot with Windows. A
list of autobooted programs can be found in the registry keys listed in Table 4.2
 Table 4.2. Common Windows Registry Startup Location Keys
Microsoft has a portable utility available to investigate all autorun programs
called Autoruns (see Figure 4.11). This tool can be downloaded from
[Link] [Link]/en-us/sysinternals/downloads/autoruns.
 Figure 4.11 Using Autoruns from Sysinternals to view automatic startup
programs and associated registry key in Windows
Installed Program Keys in the Windows Registry
Learning what programs are currently or were previously installed on the suspect
machine can be of a great value for forensic investigators. For example, the
existence of steganography and encryption programs—or the leftovers belonging
to such tools—will give an indication that the suspect machine may contain hidden
data or simply was used to execute such programs.
Nirsoft offers a free tool called RegScanner ([Link]/utils/regscanner.
html), which is a small tool used to search the Windows registry according to
specific search criteria entered by the user. The returned results appear in a list, and
a user can click any item in this list to go to the associated value in RegEdit. We
can also export the found registry values into a .reg file. After executing this tool,
a search option dialog will appear to enter your search criteria, and you can also set
some search options.
USB Device Forensics
Windows keeps a history log of all previously connected USB devices along with their
connection times in addition to the associated user account which installs them. The Windows
registry also stores important technical information for each connected USB device such as
vendor ID, product ID, revision, and serial number. Windows stores USB history-related
information using five registry keys, where each key offers a different piece of information
about the connected device. By merging this information together, investigators will have an
idea of how an offender has used removable devices—such as a USB—to conduct/facilitate
his/her actions.

1. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Enum\USBSTOR Here you

will find all USB devices that have been plugged into the operating system since its installation.
It shows the USB vendor ID (manufacturer name), product ID, and the device serial number
(note that if the second character of the device serial number is “&,” it means the connected
device does not have a serial number and the device ID has been generated by the system). See
Figure 7-20 for a list of previously connected USB devices on the author’s machine.

2. HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices The MountedDevices subkey

stores the drive letter allocations; it matches the serial number of a USB device to a given drive
letter or volume that was mounted when the USB device was inserted.

3. HKEY_CURRENT_USER\Software\Microsoft\Windows\
CurrentVersion\Explorer\MountPoints2 This key will record which user was logged into
Windows when a specific USB device was connected. The key also includes the “Last Write
Time” for each device that was connected to the system.

4. HKEY_LOCAL_MACHINE\SYSTEM\Currentcontrolset\Enum\ Usb This key holds

technical information about each connected USB device in addition to the last time the subject
USB was connected to the investigated computer.
5. Identify the first time device was connected: Check this file at
\Windows\inf\[Link] for Windows Vista, 7, and 8, and at
\Windows\inf\[Link] for Windows 10. On Windows XP, this file will be located
at \Windows\setupapi. log. Search in this file for a particular USB device’s serial number to
learn when it was first connected to the subject system (in local time).
To automate the process of finding information about the current and previous USB
connected devices, you can download a free tool by Nirsoft that can perform all the tasks we
just did manually; this tool is called USBDeview ([Link]/utils/
usb_devices_view.html). After executing this tool on the target system, extended information
(e.g., device name/description, device type, serial number, and much more) about each
connected USB device will appear.

In Figure 7-21, the Last Plug/Unplug Date represents the first time that the device was
connected to the system. This date does not change when the same device is repeatedly
reinserted. The “Created Date” represents the last time that the same device was attached to the
system.

Unfortunately, not all USB device types will leave traces in Windows registry as we have
described, for instance, USB devices that use media transfer protocol (MTP) when connecting
with computers. Devices equipped with the modern Android OS versions in addition to
Windows phones and Blackberry all use the MTP protocol; this protocol does not leave traces
in the Windows registry when a USB device is connected to a Windows computer. This
necessitates a specialized tool to handle the investigation of such artifacts
USB Detective ([Link] supports detecting USB devices that use the
MTP protocol to connect to Windows. It also offers rich features for thoroughly investigating
connected USB devices, like creating timelines of all unique connection/ disconnection and
deletion timestamps for each device; however, you need to upgrade to the professional paid
version to use all features.

File Format Identification

A signature analysis is a process where file headers and extensions are compared with
a known database of file headers and extensions to discover whether an attempt to conceal
original file type has been made (changing the file extension to something else to hide it from
the investigators’ eyes). As we know, each file under Windows has a unique signature, usually
stored in the first 20 bytes of the file. We can check the original file signature of any file by
examining it with Notepad or through using a Hex editor.
HexBrowser is a Windows tool that can recognize more than 1,000 different file formats and
shows detailed information about each file. To use this tool, follow these simple steps:
1. Go to [Link] and download HexBrowser.
2. Click the “Open” button in the main program
menu, select the suspect file, and you are done! 3. See the results on the right pane of the
program window (see Figure 7-27).

Autopsy has the ability to discover file extension mismatches; to use this feature,
you have to enable the “Extension Mismatch Detector” module. You can further
configure file mismatch search options by going to the Tools menu ➤ Options ➤ File
Extension Mismatch. From here, you can add or remove extensions based on your case
need (see Figure 7-28), and the results are shown in the Results tree under “Extension
Mismatch Detected” (see Figure 7-29).
Windows Features Forensics Analysis

There are many features offered by Windows OS to optimize—or to allow a user to

customize—some of its functions to become more user friendly. Investigating such features is
essential, as they can be a source of digital evidence. In this section, we will examine some
common features of Windows for interesting artifacts.
A)Windows Prefetch Analysis
 Prefetch is a feature used by Windows to speed up loading applications. Windows
creates a Prefetch file when a user executes an application for the first time, and then it will
record which files have been loaded as a part of this application execution, in addition to the
last time this application was executed, so the next time a user launches it, Windows will load
it quicker. From a digital forensic perspective, the Prefetch feature can tell us what program(s)
was executed on the target system even though the subject program was uninstalled after
executing it, as it will remain in the Windows Prefetch folder.
The Prefetcher’s configuration is stored in the following Windows registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
Manager\Memory Management\PrefetchParameters

Windows stores Prefetch files at C:\Windows\Prefetch. Prefetch files are all named using
common naming criteria. The name of the running application comes first, then comes an eight-
character hash of the location where the application was run, and finally it ends with the .PF
extension (see Figure 7-30)

B)Windows Thumbnail Forensics

Windows stores thumbnails of graphics files (JPEG, BMP, GIF, PNG, TIFF) and some
document types (DOCX, PPTX, PDF) and movie files in the thumbnail cache file called
[Link] when a user selects to view files as thumbnail, for quick viewing at a later time.
Investigating this feature can tell examiners about previous files (e.g., images) that existed on
a system even though the user has deleted them, as image thumbnails may still exist at
[Link].

c)Jump Lists Forensics

Jump Lists is a feature that allows users to view recently viewed or accessed files for
each installed application.
[Link]-MS These files are created in
\Users\\AppData\Roaming\Microsoft\Windows\ Recent\AutomaticDestinations-ms and are
created automatically by Windows when a user opens an application or accesses a file.

[Link]-MS These files are created in

\Users\\AppData\Roaming\Microsoft\Windows\ Recent\CustomDestinations-ms when a user

pins a file to the Start menu or task bar.

d)LNK File Forensics

.lnk files are the windows shortcut files. LNK files link or point to other files or
executables for ease of access. You can find following information in these files:
● The original path of the target file.
● Timestamp of both the target files and the .lnk files.
● File Attributes like System, Hidden, etc.
● Details about the disk.
● Remote or local execution.
● MAC address of the machines.

e)Event Log Analysis

Windows records important events (both hardware and software events) that have
happened to the system, applications, or other services in what is called an event log. Recording
events like low memory, excessive access to hard drive, failed login, and others can assist
system administrators or users in learning the exact source of a particular event in addition to
helping them predict future events (e.g., replace hard drive before its complete failure).

There are five types of events that can be recorded by Windows event log: 1. Error:
Indicates that a significant problem has occurred: for example, when a service fails to load at
startup. 2. Warning: Not a significant event, but may lead to serious problems in the future. 3.
Information: Indicates successful operation of an object like service, application, or driver. 4.
Success Audit: Points to a successful security event (e.g., successful login is recorded as
“Success Audit event”).
5. Failure Audit: Reverses a Success Audit (e.g., when a user fails to log in to Windows,
the event is logged as a “Failure Audit event”).

The main elements of every event in a log entry are as follows:

1. User: Username of the account logged into the machine when the event occurs.
2. Event ID: A number generated by Windows that identifies event type.
3. Source: The object which caused the event to occur.
 4. Computer: Name of the computer where the event occurred.
5. Date and time: The date and time when the event occurred.
6. Description: Description of what happened to launch the event

f)Hidden Hard Drive Partition Analysis

Most hard drives (HDD and SSD) usually come divided into partitions. Dividing a
partition is useful for many reasons; for example, a user can dedicate one partition for housing
the OS files and another one for storing user private data. Dividing hard drives into partitions
is not only limited to end users; for instance, most computer vendors create a hidden partition
to store a recovery image of an installed OS. However, hidden partitions can also contain
incriminating data and other files of interest.
To launch this tool, open a DOS prompt, type DiskPart, and press Enter. Perform the
following actions to check for hidden partitions:
1. Type “List disk” to view a list of hard disks/drives connected to this PC and associated
numbers.
2. To view the partitions of a selected hard drive, you first need to select it through the “select
disk = n” command, where n points to the disk/drive number that appears in the first command.
3. After selecting the disk/drive, type “list partition” to see a list of partitions associated with
this disk drive.

g)Windows Minidump File Forensics

When a Windows machine crashes with a Blue Screen of Death, a copy of computer
memory at the time of the crash will be stored in \Windows\minidump or \Winnt\ minidump
depending on the version of Windows. Windows can create different memory dumps; for
instance, there are five types in Windows 10
1. Small memory dump (256 KB)
2. Kernel memory dump
3. Complete memory dump
4. Automatic memory dump (default option)
5. Active memory dump

You can configure the memory dump feature under Windows by going to Control Panel
➤ System ➤ Advanced system settings ➤ Advanced tab ➤ Startup and Recovery pane
– Settings button.
Minidump files will usually contain the programs that were running/installed at the time
of the crash; this can be very useful for digital forensic examiners. For example, if we think
that a suspect was using a portable steganography tool to conceal a secret file when the crash
happened, the steganography tool name will appear in the dump file, making it available for
forensic investigations.

h)[Link], [Link], and [Link]

[Link], [Link], and [Link] are three important system files required
for the proper functioning of the Windows OS. The default location of these files is in system
drive (usually the C:\ drive); please note that the three files come hidden, so you need to view
hidden files—including protected system files—
Figure 7-41. The location of [Link], [Link], and [Link]

[Link]
The capacity of the physical memory increases with the continual advance of
computing power (for example, it is common these days to buy a laptop with 16 GB of
RAM memory). This effectively limits the need to swap any files to the virtual memory.
All these issues result in low expectations of computer forensic investigators when
investigating [Link].

Despite the limited possibility in modern computers of finding valuable data inside
[Link], we can’t discard its importance during an investigation. Most computer
forensics suites can analyze [Link]; consult tool documentation for related
instructions.

[Link]
This is a file used by Windows to support the hibernation feature, the approximate size
of this file is about 3/4th of your RAM. The hibernation file in earlier versions of Windows
(e.g., 7 and Vista) stored kernel session, device drivers, and application data while in modern
versions of Windows (like 8 and 10) it stores only the kernel session and device drivers, making
it notably less in size. [Link] can store a wealth of information about the running machine.
The following tools can investigate the [Link] file:

● Volatility, free and open source tool: [Link]

• Belkasoft Evidence Center (commercial application):
[Link]

[Link]
Used to store the idle and other nonactive objects ejected from the RAM memory,
whenever a user tries to access an idle process again, its information will get shifted to
the RAM memory again. In modern Windows versions (like 8 and 10) we can see that
both Pagefile and Swapfile exist together on a system drive; we can consider that these
two files form together what is known now as virtual memory in Windows OS. Swapfile
has a fixed size in modern Windows versions (8, 10), which is 256 MB.

Windows Volume Shadow Copies Forensics

The Volume Shadow Copy Service (VSS)—available in all Windows versions
beginning
with Windows XP—is a service that coordinates the creation of a consistent snapshot
of data at a specific point in time for each partition where it is [Link] helps
Windows to recover if some of its files get corrupted; in such case, Windows will restore
the good version of files from the previous backups (restore points). These restore points
are taken at specific time intervals determined by Windows.
Windows restore point snapshots also capture the registry hive files, opening the
door to examining previous snapshots of the Windows registry as we did before. To
extract Windows registry files from a particular Windows restore point, you can use a
free portable tool from Nirsoft named RegistryChangesView ([Link]/utils/
registry_changes_view.html).

Figure 7-42. Configuring restore points under Windows 10

The following are two popular tools for analyzing Windows restore point file contents:
ShadowCopyView
ShadowCopyView ([Link]/utils/shadow_copy_view.html) lists all restore
points of your hard drive created by the 'Volume Shadow Copy’ service of Windows. It
supports Windows 10, 8, 7, and Vista.
To use this tool, just execute it on the target machine; it will automatically detect and
list all available restore points on the target machine in addition to relevant information
for each snapshot (like the name, explorer path, volume path, created time, snapshot ID,
and others). Detected snapshot files will appear in the upper pane; select any snapshot
and the lower pane will display its contents (see Figure 7-43).
Figure 7-43. Using ShadowCopyView to list/view existing restore points in
Windows

To extract files/folders from any snapshot, select it first from the upper pane, then
select the file/folder you want to extract from the lower pane, right-click over the target
file, select “Copy Selected Files To…”, choose the destination folder, and then press “Do
it!” (see Figure 7-44).

Figure 7-44. Extract/copy files from selected snapshot using the ShadowCopyView tool

Shadow Explorer
ShadowExplorer ([Link]) is another free utility for investigating
old
Windows restore points easily. To use this tool, select the volume (partition) that has a
system restore activated for it and then select the point that you want to browse. Right-click
the file or folder you want to recover and select “Export…” to save it in your desired
location (see Figure 7-45).
Figure 7-45. Using ShadowExplorer to browse old restore point contents

Windows 10 Forensics
Windows 10 introduces new features and applications to its users like Edge browser,
Windows 10 apps, Cortana (Microsoft’s voice-controlled digital assistant), and many more.
The most important one was the introduction of Universal Application Platform (UAP), which
enables the same application to run on different device types like laptops, desktops, IoT
devices, tablets, smartphones, and so on.

Windows 10 Features Forensics

Windows 10 comes equipped with many new features. In this section, we will
investigate two of them:
1. Notification area database
2. Cortana forensics

Notification Area Database

This is a new feature begun with Windows 8 and continuing to Windows 10.
Any application that is capable of generating a systray notification will subsequently
record this notification in a centralized database. The notification area database can be
found at \Users\\AppData\Local\Microsoft\Windows\Notifications under the name
[Link]

The notification database holds various notification types seen by Windows users on the bottom
right corner of the screen, such as pop-up messages from various parts of the OS (e.g., backup
and restore), e-mail alerts, and messages related to specific apps like Torrent downloads,
among other things. The forensic value of Windows notification is that it can reveal previous
user activities on the target machine.
The notification area database is of type SQLite (.db extension). To analyze this
database’s contents, follow these steps:
• Go to [Link] and download DB Browser for SQLite; select the
version appropriate for your OS version.
• Launch the program, go to File menu ➤ Open Database…; browse to
\Users\\AppData\Local\Microsoft\Windows\ Notifications; and select
[Link]. • In Figure 7-46, we can see the database schema of the Windows
notification area ([Link]).
In the Notification table, we can find the following attributes:
• “HandlerId”, which tells which program has created the notification (retrieve
program name from table “NotificationHandler”).
• “Payload” contains notification contents (see Figure 7-47).
• “ArrivalTime”; date/time when notification received.
• “ExpiryTime”; date/time when notification will be deleted from the database.
 The values of “ArrivalTime” and “ExpiryTime” are stored in decimal format;
to convert them into a readable format, we need first to convert the number into Hex, then use
the DCode tool (as used previously; available at [Link]/ dcode) to convert
the number into a readable date/time (see Figure 7-48).

Cortana Forensics
Cortana is a voice-activated personal assistant (similar to Siri developed by Apple Inc.
for its iOS). Cortana is a relatively new feature first introduced in Windows phone version 8.1;
later, with the release of Windows 10, it has ported into Windows desktop as well. Its main
task is to provide a personalized experience for Windows 10 users by offering suggestions
when conducting searches in addition to remembering events, sending e-mails on the user’s
behalf (when configured properly), searching the Web, checking weather forecasts, and many
more useful things. Cortana works through cumulative learning. Hence, when the user
communicates with it more (through the PC microphone or by typing), it will understand the
user’s personal habits and attitudes more, leading to more accurate results in future interactions.
From a digital forensics perspective, Cortana can provide a wealth of
information about a user’s previous activities on the target machine in addition to web searches
and geolocation data (latitude/longitude of the triggered location-based reminders). Bear in
mind that despite the important information that can be retrieved from the Cortana feature, we
cannot always expect to have it enabled on all Windows machines, as this feature has a
reputation of being a privacy invader for Windows users and many of them have already
deactivated this feature due to privacy concerns.
Cortana keeps some information related to its work on two extensible storage engine
(ESE) databases that can be found at the following locations:
\Users\\AppData\Local\Packages\[Link].Cortana_xxxx\
AppData\Indexed D\[Link]
\Users\\AppData\Local\Packages\[Link].Cortana_xxxx\
LocalState\ESEDatabase_CortanaCoreInstance\[Link]
The “[Link]” holds forensically valuable information related to
user geolocation data in addition to reminders set by a user and where and when these
remainders have triggered. Please note that Cortana can record extensive private information
about its users; however, it seems that Microsoft has shifted many user interactions with
Cortana onto Microsoft cloud servers.
Another location where some Cortana-related artifacts can be found on the local
machine is \Users\\AppData\Local\Packages\[Link].
Cortana_xxxx\LocalState\LocalRecorder\Speech (see Figure 7-49).

This folder stores voice command (WAV audio files) recordings issued by a user to
Cortana to perform a task. Please note that not all computer forensic suites support decoding
the Cortana database; always consult the manual or tool features before buying it. For instance,
EnCase has a script to decode Cortana search terms of user-specified [Link] files.

4.2 Investigating Unix Systems

STEPS IN A UNIX INVESTIGATION
The following actions pro- vide the most likely way to identify relevant evidence:

▼ Review all pertinent logs

■ Perform keyword searches
■ Review relevant files
■ Identify unauthorized user accounts or groups
■ Identify rogue processes
■ Check for unauthorized access points
■ Analyze trust relationships
▲ Check for kernel module rootkits

REVIEWING PERTINENT LOGS

Unix operating systems have a variety of log files that can yield important clues during
incident response. Not only are system activities such as logons, startups, and shutdowns
logged, but also events associated with Unix network services. Most log files are located in a
common directory, usually /var/log. However, some flavors of Unix will use an al-
ternate directory, such as /usr/adm or /var/adm.

Network Logging
Probably the single most useful logging capability in Unix is the syslog (system log)
file. This log captures events from programs and subsystems within Unix. The activi-
ties of syslog are controlled through the syslog configuration file, usually
/etc/[Link]. A syslog daemon, syslogd, runs on the system to log messages.
Syslog also offers the ability to log messages remotely, across a network.
The syslog configuration file controls which types of messages are sent to which logs.

Each line in the configuration file contains three fields:

▼ The facility field denotes the subsystem that produced the log file. For example,
sendmail logs with the mail facility. The facility types are auth (security), authpriv,
cron, daemon, kern, lpr, mail, mark, news, syslog, user, uucp, and local0-7.
■ The priority field indicates the severity of the log. There are eight priority
levels: debug, info, notice, warning, err, crit, alert, and emerg.
▲ The action field specifies how the log will be recorded.

Remote Syslog Server Logs

The log files generated locally by the syslog daemon are text files that are usually
world-readable but writable only by root. This means that any attacker who has gained
administrator-level access can easily modify the syslog log files—removing selected en-
tries, modifying selected entries, or adding misleading entries. These modifications are
nearly impossible to detect. If you suspect that an attacker has gained root-level access on
the system where the logs are stored, do not trust the logs. The only way to tell for certain
if an attacker modified the log files is to perform redundant logging to a secure, remote
syslog server.
The action field of the [Link] file should contain the string “@remote_host,” where
re- mote_host is the IP address of the remote syslog server. All hosts should log to the same
syslog server.
In the event that a system is hacked and the log files are manipulated, or if the attacker
deleted the entire log file, a pristine copy should exist on the remote syslog server. Of
course, the attacker could add spurious entries to the remote syslog server, but the at-
tacker could not edit or remove entries without first compromising the remote server. For
this reason, the remote syslog server should be a hardened (secure) host with minimal
access, preferably only console or secure shell (ssh), which also takes advantage of system
logging.

TCP Wrapper Logging

 TCP Wrappers is a host-based access control for TCP and UDP services. Any
connection attempts to “wrapped” services are logged via [Link] that the log entry
provides a lot of valuable information: the time and date of the attempted logon, the hostname
(victim), the service (sshd), the account (root), and the IP address of the system that attempted
to log on.

→Other Network Logs

This log entry provides the following information:
▼ The time and date that the transfer occurred
■ The number of seconds that the transfer took (1)
■ The remote host ([Link])
■ The number of bytes transferred
■ The name of the transferred file
■ The type of file transfer (b for binary)
■ A special action flag (_ indicates no special action)
■ The direction of transfer (o represents outgoing; i is incoming)
■ The access mode (r is for real, as opposed to anonymous or guest)
The username (chris)
■ The service name (ftp)
■ The authentication method (0 for none)
■ The user ID (* indicates none available)
▲ The status of the transfer (c for complete)

→Host Logging
Unix provides a variety of log files that track host operations. Some of the more useful
logs record su command execution, logged-on users, logon attempts, and cron job
(scheduled program) execution.

su Command Logs
The su command allows a user to switch to another user ID during a session. Attackers
sometimes use this command to attempt to gain root access to a system. Unix records every
attempt to execute the su command on the system. The log shows the time and date of the su
attempt, whether the attempt was successful, the terminal device from which the user at-
tempted to execute su, and the user ID before and after the su attempt.

Logged-on User Logs

The utmpor wtmpfile is used to store information about users currently logged on to the
system. The log file is named differently and stores slightly different information, de-
pending on the flavor of Unix. The basic information stored is the name of the user, the
terminal used to log on, and the time of the logon. The file is stored in a binary data for- mat,
rather than as a text file.

Logon Attempt Logs

Logon attempts, both failed and successful, are recorded by default on most Unix sys-
tems.
Cron Logs
Cron is a feature in Unix that allows users to schedule programs for future execution,
and it is often used for attacks. All executed cron jobs are logged, usually in /var/cron/log or
in the default logging directory, in a file called cron.

User Activity Logging

Along with logons, other types of user activities are recorded in Unix logs. Process ac-
counting logs and shell history files record the commands executed by users.
Process Accounting Logs
This type of logging is not enabled by default. If the acct or pacct log file does not exist
on the system, you will not be able to use this feature. If either of these files exists, you can use
the lastcomm or acctcom command to review the
contents of the file.
Shell Histories
Users with interactive access to Unix systems have an associated command shell, such
as the Bourne (sh), Korn (ksh), or Bourne-Again (bash) shell. These shells provide the
capability to log all commands, along with their command-line options.

PERFORMING KEYWORD SEARCHES

Keyword searches are a critical part of almost every incident response investigation,
ranging from email harassment to remote network compromise cases. Keywords can be a wide
range of ASCII strings, including an attacker’s backdoor password, a username.

→String Searches with grep

flexible grep command is a primary tool for string searches.
→File Searches with find
Another useful command for string searches is find. You can use the find command to
find any filename that matches a regular [Link] find command is helpful for many
searches. It can search a file system for files that match a wide variety of characteristics,
including modification or access time, owner of file, string inside a file, string in the name of
the file, and so on.

REVIEWING RELEVANT FILES

Incident Time and Time/Date Stamps

In order to search for files and directories that were accessed, modified, or created
around the time of a suspected incident, you must first know the time of the suspected incident.
The timeframe may be very specific, such as when a network IDS discovered and logged the
attack as it happened. On the other hand, the timeframe may be general, such as in the case
where a system administrator connected the system to the Internet two weeks ago and evidence
of compromise was found today. If you have a good record from an outside source (such as
network IDS) of when the attack occurred, the first step is to make sure that the system time
on the IDS matches that of the victim system.
Unix file system saves three different timestamps for each file or directory:
● The atime, or access time, is the last time that a file or directory was accessed.
This includes even read access (such as cat filename).
■ The mtime, or modification time, records the last time a file was modified.
▲ The ctime, is similar to the mtime, but it records the last time the inode value
was changed. This value can change with events such as changing permissions
or ownership.
Special Files
Certain types of files and directories seem to regularly turn up in incidents. These files
and directories include SUID and SGID files, unusual and hidden files and directories,
configuration files, and the /tmpdirectory. Let’s see how these files can be relevant to
Unix investigations.

SUID and SGID Files

Unix contains features known as set userid (SUID) and set groupid (SGID), which are de-
signed to allow programs to operate with higher privileges than those of the user running the
program. For example, if user Bob executes a program, that program runs with the privileges
of user Bob. However, if the program is SUID and Bob executes it, the program runs with the
privileges of whichever user owns the executable, usually the root. SGID works the same way,
except that the program runs with the privileges of the associated group.
SUID and SGID root programs are the source of most privilege-escalation attacks on
Unix systems, and they are also a favorite backdoor for attackers.

Unusual and Hidden Files and Directories

Any file or directory that starts with a dot (.) is hidden from casual view; it will not
appear in an ls command listing unless the -a option is used.

Configuration Files
Configuration files are a key location of evidence during many incidents. With all of
the built-in functionality of the Unix operating system, a knowledgeable attacker can easily
modify applications to perform evil tasks. Frequent targets include files that control
access to the victim system, such as the TCP Wrapper configuration files
/etc/[Link] and /etc/[Link]. Attackers may modify or delete these files to
allow certain computers to connect to the victim system at will.

Startup Files
The Unix operating system has several locations that are used to start services and
applications. We just mentioned the [Link] file, one of the primary files of this type. Other
examples include cron, rc startup files, and user startup files.

Tmp Directory
By default, the /tmpdirectory is the only world-writable file system on a Unix system.
This makes it a popular hangout for attackers and a favorite storage site for nefarious
tools. Also, many publicly available exploits use the /tmp directory to store temporary
files during privilege-escalation attacks, and sometimes they leave trace evidence. Check
the /tmpdirectory carefully in the event of an incident to determine if hidden directories
or suspicious files exist there.
IDENTIFYING UNAUTHORIZED USER ACCOUNTS OR GROUPS
Attackers will often modify account and groupinformation on victim systems. This
modification can come in the form of additional accounts or escalations in privilege of current
accounts. The goal is usually to create a backdoor for future access. You should audit user and
groupaccounts on suspected victim systems to validate that an attacker did not ma-
nipulate this information.

User Account Investigation

User information is stored in the /etc/passwd file. This is a text file that you can easily
review through a variety of mechanisms.
Any extra user accounts not created by the system administrator are cause for alarm.
Examine any accounts that should be disabled or unavailable for remote logon—such as
daemon, sync, or shutdown—to ensure that they have not been manipulated.

Group Account Investigation

Group accounts use the groupID shown in the /etc/passwd file as well as the
/etc/groups file. A typical /etc/group file looks like this:
$ cat /etc/group
root::0:root,ashunn
bin::2:root,bin,daemon
sys::3:root,bin,sys,adm
adm::4:root,adm,daemon
uucp::5:root,uucp

The file lists the groups, along with the users that are associated with that group. It is
important to note that an entry in the groupfile does not need to exist for a groupto exist.
Group membership is based on the group ID in the password file.

IDENTIFYING ROGUE PROCESSES

You should carefully examine the running processes to verify their validity. Also
review all binaries associated with listening services and running processes to ensure that
they have not been modified.

CHECKING FOR UNAUTHORIZED ACCESS POINTS

Unix offers a dazzling array of network services, including the Network File System
(NFS), telnet, finger, rlogin, and many others. Any one of the networked services on Unix
systems can potentially allow some degree of remote access to unwanted intruders, as
can a phone line connected to a modem.
The most common access points that we have seen intruders take advantage of
include X Servers, FTP, telnet, TFTP, DNS, sendmail, finger, SNMP, IMAP, POP, HTTP, and
HTTPS. Unfortunately, this is just a partial list.
As you conduct your investigation of the Unix system, you will need to examine all
network services as potential access points. Net work services could be vulnerable, allowing
intruders access to your system, or network services could already be trojaned by a successful
intruder.
ANALYZING TRUST RELATIONSHIPS
Trust relationships within Unix systems were once a primary mechanism of attack.
Trust can be established between Unix systems with a variety of services, the most popular of
which include rlogin, rsh, the Network Information Service (NIS and NIS+), NFS, and
ssh. Trust relationships can be convenient time-savers for system administrators and us-
ers. If machine A trusts machine B, then the user on machine B can access machine A with
no additional credentials. If you are a system administrator with dozens of systems to
maintain, using this feature can be very enticing.
Trust relationships are usually configured through files such as /etc/[Link] or
any .rhosts file in a user’s home directory. Trust relationships can be established with ssh
through shared keys and through NFS shares. Furthermore, firewalls and host-based ac-
cess controls such as TCP Wrappers are often configured to let certain source IP ad-
dresses communicate with protected hosts, another form of trust. Investigate all possible
trust relationships to determine if they played a part in the incident.
Trust relationships seem to be less common today. However, another type of trust is
created through network topology. Networked computers that share a common network
segment must trust their peers. This means that an attacker who compromises a single
host can view network traffic on the same segment, even in a switched environment.

DETECTING TROJAN LOADABLE KERNEL MODULES

Loadable kernel modules (LKMs), or kernel extensions, are found on the various
flavors of Linux, BSD, and Solaris. They extend the capabilities of the base operating system
kernel, typically to provide additional support within the operating system for device and file
system drivers. LKMs can be dynamically loaded by a user with root-level access, and they
run at the kernel level instead of at a normal user-process level.
Several intrusion-based LKMs have been developed, and once a malicious user ob-
tains privileged access to your system, she can install one. Some common malicious
LKMs include Adore, Knark, and Itf. These LKMs provide several capabilities for attack-
ers, such as providing remote root access and hiding files, processes, and services.
LKMs on Live Systems
Detecting trojan LKMs on a live system can be complicated because these tools actually
intercept system calls (such as ps or directory listing) to provide false information. They are
specifically designed to prevent detection with traditional response methods. How-
ever, in many cases, you can find them by combining externally executed commands with local
commands to detect anomalies or discrepancies. An example would be an external port scan
compared to a port scan performed directly on the local suspect system.

LKM Elements
In some cases, the intruder uploads and compiles the source, and successfully installs the
LKM; however, she forgets to delete the actual LKM source files! When this happens, you
may not only discover the presence of the LKM, you may also find additional configura tion
information.