認証 | SQAT®.jp

2026年10月15日2026年10月19日

国内で相次ぐ不正アクセス、企業が点検すべきAPIと業務システム

不正アクセスに関する注意喚起を受け、自社で利用している製品を確認するだけでは、点検すべき範囲を見落とす可能性があります。Webサービスの裏側で動くAPIや、限られた従業員だけが使う業務システムまで含め、公開範囲と操作権限を確認することが重要です。

JPCERT/CCは2026年10月8日、国内組織で相次ぐ不正アクセスについて注意喚起を公表し、翌9日に情報を追加しました*1。本記事では、注意喚起のうちAPIや業務システムに関する内容を中心に、OWASPの技術資料も踏まえながら、企業が実施すべき点検方法を解説します。

今回の注意喚起で確認されていること

JPCERT/CCが取り上げているのは、2026年9月前後に国内組織で相次いだ、個人情報等の漏えいにつながる不正アクセスです。既知の脆弱性の探索・悪用やAPI経由の不正操作、BIツール「Metabase」の脆弱性を悪用した攻撃などが報告されています。また、一般利用者向けのサービスだけでなく、BIツールや従業員向け管理システムも被害対象となっています。10月9日の更新では、公開Webサーバーからアクセス可能なアプリケーションサーバーにWebシェルが設置された事案が追加されました。

ただし、公表された事案を一つの原因で説明することはできませんJPCERT/CCは、攻撃に関する技術的な情報の共有が十分でない状況を説明し、把握している情報について「限定的かつ断片的」としています※。

出典：JPCERT/CC「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」（2026年10月8日公開、10月9日更新）（https://www.jpcert.or.jp/at/2026/at260030.html）I. 概要より一部引用。

こうした状況を踏まえ、以降はAPIや業務システムのセキュリティ対策について、企業が確認すべきポイントを解説します。

画面に表示されないAPIも点検が必要

APIは、アプリケーション同士がデータや機能をやり取りするための仕組みです。スマートフォンアプリやWeb画面でボタンを押すと、その裏側でAPIに要求が送られ、サーバーが処理する構成があります。画面の表示と、サーバーが要求を受け付ける条件は、それぞれ確認する必要があります。例えば、一般利用者には管理ボタンを表示しない設計でも、それだけで管理用APIへの要求を防げるわけではありません。要求を受けたサーバーが利用者の権限を確認しなければ、本来許可されていない機能を実行されるおそれがあります。OWASPは、こうした問題を機能レベルの認可の不備として整理しています*2。

認証は利用者が誰かを確認すること、認可はその利用者が何をしてよいかを判断することです。ログイン済みであっても、すべての顧客情報を閲覧してよいとは限りません。同じ閲覧機能でも、自分の契約に属するデータだけを扱えるよう、対象データごとに権限を確認する必要があります。

図：画面の表示制御とAPIの権限確認

管理用や内部利用を想定したAPIであっても、適切なアクセス制御は欠かせません。OWASPの「REST Security Cheat Sheet」では、非公開のRESTサービスについても、各APIエンドポイントでアクセス制御を実施することを求めています。APIのURLが一般に知られていないことだけを安全性の根拠とせず、アクセス元の制限や利用者の認証・認可を適切に設定する必要があります。

自社で確認すべき6つの点検項目

公開中のシステムとAPIを把握しているか

まず、運用担当者や開発委託先に、現在動いているシステムとAPIの一覧を確認します。サービス名だけでなく、利用目的、管理担当者、接続先、扱うデータ、利用を許可する相手まで整理すると、見直すべき範囲がはっきりします。仕様書と実際の稼働環境に差がないかも確認したいところです。特に確認したいのは、更新前のAPI、試験用の環境、保守用の機能です。OWASPは、管理から漏れた古いAPIや不要な公開環境をリスクとして挙げています*3。本番のAPIを修正しても、同じデータに接続する旧版が動き続けていれば、点検は完了していません。廃止の判断には利用状況を確認し、停止する担当者と日程まで決めておきます。

また、公開Webサーバーから内部のアプリケーションサーバーや管理システムへ、どのような通信が許可されているかも確認します。外部公開していないシステムであっても、公開サーバーを経由して到達できる場合があります。業務上必要な通信に限定されているか、不要な接続経路が残っていないかを点検することが重要です。

利用者ごとの操作権限は適切か

権限の確認では、誰に、どの機能を、どのデータに対して許可するのかを明文化します。例えば「担当者は自分の担当顧客を閲覧できるが、他部署の顧客情報の出力はできない」といった業務上の条件です。一般利用者と管理者の区別に加えて、所属部署や契約先などの境界も整理します。そのうえで、許可された操作が成功することと、許可されていない操作が拒否されることの両方を確認します。機能単位の権限と、データ単位の権限は別々の観点です。実機での確認は、システム所有者と対象範囲を合意し、検証用アカウントやテストデータを用意して進めます。

APIキーやトークンを失効できるか

APIキーやアクセストークンの管理では、発行済みのものを把握できるかに加え、漏えいが疑われた際に失効させられるかを確認します。どのシステムが使い、どこまでの操作を許可し、誰が更新するのかが分からなければ、緊急時の判断が遅れます。OWASPも、秘密情報への最小限の権限付与と、更新・失効・有効期限を含む管理を示しています*4。実務では、鍵の値そのものを点検表に転記せず、識別子と用途、管理先を記録すると扱いやすくなります。更新後に古い認証情報が使えなくなるか、連携先の設定変更が必要かも確かめます。APIキーの所持だけを機密性の高い処理の許可条件とせず、システムの用途や扱う情報に応じて、適切な認証・認可の仕組みを組み合わせることが重要です。

APIの大量実行を制限できるか

操作権限の確認とあわせて、短時間に繰り返される要求への制限も確認します。検索やパスワード再設定など、機能ごとに通常の利用量を把握し、実行回数や一度に返すデータ件数に適切な上限を設けます。OWASPも、業務に応じたレート制限や応答件数の制限を推奨しています*5。ただし、回数を制限しても、権限のない操作が一度でも通る問題は解消しません。認可の点検と並行して進めます。

脆弱性の修正と暫定措置を管理できるか

既知の脆弱性への対応は、利用製品や部品のバージョンを把握することから始まります。開発委託先に確認する場合も、「対応済み」という回答だけで終えず、修正した対象と反映日、残っている課題を共有してもらいます。更新による業務影響が心配な場合は、検証環境で機能を確認したうえで反映します。すぐに更新できなければ、提供元の回避策や機能制限などの適用可否を検討します。OWASPも、修正版の検証と、修正できない場合の暫定的な緩和策を分けて扱っています*6。暫定措置には担当者と見直し期限を設定し、恒久対応まで追跡することを勧めます。

不審な操作をログで追跡できるか

ログの点検では、記録の有無に加えて、利用者と操作内容を結び付けて調べられるかを確認します。認証や権限確認の失敗、権限変更、アカウント作成、データ出力といった操作は、調査に役立つ手掛かりになります。OWASPのログ管理資料でも、これらの記録が取り上げられています*7。例えば、通常と異なる時間帯に大量の出力が行われた場合、操作した主体、対象データ、実行結果を追えるでしょうか。担当者が一件の操作を実際にたどってみると、記録項目や保存先の不足を見つけやすくなります。一方、パスワードやアクセストークンをそのままログに残すと、記録自体が漏えいの原因になり得ます。必要な情報を選び、秘密情報は記録から除外・マスキングする設計が必要です。

点検結果を改善と初動対応につなげる

点検で見つかった問題は、対応する人と完了を確かめる方法まで決めて初めて管理できます。本記事では、点検結果に「対象」「確認できた事実」「業務への影響」「対応担当者」「期限」「再確認の方法」を残す運用を勧めます。判断材料が不足する項目は、問題なしとして閉じず、未確認の内容を明らかにして担当者へ引き継ぎます。例えば、使われていない公開APIが見つかったなら、利用状況を確認して公開を止め、実際に外部から利用できなくなったかを確認します。権限の不備を修正したなら、許可されない操作が拒否されることと、正規の業務が継続できることを再度確かめます。修正作業の完了と、安全性の確認を対応記録の中で結び付けることが大切です。

不正アクセスが疑われる場合の対応

すでに不審な操作が確認されている場合は、予防目的の点検だけでなく、インシデント対応の担当者へ速やかに連絡します。原因調査に必要なログや設定情報などを保全し、証拠を失わないよう注意しながら、被害の拡大を抑える措置を検討します。平時から、夜間や休日の連絡先と、システムの利用停止を判断する責任者を決めておくことも重要です。

脆弱性診断を相談する前に整理しておきたい情報

専門家に相談する際には、対象URLの一覧に加え、API仕様書、利用者の権限区分、重要な業務機能、扱う情報を整理しておくと、確認したい範囲が伝わりやすくなります。顧客向けの画面だけを対象にするのか、管理機能やAPIも含めるのかを、依頼段階で明確にしておきましょう。自社のAPIや管理機能について、どこまでを診断対象に含めるべきか判断が難しい場合は、システムの構成や業務上の権限を共有したうえでご相談ください。運用中のシステムを定期的に点検する機会としては、脆弱性診断を活用できます。

Webアプリケーションの脆弱性を把握し、適切な対策につなげる

ブロードバンドセキュリティ（BBSec）の「Webアプリケーション脆弱性診断」では、Webアプリケーションの脆弱性を診断し、リスクの深刻度と推奨対策をご報告します。管理機能やAPIを含む診断範囲についても、お気軽にご相談ください。

【関連記事】

APIの脅威と対策について知りたい方は、「OWASP API Security Top 10とは？APIの脅威と対策を知ろう」もあわせてご覧ください。

公開範囲と権限を確かめることから始める

今回の注意喚起を自社の対策につなげるには、現在公開しているシステムを把握し、誰がどの情報を扱えるのかを確かめることが出発点になります。まずは主要な業務システムを一つ選び、APIの一覧、権限の設計、操作ログを担当者と確認してみてください。確認できない部分が見つかれば、そこから次の調査や改善につなげられます。

【参考情報】

JPCERT/CC「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」（2026年10月8日公開、10月9日更新）（https://www.jpcert.or.jp/at/2026/at260030.html）
OWASP API Security Project「API5:2023 Broken Function Level Authorization」
https://api-security.owasp.org/editions/2023/en/0xa5-broken-function-level-authorization/
OWASP API Security Project「API1:2023 Broken Object Level Authorization」
https://api-security.owasp.org/editions/2023/en/0xa1-broken-object-level-authorization/
OWASP API Security Project「API9:2023 Improper Inventory Management」
https://api-security.owasp.org/editions/2023/en/0xa9-improper-inventory-management/
OWASP Cheat Sheet Series「Secrets Management Cheat Sheet」
https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
OWASP API Security Project「API4:2023 Unrestricted Resource Consumption」
https://api-security.owasp.org/editions/2023/en/0xa4-unrestricted-resource-consumption/
OWASP Cheat Sheet Series「Vulnerable Dependency Management Cheat Sheet」
https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

2026年10月2日2026年10月2日

EvilTokensとは？Microsoft 365を狙うデバイスコードフィッシングとAI悪用

Microsoft 365の正規のサインイン画面を利用し、利用者に攻撃者側のアクセスを承認させる「デバイスコードフィッシング」が悪用されています。Microsoftが2026年9月に活動基盤を妨害した「EvilTokens」は、この手口によるアカウント侵害に加え、AIを使って侵害した受信箱を分析し、詐欺の標的やなりすまし相手を選ぶ機能も備えていました。本記事では、EvilTokensの仕組みと、Microsoft 365を利用する企業が確認しておきたい認証設定、監視、侵害後の対応について解説します。

