本サイトは、快適にご利用いただくためにクッキー(Cookie)を使用しております。
Cookieの使用に同意いただける場合は「同意する」ボタンを押してください。
なお本サイトのCookie使用については、「個人情報保護方針」をご覧ください。
はじめに
岩崎利己です。
私はMBSDに中途入社して2年目で、普段はWebアプリケーション脆弱性診断を行っております。
このブログでは、2025/08/03~08/07にラスベガスで開催された「Black Hat USA 2025」の参加レポートをお送りしたいと思います。
入社2年目の若輩でも希望したらすんなり行かせてくれたので「いいから黙って全部オレに投資しろ!!」という心意気のある方は弊社、いいんじゃないでしょうか。
Black Hatについて
採用活動もほどほどにBlack Hatの紹介です。
Black Hatには大別して以下の要素があります。
- Trainings
2日間、もしくは4日間かけて一つのトピックスを学ぶコースが提供されます。各コースはBlack Hat Trainings Review Boardによって厳選されているようなので高い品質が期待できます。 - Briefings
各国のセキュリティエンジニアが最新の調査・研究内容を発表する場です。各セッションは40分で構成されており、タイムテーブルによっては自分が聞きたいセッションの時間が被っていることもあるので同行者と分担して聴講するのも有効です。 - Arsenal
プレゼンターが作成したツールや自社製品などを、より参加者と近い距離で共有するコミュニケーションの場です。弊社も以前プレゼンターとして参加していますのでそちらのブログもぜひご覧ください。
セキュリティトレーニング・ツール"ZANSIN"の公開 | 技術者ブログ | 三井物産セキュアディレクション株式会社
AIのための脆弱性スキャナー -Black Hat ASIA 2021 Arsenal 登壇予告- | 技術者ブログ | 三井物産セキュアディレクション株式会社 - Business Hall
企業ブースです。各会社が自社製品のデモを用意しており、商談の場として大いに盛り上がっていたように思います。(私はあまり立ち寄りませんでした。)
私は主に「Trainings」と「Briefings」に重きを置いて動き回っていたので今回はその二つにフォーカスしてお送りします。
Trainings
元々は弊社のメンバー全員に、AIに関係するトレーニングを受けるミッションが与えられていましたが、わがままを言って私が受けたいトレーニングを受けさせていただきました。(圧倒的感謝)
さて、今回私は「Advanced Threat Emulation: Evasion」という検知回避を主眼とした二日間のトレーニングを選択しました。
当トレーニングはBC Security社の方が講師を務めており、同社が提供するトレーニングサービスにも同名のコースが存在します。
https://bc-security.org
主にWindows環境をターゲットとしており、トレーニングで使用する環境にはBC Securityが提供するプラットフォーム上に構築されたWindowsと、それを監視するELK Stackが存在します。この環境に対して攻撃を行い、検知の有無を確認しながらトレーニングが進行していきます。
人気のトレーニングかなと思いきや20人ほどしか参加者がいなかったのでAI系のトレーニングに人が流れたのかなと推測しています。
また、この少ない参加人数の中で、日本人参加者が私を含め4人いらっしゃいました。他のAI系のトレーニングでは日本人があまりいないという話も聞いていたので現在の日本は検知回避への関心の方が高い傾向にあるということでしょうか。
参加者の自己紹介を聞いた感じでは私以外のほぼ全員が何かしらの形で当該トレーニングに関わる業務に携わっており、ものすごい焦燥感に駆られた覚えがあります。
スケジュール
トレーニングは以下のスケジュールで進行しました。
Day1 | Introduction to Evasion |
Threat Hunting | |
Breaking Blue's Kill Chain | |
Windows Attack Surfaces | |
Theory of Obfuscation | |
Day2 | Obfuscating Methods |
Practical Implementations of Obfuscation | |
Evading Blue Team Hunt | |
Masking Network Traffic | |
SOC Exploitation |
表を見てわかる通りObfuscationにかなりのウェイトが取られております。
これについては講師の説明にもありましたが「新しい手法をゼロから研究するよりも、既存の検出を回避するために難読化を深く理解し適用することが、レッドチームの運用において非常に価値が高い」ということからObfuscationを重視しているようです。
ここからは各セクションごとに、公開して差し支えない情報をご紹介します。
Introduction to Evasion
このセクションは座学形式で行われ、主に以下の内容の説明がありました。
- レッドチームとブルーチームにおける目的、活動の対比
- Advanced Persistent Threat(APT)とは何か、またその活動の性質について
- 近年進化を続けているAPTのタクティクス(TTPs)の説明
- 攻撃者のライフサイクルについて、またレッドチームが攻撃者のライフサイクルを理解することの重要性
- Evasionとは何か (当トレーニングではEvasionの例として以下が挙げられています)
- Disabling Security Software
- Obfuscation
- Encryption
- Blending into network traffic (Normal operations)
- Leverage trusted processes or files (LOLBins)
- Alternate Communication
また、以前から私の中での「Evasion」の認識は「検知されない」だったんですが、トレーナーによると「攻撃実行からインシデントが発生したと宣言されるまでの時間をできるだけ延長し、ゴール達成のチャンスを最大化するもの」と説明されており認識を改めるきっかけになりました。
Threat Hunting
引き続きこのセクションも座学形式です。
- IoC(Indicators of Compromise)とは何か
- 一般的なIOC
- Strong Indicators (単独で悪意のある活動の根拠となる指標)
- Weak Indicators (疑わしいがそれだけでは悪意があると特定できない指標)
- セキュリティ製品の概要
- AV
- EDR
- IDS,IPS
- FW
- SIEM
Breaking Blue's Kill Chain
このセクションはブルーチームの防御策を回避するためにその防御策を理解するところから始まります。
ブルーチームの防御策は「Funnel of Fidelity」という概念で表されることが多いらしく以下のような図で示されます。
引用元:Introducing the Funnel of Fidelity
https://miro.medium.com/v2/resize:fit:2000/format:webp/1*vS3SAuKsSAfFrTXjKSJDwg.png
この図によるとFunnel of Fidelityは以下の段階で構成されています。
1 |
Collection(収集) |
ネットワーク上のあらゆるソースから大量のログやテレメトリーデータを収集 |
2 | Detection(検出) | 収集されたデータから潜在的な脅威を特定する |
3 | Triage(優先度決定) | 検出されたアラートを重要度と関連性に基づいて優先順位付け |
4 | Investigation(調査) | 優先順位付けされたアラートの詳細な分析と調査を行い、真に陽性かを確認する |
5 | Remediation(修正、改善) | 確認されたインシデントを封じ込め、根絶し、復旧するための措置を講じる |
また、上記のそれぞれの段階に対して分類されたEvasionのテクニックも説明されました。
1 | Collection Evasion(収集回避) | センサーが把握できない戦術や技術を使用したり、センサーそのものを無効にする等 |
2 | Logical Evasion(論理回避) | 検出ロジックを回避するために、コードの難読化や既知のTTPをカスタマイズして「偽陰性」を引き起こす |
3 | Classfication Evasion(分類回避) |
悪意のある活動を通常の活動に紛れ込ませることで、詳細な分析を回避する。これにより「偽陽性」となることを狙い、アラート疲労を悪用する。 |
4 | Temporal Evasion(一時的回避) | ブルーチームが対応するよりも早く目的を達成する |
5 | Technical Evasion(技術的回避) | 担当者が必要な技術的スキルを持っていなかったために検出されなかったケースを指す |
6 | Procedural Evasion(手続き的回避) | アラートのエスカレーションプロセスが機能しない場合など、ブルーチーム側のプロセスに問題があったために検出されなかったケースを指す |
Windows Attack Surfaces
このセクションでは狙われやすいWindowsのコアコンポーネントに焦点を当て、ハンズオンを交えて回避手法を学びました。
- PowerShellのソースコードを確認しながらAMSIバイパスを実装する(AMSI Providerを実装した経験があったのでこのあたりは理解しやすかったです)
- .NET リフレクションを使用してアセンブリ名をETWイベントにキャプチャされないようにSeatbelt.exeを実行する
- API Hookingが行われている関数を特定し、フックを解除する
- 脆弱なドライバを解析し、任意のプロセスをKillできる脆弱性を悪用してDefenderを継続的に使用不可能にする
Theory of Obfuscation
このセクションでは攻撃者が自身のコードや挙動を検知から隠蔽するため、細かく分類された難読化技術が説明され、それぞれの実装方法を学びました。
詳細については以下で確認できますので是非興味がある方はご確認ください。
Obfuscating Methods
「Theory of Obfuscation」から続いてC#のメソッドを用いた難読化手法です。難読化の対象は変わりますが、内容はほぼ同様です。
このセクションの最後に「Obsuscation Competition」が行われました。
これまでに学習した難読化手法を用いて、与えられたPowerShellコードの機能を変更せずに実行する、というものです。
このCompetitionで「MOST UNIQUE code」に選ばれ、チャレンジコインとC2フレームワークである「Empire」のトレーニングバウチャーをいただきました。
Practical Implementations of Obfuscation
ここまでで学んできた個々の難読化手法を「Invoke-Obfuscation」を使用して複合的に組み合わせて実装するハンズオンを行いました。
ただし、むやみやたらにツールを使用するだけでは元々の機能を損なう可能性があるので、検証を行いながら動く実装を最終的に提出する必要があります。
Evading Blue Team Hunt
このセクションでは既存のTTPsに対して変更を加えることで検知回避を試みる手法が説明されました。
ハンズオンではPsinjectという、Cobalt StrikeやEmpireでよく使われる手法を、どのように変更して検出を回避するのかを探りました。
PSinjectの仕組み自体は以前実装したことがあり、Unmanaged Codeから.NET CLRを起動し、CLR経由でManaged Codeを実行するというところまで噛み砕けていたので特に手こずることはありませんでした。
また、CloudFlare WorkerをリダイレクタとしたC2環境を構築し、Stager経由でC2セッションを張る、といった発展的なハンズオンも行われました。
(ハンズオンと同時にCloudFlareとngrokのアカウントを作らなければいけなかったので別のところで手こずりました…)
Trainingsまとめ
受講する前までは自分のレベルに合ってないのではないかと不安になっていましたが、いざ受講してみるとTry Harderしてちょうどいい難易度のコースでした。
ただ、私の他は業務でペネトレーションテストやレッドチームを担当している方ばかりでしたのでその方々からするとまた違った意見かもしれません。
ちょうどC2フレームワークのどれかに手を出さなければいけないと思っていたのでEmpireトレーニングのバウチャーがもらえたのはラッキーでした。
Breifings
私は二日間で以下のセッションを聴講しました。
- I'm in Your Logs Now. Deceiving Your Analysts and Blinding Your EDR
- Death by Noise: Abusing Alert Fatigue to Bypass the SOC (EDR Edition)
- Thinking Outside the Sink: How Tree-of-AST Redefines the Boundaries of Dataflow Analysis
- HTTP/1.1 Must Die! The Desync Endgame
- Not sealed: Practical Attacks on Nostr, a Decentralized Censorship-Resistant Protocol
- Diving into Windows HTTP: Unveiling Hidden Preauth Vulnerabilites in Windows HTTP Services (PRE-RECORDED)
- AI Agents for Offsec with Zero False Positives
- Lost & Found: The Hidden Risks of Account Recovery in a Passwordless Future
- Cross-Origin Web Attacks via Http/2 Server Push and Signed HTTP Exchange
- Behind the Screen: Unmasking North Korean IT Workers' Operations and Infrastructure
この中から最も私の糧になったセッション、「Lost & Found: The Hidden Risks of Account Recovery in a Passwordless Future」についてセッションの内容を簡単に説明します。
当セッションでは、今日ほとんどのWebサイトが有する機能であるユーザーアカウントのリカバリーにおけるセキュリティ上の脆弱性の説明と、それに対処するための最善策を提示していました。
これに関連する脆弱性は確かに私がWebアプリケーション診断を行ってきた中でも何度か検出したことがあります。中にはなんでこんな実装になったんだ…?というようなサイトもありました。
スピーカーは「アカウントリカバリにはベストプラクティスがないか、誰もアカウントリカバリに注目していないため、または、ログインなどの別の領域で使用するベストプラクティスをリカバリに適用してしまっているか、のどちらかである。」と述べており、確かにアカウントリカバリー機能が悪用される事例は散見されますが、実装のベストプラクティスにフォーカスされることって少ないなと感じます。
そのためスピーカーは後述するテストケースの作成によって当該領域のセキュリティを高めることに貢献されています。
以下は(私が理解できた範囲での)スピーカーが提示していた脆弱性の一覧です。
- アカウントリカバリー時にメールや電話番号の所有検証が不十分な場合がある
- アカウント作成時にメールアドレスが設定されていないにもかかわらず、復旧プロセスがメールアドレスの存在を前提としている場合がある
- アカウントリカバリー後も以前のログインセッションが継続される場合、攻撃者がリカバリーを実行しても正規ユーザーが検知できない(スピーカー曰く「Parallel Session Attack」)
- リカバリープロセス中にMFAが利用されない場合、攻撃者と正規ユーザがアカウントを取り合う状態になる可能性がある。(スピーカー曰く「Arms Race Attack」) また、攻撃者が以前と同じパスワードを使用してアカウントリカバリーを実行した場合、継続的かつステルスなアクセスを取得される可能性がある。
- 信頼済みデバイスからのアクセスにおいて、リカバリー後の再認証でMFAが要求されない場合、攻撃者がデバイスに物理的にアクセスしてアカウントリカバリー方法の設定を変更することで正規ユーザをシャットアウトすることが可能になる。
- アカウント設定やリカバリー方法の変更時にユーザーにアラートが送信されないため、攻撃が検知できない可能性がある
-
ユーザーがアカウントを作成する際に、パスワード以外のリカバリー方法の追加と検証をユーザに強制していない場合、ユーザーは最低限の認証情報(ユーザIDとパスワードのみ、など)でアカウントを作成できてしまい、もしパスワードを忘れたりアカウントが侵害されたりした場合に、そのアカウントを復旧するための安全な手段が提供されていない状態からスタートすることとなる。
- ログイン機能や、認証後の重要な要素の変更時にはMFAが要求される一方で、アカウントリカバリーにおいてはMFAが十分に活用されていないケースが多い
上記の脆弱性に対してスピーカーはアカウント作成時、リカバリーのトリガー時、リカバリー処理時など各ステップに分けて包括的な対策を提示されていました。
「これは最低限やらなければならないよね」といったような対策もあった一方で実装にコストがかかりそうな割に効果が薄そうな対策も見て取れたため、あくまでベストプラクティスのような活用とし、自組織としてどこまでの実装を担保するかをトリアージすべきかなと考えています。
また、スピーカーは上記の脆弱性をテストするためのテストケースを公開されております。アカウントリカバリの各ステップごとにQuestionに回答していく形式で、次に確認すべきテストケースとの紐づけもされているので実用的かと思います。興味のある方は以下からご覧いただけます。
Nokia-Bell-Labs/Account-Recovery-Threat-Heuristic-Auditing-Framework
最後に
参加する前はやけにハードルが高かったBlack Hatでしたが、参加してみたらあっという間の4日間でした。
ハードルの1要因であった英語も、AIや翻訳技術の進化によって気にならないレベルにまで来ています。
それでもどうにもならない時があっても「旅の恥は搔き捨て」という言葉もあるくらいですし、多少思い切ってみてもいいのではないでしょうか。
以上、来年も弊社のエンジニアが大勢参加できますように…
おすすめ記事