Understanding Windows Trusted Boot – Integrity Check and ELAM

The main purpose is to give an overview of the Windows NT kernel initialization (Windows Trusted Boot). What happens when we are booting a Windows device?

There are not many detailed posts on this, so I thought of writing this up.

This is a continuation of my previous article, “Understanding UEFI Secure Boot – How it helps to secure the Windows 10 pre-boot phase“.

You can consider it as the foundation on which I will explain the role of Windows Trusted Boot (Code Integrity) and ELAM.

Windows OS Architecture – Shell View

Execution of the OS Boot Loader winload.efi marks the end of the Windows Pre-Boot phase (marks the end of jurisdiction for Secure Boot) and the beginning of the NT kernel (NTOS) initialization.

An overview of the Windows OS architecture in shell view

Activities performed by Windows Boot Loader

The actions as performed by winload. efi (synchronous) –

• Loads NT Kernel (ntoskrnl.exe) to memory (RAM)
• Loads Hardware Abstraction Layer module (hal.dll) and Local Kernel Debugger (kd.dll). If debugging is enabled, loads the other debugging libraries as kdcom.dll, kd1394.dll, kdusb.dll
• Loads the SYSTEM registry hive HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control from %SystemRoot%\System32\config\SYSTEM and scans it to pick the SERVICE_BOOT_START drivers identified via reg_dword value 0x00000000
• Loads the scanned SERVICE_BOOT_START drivers to memory
• Executes the NT Kernel (ntoskrnl.exe) and terminates itself

Before terminating itself, it does one last important thing – it removes the EFI Boot Services by calling the EFI function ExitBootServices(), thus reclaiming the memory used by EFI during the EFI boot phase.

Phases of NT Kernel Initialization

Execution of the NT Kernel marks the beginning of the NT Kernel (ntoskrnl.exe) initialization. Kernel initialization happens in two phases, as explained below.

NT Kernel Initialization (Phase 0)

• Phase 0 starts with the Kernel call to initialize the Hardware Abstraction Layer (hal.dll)

HAL forms the base for the NT kernel, it encapsulates the system hardware,
allowing the OS Kernel and Executive services to communicate with the hardware
using instructions (routines and macros) in a generalized way without accessing
the hardware directly - thus allowing the Kernel and the Executive Services to
function without being dependent on the underlying platform hardware.

• HAL initializes the processor (in the case of a multi-processor system, a single processor is initialized, in the case of a multi-core processor, a single-core is initialized), prepares the System Interrupt Controller (interrupts are yet not enabled), and returns control to Kernel (ntoskrnl.exe)

• Kernel invokes the Memory Manager Executive service, which constructs the page tables and internal data structures necessary to provide basic memory services. It divides the virtual address space into two regions – the lower part accessible from both user and kernel opening and the upper part reserved for kernel space only. It creates areas for the file system cache, paged and non-paged pools of memory, and page table, which the Kernel and CPU can access. Allocation and deallocation of memory virtually and dynamically are managed by this Executive service.

• Kernel invokes the Object Manager Executive service by defining the Object Manager namespace (Process/Thread/Job/File/Section/Access Token/Event/Semaphore/Timer/Key/Desktop/Clipboard/WindowStation/Symbolic Link) such that it can start creating objects to be used by other Executive subsystems. More information on Object structure can be read. The kernel also creates the Handle table for resource (object) tracking.

• Kernel invokes the Security Reference Monitor, which initializes the token type object in the Object Manager namespace and then uses the object as returned to create and prepare the first token for assignment to the initial process.

• Kernel invokes the Process and Thread Manager Executive subsystem, which initializes the process and thread object type and sets up a list to track active processes and threads within the Object Manager namespace. It then creates a process object for the first kernel-mode process – System Idle process, a single line running on the processor.

The sole task of this process is to keep the processor occupied when it isn't
processing any other threads. In such scenarios, idle thread will call routines
in the Hardware Abstraction Layer to reduce CPU clock speed or to implement other
power-saving mechanisms. Since this process has the lowest possible priority, 
the NT Kernel scheduler can easily switch this with an incoming process. 

