Cisco Talosが新たなマルウェア「msaRAT」の分析結果を公開

サイバーセキュリティー
2026.07.28

2026年7月23日、Cisco Systemsの脅威インテリジェンス部門であるCisco Talosは、Chaosランサムウェアグループが使用する新たなマルウェア「msaRAT」に関する詳細な技術レポートを公開しました。
Chaos ransomware’s msaRAT: Living off the browser to build a covert C2 channel

Chromeを悪用した新たなC2通信手法とは

Cisco Talosによれば、このマルウェアは従来のRATとは異なり、自ら外部と通信することはありません。

代わりに、Google ChromeやMicrosoft Edgeをヘッドレスモードで起動し、“Chrome DevTools Protocol（CDP）”を利用してブラウザを操作します。

そして、Cloudflare WorkersやWebRTC、TURNサーバーなどの正規サービスを組み合わせることで、攻撃者との通信（C2通信）を通常のブラウザ通信へ紛れ込ませるという、極めて巧妙な設計になっています。

Cisco Talosは、この手法を…

Living off the Browser

という考え方として紹介しています。これは、Windowsの正規機能を悪用する「Living off the Land（LotL）」を、ブラウザの世界へ拡張したような攻撃デザインと考えることができます。

私が本当に興味を持ったのは別の点でした。

Cisco Talosは、今回のレポートでChromeを悪用した新たな攻撃デザインを明らかにしました。

もちろん、その技術内容は非常に興味深いものです。

しかし、私が最も興味を抱いたのは、攻撃手法そのものではありません。

私が知りたかったのは、Cisco Talosが、この攻撃デザインをどのように発見したのかという点です。

サイバー攻撃は、世界中で毎日のように新しい手法が生み出されています。

その中から、まだ広く知られていない攻撃を見つけ出し、分析し、世界へ向けて発信する。

それは決して簡単なことではありません。

だからこそ私は、“「Cisco Talosは、どのような視点で攻撃者を見ているのだろう。」”という疑問を抱きました。

まずは、Cisco Talosが公開した、この攻撃を理解してみましょう。

Cisco Talosが公開したレポートには、マルウェアがどこで発見されたのか、あるいは最初のサンプルをどのように入手したのかまでは記載されていません。

そのため、現時点で公開されている情報だけから発見の経緯を断定することはできません。

そこで本記事では、まずCisco Talosが公開した技術内容を一緒に読み解き、そのうえで最後に「Cisco Talosはなぜ、この攻撃デザインへ辿り着けたのか」という問いについて考えてみたいと思います。

C2（Command and Control）とは？

企業のパソコンへ侵入できたとしても、それだけでは攻撃は成功したとは言えません。

攻撃者は侵入した後も、感染した端末へ命令を送り続ける必要があります。

例えば、

  • ファイルを盗み出す
  • 社内ネットワークをさらに調査する
  • 別のマルウェアを送り込む
  • ランサムウェアを実行する

こうした操作は、一度侵入しただけではできません。

そのため攻撃者は、感染した端末と自分たちを結ぶ通信経路を確保します。

この通信経路を、C2（Command and Control）と呼びます。

言い換えれば、C2とは“攻撃者と感染端末を結ぶ「遠隔操作用の通信回線」”です。

攻撃者にとって、C2通信は「命綱」です。

C2通信が遮断されれば、攻撃者は感染した端末を自由に操作できなくなります。

つまり、攻撃者にとってC2通信は命綱とも言える存在です。

しかし、その一方で、防御側も真っ先に探すのが、このC2通信です。

不審な通信を検知し、遮断することで、被害の拡大を防ごうとするからです。

つまり…

攻撃者は見つからない通信を求めます。

防御側は見つけやすい通信を探します。

ここで、攻撃者と防御側の知恵比べが始まります。

Cisco Talosが注目したのも、この「通信」でした。

従来のマルウェアは、自ら攻撃者のサーバーへ接続し、命令を受け取ることが一般的でした。

しかし、今回Cisco Talosが分析したmsaRATは、その常識を少し変えました。

通信する役割を、自分ではなくGoogle Chromeへ任せたのです。

一見すると、単なる役割分担の違いに思えるかもしれません。

しかし、この発想こそが、今回のレポートの核心でした。

なぜなら、防御側は「マルウェアが通信すること」を前提に監視を行っています。

ところが、実際に通信しているのが普段から利用されているGoogle Chromeだったとしたらどうでしょう。

通信そのものは、ごく普通のブラウザ通信に見えてしまう可能性があります。

そこでCisco Talosは、このマルウェアがどのようにChromeを操作し、どのように通信を成立させていたのかを詳しく分析しています。

それでは、その仕組みを順番に見ていきましょう。

Chromeを遠隔操作する「Chrome DevTools Protocol（CDP）」

