Project 8: Boot Integrity Monitor

Monitor boot component hashes against a trusted baseline.

Quick Reference

Attribute Value
Difficulty Level 3
Time Estimate 1-2 weeks
Main Programming Language Bash (Alternatives: Python, PowerShell)
Alternative Programming Languages Python, PowerShell
Coolness Level Level 3
Business Potential Level 2
Prerequisites OS internals basics, CLI usage, logging familiarity
Key Topics boot integrity, baselines

1. Learning Objectives

By completing this project, you will:

  1. Build a repeatable workflow for boot integrity monitor.
  2. Generate reports with deterministic outputs.
  3. Translate findings into actionable recommendations.

2. All Theory Needed (Per-Concept Breakdown)

Boot Chain, Secure Boot, and Measured Trust

Fundamentals The boot chain is the sequence of components that initialize a system from firmware to kernel. Secure Boot establishes trust by verifying digital signatures on boot components, while Measured Boot records hashes of those components into a TPM for later attestation. Rootkits that target the boot chain (bootkits) aim to execute before the operating system, which lets them subvert the kernel before it can defend itself. A defender must know exactly which files and firmware stages participate in boot, which signatures are expected, and where trust transitions occur. Without this map, you cannot know what to baseline or where to look for tampering.

Deep Dive into the concept Modern systems rely on a multi-stage boot process. On UEFI systems, firmware verifies a bootloader image using Platform Key (PK), Key Exchange Keys (KEKs), and signature databases (db, dbx). The bootloader then loads the OS kernel and early drivers. Secure Boot prevents unsigned or revoked components from loading, but it does not guarantee the integrity of already-signed components if an attacker can replace them with other signed-but-malicious binaries or abuse vulnerable signed drivers. Measured Boot complements Secure Boot by recording hashes of each stage into TPM PCRs. This does not block boot; it enables post-boot validation by comparing PCR values to a known-good baseline.

Trust boundaries in the boot chain exist at each handoff: firmware trusts the bootloader, the bootloader trusts the kernel, and the kernel trusts early drivers. Attackers target these boundaries because a single compromised stage can persist across reboots and hide within normal boot flows. Bootkits often target the EFI System Partition (ESP), replacing or modifying bootloaders, or they modify boot configuration data to load a malicious component early. On legacy BIOS/MBR systems, the first sectors of disk are the attack surface. Because boot components are rarely observed by routine host tools, a defender must explicitly inventory them and measure them.

Practical defense requires three activities: mapping, baselining, and verification. Mapping is enumerating the exact files, partitions, and signatures involved in boot. Baselining is recording hashes and signature metadata for those components and storing the baseline offline. Verification is continuously comparing current boot components to the baseline and alerting on drift. When updates occur, the baseline must be updated in a controlled, audited workflow.

Secure Boot policy is only as strong as the enforcement of signature databases. If dbx revocations are outdated or if a platform allows custom keys without governance, attackers can introduce their own trusted components. Measured Boot adds accountability: if PCRs change unexpectedly, you know the boot chain differs. But measuring is not detecting; you must actually retrieve and compare measurements. Rootkit defense therefore depends on operationalizing those checks, not just enabling Secure Boot in firmware.

How this fit on projects You will apply this in Section 3.1 (What You Will Build), Section 3.5 (Data Formats), and Section 4.1 (High-Level Design). Also used in: P02-boot-chain-map, P08-boot-integrity-monitor, P19-secure-boot-policy-review, P13-bootkit-response-playbook.

Definitions & key terms

  • Boot chain: Ordered sequence of firmware, bootloader, kernel, and early drivers that start the OS.
  • Secure Boot: Signature verification that blocks untrusted boot components from loading.
  • Measured Boot: Recording hashes of boot components into TPM PCRs for later attestation.
  • Bootkit: Rootkit that compromises boot components to execute before the OS.

Mental model diagram

[UEFI Firmware]
   |  (verifies)
   v
[Bootloader] --(loads)--> [Kernel] --(loads)--> [Early Drivers]
   |
   v
[TPM PCR Measurements]
   |
   v
[Attestation / Baseline Compare]

How it works (step-by-step)

  1. Firmware verifies bootloader signature using platform keys.
  2. Bootloader loads kernel and early drivers; hashes are measured into TPM.
  3. OS starts and reads boot configuration data and driver lists.
  4. Defender tool compares current hashes and PCR values to a trusted baseline.
  5. Any mismatch triggers investigation or containment.

Minimal concrete example

