DragonForce のランサムウェア攻撃で確認されたバックドア Backdoor.Turn は、Microsoft Teams の TURN リレーを悪用して C2 通信を正規インフラに紛れさせていた。問題は「Teams が危ない」ではなく、企業が止められない信頼済み SaaS 通信が攻撃者の隠れ蓑になること。出口で止める発想から、信頼済みの中の異常を見る発想へ。
関係ないとは思う。 でも、今日 Teams が異常に遅かった。
会議中に反応が重い。チャットの表示も遅い。 「また Microsoft 365 側の調子が悪いのか」と思いながら、少し気になって調べてみた。
そこで目に入ったのが、Teams を悪用したランサムウェア攻撃の話だった。
もちろん、今日の Teams の遅さとこの攻撃が直接関係しているとは思っていない。 ただ、読んでいて気になったのは別の点だ。
攻撃者は、Teams そのものを壊しているわけではない。 正規のコミュニケーションツールを使い、正規の通信に見せかけて、社内で身を隠そうとしている。
つまり、問題は「Teams が危ない」という単純な話ではない。 私たちが普段信頼している業務ツールそのものが、攻撃の足場にも、制御チャネルにもなり得るという話だ。
よく「入られたらおしまい」と言われる。 これは半分正しい。 正規の通信に化けた C2 は、出口では止めにくい。入口を抜かれた時点で、チャネルの勝負はかなり厳しい。
でも、半分は違う。
「入られた後に、どこまで触られるか」は、まだコントロールできる。
ここで、攻撃そのものをもう少し具体的に見ておきたい。なぜ「出口で止められない」のか、その仕組みがこの事件によく表れている。
BleepingComputer によると、DragonForce ランサムウェアの攻撃で、Microsoft Teams の TURN リレー基盤を悪用して C2 通信を隠すカスタムマルウェアが使われた。マルウェア名は Backdoor.Turn。Symantec は、Microsoft Teams の TURN リレーサーバーを悪用して C2 通信を隠した、初めて確認された実運用マルウェアだとしている。
ここで重要なのは、Teams の脆弱性が悪用された、という単純な話ではない。
攻撃者は、企業が信頼している SaaS の通信経路そのものを、隠れ蓑にした。
この攻撃を「Teams が危ない」とだけ見ると、かなり狭い。
本質は、企業ネットワークの中で、信頼済み SaaS が巨大な例外ルールになっていることだと思う。
Teams、Zoom、Slack、Google Workspace、Microsoft 365。 これらは止められない。止めると業務が止まる。
もちろん、今回確認されたのは Microsoft Teams の TURN リレー悪用であり、これらすべてが同じ手法で悪用されたという意味ではない。だが、企業が止められない信頼済み SaaS が、攻撃者にとって魅力的な隠れ蓑になるという構図は共通している。
だから攻撃者は、もはや怪しい外部サーバーへ堂々と通信するのではなく、企業が許可している通信経路に乗ってくる。
これは、昔ながらの「IP アドレスでブロックする」「ドメインで許可する」という発想の限界でもある。
通信先が有名ベンダーだから安全、とは言えない。 通信が TLS で暗号化されているから安全、でもない。 SaaS の正規機能が、攻撃者の通信トンネルになる。
TURN は、NAT やファイアウォールの背後にいる端末同士が直接通信できない場合に、中継サーバーを経由して通信させる仕組みだ。
Teams や Zoom のような会議・通話サービスでは、端末間で直接接続できないケースが普通にある。 そのため、TURN リレーは正規の機能として使われる。
今回の Backdoor.Turn は、この仕組みを悪用した。
報道によれば、マルウェアは匿名の Teams visitor token を取得し、正規の Microsoft TURN リレーを接続確立時に利用したうえで、攻撃者の C2 サーバーと通信していた。防御側から見ると、その通信は Microsoft Teams 関連の正規インフラに見えやすくなる。
つまり、問題はこうだ。
怪しい通信を探しているのに、通信先が Microsoft に見える。
Symantec が確認した攻撃は、2025 年 12 月に米国の大手サービス企業を標的にしたものとされる。
初期侵入は、SQL または MSSQL サーバー上の未知の脆弱性を悪用した可能性がある。侵入後、攻撃者は ZIP アーカイブをダウンロードし、正規の VirtualBox / DbgView 実行ファイルと悪意ある DLL を使ってサイドローディングを行った。
その後、攻撃者は永続化を強化し、不正ユーザー作成、Windows の LimitBlankPassword ポリシー悪用、ファイアウォールルール変更などを実施した。
さらに BYOVD、つまり Bring Your Own Vulnerable Driver の手法も使われた。Huawei、Topaz Antifraud、Tower of Fantasy、K7 Security など複数の脆弱なドライバを使い、カーネル権限でセキュリティツールを停止しようとしていた。
最終的には、データを窃取したうえで DragonForce ランサムウェアを展開し、システムを暗号化した。
なお、Backdoor.Turn は攻撃の初期侵入に使われたものではなく、ランサムウェア展開後に DbgView64.exe に注入されていたとされる。そのため、暗号化後の再侵入、継続アクセス、追加操作のために使われた可能性がある。
重要なのは、攻撃者が侵入後の制御チャネルとして、Teams の TURN リレーという信頼済み通信を悪用した点だ。
Backdoor.Turn は単なる通信トンネルではない。
報道では、以下のような機能が挙げられている。
つまり、攻撃者は侵入後の制御チャネルとして、Teams の通信に紛れる形で、内部偵察、認証情報窃取、追加操作につながる機能を持つバックドアを利用できる。 ただし、今回の事例では Backdoor.Turn が初期侵入からランサムウェア展開までの全工程を担った、という意味ではない。
これはかなり厄介だ。
なぜなら、セキュリティ担当者が「Microsoft Teams の通信だから業務通信だろう」と見逃す可能性があるからだ。
この攻撃から得られる教訓は、単純な IOC ブロックではない。
もちろん Symantec は IoC を公開しており、該当する環境では確認すべきだ。 ただし、この種の攻撃は IoC だけでは追いつかない。
重要なのは、以下のような振る舞いを見ることだ。
特にサーバー環境では、「Teams の通信が出ること自体が不自然」というケースが多い。
業務端末では Teams が普通でも、SQL Server やファイルサーバーから Teams TURN 通信が出ていたら、それは別の意味を持つ。
通信そのものは止められない。では、何を制御できるのか。
止められるのは通信ではなく、攻撃者が触れる範囲だ。
今回の攻撃者は、内部偵察・認証情報窃取・横展開まで進めようとしていた。 ここで効いてくるのが、データアクセスの最小化だ。
たとえば OneDrive や SharePoint。 これは今回の攻撃で OneDrive や SharePoint が悪用されたという意味ではない。 ただ、Microsoft 365 環境では、侵害されたユーザーや端末の権限が残っていれば、これらのデータにも正規アクセスとして到達され得る。通信としては怪しく見えにくい。
だからこそ、アクセスできる範囲そのものを絞っておく。
最小権限は、侵入を防ぐ仕組みではない。 侵入された後、攻撃者がどこまで行けるかの天井を決める仕組みだ。
入口を塞ぐ努力をしても、いつかは抜かれる。 そのときに「抜かれた一台から、どこまで広がるか」を小さくしておく。
「入られたらおしまい」を、「入られても、ここまで」に変える。 それが最小権限の役割だ。
ここで少し先の話をすると、この問題は AI エージェント時代にもそのまま来る。
AI コーディングエージェント、MCP サーバー、SaaS 連携、RAG、ブラウザ操作エージェント。 これらは、外部サービスと通信することが前提になっている。
そして企業は、開発効率や業務効率のために、それらの通信を許可していく。
そのとき攻撃者は、怪しい C2 サーバーではなく、正規の SaaS、正規の API、正規の連携基盤に紛れてくる。
Teams の TURN 悪用は、その先取りに見える。
問題は「マルウェアが外に出ているか」ではなく、正規の通信経路が攻撃者の制御経路に変わっていないかだ。
これが Teams の MCP サーバーや Microsoft 365 連携エージェントに広がると、さらに厄介になる。 いまは「Teams の通信に見える C2」だが、次は「Teams の正規 API 操作に見えるエージェント操作」になる。 メッセージを読む、投稿する、ファイルを探す、会議情報を見る。これらがエージェント経由で正規操作として実行されるなら、通信先だけを見ても異常は分からない。 問題は、誰が、どの権限で、何を読み、何を実行したかに移る。
今回の Backdoor.Turn は、ランサムウェア攻撃の隠密化が次の段階に進んだことを示している。
攻撃者は、怪しいドメインを使うだけではない。 企業が止められない SaaS、信頼しているクラウド、業務に必要な通信経路を使う。
だから防御側も、発想を変える必要がある。
「この通信先は Microsoft だから安全」ではなく、 「この端末が、このタイミングで、この種類の通信をするのは自然か」と見る。
セキュリティは、信頼済みリストを作る仕事ではなくなっている。 信頼済みの中で起きる異常を見つける仕事になっている。
Teams の TURN リレー悪用は、その象徴的な事件だと思う。
Aikido Community Japan
公開日: 2026/6/17
最終更新: 2026/6/16
セキュリティの最新情報をお届けします。