WSCのリバースエンジニアリングで休暇を台無しにした話

• Windows Security Center(WSC) サービス APIを直接活用して Windows Defender を無効化するツール defendnot の開発過程に関する体験共有
• プロジェクトは 以前の no-defender プロジェクトの技術的限界と法的問題を乗り越える過程で始まった
• 特殊な環境(MacBook arm64、リモートデバッグ、高遅延) など、さまざまな障害の中でリバースエンジニアリングとデバッグを進めた
• Defender 登録の回避とプロセス検証メカニズムを分析し、数々の失敗と試行の末に安定して動作するよう改善した
• 最終的に 自動実行機能まで実装し終えると同時に、プロジェクトの過程を振り返りながら大変だった点を打ち明けている

---

紹介

• Windows Defender を無効化する defendnot ツールの実装の道のりに関する体験共有
• 主要な技術的詳細の説明よりも、実際の環境で直面した問題や試行錯誤の経験を中心にまとめられている
• 正式なドキュメント化や技術的説明は、後日別途公開される予定

1年前の振り返り

• 約1年前に no-defender というプロジェクトを公開し、WSC API を通じて Windows Defender が無効化される仕組みを活用した
• このプロジェクトはアンチウイルスベンダーの サードパーティ製コードを参照することで、システムに別のアンチウイルスが登録されているように見せかけていた
• 公開後は大きな注目を集めて約1,500個の Star を獲得したが、関連アンチウイルス企業の DMCA 削除要請により、ソース削除とプロジェクト終了を決めた

プロジェクト開始のきっかけ

• 本稿執筆時点ではソウルの Airbnb に滞在中
• 主な開発環境は M4Pro MacBook で、必須となる x86 リバースエンジニアリング用の機器は別途持参していなかった
• CTF 大会と旅行日程のため、x86 デバイスなしで作業を進めなければならない状況が発生
• no-defender プロジェクトの「正常な」実装可能性を検討するとともに、AV 非依存の単独実装が可能かどうかの探求を始めた

初期調査（1日目）

• 友人の助けで wsc バイナリを提供してもらい、以前のプロジェクトと似た構成で WSC 登録の再実装を試みた
• WSC の COM APIを活用して実装したが、Access Denied エラーが発生
• エラー原因を、WSC が API 呼び出しプロセスの署名検証と認証を行っている点に見いだした
• AV プロセスにモジュールをインジェクションして登録を試みたところ、AV が正常に登録された

AV バイナリの代替と追加実験（1日目）

• 署名済みシステムプロセス（cmd.exe など）経由でツールの実行を試したが、PPL(Protected Process Light) 検証で失敗した
• 分析のため詳細な逆アセンブルと追跡を後日に回し、いったん中断した

環境構築（2日目）

• arm64 MacBook 環境の制約により、x86 Windows のデバッグが非常に困難な状況だった
• 米国に住む友人の PC をリモート（Parasec、Anydesk など）で利用し、高遅延環境下でデバッグと実験を進めた
• コードビルドと VM デバッグが複雑に行き交う過程で、速度低下と混乱を経験した

WSC サービスのデバッグ（2日目）

• WSC サービスが svchost によって実行される DLL構造であることを確認
• PPL 保護解除のため、特殊なドライバで回避を適用し、デバッガで関数への突入を確認した
• サービス内部で WinDefend SID トークンの確認が実行されていることを把握
• WinDefend SID を持つプロセスを模倣することで、認証手順を回避できるという理論を立てた

WinDefend SID の模倣（2日目）

• Windows のトークン構造と動作原理について追加学習を行った
• WinDefend SID を模倣するコードを実装して実行した結果、すべての COM 呼び出しで SUCCESS が返るにもかかわらず、実際には AV 登録が行われていない状況を確認した

検証アルゴリズムの再構成（3日目）