boot_component, path, signer, sha256
bootloader, \EFI\Microsoft\Boot\bootmgfw.efi, Microsoft, 9f...
kernel, C:\Windows\System32\ntoskrnl.exe, Microsoft, 4a...
boot_driver, C:\Windows\System32\drivers\elam.sys, Microsoft, c1...

Common misconceptions

  • “Secure Boot means no bootkits.” It reduces risk but does not prevent signed malicious components.
  • “Measured Boot blocks tampering.” It only measures; you must compare measurements.
  • “Boot integrity is a one-time check.” Updates and configuration changes require re-baselining.

Check-your-understanding questions

  • What is the difference between Secure Boot and Measured Boot?
  • Why is the ESP a common bootkit target?
  • What evidence proves a boot chain is unchanged?

Check-your-understanding answers

  • Secure Boot blocks untrusted components; Measured Boot records hashes for later validation.
  • The ESP contains bootloaders and configuration that execute before the OS; modifying it enables early execution.
  • Matching hashes or PCR measurements against a known-good baseline is strong evidence.

Real-world applications

  • Enterprise boot integrity baselining and compliance checks.
  • Incident response for suspected boot-level compromise.

Where you’ll apply it You will apply this in Section 3.1 (What You Will Build), Section 3.5 (Data Formats), and Section 4.1 (High-Level Design). Also used in: P02-boot-chain-map, P08-boot-integrity-monitor, P19-secure-boot-policy-review, P13-bootkit-response-playbook.

References

  • Microsoft Secure Boot documentation
  • NIST SP 800-147 (BIOS protection guidelines)
  • UEFI specification sections on Secure Boot

Key insights Boot integrity is a chain; the weakest or unmeasured link decides trust.

Summary Secure Boot verifies; Measured Boot records. You need both, plus baselines and monitoring.

Homework/Exercises to practice the concept

  • Enumerate the boot components on your OS and note their signature status.
  • Compare boot hashes before and after a system update.

Solutions to the homework/exercises

  • Your list should include firmware, bootloader, kernel, and early drivers with signer names.
  • After updates, at least one boot component hash should change; document it and update the baseline.

Integrity Baselines, Hashing, and Drift Management

Fundamentals An integrity baseline is a recorded snapshot of trusted system components and their cryptographic hashes. In rootkit defense, baselines allow you to detect subtle changes to bootloaders, kernels, drivers, and critical configuration files. A hash is a fingerprint; when it changes, the underlying content has changed. Baselines must be stored out-of-band so a compromised system cannot rewrite them. Drift management is the discipline of updating baselines after legitimate changes and documenting why a change is expected. Without drift management, baselines either generate noise or become obsolete.

Deep Dive into the concept A baseline is only meaningful if you trust the state you captured. That means you collect it from a known-good system state and you store it where it cannot be modified by an attacker. For boot and kernel integrity, the baseline should include paths, hashes, sizes, signer metadata, and version identifiers. Hash choice matters: SHA-256 or better is standard for integrity. You also need to record the hash tool version and operating system build because differences in tooling or build can change file layouts or metadata.

Drift is inevitable because software updates change files. The mistake is treating drift as noise. Instead, drift should be managed as a controlled change process. When a patch is applied, you update the baseline with evidence: the patch ID, the time, and the list of changed components. Some teams sign baseline files or store them in a WORM location to prevent tampering. Another approach is to store baselines in a central secure system and compare the local system to that secure copy.

The baseline schema should be explicit. For each component, include: file path, hash, signer, file size, timestamp, and expected owner/permissions. This allows you to detect not just content changes but also permission changes that might signal tampering. If you run baselines across multiple OSes, create a common schema but allow OS-specific fields (e.g., Authenticode signer on Windows, module signing key on Linux, SIP state on macOS).

Operationally, baselines are only useful if there is a diff workflow. A diff tool should categorize changes: expected (known patch), suspicious (unsigned driver appears), and unknown (hash mismatch without explanation). The diff output should be actionable: it should highlight what changed, where, and how to reproduce the check. If a system is compromised, baselines enable you to identify the earliest point of drift and decide whether to rebuild.

Finally, baselines are not just for detection; they are for accountability. A well-maintained baseline program forces teams to document changes, which makes stealthy tampering harder to hide. In rootkit defense, the baseline is the anchor that turns “unknown” into a measurable delta.

How this fit on projects You will apply this in Section 3.2 (Functional Requirements), Section 3.5 (Data Formats), and Section 6.2 (Critical Test Cases). Also used in: P03-integrity-baseline-builder, P08-boot-integrity-monitor, P20-rootkit-defense-toolkit.