EvilTokensとは

EvilTokensは、デバイスコードフィッシングによるアカウント侵害や、AIを使った侵害後の情報収集などを支援するPhishing-as-a-Service（PhaaS）プラットフォームです。Microsoftは2026年9月22日、同サービスの活動基盤を妨害したと発表しました。同社によると、世界の1万を超える組織で、1万2,000を超える受信箱が侵害されています。この数字はメール侵害の規模を示したものであり、金銭被害が発生した組織数を示すものではありません。

Microsoft 365を利用する企業が見直したいのは、認証画面のURLだけで安全を判断する運用です。EvilTokensは、利用者に正規のMicrosoftの画面で操作させ、攻撃者が開始した認証要求を承認させます。アカウントを守るには、MFAの導入に加え、自社で利用を認める認証方式や、侵害が疑われた場合の対応を確認する必要があります。

正規の認証画面でも侵害につながる理由

デバイスコード認証は、入力操作に制約のある機器などへサインインするための仕組みです。機器側に表示されたコードを、別の端末のブラウザーで入力して認証を完了します。デバイスコードフィッシングでは、この認証要求を攻撃者が開始し、コードを利用者に入力させます。問題は、コードにひも付く認証要求の主体です。画面自体がMicrosoftの正規サイトでも、そこで承認する要求が攻撃者によって開始されたものであれば、攻撃者側にアクセスが与えられます。偽サイトへパスワードを送信していなくても成立する手口です。利用者がMicrosoftにサインインしていない場合には、正規の画面でパスワードやMFAによる認証を求められることがあります。MFAを設定していても、利用者が攻撃者の要求を正規の認証画面で承認すると、侵害につながる場合があります。

図1：EvilTokensによるデバイスコードフィッシングと侵害後の流れ

出典：Microsoft「Disrupting EvilTokens: The AI Chatbot Built for Cybercrime」「Unmasking EvilTokens: Getting to the root of device code phishing」を基に弊社作成
※図は攻撃の概略を示したものです。AIによる分析後に、必ずなりすましや金銭被害が発生することを示すものではありません。

AIは受信箱から取引関係や送金担当者を探す

EvilTokensのAI機能は、侵害した受信箱を解析し、支払いに関する会話や組織内の役割、信頼関係などを把握するためにも使われていました。Microsoftは、詐欺の標的やなりすまし相手を選び、詐欺の進め方を提案する機能を報告しています。AIが、フィッシングメールの作成だけでなく、侵害した受信箱から詐欺に利用できる情報を探すためにも使われた事例です。このため、ビジネスメール詐欺対策では、振込先の変更や通常と異なる送金依頼について、信頼できる別の連絡経路で確認することが欠かせません。Microsoftも別経路での確認を推奨しています。実務では、受信メールに記載された連絡先をそのまま使わず、社内で管理している既知の連絡先で確認する運用が考えられます。

EvilTokensへの対策

図2：EvilTokensへの防御と対応

出典：Microsoft「Disrupting EvilTokens: The AI Chatbot Built for Cybercrime」、Microsoft Learn「Block authentication flows with Conditional Access policy」「Token theft playbook」「Respond to a compromised cloud email account」を基に弊社作成
※対策の分類は、Microsoftの公表資料を基に弊社が整理したものです。

不要なデバイスコード認証を制限する

予防策の出発点は、自社でデバイスコードフローを使っているかを把握することです。Microsoftは、利用状況を監査して必要性を判断し、可能な限り利用を遮断する方針を推奨しています。業務上必要な用途がある場合は、その理由と保護方法を明確にし、例外を限定します。Microsoft Entra IDの条件付きアクセスでは、認証フローを条件としてデバイスコードフローをブロックできます。変更時は、レポート専用モードで影響を確認してから有効化します。緊急アクセス用アカウントなど必要な除外を設計し、例外が増え続けないよう定期的に点検することも重要です。従業員向けの説明にも、この仕組みを反映することが重要です。「URLを確認する」に加え、「自分が開始していないサインインのコードは入力しない」と具体化すれば、何を判断すべきか伝わりやすくなります。これは、今回の認証手口を踏まえた教育上の対策の一例です。

認証後の不審な操作を監視する

監視では、サインインの成否だけで判断を終えないことが重要です。Microsoftのトークン窃取対応資料では、サインインログ、監査ログ、Officeの操作、関連端末の情報などを調べるよう案内しています。新しい認証方法や端末の登録、メール転送ルールの追加なども確認対象となります。これらの情報は、必要に応じてSIEMなどへ集約し、関連付けて確認できるようにします。たとえば、普段と異なるサインインと、その後の転送設定変更を、同じアカウントの時系列として調べる運用が考えられます。ただし、不審な出来事が一つあっただけでEvilTokensによる侵害と断定することはできません。利用者の操作や業務上の変更だったかを確認し、侵害の有無と範囲を絞り込む必要があります。

侵害が疑われるアカウントを封じ込める

アカウント侵害が疑われる場合、Microsoftは、侵害が疑われるアカウントを調査中は一時的に無効化することを推奨しています。あわせて、アクティブなセッションと更新トークンを失効させ、登録されたMFAの方法や端末、同意済みアプリ、管理者権限などを点検します。不正なメール転送設定や、通常の画面では見落としやすい受信箱ルールも確認対象です。パスワードを変更して利用者が再びログインできたことだけでは、攻撃者が残した設定まで除去できたとは限りません。どのアクセスを止め、どの変更を戻し、どのログで確認したかを記録し、公式手順に沿って復旧することが必要です。

送金や支払情報の変更は別経路で確認する

EvilTokensでは、侵害した受信箱から取引関係や支払いに関する情報が把握され、なりすましや送金詐欺に悪用される可能性があります。振込先の変更や送金依頼など、金銭に関わる重要な依頼については、メールだけで判断せず、既知の電話番号など信頼できる別の連絡手段で確認することが重要です。

EvilTokensへの対策は、認証管理だけでは完結しません。認証フローの制御、不審な操作を追跡できるログの整備、侵害時の対応、送金依頼の確認までを、自社の担当者と手順に落とし込むことが重要です。正規の認証画面を通った操作であっても、誰のアクセスを許可しようとしているのかを確認する視点が求められます。

【参考情報】

Microsoft「Disrupting EvilTokens: The AI Chatbot Built for Cybercrime」（2026年9月22日公表）（https://blogs.microsoft.com/on-the-issues/2026/09/22/disrupting-eviltokens-the-ai-chatbot-built-for-cybercrime/）
Microsoft Security Blog「Unmasking EvilTokens: Getting to the root of device code phishing」（2026年9月22日公表）（https://www.microsoft.com/en-us/security/blog/2026/09/22/unmasking-eviltokens-getting-to-the-root-of-device-code-phishing/）
Microsoft Learn「Block authentication flows with Conditional Access policy」（https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-authentication-flows）
Microsoft Learn「Token theft playbook」（https://learn.microsoft.com/en-us/security/operations/token-theft-playbook）
Microsoft Learn「Respond to a compromised cloud email account」（https://learn.microsoft.com/en-us/defender-office-365/responding-to-a-compromised-email-account?view=o365-worldwide）

編集責任：木下

アカウント侵害や不正アクセスが疑われる場合は

BBSecでは、セキュリティインシデント発生時の初動対応から、原因・影響範囲の調査、フォレンジック調査、再発防止まで支援しています。

平時の対応体制を見直したい場合

インシデント初動対応準備支援サービスはこちら

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

2026年9月17日2026年9月17日

盗まれたトークンから約3時間でクラウド管理権限へ ―AnthropicのAI悪用報告から考える企業の対策

生成AIの活用が広がる一方で、サイバー攻撃にAIを悪用する動きも確認されています。Anthropicが2026年9月10日に公表したAI悪用の調査報告には、盗まれた開発者トークンを足掛かりに、攻撃者が被害組織のクラウド環境の完全な管理権限を約3時間で取得した事例が記されています。AIサイバー攻撃への備えを考えるうえで、この事例は、認証情報の保護と、検知後に動ける体制を点検する材料となります。

AnthropicのAI悪用報告で何が確認されたのか

今回の報告では、2025年12月から2026年8月にかけてAnthropicが検知・対処したAI悪用活動が取り上げられています。サイバー攻撃におけるAIの使われ方には幅があり、攻撃者の補助として利用された例に加え、偵察、侵入、認証情報の収集、情報窃取などをAIに実行させる例や、複数の標的に対してAIエージェントが並行して処理する例も確認されています。一方、標的の選定や攻撃結果の確認、収益化などの重要な判断には、人間が引き続き関与していたとされています。

報告には、認証情報の悪用に関する事例も複数示されています。被害組織の環境から盗んだAIサービスのAPIキーを別の攻撃に利用した例に加え、盗まれた開発者トークンを足掛かりに、被害組織のクラウド環境の完全な管理権限を約3時間で取得した事例も報告されています。認証情報は情報を盗む入口となるだけでなく、攻撃に用いるAIの計算資源へのアクセスにも利用されていました。*8

なお、約3時間という数値は、Anthropicが観測した個別の侵害事例に関するものです。すべてのAIを使った攻撃が同じ速さで進むことや、従来の攻撃より何倍速いかを示す統計ではありません。この事例から企業が考えるべきなのは、約3時間という時間そのものではなく、認証情報が悪用された場合に、異常を検知し、調査やアクセス制限などの対応へ移るまでにどの程度の時間を要するかという点です。

図1：AI悪用による侵入の個別事例

開発者トークンから管理権限取得までの個別事例
出典：Anthropic「Detecting and countering misuse of AI: September 2026」（https://www.anthropic.com/threat-intelligence-report-september-2026）を基に作成

認証情報漏洩への対策は、トークンの権限まで確認する

認証情報の管理を見直すときは、人がログインに使うパスワードに加え、アプリケーションや開発環境が使うアクセスキー、トークンも対象にします。ここからは、クラウド環境で取り組める対策をAWSの公式資料を例に整理します。前述の被害事例のクラウド事業者をAWSと特定するものではありません。

AWSはIAMの推奨事項として、一時的な認証情報の利用、多要素認証（MFA）、業務に必要な範囲に絞った権限付与、使われていない認証情報や権限の定期的な見直しを挙げています*2。システムが継続的に使う認証情報についても、長期のアクセスキーを配布する構成から、IAMロールによる一時的な認証情報へ移行できるかを検討します。自社で点検する際は、認証情報を誰が管理し、どのシステムが使い、どのデータにアクセスできるのかを確認し、用途が終わったテスト用の権限や、担当者の異動後も残る認証情報などを整理します。認証情報の保護とあわせて、必要以上の権限を与えないことが重要です。

クラウドのログは、データへの操作まで記録されているか

クラウド監視では、「ログを取得している」だけでなく、実際にどの操作まで記録されているかを確認する必要があります。例えばAWS CloudTrailでは、Amazon S3上のオブジェクトの読み取りなどはデータイベントに分類され、証跡やイベントデータストアでは初期設定で記録されないため、取得には設定と追加料金が必要です*3。自社の重要データについて、調査時に確認したい操作が記録に残るかを点検し、顧客データを保管する領域であれば、誰が、いつ、どのデータへアクセスしたかを追える設定になっているかを確認します。大量のログを一律に増やすのではなく、守るべきデータと必要な調査項目を先に決めると、取得範囲や費用も検討しやすくなります。

