Cách săn rootkit kernel bằng logs và integrity

Khi mối đe doạ dần dịch chuyển xuống sâu hơn — từ ứng dụng, sang nhân hệ điều hành — mọi sai khác nhỏ nhất trong nhật ký (logs) và tính toàn vẹn (integrity) bỗng trở nên quý như vàng. Săn rootkit kernel không phải chỉ là “tìm kim trong bể cỏ khô”, mà là dàn dựng một hệ thống cảm biến đủ nhạy để nghe thấy cả khoảng lặng: dấu hiệu gián tiếp, những dòng log bị cắt bỏ nửa chừng, những giá trị bất biến (invariants) bỗng lệch pha. Bài viết này là một lộ trình thực dụng: đâu là nguồn tín hiệu tốt, cách diễn giải chúng, và làm thế nào để ghép logs với integrity thành một cặp bài trùng phơi bày rootkit kernel.

Vì sao rootkit kernel là “nốt nhạc im lặng” trong SOC?

Rootkit ở mức kernel (Linux, Windows, thậm chí hypervisor) sở hữu hai lợi thế: đặc quyền hệ thống tối cao và khả năng can thiệp vào đường ống quan sát. Chúng có thể:

• Hook/hijack đường đi của lệnh gọi hệ thống (syscall) hoặc bảng chức năng (như fops, netfilter hooks), che giấu tiến trình, tập tin, cổng mạng.
• Vô hiệu hoặc làm sai lệch các nguồn logs: chặn netlink, thao túng /proc, sửa đổi bộ đệm vòng kernel (kernel ring buffer), hoặc nạp driver không ký số rồi tự xóa dấu vết.
• Trốn tránh kiểm tra chữ ký nếu chuỗi tin cậy (chain of trust) bị rỗng đoạn: Secure Boot tắt, Code Integrity lỏng lẻo, IMA/EVM thiếu chính sách.

Điểm mấu chốt: đừng trông đợi một “bằng chứng duy nhất”. Săn rootkit là bài toán ghép mảnh — tìm bất thường liên chuỗi giữa logs, thiết lập giá trị bất biến, và kiểm định toàn vẹn theo thời gian.

Bản đồ nguồn log: nghe thấy điều kernel muốn nói

Để săn hiệu quả, bạn cần bản đồ nguồn tín hiệu. Dưới đây là những nguồn logs và sự kiện nền tảng nên chuẩn hoá và thu thập trung tâm:

• Linux

  • Kernel ring buffer: dmesg, /dev/kmsg, journald (unit: kernel). Các mẫu: “module verification failed”, “tainting kernel”, “Lockdown: …”, “IMA:”, “AppArmor:”/“SELinux:”.
  • auditd: theo dõi syscalls nhạy cảm (init_module, finit_module, delete_module, kexec_load), thay đổi sysctl, quyền trên /dev/mem, /dev/kmem, /dev/kmsg.
  • LSM (SELinux/AppArmor): các từ chối (denials) bất thường hé lộ hành vi chưa từng thấy của tiến trình đặc quyền.
  • eBPF/bpf-lsm telemetry: nếu cho phép, ghi lại hooks bảo mật (security_*) để phát hiện thao tác khả nghi trên executable, network, hoặc credential.
  • Trình tải module (modprobe, kmod) và biến thể dynamic loader: nhật ký nạp/gỡ module, lỗi chữ ký, đường dẫn bất thường.

• Windows

  • Event Logs liên quan Code Integrity, Driver, Kernel-Boot/Kernel-General, và các kênh Operational cho Device Guard/HVCI. Tìm dấu hiệu nạp driver không ký số, test-signed, hoặc vi phạm chính sách.
  • ETW (Event Tracing for Windows): nguồn tín hiệu giàu cho hoạt động kernel và driver; nên thu thập qua EDR hoặc Sysmon (nếu có cấu hình event về driver, registry, image load).
  • Tampering signal: sự kiện vô hiệu hoá bảo vệ, thay đổi Secure Boot, lỗi trong “Measured Boot”/TPM attestation do chuỗi khởi động bị can thiệp.

• Chéo nguồn (cross-host)

  • SIEM/SOAR: đồng bộ thời gian chính xác (NTP), chuẩn hoá hostnames, và enrichment về chính sách (host nào bật Secure Boot/IMA/Device Guard).
  • Mối tương quan (correlation) giữa log kernel, audit, EDR và FIM (File Integrity Monitoring) là tối quan trọng.