Without the System Idle Process, if a situation arises where the processor has
nothing to process, it can result in system freeze. Thus this process keeps the
CPU running and waiting for anything the Kernel throws at it.

In the below reference snap, it shows the System Idle Process using 79% of CPU
which means 79% of CPU is free to be allocated to other processes. This is
commonly mistaken as a high CPU utilization process.

 
Windows Trusted Boot

The Process and Thread Manager also creates another process object – The system process, which is pawned by the NT Kernel (ntoskrnl.exe) and launches a thread of this process to drive the next Kernel initialization phase.

NT Kernel Initialization (Phase 1)

• The system processes thread requests HAL to enable interrupts.

• System process thread initializes Local Kernel Debugger (kd.dll) already loaded in memory by the bootloader (winload. efi)

• The system process thread invokes the rest of the Executive services to initialize and have their objects created. The below steps are not sequential but asynchronous.

• Configuration Manager Executive service defines the HKEY_LOCAL_MACHINE\SYSTEM part of Windows Registry as found at %SystemRoot%\System32\config\SYSTEM. It also establishes the HKEY_LOCAL_MACHINE\HARDWARE\ Registry part, which the I/O Manager Executive service will fill during driver initialization.

Windows drivers, in addition to the START value has three other properties - 
GROUP, TAG and DependOnGroup value which decides the time of the driver
initialization during the OS boot.

• I/O Manager sorts the SERVICE_BOOT_START drivers (loaded to memory by winload. efi reading the START value) according to their GROUP value by reading the Registry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder. It then sorts the sorted drivers against the TAG value within each group using the Registry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GroupOrderList to prepare the final list. It then traverses the list and initializes each driver according to its place in the list.

• Power Manager Executive service becomes functional with the initialization of ACPI.sys (a SERVICE_BOOT_START driver), which is to support power management and Plug and Play (PnP) device enumeration. HAL causes the ACPI.sys to be at the base of the Device Tree. The current system time is recorded as the System Boot time.

Until this point, only a single processor (or core in the case of a multi-core processor) is active. The system process thread calls HAL to initialize the rest of the processors (in the case of a multi-core processor, the rest of the cores).

• I/O Manager scans the Registry to load the SERVICE_SYSTEM_START drivers. The drivers are initialized in the same manner as above. 

During initialization, if I/O Manager encounters a driver which has DependOnGroup
value defined, it waits to initialize that driver till a driver belonging to that
particular group is not initialized. 

As part of initialization, I/O Manager also checks the return status. If a 
driver reports error on initialization, I/O Manager takes action according 
to the ErrorControl value as defined in the driver's registry key. In some case,
an error may prevent NT Kernel to continue booting resulting a BSOD. This type of
scenario can be investigated by enabling the Windows Boot log as created by the
NT Kernel and saved at %WinDir%\ntbtlog.txt

• Post initializing the kernel-space drivers, I/O Manager calls HAL to define the drive-letter mappings, which it does by reading the information from the registry path. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk

• I/O Manager invokes its subsystem Cache Manager, which works closely with the File-System subsystem and Memory Manager Executive service to cache file-system data in memory. Cache Manager helps in optimizing the OS performance as it greatly reduces expensive Disk operations every time a process/thread needs to access a file data.

• I/O Manager invokes its subsystem PnP Manager, enabling the OS to respond to Plug and Play devices.

PnP Manager initializes with one Virtual Device on the system named Root. 
This is used by HAL to detect bus and everything connected to the System Board.
The bus and devices as discovered by HAL returns a Vendor ID and Product ID. 
The PnP Manager reads the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum to
find a key which matches the returned Vendor ID and Product ID. 
The key contains a value Driver which points to a particular Registry key under
HKEY_LOCAL_MACHINE\ SYSTEM\ControlSet001\Control\Class which contains the value
InfPath (points to C:\WINDOWS\INF)telling the kernel from where to load the
driver. Alternately, if a match is not found meaning the driver is not present,
prompt to install driver will be triggered once Windows Explorer starts.

• Kernel Transaction Manager Executive service implements transaction processing in kernel mode, enabling processes/threads to use atomic transactions (ACID property to ensure data integrity) on resources (both kernel/user mode)