また、アクセスがあったという事実だけで、不正利用とは断定できません。AWSのGuardDutyの対応ガイドも、検知に関係するユーザーやロール、API操作を特定し、操作時刻や接続元IPアドレスを含めて正当な利用か確認するよう案内しています*4。担当者がこれらを照合できる情報と連絡先を持つことが、アラートを判断につなげる前提になります。

検知後は、どの認証情報の利用を止めるか判断する

認証情報の不正利用が疑われる場面では、影響するユーザーやロールと、その権限を特定する必要があります。API操作の内容を見れば、正常な処理との違いや調査すべき範囲を検討できます。確認の結果、正当な利用と判断できない場合は、該当するクラウドサービスの手順に沿って封じ込めを進めます。

ここで注意したいのが、すでに発行された一時的な認証情報の扱いです。AWSは、不正利用を止める手段として、一時的な認証情報に付与される権限の変更や、IAMロールの既存セッションの取り消し方法を説明しています*5。対象のロールを利用する正常なユーザーにも影響する場合があり、どの利用を止めるかを区別することが必要です。

緊急時の手順には、実行する操作だけでなく、その操作で停止する業務と、判断を行う担当者も記載しておきます。「認証情報を無効にする」とだけ書かれた手順を、自社のアカウントやサービスに当てはめて確認する作業です。担当部門が異なる場合も、現場で判断できる範囲をあらかじめ合意しておくことが、連絡待ちを減らすための実務的な準備になります。

図2：認証情報の悪用に備える監視と初動対応

出典：AWS「Remediating potentially compromised AWS credentials」（https://docs.aws.amazon.com/guardduty/latest/ug/compromised-creds.html）「Disabling permissions for temporary security credentials」（https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_disable-perms.html）「SEC10-BP07 Run simulations」（https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_run_game_days.html）を基に弊社作成

「対応できるはず」を訓練で確かめる

検知から対応までの時間を短くしたいなら、まず自社の手順を一度動かして確かめることです。AWSのWell-Architected Frameworkでは、インシデント対応能力を評価する方法として演習を挙げ、机上演習では関係者の役割や責任、連絡手段、手順書を確認できると説明しています。*6

例えば「夜間に、通常と異なる認証情報の利用が通知された」という場面を設定し、担当者に連絡が届くか、正当な作業かを確認できるか、アクセス制限を誰が判断するかを話し合います。これは本稿で提案する訓練の例です。連絡先の更新漏れや判断権限の曖昧さが見つかれば、実際のインシデントが起こる前に修正できます。

演習では、通知を確認した時点、調査を始めた時点、対応を決めた時点を分けて記録すると、改善すべき箇所を具体化できます。約3時間という他社事例をそのまま自社の目標時間にするのではなく、自社の重要業務と運用体制に即して、対応を遅らせる要因を取り除くことが大切です。

監視からインシデント対応まで、セキュリティ体制を見直したい企業へ

こうした体制を自社だけで維持することが難しい場合は、監視や分析、対応を専門家と分担する方法があります。ブロードバンドセキュリティ（BBSec）の「G-MDR^®」では、セキュリティ対策を統合的に監視・相関分析し、専門エンジニアが24時間365日体制で監視・運用を支援します。アラートの検知だけでなく、その後の調査や対応を含めたセキュリティ体制についてもご相談いただけます。

G-MDR^® について詳しく見る

※外部サイトにリンクします。

セキュリティ対策について相談する

「アラートは検知できても、その後の調査や対応に不安がある」「24時間365日の監視体制を整えたい」といった課題がある場合は、BBSecまでお気軽にご相談ください。

導入を検討する際は、自社のクラウド環境や既存製品から連携できるログ、検知後に実行する対応、社内の承認が必要な操作を具体的に相談するとよいでしょう。すべてのクラウドサービスや復旧作業が無条件に対象になると考えず、自社に必要な監視範囲と対応範囲を確認することが大切です。

【参考情報】

Anthropic「Detecting and countering misuse of AI: September 2026」（https://www.anthropic.com/threat-intelligence-report-september-2026）
Anthropic「Threat Intelligence」（https://www.anthropic.com/threat-intelligence）
AWS「Security best practices in IAM」（https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html）
AWS「Logging data events」（https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html）
AWS「Remediating potentially compromised AWS credentials」（https://docs.aws.amazon.com/guardduty/latest/ug/compromised-creds.html）
AWS「Disabling permissions for temporary security credentials」（https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_disable-perms.html）
AWS「SEC10-BP07 Run simulations」（https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_run_game_days.html）

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

2026年7月1日2026年7月1日

サッポロHD海外2社に不正アクセス ―海外グループ会社を狙うサイバー攻撃リスクとは

サッポロホールディングスが公表した海外グループ会社2社への不正アクセスは、海外拠点を狙ったサイバー攻撃リスクを改めて浮き彫りにしました。現時点では情報漏洩の有無や影響範囲は調査中ですが、海外子会社や現地法人のセキュリティがグループ全体の事業継続や信頼に影響を及ぼす可能性があります。本記事では、本件の概要を整理するとともに、海外拠点が攻撃の入口になりやすい理由や、企業が見直すべき認証管理、ログ監視、脆弱性管理などの対策について解説します。

※本記事は2026年6月30日までに公開された情報もとに作成しています。ご覧いただく時期によっては古い情報となっている場合もありますので、ご承知おきください。

サッポロホールディングス株式会社は2026年6月24日、同社の海外グループ会社2社のシステムに対して不正アクセスが発生したことを公表しました*7。対象となったのは、POKKA PTE. LTD.とSLEEMAN BREWERIES LTD.です。サイバー攻撃の恐れがある不正な通信ログを検知し、初動調査を行った結果、不正アクセスが判明したとされています。

今回の事案で注目すべきなのは、国内本社ではなく海外グループ会社で不正アクセスが確認された点です。企業のグローバル展開が進むなか、海外子会社、海外拠点、現地法人、委託先、販売会社などを含めたセキュリティ対策は、もはや一部門だけの問題ではありません。サイバー攻撃は、もっとも守りが弱い場所から侵入し、グループ全体の信頼や事業継続に影響を及ぼす可能性があります。サッポロホールディングスの公表によると、POKKA PTE. LTD.では2026年6月14日、SLEEMAN BREWERIES LTD.では同年6月17日に不正アクセスを確認しています。安全確保のため、関係するシステムや機器は遮断され、外部専門家の協力のもと原因や影響範囲の調査が進められています。公表時点では、情報漏洩の事実および影響範囲は確認中であり、国内事業への影響は確認されていません。また、2社への不正アクセスについて、現時点で因果関係は認められていないとされています。

サッポロHDの海外グループ会社で何が起きたのか

今回の不正アクセスは、サッポロホールディングスの海外グループ会社であるPOKKA PTE. LTD.とSLEEMAN BREWERIES LTD.において確認されました。POKKA PTE. LTD.は海外飲料事業、SLEEMAN BREWERIES LTD.は海外酒類事業に関係する企業です。サッポロホールディングスは海外酒類事業を北米中心に展開しており、海外飲料事業ではシンガポール、マレーシア、中東など約60か国でPOKKAブランドを展開していると説明しています。

このことから、今回の事案は単なる「海外拠点のトラブル」として片付けるべきものではありません。企業が海外展開を進めるほど、システム、ネットワーク、アカウント、取引先、現地運用体制は複雑になります。国内本社のセキュリティレベルが高くても、海外子会社や現地拠点の監視体制、認証管理、端末管理、ログ管理が十分でなければ、攻撃者にとって侵入口になり得ます。ただし、現時点で公表されている情報からは、ランサムウェア攻撃であったか、特定の攻撃グループが関与したか、どのような情報が外部に流出したかは確認できません。したがって、本件を「情報漏洩事故」や「ランサムウェア被害」と断定することは避ける必要があります。一次ソースから確認できるのは、不正な通信ログの検知、不正アクセスの判明、関係システム・機器の遮断、外部専門家による調査、情報漏洩の有無は確認中という点です。

なぜ海外グループ会社はサイバー攻撃の入口になりやすいのか

海外グループ会社や海外子会社は、サイバー攻撃の入口になりやすい構造的なリスクを抱えています。理由の一つは、拠点ごとにIT環境やセキュリティ運用の成熟度が異なりやすいことです。本社ではEDR、ログ監視、多要素認証、脆弱性管理が整備されていても、海外拠点では現地事情や人員不足により、同じ水準の対策が実施されていないケースがあります。

もう一つの理由は、グループ会社が業務上、本社や他拠点とつながっていることです。販売、製造、物流、会計、メール、クラウドサービスなど、業務に必要な連携がある以上、一つの拠点への不正アクセスが、別拠点への攻撃や認証情報の悪用につながる可能性は否定できません。今回のサッポロホールディングスの発表では2社間の因果関係は認められていないとされていますが、企業一般のリスクとしては、海外拠点を含めたグループ全体のセキュリティ統制が重要になります。

独立行政法人情報処理推進機構（IPA）から公開された「情報セキュリティ10大脅威 2026」でも、組織向け脅威の上位に「サプライチェーンや委託先を狙った攻撃」が挙げられています。これは、攻撃者が必ずしも本丸である大企業や本社を直接狙うのではなく、関係会社、委託先、取引先、外部サービスなどを経由して侵入を試みるリスクが高まっていることを示しています。

不正通信ログの検知が示す「早期発見」の重要性

今回の公表で見落としてはならないのが、「サイバー攻撃の恐れがある不正な通信ログを検知した」という点です。不正アクセスは、必ずしも最初から目に見える被害として現れるわけではありません。ファイルが暗号化される、Webサイトが改ざんされる、顧客情報が公開されるといった被害が起きる前に、攻撃者がネットワーク内で探索や権限拡大を行っている場合があります。

そのため、企業にとって重要なのは、攻撃を完全に防ぐことだけではなく、異常な通信、不審なログイン、通常と異なる端末挙動を早期に見つける体制です。ログを取得していても、監視や分析ができていなければ、攻撃の兆候を見逃してしまいます。特に海外拠点では、時差、言語、現地ベンダーとの契約、運用担当者の違いにより、インシデントの発見や報告が遅れる可能性があります。不正アクセス対策では、ファイアウォールやウイルス対策ソフトだけでは不十分です。EDRによる端末監視、SIEMによるログ分析、SOCによる常時監視、ID管理、多要素認証、脆弱性診断、ペネトレーションテストなどを組み合わせ、攻撃を受けた場合でも早期に検知し、被害を最小化する考え方が求められます。

情報漏洩が確認されていない段階でも対応が必要な理由

サッポロホールディングスは、公表時点で情報漏洩の事実および影響範囲は確認中としています。ここで重要なのは、「漏洩が確認されていない」ことと「リスクがない」ことは同じではないという点です。サイバー攻撃では、外部送信の痕跡、認証情報の悪用、攻撃者の侵入経路、アクセスされたファイル、影響を受けたシステムを慎重に調査する必要があります。

調査中の段階では、企業は被害範囲を過小評価することも、過度に断定することも避けなければなりません。公表内容において「確認中」「影響が確認された場合は速やかに報告」といった表現が使われているのは、調査結果に基づいて正確に説明する姿勢の表れといえます。企業が同様の事案に備えるためには、インシデント発生後の連絡体制、初動対応手順、システム遮断の判断基準、外部専門家への相談ルート、顧客・取引先への説明方針を事前に整備しておくことが重要です。サイバー攻撃を受けてから対応を考えるのではなく、攻撃を受ける前提で準備しておくことが、事業継続と信頼維持につながります。

海外拠点を持つ企業が見直すべきセキュリティ対策

