【合格体験記】カーネルモードから見る防御 ― CETP合格までの軌跡

公開日：2026.02.04　更新日：2026.02.03

はじめに

アセスメントサービス部のわさびです。
普段は、Webアプリケーション、サーバサイドAPI、モバイルゲームのチート診断などを担当しています。

個人的にWindows Internalsに興味があり、余暇で関連する技術を学習しています。

今回は、攻撃者がどのようにEDRを回避しようとするのかを理解し、防御側の視点から対策を考えるため、Altered Security社が提供する「CETP（Certified Evasion Techniques Professional）」を受講し、試験に合格しました。
本記事では、その内容や所感を紹介していきます。

CETP（Evasion Lab）について

CETPは、Altered Security社が提供する、EDRなどのセキュリティソリューションの回避に特化した上級トレーニングです。
特に、BYOVD（Bring Your Own Vulnerable Driver）を中心とした、カーネルモードでの防御回避技術に焦点を当てています。

攻撃者の視点を理解することで、より効果的な防御策の検討に役立てることができます。

ラボ環境には、Elastic EDRとMicrosoft Defender for Endpoint（MDE）が検知モードで導入されています。
コンソールから攻撃がどのように検知されるかをリアルタイムで確認でき、EDRの検知ロジックや挙動特性を把握しながら学べる環境です。

CRTLとの比較

防御回避系のトレーニングとして、Zero-Point Security社のCRTLがありますが、CRTLがCobalt Strikeを中心に、ユーザモードでの検知回避（初期アクセス・横展開用シェルコードローダの高度化や、Malleable C2プロファイルのカスタマイズなど）を扱うのに対し、CETPは、より低レイヤーなカーネルモードでの回避技術に踏み込んだ内容になっています。

CRTLでも、RedOctoberのようなツールを使って、カーネルドライバ経由でPPLを無効化する演習はありますが、CETPでは、ドライバを一からリバースエンジニアリングし、エクスプロイトを開発するところまで学びます。

OPSECとは

OPSEC（Operations Security：作戦保全）は、アメリカ軍発祥の軍事用語で、「自分たちの作戦や行動を敵に悟られないようにする」という考え方です。

サイバー攻撃の文脈では、侵入後の活動がEDRやセキュリティチームに検知されないよう立ち回ることを指します。
CETPは、このOPSECを実現するための技術を学ぶトレーニングです。

防御側がこれらの手法を理解することで、より効果的な検知・対策を検討できるようになります。

学習前のスキルレベル

学習開始前には以下のトレーニングを受講して合格済みでした。

・CRTL（Certified Red Team Lead） – Zero-Point Security社
・OSEP（PEN-300） – OffSec社

CRTLではEDRの回避技術を学んでいたため、CETPの学習において良い下地になりました。

ラボ学習

2025年1月、CETPが発売された直後にトレーニングを購入しました。
リリース直後だったため、ラボが利用可能になったのは3〜4月頃だったと思います（うろ覚えですが……）。

ただし、4月から8月まではOSCP+とOSEPの学習に集中していたため、実際にCETPのラボに取り組み始めたのは、8月のOSEP合格後です。
ラボは3ヶ月契約でした。

VPN経由で学生用マシンにリモートデスクトップ接続して、開発や演習などを行いました。
ラボマニュアルは丁寧に解説されており、マニュアルに沿って進めながら、知識と技術を段階的に身につけていきました。

学習内容は以下のとおりです。

• 脆弱なカーネルドライバの解析とエクスプロイト開発
• IDAを使ったドライバのリバースエンジニアリング
• BYOVD（Bring Your Own Vulnerable Driver）による防御回避
• EDRプロセスのEPROCESS構造体を書き換えることによる、EDR監視機能の低下・無効化

など

ユーザモードアプリケーションとカーネルドライバの通信

以降の話に進む前に、まずWindows OSにおけるいくつかの重要な仕組みを理解する必要があります。

ユーザモードとカーネルモード

• ユーザモード：普段利用するアプリケーション（ブラウザやメモ帳など）が動作するモード。システムの重要な領域やハードウェアへの直接的なアクセスは制限されている
• カーネルモード：OSの中枢部分が動作する特権的なモード。メモリ管理やハードウェア制御など、システム全体に影響する処理を行う権限を持つ

