SentinelOne防竄改機制

起因是看到Akamai 的研究文章，因此對於S1的防竄改機制做個研究整理。

2026 Akamai 研究核心手法：

• 濫用 SentinelHelper.1 COM 介面的 Dump 方法
  • 這個方法只檢查管理員權限，沒有嚴格驗證呼叫來源路徑
  • 因為繼承了 S1 的 PsProtectedSignerAntimalware-Light 等級，所以可以 Dump 其他 PPL 進程（包含 S1 自己和 Defender 的 MsMpEng）
• 從 Dump 出來的記憶體中提取 COM Secret / Context
• 結合 James Forshaw 的 IRundown DoCallback COM remoting 技術，把未簽名程式碼注入到其他 PPL 進程中執行
• 可進一步用「Bring Your Own Installer」概念安裝無授權的 S1 Agent，讓它自動禁用原本的防護軟體，並用自己的 PPL 保護惡意 payload

只靠 S1 自己暴露的介面 + 管理員權限就能跨過保護邊界。

個人建議

1. 強化 SentinelHelper 的呼叫者驗證

此次問題的核心是：

• Dump 方法只檢查「是否有管理員權限」
• 沒有驗證呼叫者的：
  • 進程路徑是否在合法的 SentinelOne 安裝目錄
  • 是否有正確的數位簽章（SentinelOne 的簽章）
  • 是否為預期的合法診斷工具

建議做法：

• 檢查呼叫進程的完整路徑
• 驗證呼叫進程的數位簽章必須是 SentinelOne 官方簽章
• 只允許特定的合法二進位（例如 Troubleshooter / Diagnostic 工具）呼叫 Dump
• 對非預期的呼叫來源直接拒絕，並記錄詳細的安全事件

2. 其他措施

機制介紹：

以下是SentinelOne的防竄改機制架構：

1
2
3
4
5
6
7
8
9
10
11
12

               SentinelOne
                    │
           Anti-Tamper「功能」
        ┌──────────┼───────────┐
        │          │           │
     Windows      macOS       Linux
        │          │           │
   Windows機制   Apple機制   Linux機制
     COM/PPL      ESF/SIP    Kernel/eBPF
        │
SentinelHelper COM

Windows機制

COM,Component Object Model，元件物件模型。

元件物件模型（Component Object Model，簡稱 COM）是微軟推出的一套軟體元件二進位介面標準，讓不同程式語言寫成的程式與物件能互相溝通、重複使用。

這東西的起源：
Windows作業系統在應用程式之間提供了三種通訊機制:剪貼簿（剪貼簿）、DDE和OLE。
OLE 的原名是 Object Linking and Embedding。OLE 可以說是 DDE 的改良版。
OLE 1。0 版本提供複合文件處理功能。然而,由於其複雜性,Brockschmidt 和 Kraig 的書《OLE 內部》提到,需要六個月的精神混亂才能理解 OLE 是什麼。
因此在OLE 2。0之後,微軟提出了COM架構。所有 OLE 元件均繼承自 COM,這些技術包括 OLE 文件和 OLE 控制、拖放等。

COM組件類型

進程內元件:元件在主呼叫應用程式的進程範圍內運行,並以 DLL 方式實作。(該組件的實現速度很快,但由於與應用程式共享進程而導致不安全。)

進程外組件:可分為兩類。本地伺服器進程元件是與呼叫者在同一台機器上與呼叫者通訊的元件；遠端伺服器進程元件是使用遠端過程呼叫 RPC 和客戶端應用程式進行通訊的元件。

PPL,Protected Process Light,

主要目的與功能

• 防止惡意篡改：PPL 的主要目的是防止未授權的行程（即使具有最高權限的系統管理員 Administrator 帳號所啟動的普通程式）去讀取、注入、終止或修改被保護的重要系統行程與資安軟體。
  它能有效阻擋許多常見的憑證盜取攻擊（例如防止攻擊者利用工具直接傾倒 lsass.exe 記憶體中的使用者密碼或雜湊值）。

PPL 的運作原理

• 保護層級與簽章：PPL 引入了不同的「保護類型（Type）」與「簽章者（Signer）」等級。
  只有透過微軟官方特殊數位憑證或簽章授權的二進位檔案，才能以對應的 PPL 等級啟動。

• 核心強制拒絕：當一個未受保護的普通行程嘗試以高權限（例如寫入、終止）要求開啟或存取 PPL 行程時，作業系統核心會直接攔截並回傳 Access is Denied（拒絕存取）的錯誤。

Protected Process Light (PPL) Attack
PPL 層級對照表

1.Signer 層級（由高到低）

數值越高，保護等級越強。高階 Signer 可以存取低階，反之不行。

後來也有 PsProtectedSignerApp (8) 用於 Store App，但實務上較少遇到。

2.Protection Type

3.常見組合（EPROCESS.Protection 的實際數值）

4.存取規則重點

• 完整 PP (Type=2) 永遠優先於 PPL (Type=1)。
• 同為 PPL 時，Signer 數值 ≥ 目標 才能取得完整存取權（讀記憶體、注入、終止等）。
• 舉例：
• WinTcb-Light (0x61) → 可以存取 Antimalware-Light (0x31) 和 Lsa-Light (0x41)
• Antimalware-Light (0x31) → 無法存取 Lsa-Light (0x41)（這就是為什麼一般 AV 很難直接 Dump LSASS）
• 一般進程 → 幾乎無法對任何 PPL 進程做敏感操作

5.對於 SentinelOne

SentinelOne 的主要 Agent 進程通常以 Antimalware-Light (0x31) 運行。