海外グループ会社や海外子会社を持つ企業は、まずグループ全体のIT資産を把握する必要があります。どの拠点にどのシステムがあり、誰が管理し、どのネットワークとつながっているのかが分からなければ、リスクの評価も対策の優先順位付けもできません。

次に重要なのが、認証情報の管理です。海外拠点のVPN、メール、クラウドサービス、業務システムに対して多要素認証を導入し、不要なアカウントや退職者アカウントを放置しないことが求められます。攻撃者は、脆弱性だけでなく、漏洩したID・パスワードや使い回された認証情報を悪用することがあります。

また、脆弱性管理も欠かせません。海外拠点では、本社の管理外にあるサーバ、ネットワーク機器、リモートアクセス環境、業務アプリケーションが残っている場合があります。定期的な脆弱性診断や外部公開資産の棚卸しを行い、攻撃者から見える入口を減らすことが重要です。

さらに、ログ監視とインシデント対応訓練も見直すべきです。不正通信ログを検知しても、その意味を判断できる人がいなければ対応は遅れます。検知、報告、遮断、調査、復旧、再発防止までの流れを整備し、海外拠点を含めて実効性を確認しておく必要があります。

サイバー攻撃対策は「国内本社だけ」では足りない

今回のサッポロホールディングスの事案は、海外グループ会社への不正アクセスとして公表されました。国内事業への影響は確認されていないとされていますが、企業にとっては、海外拠点を含むグループ全体のセキュリティを見直すきっかけになります。

サイバー攻撃は、企業規模や知名度に関係なく、システムの弱点、管理のすき間、監視の遅れを突いてきます。特に海外展開を進める企業では、本社、海外子会社、委託先、取引先、クラウドサービスを含めた全体像を把握し、どこから攻撃されても早期に検知・対応できる体制を作ることが欠かせません。不正アクセス、情報漏洩、ランサムウェア、サプライチェーン攻撃への備えは、もはや情報システム部門だけの課題ではありません。経営リスクとしてセキュリティを捉え、グループ全体で守る仕組みを整えることが、企業の信頼と事業継続を守るための第一歩です。

まとめ

サッポロホールディングスの海外グループ会社2社で確認された不正アクセスは、海外拠点を持つ企業にとって重要な示唆を含んでいます。公表時点では情報漏洩の有無や影響範囲は確認中であり、国内事業への影響も確認されていません。しかし、海外子会社や現地法人を含むグループ全体のセキュリティ管理が求められる時代であることは明らかです。

企業は、海外拠点のセキュリティ対策を現地任せにせず、IT資産の把握、認証管理、脆弱性診断、ログ監視、インシデント対応体制の整備を進める必要があります。攻撃を完全に防ぐことが難しい今、重要なのは、侵入の兆候を早く見つけ、被害を広げない仕組みを持つことです。サイバー攻撃対策を見直す際は、国内本社だけでなく、海外グループ会社、委託先、取引先、クラウド環境まで含めた全体像を確認することが欠かせません。今回の事案は、グローバル企業だけでなく、海外取引や外部委託を行うすべての企業にとって、自社のセキュリティ体制を点検する機会といえるでしょう。

【参考情報】

サッポロビール株式会社「当社の海外グループ会社２社のシステムへの不正アクセス発生について」（2026年6月24日公表）（https://www.sapporobreweries.com/notice/detail/20260624000010.html）

編集責任：木下

BBSecの脆弱性診断・セキュリティ対策支援サービス

BBSec（ブロードバンドセキュリティ）では、Webアプリケーション診断、プラットフォーム診断、クラウド環境診断、脆弱性管理支援など、企業のセキュリティリスクを可視化する各種サービスを提供しています。外部サービスや委託先を含めたセキュリティ体制の見直し、情報漏えいリスクへの備え、インシデント発生前の予防対策を検討している企業は、ぜひご相談ください。

ウェビナー開催のお知らせ

2026年7月8日（水）13:00～14:00「企業は何から対策すべきか？― OWASP Top 10:2025から読み解く、最新のセキュリティリスクと対策の考え方 ―」

2026年7月15日（水）14:00～15:00「AI事業者ガイドライン第1.2版に基づくセキュリティ対策の実践ポイント～生成AIからAIエージェントへ～」

2026年7月22日（水）14:00～15:00「そのIT資産、本当に把握できていますか？～見落としがちなセキュリティリスクと対策の第一歩～」

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

2026年6月25日2026年6月25日

KDDIメールシステムに不正アクセス、最大1,422万件漏えいの可能性―企業が見直すべき「共通基盤リスク」とは

「KDDIメールシステムに不正アクセス、最大1,422万件漏えいの可能性」アイキャッチ画像

KDDI株式会社（以降、KDDI）がISP事業者向けに提供するメールシステムで不正アクセスが確認され、BIGLOBEメール、@niftyメール、J:COM NET、コミュファ光、ピカラ光、CPIなど複数のメールサービスにおいて、メールアドレスやパスワードが外部に漏えいした可能性があることが公表されました。漏えいした可能性のある情報は最大1,422万件にのぼり、現在利用中のユーザーだけでなく、解約済みの顧客や一定期間利用のない休眠アカウントも含まれるとされています。

今回の事案で注目すべきなのは、単に「メールアドレスとパスワードが漏えいした可能性がある」という点だけではありません。KDDIが提供するISP向けの共通メール基盤に不正アクセスが発生したことで、複数の事業者・複数のサービスに影響が広がった点が重要です。これは、現代の企業システムにおいて避けて通れない「外部委託先リスク」「サプライチェーンリスク」「共通基盤リスク」を象徴する事案といえます。

本記事では、KDDIの公式発表および関係各社の公表情報をもとに、今回の不正アクセスの概要、影響範囲、利用者が取るべき対応、そして企業が学ぶべきセキュリティ対策について解説します。

KDDIのISP向けメールシステムで何が起きたのか

KDDIは、インターネットサービスプロバイダー、いわゆるISP事業者向けに提供しているメールシステムにおいて、不正アクセスを受けていたことを2026年6月17日に確認しました。KDDIの発表によると、不正アクセスの原因は、同システムで利用していた第三者製ソフトウェアの脆弱性を悪用されたことによるものです。

KDDIは同日、被害拡大を防ぐためにシステムを改修し、不正アクセスの被疑箇所を特定したうえで、技術的な防御措置を実施したとしています。また、個人情報保護委員会や総務省への報告・相談を含む必要な対応も進めていると説明しています。

現時点で公表されている漏えい可能性のある情報は、対象メールサービスで作成されたメールボックスに紐づくメールアドレスとパスワードです。件数は最大1,422万件とされており、この数字には解約済みの顧客や、一定期間利用していない休眠アカウントも含まれています。なお、パスワードの中には、ハッシュ化または暗号化されたものも含まれるとされています。

ここで注意したいのは、最大1,422万件という数字が「実際に漏えいした件数」と確定したものではないという点です。KDDIは調査継続中であるため、現時点では漏えいした可能性のある最大値として公表されています。

影響を受けるメールサービス

今回の不正アクセスで対象とされているのは、KDDIがISP事業者向けに提供していたメールシステムを利用する複数のメールサービスです。KDDIの発表では、STNetのピカラ光サービス、ピカラモバイルサービス、お仕事ピカラサービスに係るメールサービス、KDDIウェブコミュニケーションズのレンタルサーバー「CPI」のメールサービス、JCOMのJ:COM NETおよびケーブルテレビ事業者向けメールサービス、中部テレコミュニケーションのコミュファ光・ビジネスコミュファのメールサービス、ニフティの@niftyメール、ビッグローブのBIGLOBEメールが対象として挙げられています。

各社の発表を見ても、KDDIが提供する基盤システムを利用していたこと、第三者製ソフトウェアの脆弱性悪用によって不正アクセスが発生したこと、メールアドレスやメールパスワードなどが漏えいした可能性があることが説明されています。BIGLOBEでは、BIGLOBEメールアドレス、BIGLOBE IDおよびパスワードが漏えいした可能性があると公表しています。@niftyでは、メールアドレスおよびメールパスワードが第三者に漏えいした可能性があるとして、利用者にメールパスワードの変更を求めています。

このように、ひとつの基盤システムに起きた不正アクセスが、複数ブランドの利用者に影響する形になっています。これは、クラウドサービス、外部委託システム、SaaS、共通認証基盤などを活用する多くの企業にとっても、決して他人事ではありません。

なぜメールアドレスとパスワードの漏えいは危険なのか

メールアドレスとパスワードの漏えいは、単なる連絡先情報の流出にとどまりません。メールアカウントは、多くのWebサービスや業務システムにおいて本人確認やパスワード再設定の起点として使われています。そのため、メールアカウントに不正ログインされると、他サービスへの侵入、なりすまし、フィッシングメールの送信、業務情報の閲覧など、被害が連鎖するおそれがあります。

特に危険なのは、同じパスワードを複数のサービスで使い回しているケースです。攻撃者は、漏えいしたメールアドレスとパスワードの組み合わせを使い、別のWebサービスやクラウドサービスへのログインを試みることがあります。これは一般にパスワードリスト攻撃、またはクレデンシャルスタッフィングと呼ばれる手口です。

今回の件では、対象情報にメールパスワードが含まれる可能性があるため、利用者は対象メールサービスのパスワードを変更するだけでなく、同じ、または似たパスワードを使用している他サービスについても見直す必要があります。メール、ECサイト、SNS、クラウドストレージ、業務用SaaSなどでパスワードを使い回している場合は、早急な変更が望まれます。

利用者が今すぐ取るべき対応

対象サービスを利用している可能性がある場合、まずは各ISP事業者やサービス提供会社の公式案内を確認することが重要です。検索結果やSNS上のリンクからではなく、公式サイト、公式サポートページ、契約時に案内された会員ページなどから確認することで、フィッシングサイトに誘導されるリスクを下げられます。

次に、対象となるメールパスワードを変更します。@niftyのように、一定期限までに変更が確認できない場合、システム側でメールパスワードを順次無効化すると案内している事業者もあります。Outlook、Macメール、スマートフォンのメールアプリなどを利用している場合は、Web上でパスワードを変更した後、メールソフト側に保存されているパスワードも更新する必要があります。

また、メールパスワードとログインパスワードを同じ文字列にしている場合や、他のサービスでも同じパスワードを使っている場合は、それらも変更すべきです。メールアカウントは、他サービスのパスワード再設定メールを受け取る重要な入口です。メールアカウントの安全性が崩れると、他のアカウントにも被害が広がる可能性があります。加えて、しばらくの間は不審なメールへの警戒が必要です。今回の不正アクセスに便乗し、「パスワード変更が必要です」「アカウントを確認してください」などと称する偽メールが送られる可能性もあります。本文中のURLを安易にクリックせず、ブックマークや公式アプリ、公式サイトから手続きすることが大切です。

「委託先だから安全」ではないという現実

今回の事案は、企業のセキュリティ対策を考えるうえで重要な教訓を含んでいます。多くの企業は、自社の業務効率化やコスト削減、専門性の確保を目的に、メール基盤、クラウドサービス、決済システム、顧客管理システム、認証基盤などを外部サービスに委託しています。これは現代の事業運営では自然な選択です。