Săn qua bất thường trong logs (Linux)

Khi rootkit tìm cách nạp hoặc bám rễ, kernel thường “than phiền” trước khi kẻ xấu kịp tắt tiếng than. Hãy canh những mẫu sau:

• Dấu hiệu chữ ký và taint

  • module verification failed: signature and/or required key missing — tainting kernel
  • Kernel taint flags (Tainted: G W ...): W (warning), O (out-of-tree module), E (error), P (proprietary), X (staging)… Một cờ lạ, xuất hiện mới, hoặc chồng cờ bất thường là tín hiệu cần điều tra.
  • Lockdown: policy knocked down hoặc log vi phạm (chẳng hạn truy cập MSR, kexec) khi Kernel Lockdown mode bật.

• Hoạt động với module

  • Chuỗi log modprobe/kmod không khớp với hoạt động người dùng/CMDB.
  • Thời điểm gỡ (rmmod) và nạp lại module khó giải thích, đặc biệt ngoài lịch bảo trì.
  • Module tên “vô danh”, đường dẫn không chuẩn (không thuộc /lib/modules//), hoặc checksum lệch so với baseline.

• Chính sách LSM & IMA

  • SELinux/AppArmor denials xuất hiện trên tiến trình vốn “sạch” từ trước; ví dụ tiến trình hệ thống đòi truy cập đường dẫn /dev/mem, /dev/kmem, /dev/kmsg.
  • IMA/EVM: lỗi xác minh chữ ký tập tin thực thi hoặc policy thay đổi đột ngột.

• Chỉ dấu tắt tiếng

  • dmesg_restrict, kptr_restrict thay đổi so với baseline; cờ kernel.printk giảm mức in ra khiến ring buffer im hơi lặng tiếng.
  • journald bị cắt gọt đột ngột (rotation bất thường, rỗng log đúng thời điểm sự cố).

Ví dụ chuỗi tín hiệu bạn nên cảnh báo tức thì:

• Có log “module verification failed” + ngay sau đó audit ghi nhận delete_module hoặc modprobe lỗi.
• IMA log bắt đầu xuất hiện failures trên các binary hệ thống vừa cập nhật nhưng không được update khoá.
• Sysctl thay đổi: kernel.kptr_restrict → 2, kernel.dmesg_restrict → 1, net.core.bpf_jit_enable → 1 trên máy vốn baseline là 0 (hoặc ngược lại, tuỳ chính sách).

Săn qua bất thường trong logs (Windows)

Trên Windows, rootkit kernel thường đi kèm driver độc hại hoặc lợi dụng driver dễ bị lỗi. Một số hướng săn qua logs:

• Code Integrity/Device Guard/HVCI

  • Tín hiệu nạp driver không ký số, test-signed, hoặc bị chặn vì không đáp ứng chính sách. Theo dõi kênh Code Integrity/Device Guard để phát hiện lệch chuẩn này.
  • Ghi nhận thay đổi cấu hình làm suy yếu bảo vệ: tắt VBS/HVCI, thay đổi Secure Boot, hoặc boot thông qua chế độ không đo lường (unmeasured).

• Kernel và Driver Operational

  • Bất thường ở chuỗi khởi động (Kernel-Boot/Kernel-General) và tải driver sớm (early-boot). Lỗi lặp lại quanh cùng một driver vendor/đường dẫn lạ là tín hiệu đỏ.
  • Event về filter drivers (File System Minifilter) mới xuất hiện không khớp CMDB.

• Sysmon/EDR

  • ImageLoad, DriverLoad (nếu hỗ trợ): file driver từ thư mục không chuẩn, có timestamp “quá hoàn hảo” (tương lai/quá khứ xa), hoặc hash không trùng baseline.
  • Registry thay đổi liên quan service type=kernel driver, start=0/1 (BOOT/ SYSTEM) mờ ám.

• Tín hiệu tắt tiếng

  • Nhật ký bảo vệ bị vô hiệu (Operational channel tắt), hoặc chính sách audit giảm chi tiết bất ngờ.

Integrity là sợi dây an toàn: từ boot đến runtime

Khai thác integrity đúng cách giúp bạn biến rootkit thành kẻ “không hộ chiếu” trong chuỗi tin cậy.

• Chuỗi tin cậy từ boot

  • UEFI Secure Boot: chỉ cho phép kernel và bootloader đã ký số với khoá tin cậy. Trên máy chủ, hãy bắt buộc chế độ này cùng với khoá quản trị riêng (custom keys) để kiểm soát vendor.
  • Measured Boot + TPM Attestation: đo (measure) các thành phần boot vào PCR; thu thập và so sánh “quotes” qua hệ thống attestation để phát hiện sai lệch theo lô (fleet).

• Nội dung hệ thống tệp

  • fs-verity/dm-verity: bảo vệ tính bất biến ở cấp file/block cho các binary trọng yếu.
  • AIDE/Tripwire/Wazuh FIM: baseline hoá /boot, /lib/modules//, /etc/modprobe.d/, các binary đặc quyền, và tự động cảnh báo khi thay đổi.

• Thực thi và tải mã

  • Module signing: bật bắt buộc chữ ký, kết hợp Kernel Lockdown (Linux) để chặn viết vào MSR/kexec/đọc kmsg.
  • IMA/EVM: chính sách xác minh và đo lường (measure + appraisal) đối với executable, libraries, và scripts nhạy cảm. Gửi log IMA về SIEM để phát hiện failure theo thời gian.
  • Windows: Device Guard/Code Integrity/HVCI: bắt buộc driver đã ký, dùng policies ở chế độ Enforce (không chỉ Audit) trên máy sản xuất có độ nhạy cao.

• Invariants (bất biến) vận hành

  • Không chỉ “file hash”: bất biến còn là số module hợp lệ, danh sách netfilter hooks đã phê duyệt, sysctl quan trọng, danh sách driver/filters hợp lệ, và trạng thái bảo vệ (Secure Boot, HVCI) đối với từng lớp máy.

Thiết lập baseline và “cross-view” để lộ kẻ ẩn mình

Rootkit hay chặn một nguồn quan sát, nhưng hiếm khi che được mọi nguồn. Chiến lược cross-view so sánh chéo nhiều kênh giúp phơi bày “điểm sai”:

• Process và network

  • So sánh danh sách tiến trình từ user-space (ps) với dữ liệu hạt nhân (eBPF trace, audit fork/exec) và /proc. Một tiến trình “chỉ xuất hiện” trong một kênh là bất thường.
  • So sánh socket đang lắng nghe giữa ss/netstat, /proc/net/*, và telemetry eBPF. Port “mồ côi” hoặc bị ẩn ở một kênh là dấu hiệu che giấu.

• Module/driver

  • Cross-check giữa /proc/modules, lsmod, /sys/module và nhật ký nạp/gỡ. Trên Windows, so sánh Service Control Manager (SCM) entries với Module list từ EDR.
  • Bất biến: module/driver chỉ được nạp từ whitelist; bất kỳ tên lạ, đường dẫn lạ hoặc hash lệch đều cần điều tra.

• Sysctl và chính sách

  • Kiểm soát kptr_restrict, dmesg_restrict, unprivileged_bpf_disabled, kexec_load_disabled. Lập baseline theo lớp máy (prod/dev) và cảnh báo khi sai lệch.

• Filesystem

  • So sánh FIM chống lại package manager database (rpm, dpkg) và danh mục phát hành nội bộ; các binary “không thuộc gói” xuất hiện trong đường dẫn hệ thống là tín hiệu đỏ.

Playbook săn rootkit: từ tín hiệu đến kết luận

Một playbook gọn, kỷ luật giúp tránh “đánh động” kẻ ẩn mình và mất bằng chứng.

• Nhận diện và phân loại tín hiệu

  • Tín hiệu chữ ký/taint/module; Integrity failures; Thay đổi chính sách; Khoảng trống/log rỗng đúng dịp.
  • Gán mức rủi ro: driver/kernel-space vs user-space; early-boot vs runtime.

• Cô lập an toàn và bảo toàn bằng chứng

  • Hạn chế thao tác trực tiếp: tránh chạy lệnh tuỳ tiện trên host nghi nhiễm.
  • Cô lập mạng theo hướng inbound/outbound tối thiểu cần thiết để thu thập bằng chứng từ xa.
  • Thu thập bộ nhớ (memory acquisition) bằng công cụ chuẩn mực và đã được phê duyệt, đồng thời ghi nhận chuỗi kiểm soát (chain-of-custody).

• Thu thập logs và dữ liệu toàn vẹn

  • Kéo về mọi nguồn: dmesg/kmsg, audit, LSM denials, IMA runtime measurements, Sysmon/EDR, FIM diffs, cấu hình Secure Boot/Device Guard.
  • Đối chiếu với baseline (hash, số module, danh sách hooks) và CMDB (driver hợp lệ theo phần cứng).

• Phân tích chéo và giả thuyết

  • Xây giả thuyết dựa trên chùm tín hiệu (ví dụ: nạp module không ký + kptr_restrict thay đổi + port ẩn chỉ thấy qua eBPF) rồi kiểm chứng từng mảnh.

• Quyết định xử lý

  • Nếu nghi ngờ cao: chuyển sang phân tích ngoại tuyến (offline), reimage có kiểm soát sau khi thu thập đầy đủ.
  • Cập nhật quy tắc săn (hunt rules) và baseline để ngăn tái diễn.

Công cụ thực dụng và cách dùng an toàn

• FIM/Integrity

  • AIDE/Tripwire/Wazuh: lập lịch kiểm tra /boot, /lib/modules, /etc/modprobe.d, binary đặc quyền; gửi diff vào SIEM. Gắn nhãn mức nghiêm trọng theo đường dẫn/ownership.
  • IMA/EVM: bật measure + appraisal nơi phù hợp; chuyển ascii_runtime_measurements vào pipeline phân tích. Cảnh báo theo mẫu “appraise fail” và “unknown key”.

• Telemetry và truy vấn

  • osquery: thu thập kernel_modules, processes, listening_ports, crontab, drivers (Windows), registry keys liên quan service/driver. Thiết lập pack cho "kernel hygiene".
  • Sysmon (Windows) hoặc EDR tương đương: bật sự kiện ImageLoad/DriverLoad/Registry theo whitelist; giảm nhiễu bằng baseline theo nhóm máy.

• SIEM/SOAR

  • Chuẩn hoá và enrich: gắn metadata về Secure Boot/Device Guard/IMA policy version vào mỗi host event.
  • Kịch bản SOAR: khi thấy “module verification failed” → kiểm tra gần nhất auditd về finit_module → lấy snapshot sysctl quan trọng → mở ticket P1 nếu trùng khớp.

• eBPF/bpf-lsm (Linux)

  • Dùng cho quan sát runtime (exec, net, file) trong môi trường kiểm soát; log tối thiểu cần thiết, tránh mở bừa bãi gây tăng bề mặt tấn công.

• Cảnh báo về công cụ lỗi thời

  • Một số trình dò rootkit cổ điển thường tạo false negative/positive. Dùng chúng như chỉ số bổ trợ, không phải nguồn chân lý.

Những bẫy thường gặp và cách gỡ

• False positive do driver hợp lệ

  • Các module/proprietary driver có thể gây “taint” nhưng vẫn hợp lệ (ví dụ O/P). Xác minh theo whitelist vendor/hardware.

• Phản ứng quá tay

  • Gỡ module bừa bãi có thể gây crash, mất dữ liệu. Ưu tiên thu thập bằng chứng, cô lập, và khôi phục có kiểm soát.

• Thiếu baseline theo lớp máy

  • Máy GPU/FPGA/Storage HBA có driver riêng, lịch cập nhật riêng; không baseline → cảnh báo ồ ạt vô ích.

• Log bị bóp nghẹt

  • Kernel ring buffer nhỏ, rotation gấp; journald không forward kịp. Giải pháp: tăng kích thước buffer, forward thời gian thực, bảo toàn log off-host.

• Bỏ quên chuỗi tin cậy

  • Secure Boot tắt khi bảo trì và không bật lại; IMA bật measure nhưng không appraisal; Device Guard ở Audit thay vì Enforce. Kẻ tấn công chỉ cần một lỗ hổng nhỏ.

Tình huống minh hoạ: module mồ côi và netfilter lạ

Hãy tưởng tượng đội SOC nhận được cảnh báo từ SIEM: “module verification failed — tainting kernel” trên một node chạy dịch vụ cổng API.

• Tín hiệu đầu vào

  • dmesg: module verification failed (không chỉ rõ tên), sau đó có dòng rmmod không khớp lịch vận hành.
  • auditd: ghi nhận finit_module từ tiến trình lạ không thuộc change window; kế tiếp là cap_sys_module bị từ chối bởi LSM vài lần trước khi thành công.
  • FIM: thay đổi trong /etc/modprobe.d/ với một alias mới không thuộc baseline.
  • Netflow/eBPF: xuất hiện hook netfilter mới, số lượng kết nối outbound tăng đột ngột trong khoảng 30 giây rồi trở lại bình thường.

• Điều tra

  • Cross-view: lsmod không thấy module mới, nhưng /sys/module có thư mục ephemeral biến mất khi quét lại; eBPF vẫn thấy callback netfilter tại địa chỉ không khớp symbol table.
  • Sysctl: kernel.kptr_restrict tăng lên 2 đúng vào thời điểm cảnh báo; journald bị rotation, trống khoảng 2 phút logs.
  • IMA: xuất hiện appraisal fail cho một helper binary vừa chạy trong thời gian bất thường.

• Kết luận và xử lý

  • Chùm tín hiệu gợi ý module/patch tạm thời, ẩn khỏi /proc nhưng vẫn để lộ hook ở lớp mạng. Đội IR cô lập máy, thu thập bộ nhớ và khởi động phân tích offline. Hậu kỳ, họ gia cố: bắt buộc module signing, mở rộng IMA appraisal, tăng forward dmesg theo thời gian thực, và thêm rule SOAR tự động hoá triage khi kptr_restrict thay đổi ngoài lịch.

Mẫu truy vấn và rules khởi điểm

• Linux (dấu hiệu nạp/gỡ module, chữ ký, thay đổi sysctl)

  • Truy vấn SIEM: tìm "module verification failed", "tainting kernel", "Lockdown:" gần nhau trong 5 phút, kèm audit event finit_module/delete_module.
  • Cảnh báo khi sysctl kernel.kptr_restrict, kernel.dmesg_restrict, kernel.kexec_load_disabled thay đổi ngoài change window.

• Windows (driver và integrity)

  • Tìm sự kiện nạp driver không ký số/test-signed hoặc vi phạm chính sách Device Guard; kết hợp với thay đổi registry dịch vụ kiểu kernel driver start=0/1.
  • Cảnh báo khi kênh Code Integrity/Operational bị tắt hoặc giảm mức ghi.

• Cross-view

  • Chênh lệch giữa số process từ ps và audit execve trong cùng khung thời gian > ngưỡng; giữa listening_ports (osquery) và /proc/net/*; giữa danh sách module từ lsmod và IMA measurement về module file.

• Integrity/FIM

  • Rule: bất kỳ thay đổi file dưới /boot, /lib/modules//, /etc/modprobe.d/ hoặc binary setuid/setcap → P1/P2 tuỳ môi trường.

Lưu ý: triển khai theo mức độ “ồn” của hệ thống; luôn baseline trước khi bật cảnh báo nghiêm ngặt.

Lộ trình nâng cấp khả năng săn: từ logs đến attestation

• Giai đoạn 1: Ổn định log pipeline

  • Forward dmesg/kmsg, audit, LSM, IMA; chuẩn hoá timestamp và host metadata; tăng buffer và độ bền logs.

• Giai đoạn 2: Baseline và bất biến

  • Xây whitelist module/driver theo lớp máy; baseline sysctl nhạy cảm; bật module signing/Lockdown/Code Integrity.

• Giai đoạn 3: Cross-view tự động

  • So sánh ps vs audit/eBPF; listening ports vs /proc; module list vs IMA; phát hiện chênh lệch tự động và cảnh báo theo ngưỡng.

• Giai đoạn 4: Integrity nâng cao

  • IMA appraisal rộng hơn; fs-verity/dm-verity cho binary trọng yếu; measured boot + TPM attestation với so khớp từ xa.

• Giai đoạn 5: Purple team và kiểm chứng

  • Kiểm thử định kỳ bằng mô phỏng hành vi rootkit ở môi trường lab cách ly; hiệu chỉnh rule để cân bằng độ nhạy/độ chính xác; mở rộng coverage qua eBPF/ETW có kiểm soát.

Săn rootkit kernel bằng logs và integrity là hành trình kết hợp kỹ thuật và kỷ luật: bạn lắng nghe từng nhịp thở của kernel, giữ cho chuỗi tin cậy luôn căng, và dùng cross-view để khiến mọi chiêu che giấu trở nên kệch cỡm. Khi pipeline logs vững, baseline rõ, và integrity được áp dụng từ boot tới runtime, rootkit không còn đất diễn — hoặc ít nhất, chúng sẽ để lại đủ nhiều “tiếng động” để bạn lần ra và khoanh vùng kịp thời.