社内のMicrosoft Teamsに、見覚えのない「IT Service Desk」から突然チャットが届いたら、どう対応するでしょうか。情報セキュリティ担当者やIT管理者、Microsoft 365環境を運用している方に向けて、Teamsの外部アクセス機能が悪用される攻撃パターンと、確認すべき設定を整理します。
セキュリティ企業Arctic Wolfが2025年10月26日に公開した調査では、400件以上のインシデントで共通する手口が報告されています。攻撃者がTeams上でIT部門のサポート担当者になりすまし、最初のメッセージ送信から15分以内に被害者のPCへ遠隔操作でアクセスする、というものです。
何が起きているか
Microsoft Teamsには「外部アクセス（external access）」という機能があります。
これは、異なるMicrosoft 365テナント（組織ごとに割り当てられるクラウド環境の単位）同士で、ユーザーがチャットや通話を行える仕組みです。この機能は初期設定で有効になっています。
両方のテナントが外部アクセスを許可していれば、社外の誰でも組織内の従業員を検索し、チャットを送ることができます。攻撃者はこの仕組みを使い、「IT Service Desk - Liam」のような、いかにも社内サポートらしい表示名でチャットを送ってきます。
観測された事例の30〜40%で、攻撃者はMicrosoftが無料で発行する既定ドメイン（onmicrosoft.com）のテナントを使っていました。このドメインは本人確認が不要で、数分あれば用意できます。テナント名にはsupport、IT、admin、helpdeskといった単語や「365」を組み合わせ、信頼させやすい名前を作っています。
一部の事例では、実在する取引先企業名がテナント名に使われていたケースもありました。Teams上には「External」という外部送信者タグが表示されますが、名前に見覚えがあると判断の負荷が上がり、タグを見落とすリスクが高まります。
攻撃の多くは、事前に被害者の受信トレイへ大量のニュースレター登録確認メールを送りつける「メールボム」から始まります。数分間で数百通のメールが届き、受信者が混乱しているタイミングで、「その問題を解決します」とTeamsチャットが届く流れです。
チャットが成立すると、多くの場合Windowsに標準搭載されている遠隔操作ツール「Quick Assist」の起動を促されます。インストール不要で使えるため、相手の警戒心を下げやすいツールです。持続的なアクセスを狙う場合は、AnyDeskやScreenConnectといった商用RMM（リモート監視・管理）ツールへ誘導されることもあります。その後、PowerShellコマンドを実行させて不正なファイルをダウンロードさせ、ランサムウェア展開を含む侵害に発展した例も報告されています。
なぜ防ぎきれないか
原因を段階的に分解すると、3つの層が重なっていることが分かります。
1つめは、設定の既定値がリスク側に倒れている点です。外部アクセスも、未管理アカウントとのチャットも、初期状態では許可されています。組織側が意図して制限しない限り、誰でも社内ユーザーにメッセージを送れる状態が続きます。
2つめは、信頼のシグナルが表示名とテナント名という、攻撃者が自由に設定できる情報に依存している点です。「External」タグは送信元が社外であることは示しますが、その送信者が本物のIT部門でないことまでは示してくれません。
3つめは、時間的な制約です。最初の接触から15分以内に遠隔操作へ至るケースが多く、ユーザーが立ち止まって確認する猶予がほとんどありません。研修で「怪しいと思ったら確認する」よう教えても、判断が間に合わない設計になっています。
ランサムウェア集団Black Bastaを含む複数の攻撃グループが、この外部Teamsチャットを初期侵入経路として使っていることも報告されています。単発の悪戯ではなく、再現性のある攻撃手法として定着していると見るべきです。
自分の組織が該当するか確認する方法
まず、Teams管理センター（admin.teams.microsoft.com）にアクセスし、以下を確認してください。
- Users > External access の設定で、外部アクセスが全ドメイン許可になっていないか
- 未管理テナント（Teamsアカウントを持たない組織）やTeams consumer（個人向けTeams）アカウントとのチャットが許可されていないか
- 未管理ユーザー側からチャットを開始できる設定が有効になっていないか
- Quick Assistの利用が全従業員に許可されていないか（Intuneやグループポリシーで制御されているか）
- 社内で許可していないRMMツール（AnyDesk、ScreenConnect等）がエンドポイントにインストール可能な状態か
これらはポータル画面から確認できる項目です。CLIで管理している場合は、Microsoft Teams PowerShellモジュールのGet-CsTenantFederationConfigurationを実行すると、現在の外部アクセス設定を一覧で確認できます。
# Teams PowerShellモジュールで現在の外部アクセス設定を確認
Connect-MicrosoftTeams
Get-CsTenantFederationConfiguration | Format-List AllowedDomains,BlockedDomains,AllowTeamsConsumer,AllowPublicUsers出力のAllowedDomainsがAllTrustedDomains（全ドメイン許可）になっている場合、対策が未実施の状態です。
対策の手順
報告されている推奨策は、攻撃の各段階に対応する形で整理できます。
まず、外部アクセスの範囲を絞り込みます。Teams管理センターのExternal accessで「特定の外部ドメインのみ許可」を選び、取引のある組織のドメインだけを許可リストに登録します。
# 特定ドメインのみ許可し、それ以外をブロックする設定例
Set-CsTenantFederationConfiguration -AllowedDomains $AllowAllKnownDomains -BlockedDomains @{Add="*"}次に、未管理アカウントおよびTeams consumerアカウントとのチャットを無効にします。これにより、管理されたテナントを持たない攻撃者が無料アカウントを使って接触する経路を塞げます。トライアルテナント同士の連携もブロック対象に含めると、攻撃者が最も安価に調達できるインフラを封じられます。
続いて、Quick Assistの利用を許可されたIT部門のロールに限定します。Microsoft Intuneのアプリ保護ポリシーやAppLockerで、一般ユーザー端末からの起動を制限する方法が一般的です。未承認のRMMツールについては、エンドポイント検出・対応（EDR）製品でブロックリストに登録するか、アンインストールを徹底します。
最後に、ユーザー側の通報経路を整備します。Teamsにはメッセージや外部ユーザーを2クリックで報告できる機能があり、Microsoft 365 Defenderと連携して管理者に通知が届きます。これは最初の接触段階、つまりまだ不正なファイルが存在しない時点で検知できる、数少ない手段です。
研修自体が無意味というわけではありません。実際のIT部門がどのドメインから、どんな手順で連絡してくるかを明文化し周知することは、Externalタグが埋めきれないギャップを補う役割を果たします。ただし、研修だけに頼る設計は前提として避けるべきです。RMM制限のような、ユーザーの判断に依存しない対策を先に置くことが、全体の設計として筋が通っています。
まとめ
Teamsの外部アクセスは便利な機能である一方、初期設定のままでは社外から組織内ユーザーへの接触を広く許してしまいます。まずGet-CsTenantFederationConfigurationで現状を確認し、許可ドメインが絞られているかを見てください。
続いて、未管理アカウントとのチャット、Teams consumerとの連携、トライアルテナントとの federationが許可されたままになっていないか、管理センターで一つずつ点検します。
Quick AssistとRMMツールの利用制限は、ユーザーの注意力に頼らない対策として優先度が高い項目です。これらを設定したうえで、Teams内の通報機能を周知し、最初の接触段階で検知できる体制を整えておくと安心です。