Black Hat USA 2025 の登壇経緯・感想・発表紹介 (中川)

はじめに

こんにちは、基礎技術研究部の中川です。
8 月にラスベガスのマンダレイベイで開催された Black Hat USA 2025 に登壇しました。
この記事では Black Hat の概要を簡単に紹介した後、自身の発表内容や登壇に至る経緯、現地で聴講した発表についてまとめます。最後に今後の目標についても触れます。

Black Hat について

Black Hat は世界最大級の産業系セキュリティ国際会議で、毎年 Asia、USA、Europe と 3 回開催されています。最近では Black Hat Middle East & Africa や SecTor も関連イベントとして行われていますが、メインはやはり Asia、USA、Europe です。私はこれまでに Black Hat Europe 2020、Asia 2023 に参加しましたが、USA への参加は今回が初めてでした。

Black Hat は主に以下の 4 つの要素で構成されています。

Training: セキュリティ関連のさまざまなテーマに関するトレーニングが行われます。Briefings や Arsenal の前に実施されます。
Briefings: 最新の研究成果が共有される研究発表の場です。
Arsenal: 開発したツールを展示・デモする場です。
Business Hall: セキュリティ関連企業が製品やサービスを展示する場です。

私はこのうち Briefings で研究成果を発表しました。なお、Briefings スピーカーには以下のような特典があります。

無料の Briefings pass
マンダレイベイのホテル 3 泊分
謝礼金 $1000 / speaker
航空券代 $1500 まで補助
VIP パーティーへの招待
スピーカー専用のノベルティの支給
学生 2 名までを Black Hat に招待

Briefings の特典については公式の情報もぜひご参照ください。

Black Hat USA の採択率は低く (例年 10% 未満が通常とのこと)、登壇は狭き門です。とはいえ、VIP 待遇で Black Hat に参加したい方には Briefings のスピーカーになることをおすすめします。例年 2 月頃に CFP が公開され、3 月末が締め切りです。来年の Black Hat USA で研究成果を発表したい方は、早めに準備することをおすすめします。ちなみに私は、CFP 応募時には "submit early" を徹底しており、今回も 2 月の時点で応募を済ませていました。

自分の発表

今回の発表は macOS のセキュリティ機構 XProtect Remediator (XPR) のリバースエンジニアリング に関する研究です。

近年、macOS を取り巻く脅威状況は大きく変化しています。かつてはアドウェア中心で深刻な脅威ではないと考えられていましたが、今では Info Stealer 系マルウェア が主要な脅威となっています。2024 年の Virus Bulletin における Patrick Wardle 氏の講演でも同様の指摘がありました。以下は講演スライドの内容の抜粋になります。図から明らかなように Adload や Pirrit などのアドウェアも健在ですが、今は AMOS をはじめとした Info Stealer 系のマルウェアも多く見られることがわかります。

Apple はこうした脅威に対応するため、複数のマルウェア対策を導入しています。Apple Platform Security によると 3 つのレイヤーによって構成されています。

3つの防御層

マルウェアからの防御は以下の3つの層で構成されています:

1.マルウェアの起動と実行の防止: App Store、または公証と組み合わせたGatekeeper

2.お客様のシステムでのマルウェア実行をブロック: Gatekeeper、公証、およびXProtect

3.実行されたマルウェアへの対処: XProtect

初めの防御層は、マルウェアの配付を阻止し、1回たりとも起動させないように設計されています。これはApp Storeや、公証と組み合わせたGatekeeperの目指すことです。次の防御層は、Mac上に出現したマルウェアを素早く検出およびブロックすることで、マルウェアの拡散を防ぐだけでなく、すでにマルウェアが足場を築いてしまったMacシステムを修復できるようにします。この防御は、XProtect、さらにGatekeeperと公証によって強化されます。最後にXProtectが動作し、実行に成功したマルウェアに対処します

