今週のサイバーセキュリティニュース
【｜結論】
メール対策だけでは足りません。
Microsoftが2026年7月23日に公表した脅威分析では、メールが依然として主要な攻撃経路である一方、Microsoft Teamsを使ったフィッシングや偽サポート電話が増加しています。
今後の対策は、
「怪しいメールを開かない」
だけではなく、
・Teamsの外部チャット・通話
・Microsoft Entraの認証
・Intuneによる端末状態
・インシデント発生後の証拠保全
・委託元、顧客、行政機関への報告
まで一体で設計する必要があります。
【｜確認できた事実】
Microsoft Threat IntelligenceとMicrosoft Defender Security Research Teamは、2026年第2四半期、4月から6月までに、約76億件のメール経由のフィッシング脅威を検知したと報告しています。
月別では、
・4月：約27億件
・6月：約24億件
と全体量はやや減少しました。
ただし、悪意あるペイロードを使った攻撃のうち、**94～96％**は認証情報の窃取を目的とするものでした。
マルウェアを送り込む攻撃よりも、ID・パスワード・認証セッションを奪う攻撃が中心になっていることが分かります。
なお、この数字はMicrosoftが観測した脅威データであり、世界中の全攻撃件数を示すものではありません。
【｜Teamsを狙う攻撃】
Microsoftは、Teamsを使ったソーシャルエンジニアリング、フィッシング、マルウェア配布が増加したと報告しています。
特に増えているのが、攻撃者がIT部門やヘルプデスクを装って電話をかける「ビッシング」です。
Teams上で観測された悪意ある通話の週間件数は、
・2026年初頭から約80％増加
・2025年半ばの水準と比べて約10倍
に達しました。
メールと異なり、Teamsのメッセージや通話は「社内の正規ツールから届いた連絡」に見えやすいため、利用者が信用してしまう危険があります｜攻撃者は「IT担当者らしさ」を捨て始めている】
従来は「IT Support」「Help Desk」など、分かりやすい表示名を使う攻撃が中心でした。
しかし2026年6月にMicrosoftが観測したTeamsフィッシングでは、**52％**が一般的な表示名を使っていました。
攻撃者は、露骨な偽ヘルプデスク名ではなく、取引先、同僚、外部の業務担当者に見える名前を使う方向へ変化しています。
さらに、Teams通話で、
「アカウントが停止される」
「更新作業が必要」
「画面共有してほしい」
「確認コードを教えてほしい」
などと迫る手口も確認されています。
表示名だけで相手を信用する運用は危険です。
【｜攻撃は短時間で大量に実行される】
Microsoftは、2026年6月1日に発生した自動化されたBEC攻撃について、3時間未満で、
・6万7,000人以上
・4万2,000組織以上
にメッセージが送信されたと報告しています。
使われた誘導内容は、売掛金の一覧や顧客連絡先の提出要求、給与振込先の変更などでした。
BECの最初の接触では、直ちに振込を求めるとは限りません。
Microsoftの分析では、初回メッセージの**87～92％**が、
「今、席にいますか」
「少し相談できますか」
といった一般的な会話から始まっていました。
不正送金対策では、金額や振込先だけでなく、会話を開始した相手の本人確認が必要です。
【｜Azure・Microsoft 365の技術対応】
企業が優先して確認すべき項目は次のとおりです。
① Teamsの外部アクセスを業務上必要な範囲へ限定する
② 管理されていないTeamsアカウントからの接触可否を確認する
③ 不審なドメインと送信者をTenant Allow／Block Listへ登録する
④ Defender for Office 365のTeams保護を有効化する
⑤ Teams向けSafe LinksとZero-hour auto purgeを確認する
⑥ Microsoft Entraの特権管理者へ耐フィッシングMFAを要求する
⑦ Intune準拠端末を条件付きアクセスの判定材料にする
Microsoft Defender for Office 365では、Teams内のリンクをクリック時に検査するSafe Linksや、配信後に悪意が判明したメッセージを処理するZAPを構成できます。
【｜Entra・Intuneで止める】
通常のMFAも重要ですが、攻撃者中間者型フィッシングでは、入力された認証情報や認証セッションが悪用される可能性があります。
Microsoft Entraでは、条件付きアクセスの「認証強度」を使用して、管理者などへ耐フィッシングMFAを要求できます。
Microsoftが耐フィッシング方式として示しているのは、Windows Hello for Business、パスキー・FIDO2、証明書ベース認証などです。
また、Intuneの準拠状態をMicrosoft Entraへ渡し、組織の要件を満たした端末だけにアクセスを許可する設計も可能です。
ただし、認証強度や準拠端末の必須化は、緊急用アカウント、サービスアカウント、未登録端末への影響を事前に検証してから段階的に導入する必要があります。
【｜侵害が疑われたときに調べるもの】
Teams上の不審な連絡や認証情報の入力が確認された場合は、パスワード変更だけで終了してはいけません。
少なくとも次を時系列で確認します。
・Microsoft Entraのサインインログ
・不審な国、IPアドレス、端末からのアクセス
・MFA方法や認証情報の追加・変更
・新規アプリ登録、OAuth同意、API権限
・受信トレイルール、転送設定、代理アクセス
・Teamsの外部ユーザーとの通信記録
・SharePoint、OneDrive、メールへのアクセス
・Defender XDRのインシデントとアラート
・Intune端末の準拠状態とリスク状態
・管理者ロールやグループ構成の変更
「パスワードを変更した記録」と「情報が持ち出されていないことを確認した記録」は別の証拠です。
【｜クラウド法務上の判断】
認証情報を入力した、またはアカウントが不正利用されたという事実だけで、直ちに個人情報保護委員会への報告義務が確定するわけではありません。
実際に、
・個人データへアクセスされたか
・閲覧、転送、ダウンロードされたか
・漏えい、滅失、毀損が発生したおそれがあるか
・法令上の報告対象事態に該当するか
を、ログやフォレンジック調査から判断します。
個人情報保護委員会は、令和7年度第4四半期に、個人情報に関する漏えい等報告を4,602件、特定個人情報に関する報告を91件処理したと公表しています。
不正アクセス事案では、原因や被害範囲の調査に加え、必要に応じて警察やIPAへの連絡を促しています。
【｜報告期限と山崎行政書士事務所の支援】
報告対象事態に該当する場合、個人情報保護委員会への速報は、事態を知った後、速やかに、目安として概ね3～5日以内に行う必要があります。
確報は原則30日以内、不正目的の行為による漏えい等では60日以内です。
法人では、経営者が報告を受けた日ではなく、いずれかの部署が事態を知った時点が起算点になります。
また、委託元・顧客との契約に別の通知期限が定められている場合は、行政報告とは別に確認が必要です。
山崎行政書士事務所では、
・Azure、Microsoft Entra、Microsoft 365、Intuneの構成確認
・条件付きアクセスと認証方式の設計支援
・ログ、証拠、影響範囲の整理
・委託契約と責任分界の確認
・顧客、委託元への通知文書
・個人情報保護委員会への報告資料
・原因、経緯、再発防止策の文書化
を、Azure技術支援とクラウド法務の両面から支援します。
攻撃の入口がメールからTeams、通話、認証基盤へ広がる中で重要なのは、単一製品の設定変更だけではありません。
「誰が、どの端末から、何へアクセスしたか」
「何を根拠に漏えいの有無を判断したか」
「いつ、誰へ報告したか」
を後から説明できる状態まで整えることです。
コメント