The communication between the Executive subsystems and Kernel is through Asynchronous Local Inter-Process Communication (ALPC) implemented via Native APIs – a lightweight API used within the Kernel space, by the Kernel Executive services for communication and providing assistance to the user-mode clients, exposed to the user-mode area via ntdll.dll.

With all the kernel space drivers initialized and Executive services functional, the System process thread invokes the Process and Thread Manager Executive service to create and launch the Session ManagerSubsystem process (smss.exe). This first user-mode process gets completed and is responsible for creating the user-mode environment that provides the visual interface to the Windows NT Kernel.

This marks the end of the Kernel Initialization and starts of the GUI interface.

Kernel Initialization – Components Schema representation

The below image shows the components of NT Kernel and is colored according to the initialization phase – blue denotes Phase 0, and green denotes Phase 1.

Windows Trusted Boot – Code Integrity?

The above gives you an overview and internals of the NT Kernel Initialization. Now let’s relate this to the security aspect.

The pre-boot UEFI phase is already protected by Secure Boot. But is it enough to ensure that the OS boots to a trusted and secure state?

No. Because if there is no checking mechanism implemented at the Kernel Initialization phase – this is when the drivers are executed, preparing the runtime.

Enter Windows Trusted Boot – which takes over from where Secure Boot left off. The bootloader verifies the digital signature of the Windows 10 kernel before loading it.

The Windows 10 kernel, in turn, verifies every other component of the Windows startup process, including the boot drivers, startup files, and ELAM.

The logic in the Kernel-Mode Code Signing Policy responsible for enforcing code integrity is shared between the Windows kernel image and the kernel-mode library ci.dll

For devices that clean install Windows 10 and where Secure Boot is On (this is standard for all new devices since the release of Windows 8.0), all new drivers must be signed by WHQL/Sysdev. Else will fail the code integrity check. Read this Microsoft document for more information.

If a critical component fails the integrity check, it may cause a BSOD as it will be denied from getting loaded and executed.

However, in most cases, Windows 10 will automatically try to repair the corrupted component restoring the integrity of Windows and allowing the PC to start normally.

However, if you are getting this frequently, the probable action plan would be

1. Run DISM /Online /Cleanup-Image /RestoreHealth

Deployment Image Servicing and Management tool will connect to the
Windows Update servers to download and replace any damaged files in the
local image for Windows 10 as necessary. Once this is complete…

2. Run SFC /scannow

This will scan all protected system files and replace corrupted files with a
cached copy that is located in a compressed folder at %WinDir%\System32\dllcache

Post this if still, you are getting the same BSOD. It could mean an issue
with the system itself, and you should run the UEFI diagnostics to check memory
and HDD.

Configurable Code Integrity

Further, a Windows 10 device can be restricted to only run authorized apps by using Configurable Code Integrity, part of the Windows Defender Application Control features of Windows 10.

The advantage of this is stated here in the Microsoft documentation.

You can configure and deploy a WDAC policy from Intune. Click here to know more about this.

Are you running Code Integrity as a separate service from the OS kernel?

With Virtual Secure Mode (VSM) – a feature that leverages the virtualization extensions of the CPU to provide the added security of data in memory, Windows 10 can run the entire Code Integrity as a VSM instance run under Hypervisor authority completely separate from the OS Kernel.

The feature name is Hypervisor Code Integrity (HVCI). This helps to harden the OS Kernel against memory attacks further.

With the Code Integrity service running as a virtual instance separate from the OS Kernel itself, the protected boot flow schema becomes

Role of ELAM in securing the Windows Boot

Secure Boot ensures trusted OS bootloader is allowed to execute, whereas Trusted Boot ensures that the OS kernel meets the trust. Here trust means Microsoft signs the components.

But when a system boots, it loads and executes numerous drivers, all of which are not Microsoft. Thus the next opportunity for malware to start is by infecting a non-Microsoft boot driver.

As I mentioned in my previous article, “Understanding UEFI Secure Boot – How it helps to secure the Windows 10 pre-boot phase”, traditional Anti Malware apps start post Kernel Initialization – thereby allowing a rootkit disguised as a driver to work.