しかし、外部サービスを利用しているからといって、リスクが自社から消えるわけではありません。委託先や共通基盤でインシデントが発生すれば、自社の顧客情報、業務データ、ブランド信頼にも影響が及びます。特に、複数の事業者が同じ基盤を利用している場合、一箇所の脆弱性が広範囲のサービスに波及する可能性があります。企業に求められるのは、外部委託先を「便利なサービス提供者」として見るだけでなく、自社のセキュリティ境界の一部として管理する姿勢です。契約時のセキュリティ要件、脆弱性対応の体制、インシデント発生時の報告フロー、影響範囲の確認方法、利用者への通知方針などを事前に整理しておかなければ、実際に問題が起きた際の初動対応が遅れてしまいます。

第三者製ソフトウェアの脆弱性はなぜ狙われるのか

KDDIは今回の不正アクセスについて、第三者製ソフトウェアの脆弱性が悪用されたと説明しています。現時点でソフトウェア名やCVE番号などの詳細は公表されていませんが、一般論として、第三者製ソフトウェアの脆弱性は攻撃者にとって非常に狙いやすいポイントです。

企業システムは、自社開発のプログラムだけで構成されているわけではありません。OS、ミドルウェア、メールサーバー、認証機能、管理画面、ライブラリ、監視ツールなど、さまざまな外部コンポーネントに支えられています。これらのどこかに脆弱性が存在し、修正が遅れれば、攻撃者に侵入口を与えることになります。特に、インターネットからアクセス可能なシステムや、多数の顧客情報を扱う共通基盤では、脆弱性管理の遅れが大きなインシデントにつながりかねません。脆弱性情報を収集し、影響有無を確認し、必要なパッチ適用や回避策を迅速に実施する体制が不可欠です。

企業が見直すべきセキュリティ対策

今回のような不正アクセスや情報漏えいリスクに備えるには、単にパスワードを強化するだけでは不十分です。まず重要なのは、自社がどの外部サービスや委託先に、どのような情報を預けているのかを把握することです。顧客情報、メールアドレス、認証情報、業務データ、ログ情報など、預託している情報の種類と影響範囲を整理しておく必要があります。

次に、委託先や利用サービスに対するセキュリティ確認を継続的に行うことが求められます。契約時だけでなく、運用中も脆弱性対応、インシデント報告体制、アクセス制御、ログ管理、バックアップ、暗号化、権限管理などの観点で確認を続けることが重要です。

さらに、自社側でも認証情報の管理を強化する必要があります。多要素認証の導入、パスワード使い回しの禁止、不要アカウントの棚卸し、退職者や休眠アカウントの削除、権限の最小化などは、基本的でありながら効果の高い対策です。今回の件で解約済みや休眠アカウントも最大件数に含まれていることは、使われていないアカウントや古いデータの管理がいかに重要かを示しています。最後に、インシデント発生時の対応手順を事前に整備しておくことも欠かせません。誰が影響範囲を確認し、誰が顧客へ通知し、どのタイミングで監督官庁へ報告し、どのように再発防止策を公表するのか。こうした手順が曖昧なままでは、被害の拡大だけでなく、顧客からの信頼低下にもつながります。

メール漏えいではなくサプライチェーンリスクの問題

今回のKDDIメールシステム不正アクセスは、メールアドレスとパスワードの漏えい可能性が注目されています。しかし、企業のセキュリティ担当者や経営層が本当に見るべきポイントは、その背後にある構造です。

ひとつの共通基盤に脆弱性があり、そこを攻撃されることで、複数のISP事業者やメールサービスに影響が広がりました。これは、外部委託やクラウド利用が進む現在の企業環境において、どの企業にも起こり得る問題です。自社のシステムが直接攻撃されていなくても、委託先、取引先、共通基盤、利用中のSaaSで起きたインシデントが、自社の顧客対応や事業継続に影響する可能性があります。セキュリティ対策は、もはや自社ネットワークの内側だけを守ればよい時代ではありません。外部サービスを含めた全体像を把握し、脆弱性管理、委託先管理、認証情報管理、インシデント対応を一体として整備することが求められます。

まとめ

KDDIのISP事業者向けメールシステムに対する不正アクセスでは、メールアドレスやパスワードが最大1,422万件漏えいした可能性があると公表されました。対象にはBIGLOBEメール、@niftyメール、J:COM NET、コミュファ光、ピカラ光、CPIなど複数のメールサービスが含まれており、共通基盤に起きた不正アクセスが広範囲に影響する構図となっています。

利用者は、各事業者の公式案内を確認し、対象となるメールパスワードを速やかに変更することが重要です。同じパスワードを他サービスで使い回している場合は、あわせて変更し、不審なメールや偽のパスワード変更案内にも注意が必要です。

企業にとっては、今回の事案を「大手通信会社の情報漏えい」として見るだけでは不十分です。第三者製ソフトウェアの脆弱性、外部委託先の管理、共通基盤への依存、休眠アカウントの扱い、インシデント発生時の連絡体制など、自社のセキュリティ運用を見直すきっかけにすべきです。サイバー攻撃は、自社の真正面から来るとは限りません。取引先、委託先、クラウドサービス、共通基盤を経由して影響が及ぶ時代だからこそ、企業にはサプライチェーン全体を見据えたセキュリティ対策が求められています。

【参考情報】

KDDI株式会社、ニュースリリース「ISP事業者向けメールシステムに対する不正アクセスの発生について」（2026年6月23日公開）（https://newsroom.kddi.com/news/assets/2026/kddi_nr_s-71_4593/kddi_nr_s-71_4593_pdf_01.pdf）
ビッグローブ株式会社（BIGLOBE）、ニュース「「BIGLOBEメール」への不正アクセス発生のお詫びとご報告」（2026年6月23日公開）（https://www.biglobe.co.jp/pressroom/release/2026/06/260623-a）
ニフティ株式会社「＠nifty」お知らせ「【第一報】当社メールサービスへの不正アクセスの発生について」（2026年6月23日公開）（https://support.nifty.com/topics/2026/06232410）

編集責任：木下

BBSecの脆弱性診断・セキュリティ対策支援サービス

ウェビナー開催のお知らせ

2026年7月1日（水）13:00～14:00「ランサムウェア対策は「侵入前提」で考える―最新事例から学ぶ、企業に求められるリスク把握と対策の考え方―」

2026年7月8日（水）13:00～14:00「企業は何から対策すべきか？― OWASP Top 10:2025から読み解く、最新のセキュリティリスクと対策の考え方 ―」

2026年7月15日（水）14:00～15:00「AI事業者ガイドライン第1.2版に基づくセキュリティ対策の実践ポイント～生成AIからAIエージェントへ～」

2026年7月22日（水）14:00～15:00「そのIT資産、本当に把握できていますか？～見落としがちなセキュリティリスクと対策の第一歩～」

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

2026年5月28日2026年6月1日

ゼロデイ脆弱性とは？最新事例と企業が取るべき対策を解説

ゼロデイ脆弱性は、修正パッチが提供される前に悪用される極めて危険な脆弱性です。ChromeやFirefox、VPN機器など、企業で日常的に利用される製品でも継続的に確認されており、情報漏えいや業務停止につながるケースもあります。本記事では、ゼロデイ脆弱性の基本的な仕組みや実際の被害事例、従来対策が通用しにくい理由を整理しながら、企業に求められる現実的な対策について解説します。

ゼロデイ脆弱性が実際にどのように悪用されるのかについては、以下の記事で詳しく解説しています。
「世界で多発するゼロデイ攻撃とは？Apple・Google・Ciscoを襲った脆弱性の実態と対策」

本記事は2026年5月時点の情報をもとに作成しています。記載している脆弱性情報やCVE詳細は、公開後に内容が更新される場合があります。最新情報は各ベンダーおよびNVD・CISAの公式情報をご確認ください。

はじめに

ChromeやFirefoxなど、日常業務で広く使われている主要ブラウザでも、ゼロデイ脆弱性は繰り返し確認されています。ゼロデイ脆弱性とは、製品ベンダーや利用企業が十分な修正猶予を持てないまま悪用される、極めて危険度の高い脆弱性です。企業にとってゼロデイ脆弱性が厄介なのは、単に危険な脆弱性であるという点だけではありません。多くの場合、攻撃が確認された時点では、すでに悪用が始まっているか、修正パッチの適用が間に合っていない状態です。つまり、通常のパッチ管理や既知のマルウェア検知だけでは、防御が後手に回る可能性があります。 Webブラウザ、VPN機器、セキュリティ製品、業務アプリケーション、開発支援ツールなど、企業活動を支えるソフトウェアの多くは、常に外部との接点を持っています。そのため、ゼロデイ脆弱性は情報漏えい、業務停止、信用毀損、取引先への影響といったビジネスリスクに直結します。まず押さえたいのは、ゼロデイ脆弱性を悪用した攻撃に対し、完全に避けるのではなく、発生を前提に、侵入されにくく、侵入されても早期に検知し、被害を抑え込める体制を整えることです。

ゼロデイ脆弱性とは何か

ゼロデイ脆弱性とは、製品ベンダーや利用者がまだ十分に把握していない、または修正パッチが提供されていない脆弱性を指します。「ゼロデイ」という言葉は、攻撃者に悪用される可能性があるにもかかわらず、防御側に残された対応猶予が実質的にゼロ日であることに由来します。ここで整理しておきたいのが、「脆弱性」と「攻撃」は同じものではないという点です。脆弱性は、ソフトウェアやシステムに存在するセキュリティ上の欠陥です。一方で、ゼロデイ攻撃は、その未知または未修正の欠陥を悪用して、情報の窃取、権限昇格、不正コード実行、システム侵入などを行う攻撃行為を指します。NIST（米国立標準技術研究所）では、ゼロデイ攻撃を「これまで知られていなかったハードウェア、ファームウェア、ソフトウェアの脆弱性を悪用する攻撃」と定義しています。

たとえば、あるブラウザに不正なHTMLページを処理した際に任意のコード実行につながる欠陥があったとします。その欠陥自体がゼロデイ脆弱性であり、攻撃者が細工したWebページへ利用者を誘導して実際に悪用すれば、それがゼロデイ攻撃になります。CVEはこうした脆弱性を識別するための共通番号であり、NVD（米国国立脆弱性データベース）ではCVEプログラムについて、「特定のコードベースで確認された脆弱性を参照するための辞書、または用語集のような仕組みだ」と説明しています。

なぜゼロデイ脆弱性は危険なのか

ゼロデイ脆弱性が危険視される最大の理由は、修正パッチが存在しない、または広く適用される前に攻撃が始まることです。一般的な脆弱性対応では、ベンダーが脆弱性情報を公開し、修正パッチを提供し、企業が影響範囲を確認して適用するという流れになります。しかしゼロデイの場合、この順番が崩れます。攻撃者が先に脆弱性を把握し、攻撃に利用してから、ベンダーや利用者が気づくことがあるためです。もう一つの問題は、従来型のシグネチャ検知が効きにくいことです。シグネチャ型のセキュリティ対策は、既知のマルウェアや既知の攻撃パターンを検出するうえでは有効です。しかし、まだ十分に解析されていない攻撃コードや、新しい悪用手法に対しては、検知が遅れる可能性があります。NISTの関連文献でも、「ゼロデイ攻撃は未知の脆弱性を悪用するため従来のシグネチャ型検知では事前に攻撃シグネチャを用意できず有効性に限界がある*2」とされています。

ゼロデイ攻撃は、標的型攻撃にも使われやすい傾向があります。攻撃者にとって、未修正の脆弱性は価値の高い侵入口です。特に、ブラウザ、VPN、ファイアウォール、メールサーバ、リモートアクセス製品、エンドポイント管理製品などは、企業ネットワークの入口や重要な業務環境とつながっているため、攻撃が成功した場合の影響が大きくなります。ビジネス面では、ゼロデイ脆弱性の悪用は情報漏えい、業務停止、顧客対応コストの増加、監督官庁や取引先への報告、ブランド信用の低下などに発展します。攻撃の起点が一台の端末や一つのWebアクセスであっても、その後に認証情報の窃取、横展開、機密情報の持ち出しが行われれば、被害は組織全体へ拡大します。