• 一般管理員進程無法直接 Terminate / Inject / 讀取它的記憶體。
• 要繞過需要更高 Signer 等級的進程（例如 WinTcb），或透過 kernel（BYOVD、直接改 EPROCESS）把保護關掉。

運作方式

核心組成

主要保護行為（Anti-Tampering 開啟時）

• 阻止直接終止 Agent 行程：一般 Admin 工具或腳本無法直接 Kill 受 PPL 保護的行程。
• 阻止修改 / 刪除 Agent 檔案：安裝目錄下的關鍵檔案受到驅動保護。
• 阻止停止或修改服務：無法輕易透過服務管理員或 sc 指令停用 Agent 服務。
• 阻止未授權的設定變更：多數本機設定變更需要 Passphrase。
• 可疑驅動阻擋（Suspicious Driver Blocking）：這是 Anti-Tampering 的一部分。預設會阻擋可疑/未授權的驅動載入（包括部分已簽名但行為異常的驅動），用來對抗 BYOVD（Bring Your Own Vulnerable Driver）攻擊。關閉 Anti-Tampering 時，這個功能也會一併停用。

控制指令（需 Passphrase）

常見指令（需以 Administrator 執行，並提供 -k 或 –passphrase）：

1
2
3
4
5
6
7
8
9
10
11

# 暫時關閉防竄改
sentinelctl unprotect -k "密碼"
	
# 重新開啟防竄改
sentinelctl protect
	
# 卸載 Agent（需先 unprotect 或直接帶 Passphrase）
sentinelctl uninstall -k "密碼"
	
# 設定 Anti-Tampering 開關本身
sentinelctl config antiTampering true|false -k "密碼"

Passphrase 是從 Management Console 針對該 Endpoint 產生的，不是固定密碼。

額外強化機制

• Local Upgrade Authorization：防止攻擊者用合法的 S1 Installer 進行「升級/降級」來製造空窗期（先終止舊行程，再在新行程啟動前殺掉安裝程序）。開啟後，本機升級必須經過 Console 授權。
• Online Authorization：部分敏感操作需要 Console 端確認。
• 針對 BYOVD 與惡意驅動的防護：預設開啟，作為 Anti-Tampering 的一部分。

Apple機制

ESF,Endpoint Security Framework

端點安全（ES）框架是作為macOS安全架構的核心,它完全取代了傳統的不穩定核心擴充（KEXT）安全回調,而是透過系統擴充（System Extension）在使用者空間（User Space）中提供高效、安全、穩定的系統級監控和攔截機制。

架構：

1
2
3
4
5
6
7
8
9
10
11
12
13

macOS Kernel
     │
     │ 系統安全事件
     ▼
Endpoint Security Framework (ESF)
     │
     ▼
SentinelOne Agent
     │
     ├─ Process Execution
     ├─ File Events
     ├─ Malware Detection
     └─ Behavioral Detection

核心機制 ：

相關利用參考

SIP,System Integrity Protection, 系統完整性保護

系統完整性保護 (SIP) 是蘋果 macOS 作業系統的安全功能，於 OS X El Capitan 中引入。包含一系列由核心強制執行的機制。
SIP 的核心在於保護系統擁有的檔案和目錄，防止未經授權的程序對其進行修改，即使是 root 使用者或擁有 root 權限的使用者執行的程序也不例外。

Linux機制

eBPF LSM

LSM（Linux Security Module） 是 Linux 核心的安全框架，在關鍵安全操作點插入 hook，讓安全模組可以進行強制存取控制（Mandatory Access Control, MAC）。這些 hook 涵蓋：

• 檔案操作（open、read、write、unlink、rename、create 等）
• 行程操作（exec、setuid、ptrace 等）
• 網路操作（socket create/connect/send 等）
• Capability 檢查
• 其他敏感核心物件

傳統 LSM 實作包括 SELinux、AppArmor、Smack、Yama 等。

eBPF LSM（也稱 BPF LSM） 從 Linux 5.7 開始支援。它允許把 eBPF 程式 動態掛載到這些 LSM hook 上，而不是寫傳統的 kernel module。

主要特點：

• 程式以 eBPF bytecode 形式載入，經過核心 Verifier 檢查（確保安全、不會造成 kernel panic、有限迴圈等）。
• 可在 runtime 動態載入 / 卸載，不需重開機或修改核心。
• 回傳值決定允許或拒絕操作（一般情況下回傳 0 表示允許，錯誤碼表示拒絕）。
• 比傳統 LSM 更有彈性，適合安全產品實作細粒度、動態的政策。

常見應用包括 Cilium Tetragon、Falco 等，以及各家 EDR / CWPP 的 runtime 防護。

運作方式簡述

Agent 在啟動時載入對應的 eBPF 程式，掛載到相關的 LSM hook（例如 file_open、inode_unlink、inode_rename、inode_create 等）。
當系統發生檔案操作時，LSM hook 會觸發 eBPF 程式。
eBPF 程式檢查操作對象是否為 Agent 保護的路徑 / inode，以及發起操作的 process 是否被允許。
若判定為未授權竄改，則拒絕操作（並產生告警到 Management Console）。
可透過 Policy Override 或 sentinelctl 微調：

• 關閉特定事件
• 白名單特定可執行檔允許修改 Agent 檔案（需完整路徑）

注意事項：

Container Agent 不支援 anti-tampering。
需要系統支援 eBPF 且 BPF LSM 有啟用。
這是 kernel-level 的強制執行，比純 user-space 檢查更難被繞過（攻擊者需要能影響 eBPF 程式本身或找到其他路徑）。