Microsoft introduced the Early Launch Anti Malware (ELAM) driver – a detection mechanism for Windows systems that allows third-party security software, such as antivirus software, to register a kernel-mode driver that is guaranteed to execute early in the boot process before any other driver is loaded.

The ELAM driver receives callback routines from the Plug and Play manager executive to determine whether the driver should be initialized.

Based on the returned classification and defined policy, the PnP manager decides whether to initialize the boot driver.

Working as an ELAM driver

ELAM driver evaluates a driver signature and classifies it as good, bad, or unknown based on the malware signature data stored under HKLM\ELAM\<VendorName>\Where the ELAM driver vendor stores the allowlist/blocklist AV signatures for the ELAM driver to use.

This registry hive is loaded to memory by OS Bootloader (winload. efi) from c:\Windows\System32\config\ELAM. However, you won’t find this when you view the system’s registry post that the system has completed boot. This is for performance reasons. As the role of ELAM gets over, this registry hive also gets unloaded.

Kernel decides to load a driver post ELAM classification as per the policy defined at the registry path HKLM\SYSTEM\CurrentControlSet\Policies\EarlyLaunch\DriverLoadPolicy

The reg_dword DriverLoadPolicy can have the below values

8 = Good only
1 = Good and unknown
3 = Good, unknown, and bad but critical
7 = All

This can also be configured using GPO from under Computer Configuration \ Administrative Templates\ System \ Early Launch Antimalware\ Boot-Start Driver Initialization Policy

There is no policy defined by default, and Windows Kernel will load drivers with the following ELAM classification – Good, Bad but critical for boot and Unknown.

But by defining a policy, you can add more security by allowing only Good drivers to load. However, this sometimes might lead to instability.

As the Kernel initialization completes and the Windows subsystem starts (win32 environment), the runtime AV service gets initialized. At this point, the ELAM driver gives the handoff and is unloaded.

The runtime AV service takes the mantle for AV check and protection.

The default Windows ELAM driver

Yes, Windows Defender provides the default ELAM driver on Windows 10, and it is pretty good at its work, considering that it comes free. Microsoft being named the leader in the Gartner Magic Quadrant in Endpoint protection, it is quite easy to state that the AV from Microsoft is quite robust and effective.

Here you see the START_TYPE as DEMAND_START because my system has 3rd party AV service registering their ELAM driver.

3rd party AV service also allowed to register ELAM driver

Microsoft allows 3rd party AV services to register their ELAM driver if you choose to use them instead of the inbuilt AV solution that Windows 10 comes with.

You can see here that I have McAfee. My 3rd party Anti-Malware service has its own ELAM driver register START_TYPE set as BOOT_START and LOAD_ORDER_GROUP Early-Launch.

ELAM recovery

By default, it is the responsibility of the 3rd party AV service to store a copy of the ELAM driver in the registry-defined backup location, from where a copy of the ELAM driver can be obtained in case the original file gets corrupted.

This is usually the path C:\Windows\ELAMBKUP defined in the registry location HKLM\SYSTEM\CurrentControlSet\Control\EarlyLaunch via reg_key BackupPath

Does ELAM guarantee complete AV protection?

Sadly no. The ELAM works when nothing on the system has been initialized, and it also does not gets to check the driver package by itself. It only gets the driver signature details from the RPC call it receives from Kernel, which it uses to check against its fixed AV signature database as defined in the Registry.

This limits the ability of ELAM to detect heuristic or polymorphing malware.

But some protection/check mechanism is better than nothing, and in such a sense, ELAM plays its role well in securing the Windows boot flow.

Ending

If you have read this, you would be able, to sum up that Secure Boot protects the entire boot flow and Windows Trusted Boot, as shown below.

To be contd…

This article will be followed by my next article, where I will talk about the Windows Measured Boot and how it helps secure the Windows Boot flow.

As I always say, I read something new every day and learn something new every day…

Resources

• Code Integrity
• Virtual Security Mode in Windows 10
• Credential Guard
• Code Integrity Diagnostic System Log Events
• Viewing Code Integrity Events
• SetupAPI Text Logs