Acronis Japan 脅威リサーチユニット（TRU) ソリューションアーキテクトの杉山吉寿です。
先日、日本経済新聞社（以下、日経新聞社）は、業務で利用しているビジネスチャット「Slack」に対して外部からの不正アクセスがあり、社員や取引先など1万7368人分の氏名・メールアドレス・チャット履歴が流出した可能性があると公表しました。
同社の発表および報道によれば、次のように説明されています。
「社員の個人所有（私物）のPCがウイルスに感染し、その端末から Slackの認証情報が漏えいし、その情報が悪用されてSlackワークスペースへの不正ログインが行われたとみられる」
ここで注意しておきたいのは、技術的な詳細（具体的なマルウェアの種類や、攻撃者がワークスペース内でどこまで踏み込んだか等）は現時点で公式には公開されていないという点です。 したがって、本記事では日経新聞社の内部事情を推測したり、確たる根拠のない「裏ストーリー」を語るつもりはありません。
その代わりに、このインシデントをきっかけとして、
「こうした 個人情報漏えいインシデントが起こるときに、現場でよく使われる攻撃チェーン はどういうものなのか」
を、あくまで一般論として整理し、
さらに「NISTのフレームワークに沿った考え方」と「アクロニスとして提案できる現実的な対策 」について解説します。
よくある攻撃チェーンの「型」を言語化してみる
Slack や Teams、Microsoft
365 などの SaaS から情報が漏れるインシデントでは、実は「典型的な型」とも言える攻撃チェーンが存在します。 ここでは日経の事例とは切り離した よく見られる攻撃の流れを、噛み砕いて分かりやすく説明します。
1. 最初の一撃は、やはり「1台の端末」から
攻撃のスタート地点は、主に次のようなところです。
- フィッシングメールの添付ファイルを開いてしまう
- 偽ログインページでID／パスワードを入力してしまう
- マルウェア付きのソフトやクラック版をインストールしてしまう
ここで侵害されるのはエンドポイント、つまり ユーザーのPCやノートPCです。
かつては、侵入後すぐにランサムウェアで「暗号化して身代金の要求」というパターンが一般的でした。しかし、ここ数年はまず 情報窃取型マルウェア（インフォスティーラー）
を仕込むケースが非常に多くなっています。
2. インフォスティーラーが「認証情報」と「トークン」を根こそぎ奪う
インフォスティーラーはとにかく「資格情報」が大好物です。
- ブラウザに保存された ID／パスワード
- Cookie、セッショントークン
- 各種クラウドサービスのアクセストークン
- OSやアプリの資格情報ストアに入っている秘密情報
これらを一気にかき集めて、攻撃者のサーバーに送信します。
ここに Slack や Teams、M365
の情報が含まれていると、一気にクラウド環境が丸裸になり危険にさらされる わけです。
代表的なインフォスティーラーの例
日経新聞社のインシデントで使用されたマルウェアは公表されていませんが、一般論として、現場でよく観測される代表的なインフォスティーラーには、例えば次のようなものがあります。
- Raccoon Stealer：比較的扱いやすい「マルウェア・アズ・ア・サービス」として出回っている窃取系マルウェア。 ブラウザの保存パスワード、Cookie、暗号資産ウォレットなどを大量に抜き取り、攻撃者のC2サーバーに送信します。
- RedLine Stealer： クレデンシャルやブラウザデータに加え、VPNクライアントやFTPクライアントの設定情報、暗号資産ウォレットなども狙う、近年特に検出件数の多いファミリーです。スパムメールやクラックソフト、偽ツールにバンドルされて配布されるケースが多く報告されています。
- Vidar / Azorult 系：古株のインフォスティーラーで、ブラウザ・メッセンジャー・暗号資産ウォレットなど、幅広いアプリケーションから情報を抜き取る機能を持っています。攻撃者側のコンフィグ次第で、狙うサービスを柔軟に切り替えられるのが特徴です。
これらのファミリーに共通しているのは、
「一度侵入されると、その端末は“鍵束”のように扱われてしまう」 という点です。
メール、クラウドストレージ、SaaS、社内VPN…あらゆるサービスの鍵がまとめて奪われてしまうため、「1台やられたら全部やられた」に近い状態 になりやすいのです。
インフォスティーラー侵入の 典型パターン
では、「具体的にどういう場面でインフォスティーラーが入ってくるのか？」という点についても、具体的な例をいくつか紹介します。
こちらもあくまで一般論となりますが、現場で頻繁にみられる「あるある」な侵入経路パターンです。
請求書や見積書を装ったOfficeファイル（マクロ付き）
- 件名は「【至急】支払確認のお願い」「請求書再送の件」など、現実的でそれっぽいもの
- 添付は Word や Excelファイル。開くと「コンテンツの有効化」「マクロを有効にしてください」と表示され、ユーザーがクリックするとマクロ経由でインフォスティーラーが落とされる
圧縮ファイル（ZIP / RAR / ISO）に偽装されたインストーラー
- メールやチャットで送られてくる「パスワード付きZIP」、あるいはファイル共有サービスのリンク
- 中身は見積書PDFに見せかけた実行ファイル（.exe）や、ISOイメージの中に仕込まれたランチャー。開くと裏でマルウェア本体が展開・実行される
クラックソフト／偽ライセンスジェネレーター
- 有償ソフトの「無料版」「アクティベーション解除ツール」を探して、怪しいサイトからダウンロード
- それ自体がインフォスティーラーの“配布ツール”になっており、実行した瞬間に端末が汚染される
- 個人PCや在宅環境で特に多いパターンとして、「業務にも使っている私物PC」がこうした経路で感染され、被害が一気に企業側に波及します
検索結果や広告を悪用した「偽公式サイト」
- ドライバ更新ツールやPDF変換ソフト、動画コーデックなどを検索した際に、検索結果の上位や広告枠に紛れ込む偽サイト
- 「Download」「Update」といったボタンを押すと、“それっぽいインストーラー”と一緒にインフォスティーラーが導入される
偽ブラウザ更新・偽セキュリティソフト
- ブラウザで怪しいサイトを開いたときに、「ブラウザを更新してください」「ウイルスが検出されました」といったポップアップが出てくる
- そこでダウンロードされる「アップデート」や「無料スキャンツール」が、実は情報窃取型マルウェアだった、というケース
チャット／コラボレーションツール経由のファイル・リンク
- Slack、Teams、LINEなどで「ちょっとこの資料見て」「このツール便利だったよ」と送られてくるURLやファイル
- アカウントがすでに侵害されていて、そのユーザーになりすました攻撃者が同僚にマルウェアをばらまく、という“横展開”攻撃パターン
どれも「やってしまいそうだな」と感じる現実的な手口ばかりだと思います。
こうしたルートから一度インフォスティーラーが侵入すると、その端末が持っているあらゆる“鍵”が順番に抜かれていく、というわけです。
3. クラウドサービスへの「なりすましログイン」
次に、攻撃者は盗んだクレデンシャル／トークンを使ってクラウドサービスにログインします。
- 正規ユーザーと同じ場所・同じブラウザ情報を装って、不審ログイン検知をすり抜ける
- すでに発行済みのセッショントークンを再利用して、MFAをすり抜ける
- 条件付きアクセスやデバイスヘルスのチェックが甘い環境だと、そのまま中に入れてしまう
結果として、攻撃者は 「コラボレーション環境の内側」 に立つことができます。
4. ワークスペースの中で静かに偵察・収集
ワークスペースに侵入後は、比較的静かに、しかし着実に、情報が集められていきます。
- ユーザーリスト、チャンネル構成、外部連携の状況を把握
- DM やプライベートチャンネルを含むチャット履歴のダンプ
- 添付ファイル・共有リンクからのファイル取得
- 他社との共有チャンネル（Slack Connect 等）を足掛かりにした横展開
ここで盗まれるのは、
「氏名＋メールアドレス」だけではありません。
会話の文脈、プロジェクト名、役職、誰が誰とどういう関係性、といった “人間関係グラフ”
そのもの です。
5. その情報が、次の攻撃の「燃料」になる
集めた情報は、次の攻撃に再利用されます。
- 過去の会話やプロジェクト名を引用した、超リアルなビジネスメール詐欺
- 取引先や顧客になりすました、支払い依頼やアカウント更新メール
- 会員・読者・視聴者を装ったフィッシングキャンペーン
「メールアドレス＋氏名＋チャット履歴」というパッケージは、
攻撃者にとっては 極めて価値の高い“素材” です。
1台のエンドポイントから、SaaS全体へ
アクロニス脅威リサーチユニット（TRU）でもこの件について議論しましたが、要点は非常にシンプルです。
「たった1台のエンドポイントから、SaaS全体の情報が連鎖的に抜かれる時代になっている」
ー
アクロニス脅威リサーチユニット（TRU）テクノロジーダイレクター、アレックス・イヴァニューク（Alex
Ivanyuk）
Acronis TRUは今回のインシデントについて、概ね次のようにコメントしています（要約しつつ、私の言葉で整理してあります）。
- 日経新聞社の事案は、侵害された単一のエンドポイントが、相互接続された職場ツールにおける大規模データ漏洩へと連鎖し得ることを示した
- こうしたインシデントで多く問題になるのは、ゼロデイなどの“華やかな技術”ではなく、認証情報やセッショントークンの窃取という、今や最も一般的な手口である点
- 多くの組織で、コアシステムに比べて コラボレーションツールの監視が手薄 になりがちであることも、改めて浮き彫りになった
- 日経新聞社が透明性を重視し、早期に当局へ任意報告した点は評価できる一方で、すべての組織がSaaSセキュリティの管理方法を見直すべきタイミングに来ている
そしてTRUが強く強調しているのは次の点です。
強力な多要素認証の適用 クラウドアプリ内の異常行動の監視 ／それらにアクセスするエンドポイントの健全性確保
これらはもはや「上乗せのオプション」ではなく、
サイバー・ハイジーンの最低ライン だ、ということです。
NISTのフレームワークから見える「守り方の型」
ここで少し視点を変えて、NISTのフレームワークからも整理してみます。
CSF 2.0：GOVERN（統治）を中心に「端末＋ID＋SaaS」を一体管理
2024年2月に公開された NIST Cybersecurity Framework 2.0（CSF 2.0） では、 コア機能が次の6つに整理され、その中心に GOVERN（統治） が据えられました。
GOVERN（統治） / IDENTIFY（識別） / PROTECT（防御） / DETECT（検知） / RESPOND（対応） / RECOVER（復旧）
今回のようなインシデントをCSF 2.0の視点で見ると、以下の要素が重要です：
- GOVERN（統治）：BYOD（私物端末）の利用方針 ／ どのSaaSを、どのID基盤と連携して使うか／ 個人情報・取材情報の扱い、報告基準
- IDENTIFY（識別）／PROTECT（防御）：「どの端末から、どのアカウントで、どのSaaSを使っているか」の棚卸し ／ エンドポイント防御、パッチ管理、最小権限
- DETECT（検知）／ RESPOND（対応） ／RECOVER（復旧）：不審ログインや大量ダウンロードの検知 ／ トークン失効や強制ログアウトを含めたインシデントレスポンス ／ ログとバックアップを使った事後検証と再発防止
「端末」「ID」「SaaS」をバラバラに考えず、一体の仕組みとして設計せよというメッセージになります。
NIST SP 800-63B：MFAとセッション管理は「設計の話」
もうひとつ重要なのが、NIST SP 800-63B（Digital Identity Guidelines: Authentication & Lifecycle Management） です。 これは、認証の強度（AAL）や、多要素認証、トークンのライフサイクル管理に関するガイドラインです。
ここから読み取れるポイントは次の通りです：
- パスワード単体ではなく、フィッシング耐性の高いMFA（FIDO2/WebAuthnなど） を優先すること
- 認証が一度通ったあとも、リスクの高いアクセスや不審な場所・時間帯では追加認証を求めるなど、リスクベース認証の設計が重要
- パスワード変更時には、既存セッションやトークンを確実に失効させること
要するに、「パスワードを変えたからOK」という話ではなく、
セッションとトークンのライフサイクル全体をどう設計するかが勝負 だということです。
アクロニスの提案する「三層構え」の現実的な対策
アクロニスとしては、こうしたインシデントを防ぎ、被害を最小化するために、
「エンドポイント」「SaaS・ID」「バックアップ／ログ」 の三層で対策を組み立てることを推奨しています。
1. エンドポイント：インフォスティーラーを入れない・動かさない
- Acronis Cyber Protect （Cloud/On-Prem） のアンチマルウェアとEDRで情報窃取型マルウェアの典型的な振る舞い（ブラウザ資格情報へのアクセス、C2通信など）を検知・遮断
- 脆弱性管理とパッチ配布により、古いブラウザやVPNクライアントなど「狙われやすいソフト」を減らす
「私物PCだから知らない」「家のPCだから関係ない」ではなく、
業務アカウントでSaaSにアクセスする端末は、企業ポリシーに合わせて管理する
――この割り切りが極めて重要です。
2. SaaS・ID：ゼロトラストの視点でアクセスを絞る
- Entra ID や Okta などのID基盤と連携し 条件付きアクセス（デバイス健全性／IP／リスク判定）管理者アカウントの特権管理
- Slack や M365の監査ログを集約し、短時間の大量ダウンロードや通常とは異なる場所からのアクセス、といった兆候を検知する
端末側で異常を検知したら、SaaS側のアクセス制御や資格情報リセットに迅速に繋げる運用が理想です。
3. バックアップ／ログ：消されても、後から追える状態を維持
- M365などのSaaSデータも含めた定期バックアップと、不変ストレージへの保存
- ログの長期保管により、「どこから・どこまで見られたのか」を後から追える状態を確保
バックアップは「最後の保険」であると同時に、
インシデント対応とフォレンジックのための“タイムマシン” でもあります。
BYODとシャドーITとの付き合い方
今回のインシデントで改めて浮き彫りになったのが、私物端末（BYOD）とシャドーIT の問題です。
- 何でも禁止すれば、業務や働き方の柔軟性が失われる
- 何でも許可すれば、セキュリティが崩壊する
その中で現実的にやるべきことは、シンプルです。
1. 「どこまでOKか」を明文化する
・業務アカウントでアクセス可能な端末の条件
・絶対にNGな使い方（例：家族共用PCからのアクセスなど）
2. 技術でガードレールを敷く
・条件を満たさない端末からは、重要SaaSへのアクセスを自動的にブロック
・やむを得ない場合は、VDIやブラウザ分離など、安全な迂回路を用意する
3. ユーザー教育を「共犯関係」で進める
・「ダメ！」で終わらせず、「こういうリスクがあるから一緒に考えましょう」というスタンス
・アクロニスのSecurity Awareness Trainingのように、実際の攻撃シナリオに近い演習で「体感してもらう」
まとめ～信頼を守るための「1台目からの設計」
日経新聞社のインシデントは、「またクレデンシャルか」という既視感のある事件でありながら、SaaSとBYODが前提となった2025年のサイバー空間を象徴する出来事だと言えます。
- たった1台の端末
- たった1つのクレデンシャル漏えい
- そこから数万件規模の個人情報と、企業の信頼が揺らぐ
これはメディア企業だけの話ではありません。ほぼすべての組織が、今この瞬間に直面しているリスクです。アクロニスとして、我々は
「端末」「SaaS・ID」「バックアップ／ログ」を三位一体で設計すること
こそが、この連鎖を途中で断ち切る最も理想的な近道だと考えています。
今回の記事が、皆さまの組織において 「うちは本当に大丈夫か？」
と立ち止まり、最初の１台目からの設計を見直すきっかけになれば幸いです。
著者：Acronis Japan 脅威リサーチユニット／ソリューションアーキテクト 杉山 吉寿
SIer、外資系ベンダー、コンサルティングファームにて、セキュリティの構築・運用・監査業務に従事。現在は、セキュリティおよびバックアップ領域のソリューションアーキテクトとして、国内外の企業に向けたEDR/XDR導入支援やセキュリティ教育・セミナー登壇を多数実施している。CISSP、CCSP、CISM、CISAなどの国際資格を保持し、攻撃防御からデータ復旧までを統合した“サイバー・レジリエンス”の実現を支援。最新脅威動向と現場対策を橋渡しする専門家として活動中。
Acronis について
Acronis は、2003 年にシンガポールで設立されたスイスの企業で、世界 15ヵ国にオフィスを構え、50ヵ国以上で従業員を雇用しています。Acronis Cyber Protect Cloud は、150の国の26の言語で提供されており、21,000を超えるサービスプロバイダーがこれを使って、750,000 以上の企業を保護しています。
