はじめに
PenTestSecJP2 に参加して
EDR を「どう回避するか」ではなく
EDR が何を見ていて なぜ検知されるのかを
実装レベルで理解する内容が多く 非常に学びが大きかった
本記事は 当日の資料とメモをもとに
理解の整理と要点の共有を目的としてまとめている
本勉強会の前提
- 対象は Windows 端末上の EDR
- 情報収集や横展開の話はほぼ扱わない
- C2 フレームワークとして Havoc をベースに解説
- CrowdStrike Falcon
Microsoft Defender for Endpoint
Cortex XDR
それぞれでの検知ポイントを比較
「どうすれば検知されないか」より
なぜ検知されるのかを理解する構成だった点が印象的だった
Havoc と BOF の位置づけ
Havoc とは
- OSS の C2 フレームワーク
- Beacon Object File（BOF）を実行できる
- 実運用レベルで EDR 検知を意識した設計がされている
特に BOF を前提とした話が多く
EDR 視点でのメリットと制約が整理されていた
BOF の特徴
BOF は マルウェアのメインスレッド上で実行される
- 新規プロセスやスレッドを生成しない
- Windows API の呼び出しも最小限
- 振る舞い検知を回避しやすい
一方で 明確な制約もある
- 実行中はメインスレッドを占有する
- 長時間処理には向かない
- BOF がクラッシュすると プロセスごと落ちる
万能ではないが ピンポイントで使うと強い
という立ち位置が整理されていた
COFF と Shellcode の違い
よくある誤解として
- Windows Shellcode ≠ Position Independent Code
Havoc が生成するものは
一般的な意味での Shellcode とは少し異なる
- COFF は 半完成品のコード
- ローダーを介して初めて実行可能
- Shellcode Runner で exe 化するケースもある
この辺りを曖昧に理解していると
EDR の検知理由が説明できなくなる点が刺さった
YARA によるシグネチャ検知
EDR の基本は今も YARA
- バイナリパターンの一致
- 命令列や定数の特徴
印象的だったのは
検知が非常に脆いという点
- push するレジスタを変える
- 不要な変数を確保してスタックサイズを変える
それだけで シグネチャが外れるケースがある
つまり
YARA は強力だが 完全ではない
EDR 側も
シグネチャ単体に依存していない理由がよく分かる
CrowdStrike Falcon の特徴
国内導入率が高い EDR
- Machine Learning を強く活用
- インジェクション系 API は特に重点監視
- API フックにより シェルコードも観測されやすい
印象的だったポイント
- 単純な Shellcode 実行は意外と通ることがある
- 逆に 単純すぎるバイナリは怪しまれる
例として挙げられていたのが
- JSON CSV YAML を変換するだけの CLI
- 引数なし実行時だけ Shellcode Runner が動く
「普通のツールに見せる」という発想が重要だと感じた
Microsoft Defender for Endpoint（MDE）
非常に優秀な EDR
- CrowdStrike で回避できた手法が通らないケースあり
- Havoc のコードであること自体を検知することもある
対策として紹介されていたのが
- Shellcode を暗号化して埋め込む
- 実行直前まで復号しない
また Chrome や Edge のプロセス操作についても
- Cookie 等にアクセスできる
- ただし アクセス行為自体は検知される
できること と 見られていることは別
という視点が重要
Sleep Mask
Cobalt Strike や Havoc にある仕組み
- Sleep 中はメモリ上でも暗号化
- シグネチャスキャン対策
「常に平文で置かない」
という考え方が EDR 回避の基本になっている
Cortex XDR の検知視点
日本ではややレアだが
YARA が非常に強力
特に
- DLL ロード時の挙動
- プロセスメモリ内の Shellcode
ここで出てきたのが
Proxy Loading
- 別スレッドから LoadLibraryW を呼ぶ
- Call Stack を綺麗に保つ
- DLL 読み込み時点では Shellcode を含めない
Call Stack Spoofing
- return address を偽装
- 正常な関数呼び出しに見せかける
どちらも
「何をしたか」ではなく「どう見えるか」
を強く意識した手法だと感じた
検知される理由の整理
技術以前に 多かった理由
- オペレーションミス
- 不適切なアクセス方法
- 不自然な振る舞い
- 検知ロジックの更新
- カスタムルール
特に
一度検知されると 以降は検知が強化される
という話は
運用視点で非常に重要だと感じた
まとめ 所感
今回の勉強会で一番の学びは
EDR 回避は テクニックではなく設計思想
という点
- なぜその API を使うのか
- なぜその実行形態なのか
- どう見えるか
これを説明できない実装は
遅かれ早かれ検知される
ペネトレーションテストだけでなく
- EDR 運用
- 検知ルール設計
- ブルーチーム視点の理解
にも直結する内容だった
非常に濃い勉強会でした
ありがとうございました