1 番目の防御層は App Store のレビューや公証を通じ、攻撃者がそもそもマルウェアを配布することを防ぐためのものです。例えば攻撃者が App Store にマルウェアをアップロードしたとしても、Apple のレビュープロセスによって弾かれます。 2 番目の防御層はユーザーの端末でマルウェアの実行を阻止するためのものです。これは Gatekeeper によって主に実現されており、Gatekeeper によって信頼されたアプリケーションのみ実行が許可されます。

App Store のレビューや Gatekeeper による防御は非常に強力ですが、それを突破するマルウェアは存在します。例として 2023 年の 3CX supply chain 攻撃があります。この場合は 3CX のビルドサーバーが改ざんされ、3CX アプリケーションの依存ライブラリにマルウェアが仕込まれました。バックドアが仕込まれていたにも関わらず、3CX アプリは公証をパスしたため、Gatekeeper による防御を突破しユーザーの端末で実行されています。

その他 Info Stealer 系のマルウェアはソーシャルエンジニアリングにより、Gatekeeper の検証をユーザーに明示的に無効化させることで攻撃に成功するケースがあります。macOS ユーザーの方であれば、ソフトウェアインストールの際に DMG ファイルをクリックし、アプリケーションをドラッグ&ドロップしてインストールした経験があるでしょう。DMG ファイルにはインストール手順を画像で示すのが通例ですが、この画像として Gatekeeper を無効化してアプリケーションを実行する手順を示すのです。

Gatekeeper bypass をソーシャルエンジニアリング経由で無効化してアプリケーション実行を誘導する例

https://www.kandji.io/blog/amos-macos-stealer-analysis

こうした 1 と 2 番目の層を突破して実行されたマルウェアを削除するのが XPR です。XPR は 20 以上のスキャナーから成り立ち、それぞれ特定のマルウェアファミリーを削除するように設計されています。例えば XProtectRemediatorAdload というスキャナーがあるのですが、これは著名な Adload アドウェアを除去するためのものです。

Adload のようになんのマルウェアファミリーを削除の対象としているのかが明らかなスキャナーもあります。しかし、ほとんどは Apple 独自の命名規則に従って命名されており、なんのマルウェアを対象としているスキャナーなのか不明でした。複数の研究者がなんのマルウェアファミリーを対象としているのかを調査していますが、依然として不明なものも存在していました。

XPR をリバースエンジニアリングするにしても、一筋縄ではいきません。これらのスキャナーは Swift で書かれています。Objective-C とは違い Swift のリバースエンジニアリング手法は私が研究を開始した時点では研究が発展途上で、逆アセンブラのプラグインも多くありませんでした。

そこで Swift のリバースエンジニアリング手法を研究し、その手法を使って XPR のスキャナーをリバースエンジニアリングした、というのが今回の発表内容です。詳細な解析を通じ、XPR のスキャナーがどのようなマルウェアファミリーを対象としているのかを明らかにしました。それだけでなく、OCR を利用した興味深い検知ロジック、2023 年の 3CX supply chain 攻撃に関する新しい知見、その他にも興味深い発見がありました。

研究のきっかけ

今回の研究のきっかけは macOS Ventura から追加された XProtect Behavior Service の調査から始まりました。macOS Ventura で実行されているプロセスを何気なく眺めていて XProtect Behavior Service というあまり見慣れないプロセスを見たところから解析が始まりました。調べると Apple Sandbox Profile Language (SBPL) をベースに記述された振る舞い検知のルールを発見しました。この解析結果を X 上で投稿したところ、大きな反響があり、XProtect 関連では知られていないことが多く、他にも研究したら面白そうだと感じました。

その頃、あるブログポストを読んでいて macOS Monterey から XProtect Remediator というのも追加されていることを知りました。Malware Removal Tool (MRT) という、実行に成功したマルウェアを除去する仕組みがあることはなんとなく知っていましたが、それが XPR に置き換えられたのをこれで知りました。

