(W31M00) About The Course

About The Course

The course aims to deepen the knowledge of the Windows registry and Log Analysis using some of the best known free tools in Windows computer forensics in order to reconstruct in detail the user’s activities, leading to a deeper level of knowledge of the very principles of the functioning of both Windows Registry and Logging. The very practical approach can be used both for understanding the principles behind the automated analysis carried out by the industry’s most popular forensic suites, both to deepen the level of detail, thanks to the gained knowledge, and interpretation of the artefacts generated by the system.

The use of individual different tools forensically tested, allows one to exit the fast but delimited path of automation, forcing the user to understand and deepen the detail of his analysis. While this is very common on Linux, where inside the most popular forensic distributions such as Caine, Deft or Sift, you can find a multitude of different and independent tools, like the Sleuth Kit, RegRipper, Plaso and many others, in a Windows environment, forensic suites automate and speed up the work, but at the same time, deprive the user of the need to look a little more "under the hood".

The purpose of this course is just that, to look under the hood of Windows through the analysis of the logs and the registry, taking advantage of simple and free tools, but forensically valid to refine the results of our analysis, bringing the user to obtain more precise results through a deeper knowledge of the operating system, in our case, the versions of Windows from 7 to 10.

To achieve these objectives, we will use three freely downloadable tools (FTK Imager, Registry Viewer, Log Parser) and one already present in Windows installation (PowerShell). Starting from the ease of use of these tools, we can create accurate and valid forensic reports; during the various modules, we will see some examples.

In Module 1 we will use PowerShell to parse the logs produced by the Operating System, selecting the most useful for our purposes to reconstruct the activities of users or the phases of use of the machine.

In Module 2 we will use the hexadecimal viewer of FTK Imager to go down to the lowest level of the registry analysis and explain how it works in depth. This process will allow us to understand how the registry parsing tools such as Registry Viewer work, and to create new tools once we know the rules that underlie the creation of keys and values.

In Module 3, once we’ve explained the operation of the registry, we will proceed with its analysis with the Registry Viewer to extract the most useful keys about Operating System, users, applications, USB devices and network activities.

In Module 4 we’ll see how to combine information from different sources and different tools. We’ll learn to use Log Parser and create SQL-like queries to parse logs and track user activity on the machine or across a Windows domain. Finally, we’ll proceed to analyze a real case where we’ll integrate the evidence coming from the logs and the registry to collect as much information as we need to complete our analysis and draft a report.

Module 1 (Keeping track of it all - the Windows Event Logging)

Logs are records of events that happened in the computer. On a Windows machine, the Event logging service records events from various sources and stores them in a single collection called an event log.

EVTX is Microsoft’s log format implemented in Vista and Server 2008 that stores event log records as a stream of binary XML. It makes large use of channels, which could be considered as streams of events used by the OS and applications to transport events from an event publisher to a log file.

Channels are divided in two groups: Windows Logs (Application, Security, System, Setup, ForwardedEvents) and Application and Services Logs, including many individual channels that publish events from a single application or component.

PowerShell is the tool we will use to analyze the logs contained in EVTX files. This tool consists of a Windows command-line shell that accepts and returns .NET Framework objects that can interact not only with the file system, but also with the other data stores, such as logs and the registry, using providers, Microsoft .NET Framework-based programs designed to take data storage and make it look like a disk drive.

The interaction between PowerShell and the machine takes place through the hundreds of cmdlets, simple, single-function command-line tools built into the shell that can be used separately or in combination to perform complex tasks.

Here are some useful logs to trace machine and user activity among the thousands at our disposal in a Windows environment.

Application:

  • ID 11707 – Product installed
  • ID 11708 – Product installed failed

Security:

  • ID 4608 – Windows is starting up
  • ID 4726 – A user account was deleted
  • ID 4728 – A member was added to a security-enabled global group
  • ID 4738 – A user account was changed

System:

  • ID 6008 – Unexpected Shutdown
  • ID 6009 – System boot
  • ID 1074 – Shutdown

Module 2 (At the heart of Windows OS - the Registry)

The Registry is a hierarchical and centralized database for storing system and application configuration information.