実際の被害事例

Google Chromeで相次いだゼロデイ脆弱性

ゼロデイ脆弱性の代表的な事例として、Google Chromeの脆弱性が挙げられます。Chromeは多くの企業で標準ブラウザとして利用されており、Webメール、SaaS、業務システム、クラウド管理画面などへのアクセスにも使われています。そのため、Chromeのゼロデイ脆弱性は、単なる個人利用者向けブラウザの問題ではなく、企業の業務端末リスクとして捉える必要があります。

2025年には、Chromeで悪用が確認されたゼロデイ脆弱性が複数回修正されました。BleepingComputerでは、2025年から2026年にかけてChromeは複数のゼロデイ脆弱性を修正したと報じています*2。2026年2月には、CVE-2026-2441が修正されました。NVDによれば、この脆弱性はChromeのCSSにおけるUse After Free（解放済メモリの再利用）の問題であり、 Google Chrome 145.0.7632.75より前のバージョンでは、細工されたHTMLページを介してリモート攻撃者がサンドボックス内で任意のコードを実行できる可能性がありました。GoogleのChrome Releasesでも、この脆弱性について「実際に悪用が確認されている」旨が記載されています。2026年3月には、CVE-2026-3909とCVE-2026-3910が修正されました。CVE-2026-3909は「Skia（Chromeが使用するグラフィック処理ライブラリ）における境界外の書き込み」で、細工されたHTMLページを介して境界外メモリアクセスにつながる可能性があります。CVE-2026-3910は「V8（ChromeのJavaScript実行エンジン）における不適切な実装」で、細工されたHTMLページを介してサンドボックス内で任意のコード実行が可能となるおそれがありました。GoogleはCVE-2026-3910について、「実際に悪用が確認されている」と公表しています。また、2026年3月末にはCVE-2026-5281も修正されています。NVDによれば、これはChromeのDawnにおける解放済メモリの再利用の脆弱性で、レンダラープロセスが侵害された状態で、細工されたHTMLページを通じて任意のコード実行につながる可能性があるものです。Googleはこの脆弱性についても、「実際に悪用が確認されている」と公表しています。

これらの事例が示しているのは、Webブラウザが単なる閲覧ツールではなく、企業ネットワークへの入口になり得るということです。利用者が業務中にWebサイトを閲覧する、SaaSへアクセスする、メール内のリンクを開くといった日常的な操作が、ゼロデイ攻撃のきっかけになる可能性があります。

OpenAI Codexに関するサンドボックス迂回の事例

近年は、開発支援ツールやAI関連ツールもゼロデイリスクの対象になっています。Zero Day Initiativeは2026年4月、OpenAI Codexに関するZDI-26-305を公開しました*3。この脆弱性は、影響を受けるOpenAI Codex環境においてサンドボックスを迂回できる可能性があるものとされ、攻撃には、「標的ユーザーが悪意あるJavaScriptを含むリポジトリをCodexで処理する必要がある」と説明されています。OpenAI Codex CLIでは2025年にも、サンドボックス設定ロジックの問題により、意図したワークスペース境界を迂回し、Codexプロセスが権限を持つ範囲で任意のファイル書き込みやコマンド実行につながる可能性がある脆弱性が、GitHub Security Advisoryで公開されています*4。この問題はCodex CLI 0.39.0で修正され、利用者には更新が推奨されています。

この事例から分かるのは、ゼロデイ脆弱性がOSやブラウザだけの問題ではないということです。開発者が利用するCLIツール、AIエージェント、コード生成支援ツール、CI/CD環境も、企業の重要な攻撃面になりつつあります。特に、ソースコード、認証情報、クラウド設定、APIキーにアクセスする可能性があるツールでは、サンドボックスや権限管理を過信しない運用が必要です。

ゼロデイ攻撃の仕組み

※ゼロデイ攻撃では、脆弱性公開前や修正前に攻撃が始まるため、従来型のシグネチャ検知だけでは防御が難しい場合があります。

ゼロデイ攻撃は、脆弱性の発見から攻撃実行までが非常に速い場合があります。攻撃者は、ソフトウェアの不具合を独自に発見することもあれば、脆弱性情報が闇市場や限定的なコミュニティで売買されることもあります。その後、攻撃者はその脆弱性を悪用するエクスプロイトコードを作成し、標的組織に対して攻撃を実行します。まず、未公開または未修正の脆弱性が発見されるところから始まります。次に、その脆弱性を悪用するための攻撃コードが作成されます。ブラウザの脆弱性であれば、細工されたHTMLページやJavaScriptが使われることがあります。VPNや外部公開サーバの脆弱性であれば、インターネット越しに直接攻撃が行われることもあります。攻撃が成功すると、攻撃者は端末やサーバへ侵入し、認証情報の取得、権限昇格、内部ネットワークへの横展開を試みます。その後、機密情報の収集、データの持ち出し、ランサムウェアの展開、バックドア設置などへ進む可能性があります。

ゼロデイ攻撃の基本的な仕組みについては、以下の記事でも詳しく解説しています。
「世界で多発するゼロデイ攻撃とは？Apple・Google・Ciscoを襲った脆弱性の実態と対策」

従来対策が通用しない理由

ゼロデイ脆弱性への対応で難しいのは、従来のセキュリティ対策が必ずしも十分に機能しないことです。もちろん、ウイルス対策ソフト、ファイアウォール、パッチ管理、メールセキュリティ、URLフィルタリングといった対策は今でも重要です。しかし、ゼロデイ攻撃では、これらをすり抜ける可能性があります。シグネチャ型対策は、既知の攻撃には強い一方で、未知の攻撃には限界があります。攻撃コードが新しく、まだ検体や攻撃パターンが共有されていない場合、検知ルールが存在しないことがあります。さらに、攻撃者は正規のWeb通信、正規のプロセス、正規の認証情報を利用して侵入後の活動を行うため、外形上は通常の業務通信に見えることもあります。また、境界防御だけに依存した対策では対応が難しいケースも増えています。クラウドサービスやリモートワークの拡大により、従来の「社内は安全」という前提だけでは、ゼロデイ攻撃のような未知の脅威への対応が難しくなっています。ゼロデイ攻撃では、社内端末、クラウドアカウント、開発端末、外部公開資産のどこからでも侵入口が生まれる可能性があります。

ゼロトラストの考え方を含め、従来型セキュリティ対策の課題については、こちらの記事でも詳しく解説しています。
「ゼロトラストセキュリティ -今、必須のセキュリティモデルとそのポイント-」

ゼロデイ脆弱性への対策

ゼロデイ脆弱性への対策では、未知の攻撃を完全に防ぐことだけでなく、侵入後の被害を最小限に抑えるアプローチが重要です。ゼロトラストに基づく権限管理や多要素認証に加え、EDRやXDRによる侵入後の検知、ASMによる攻撃面の把握、SOCによる継続監視などを組み合わせた多層的な対策が求められます。

ゼロデイ攻撃対策を支援するBBSecのアプローチ

ゼロデイ攻撃へ備えるには「脆弱性情報を知ること」だけでなく、「自社がどの製品を利用しているのか」「どこが外部公開されているのか」を知ることで自社環境への影響を迅速に把握し、継続的に監視・対応できる体制を持つことが重要になります。

ブロードバンドセキュリティ（BBSec）では、EDR-MSSによる侵入後の検知・対応、G-MDRによる高度な脅威分析、ASMによる攻撃面の可視化を通じて、企業のゼロデイ対策を支援しています。ゼロデイ脆弱性への備えを強化したい方は、以下のサービスページもあわせてご覧ください。

アタックサーフェス調査 -SQAT^® ASM-（攻撃面の可視化・管理）
エンドポイントセキュリティ EDR-MSS（侵入後の検知・対応）
G-MDR^®（高度な脅威分析・対応）

ASM（アタックサーフェス管理）の考え方や、攻撃面を継続的に把握する重要性については、こちらの記事でも詳しく解説しています。
「脆弱性管理とIT資産管理 -サイバー攻撃から組織を守る取り組み-」

まとめ

ゼロデイ脆弱性は、主要ブラウザやVPN機器、業務ソフトウェアなど、企業が利用するさまざまな環境で発生する可能性があります。ゼロデイ攻撃による被害を抑えるためには、パッチ管理だけでなく、ゼロトラストに基づく権限管理、EDRやXDRによる侵入後の検知、ASMによる攻撃面の把握、SOCによる継続監視などを組み合わせた多層的な対策が求められます。

【参考情報】

NIST（米国立標準技術研究所）Information Technology Laboratory Computer Security Resource Center「zero day attack」（https://csrc.nist.gov/glossary/term/zero_day_attack）
NVD（米国国立脆弱性データベース）「CVEs and the NVD Process」（https://nvd.nist.gov/general/cve-process）
Zero Day Initiative (ZDI)「(0Day) OpenAI Codex Sandbox Escape Vulnerability」
https://www.zerodayinitiative.com/advisories/ZDI-26-305/

ウェビナー開催のお知らせ

2026年6月3日（水）14:00～15:00「金融機関の対応事例に学ぶPQC移行の進め方と実務ポイント」

2026年6月10日（水）14:00～14:30「Webサイトの見えない脅威を可視化する外部タグ・サードパーティースクリプトの監視対策」

最新情報はこちら

年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

サービスに関する疑問や質問はこちらからお気軽にお問合せください。

編集責任：木下

Security NEWS TOPに戻る
バックナンバー TOPに戻る

2026年1月29日2026年1月30日

2025年4Q KEVカタログ掲載CVEの統計と分析

米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）から公開されている「KEVカタログ（Known Exploited Vulnerabilities）」は、実際に攻撃に悪用された脆弱性の権威あるリストとして、組織のセキュリティ対策の優先順位付けに不可欠なツールとなっています。本記事では、KEVカタログに2025年10月1日～12月29日に登録・公開された脆弱性の傾向を整理・分析します。

本記事は2025年1Q：第1四半期～3Q：第3四半期の分析レポートに続く記事となります。過去記事もぜひあわせてご覧ください。
「2025年1Q KEVカタログ掲載CVEの統計と分析」
「2025年2Q KEVカタログ掲載CVEの統計と分析」
「2025年3Q KEVカタログ掲載CVEの統計と分析」

はじめに

2025年第四四半期（10月～12月）における既知の悪用された脆弱性の統計分析レポートです。本記事は最新のデータから見える傾向を解説します。前回までの分析ではMicrosoftやCisco製品への攻撃の多さや古い脆弱性が依然悪用されている実態が明らかとなりました。今回は第四四半期のデータを掘り下げ、攻撃トレンドの変化やリスクの深刻度を検証します。経営層に有用な全体像の把握と、技術担当者向けの詳細な分析を両立させ、組織が取るべき対策についても提言します。

2025年4Qの統計データ概要

2025年第四四半期に新たにKEVに追加・公開された脆弱性は62件でした。第三四半期（51件）から増加に転じ、2025年1月～12月29日時点で245件（2024年累計186件から約30%増）となっています。まずは月別推移や脆弱性の種類・深刻度について、データの全体像を俯瞰し、特にランサムウェア関連の脆弱性や影響度の大きい脆弱性、自動化攻撃が可能な脆弱性に着目します。