それで XPR に興味が移り、何気なく Ghidra で開いて解析してみたところ、全く歯が立ちませんでした。正直、デコンパイル結果を見ても何をやっているのかさっぱりわかりませんでした。バイナリのセクション名から Swift で書かれているのはすぐにわかり、Swift バイナリを解析する手法について調べるとあまり情報が出ませんでした。これはきちんとやったら面白そうと考え Swift バイナリの解析手法の先行研究を調べつつ、独自のツールを作り Swift バイナリを解析することにしました。

そのあとは地道な解析を 20 ぐらいのスキャナーについて行いました。今回は調査の過程で非常に多くの解析ツールを作成しましたが、どのツールも今回の研究成果を出す上で欠かすことのできないものです。また、調査の過程でいくつか脆弱性も発見し (CVE-2023-41979, CVE-2024-23201, CVE-2024-40843)、併せて報告しました。

発表の反響

発表後は Apple のエンジニア数名が私のところにきてくれ、良いフィードバックをもらいました。また、macOS セキュリティを同様に研究している複数の研究者からも有益なフィードバックをもらいました。SNS を通じても多くの賞賛の声をもらい、私が macOS セキュリティを始めるきっかけとなった方からもお声かけいただき (top-notch research と称賛)、大きな手応えを感じました。

また発表前には macOS の内部を長年研究していることで著名な Howard Oakley 氏と Jonathan Levin 氏から発表のスライドをレビューいただけるという、機会もありました。ご多忙であるにも関わらず、非常に丁寧なフィードバックをいただけたことに本当に感謝しています。今回の機会を通じ、お二人と気軽にやり取りできるようになったのは非常に嬉しい限りです。その他にも多くの方とつながりを持つことができ、macOS セキュリティというニッチな領域で、研究者間の横のつながりを広げることができました。

聴講した発表

今年は Apple 製品のセキュリティに関する発表が例年より多めで、その発表をメインに聴講しました。以下が (私のも含め) Apple 製品のセキュリティに関連する発表です。

その中でも特に気になった発表を 1 つ簡単に紹介します。

A Worm in the Apple - Wormable Zero-Click RCE in AirPlay Impacts Billions of Apple and IoT Devices

Airborne として知られる一連の脆弱性に関する発表です。発表前からニュース等で取り上げられ話題になっていたこともあり、会場には多くの人が訪れていました。

https://www.wired.com/story/airborne-airplay-flaws/

AirPlay は iPhone や iPad から映像や音声を外部デバイスにキャストする機能です。AirPlay に対応したスピーカーやディスプレイであれば、iPad や iPhone から音楽やビデオをストリーミングできます。この発表では AirPlay のプロトコルに存在した脆弱性と Remote Code Execution (RCE) のデモが紹介されていました。今回の脆弱性の対象となるデバイスは Mac や iPhone など Apple のものにとどまりません。AirPlay SDK を通じて開発されたスピーカーやディスプレイ、車載インフォテイメント ^*1 も対象となります。そのため、この脆弱性の影響は甚大と言えます。

話題性から複雑な Exploit 手法が使われているのではと期待して聴講したのですが、全てが複雑な手法ではありませんでした。 AirPlay SDK に存在した脆弱性はなんと Stack-base の Buffer Overflow (CVE-2025-24132) で、それを通じて AirPlay 対応スピーカーに対する RCE を実現していました。2025 年にもなって、Apple の開発している SDK に Stack BOF があるとは正直驚きました。

発表では別の脆弱性を利用した macOS の RCE のデモも紹介されていました。こちらは Apple Silicon、Intel 関係なく RCE 可能である Use After Free (UAF, CVE-2025-24252) とのことでした。Apple Silicon のセキュリティ緩和策として Pointer Authentication Code (PAC) を知っている方であれば、おそらく PAC をどうバイパスしたかが気になるでしょう。発表者に質問したところ、Data-Oriented Programming (DOP) を使っており PAC bypass は不要とのことでした。おそらく UAF を通じ任意アドレス書き換えの権限を得られるため、これを通じて RCE を実現したと考えられます。しかし、発表の内容だけで正確なところはよくわかっていません。