The operation of the Windows Registry is based on two elements: keys, containers similar to folders, and values, non-container objects similar to files.

Keys may contain values and subkeys. They are referenced with a syntax like path names, including the use of backslashes to indicate a lower or higher level of hierarchy inside the registry.

Each registry key has a value called Last Written Time, a 64-bit FILETIME structure representing the number of 100-nanosecond intervals since January 1, 1601 UTC whose behavior is similar to a file’s last modification time: the value will be updated whenever a registry value in the key is created, modified or deleted.

Each value consists of several parts, the most important of which are Name, Type and Data:

  • Name - a unique name in the key
  • Type - up to twelve possibilities, as we will see later
  • Data - data related to the values type

A hive is a logical group of keys, subkeys, and values in the registry that has a set of supporting files containing backups of its data. Individual settings for each user are stored in a disk file per user called hive. During user login, the system loads the right hive under the HKEY_USERS key and sets the HKCU (HKEY_CURRENT_USER) symbolic reference to point to the user.

Most of the supporting files for the hives are in the %SystemRoot%\System32\Config directory and they are updated each time a user logs on.

Hive files are made up of 4-KB sections named bins. Each bin starts with a header in the first four bytes corresponding to regf.

From the offset 0, as we traverse through the hive file on a binary level with a hex editor, we can find an hbin header every 4096 bytes or multiple of 4096. The hbin header is essential to the section’s structure, it’s the reference point for offset values listed with the key and value of the hbin section.

Module 3 (Taking advantage of the Windows Registry)

In this section we will see some of the keys used to track machine and user activities using Access Data Registry Viewer, a very useful tool that can simplify and speed up the analysis of the multitude of stored keys and values. We will retrieve information about the machine and the operating system, physical (Manufacturer, Model) or logical (OS, Timezone, Installed Applications...). Attention will be payed to the Timezone, the geographic area used as a reference by the machine for the standard time besides the UTC, vital information to conduct a proper analysis, especially when it comes to timelines and computer alibi.

We’ll see how to find information about USB devices previously connected to the machine, such as device ID, Last connection time, device name, the assigned drive letter and installed printers, how the SAM hive can provide some interesting statistical information about users and accounts, and the keys useful to gather as much information as possible about the installed applications, like install date, web browsers and default mail client.

Network analysis will be covered in the last part of the module. Specifically, we’ll see the keys that allow us to answer to the following questions:

  • What was the network card in use?
  • What is the last known IP?
  • Was the IP address in use static?
  • What was the default gateway?
  • At what time was the last lease obtained?
  • What was the DNS server?
  • What was the DHCP server?

 

Module 4 (Tracking User Activities - Combining information from Logs and Registry)

Log Parser 2.2 is a powerful tool that provides access to text-based data such as log files, XML files and CSV files, as well as key data sources on the Windows operating system such as the Event Log, the Registry, the file system, and Active Directory using SQL-like queries.

If we combine Log Parser and PowerShell, we can filter and analyze the extracted EVTX files and create a report with the obtained results, a function for which Log Parser is very convenient and efficient.

Let’s suppose we want to know how many times a certain user had access to the machine during a given period of time: Log Parser can filter logs to show only the useful results. Additionally, if we want to find out what kind of logon has been made by the user we can add the appropriate parameter. This is useful, as we will see, when we come to track Remote Sessions established using the Remote Desktop Protocol (RDP), a proprietary protocol developed by Microsoft, which provides a user with a graphical interface to connect to another computer over a network connection.

Furthermore, working in a Windows domain allows us to trace the connections through the network by moving our analysis to the logs produced by the domain controllers, servers running Active Directory Domain Services, which authenticate and authorize users, and computers assigning and enforcing security policies and installing or updating software.

We will illustrate this process linking each step to the log produced and stored by a domain controller, from the Ticket Granting Ticket (TGT) request to the end of the user’s session.

Finally, we’ll see an example based on a fact that really happened. Specifically, a case of abusive access to a computer in a public office circumventing corporate policies by the installation of forbidden software.

SEE ALL Add a note
YOU
Add your Comment
 

Certificate Validation

© HAKIN9 MEDIA SP. Z O.O. SP. K. 2023