通常、ユーザモードのアプリケーションがカーネルモードの機能を利用するには、Windowsが提供する正規のルートであるAPIを通じてOSに処理を要求し、内部的にはシステムコールによってカーネルモードへ遷移します。

アプリがDeviceIoControlなどのWindows APIを呼び出す
シンボリックリンク（\\.\DeviceNameのような名前）を通じてドライバを指定
WindowsカーネルがIRP（I/O Request Packet）という要求パケットを作成
ドライバがIRPを受け取り、要求された処理を実行

なぜ脆弱なドライバが問題なのか

通常のドライバは、「このアプリにはこの操作だけ許可する」といった形で、アクセス可能な機能や範囲に制限を設けています。
しかし、脆弱なドライバでは、入力値のチェックが甘かったり、誰でも任意のメモリアドレスを読み書きできてしまう場合があります。

この「任意のメモリを読み書きできる機能」を、読み書きプリミティブと呼びます。
「プリミティブ」とは「基本的な操作・機能」という意味で、この基本機能さえあれば、そこからさまざまな攻撃に発展させることが可能です。

防御側としては、このような脆弱なドライバの存在を把握し、ブロックリストの管理や、脆弱なドライバのロード検知といった対策を講じることが重要になります。

学んだテクニック

BYOVD（Bring Your Own Vulnerable Driver）

CETPの中心となるテクニックです。日本語にすると「脆弱なドライバを持ち込む」という意味になります。
正規の署名が付いた脆弱なドライバを標的システムにロードし、そのドライバの脆弱性を悪用してカーネルメモリを読み書きします。

本トレーニングでは、RTCore64.sysというドライバを使用します。
これは、MSI（Micro-Star International）社が提供するオーバークロックツール「MSI Afterburner」に含まれるドライバで、本来はハードウェアの監視や設定変更のために使われるものです。

しかし、このドライバにはCVE-2019-16098という脆弱性が存在し、任意のカーネルメモリアドレスへの読み書きが可能になっています。
正規の署名が付いているため、Windowsに正常にロードできてしまう点が厄介です。

APT41などの国家関与型脅威アクターが、実際のサイバー作戦でこのドライバを展開した事例も報告されています［1］。

参考文献
[1] Trend Micro, “Hack the Real Box: APT41’s New Subgroup Earth Longzhi”
https://www.trendmicro.com/ja_jp/research/23/a/hack-the-real-box-apt41-new-subgroup-earth-longzhi.html

PPL保護の無効化

Windowsでは、LSASS（認証情報を管理するプロセス）などの重要なプロセスは、PPL（Protected Process Light）によって保護されています。
そのため、通常はローカル管理者権限やSYSTEM権限を持っていても、プロセスのメモリダンプなどの操作は制限されます。

しかし、任意のカーネルメモリ書き込みが可能な状況では、この保護を無効化できる場合があります。

カーネル内にはEPROCESS構造体と呼ばれるプロセス管理情報が存在し、その中のProtectionフィールドがPPLの保護状態を表しています。
書き込みプリミティブを用いてこのフィールドを書き換えることで、PPLの保護状態を変更することが可能です。

なお、Protectionフィールドの具体的な値はOSのバージョンや環境によって変化する可能性があります。
以下はLSASSプロセスにおいて一般的に観測される一例です。

・攻撃前：Protection = 0x41（PPL有効）
→ メモリダンプによる情報窃取は不可
・攻撃後：Protection = 0x00（PPL無効）
→ メモリダンプによる認証情報の窃取が可能

このように、1バイトの書き換えによってLSASSの保護状態が変更され、認証情報の取得が可能になる場合があります。
同様の手法を応用することで、EDRプロセスの保護解除や、カーネル内コールバックの無効化が行われる場合もあります。

ドライバのリバースエンジニアリング

IDA Freeを使って脆弱なドライバを解析し、どこに脆弱性があるかを見つけてエクスプロイトコードを書く演習も行いました。

EDRプロセスのEPROCESS操作

Windowsでは、各プロセスに「トークン」と呼ばれる、アクセス権限や実行主体を表す情報が付与されています。
カーネルメモリの書き込みプリミティブを利用することで、EDRプロセスが保持するトークンの内容を書き換え、権限や整合性レベルを低下させることが可能な場合があります。

権限が低下したEDRプロセスは、本来監視対象となる情報やリソースへアクセスできなくなり、結果として一部の検知・防御機能が正常に動作しなくなる場合があります。