まず理解しておきたいのが、“Chrome DevTools Protocol（CDP）”です。

名前だけ聞くと難しく感じますが、CDPはGoogle Chromeに標準で備わっている開発者向けの機能です。

本来は、Webサイトの動作確認やブラウザの自動テスト、デバッグなどを行うために利用されます。

つまり、Chromeの弱点（脆弱性）を突いたわけではありません。

Chromeが正規に備えている便利な機能を利用したという点が重要です。

Cisco Talosによれば、msaRATはこのCDPを利用してChromeを裏側から操作し、攻撃者との通信を実現していました。

画面を表示しない「ヘッドレスモード」とは？

読者の多くは、「Chromeを起動した」と聞くと、ブラウザの画面が表示されることを想像します。

しかし、Cisco Talosのレポートで登場するChromeは少し違います。

“画面を表示しないまま動作する「ヘッドレスモード（Headless Mode）」”で起動していたのです。

ヘッドレスモードは、本来、Webサイトの自動テストやシステム開発などで利用される開発者向けの機能です。

つまり、CDPと同じく、これもGoogle Chromeに標準で備わっている正規機能です。

利用者にはChromeが起動していることを意識させることなく、バックグラウンドでブラウザを動作させることができます。

Cisco Talosによれば、msaRATはこのヘッドレスモードを利用し、CDPを通じてChromeを操作していました。

その結果、“「通信しているのはマルウェアではなく、Chrome」”という状態を作り出していたのです。

しかし、ここで新たな疑問が生まれます。

Chromeが通信していたことは分かりました。

では、そのChromeは誰と、どのような方法で通信していたのでしょうか。

Cisco Talosのレポートを読み進めると、その先には

といった、いずれも正規のインターネットサービスや通信技術が登場します。

これらを巧みに組み合わせることで、攻撃者はC2通信を通常のブラウザ通信へ紛れ込ませようとしていました。

それでは次に、それぞれがどのような役割を果たしていたのかを見ていきましょう。

Chromeは、どこと通信していたのでしょうか。

まず最初に登場するのが「Cloudflare Workers」でした。

Cisco Talosのレポートによれば、Chromeが最初に接続していたのは、Cloudflare Workersでした。

Cloudflare Workersは、Cloudflare社が提供している“サーバーレス実行環境（Serverless Platform）”です。

簡単に言えば、Cloudflareが世界中に展開するサーバー上でプログラムを実行できるクラウドサービスです。

本来は…

  • Webアプリケーションの開発
  • APIの構築
  • Webサイトの高速化
  • システムの自動処理

…などを目的として、多くの企業や開発者に利用されています。

つまり、攻撃者専用のサーバーではなく、世界中で利用されている正規のクラウドサービスなのです。

ここで一つ考えてみてください。

もし企業のネットワークからCloudflareへの通信があったとして、それだけで「サイバー攻撃だ」と判断できるでしょうか。

おそらく、多くの企業では難しいでしょう。

Cloudflareは日常的に利用されているサービスであり、その通信自体は決して珍しいものではありません。

Cisco Talosによれば、msaRATはこうした正規サービスへ通信を紛れ込ませることで、不自然さを抑えようとしていました。

しかし、Cloudflare Workersは攻撃者との最終的な通信相手ではありません。

Cloudflare Workersは、この通信経路の最初の中継地点に過ぎなかったのです。

では、その先でChromeは、誰と通信していたのでしょうか。

Cisco Talosのレポートを読み進めると、そこにはWebRTCという、さらに興味深い技術が登場します。

WebRTCとは？

WebRTC（Web Real-Time Communication）は、Webブラウザ同士がリアルタイムに通信するための技術です。

例えば…

  • オンライン会議
  • 音声通話
  • ビデオ通話
  • 画面共有

…など、多くのWebサービスで利用されています。

ZoomやGoogle Meet、Microsoft Teamsなどを利用したことがある方も多いと思います。

実は、こうしたリアルタイム通信を支えている技術の一つがWebRTCです。

つまり、これもまた世界中で日常的に利用されている正規の通信技術なのです。

Cisco Talosが注目したのは、この使い方でした。

WebRTCは本来、人と人がリアルタイムで会話するための技術です。

ところがCisco Talosによれば、msaRATはこの仕組みを利用し、攻撃者との通信経路として応用していました。

つまり…

本来は人同士を結ぶための通信技術が、

攻撃者と感染した端末を結ぶ通信路として利用されていたのです。

もちろん、これはWebRTCそのものに問題があるという意味ではありません。

重要なのは、正規の通信技術が、本来とは異なる目的で利用されていたという点です。

しかし、ここで一つ問題が残ります。

WebRTCは、ブラウザ同士が直接通信する仕組みとして設計されています。

しかし実際のインターネットでは…

企業のファイアウォールやNAT（Network Address Translation）の影響により、ブラウザ同士がそのまま通信できないケースも少なくありません。

