Teamsを悪用した“偽旗ランサム”──MuddyWaterが画面共有で認証情報を奪取し、RMMで居座る、暗号化はしないです

今日の深掘りポイント

• 協働基盤そのもの（Microsoft Teams）が初動の土俵になり、画面共有と“制御権の付与”を梃子に認証情報が抜かれる設計です。
• ランサムを装うが暗号化は行わず、汎用RMMで長期居座りと流出・恐喝に軸足を置く“偽旗”手口です。ランサム特有の検知シグナルが出ないため、組織側の検知網が素通りしやすいです。
• 国家支援×サイバー犯罪のハイブリッド化により、帰属（attribution）を攪乱し、インシデント対応の規範が揺さぶられる懸念が強まっています。
• 防御の焦点は「Teamsの外部テナント接続ポリシー」と「RMMガバナンス」。EDRやメール中心の“従来ランサム”前提から、ID・コラボ・RMMの三位一体へ舵を切るべき局面です。
• 現場判断に即した優先度付けとして、直近の設定変更（72時間）、構成の是正（2週間）、運用の再設計（90日）の三段ロールアウトを提案します。

はじめに

“ファイル暗号化→身代金”の図式に合わせた防御は、いまや攻撃者側の意図的な死角になりつつあります。報道によれば、イラン関連のMuddyWaterがMicrosoft Teamsを入口に、画面共有を介したソーシャルエンジニアリングで認証情報を奪い、汎用のリモート管理ツール（RMM）で粘り強く居座る作戦を展開したとのことです。しかもランサムを装いつつ、実態は暗号化しない“偽旗”でした。国家支援とサイバー犯罪の手法が混じり合うことで、観測されるシグナルは“ありふれた犯罪ツールのノイズ”に溶け込み、帰属を鈍らせます。
コラボレーションが競争力の源泉であるほど、Teamsの“外”との付き合いは切れません。だからこそ、コラボとID、RMMを横串にした運用の見直しが、今このタイミングで要るのだと強く感じます。

参考: 本件はRapid7の観測に基づくと報じられています。詳細は二次報道ですが、公開情報に依拠しています。The Hacker Newsの報道です。

深掘り詳細

事実関係の整理（公開報道ベース）

• 攻撃者はMicrosoft Teamsを用い、外部から従業員にコンタクト。画面共有の場で“制御権の付与”やログイン操作を誘導し、認証情報を奪取したと報じられています。
• 侵害後はファイル暗号化を伴う典型的ランサムの流れに入らず、データ流出と長期的な持続性確保を優先。汎用RMMを投入して遠隔操作・横展開・再入場の足場を固めたとされています。
• ランサムのレトリックやツール選択を“偽旗”として活用し、国家支援色を薄める意図が読み取れる構図です。一般流通のサイバー犯罪ツールを前面に出すほど、帰属は困難になります。
  出典はいずれも上記の公開報道です。

Packet Pilotの視点（なぜこれが厄介か）

• 協働ツールは“身内空間”の認知バイアスを突ける
  Teamsは“仕事相手と話す正規の場”という心理的前提を持ちやすいです。画面共有や制御権の授受に“正当な理由”を与えられると、ユーザー教育だけでは踏みとどまるのが難しいです。
• ランサム特有の“騒音”が出ないと、検知はID/RMM側に偏移する
  暗号化の急峻なI/Oや大量の拡張子変更といった従来シグナルが立ちません。代わりに見えるのは“RMMの導入・異常な外向き制御チャンネル・正規アカウントの悪用”です。SOCは検知ロジックの重心を移す必要があります。
• “偽旗”は法務・広報・経営判断を惑わせる
  サイバー犯罪の外形を纏いつつ国家支援の目的を達する設計は、対外説明や当局連携の初動を鈍らせます。技術対応と同時に、シナリオベースの社内意思決定手順の明確化が欠かせません。