カーネルモードルートキットの開発

トレーニングでは、カーネルモードで動作するルートキットを題材として、その実装方法や挙動についても学習しました。

具体的には、セキュリティソリューションのプロセス管理に関与するルートキットや、プロセストークンの操作を行うルートキットを実装し、カーネルレベルでどのような制御が可能になるのかを確認しました。

※これらは、カーネル内部の仕組みや防御機構への理解を深めることを目的とした学習・検証用のものであり、実運用環境での悪用を意図したものではありません。

注意点：VBS / HVCIとは

VBS（Virtualization Based Security）は、CPUとWindows（Hyper-V）のハイパーバイザー機能を使って、OSの重要な部分を隔離する仕組みです。通常のOSとは別の「安全な領域」を作り、そこにセキュリティ上重要な機能を配置することで、たとえカーネルが侵害されても守れるようにしています。

HVCI（Hypervisor-protected Code Integrity）は、VBSの上で動くセキュリティ機能で、カーネルモード以上で実行されるコードの整合性をハイパーバイザーが監視します。これにより、署名のない不正なドライバのロードや、メモリ上のコード改ざんを防ぎます。

VBSやHVCIが有効な環境では、BYOVDによって脆弱なドライバをロードできた場合でも、そこから先の悪用は困難になる場合があります。
また、これら以外にも複数のカーネルエクスプロイト緩和策が存在するため、攻撃の条件や環境によっては、こうした防御機構を段階的に回避する必要が生じると考えられます。

試験

NDAの都合上、詳細は控えますが、ここでは試験の概要をお伝えします。

試験では、48時間以内にActive Directoryドメイン内の5台のマシンを、防御回避を行いながら攻略し、最終フラグを取得することが目標です。
試験終了後は、24時間以内に報告書を作成して提出します。

試験内容は、基本的にトレーニング内で扱われている内容がベースになっています。
ただし、トレーニングで提供されるツールをそのまま使えばよいというわけではなく、状況に応じてカスタマイズしたり、ビルドし直したりする必要がありました。

1回目の挑戦

最後のマシンだけ攻略できず不合格。完全に準備不足でした。

2回目の挑戦

1回目の反省を活かし、ツールを改良して臨みました。結果、2回目で無事合格できました。

ユーザモードでのOPSEC向上

試験などで使用するツールは、極力検知されないよう、ユーザモードで実施可能な最大限のOPSEC対策を施しています。

VBSやHVCIといったカーネルエクスプロイト緩和策が有効な環境では、ドライバを利用した攻撃が困難になる場合があります。
そのため、カーネルモードを制御下に置けない場合でも、検知されるリスクを下げることを目的として、以下の対策を実装しました。

• 間接システムコール：ntdll.dll内のフックされたNt/Zw系APIを直接呼び出さず、syscall命令を自前で発行することで、EDRのユーザーモードAPIフックを回避する手法
• 戻りアドレス・スタックスプーフィング：API呼び出し時の呼び出し履歴を偽装し、正規のWindowsシステムDLL（ntdll.dllなど）から呼び出されたように見せかける手法。
主にベクトル化例外ハンドラ（VEH）とハードウェアブレークポイント（HWBP）を用い、実行時にスレッドコンテキストを制御することで実装。
• ユーザモードETWバイパス：Windowsのイベントトレーシング機構（ETW）へのイベント送信を抑制し、EDRによるユーザーモードテレメトリ収集を回避する手法。
APIのパッチやフックを行わず、主にVEHとHWBPを利用した実行時制御によって実装。

他にも、カスタムハッシュアルゴリズムを使ったNative API名のハッシュ化、XOR文字列暗号化、PEBウォーキング、スリープ難読化、UNWIND_INFO解析によるフレームサイズ計算、TEB境界内でのスタック領域ローテーションなどを実装しました。

それに加えて、ビルド成果物自体が解析や検知の起点にならないよう、ビルド設定や依存関係の見直しも行い、デバッグ情報を出力しない構成や不要なDLLをインポートしない設計を徹底しました。
また、コードは平文の状態でも処理の意図が直感的に把握しづらい構成とし、最終的なビルド段階ではoLLVMを用いて制御フローを著しく大きく変形させることで、静的・動的解析の双方に対する耐解析性向上も意識しました。