そこで登場するのが、TURNサーバーです。

Cisco Talosのレポートでは、このTURNサーバーも通信経路の一部として利用されていました。

それでは、このTURNサーバーがどのような役割を果たしていたのかを見ていきたいと思います。

TURNサーバーとは？

TURN（Traversal Using Relays around NAT）は、WebRTCによる通信を中継するためのサーバーです。

簡単に言えば…

「直接つながらない通信を中継してくれる役割」

…を担っています。

本来は…

「ビデオ会議がうまくつながらない」

「音声通話が途中で切れてしまう」

…といった問題を防ぐための仕組みとして利用されています。

つまり、TURNサーバーもまた、インターネットを便利にするための正規の技術です。

Cisco Talosによれば、msaRATは、このTURNサーバーも通信経路の一部として利用していました。

なぜ、ここまで複雑な通信経路を構築したのでしょうか。

ここまで見てきたように、msaRATは単純に攻撃者のサーバーへ接続するような設計ではありませんでした。

Chromeを起動し、

Cloudflare Workersを経由し、

WebRTCを利用し、

必要に応じてTURNサーバーまで利用する。

一見すると、非常に遠回りな通信経路にも見えます。

では、なぜ攻撃者は、このような複雑な構成を選択したのでしょうか。

「見つからないこと」が最優先だったのかもしれません。

近年、多くの企業ではEDR（Endpoint Detection and Response）を導入し、パソコン上で動作するプログラムを常に監視しています。

従来のRATが直接インターネットへ通信を開始すれば…

「見慣れないプログラムが外部と通信している」

…という異常として検知される可能性があります。

しかし、Chromeが通信していた場合はどうでしょうか。

Chromeは、多くの企業で毎日利用されているソフトウェアです。

Webサイトを閲覧し、クラウドサービスへ接続し、動画を再生する。

こうした通信は、ごく日常的なものです。

つまり、攻撃者は「怪しい通信」を隠すのではなく、「普通の通信」の中へ溶け込ませようとしたのかもしれません。

「マルウェアが通信する」のではなく、「ブラウザが通信する」

ここが、Cisco Talosのレポートで最も印象に残った点でした。

従来の発想では、「マルウェアが外部と通信する」ことが当たり前でした。

しかし、msaRATでは、通信している主体はChromeです。

マルウェアは、そのChromeを裏側から操作しているだけでした。

通信という「目立つ仕事」を、日常的に使われているブラウザへ任せてしまう。

この発想は、防御側にとって非常に厄介です。

そして、私は一つの変化を感じました。

今回の事例を見ていて感じたのは、攻撃者は、新しいマルウェアを作ろうとしているのではなく、

既に社会へ広く普及している技術を、どう組み合わせれば見つかりにくくなるのか。

その設計に力を注ぎ始めているように見えることです。

Cloudflare Workersも、

WebRTCも、

TURNサーバーも、

いずれも社会に欠かせない正規の技術です。

だからこそ、それらを全面的に遮断することは現実的ではありません。

攻撃者は、その「止められない技術」の中へ、自らの通信を紛れ込ませようとしているようにも見えます。

そして、最後に残る疑問があります。

ここまで通信経路を理解すると、私の中には一つの疑問が残りました。

Cisco Talosは、この複雑な攻撃デザインを、どのようにして解き明かしたのでしょうか。

今回のレポートで公開されていること、公開されていないこと

Cisco Talosが公開したレポートには、

など、技術的な解析結果が非常に詳しくまとめられています。

一方で…

  • 最初に何をきっかけとして調査が始まったのか。
  • 最初にどのような挙動へ着目したのか。
  • テレメトリによる検知だったのか。
  • インシデントレスポンスの過程で発見されたのか。
  • 顧客から提供されたサンプルを解析したものなのか。
  • どのような調査プロセスを経て、この通信経路を解き明かしたのか。

こうした調査の出発点や解析の経緯については、今回の公開レポートでは説明されていません。

そのため、本記事でも、それらについて推測や断定は行わず、公開されている事実を基に考察を進めています。

公開されたレポートからは、解析結果を知ることはできます。

しかし…

最初に何を手掛かりとしたのか。

きっかけは？

どこから違和感を覚えたのか。

どのような思考で、この通信経路を一つずつ復元していったのか。

そこまでは書かれていません。

もちろん、私には分かりません。

ですが、攻撃者が「見つからない設計」を追求するように、Cisco Talosの研究者たちもまた、「見つけるための思考」を日々磨き続けているのではないかと考えるようにしています。

サイバー攻撃は、単なる技術の競争ではありません。

攻撃者の設計思想と、防御側の分析力がぶつかり合う、知の攻防でもある。

今回のレポートは、そのことを改めて考えさせてくれる内容だと思いました。

タイトルとURLをコピーしました