• AV バイナリで SID チェックが本当に通過しているのか慎重に再分析した
• SID チェック不通過時には、サービスが昇格済み権限状態、バイナリ署名、PE の DllCharacteristics フラグ（ForceIntegrity）なども追加で確認していることが分かった
• その構造を実行する関数を再現し、システム内の core バイナリに適用して実験を進めた

Taskmgr プロセスの活用（3日目）

• Taskmgr.exe を対象プロセスにして再実験したが、名前の受け渡し過程のエラーと IPC バグにより、WSC が要求を拒否する問題に直面した
• ファイルパス推論と AV 名の受け渡し方式を改善した後、正常動作を確認した

コード整理（3日目）

• 機能を整理し、自動実行(autorun) 機能の実装を試みた
• 自動実行の管理で断続的な失敗が発生し、原因究明のためにコードと環境の確認を繰り返した

自動実行の実装（4日目）

• タスク スケジューラ（Task Scheduler）のオプションのうち、ノート PC が AC 電源に接続されていない場合にタスクを実行しないチェックボックスが原因であることを確認した
• 該当設定を解除した後、自動実行は正常に動作した
• 最後にコードのクリーンアップとテストを行った

結論

• 制約が多く不便な環境でのリバースエンジニアリング作業は、心理的にも物理的にも非常に大変な経験だった
• 今後、より詳細な WSC 実装ドキュメントが別途公開される予定

謝辞

• Pindos: 夜間に PC を提供してデバッグを手伝い、部屋を暖めてくれた友人
• MrBruh: プロジェクト探求のきっかけを与え、アイデアへのフィードバックをくれた仲間
• プロジェクト期間中、連絡を取り合いながら支えてくれた知人たち
• キムチが大好きだと告白する
• 私たちの壁にグラフィティを残したアーティストにも感謝する

[GN⁺]

Hacker Newsの意見

• Defenderを無効化する最も強力だが侵襲的な方法は、Live Linux USBで起動して "C:\ProgramData\Microsoft\Windows Defender" フォルダ名を変更し、その場所に空ファイルを作ること
  • グループポリシーがあまりにもうまく機能するので、homelabにコントローラを置き、全ユーザーについてDefenderポリシーを自動で変更するローカルドメイン環境を構成した
  • Windowsにそのような改変を検出する署名付きマニフェストがないのは奇妙だ
  • 人気製品も事実上そうしており、インターネット全体の約25%をダウンさせたことさえある
• プロジェクトが大きな話題になって約1.5kスターも獲得したが、その後、私が使っていたアンチウイルスの開発者がDMCA申請を送ってきた。"私が使っていたアンチウイルス"が何なのか、この人物がなぜDMCAを送ってきたのか理解できない。おそらく作者が別のアンチウイルスをリバースエンジニアリングしてオープンソースに入れたか、少なくともWinDefendを模倣したことに関係しているようだ。著作権上の問題があったらしい
  • 私の理解では、別のアンチウイルスツールの殻を使ってシグネチャ要件を回避したように見える。変形的で合理的かもしれないが（法律の専門家ではない）、グレーゾーンだ
  • はい、既存のアンチウイルスプログラムの一部をコピーして著作権法に違反したということ。引用した直前の段落でも、プロジェクトが既存アンチウイルスのサードパーティコードを使ってAVをWSCに登録させたと説明している
• 参考までに、WSCはWindows Security Centerの略
  • 助かる。最初に略語が出たときに説明がないと本当にいら立つ
• これは本当に奇妙だ: https://github.com/es3n1n/defendnot/… 気になるなら、実際に何が起きているかはここを参照: https://github.com/es3n1n/defendnot/…
  • C++の魔法をうまく説明できる人が、なぜこのコードが奇妙なのか説明してくれないだろうか
  • 何が変なのかわからない。私はこのパターンをコードのあちこちで普通に使う。呼び出し側ではシグネチャは違うが（個人的な好み）。ちなみにD言語には、scope終了時にトリガーされる構文が組み込みである
  • 時間がなく、すべてのCOM要素に対して手作業でRAIIパターンを実装するのは面倒だった。次のアップデートで変える予定だ
  • 「コードは同僚への接し方と同じだ」 - Michael Feather 要するに、AIではない このコードは、あるオブジェクトのスコープが終了したときに関数呼び出しを遅延させる役割を持つ。Cマクロを使って複雑なCラムダ/無名関数定義と一意な変数名生成を簡略化している。ただし、マクロを大文字で表記せず関数呼び出しのように見えるため、不慣れな人には紛らわしい。人によってはこのパターンは十分に有用で、イディオム的だと認識されている。技術的な説明は別コメントのリンクで見られる
