Teams Vishing ― 「IT Supportを信じる」ことがInitial Accessになる
Executive Summary
Microsoft Incident Responseは2026年3月16日、Microsoft TeamsのVoice PhishingでIT Supportを装ったThreat Actorが、被害者にQuick Assistを許可させて初期侵入した事例を公表しました。1
この事例の重要点はZero-dayでもMalware Deliveryでもなく、正規Collaboration Tool、正規Remote Support Tool、利用者のTrustをつないで侵入したことです。その後は偽Credential Page、Malicious MSI、C2、Credential Harvesting、Session Hijackingへ展開しました。
なぜ今なのか
Email Securityが強くなるほど、攻撃者はTeams、Voice、Helpdesk、Remote Support等の「業務上信頼される経路」へ移ります。Security AwarenessをEmailだけに限定するとBlind Spotになります。
攻撃Flow
MITRE ATT&CK® Mapping
この表は、攻撃・Campaignの理解に有用な場合だけ表示します。Source-labeled は一次情報がATT&CK IDを明示したもの、Analyst-mapped は一次情報に記載された行動を本LibraryがATT&CKへ対応付けたものです。後者は、元情報の発行者がそのATT&CK IDを明示したことを意味しません。
| Technique | Tactic | Basis | Article context |
|---|---|---|---|
| T1566.004 Spearphishing Voice | Initial Access | Analyst-mapped | Microsoft TeamsのVoice CallでIT Supportを装い、利用者を操作したInitial Accessに対応。 |
| T1219.002 Remote Desktop Software | Command and Control | Analyst-mapped | 被害者にQuick AssistでRemote Interactive Accessを許可させた正規Remote Desktop機能の悪用に対応。 |
経営インパクト
| 観点 | 影響 |
|---|---|
| Helpdesk | Support Process自体がHigh-risk Security Controlになる |
| Collaboration | Teams等をEmail外のPhishing Surfaceとして管理する必要 |
| Remote Tool | 正規ToolはAllowlistされやすくDetectionを回避しやすい |
| Identity | Endpoint侵入後の最終TargetはCredential / Sessionになりやすい |
日本企業への示唆
「社内ITから連絡が来たら従う」という業務習慣そのものを設計し直す必要があります。特にRemote Support開始時のIdentity Verificationと、外部Teams AccountからのContact Policyが重要です。
推奨アクション
- 外部Teams Communicationを必要最小限に制限する
- Helpdeskの本人確認とCallback Processを標準化する
- Quick Assist / RMM ToolをInventory化し不要なら無効化する
- Remote Support開始時に別ChannelでVerificationする
- Voice PhishingをAwareness / Tabletop Exerciseへ追加する
- Remote Tool利用とIdentity RiskをSOCで相関する
用語解説
Vishing
Voice（電話・音声Call）を使ったPhishing / Social Engineering。