• RMMは“運用の必需品”だからこそ利敵化の痛手が大きい
  現場が正当な理由で使うRMMと、攻撃者が持ち込むRMMは、プロセスや通信先がほぼ同一です。よって“許可されたRMM以外は原則禁止”というポリシーと監査の整備が成否を分けます。

脅威シナリオと影響

以下は公開情報を踏まえたうえでの仮説シナリオです。各TはMITRE ATT&CKのテクニックを示します。

• シナリオA：Teams外部チャット→画面共有での誘導→認証情報奪取→RMM設置→流出・恐喝
  • 初動: Teamsで外部から接触し、会議・画面共有を設定（T1566.003 Spearphishing via Service）。会話の流れで“制御権の付与”やログイン操作を要請（T1204 User Execution）。
  • 資格情報: 画面共有下でSSO/社内ポータルへのログイン操作を誘導し、パスワードやワンタイムコードを窃取、あるいは正規セッションを攻撃者が操作（T1078 Valid Accounts）。
  • 居座り: 正規RMMをダウンロード・登録して持続化（T1219 Remote Access Software）。必要に応じてスケジュールや自動起動で再入場（T1053 スケジュール実行などの一般的手口）。
  • 流出・恐喝: ファイル暗号化は行わず、データを選択的に持ち出し（T1567 Exfiltration Over Web Services/Cloud）、後日恐喝や“脅迫状のみ”提示で偽旗を演出（T1036 Masqueradingの文脈）。
• 影響評価（実務観点）
  • 営業・法務リスクが即時顕在化します。暗号化がないため“止まっている系の被害”は目立たず、気づいた時には取引先・役職者の機微データが選別流出している、という最悪パターンになりやすいです。
  • インシデント特定の難易度が上がります。ログには“外部とのTeams会話・正規アカウント操作・正規RMM通信”しか写らないため、従来のランサムIOCでは網にかかりにくいです。
  • サプライチェーン伝播の懸念が高いです。Teamsの外部接続は取引網の“高速道路”であり、域外テナントに自然に伸びます。単一組織の境界防御発想では収まりません。

メトリクスからの示唆（総合所見）
即応性と実効可能性が高く、信頼度も高い類型に映ります。すなわち“今、目の前の運用を変えるだけで被害確率と影響を下げられる”一方で、放置すれば被害顕在化の速度も早い、ということです。現場は“Teams外部接続ポリシーの見直し”と“RMMの許可制・検知制”に当面の予算と時間を振り向けるべきフェーズにあります。

セキュリティ担当者のアクション

“いまできること（72時間）–“次にやること（2週間）–“仕組みを変えること（90日）”の三段で具体化します。製品名は自組織の環境に読み替えてください。

• 72時間でやること（遮断と可視化）

  • Teams外部接続の即時見直し
    • 既定の外部テナントとのチャット/会議を禁止し、業務上必要なドメインのみ許可リスト方式にします。
    • 画面共有における“外部からの制御権要求/付与”を会議ポリシーで禁止します（外部との会議テンプレートを分離するとなお良いです）。
    • URL防御（Safe Links等）をTeamsに適用していない場合は直ちに有効化し、ブロック時はユーザーにも見える警告を出します。
  • RMMガバナンスの暫定ルール
    • 自組織で“許可されたRMMの製品名・配布元・インストール方法・通信先FQDN/ASN”を一枚にまとめ、許可以外は原則ブロック（EgressのFQDN制御、アプリケーション制御）します。
    • EDR/AVで“RMM系プロセスの新規インストール・サービス登録・自動起動”を高優先のアラートに昇格します。
  • 身元・セッションの強制再評価
    • 重要ユーザー（財務、人事、経営、営業責任者）についてサインイン強制再認証・リフレッシュトークンの失効を実施します。
    • 直近7〜14日の外部Teams会議ログ（可能な範囲）から、未知ドメインとの接触・画面共有があったユーザーを優先スクリーニングします。

