最初の一歩で止まる、九段階の攻撃
Microsoftは、ヘルプデスクを装った外部からのTeamsメッセージに始まり、Rcloneがネットワーク共有を静かに持ち出して終わる、九段階のランサムウェア攻撃チェーンを記録しました。そのうち八段階は、ホストのオペレーティング・システムを必要とします。タブを相手にして動くものは、一つもありません。
Microsoftは今週、九段階の攻撃チェーンを公開しました——偽のヘルプデスクからのTeamsメッセージ、Quick Assistのセッション、署名付きベンダーバイナリを介したDLLサイドロード、ネットワーク越しのWinRM、そして攻撃者のクラウドストレージへと向かうRclone。九段階のうち八段階は、ホストのオペレーティング・システムが本物のデスクトップであることを前提にしています。使い捨てのVMの中で動くブラウザタブは、そのどれでもありません。
2026年4月20日、Microsoftの脅威分析チームは、複数のランサムウェア・アフィリエイトが現在実運用で使っている九段階の攻撃チェーンの解説を公開しました。最初の一手はソーシャルなものです。外部テナントからのメッセージがMicrosoft Teamsに届き、差出人はITを名乗り、「アカウントの問題」を解決するため、あるいは「セキュリティ更新をインストールする」ために、リモートサポート・セッションの開始を求めてきます。締めくくりの一手は金銭的なものです。正当なクラウド同期ユーティリティであるRcloneが、ファイルサーバーを攻撃者の管理するオブジェクトストレージへと流し出している一方で、後に残ったものをランサムウェアが暗号化していきます。
Microsoftの表現はそのまま引用する価値があります。「脅威アクターは、外部とのMicrosoft Teamsのコラボレーションを悪用し、ITあるいはヘルプデスク担当者になりすまして、ユーザーにリモート支援のアクセスを許可させる例が増えつつある」。目新しいのはソーシャル・エンジニアリングの手口そのものではありません——ヘルプデスクを装う手口はヘルプデスクと同じだけ古いものです——新しいのは「配信面」の方です。Teamsはあらゆる企業デスクトップに座り、常時サインインしたまま、起動時に自動で立ち上がり、外部メッセージが社内メッセージと同じに見えるような通知APIを備えた、コラボレーション・クライアントです。2026年において、それはメールよりも優れたフィッシング経路なのです。
チェーンの端から端まで。
Windowsマシン上で、九段階が実際に何をするのかを示します。番号はMicrosoftのもので、平易な言葉による説明は私たちのものです。
このチェーンは効率的で退屈です——それこそが2026年における優れたランサムウェアのトレードクラフトの姿です。ここには一つもゼロデイがありません。Quick AssistはWindowsに付属するMicrosoft純正のリモートサポート・ツールです。PowerShellは純正の管理用シェルです。DLLサイドロード——攻撃者の管理下のライブラリを、正規に署名されたプログラムの隣に落とし、その署名付きプログラムに悪意あるコードを読み込ませる手口——は、もう20年の歴史があります。WinRMは、ドメイン管理者がWindowsの群れを管理するために想定されているやり方です。RcloneはHomebrewから入れられるオープンソースのクラウド同期ユーティリティです。この攻撃は、サポートされ、署名され、IT部門に祝福されたプリミティブでできています。それが、従来のエンドポイント・ツールでは検出しにくい理由です。個々のステップはどれも、IT部門が意図的にやっていることに見えるのです。
積極的な主張——チェーンを最初の段階で断ち切る。
では、同じチェーンで、第1段階がネイティブなWindowsデスクトップ・クライアントに現れる通知ではなく、ブラウザタブの中に現れる通知だったら、どうなるか考えてみてください。それも、Bromureのブラウザタブの中に。永続的なディスクもなく、ドメイン参加もなく、Windowsのバイナリもなく、WinRMリスナーもなく、Rcloneもなく、サイドロードする先のAdobe Readerもなく、ホストと共有されたファイルシステムもなく、ウィンドウを閉じれば破棄される——そんな使い捨てのLinux VMの中で動くタブです。
第1段階は、それでも着地します。外部のTeamsテナントはDMを送れますし、ユーザーはメッセージを目にします。ソーシャル・エンジニアリングの圧力も、そのままそこにあります。ヘルプデスクを自称する見知らぬ相手がチャット画面に「あなたのマシンにセキュリティ更新をインストールする必要があります。Quick Assistのセッションを始めさせてください」とタイプするのを、Bromureが止めるわけではありません。
しかし、第2段階で止まります。ブラウザタブはQuick Assistを起動できません。なぜならQuick Assistはネイティブなバイナリであり、タブはLinux VM内のChromiumウィンドウで、そこにはQuick Assistはインストールされていないし、インストールする手段もないし、Bromureを動かしているデバイスの向こう側にいるWindowsマシンへのIPCチャンネルも存在しないからです。そしてチェーンが厳密に順序どおりである——後続のあらゆる段階が一つ前の段階の成果物を必要とする——ということは、第2段階で首を落とせば、第3〜9段階は永久に起きないということを意味します。
この図には「Bromureを使えばランサムウェアに免疫がある」という、強すぎる読み方を誘う誘惑があります。それは主張ではありません。主張はもっと狭く、その狭い版のほうが誠実で、役に立ちます。
境界とは実際には何なのか。
ここで仕事をしているのは、巧妙なTeams専用フィルタではありません。それはBromureがWebコンテンツを動かす仕組みに備わった、構造上の性質です。Bromureの各タブは、あなたのMac上で、それ自身の使い捨てLinux VMの中で動きます。ユーザーに見えているブラウザはChromiumで、そのLinuxゲストの中で動いています。タブはVMで区切られ、ホストはハイパーバイザーで区切られています。タブを閉じればVMは破棄され、新しいタブを開けば、クリーンなディスクイメージから新しいVMが作られます。
第2段階で攻撃者が「Quick Assistのセッションを受け入れてください」と言うとき、その呼び出そうとしている仕組みは、境界の向こう側には存在しません。LinuxゲストにはQuick Assistがありません。たとえユーザーが完全に信頼しているWebページであっても、ゲストからホストへ手を伸ばして、macOSやWindowsのネイティブ・バイナリを起動させる手段はありません。そのためのブリッジは存在しませんし、もしあれば、このアーキテクチャの目的そのものが崩れてしまいます。攻撃者のチェーンは一揃いの能力——ネイティブ・アプリの起動、永続ファイルシステムへの書き込み、署名付きベンダー・バイナリの隣へのDLL読み込み、WinRMセッションの開設、ホストの資格情報の読み取り——に依存しており、タブVMは構造上、そのどれも持ちません。
これはTeamsのヘルプデスク脅威のために特別に追加した機能ではありません。それは、ブラウザのゼロデイ、悪意ある拡張機能、そして一般の情報窃取マルウェアに対してBromureを有用にしているのと、まったく同じ性質です。ユーザーが何をクリックしたかを気にするのは、チェーンの中で第1段階だけです。それ以降のすべての段階は、ユーザーのデスクトップを必要とします。ブラウザをデスクトップとは別のコンピュータに置けば、チェーンの話はユーザーの判断の話ではなくなり、マシンのアーキテクチャの話になるのです。
これが解決しないこと。
もし同じユーザーが、ネイティブなデスクトップ・クライアントとしてのMicrosoft Teams——macOSのMicrosoft Teams.app、あるいはWindowsのデスクトップ・クライアント——を、Bromureの外で、同じユーザーアカウントにサインインした状態でインストールしているなら、外部テナントからのDMはホストに着地します。その時点で、私たちは図の上段Aに戻っています。第1段階はネイティブ通知。第2段階は、ユーザーが本物のデスクトップでQuick Assistのセッションを受け入れること。タブVMは、この物語には一度も登場しません。Bromureは、Bromureの中で動いていないものを守ることはできません。
同様に:組織のITポリシーが、テナント・レベルで外部TeamsのDMをブロックしているなら——それはMicrosoftの解説が推奨していることでもあります——どちらの世界でも、第1段階はユーザーに届かず、アーキテクチャ論は意味を失います。それが正しい最初の修正です。Bromureは、最初の修正が適用されなかったケース、ユーザーが個人デバイスを使っているケース、ポリシーに例外枠があるケース、あるいは攻撃者がそれを強制していないテナントを見つけたケースのための防御なのです。
ブラウザ習慣が変えるもの
teams.microsoft.comをBromureのタブで開けば、第1段階はあなたのMac上の使い捨てLinux VMに移ります。なりすましが送ってくる「サポートを受け入れる」リンクをクリックしても、相手が望んだツールは、クリックの着地先には存在しません。要求は失敗します。能力がそこにないからです。
ネイティブ・クライアントがしてくれないこと
もしすでにTeamsのデスクトップ・アプリをインストールしてサインインしていれば、DMはそちらに届き、ホストはMicrosoftが記述した通りに露出します。デスクトップ・クライアントを削除する、あるいは専用の業務マシンに追いやるというのは、Bromureが可能にする行動変化であって、押しつけるものではありません。
Bromureが止めないもの
Bromureタブ内のフォームに会社のパスワードを入力するよう話しこまれたユーザーは、そのパスワードをやはり失います。ブラウザのフィッシング対策はそのフォームを捕まえようとしますが、粘り強いソーシャル・エンジニアリングの対象者は、そうした守りをいくらでもかいくぐれます。資格情報フィッシングと、VM境界の防御は、別々の問題です。
主張の正直な形
ブラウザTeamsを仕事習慣とするユーザーにとって、Bromureは九段階の侵入を一段階の会話に変えます。ネイティブ・クライアントを仕事習慣とするユーザーにとって、Bromureはこの攻撃について何も変えません。短く、もっと大声な記事ではなく、この記事を書いて公開する理由のすべてが、そこにあります。
なぜブラウザ習慣を守る価値があるのか。
主だった企業向けチャット・クライアント——Teams、Slack、Discord、Zoom——はどれも、同じURLでネイティブのデスクトップ・アプリと、Webアプリの両方を提供しています。ほとんどの人がそこで行うこと——メッセージの読み書き、検索、ファイル添付、通話——の大半に対して、Web版は機能的にほぼ完全です。Web版は起動時に自動で立ち上がりません。Web版は、攻撃者が探りを入れられる永続プロセスをホスト上に維持しません。Web版は、過去に自分自身のサプライチェーンインシデントの媒介となったアップデート・チャネルを同梱していません。そして、問題のブラウザがBromureである場合に限って、Web版は、ユーザーの本物のマシンとファイルシステムを共有しないコンピュータの中で動いているのです。
ここでの提案は、すべてのユーザーが明日Teamsデスクトップ・アプリをアンインストールすべきだ、というものではありません。そうではなく、「Web中心」の選択肢はすでに存在し、何年も静かに容認されてきたものであり——Microsoftが4月20日に記述した内容を踏まえれば——デスクトップ・クライアント限定の機能を特に必要としていないユーザーにとって、いまや実質的に安全な選択肢である、ということです。Bromureはこの選択肢を意味のあるものにします。通常のChromeウィンドウの中のWeb Teamsセッションは、それでもなおMac上の他のすべてのプログラムとファイルシステムを共有するセッションです。Bromureタブ内のWeb Teamsセッションは、そうではありません。
一つの物語、そしてそれが変えるもの。
Microsoftの九段階の解説は、この種のものとして最後のものではありません。その「形」——外部のソーシャル・チャネル → リモートアクセス・ツール → 偵察 → 署名付きバイナリによる永続化 → 横展開 → 持ち出し——は、どのチャット・クライアントから始まるかに関係なく、人間が操作する現在のランサムウェア侵入の大多数が採る形です。コラボレーション・クライアントは、新しいメールの受信箱です。「サポート・セッションを受け入れるためにクリック」は、新しい「マクロを有効化するためにクリック」です。その後の「手とキーボード」で行われる作業こそが、攻撃そのものです。
ユーザーの日々の仕事が、チャット・クライアントとファイルサーバーが同じオペレーティング・システムを共有するマシンで行われているのなら、攻撃者は残り八段階をこなすために、そのオペレーティング・システムに片足を踏み入れるだけで足ります。ユーザーの日々の仕事が、チャット・クライアントが抜け出せないVMの中で動くブラウザの中で行われているのなら、攻撃者は仕事を終わらせるためにまったく別の一揃いのプリミティブを必要とします——現世代のランサムウェアの手引書には、そのプリミティブはありません。
それは免疫ではありません。最初の段階での断頭です。Bromureをインストールして、業務チャットのうちそうできる部分についてはネイティブ・クライアントの代わりにteams.microsoft.comをBromureの中で使い、次の九段階のチェーンは攻撃者の側の問題にしてあげてください。