Definitions & key terms

  • Baseline: A trusted snapshot of component hashes and metadata used for comparison.
  • Drift: Any change between current state and baseline, whether legitimate or malicious.
  • Hash: A cryptographic fingerprint that changes when file contents change.
  • WORM storage: Write-once, read-many storage to prevent tampering with baselines.

Mental model diagram

[Known-Good System]
   |  (hash + metadata)
   v
[Baseline JSON] --(stored offline)--> [Comparison Engine]
   ^                               |
   |  (hash live system)           v
[Current System] -------------> [Diff Report]

How it works (step-by-step)

  1. Collect hashes and metadata from a known-good system state.
  2. Store the baseline offline or in a secured repository.
  3. Collect the same fields from the live system.
  4. Compare current state to baseline and categorize drift.
  5. Update baseline only after verified change approval.

Minimal concrete example

{
  "component": "kernel",
  "path": "/boot/vmlinuz-6.6.8",
  "sha256": "9f...",
  "signer": "Build Key",
  "version": "6.6.8",
  "collected_at": "2026-01-01T10:00:00Z"
}

Common misconceptions

  • “Baselines are set-and-forget.” Without updates, they become noisy and ignored.
  • “Hashes alone are enough.” Metadata like signer and permissions provides additional context.
  • “Storing baselines on the same host is safe.” A compromised host can tamper with them.

Check-your-understanding questions

  • Why should baseline data be stored offline?
  • What fields beyond hashes are useful in a baseline?
  • How do you reduce false positives from software updates?

Check-your-understanding answers

  • Offline storage prevents a compromised system from rewriting the baseline.
  • Signer, file size, version, and permissions help identify suspicious changes.
  • Track patch IDs and update baselines only after verified changes.

Real-world applications

  • System integrity monitoring in regulated environments.
  • Golden image compliance validation for server fleets.

Where you’ll apply it You will apply this in Section 3.2 (Functional Requirements), Section 3.5 (Data Formats), and Section 6.2 (Critical Test Cases). Also used in: P03-integrity-baseline-builder, P08-boot-integrity-monitor, P20-rootkit-defense-toolkit.

References

  • NIST SP 800-94 (Guide to Intrusion Detection and Prevention Systems)
  • CIS Benchmarks - integrity monitoring guidance

Key insights A baseline turns invisible changes into measurable drift with accountability.

Summary Hash baselines detect tampering, but only if you store and update them correctly.

Homework/Exercises to practice the concept

  • Design a baseline schema for boot files and drivers.
  • Write a diff rule that labels changes as expected or suspicious.

Solutions to the homework/exercises

  • Your schema should include path, hash, signer, size, timestamp, and OS build.
  • A diff rule should check for missing patch IDs or unsigned new components.

3. Project Specification

3.1 What You Will Build

A tool or document that delivers: Monitor boot component hashes against a trusted baseline.

3.2 Functional Requirements

  1. Collect required system artifacts for the task.
  2. Normalize data and produce a report output.
  3. Provide a deterministic golden-path demo.
  4. Include explicit failure handling and exit codes.

3.3 Non-Functional Requirements

  • Performance: Complete within a typical maintenance window.
  • Reliability: Outputs must be deterministic and versioned.
  • Usability: Clear CLI output and documentation.

3.4 Example Usage / Output

$ ./P08-boot-integrity-monitor.sh --report
[ok] report generated

3.5 Data Formats / Schemas / Protocols

Report JSON schema with fields: timestamp, host, findings, severity, remediation.

3.6 Edge Cases

  • Missing permissions or insufficient privileges.
  • Tooling not installed (e.g., missing sysctl or OS query tools).
  • Empty data sets (no drivers/modules found).

3.7 Real World Outcome

A deterministic report output stored in a case directory with hashes.

3.7.1 How to Run (Copy/Paste)

./P08-boot-integrity-monitor.sh --out reports/P08-boot-integrity-monitor.json

3.7.2 Golden Path Demo (Deterministic)

  • Report file exists and includes findings with severity.

3.7.3 Failure Demo

$ ./P08-boot-integrity-monitor.sh --out /readonly/report.json
[error] cannot write report file
exit code: 2

Exit Codes:

  • 0 success
  • 2 output error

4. Solution Architecture

4.1 High-Level Design

[Collector] -> [Analyzer] -> [Report]

4.2 Key Components

Component Responsibility Key Decisions
Collector Collects raw artifacts Prefer OS-native tools
Analyzer Normalizes and scores findings Deterministic rules
Reporter Outputs report JSON + Markdown