登録件数の月別推移

10月に追加件数が31件と突出し、11月は11件、12月は20件となりました（図1参照）。月ごとのばらつきが大きく、10月に集中して脆弱性が公表・追加されたことが分かります。これは各メーカーの定例アップデート直後に既知悪用事例が判明したケースが多いためと考えられ、特定の月に攻撃が急増する傾向が引き続き見られます。4Q全体では3Qからの増加により、年末にかけて脅威が再び活発化したことを示唆します。

主要ベンダー別の内訳

4Qに新規追加された脆弱性のベンダーを見ると、Microsoftが10件と突出して最多でした。次いでOracle、Fortinet、Gladinetが各3件、Google、Samsung、Kentico、Android、OpenPLC、Dassault Systèmes、WatchGuardなどが各2件で続きます。3Qで多かったCiscoは1件に留まり、Microsoft製品への攻撃集中が際立つ結果です。一方、新たにGladinet（クラウドストレージ）やOpenPLC（産業制御システム）といったベンダーの脆弱性が複数追加されており、攻撃対象の幅が広がっていることが分かります。これは企業向けソフトウェアから家庭用/産業用機器まで攻撃者の関心が及んでいることを示し、ITインフラ全体で対策が必要です。

脆弱性タイプ（CWE）の分布

CWE	件数	脆弱性タイプ
CWE-787	5	範囲外の書き込み
CWE-78	4	OSコマンドインジェクション
CWE-862	3	認可の欠如
CWE-284	3	不適切なアクセス制御
CWE-20	2	不適切な入力検証
CWE-416	2	解放済みメモリの使用
CWE-434	2	危険なタイプのファイルのアップロード許可
CWE-22	2	パストラバーサル
CWE-79	2	クロスサイトスクリプティング (XSS)
CWE-306	2	重要な機能の使用に対する認証の欠如

2025年4Q CWE分布表

悪用された脆弱性の種類としては、範囲外の書き込み（CWE-787）が5件で最多となりました。次いでOSコマンドインジェクション（CWE-78）が4件で続きます。認証・認可に関わる欠陥（CWE-862, CWE-284, CWE-306）も合計8件と多く、アクセス制御の不備が依然として攻撃者に悪用されやすいことが分かります。また、メモリ管理上の欠陥である解放済みメモリの使用（CWE-416）や範囲外の書き込み（CWE-787）など、低レベルのプログラムバグも上位を占めており、メモリ安全性の欠陥が攻撃に利用されるケースが増えています。

過去頻出したパストラバーサル（CWE-22）も複数含まれており、データから見ると、入力検証検証の不備を突いた攻撃（インジェクション系）、認証・認可の不備、そしてメモリ安全性の欠如という3つの古典的な脆弱性カテゴリーが依然悪用の中心であることが読み取れます。

攻撃の自動化容易性（Automatable）

4Qに登録された脆弱性のうち、約48%（30件）は自動化攻撃が容易である「Yes」と分類されました。これは自動スキャンやマルウェアボットによる大規模攻撃に適した脆弱性が増えたことを意味します。残る52%（32件）は「No」（手動操作や特定条件が必要）ですが、スクリプトキディでも悪用できる脆弱性が半数近くを占める状況は深刻です。（2025年年間累計は図3参照）攻撃者は脆弱性を迅速にスキャン・悪用する自動化ツールを駆使するため、組織側も早期パッチ適用と防御網の自動化で対抗する必要があります。

技術的影響範囲（Technical Impact）

62件中55件（約89%）は「Total」（＝脆弱性を突かれるとシステムを完全制御されてしまう深刻な影響を持つもの）でした。（図3参照）。攻撃者がシステム全面乗っ取り可能な脆弱性を優先的に悪用していることがわかります。特に単独で完全権限を奪える脆弱性は魅力的な標的であり、一方部分的な影響に留まる脆弱性も他のTotalな脆弱性と組み合わせて攻撃チェーンに利用される恐れがあります。

※注）KEVカタログ掲載時点で実害確認済みである以上、CVSSスコアの大小や影響範囲の違いに関わらず優先度高く対処すべきである点に留意が必要です。

CVSSスコア分布

4Qに追加された脆弱性のCVSS基本値は、最大が10.0（3件）、9.8が数件含まれ、9.0以上の「Critical（緊急）」帯が約39%（24件）、7.0～8.9の「High（高）」帯が約52%（32件）を占めました。残り約10%がMedium以下です。平均値は8.48で、前四半期同様に高スコアの欠陥が大半を占めています。3QではCVSS10.0が5件含まれていましたが、4QではCritical帯比率は維持しつつ極端に満点の脆弱性は減少しました。それでもなおHigh以上が全体の9割を超えており、KEVカタログに登録される脆弱性がいかに深刻度の高いものに偏っているかを裏付けています。Criticalでなくとも攻撃に利用され得る（実際に悪用された）ことを示すデータでもあり、スコアに油断せず注意が必要です。

攻撃手法・影響の深掘り分析

前述の統計情報を踏まえ、4Qに観測された攻撃の特徴や脅威動向をさらに分析します。ランサムウェアなどサイバー犯罪による悪用事例や、国家支援型グループ（APT）の関与、古い脆弱性の再悪用など、データから読み取れるポイントを考察します。

実際にランサムウェア攻撃に悪用された脆弱性

3Qと同様、ランサムウェア攻撃での悪用が確認された事例はごく少数に留まります。4Qに追加された62件中、実際にランサムウェアに悪用されたと判明しているのは3件（約5%）でした。具体的にはオラクルの Oracle Concurrent Processing における認証に関する脆弱性／Oracle E-Business Suite（EBS）のSSRF（サーバサイドリクエストフォージェリ）の脆弱性（CVE-2025-61882および61884）やReact Server Componentsにおける認証不要のリモートコード実行の脆弱性（CVE-2025-55182）がランサムウェア攻撃で利用された例です。これらはいずれも企業の基幹システムや広く使われるフレームワークに関わる欠陥で、金銭目的の攻撃者に狙われたと考えられます。ただしKEVカタログ全体で見ると、依然として国家主体・高度なAPT攻撃での悪用例が多く、ランサムウェアによる事例は氷山の一角です。これは、KEVカタログが単なる理論上の危険性ではなく、「現在進行形で利用されている攻撃手法」を反映したリストであることを示しています。高度な攻撃者はゼロデイ脆弱性を含む様々な欠陥を悪用しており、ランサムウェア以外の脅威にも引き続き注意が必要です。

古い脆弱性の再注目

4Qに新規登録された脆弱性の中には、2024年以前に発見されたものが17件（約27%）含まれていました。最も古いものは2010年公表のMicrosoft製品の脆弱性（CVE-2010-3962）で、15年以上前の欠陥が今になって攻撃に利用されたことになります。前四半期にも2020年公表のD-Link製品脆弱性が複数追加されており、サポート切れの古い機器・ソフトが依然として攻撃対象になる実態が浮き彫りです。こうした古い脆弱性はパッチ未適用のまま放置されている資産が狙われており、攻撃者は年代を問わず利用可能な欠陥を有効活用しています。組織内に残存するレガシーシステムの脆弱性管理を怠ると、想定外に古いバグで侵入を許すリスクがあることに注意が必要です。

脆弱性悪用の手口

攻撃者の手口としては、引き続きリモートコード実行（RCE）や権限昇格といった直接的にシステム乗っ取りに繋がる攻撃が顕著です。例えば前述のCWE分布にあるCWE-787, CWE-416などのメモリ破壊型脆弱性は、悪用された場合、ターゲットプロセス内で任意コード実行やサービス停止を引き起こします。またCWE-78等のコマンドインジェクションは、サーバー上で攻撃者のコマンドを実行させる手段として多用されています。4Qにはこれらテクニカルな攻撃に加え、認証・認可の不備（CWE-306/862等）を突いて管理者権限を不正取得するケースも見られ、攻撃パターンは多岐に及びます。総じて攻撃者は最も効率よく高い権限を得られる脆弱性の組み合わせを模索しており、一つでも未対策の弱点があれば連鎖的に侵入を許す恐れがあります。

影響とリスクの評価

攻撃者は完全なシステム制御が可能な脆弱性（＝「Total」）を好んで悪用します。CVSSスコアが「High」や「Critical」の深刻度であればなおさらですが、たとえ中程度でも「KEVカタログに掲載＝実害発生済み」である以上、油断は禁物です。特にランサムウェア攻撃では、初期侵入に使った脆弱性自体はさほど目立たない中～高程度の欠陥であっても、内側で別のCritical脆弱性と組み合わせて横展開・権限昇格することが知られています。部分的な影響の脆弱性であっても他の欠陥と組み合わされば致命傷となり得るため、既知の悪用脆弱性は大小問わず優先的に潰す姿勢が重要です。経営層にとっても、これらの統計が示すリスクの高さを踏まえれば、脆弱性対応に十分なリソース投資と適切な意思決定を行う必要性が理解できるでしょう。

組織が取るべき対策

4Qの分析レポートの結果を受け、組織として優先的に講じるべき脆弱性管理策を整理します。経営層は戦略的視点から、現場のセキュリティ担当者は実践的観点から、以下のセキュリティ対策の実施をおすすめします。

KEV掲載脆弱性の最優先パッチ適用

CISAは継続的にKEVカタログ掲載項目を優先的に修正するよう勧告しています。自社で利用する製品・システムに該当する脆弱性が公開された場合、定例パッチを待たず緊急で対応する体制を整えましょう。自動アラートによる通知や情報資産との照合などによって見落としを防ぐ運用が有効です。特に公表から日が浅い脆弱性は攻撃者も素早く狙ってくるため、初動対応のスピードが重要になります。

主要ベンダー製品の迅速なアップデート

MicrosoftやOracle、Cisco、Googleなど主要ベンダーのソフトウェアや機器は引き続き攻撃者の主要標的です。毎月発表されるセキュリティ更新プログラム（例: Microsoftの月例パッチ）や緊急アップデート情報を速やかに収集し、適用テストを経て迅速に全社展開する習慣をつけましょう。4QではMicrosoft製品の脆弱性が突出しましたが、他ベンダーでもゼロデイが報告されればすぐ悪用される可能性があります。例えば「重要なアップデートは可能な限り2週間以内に適用」などといった内部目標を設定し、経営陣もその重要性を認識すべきでしょう。

ネットワーク機器・IoT/産業機器の点検

企業ネットワークや工場内に設置されたルーター、NAS、監視カメラ、制御システム等も忘れてはいけません。4QにもD-LinkルーターやOpenPLCなどIoT/OT機器の脆弱性が含まれており、これらは往々にしてファームウェア更新が滞留しがちです。サポート切れやアップデート未適用の機器がないか棚卸しし、可能な限り最新ファームウェアへの更新や機器リプレースを実施しましょう。どうしても更新できない場合は、ネットワーク分離やアクセス制限など緩和策を講じ、インターネットから直接アクセスできる状態を放置しないことが重要です。

脅威検知とインシデント対応の強化

脆弱性への対策だけでなく、悪用された際に速やかに検知・対応する能力も不可欠です。IPS/IDSやエンドポイント検知（EDR）のシグネチャを最新化し、KEVに掲載された脆弱性の既知の攻撃パターンやIoC（Indicators of Compromise）を監視します。CISAやセキュリティベンダーから提供される検知ルールやYARAルールを活用し、ログ分析やトラフィック監視に組み込みましょう。また万一侵入を許した場合でも、早期にそれを発見し被害を最小化できるようインシデント対応訓練を積んでおくことも有効です。

