Sanctum EDR Documentation

Sanctum EDR is an experimental, proof-of-concept Endpoint Detection and Response (EDR) tool written entirely in Rust. It is designed for low-level Windows system security research and includes features like kernel-side syscall interception, ETW Threat Intelligence telemetry subscription, and rootkit/NTDLL tampering detection.

Warning: This project manipulates the Windows kernel (Windows 11). Do not deploy this on your host machine; use a Virtual Machine (VM) to avoid system instability.

The project is organized into several crates with specific roles:

• driver: The Rust kernel driver required for kernel monitoring.
• um_engine: The user-mode engine that communicates with the driver, running processes, and the GUI.
• gui: The user interface built with Tauri.
• shared_*: Shared crates for std and no_std environments.
• server: (In development) A telemetry server for receiving signals from endpoints.
• injected_dll: (Deprecated) A DLL for EDR hooking, replaced by kernel-side Alt Syscalls.

Deprecated Modules:

• etw_installer: Used to create the ELAM PPL service.
• sanctum_ppl_runner: An ELAM-signed Protected Process Light (PPL) for monitoring ETW Threat Intelligence.
• etw_consumer: Deprecated; functionality is now handled by sanctum_ppl_runner.

After signing the driver, build the remaining components from the repository root:

PPL Service (Must be release mode):

1. cargo build --release -p sanctum_ppl_runner
2. .\sign_ppl_runner.bat

Other Components:

1. cargo build --release -p elam_installer
2. cargo build --release -p injected_dll
3. cargo build --release -p um_engine
4. cargo tauri build --debug (for the GUI)

cargo build --release -p sanctum_ppl_runner
.\sign_ppl_runner.bat

# Other components
cargo build --release -p elam_installer
cargo build --release -p injected_dll
cargo build --release -p um_engine
cargo tauri build --debug

To build and deploy Sanctum, you need the following installed:

1. Rust/Cargo: Use the Nightly channel.
2. Windows Driver Kit (WDK): Includes the Developer Console (must run as Administrator for driver builds).
3. Build Tools: cargo make and LLVM tools (refer to Microsoft's windows-drivers-rs instructions).
4. Tauri Build Tools: Required for the GUI component.

The driver requires a specific signing process involving a custom hash in build.rs:

1. Open a Developer Command Prompt as Administrator.
2. Navigate to the driver crate.
3. Generate an ELAM compatible certificate: .\cert.ps1 (creates sanctum.pfx in the driver root).
4. Build the driver: cargo make.
5. Sign the driver: .\sign.bat.
6. Update the Build Hash:
   • Run certmgr.exe -v target\debug\sanctum_package\sanctum.sys.
   • Locate the Content Hash (To-Be-Signed Hash):: section.
   • Concatenate the two lines of bytes into one long string.
   • Open driver/build.rs and replace the existing hash with your new concatenated string.
7. Rebuild and re-sign:
   • cargo clean
   • cargo make
   • .\sign.bat

.
.\cert.ps1
.\cargo make
.\sign.bat
# After updating build.rs hash:
.\cargo clean
.\cargo make
.\sign.bat

Before deploying, prepare a clean Windows 11 VM with the following configuration:

1. Hardware/BIOS: Use a Gen2 processor, enable Secure Boot and TPM during initial installation.
2. Post-Install: Update Windows, then Disable Secure Boot and TPM.
3. Initialization:
   • Copy installer_clean_vm.ps1 from the repository root to the VM.
   • Open PowerShell as Administrator.
   • Run Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass.
   • Run ./installer_clean_vm.ps1 to initialize the folder structure, download static files, and configure the VM for WinDbg kernel debugging.

Polling Rate

When initializing Core::from(poll_rate), the poll_rate is defined in milliseconds. This determines how frequently the engine queries the kernel driver. Note that the actual interval may be slightly longer due to the synchronous nature of the decision-making loop.

Injection Logic

The core automatically monitors for image_loads reported by the driver. When a target process is detected, the core attempts to inject the EDR DLL via inject_edr_dll. If injection fails (e.g., due to PPL or AppContainers), the core notifies the driver via ioctl_dll_inject_failed to prevent unnecessary 'ghost hunting' of that process.

The Sanctum driver operates in one of two modes, which determines how it responds to detected threats:

• ReportOnly: The driver logs events but does not take active measures to stop them.
• Blocking: The driver actively intervenes to contain threats (e.g., by terminating processes).

Note: Currently, the DRIVER_MODE is a static value. To change this mode, a device reboot is required for the change to take effect. Future versions intend to support changing this via an IOCTL.

// Available DriverMode variants:
// DriverMode::ReportOnly
// DriverMode::Blocking

The injected DLL follows a specific initialization sequence to ensure system stability and security monitoring during the patching process:

1. Thread Suspension: All threads in the target process are suspended except for the thread running the initialization.
2. Stub Resolution: The DLL resolves the virtual addresses for both the original NTDLL syscall functions and the EDR callback functions (stubs).
3. NTDLL Patching: The DLL patches NTDLL syscall stubs to redirect execution to the EDR's callback functions.
4. Integrity Monitoring: The NTDLL integrity monitor is started to protect the newly patched memory.
5. Engine Notification: An IOCTL is sent to the driver via send_ipc_to_engine using DLLMessage::ProcessReadyForGhostHunting to signal the process is ready.
6. Thread Resumption: All previously suspended threads are resumed.