4.3 Data Structures (No Full Code)

finding = { id, description, severity, evidence, remediation }

4.4 Algorithm Overview

Key Algorithm: Normalize and Score

  1. Collect artifacts.
  2. Normalize fields.
  3. Apply scoring rules.
  4. Output report.

Complexity Analysis:

  • Time: O(n) for n artifacts.
  • Space: O(n) for report.

5. Implementation Guide

5.1 Development Environment Setup

python3 -m venv .venv && source .venv/bin/activate
# install OS-specific tools as needed

5.2 Project Structure

project/
|-- src/
|   `-- main.py
|-- reports/
`-- README.md

5.3 The Core Question You’re Answering

“How do you detect boot component tampering early?”

This project turns theory into a repeatable, auditable workflow.

5.4 Concepts You Must Understand First

  • Relevant OS security controls
  • Detection workflows
  • Evidence handling

5.5 Questions to Guide Your Design

  1. What data sources are trusted for this task?
  2. How will you normalize differences across OS versions?
  3. What is a high-confidence signal vs noise?

5.6 Thinking Exercise

Sketch a pipeline from data collection to report output.

5.7 The Interview Questions They’ll Ask

  1. What is the main trust boundary in this project?
  2. How do you validate findings?
  3. What would you automate in production?

5.8 Hints in Layers

Hint 1: Start with a small, deterministic dataset.

Hint 2: Normalize output fields early.

Hint 3: Add a failure path with clear exit codes.

5.9 Books That Will Help

Topic Book Chapter
Rootkit defense Practical Malware Analysis Rootkit chapters
OS internals Operating Systems: Three Easy Pieces Processes and files

5.10 Implementation Phases

Phase 1: Data Collection (3-4 days)

Goals: Collect raw artifacts reliably.

Tasks:

  1. Identify OS-native tools.
  2. Capture sample data.

Checkpoint: Raw dataset stored.

Phase 2: Analysis & Reporting (4-5 days)

Goals: Normalize and score findings.

Tasks:

  1. Build analyzer.
  2. Generate report.

Checkpoint: Deterministic report generated.

Phase 3: Validation (2-3 days)

Goals: Validate rules and handle edge cases.

Tasks:

  1. Add failure tests.
  2. Document runbook.

Checkpoint: Failure cases documented.

5.11 Key Implementation Decisions

Decision Options Recommendation Rationale
Report format JSON, CSV JSON Structured and diffable
Scoring Simple, Weighted Weighted Prioritize high risk findings

6. Testing Strategy

6.1 Test Categories

Category Purpose Examples
Unit Tests Parser logic Sample data parsing
Integration Tests End-to-end run Generate report
Edge Case Tests Missing permissions Error path

6.2 Critical Test Cases

  1. Report generated with deterministic ordering.
  2. Exit code indicates failure on invalid output path.
  3. At least one high-risk finding is flagged in test data.

6.3 Test Data

Provide a small fixture file with one known suspicious artifact.

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

Pitfall Symptom Solution
Noisy results Too many alerts Add normalization and thresholds
Missing permissions Script fails Detect and warn early

7.2 Debugging Strategies

  • Log raw inputs before normalization.
  • Add verbose mode to show rule evaluation.

7.3 Performance Traps

Scanning large datasets without filtering can be slow; restrict scope to critical paths.

8. Extensions & Challenges

8.1 Beginner Extensions

  • Add a Markdown summary report.

8.2 Intermediate Extensions

  • Add a JSON schema validator for output.

8.3 Advanced Extensions

  • Integrate with a SIEM or ticketing system.

9. Real-World Connections

9.1 Industry Applications

  • Security operations audits and detection validation.
  • osquery - endpoint inventory

9.3 Interview Relevance

  • Discussing detection workflows and auditability.

10. Resources

10.1 Essential Reading

  • Practical Malware Analysis - rootkit detection chapters

10.2 Video Resources

  • Conference talks on rootkit detection

10.3 Tools & Documentation

  • OS-native logging and audit tools

11. Self-Assessment Checklist

11.1 Understanding

  • I can describe the trust boundary for this task.

11.2 Implementation

  • Report generation is deterministic.

11.3 Growth

  • I can explain how to operationalize this check.

12. Submission / Completion Criteria

Minimum Viable Completion:

  • Report created and contains at least one finding.

Full Completion:

  • Findings are categorized with remediation guidance.

Excellence (Going Above & Beyond):

  • Integrated into a broader toolkit or pipeline.