資産管理と内部教育の徹底

攻撃者に狙われる脆弱性は多岐にわたるため、まずは自社システムの全容を把握することが出発点です。ハードウェア・ソフトウェア資産の最新インベントリを整備し、使用中の全ての製品についてサポート状況や最新パッチ適用状況をチェックします。使われていないシステムや旧式OSは計画的に撤去し、やむを得ず残す場合もネットワークを分離するなどリスク低減策を講じます。またIT部門や開発部門に対し、「古い脆弱性を放置しない」「定期的なアップデート適用は必須」といった意識付けを行います。定期的なセキュリティ研修や訓練で、脆弱性管理の重要性を全社員と共有することも大切です。

脆弱性管理プロセスの強化と自動化

増加する脆弱性に対処するには、属人的な対応から脱却しプロセスとツールの整備を進める必要があります。脆弱性情報収集から評価、パッチ適用状況のトラッキングまで一元管理できる仕組みを整えましょう。例えばKEVカタログのデータを自社資産データベースと照合する自動ツールを導入すれば、新たな緊急欠陥の検知と対応指示を迅速化できます。また定期的に脆弱性対応状況をレビューし、未対応件数や所要日数といったKPIを計測・改善することも効果的です。経営層は必要な人員・予算を投じ、継続的に脆弱性管理体制を進化させることが求められます。

脆弱性管理プロセスの概要とポイントについては以下の記事でも解説しています。あわせてぜひご覧ください。
「脆弱性管理とIT資産管理-サイバー攻撃から組織を守る取り組み-」

まとめ

2025年4QKEVカタログ分析レポートからは、攻撃者の手口がより広範かつ巧妙になっている実態が浮き彫りになりました。特に今年はKEVカタログへのCVE追加件数が前年より増加し記録更新となったことから、従来以上のハイペースで緊急脆弱性が発生・悪用される可能性が高まっています。侵入前提での備えを強化すべきでしょう。

2025年を通じて言えることは、脆弱性対応のスピードと徹底度を組織文化として根付かせることです。経営層はリスクと投資対効果を理解し、現場は技術的施策を愚直に実行する。そして最新の脅威情報をキャッチアップし続けることで、組織全体のサイバー耐性を高められるでしょう。来たる2026年も同様のレポートを継続し、変化する攻撃者の戦術に対抗すべく知見をアップデートしていきます。

BBSecでは

脆弱性の悪用リスクに迅速に対応するには、専門家の支援を仰ぐことも有効です。ブロードバンドセキュリティ（BBSec）では、発覚した脆弱性への対応支援や緊急インシデント対応サービスをご提供しています。自社だけでは対応が難しいゼロデイ攻撃の発生や、大規模サイバー攻撃の兆候を検知した際はぜひご相談ください。経験豊富なセキュリティ専門チームが、お客様のシステム状況の迅速な把握、攻撃の封じ込め、再発防止策の導入まで包括的にサポートいたします。また、平時からの脆弱性診断サービスやセキュリティ研修なども取り揃えており、脆弱性管理体制の構築から有事の対応までワンストップで支援可能です。BBSecのサービスを活用し、貴社のセキュリティレベル向上にぜひお役立てください。

サイバーインシデント緊急対応

セキュリティインシデントの再発防止や体制強化を確実に行うには、専門家の支援を受けることも有効です。BBSecでは緊急対応支援サービスをご提供しています。突然の大規模攻撃や情報漏洩の懸念等、緊急事態もしくはその可能性が発生した場合は、BBSecにご相談ください。セキュリティのスペシャリストが、御社システムの状況把握、防御、そして事後対策をトータルにサポートさせていただきます。

ウェビナー開催のお知らせ

2026年2月4日（水）13:00～14:00
【好評アンコール配信】「フィッシング攻撃の最新脅威と被害事例〜企業を守る多層防御策〜」

2026年2月10日（火）14:00～15:00
「Web攻撃の“今”がわかる OWASP Top 10 2025で読み解く脆弱性の狙われ方と対策の考え方」

2026年2月18日（水）14:00～15:00
「急増する「LINE誘導型」ビジネスメール詐欺の実態 ―社長になりすます最新BEC手口と組織で取るべき対策―」

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

2024年10月15日2025年8月12日

APIとは何か（2）～APIの脅威とリスク～

Security NEWS TOPに戻る
バックナンバー TOPに戻る

APIセキュリティは、現代のビジネスにおいて不可欠な課題です。シリーズ第2回の今回は、APIを悪用した攻撃手法や、OWASP（Open Web Application Security Project）よりリリースされている「OWASP API Security Top 10」で取り上げられるリスクの詳細を解説します。インジェクション攻撃やDDoS攻撃、APIキーの悪用、アクセス制御に関する脆弱性など、主要な脅威を紹介しながら、APIが悪用された場合の影響について解説します。

前回記事（シリーズ第1回）「APIとは何か～基本概念とセキュリティの重要性～」はこちら。

APIとは～前回からの振り返り

日頃からインターネットなどのネットワークを使用することが多い今日、現代における多くの企業はAPIに大きく依存しており、今やAPIは不可欠なものとなっています。Akamai社のレポート「The API Security Disconnect」によると、調査対象となった企業の約8割以上が2023年に行った調査において、「過去12か月以内にAPIセキュリティをより重視した」と回答しています。しかし、2022年～2024年で調査した回答者のうち、半数以上が、APIのセキュリティインシデントの影響により顧客の信頼を失い、さらにそこからほぼ半数は生産性の低下や従業員の信頼の低下にもつながったといいます。

また、SNS事業者が提供するAndroid版アプリに存在した脆弱性が悪用された結果、膨大な量のアカウント情報が漏洩した事例*5も報告されています。これは攻撃者が大量の偽アカウントを使用し、様々な場所から大量のリクエストを送信し、個人情報（ユーザ名・電話番号）を照合するというものでした。

APIが悪用されるとどうなるか

APIが悪用された場合、多岐にわたる深刻な影響が生じます。特に、認証や認可の不備は深刻なセキュリティホールとなり得ます。攻撃者はこれらの脆弱性を悪用して不正アクセスを行い、機密データや個人情報を盗み出す恐れがあります。また、認可が適切に設定されていないと、本来は外部からアクセスできないはずのデータにまで侵入され、第三者からデータの改ざんや不正操作が可能となってしまいます。さらに、APIを標的にしたDDoS攻撃によりサービスがダウンし、正規ユーザが利用できなくなることで、企業の信用失墜や業務の中断といったダメージを引き起こします。これらの影響は、経済的損失だけでなく、法的問題やブランドイメージの毀損など、長期的な悪影響をもたらすため、APIのセキュリティ強化が不可欠です。

APIを悪用した攻撃の事例はいくつか報告されていますが、いずれの攻撃も、「OWASP API Security Top 10」で挙げられている問題と関連性があります。

OWASP API Security Top 10

APIセキュリティについて、Webアプリケーションセキュリティに関する国際的コミュニティであるOWASPが、2023年6月に「OWASP API Security Top 10 2023」をリリースしています。APIセキュリティにおける10大リスクをピックアップして解説したものです。

https://owasp.org/API-Security/editions/2023/en/0x11-t10/ より当社作成

「OWASP API Security Top 10」上位のリスク

特に上位5つの項目については、以下のような重大なリスクにつながるため、リリース前に十分な対策が施されていることを確認すべきです。

不正アクセス
なりすまし
情報漏洩
サービス運用妨害（DoS）

主なセキュリティ脅威

インジェクション攻撃

インジェクション攻撃は、悪意のあるコードをAPIに挿入し、不正な操作を行う攻撃です。APIの入力データを検証せずに処理している場合、攻撃者にデータベースへのアクセスを許すリスクが生じます。特にSQLインジェクションやコマンドインジェクション攻撃が多く、攻撃を受けてしまった場合、データベースの情報漏洩やシステムの制御不備などの被害があります。

認証およびセッション管理の不備の脆弱性を悪用

APIの認証とセッション管理の不備を悪用することで、攻撃者は不正アクセスやなりすましを行います。パスワード強度が不十分な場合やトークンの管理が適切に行われていない場合、セッションハイジャックや不正に重要な情報を閲覧されることによってデータの漏洩が発生するリスクがあります。適切な認証管理およびセッション管理を行うことが重要です。

DDoS攻撃

DDoS攻撃は、複数のPCからアクセスされることによる膨大な量のリクエストをAPIに一斉に送り込むことで、システムのリソースを枯渇させ、サービスの提供を妨害する攻撃です。APIの特性上、処理を高速に行うために外部からのリクエストを許容する必要がありますが、その柔軟性が悪用されます。攻撃者はボットネットを利用し、大量のトラフィックを発生させてサーバのリソースを消費させます。これにより、顧客はサービスが利用できず、自組織においても業務に多大な影響を及ぼします。APIを保護するためには、トラフィックの監視やレート制限、WAF（Webアプリケーションファイアウォール）などのセキュリティ対策が重要です。

APIキーの悪用

APIキーは、APIへのアクセスを制御するために利用されますが、攻撃者に奪われると不正利用のリスクが生じます。盗まれたAPIキーは無制限のアクセスやサービスの悪用に使われる恐れがあります。安全な管理や無制限にアクセスができないように適切なアクセス制御を実施すること等が重要です。

アクセス制御の不備による影響

APIのアクセス制御の不備の脆弱性を悪用することで、攻撃者は許可されていないデータや機能にアクセスできます。適切な権限設定がされていない場合、データの漏洩や不正な操作の実行のリスクがあります。権限の設定など適切なアクセス制御が求められます。

思わぬデータの公開や改ざん

APIの設計や実装の不備により、データが意図せず公開・改ざんされるリスクがあります。適切な認証・認可がないと、攻撃者が内部の機密情報にアクセスすることが可能になります。例えば、本来ならシステム管理者のみがアクセスできる設定画面または顧客情報やシステムに関する情報などの重要情報が格納されている場所に攻撃者がアクセスできてしまった場合、システムの設定を変更されたり重要情報が奪取されたりする恐れがあります。また、過剰に情報を提供するAPIレスポンスや暗号化されていないデータ転送も、情報漏洩や改ざんの危険性を高めます。データ保護には、適切なアクセス制御と暗号化の実装が不可欠です。

アカウント乗っ取り

不正アクセスによってユーザアカウントが乗っ取られ、APIを悪用される可能性があります。一度アカウントが乗っ取られると、攻撃者は個人情報の閲覧や不正操作、さらには他のシステムへの攻撃拡大を図る可能性があります。多要素認証（MFA）の導入やAPIキーの適切な管理、ログイン試行の監視など、セキュリティ対策の強化が必要です。

まとめ

現代の企業にとってAPIによるアプリケーション連携は不可欠ですが、その悪用によるセキュリティリスクも増加しています。APIを悪用した攻撃の事例は、「OWASP API Security Top 10」に関連しています。主なセキュリティ脅威には、インジェクション攻撃、認証やセッション管理の不備、DDoS攻撃、APIキーの悪用、アクセス制御の脆弱性、不適切なデータ公開や改ざん、アカウント乗っ取りなどがあります。これらは重大なリスクを孕んでいるため不正アクセス、なりすまし、機密データの盗難を含む情報漏洩、データ改ざん、サービスのダウンによるサービス低下や業務への影響、ひいては企業の信用失墜といった深刻な結果を招きます。こうした被害を防ぐため、APIの設計段階から適切なセキュリティ対策を行い、監視やアクセス制御の強化が不可欠です。

Security NEWS TOPに戻る
バックナンバー TOPに戻る