個人的に印象に残っているのが、一部の脆弱性はあまり深い解析を通じて発見したわけではないということです。非常に簡単なブラックボックスファザーを作成し、そこまで時間をかけることがなく最初の脆弱性を見つけることができたとのことでした。明らかに Apple が AirPlay プロトコルの実装において、十分なコードレビューやファジング等をリリース前に行っていないことがわかります。AirPlay をより詳細に解析することで、まだまだ脆弱性が見つかる気配を感じますね。

もう 1 つ印象に残っているのが Apple が Airborne の脆弱性に対して明らかに適切ではない説明をつけている点です。AirPlay に対応したスピーカーに対する RCE を実現可能な CVE-2025-24132 の説明をみると以下のようになっています。

Impact: An attacker on the local network may cause an unexpected app termination

"unexpected app termination" と記載されており、つまり DoS を引き起こすだけという説明になっています。しかし、実際は RCE を達成できるため、実態を表す記述は "execute arbitrary code" であるべきでしょう。 AirPlay SDK を利用する 3rd party ベンダー製品がすべて対象になることを考えると、適切な脆弱性の説明をつけ、SDK のアップデートを 3rd party ベンダーに促すべきです。特に今回のように RCE を達成可能な深刻な脆弱性であればなおさらでしょう。

脆弱性の説明が不適切というのは macOS の脆弱性報告をしている私も幾度となく経験したことがあります。別の Apple セキュリティ関連の発表 ("Dead Pixel Detected" - A Security Assessment of Apple's Graphics Subsystem) の方でも同じことが言われており、複数の研究者が同じ悩みに直面しているのだと感じました。脆弱性の説明が正しくないと、脆弱性の影響度を正しく判断できなくなり、ソフトウェアのアップデートを適切に促す上で障害となります。Apple はこの問題に早急に対応して欲しいものです。

その他の所感

Black Hat USA がやはり本場

今回 Black Hat USA に現地参加して最初に感じたことは規模の大きさです。 Black Hat Asia に参加した時と比較して参加している人数が段違いに多いと感じました。また、会場の広さ、発表の数も USA が圧倒的に多く、当社代表の Black Hat USA のレビューボードである鵜飼が「USA がやっぱり Black Hat の本場だよね。」と以前言っていたのも納得でした。

スピーカーの待遇も USA の方が圧倒的に良いと感じました。USA の場合はスピーカーに案内役 (liaison) がつき、発表の会場まで案内してくれます。また、発表開始前にスピーカー紹介をし、発表後にはスピーカーと質問者とのミーティングの会場まで案内してくれます。Asia の時と比較し、「講演に招待されている」感じが強かったです。

ホテルにあまり期待しない、必要なものはきちんと持参すべき

日本のホテルの対応に慣れているのもありますが、宿泊したホテルの対応があまり良くなかったので、その点は少し残念でした。この点について 1 つエピソードを紹介します。

同行者の松尾さんが Black Hat の開催中に、体調不良になり、発熱の可能性があったため、体温計が必要となりました。そこで「体温計はないか」とホテルに問い合わせたところ、以下のようなやり取りがありました。

私:「私の同僚の体調が悪く、熱を測りたいのだが、体温計を貸してくれないか。」
フロント:「上司と話してきます。」
... (数分後)
フロント:「ホテルには体温計は置いていない。近くに買えそうな店もないので、Amazon か eBay で探して買って下さい。」
私:「そうですか。」

コロナの頃に体温計ぐらいホテルで購入して用意してそうなものだと思っていたので、体温計をおいてないという発言には驚きました。

幸い同行していた同僚の前田さんが体温計と常備薬を持っていたため、なんとか体温を測ることができ、何かあった場合の薬も手に入れることができ、その場はなんとかなりました。(前田さんありがとうございます。) 教訓として、渡航先で何が起きるかはわからないので、体温計や常備薬、カロリーメイトなど体調不良のときでも食べられそうなものを持っていくことを覚えました。ここは海外渡航に慣れてくるとおろそかにしがちなポイントだと思っています。ちなみに私は、人生初の海外渡航では体温計・常備薬を持っていっていたのですが、2 回目以降から持参しなくなっていました。

時差ボケ対策があるとよい

私は学生の頃にヨーロッパの方へは何回か渡航していたのですが、アメリカに行くのは実は初めてでした。今回アメリカに渡航して感じたこととして、時差ボケがヨーロッパの方に渡航するときよりもひどい、というのがありました。

後で気になって調べたのですが、西回りで移動するよりも東回りで移動するほうが時差ボケはひどくなる傾向にあるようです (科学的裏付けがあるのかは知りません。)。東回りだと時計が進むため、体内時計を早める必要があり、不眠の症状が出やすいようです。実際私は発表の前日は寝付くのにかなり時間がかかり、寝不足の状態で発表に臨むこととなりました。

時差ボケ対策に低用量メラトニンを利用する手もあるようですので、次回渡航する際はこちらも検討しようと思いました。

おわりに

Black Hat Asia の参加記に書いていた Black Hat グランドスラムを今回で達成したので、次の目標を最後に書いてこの記事を終わります。ここに書くことにより自分にプレッシャーをかけるという意味も含んでいます。

いつになるかはわかりませんが、将来的には USA にも通して Black Hat グランドスラム (?) を達成したいと思っています。

「Black Hat Asia 2023 と CODE BLUE 2023 の登壇に至るまで」

Exploit Development トラックで登壇

これはかなり私の主観が入るため賛否両論ありますが、Black Hat Briefings の花形は Exploit Development トラックの発表だと思っています。今年は AI トラックの方が発表数は多いですが、例年 Exploit Development が発表数が最も多く、技術的に高度な内容が例年発表され、インパクトのある発表が多い印象です。(もちろん他のトラックにも私の尊敬する研究者による素晴らしい研究が多くあります。)

私としては Black Hat Briefings で登壇するからには花形のトラックで発表したい、というのがあり、次に発表を投稿する際は Exploit Development トラック向けの内容を用意し、発表したいと考えています。ちなみに今回の発表は脆弱性の話を内容としては含んでいるものの、メインではなかったため Reverse Engineering のトラックに投稿しました。

実は裏話として、今回発表したのとは別に進めていた研究があり、そちらは Exploit Development トラックにふさわしい内容でした。しかし、結局のところ面白い脆弱性を見つけることができず、没になったというのがあります。

分野特化型のカンファレンスでの発表

Black Hat を制覇したので、次は別のカンファレンスにもチャレンジしたいと考えています。その中でも個人的に目指したいと思っているのが Objective by the Sea (OBTS) と OfffensiveCon の 2 つです。

OBTS は Apple 製品のセキュリティに特化したセキュリティカンファレンスです。Apple 製品を専門に研究している私としては、このカンファレンスで登壇することは 1 つの大きな目標でした。実はこれに関しては今年達成の目途が立ち、10 月にスペインで発表してくる予定です。Black Hat で発表した XPR のリバースエンジニアリング結果を話しますが、Black Hat では話せなかった内容が多くあり、その内容も含めて OBTS では話す予定です。

OffensiveCon はベルリンで開催されるカンファレンスです。名前の通りで攻撃技術に特化した内容が取り扱われるカンファレンスです。今年採択された発表のリストからも明らかなように、例年非常に高度な内容が発表されます。非自明で興味深いバグを見つけ、このカンファレンスで登壇することも 1 つの目標です。

登壇を目指す上でまだまだ実力不足のところはありますが、将来的に必ず実現したいと考えています。

*1: 車載インフォテイメントの場合は CarPlay と呼ばれますが、使っている技術スタックは同じようです。 ↩

FFRIエンジニアブログ

株式会社ＦＦＲＩセキュリティのエンジニアが執筆する技術者向けブログです