• 2週間でやること（構成の是正と運用の明文化）

  • ID境界の強化
    • フィッシング耐性の高いMFA（FIDO2/証明書/番号一致）へ優先ロールアウトし、SMS/TOTPのみのアカウントを縮退します。
    • 条件付きアクセスで“社内からのTeams利用でも、外部テナントとの会話/会議は準拠デバイス限定”に縛ります。
  • コラボのセーフガード
    • 外部会議は“主催者テンプレート”（ロビー必須、発表者制限、外部制御権禁止）を標準化し、テンプレ違反をレビュー対象にします。
    • 外部からの“制御権リクエスト”の扱いを社員教育に組み込み、“断るのが標準”にします（実演動画が有効です）。
  • 監視の観点追加
    • “新規RMMの導入/登録”“未知のRMMクラウドへの長時間アウトバウンド”“正規アカウントによる深夜帯の横展開”を新たなユースケースとして検知実装します。

• 90日でやること（仕組みの再設計）

  • クロステナント戦略
    • 外部テナント接続（B2B/フェデレーション）の信頼モデルを再設計し、業務上の“常時提携先”のみを双方向既定許可に、残りは都度審査にします。
    • 重要取引先とは“専用の外部コラボドメイン/チャネル”を設け、汎用の外部接続から分離します。
  • RMMの台帳化とゼロトラスト運用
    • RMMは“資産”として台帳化（誰が・どこに・どの権限で）し、JIT/PIMで特権化は時間制にします。許可外RMMは実行も通信も原則不可にします。
  • インシデントの意思決定プロトコル
    • “偽旗の恐れがあるデータ流出”を前提に、広報・法務・経営の合議フローと対外説明テンプレートを整備します。国家関与の含意があっても、可観測事実ベースで発信する型を決めます。

• ハンティングのヒント（ベンダ非依存の観点）

  • 端末側
    • 短時間に“サービス登録→常駐化→外向き長時間セッション開始”のプロセス連鎖。新規インストールの正当性（署名・配布元・端末の役割）を突き合わせます。
  • ネットワーク側
    • 社内から特定クラウドRMMベンダ群への新規/持続的セッション増加。SNI/FQDNで“初観測ドメイン×長時間”を炙り出します。
  • ID側
    • 外部テナントとの会議直後に当該ユーザーのパスワード変更、多要素の再登録、アプリの同意（OAuth）など“アカウント敏感操作”が連続していないかを相関します（ここは仮説です）。

• ユーザー向けの一言教育

  • “外部からの画面制御リクエストは断るのが標準”
  • “初回の外部会議はロビー入室のまま、別回線で相手の真正性を確認”
  • “その場で認証コードを読み上げる・画面に映す行為は厳禁”

• MITRE ATT&CK（仮説マッピング）

  • 初期侵入: T1566.003 Spearphishing via Service（Teams）
  • 実行/ユーザー操作: T1204 User Execution（制御権付与・操作誘導）
  • 資格情報/アカウント悪用: T1078 Valid Accounts
  • 永続化/遠隔操作: T1219 Remote Access Software
  • 横展開: T1021 Remote Services（該当する場合）
  • 流出: T1567 Exfiltration Over Web Services/Cloud
  • 防御回避/偽装: T1036 Masquerading（偽旗/ランサム装い）

参考情報

• The Hacker News: MuddyWater Uses Microsoft Teams to Steal Credentials in False Flag Ransomware Attack（Rapid7観測に基づく二次報道）: https://thehackernews.com/2026/05/muddywater-uses-microsoft-teams-to.html

最後に。今回の一件は「暗号化なきランサム」というより、「IDとコラボとRMMを巡る“現代の初動戦”」の見本です。メールとEDRに寄った従来の重心を、Teamsと外部接続、RMMガバナンスに再配分する──この小さな舵取りが、次の四半期の被害を分けると考えます。温度のある運用に落とし込みながら、冷静な技術的手当てを同時に進めていきたいです。