この記事はzennから移植しています
https://zenn.dev/hiro1noue/articles/2cc60cd8724b9e
はじめに
応募課題で求められているのは正解ではなく、どう考えたかだと感じました。
そもそも知識で私は絶対に勝てないので、私は知識を並べるのではなく、
- 仮説を立てる
- 調査する
- 仮説と比較する
- 自分なりの問いを立てる
ことを意識して書きました。
これから応募する人の参考になればと思い公開します。
なお、現在読み返すと技術的に不正確な部分や理解が浅い部分もありますが、当時の考察過程を残したかったため本文は修正していません。
応募時点での私のプロフィールは以下です。
- 高専1年生
- web、フロントエンドがメイン
- CTFと競プロを少し前に始めた
- AtCoder A:灰色(参加回数6回) H:灰色(参加回数1回)
- CTFではeasyのweb問がとけるかもレベル
Q1
Q1. Microsoft Entra ID（旧Azure AD）を狙った攻撃について、実際に報告されている事例を1つ以上調査し、その事例で用いられた攻撃手法を、悪用された認証・認可フローやクラウド機能の観点から詳しく解説してください。
なお、回答にあたって参考にしたURLや文献は必ず明記してください。調査や自身の理解を深めるためにLLMを活用すること自体は問題ありませんが、LLMの回答を一次情報としてそのまま引用しないでください。LLMの回答内容については、LLM以外の情報ソースで妥当性を確認したうえで、その情報ソースを参考文献として記載してください。
まず、調べる前にある程度仮説を立ててみます。ここでは考えやすいように攻撃者の目的を、情報を得ることだと仮定します。Microsoft Entra IDについて、2FAやパスキーなどによりインジェクションや辞書攻撃による侵入は困難でしょう。そのためアプローチしやすいのは人的脅威を狙った攻撃、もしくはCookieやトークンを盗むことによる攻撃だと考えます。人的脅威は攻撃の再現性が低いため、より技術的に安定した攻撃対象としてセッション情報に注目します。ではCookieを盗むにはどうすれば良いのでしょうか。思いつく方法としては、物理的にターゲットのpcを操作する、ブラウザにログインする、偽のサイトを用いてフィッシングをする、通信にプロキシを仕込んでおく、などでしょうか。
実際に調査をしてみました。
Microsoft が公開している調査レポートでは、認証セッションを盗み取るフィッシングサイトを利用し、最終的に企業間の送金詐欺へ発展した事例が報告されています。この例ではMFA(多要素認証)そのものを突破するのではなくMicrosoft Entra IDの認証後に発行されるセッションクッキーを盗むことで、攻撃者がoutlook等にアクセスしていました。攻撃者はただのフィッシング詐欺ではなく、本物のメールアドレスを利用して被害者に成りすますことで、取引先に不正な送金をさせるBEC(Business Email Compromise)型の詐欺を行っていました。
この事例では、攻撃者は間にプロキシを挟むAiTM(Adversary in the Middle)と呼ばれる攻撃を利用してMicrosoft Entra IDの認証を悪用していました。通常、Microsoft 365にサインインする際には、Entra IDを利用してパスワード認証やMFAが完了すると、認証済みであることの証明書のような役割を果たすセッションクッキーやトークンが発行されます。このセッション情報を利用することで、ユーザーは再度MFAをすることなくExchange Onlineなどのクラウドサービスへ継続的にアクセスできるのです。
今回の攻撃では、Microsoftのログイン画面を模倣した偽のサイトが用意されていましたが、単なる偽のログインページではなく、プロキシとして正規の認証ページとの通信を中継する構造になっていました。そのため被害者の画面では、認証情報の入力によって正常な動作をしているようにしか見えません。
セッションクッキーは認証完了後に発行されますが、この事例ではAiTMプロキシが中継をしているため、発行されたセッション情報は攻撃者の手に渡った後に被害者の手に渡ります。その結果、攻撃者はユーザーのパスワードだけでなく、認証済み状態を示すセッションクッキーまで取得することが可能となっていました。セッションクッキーを利用することで、攻撃者はEntra IDにおいて「認証済みユーザー」として扱われる状態を再現でき、その結果として再認証を必要とせずにOAuth 2.0に基づくトークン発行が行われました。これにより、Exchange OnlineやOutlookなどの各クラウドサービスに対しても、SSO（シングルサインオン）を通じて正規ユーザーと同等のアクセス権限が付与されていました。
つまり、この攻撃は”MFAを破った”のではなく、”MFA後のセッションを乗っ取った”点に特徴があると考えます。認証・認可の観点では、Entra ID はセッションクッキーを保持しているブラウザを「既に認証済みの正当な利用者」と判断するため、攻撃者も正規ユーザーとして扱われてしまったのではないでしょうか。
ここで私の仮説と比較をしてみます。
今回の調査では、事前に考えていた「Cookieやトークンを盗むことで認証を回避する攻撃」が実際に存在していたことが分かりました。特に、認証を突破するのは困難であるため、セッションクッキーを盗むことで認証済み状態を再利用するという点は、当初の仮説と概ね一致していました。
また、私は当初”通信にプロキシを仕込む”ことが攻撃手法の一つとして考えられると予想していましたが、実際の事例では AiTM（Adversary in the Middle）という形で、まさに認証通信の中継を利用した攻撃が行われていました。特に印象的だったのは、単なる偽ログインページではなく、正規の Microsoft 認証ページとの通信をリアルタイムで中継する構造になっていた点です。そのため、利用者視点では通常のログインとほとんど区別がつかず、MFAを利用していても不正アクセスが成立していたことが分かりました。
一方で、想定していなかった点もありました。私は当初、Cookieを盗む目的は主に”アカウントへの侵入そのもの”だと考えていました。しかし実際には、攻撃者の最終目的は Outlook や Exchange Online 上のメールを利用した金銭詐欺でした。攻撃者は単に情報を得るだけでなく、実際に取引メールに介入することで被害者本人に成りすましてお金を得るなど、現実的で金銭目的の攻撃を行っていると感じました。
いくつか気になった点があったので考察してみます。
-
このような形で突破されるのであればMFAに意味はあるのか
結論から言うと意味はあると感じました。なぜなら今回の攻撃のターゲットとMFAが担当する守備範囲がずれていると感じたためです。MFAはログイン前からログイン後への遷移、つまり認証をより安全に行うために存在します。それに対してAiTMはログイン後の状態を奪うことに注目している。つまり、MFAは認証時の不正ログインを防ぐ点では有効であり、本事例ではその後段のセッション再利用が悪用されているため、防御対象のレイヤーが異なると考えられます。よってMFAは必要だと感じました。 -
SSO(シングルサインオン)はやめるべきなのか
そもそもSSOとは「1度のユーザー認証で複数のシステムの利用が可能になる仕組みのこと。」(NTT “シングルサインオン（SSO：Single Sign On）とは” より) です。この仕組みには利便性の面でメリットが大きいですが、一つのサービスを突破されると複数のサービスにアクセスされることにつながるという弱点があります。そのためこの仕組みをなくしてしまった方が安全性は高いのではないかと考えました。しかし、もしSSOがなくなると、各サービスに逐一ログインが必要になるため、正直に言って面倒で冗長です。そのため、”面倒だから”、”邪魔だから”そもそも使われないという本末転倒な結末へと向かってしまう可能性があるのではないでしょうか。つまり、SSOではなくとも、何かしら利便性を向上させるためのアプローチは必要になると感じました。ここは私が以前から興味を持っていた、”セキュリティと利便性の両立”という課題に重なる部分があり面白かったです。 -
攻撃者にとって難しいのはどこか
これは1つめの問いと重なる部分もありますが、やはりMFAを迂回するというアプローチをとったのが興味深かったです。私はセキュリティの中でも特に攻撃者の視点に興味があるため、”直接認証で突破できない”という状況に興味を持ちました。
また、攻撃者が継続して攻撃をするために被害者に見つからないような努力をしていたところも面白いと感じました。今の私はCTFにおいて被害者サーバーに侵入して終わりになっていますが、実際の攻撃者の視点に立ってみると侵入した後にどうするかという観点も重要になってくると感じました。
最後に、この調査ではAIとの対話を通じて仮説を整理しつつ、一次情報はMicrosoftの公式ブログやドキュメント等を利用して確認しました。
参考文献
Microsoft Entra ID
https://www.microsoft.com/ja-jp/security/business/identity-access/microsoft-entra-id
Entra IDって何？五味ちゃんと学ぶ Entra IDのはじめの一歩～Entra IDの概要からADとの違い、出来ること、Freeとの違いまで～
https://licensecounter.jp/microsoft365/blog/2023/02/azuread-fundamentals.html
From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud
https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/
多要素認証を突破する「AiTM攻撃」とは？その対策は？
https://www.trendmicro.com/ja_jp/jp-security/25/j/securitytrend-20251003-01.html
Microsoft Entra ID を使用した OAuth 2.0 承認
https://learn.microsoft.com/ja-jp/entra/architecture/auth-oauth2
Microsoft EntraIDで学ぶOAuth2
https://youtu.be/ABbL9-SBJ2k?si=KlbYSKwg2SXE6Hcm
シングルサインオン（SSO：Single Sign On）とは
https://www.ntt.com/bizon/glossary/e-s/sso.html
Q2
Q2. サイバーセキュリティに興味をもったきっかけと、これまでに学習してきたサイバーセキュリティ分野の内容、プログラミングの経験、およびLLMとどのように関わってきたかについて教えてください。
私はサイバーセキュリティに興味を持つようになったきっかけが、大きく二つあります。
一つ目は、Web開発の経験です。
私は中学生の頃、パソコン部に所属し、「全国中学高校Webコンテスト」に参加しました。この経験を通じてWeb開発に興味を持ち、実際に制作を進める中で、小規模なサイトや古いシステムに存在する脆弱性のような挙動に気づくようになりました。例えば、静的なクイズページにおいてスコア管理の変数を書き換えることでスコアが増加して見えるといった現象です。今思えば小さな発見でしたが、当時の私にとっては非常に新鮮であり、同時に「仕組みの隙」を意識するきっかけとなりました。この経験を通じて、開発を行う際にはセキュリティの視点を持つ重要性を学びました。
二つ目は、家族が詐欺被害に遭った経験です。
約2年半前、父が投資詐欺の被害に遭いました。最終的には補償を受けることができましたが、その過程を間近で見たことで、強い無力感と悔しさを感じました。この経験を通じて、技術的な対策だけでは防ぎきれない「人的脅威」の存在を強く意識するようになりました。現在は、詐欺への対抗手段について考察しながら、個人で関連する開発にも取り組んでいます。具体的には、詐欺被害後に備えて、アクセス履歴や不審サイトの記録をローカルに保存し、証拠として提出できる形に整理・出力できるChrome拡張ツールを制作しています。
これらの経験を踏まえ、私はサイバーセキュリティ分野について個人的に学習を進めてきました。当初はBlue Team寄りの関心を持っていましたが、攻撃側の視点から弱点を見つけ出すプロセスに面白さと適性を感じ、現在はRed Team寄りの分野に興味を持っています。
セキュリティ関連では、CTFへの参加およびSECHACK365への応募があります。CTFへの参加は約4か月前からで、始めた時期は中学3年生の3学期と比較的遅いですが、その分短期間で集中的に取り組んできました。具体的には経験や原体験を生かせるweb問題に積極的に取り組みました。フォームなど比較的フロントエンドよりの部分は少しでも経験があったので取り組みやすかったのですが、サーバーサイドの理解に苦しみました。印象に残っているのはReverse Shellを使ってはじめてShellに侵入したときです。フロントとサーバーの境界の脆さを実感した、自分にとって変則的で面白いアプローチでした。
一方で、開発分野ではPythonで強化学習に挑戦したり、「第27回全国中学高校Webコンテスト」において中学2年時にプラチナ賞を受賞したりしました。また現在は、高専プロコン競技部門に向けてC++のフレームワークである”Siv3D”を活用したGUI開発、”NEXT.js”での無線部のホームページ制作に取り組んでいます。
Blue Teamとしてセキュリティを意識した実装に取り組む中で、防御の重要性や奥深さを学ぶ一方で、自分の関心の方向性についても考えるようになりました。実際に経験する中で、防御側の取り組みは非常に体系的で成熟しており、その分野の専門性の高さを強く感じました。その中で、自分としてはより攻撃者視点からシステムの弱点やリスクを発見し、改善につなげていくアプローチに強く興味を持つようになりました。
そんな中、YouTubeでホワイトハッカー（レッドチーミング）に関する動画をたまたま目にして、フィクションだと思っていた領域が現実の専門職として存在することに衝撃を受けました。すぐに関心を持ち、自分でも挑戦してみたところ、システムの弱点を見つけ出し構造を理解していく過程に強く惹かれ、自身の適性とも合っていると感じました。もともと、新しい仕組みを一から作ること以上に、既存のものを分析し改善点や脆弱性を見つけることにやりがいを感じるタイプであり、その特性がレッドチームのアプローチと親和性が高いと考えています。
私はLLMに0 to 1をさせるのではなく、自分が1を作るのを前提にその壁打ちや補助として使うことが大切だと思って関わってきました。もっと言えばAIを"知的な議論相手"として、"自分専用のメンター"として使うようにしています。私の意見として、LLMは技術的な面の実装や修正には向いているが、それこそ0 to 1で何かを作ることや大きな方針の決定は任せられないと考えています。実際、 Q1でも所謂"ソクラテス式"の会話を用いて、自身の考えを整理することと考えの壁打ち相手として使用することを意識していたと思います。このゼミでも同様に、自身の挑戦を助けてくれるツールとしてLLMとうまくかかわっていきたいと考えています。
Q3
Q3. 本ゼミを通して何を学びたいか、そしてそこで得た学びを今後どのように活用していきたいかを、熱い意気込みとともに教えてください。
Z2ゼミは、Redチーミング・Blueチーミング・LLMという、私が特に重要だと考えている三つの領域を同時に扱い、それらを個別の知識ではなく一つのものとして統合的に学べる点に強く魅力を感じました。特に「認証」というテーマは、セキュリティと利便性の両立が最も顕著に現れる領域であり、攻撃と防御の境界が曖昧になる現実的な問題に対して深く向き合える題材だと考えています。
また、私はこれまでセキュリティにおいてRedとBlueのいずれか一方ではなく、その接続点に関心を持ってきました。本ゼミのように、攻撃理解・防御設計・AI活用が同一の文脈で扱われる環境は、自分の関心と強く一致していると感じています。
本ゼミでは、RedとBlueを対立構造としてではなく、相互に変換可能な技術として扱い、それらを組み合わせて実際の価値へと昇華させる方法を学びたいと考えています。
特に、AIエージェントを用いた攻撃検証や検知の自動化に強い関心があります。従来のセキュリティは人手による分析やルールベースの対応に依存する部分が多く、ソーシャルエンジニアリングやAiTMのような人的要因を含む攻撃に対しては限界があります。そこでAIを単なる補助ではなく、攻撃再現・異常検知・ログ解析の一部を自律的に担う存在として設計することで、防御の到達範囲を拡張できる可能性を探りたいと考えています。
さらに、人的脅威に対してAIがどこまで対応可能かという点も重要なテーマです。攻撃の本質が技術ではなく「理解していない人間を狙うこと」にある以上、システム単体の防御では限界があります。だからこそ、ユーザーの行動や状況の中にあるリスクを検知し、未然だけでなく事後も含めて支援できる仕組みが必要だと考えています。
この問題意識の背景には二つの経験があります。
一つは、父が投資詐欺の被害に遭った経験です。被害自体だけでなく、その後の補償や手続きのフローが非常に長く複雑であることを目の当たりにし、「被害後に何が起きているのかを正確に把握できる仕組みの不足」を強く感じました。この経験が、被害後支援という視点につながっています。
もう一つは、6歳の妹がすでにスマートフォンを利用しているという現実です。知識のないままインターネットに触れる環境が当たり前になっている中で、「守られる前提のない人間が簡単にアクセスできてしまう世界」の危うさを実感しました。
これらに共通するのは、「攻撃される可能性のある人をどう守るか」という問いです。
現在開発しているChrome拡張機能は、詐欺被害の未然防止ではなく「被害後支援」に焦点を当てています。日常的なWeb閲覧履歴やアクセスしたURLをローカル環境で記録し、必要に応じて時系列データとして整理・出力できる仕組みを持っています。
さらに、既知の詐欺サイトとの照合や不審ドメインの検出により、怪しいアクセスを自動的に識別・記録することで、被害発生時に状況を客観的に再構成できる設計にしています。出力されたログはPDF形式で整理され、金融機関や警察などへの相談時にも利用できる形を想定しています。
この「異常検知→記録→自動化」という構造は、Z2ゼミで扱われるBlue Agentの思想と強く共通していると感じています。単なるログ保存ではなく、AIを組み合わせることで意味付けや分類を行い、より実用的な防御・支援システムへと発展させられる可能性があると考えています。
本ゼミでの学びを通じて、ホワイトハッカーとして攻撃と防御の両面を理解するだけでなく、その知識を社会実装へと接続できる人材になりたいと考えています。
単に脆弱性を見つけるだけで終わるのではなく、父や妹のような「狙われる立場の人」が現実に存在することを前提に、そのリスクを技術で減らし、実際に守る仕組みを構築することが目標です。
攻撃を理解する力と、防御を設計する力、そしてそれを社会に展開する力。そのすべてを統合し、「壊せる人間」ではなく「守りを設計し、現実に実装できるホワイトハッカー」として成長したいと考えています。
最後に、始めたきっかけこそ問題意識が大きいですが、やっていて思うことがあります。楽しいです。想像通りに突破できた時の達成感も、苦労した末に突破した達成感も、知的好奇心が満たされていく感覚も、楽しいからこそ私はこの分野を続けることができています。だからこそ僕は、自分が楽しんだうえで、周りの人々を救える人間になりたいです。