• 私は去年、Windowsの仮想デスクトップをリバースエンジニアリングしながら休暇を大いに楽しんだのが素敵な思い出だ。リバースエンジニアリングは本当に面白い。面白い点をたくさん学んだが、たとえばWindows RPC内部に文書化されていないメッセージ通信方式があることなどだ: https://csandker.io/2022/05/24/Offensive-Windows-IPC-3-ALPC.html
• 最近 https://nostarch.com/windows-security-internals を読んだが、この投稿にいっそう共感できた。Windowsでバックエンドがどう動くかはある程度知っていたが、その本の最後の章ではトークンとSIDについて、著者が扱ったのと同じくらい詳しく説明している
• なぜWSCを無効化したいのか気になる
  • 性能や、マルウェア開発、ハッキングなどの理由がありそうだ
  • 脅威アクターなら、他のEDR（Endpoint Detection and Response）製品が入っていなくて運が良いかもしれない。しかし入っていれば、ほぼ確実にブロックされるだろう。EDRベンダーなら、これはWindowsファイアウォールを無効化するための難読化されたAPI呼び出しとして使える。CrowdStrikeのような製品も独自のファイアウォールを使うか、Windowsファイアウォールを置き換えられる
  • すべてのアンチウイルスソフトウェアは少なくともpowervirusだ。netcat.exe を使ってはいけない、みたいに誰かに監視されるのは嫌だ
  • 自分のハードウェアなのだから、自分の望むように使う。ただそれだけの理由だ
  • わざわざ自分のシステムにrootkitを仕込みたがる理由がわからない
• 私にとってさらにひどいのは、Check Point HarmonyがDefender向けに作られたインターフェースをまったく活用せず、ナレッジベース文書でDefenderを直接無効化するようユーザーに案内していることだ
• 念のため言うと、WSCはWindows Security Centerの略。私も調べる必要があった
  • 「これらすべてを管理しているのはWindows Security Center-WSCだ」という表現が記事に含まれている
• 「私はarm64 macbookで作業しているので、現状arm macbookでx86 Windowsをエミュレーションできるまともな方法がない」という投稿に対し、UTMはどうかと尋ね、Parallelsが最近Intel VMのサポートを始めたとも言及している
  • UTMを使ってみたが、x86 Windowsでは使いものにならなかった。コマンドラインLinuxなら遅いながら許容範囲かもしれないが、GUI環境では無理だ。arm64 Windowsはよく動くが、これはx86 Windowsではないので、x86システムコンポーネントのリバースエンジニアリングには役立たない
  • QEMUのdynamic recompilationシステムは、WindowsやmacOS（Rosetta 2）のネイティブシステムほど効率的ではない。UTMでx86 Windowsは動くには動くが、性能は非常に悪い。実際には、ARM Windows VM上でWindowsのdynamic recompilationにx86アプリを実行させるか、ネイティブコードベースのサブシステムを使うWINEのほうが良いと感じる。簡単な急ぎ作業には問題ないかもしれない。OPの言う「まとも」に性能が含まれているなら、その立場は理解できる
  • 私が間違っていたら訂正してほしいが、MMU付きCPUのエミュレーションは本質的に遅く、最適化も難しいという理解で合っていると思う。AppleのRosettaやMicrosoftの同種技術が高速なのは、ユーザー空間コードだけを実行しているからだ。システム全体のMMUエミュレーションは避けている