ニチレイへのサイバー攻撃で食品物流に影響―業務再開までの経緯と企業が見直すべきBCP

Share
ニチレイへのサイバー攻撃で食品物流に影響アイキャッチ画像

2026年7月、ニチレイがサイバー攻撃を受け、冷蔵倉庫の入出庫業務や冷凍食品の出荷業務に影響が生じました。同社は被害拡大を防ぐためグループのシステムを遮断し、一部制限のもとで業務を順次再開。7月24日には、影響を受けた業務が通常稼働へ移行しました。本事案は、サイバー攻撃が情報漏えいだけでなく、物流や取引先を含む事業継続にも影響を及ぼすことを示しています。本記事では、公式発表に基づいて対応の経緯を整理し、企業が見直すべきBCPについて解説します。

※本記事は2026年7月31日時点で確認できる公表資料に基づき作成しています。公表されていない製品名、CVE番号、攻撃者、侵入手法の詳細については推測を加えずに構成しています。

ニチレイへのサイバー攻撃とは

2026年7月13日、株式会社ニチレイは不正アクセスによるシステム障害が発生したと公表しました*1。影響が出たのは、ニチレイロジグループ各社の冷蔵倉庫における入出庫業務と、ニチレイフーズの冷凍食品出荷業務です。同社は発生当日に緊急対策本部を立ち上げるとともに、お客さまや取引先の個人情報・顧客データなどの保護を最優先し、グループで使用するシステムの遮断措置を講じたことを、2日後の第2報*2で明らかにしています。その後、7月17日から一部制限のもとで業務を順次再開し、7月24日には、影響を受けた入出庫業務と冷凍食品出荷業務の受発注制限を解除して、全拠点を平常時の通常稼働へ移行しています。

この事案が示したのは、サイバー攻撃の被害が情報漏えいだけにとどまらないことです。攻撃を受けた疑いが生じれば、被害拡大を防ぐためにシステムを止める判断が必要になる場合があります。受発注、在庫管理、倉庫の入出庫、出荷といった業務がITでつながる現在、封じ込め措置そのものが事業停止リスクを伴います。本件からは、侵入を防ぐ対策だけでなく、システムを遮断した後も業務を継続し、段階的に復旧する計画が欠かせないことが分かります。サイバーセキュリティ対策とBCPは、一体で検討すべき課題です。

7月13日から24日まで―公式発表で追う対応と復旧

7月13日:不正アクセスによるシステム障害を公表

ニチレイは7月13日、不正アクセスによるシステム障害が同日に発生したと発表しました。第1報の時点では、個人情報や顧客データが社外へ流出した事実は確認されていないとしていました。一方、冷蔵倉庫の入出庫業務と冷凍食品の出荷業務にはすでに影響が生じており、障害の範囲は公表時点で日本国内に限られると説明しています。

ここで注意したいのは、7月13日が「攻撃者の侵入日」と確認されたわけではない点です。公式発表から断定できるのは、不正アクセスによるシステム障害が7月13日に発生し、同日公表されたことまでです。攻撃者が最初に侵入した日時や、不正アクセスを検知した正確な時刻・契機は明らかにされていません。

7月15日:サイバー攻撃を確認、個人情報漏えいの可能性を報告

7月15日の第2報で、ニチレイは調査の結果、自社サーバがサイバー攻撃を受けたことを確認したと発表しました。さらなる被害拡大を防ぐため、攻撃の詳細は非開示としています。また、被害を受けたサーバの一部に個人情報が保管されていたため、個人情報保護委員会へ「漏えいの可能性がある事案」として第一報を行いました。

同社は発生当日の7月13日にグループで使用するシステムを遮断しており、この遮断措置に伴って冷蔵倉庫の入出庫と冷凍食品出荷に影響が生じたと説明しています。なお、7月16日付のIR情報では、連結業績への影響は精査中とされ、重要な影響が判明した場合は速やかに開示すると説明しています。

7月17日:受発注を制限しながら部分稼働

7月17日、ニチレイは外部のセキュリティ専門会社の支援のもと、影響を受けた業務を順次再開しました。ただし、直ちに平常運転へ戻ったわけではなく、顧客や取引先からの受発注を一部制限し、冷蔵倉庫と食品工場を部分稼働させる形での再開でした。この段階でも、原因と影響範囲は調査中とされていました。

7月22日から24日:対象者への通知と通常稼働への移行

7月22日の第4報*3では、外部のセキュリティ専門会社に加え、警察および関係機関と連携して対応していることが公表されました。被害サーバの一部に個人情報が保管されていたため、対象者へ別途通知を行っていることも明らかにされています。

7月24日、ニチレイは受発注制限を解除し、影響を受けていた入出庫業務と冷凍食品出荷業務について、全拠点が平常時の通常稼働へ移行したと発表しました。ただし、これは影響業務の通常稼働への移行を示すものであり、原因調査や影響範囲の特定まで完了したことを意味するものではありません。

なぜ食品サプライチェーンへの影響が注目されたのか

ニチレイが2026年5月12日に公開した「事業概要説明資料」によると、同社の低温物流事業は全国75カ所に冷蔵倉庫を保有し、冷蔵倉庫の保管能力で国内1位です。さらに、ニチレイグループ外の取扱比率が90%を超えるとされています。今回、75カ所すべてに同じ程度の支障が生じたと公表されているわけではありません。ただし、この事業構造から、低温物流業務の中断がニチレイグループ以外の荷主にも波及し得ることが分かります。

実際、ミールキット宅配サービスのヨシケイは7月27日、ニチレイグループのシステム障害により倉庫からの商品出庫に支障が生じ、一部エリアで代替品や代替食材を届ける場合があると公表しました*4。ニチレイは7月24日に影響業務の通常稼働への移行を発表していますが、自社の業務が再開しても、取引先側では在庫調整や代替品の手配などが続く場合があります。ヨシケイの発表は、障害の影響が取引先の商品供給にまで波及したことを示す事例といえます。

なお、サイバー攻撃の影響が取引先へ波及したことと、取引先などを侵入経路とする「サプライチェーン攻撃」は区別する必要があります。ニチレイは侵入経路を公表していないため、本件をサプライチェーン攻撃と分類することはできません。一方、業務停止の影響が取引関係を通じて広がるリスクは、物流や食品製造だけでなく、決済、医療、クラウドサービスなどにも共通します。

個人情報は漏えいしたのか

2026年7月31日時点で、ニチレイは個人情報の漏えいを確定したとは発表していません。公表されているのは、被害サーバの一部に個人情報が保管されていたこと、漏えいの可能性がある事案として個人情報保護委員会へ第一報を行ったこと、対象者へ別途通知したことです。

個人情報保護委員会は、不正の目的をもって行われたおそれがある個人データの漏えい等について、実際の漏えいが確定した場合だけでなく、それ」がある段階も報告対象になると示しています*5。このため、個人情報保護委員会への報告が行われたことだけをもって、外部流出が確定したとは判断できません。

対象人数、顧客・従業員などの属性、情報項目、持ち出しの有無、不正利用の有無も公表されていません。したがって、現段階で「顧客情報が流出した」「大規模な個人情報漏えいが起きた」と書くのは不正確です。新たな公式発表が出た場合は、漏えいの事実、対象範囲、二次被害の有無を分けて確認する必要があります。

ランサムウェア攻撃だったのか

ニチレイは、攻撃手法、侵入経路、悪用された脆弱性、マルウェアの種類、データ暗号化や身代金要求の有無、攻撃者について公表していません。このため、本件をランサムウェア攻撃、ゼロデイ攻撃、あるいは特定の攻撃グループによる犯行と断定できる公式情報はありません。

攻撃者を名乗る第三者の主張が報じられた場合でも、それだけで攻撃手法や犯行主体が確定するわけではありません。本記事では、ニチレイまたは捜査機関が確認した情報と、外部からの未検証の主張を区別して扱います。

ニチレイの事例から企業が見直すべきサイバー攻撃対策

重要業務とシステムの依存関係を可視化する

対策の出発点となるのは、止まると事業や顧客に大きな影響が出る業務を特定し、それを支えるシステム、データ、拠点、委託先を対応付けることです。受発注システムだけを復旧しても、在庫情報、倉庫作業、輸配送との連携が戻らなければ商品は届きません。業務影響分析(BIA)を用いて復旧の優先順位を整理し、目標復旧時間(RTO)や目標復旧時点(RPO)に加え、システム停止中も最低限維持すべき業務とその水準を、IT部門と現場部門で共有しておくことが有効です。

多層防御によって被害範囲を限定する

ニチレイは侵入経路や攻撃手法を公表していないため、本件の原因に特定の対策不足を結び付けることはできません。以下は、同種の業務停止に備えるための一般的な対策です。

サイバー攻撃への備えでは、侵入を防ぐだけでなく、侵入された場合にも被害を広げない対策が必要です。重要システムやネットワークの分離、特権アカウントの適切な管理、多要素認証、ログの保全・監視などを組み合わせ、攻撃者による内部での移動や権限拡大を抑制します。

経済産業省・独立行政法人情報処理推進機構(IPA)の「サイバーセキュリティ経営ガイドライン Ver3.0 実践のためのプラクティス集 第4版」も、侵入を防ぐ入口対策に加え、内部での活動拡大を防ぐネットワーク対策、外部への不正通信を防ぐ出口対策、重要データを守る対策を組み合わせる多層防御を示しています。

「システムを止めた状態」で続ける手順を用意する

不正アクセスの疑いがある状況では、ネットワークの遮断や機器の隔離、サービス停止が必要になることがあります。IPAの「中小企業のためのセキュリティインシデント対応の手引き」でも、被害拡大の可能性がある場合の初動対応として、ネットワーク遮断や対象機器の隔離、システム・サービスの停止を挙げています。

だからこそ、BCPはバックアップからシステムを戻す手順だけでは不十分です。システムを遮断した際に利用する代替手順を、業務内容に応じて事前に設計しておく必要があります。例えば、受発注や入出庫を電話、メール、紙の帳票などへ一時的に切り替える場合も、処理可能な件数、誤処理を防ぐ照合方法、記録の保全、平常系へ戻す際のデータ反映まで検証しなければなりません。机上演習に加え、主要システムを利用できない状況を想定し、代替手順が実際に機能するか確認することが重要です。

復旧可能なバックアップと復旧手順を検証する

バックアップは、データを保存しているだけでは事業復旧を保証できません。本番環境と同時に暗号化・削除されないよう、ネットワークから分離した媒体や異なる環境にも保管し、バックアップデータの完全性を定期的に確認する必要があります。

さらに、復元テストを実施し、重要なシステムやデータを想定した時間内に復旧できるかを検証します。復旧の順序、必要な担当者、利用する機器や認証情報、システム間の依存関係も事前に整理しておくことが重要です。

サイバー攻撃を受けた環境を安全確認なしに復元すると、侵害された設定やマルウェアまで戻してしまうおそれがあります。原因調査や安全性の確認と並行して、どの時点のデータを、どの環境へ、どの順番で戻すかを判断できる復旧手順を整備しておく必要があります。

初動対応をIT部門だけに背負わせない

インシデント発生時には、封じ込め、証拠保全、原因調査、復旧に加え、顧客や取引先への連絡、個人情報保護委員会などへの報告、警察との連携、経営判断が並行して進みます。ニチレイも緊急対策本部を設置し、外部のセキュリティ専門会社、警察、関係機関と連携しました。

平時から、経営、情報システム、事業部門、法務、広報、個人情報保護担当の役割と連絡順序を決め、フォレンジック調査や復旧を依頼する外部専門家の連絡先を整えておくべきです。対応手順は、社内システムが利用できない状況でも参照できる場所に保管します。また、調査に必要なログやデータを不用意に消去しないよう、対象機器の隔離方法や外部専門家へ連絡する判断基準を訓練しておくことが重要です。

取引先を含めて復旧情報を共有する

自社が通常稼働へ戻っても、取引先側では在庫不足、納品遅延、代替商品の手配、顧客への案内が続く可能性があります。サプライチェーン全体の復旧を早めるには、「何が止まっているか」「どの業務をいつ再開するか」「制限が残るか」を、攻撃者に利する情報を避けながら継続的に共有することが重要です。

公表文のひな型だけでなく、重要取引先への連絡経路、問い合わせ窓口、更新頻度、技術情報と事業影響を分けて説明するルールまで準備しておくと、混乱を抑えやすくなります。セキュリティ部門が把握する復旧状況を、物流、営業、調達、顧客対応の言葉へ変換する役割も必要です。

よくある質問

▼ ニチレイのシステム障害はいつ発生しましたか
▼ どの業務に影響が出ましたか
▼ 個人情報は漏えいしましたか
▼ ランサムウェア攻撃だったのでしょうか

まとめ―サイバー攻撃対策は業務復旧まで設計する

ニチレイへのサイバー攻撃では、冷蔵倉庫の入出庫と冷凍食品出荷に支障が生じ、制限付きの再開を経て通常運用へ戻りました。一方、2026年7月31日時点では、攻撃手法や侵入経路、個人情報の外部流出の有無、最終的な影響範囲は公表されていません。

今回の事例から企業が学ぶべきなのは、侵入防止策だけではありません。被害拡大を防ぐためにシステムを遮断しても重要業務を続けられるか、安全性を確認しながらどの順番で復旧するか、取引先へ何を伝えるかまで含めて設計する必要があります。サイバー攻撃をIT障害として閉じず、経営と現場を巻き込んだサイバーBCPとして準備することが、事業とサプライチェーンの強靱性を左右します。

【参考情報】

編集責任:木下


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

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


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

  • 2026年8月19日(水)14:00~15:00「セキュリティ対策の有効性を検証する ―ペネトレーションテストの実施ポイントと脆弱性診断との違い―
  • 2026年8月26日(水)「AI時代に見直すセキュリティ対策 ~ASMの考え方で始める攻撃対象領域の可視化とリスク対策~
  • 最新情報はこちら


    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

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

    【続報】KDDIメールシステムへの不正アクセス、約1,223万人のメールアドレス漏えい―未知の脆弱性が原因

    Share
    KDDIメールシステムへの不正アクセス、約1,223万人のメールアドレス漏えいアイキャッチ画像

    2026年6月17日、KDDI株式会社は、ISP事業者向けに提供するメールシステムが不正アクセスを受けていたことを確認しました。この不正アクセスにより、約1,223万人分のメールアドレスと、そのうち約762万人分のパスワードが漏えいしました。原因は、ソフトウェアベンダーも把握していなかった第三者製ソフトウェアの脆弱性です。本記事では、確定した被害範囲とゼロデイ攻撃との関係、認証情報漏えいのリスク、企業が見直すべき対策を解説します。

    ※本記事は2026年7月31日時点で確認できる公表資料に基づき作成しています。公表されていない製品名、CVE番号、攻撃者、侵入手法の詳細については推測を加えずに構成しています。

    KDDIのISP向けメールシステムへの不正アクセスとは

    KDDIは2026年6月23日、同社がISP事業者向けに提供するメールシステムで不正アクセスが発生し、メール関連情報が外部に漏えいした可能性があると公表しました*6。初報で示されたのは、メールボックスにひもづくメールアドレスとパスワードの最大1,422万件です。この時点では調査中の最大値で、解約済みの利用者や一定期間利用されていない休眠アカウントも含まれていました。

    その後、KDDIは7月6日に調査結果を公表*2し、7月21日に対象人数を訂正しました。更新後の確定値は、メールアドレスが12,231,954人分、パスワードが7,616,173人分です。

    影響したISP事業者とメールサービス

    対象として公表されたのは6社です。STNetの「ピカラ光サービス」「ピカラモバイルサービス」「お仕事ピカラサービス」に係るメール、KDDIウェブコミュニケーションズのレンタルサーバー「CPI」のメール、JCOMの「J:COM NET」とケーブルテレビ事業者向けメール、中部テレコミュニケーションの「コミュファ光」「ビジネスコミュファ」のメール、ニフティの「@niftyメール」、ビッグローブの「BIGLOBEメール」です。

    一方、KDDIは、auメール、UQ mobileメール、au one netメールについて、今回のシステムとは異なる設備で構築されており、本件による影響や情報漏えいはないと説明しています。「KDDIのメールが一律に被害を受けた」と広げて表現するのは適切ではありません。

    また、KDDIが示した全体人数は、6社すべてで同じ種類の情報が漏えいしたことを意味しません。事業者別の調査結果には差があり、たとえばJ:COM NET利用者についてJCOMが確認した漏えい情報はメールアドレスのみです。CPIについても、KDDIはパスワードそのものの漏えいはないと公表しています。一方、JCOMがケーブルテレビ事業者向けに提供するメールサービスでは、一部の利用者についてパスワード漏えいが確認されています。対象者は契約先の公式案内で、自分に該当する情報と必要な対応を確認することが重要です。

    2026年5月16日の発生から2026年7月の確定公表まで

    KDDIの調査では、不正アクセスは一部のISP事業者において2026年5月16日から発生していました。KDDIが不正アクセスを確認したのは6月17日で、同日に被疑箇所を特定し、システム改修と脆弱性への対処を実施しています。発生開始から確認までには約1か月の隔たりがあり、未知の脆弱性を突いた攻撃を早期に検知する難しさが表れています。

    確認後の対応として、KDDIは6月21日に、外部通信を制御する全サーバーへのEDR導入を完了しました。さらに6月23日、第三者機関によるフォレンジック調査を通じ、本件で悪用された脆弱性以外に不審な痕跡が存在しないことを確認したとしています。6月24日には総務省から電気通信事業法に基づく報告を求められ、7月6日に報告書を提出しました。

    利用者対応では、KDDIと各ISP事業者がメールアカウントのパスワード変更を進めました。7月6日の公表時点では、日常的に利用されているアカウントを中心に多数の変更が行われ、利用頻度の低いアカウントを含めてISP事業者による強制変更を進めていると説明されています。公表資料が示すのは当時の進捗であるため、その後の完了状況は各ISP事業者の最新案内で確認する必要があります。

    なぜ「ゼロデイ攻撃」と整理できるのか

    KDDIは公式資料で「ゼロデイ」という言葉を用いていません。ただし、悪用された脆弱性は、KDDIが不正アクセスを確認した2026年6月17日時点で、当該ソフトウェアのベンダーも認識していなかったと説明されています。

    米国国立標準技術研究所(NIST)は、「従来知られていなかったハードウェア、ファームウェア、ソフトウェアの脆弱性を悪用する攻撃」をゼロデイ攻撃と定義しています*3。この定義に照らせば、本件をゼロデイ脆弱性の悪用事例として整理することには根拠があります。

    ただし、KDDIの更新資料には、第三者製ソフトウェアの製品名、脆弱性の技術的詳細、CVE番号、攻撃者の属性は記載されていません。したがって、侵入手法や攻撃主体、脆弱性の深刻度を推測で補うべきではありません。現時点で確実に言えるのは、第三者製ソフトウェアの未知の脆弱性が悪用され、メールアドレスとパスワードの漏えいが確認されたことです。

    ゼロデイ攻撃では、公開済みの修正プログラムを適用するという通常の脆弱性管理だけでは初動時の防御が間に合いません。そのため、外部公開範囲の縮小、ネットワーク分離、権限の最小化、EDRやNDRによる挙動監視、外向き通信の監視、十分な期間のログ保全といった、脆弱性そのものに依存しない多層防御が重要になります。KDDIがシステム改修に加えてEDR導入とフォレンジック調査を実施した点も、検知と影響範囲確認の重要性を示しています。

    「サプライチェーン攻撃」ではなく、サプライチェーンリスクとして見る

    本件では第三者製ソフトウェアの脆弱性が悪用されましたが、これだけを根拠に、サプライチェーン攻撃と断定するのは慎重であるべきです。公表資料には、ソフトウェアベンダーの開発環境や更新配布経路が侵害され、悪意あるコードが供給されたという説明はありません。確認されているのは、KDDIのメール基盤に導入されていたソフトウェアの脆弱性が攻撃されたという事実です。

    一方で、サイバーセキュリティのサプライチェーンリスクという観点では重要な事例です。NIST SP 800-161 Rev.1は、組織が利用する製品やサービスを含むサプライチェーン全体について、リスクを特定、評価、低減することを求めています。自社システムであっても、その構成要素には商用ソフトウェア、OSS、クラウドサービス、保守事業者など多くの外部依存が含まれます。脆弱性が一つの共通基盤に存在すれば、直接の契約関係やサービス名称が異なる複数の利用者へ影響が広がり得ます。

    今回、6社のISP事業者が提供する複数ブランドのメールサービスに影響が及んだことは、共通基盤への集中が障害時や侵害時の影響範囲を大きくすることを示しました。各ISPが個別に侵入されたとする公表ではなく、共通して利用するメール基盤で発生した事案である点が重要です。サービス名や契約先だけを見てリスクを分けるのではなく、実際にどの基盤、製品、運用主体を共有しているかまで把握する必要があります。

    パスワード漏えいで警戒すべき二次被害

    確認された情報にはメールアドレスだけでなく、7,616,173人分のパスワードが含まれます。ただし、KDDIの初報は漏えいした可能性のあるパスワードについて、ハッシュ化または暗号化されたものも含むと説明しており、すべてが平文で保存されていた、あるいは直ちに不正ログインが成立したと読み替えることはできません。また、7月21日更新資料で「漏えいが確認された情報」として人数が示されたのはメールアドレスとパスワードで、メール本文や添付ファイルの漏えい確認について同資料に記載はありません。

    それでも、メールアドレスと認証情報の組み合わせは二次攻撃への備えが必要です。同じパスワードを他のサービスでも使い回していれば、漏えいした組み合わせを別サービスに試すパスワードリスト攻撃につながるおそれがあります。IPAは、パスワードを長く複雑にし、使い回さないことに加え、利用できるサービスでは多要素認証を設定するよう推奨しています。

    さらに、漏えいしたメールアドレスを宛先として、ISPやKDDIを装ったフィッシングメールが送られる可能性も考慮すべきです。ただし、これは将来のリスクに関する一般的な注意であり、本件を原因とするフィッシング被害や他サービスへの不正ログインが確認されたという意味ではありません。利用者への注意喚起では、確認済みの事実と想定されるリスクを混同しない表現が求められます。

    企業が見直すべき4つの実務ポイント

    外部依存と共通基盤の「影響半径」を把握する

    最初に必要なのは、導入している製品やサービスの一覧だけではなく、それぞれがどのデータにアクセスでき、どの顧客、事業、関連会社へ影響し得るかを結び付けて把握することです。SaaSやマネージドサービスの契約先が別々でも、背後で同じ認証基盤やメール基盤を共有している可能性があります。重要度、外部公開の有無、保存データ、依存先、代替手段、停止・侵害時の連絡先を整理し、共通基盤の事故が起きた場合の影響半径を平時から想定しておく必要があります。

    未知の脆弱性を前提に補完的統制を置く

    脆弱性管理は不可欠ですが、パッチが存在しない期間をゼロにはできません。インターネットから直接到達できる機能を最小限にし、管理系機能を分離し、サービスアカウントを含む権限を必要最小限に抑えることが基本です。加えて、EDRやNDR、WAFなどを環境に応じて組み合わせ、通常と異なるプロセス実行、大量のデータ参照、想定外の外向き通信を検知できる状態を整えます。未知の脆弱性を直接検知できなくても、悪用後の挙動を捉えられれば滞在時間と被害範囲を縮小できます。

    認証情報漏えい時の対応手順を事前に決める

    認証情報が漏えいした場合、対象者の特定、パスワードの強制変更、既存セッションやトークンの失効、不審なログインの調査、利用者への通知、問い合わせ対応を並行して進める必要があります。パスワード使い回しへの注意やフィッシング対策も同時に案内し、多要素認証を利用できる環境では導入を促すことが有効です。通知文面、意思決定者、関係部署、委託先との連絡経路をインシデント対応計画に組み込んでおけば、大規模なリセットが必要になったときの混乱を減らせます。

    休眠・解約済みアカウントをデータ管理の問題として扱う

    初報の最大件数には、解約済み利用者や一定期間使われていない休眠利用者も含まれていました。使われていないアカウントは、利用者が異常に気付きにくい一方、管理対象と漏えい時の対応負荷を増やします。法令、契約、事業上の必要性を踏まえて保存期間を定め、不要になったアカウントの無効化やデータ削除、匿名化を進めることが重要です。保持が必要な場合も、現役アカウントと同じ到達性や権限を残さず、用途に応じた分離と監視を行うべきです。

    対象サービスの利用者が確認すべきこと

    対象となるメールサービスの利用者は、まず契約中のISP事業者が公開する最新情報を確認してください。パスワード変更の案内がある場合は、メール本文のリンクからではなく、ブックマークや公式サイトから手続きページへアクセスする方が安全です。メールと同じパスワードを他のサービスで使っている場合は、そちらもサービスごとに異なるパスワードへ変更し、提供されていれば多要素認証を有効にします。不審なログイン履歴、転送設定、送信履歴がないかも確認し、身に覚えのない操作があればISPの公式窓口へ相談してください。

    よくある質問

    ▼ KDDIのauメールも今回の不正アクセスの対象ですか
    ▼ この事案はゼロデイ攻撃ですか
    ▼ サプライチェーン攻撃と呼んでよいですか

    まとめ:未知の脆弱性と共通基盤のリスクを分けて考える

    KDDIのISP事業者向けメールシステムへの不正アクセスは、12,231,954人分のメールアドレスと7,616,173人分のパスワードが漏えいした大規模インシデントです。しかし、注目すべきなのは件数だけではありません。ベンダーも把握していなかった脆弱性が悪用されたこと、一つの共通基盤を通じて複数のISPサービスへ影響が及んだこと、休眠・解約済み利用者を含む認証情報の対応が必要になったことが、企業の実務に直結する論点です。

    既知の脆弱性に迅速に対処する体制を整えたうえで、未知の脆弱性を前提とする監視と分離、外部依存関係と影響半径の把握、認証情報漏えい時の対応手順、不要データの削減を進める必要があります。サプライチェーン攻撃という言葉を安易に当てはめるのではなく、確認された事実と、そこから導ける共通基盤・外部依存のリスクを切り分けて検討することが、再発防止策を具体化する第一歩となるでしょう。

    【参考情報】

    編集責任:木下


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

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


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

  • 2026年8月19日(水)14:00~15:00「セキュリティ対策の有効性を検証する ―ペネトレーションテストの実施ポイントと脆弱性診断との違い―
  • 2026年8月26日(水)「AI時代に見直すセキュリティ対策 ~ASMの考え方で始める攻撃対象領域の可視化とリスク対策~
  • 最新情報はこちら


    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

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

    Foxconnへのサイバー攻撃とは?製造委託先が狙われる理由とサプライチェーン対策

    Share
    「Foxconnへのサイバー攻撃とは?製造委託先が狙われる理由とサプライチェーン対策」アイキャッチ画像

    2026年5月、電子機器の製造受託大手Foxconnの北米拠点がサイバー攻撃を受け、攻撃者は約8TBのデータを窃取したと主張しました。製造委託先には複数企業の設計・製造情報が集まるため、侵害の影響が取引先へ広がるおそれがあります。本記事では、製造委託先が狙われる理由と、企業が取るべきサプライチェーン対策を解説します。

    Foxconnへのサイバー攻撃で何が起きたのか

    2026年5月、電子機器の製造受託大手Foxconnは、北米の一部拠点がサイバー攻撃を受けたことを明らかにしました。Foxconnによると、影響を受けた工場では復旧対応が進められ、通常の生産体制へ段階的に戻っているとされています。

    この攻撃について、ランサムウェア攻撃グループ「Nitrogen」は、約8TB、1,100万件を超えるファイルを窃取したと主張しました。窃取した情報には、Apple、Intel、Google、Dell、Nvidia、AMDなどの顧客企業に関係する情報が含まれるとも主張しています。

    ただし、データ窃取の規模や内容、顧客企業に関する情報が実際に含まれていたかについて、Foxconnは詳細を公表していません。そのため、攻撃者側の主張とFoxconnが確認・公表している事実は分けて捉える必要があります。

    なぜ製造委託先はサイバー攻撃の標的になりやすいのか

    製造委託先が狙われやすい理由の一つは、発注元企業との間に多くの情報連携が発生するためです。製造委託企業には、設計図、部品表、製品仕様、検査手順、試作品情報、調達計画など、製品開発や量産に必要な情報が集約されることがあります。

    攻撃者から見ると、こうした企業を侵害することで、発注元企業へ直接侵入しなくても、重要情報に近づける可能性があります。特に大企業はセキュリティ対策が強化されている一方で、委託先や再委託先まで同じ水準で管理されているとは限りません。攻撃者はこの「守りの差」を狙い、比較的侵入しやすい取引先を足がかりにすることがあります。

    また、製造業では受発注システム、設計データ共有基盤、生産管理システム、保守対応の連絡経路など、複数企業をまたぐ業務連携が多く存在します。こうした接点が適切に管理されていない場合、侵害された委託先から関連企業へ芋づる式に影響が広がる可能性があります。

    つまり、製造委託先は単なる外部企業ではなく、発注元企業の事業継続や情報保護に直結するサプライチェーンの一部として考える必要があります。

    Foxconnでは過去にも被害が発生

    なお、Foxconnとその関連企業では今回が初めての被害ではなく、過去にもサイバー攻撃による被害が報じられています。

    2020年はDoppelPaymerによる攻撃、2022年には別のメキシコ拠点がLockBitの標的となりました。また2024年には子会社のFoxsemiconも攻撃を受けています。

    世界各地に拠点や子会社を持つ企業では、組織全体で統一した対策を進めていても、拠点や関連会社によってセキュリティ対策や運用の水準に差が生じることがあります。攻撃者は、こうしたサプライチェーンやグループ企業内の接点を狙う可能性があります。

    製造委託先の侵害がもたらす主なリスク

    製造委託先が侵害された場合、影響は委託先単独の問題に留まりません。まず懸念されるのは、顧客企業に関係する情報の漏洩です。実際にFoxconnの事例では、攻撃者側が顧客企業の機密情報の窃取を主張しており(Foxconn側は詳細未公表)、こうした主張の真偽が確認される前から報道が先行する点も、企業にとって風評面のリスクとなり得ます。

    設計情報や部品表、製造手順、製品仕様などが流出すれば、知的財産の漏洩、模倣品の製造、競争力の低下につながるおそれがあります。

    また、製品やシステムの構成情報が外部に出ることで、攻撃者が弱点を分析しやすくなる可能性もあります。たとえば、使用している部品、ソフトウェア、通信仕様、検査工程などの情報が悪用されれば、将来的な攻撃の足がかりになることも考えられます。

    さらに、ランサムウェア攻撃では、工場の操業停止や生産ラインの停止も大きなリスクです。製造委託先の業務が止まれば、発注元企業にとっても納期遅延、欠品、代替生産の調整、顧客説明などの対応が必要になります。

    近年のランサムウェア攻撃では、システムを暗号化するだけでなく、事前にデータを窃取したうえで公開をちらつかせる「二重恐喝」も多く確認されています。そのため、バックアップからシステムを復旧できたとしても、窃取された情報の公開リスクが残ります。

    製造委託先の侵害は、情報漏洩、知財リスク、操業停止、供給遅延、信用低下が同時に発生し得る、サプライチェーン全体のリスクとして捉えるべきです。

    企業が取るべき対策

    企業は、製造委託先を「外部の別会社」として扱うだけではなく、自社のサプライチェーンの一部として管理することが重要です。

    委託先と共有する情報を最小限にする

    まず実施すべきことは、委託先に渡す情報を必要最小限にすることです。設計データ、部品表、製造手順などの重要情報は、必要な範囲、期間、担当者に限定して共有する必要があります。

    アクセス権限を分離する

    次に、アクセス権限をプロジェクト単位で分離することが有効です。すべての担当者が広範な情報にアクセスできる状態では、侵害時の被害が拡大しやすくなります。プロジェクトごと、顧客ごと、工程ごとにアクセス範囲を分けることで、万一の侵害時にも影響範囲を抑えやすくなります。

    委託先の対策状況を定期的に確認する

    委託先のセキュリティ対策状況を定期的に確認することも重要です。ただし、すべての委託先に同じ水準の対策や監査を一律に求めるのではなく、委託する業務の重要度や、共有する情報の機密性に応じて確認内容を設定する必要があります。

    たとえば、設計情報や顧客情報を扱う委託先、業務停止時に自社の生産や供給へ大きな影響を及ぼす委託先については、ランサムウェア対策、EDRなどの端末監視、バックアップ、ログ管理、脆弱性管理、インシデント対応体制を重点的に確認します。一方で、扱う情報や事業への影響が限定的な委託先については、確認項目を絞るなど、リスクに応じた管理が現実的です。

    重要な委託先については、契約時の確認だけで終わらせず、取引期間中も定期的に対策状況を確認し、環境やリスクの変化に応じて見直すことが求められます。

    情報漏洩とランサムウェアへの技術的対策を講じる

    技術的な対策としては、DLPによるデータ持ち出し監視、アクセスログの分析、大量ダウンロードの検知、重要データの暗号化、バックアップの分離保管などが挙げられます。特にランサムウェア対策では、バックアップが攻撃者に同時に破壊・暗号化されないよう、オフライン保管や改ざん耐性のあるバックアップ設計を検討する必要があります。

    契約と事業継続計画を整備する

    契約面では、インシデント発生時の通知期限、調査協力、証拠保全、再委託先管理、損害範囲、データ削除義務を明確にしておくことが重要です。さらに、代替生産先、代替部品、重要データの社内保全を含め、サイバー攻撃を前提としたサプライチェーンBCPを整備する必要があります。

    まとめ

    製造委託先は、複数の顧客企業に関わる設計情報や製造情報を扱うため、攻撃者にとって高価値な標的になり得ます。発注元企業のセキュリティ対策が強固であっても、委託先や再委託先に弱点があれば、そこを入口として情報漏洩や業務停止が発生する可能性があります。

    製造業におけるサプライチェーンリスクは、自然災害や物流停止だけではありません。サイバー攻撃による情報漏洩、操業停止、供給遅延、二重恐喝も、事業継続に直結する重要なリスクです。 企業は、委託先への情報共有を最小限に抑え、アクセス権限を分離し、定期的なセキュリティ監査を行うことが求められます。加えて、契約面の見直しやサイバー攻撃を想定したBCPの整備を進めることで、サプライチェーン全体のレジリエンスを高めることが重要です。

    【参考情報】(2026年8月時点)

    編集責任:木下


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

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

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

    サイバーセキュリティ緊急対応電話受付ボタン
    SQAT緊急対応バナー

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

  • 2026年8月19日(水)14:00~15:00「セキュリティ対策の有効性を検証する ―ペネトレーションテストの実施ポイントと脆弱性診断との違い―
  • 2026年8月26日(水)「AI時代に見直すセキュリティ対策 ~ASMの考え方で始める攻撃対象領域の可視化とリスク対策~
  • 最新情報はこちら


    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

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

    WordPress脆弱性「wp2shell」とは?影響・対象バージョン・対策を解説

    Share
    wp2shellとは?WordPress脆弱性の対象バージョンと対策アイキャッチ画像

    2026年7月、WordPress Coreに存在する2件の脆弱性を悪用し、認証前から管理者権限の取得や任意コード実行(RCE)につながる攻撃チェーン「wp2shell」が公表されました。WordPress.orgは修正版を公開し、対象バージョンへの強制自動更新を有効化していますが、すでにPoCや実攻撃が確認され、米国サイバーセキュリティ・インフラストラクチャセキュリティ庁(CISA)も「Known Exploited Vulnerabilities(KEV)カタログ」へ登録しています。本記事では、wp2shellの対象バージョンや仕組み、確認されている攻撃、侵害確認のポイント、企業が取るべき対策を解説します。

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

    まず確認したいポイント

    • 影響を受けるバージョン:WordPress 6.9.0~6.9.4、7.0.0~7.0.1(6.8.0~6.8.5もSQLインジェクションの影響あり)
    • 対応方法:修正済バージョン(WordPress 6.9.5/7.0.2/6.8.6)へ更新
    • 更新後の確認:稼働バージョンと侵害の有無(管理者アカウント・プラグイン・PHPファイル・ログ)

    自動更新が有効でも、更新が正常に完了しているとは限りません。実際に稼働しているバージョンを確認し、修正前のバージョンを公開していた場合は、更新に加えて侵害の有無も確認する必要があります。

    wp2shellの対象バージョン

    wp2shellの影響範囲はWordPressのバージョンによって異なります。まずは利用中のバージョンが対象かどうかを確認してください。特にWordPress 6.8系について、「wp2shellのRCE対象外」と「今回の脆弱性の影響をまったく受けない」を混同しないことが大切です。

    WordPressバージョンCVE-2026-60137CVE-2026-63030wp2shellによる未認証RCE修正済バージョン
    6.8未満対象外対象外対象外今回の2件については対象外。ただし、サポート状況を踏まえ最新バージョンを推奨
    6.8.0~6.8.5影響あり対象外対象外6.8.6
    6.9.0~6.9.4影響あり影響あり影響あり6.9.5
    7.0.0~7.0.1影響あり影響あり影響あり7.0.2
    7.1 Beta 1影響あり影響あり影響あり7.1 Beta 2

    WordPress.orgは重大性を踏まえ、影響を受けるサイトへの強制自動更新を有効化しました。ただし、自動更新が無効な環境や、ファイル権限・通信の問題で更新に失敗した環境、運用上の理由でバージョンが固定されている環境も考えられます。自動更新の設定ではなく、現在稼働中のバージョンを基準に影響を判断してください。

    wp2shellとは

    wp2shellは単独の脆弱性名や3件目のCVEではありません。WordPress Coreに存在するCVE-2026-60137CVE-2026-63030を連鎖させ、認証前のSQLインジェクションから管理者権限の取得、さらに任意コード実行へつなげる攻撃チェーンの通称です。

    脆弱性概要wp2shellでの役割
    CVE-2026-60137WP_Queryのauthor__not_inパラメータに関するSQLインジェクション攻撃者がデータベース処理を不正に操作する足掛かりになる
    CVE-2026-63030WordPress REST APIのバッチ処理で発生するルート混同本来の検証と異なる処理経路を使わせ、SQLインジェクションを認証前から到達可能にする

    WordPressのREST APIには、複数のサブリクエストをまとめて処理するバッチ機能があります。脆弱なバージョンでは、サブリクエストの入力を検証したルートと、実際に処理するルートの対応関係がずれる場合があります。その結果、本来は型や値を検証されるはずの入力が、適切な検証を受けないままデータベース処理へ到達し、SQLインジェクションが成立します。

    発見者が示したフルチェーンでは、SQLインジェクションを起点に複数のWordPress内部処理を悪用し、一時的に管理者権限でREST APIを実行させて新しい管理者アカウントを作成します。その後、プラグインのアップロード機能を悪用して任意コード実行へ至ります。

    wp2shellは脆弱なプラグインやテーマを前提とせず、WordPress Coreの脆弱性を連鎖させる攻撃です。Searchlight Cyberは、「脆弱なプラグインを必要とせず、標準的なWordPress環境で成立し得る」と説明しています*4。一方、Cloudflareは、同社が確認したRCE経路について「永続オブジェクトキャッシュを使用していない場合」という条件を示しています*2。永続オブジェクトキャッシュを使用していても、SQLインジェクション自体の影響は残るため、構成にかかわらず、影響を受けるWordPress Coreは修正版へ更新することが重要です。

    wp2shellの影響

    GitHubで公開された「Icex0/wp2shell-poc」は、Searchlight Cyberの公式チェッカーではなく、第三者による独立したPoCです。公開されたPoCには、SQLインジェクションの確認から管理者アカウント作成、任意コード実行までを再現する機能が実装されています。

    公開されたPoCには、SQLインジェクションの確認から管理者アカウントの作成、任意コード実行までを再現する機能が実装されています。これにより、攻撃の検証や自動化が容易になりました。PoCの利用は、許可を得た環境での検証に限定すべきです。

    実攻撃とKEV登録状況

    修正版の公開後、複数のPoCが公開され、実環境では悪性プラグインやWebシェルを設置する攻撃も確認されました。

    Wizは7月20日、同社が可視化できるクラウド環境において、複数の攻撃者が脆弱なWordPressを悪用した事例を確認したと報告しました*3。観測された活動には、悪性WordPressプラグインのアップロード、PHP Webシェルの設置、管理画面へのアクセス、管理者名やメールアドレスの列挙、ローカルファイルインクルージョンの試行が含まれます。一方、同社は同日時点で、横展開やデータ流出は確認していないとも述べています。

    7月21日には、米国CISAがCVE-2026-60137とCVE-2026-63030をKEVカタログへ追加しました。KEVへの登録は、実際の悪用を裏付ける証拠があることを示します。ただし、攻撃件数や国内での被害規模まで示すものではありません。それでも、修正版公開後の短期間にPoCと実攻撃が確認されていることから、対象バージョンのWordPressをインターネットへ公開している場合は、対象環境では定期メンテナンスを待たず、緊急性の高いパッチとして扱う必要があります。

    国内では独立行政法人情報処理推進機構(IPA)が7月22日に注意喚起を公開*4しています。また、JPCERT/CCも7月23日に「複数のセキュリティ企業が悪用を確認している」として、修正版への更新を呼びかけています*5

    侵害確認のポイント

    ステップ1:稼働バージョンと公開期間を確認する

    • 現在のWordPress Coreのバージョンを確認する
    • 修正版へ更新済みの場合も、それ以前に脆弱な状態で公開していた期間がないか確認する(少なくとも2026年7月17日以降、可能であれば保存されている範囲全体のログを対象にする)
    • DNS、クラウド、レンタルサーバー、外部委託先を含め、管理対象外のWordPressや検証用サイトを含め、組織が現在公開されているWeb資産を棚卸しする

    ステップ2:REST APIのバッチエンドポイントへの通信を調べる

    • WebサーバーやWAFのログで /wp-json/batch/v1 および ?rest_route=/batch/v1 への不審なリクエストを確認する
    • HTTP 207の応答、wp2shell/rezwp2shell を含むUser-Agentを補助的な手掛かりとして確認する(※単独で攻撃成功を示すものではない)
    • 送信元、リクエスト内容、後続する管理画面へのアクセス、ファイル作成などを時系列で突き合わせる

    バッチAPIは正規の処理でも使われるため、HTTPステータスだけで侵害を断定することはできません。PoC固有のUser-Agentも容易に変更できる点に注意してください。

    ステップ3:管理者アカウント、プラグイン、PHPファイルを確認する

    • WordPressのユーザー一覧で、作成者や作成時刻に心当たりのない管理者アカウントがないか確認する
    • インストールした記録のないプラグインがないか確認する
    • wp-content/pluginsやキャッシュ領域に追加・変更されたPHPファイルがないか確認する
    • Webサーバープロセスからシェルや不審な子プロセスが起動された記録がないか確認する

    既知のファイル名やハッシュとの一致だけに頼るべきではありません。公開PoCは改変でき、攻撃者も名称や配置先を変えられます。通信、アカウント、ファイル、プロセスという複数の痕跡から判断してください。侵害の疑いがある場合は、証拠を保全したうえで対象を隔離し、組織のインシデント対応手順に従って調査を進めます。

    今すぐ行うべき対策

    WordPress Coreを修正版へ更新

    根本対策は、6.8系なら6.8.6、6.9系なら6.9.5、7.0系なら7.0.2への更新です。別のブランチへ移行する場合は、そのブランチで今回の脆弱性が修正済みのバージョンを選びます。WordPressの管理画面だけでなく、構成管理ツールやホスティング事業者の管理画面も確認し、更新後に実際のバージョンが切り替わったことを検証します。

    本番サイトの更新では、バックアップと復旧手順を確認し、プラグインやテーマとの互換性も検証します。ただし、今回のように実悪用が確認された脆弱性では、通常の更新サイクルをそのまま適用せず、リスクに応じて緊急変更として扱う判断が必要です。

    すぐに更新できない場合はWAFで一時的に遮断

    直ちにアップデートできない場合、Searchlight Cyberは暫定策として、未認証のバッチAPIへのアクセスを制限する方法を示しています。WAFやリバースプロキシで/wp-json/batch/v1rest_route=/batch/v1の両方を対象にし、外部からの未認証アクセスを遮断します。

    遮断条件は、URLをデコード・正規化した後の値で判定し、受信時のHTTPメソッドだけで絞り込まないようにします。サブディレクトリに設置したWordPressや、WAFを通らずオリジンサーバーへ直接接続できる経路も確認が必要です。

    この対策は、正規のREST API利用に影響する可能性があります。また、WAFは脆弱なコードを修正するものではなく、設定や通信経路によっては防御を迂回されるおそれもあります。あくまで更新までの一時的なリスク低減策と位置づけ、WordPress Coreのアップデートを先送りしないでください。

    更新後も侵害の有無を調査

    修正版への更新は、この2件の脆弱性を利用した新たな侵入を防ぐための根本対策です。ただし、更新前に作成された管理者アカウントやWebシェルは削除されません。脆弱な状態で公開していたサイトは、更新後もログ、アカウント、プラグイン、ファイル改変を確認します。

    侵害が確認された場合は、単に不審なファイルを削除して公開を再開するのではなく、影響範囲を特定し、信頼できるバックアップからの復旧、認証情報や秘密情報の変更、再侵入経路の遮断までを一連のインシデント対応として行う必要があります。

    よくある質問

    ▼ wp2shellはWordPressプラグインの脆弱性ですか?
    ▼ WordPress 6.8系はwp2shellの影響を受けますか?
    ▼ 自動更新を有効にしていれば対策済みですか?
    ▼ WAFだけでwp2shellを防げますか?
    ▼ wp2shellを利用した実攻撃は確認されていますか?
    ▼ 修正版へ更新すれば侵害調査は不要ですか?

    まとめ

    wp2shellは、WordPress Coreに存在する2件の脆弱性を組み合わせ、認証前から管理者権限の取得や任意コード実行(RCE)につながる攻撃チェーンです。対象となるWordPressバージョンでは、すでにPoCや実攻撃が確認され、CISAのKEVカタログにも登録されています。

    影響を受けるバージョンを利用している場合は、修正版への更新を速やかに実施してください。また、修正前のバージョンをインターネットに公開していた場合は、更新だけでなく、管理者アカウントやプラグイン、PHPファイル、アクセスログなどを確認し、侵害の有無も調査することが重要です。

    今回の事例は、脆弱性情報の公開後、短期間でPoCや実攻撃が確認された事例でもあります。今後の緊急対応を迅速化するため、平時から公開資産を継続的に把握できる運用体制を整えることが重要です。

    【関連記事】

    【参考情報】


    【コラム】AIを活用した脆弱性研究

    今回のwp2shellは、AIを活用した脆弱性研究の事例としても注目されました。Searchlight CyberのAdam Kues氏は、GPT-5.6 Sol Ultraをコード監査に活用し、約10時間で攻撃チェーンを構築できたと報告しています。一方で、調査対象の選定や検証、WordPressへの責任ある報告は研究者自身が行っており、「AIが単独で脆弱性を発見した」わけではありません。本件は、AIの活用によって脆弱性研究が効率化される一方、修正版公開後からPoCや実攻撃が出現するまでの期間が短くなる可能性を示した事例としても注目されています。

    参考:

    編集責任:木下


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


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

    最新情報はこちら


    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

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

    DDoS攻撃とは?仕組み・種類・被害・対策を企業向けに解説

    Share

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

    DDoS攻撃とは?仕組み・種類・被害・対策を企業向けに解説アイキャッチ画像

    DDoS攻撃は、大量の通信を送り付けて、Webサイトやサーバーを利用しにくくするサイバー攻撃です。サービス停止や業務の停滞を招くおそれがあるため、企業は仕組みと対策を理解しておく必要があります。本記事では、DDoS攻撃の種類や被害、基本的な対策を解説します。

    DoS攻撃との違いを詳しく知りたい方、実際にDDoS攻撃を受けた場合の初動対応や復旧の流れについて知りたい方は以下の記事もあわせてご覧ください。
    DoS攻撃とDDoS攻撃の違いとは
    DDoS攻撃を受けたらどうする?

    DDoS攻撃とは

    DDoS攻撃(Distributed Denial of Service attack)は、Webサイトやサーバー、ネットワーク機器などに大量の通信やリクエストを送り付け、正常なサービス提供を妨害するサイバー攻撃です。攻撃を受けると、Webサイトの表示遅延やサービス停止、ネットワークの応答遅延などが発生し、正規の利用者がサービスを利用できなくなることがあります。

    DDoS攻撃の特徴は、攻撃者が多数の端末やネットワークを利用する点にあります。攻撃者は、マルウェアなどに感染した機器で構成される「ボットネット」を悪用します。

    世界中の端末から一斉に通信を送るため、単一の送信元を遮断するだけでは防ぎにくい攻撃です。近年では、ECサイトや金融機関、自治体、医療機関など、幅広い組織が標的となっています。企業規模を問わず対策が求められています。

    また、DDoS攻撃は、サービス停止だけを目的とするものではありません。攻撃による混乱に乗じて、不正アクセスや情報窃取など、別の攻撃を試みる「陽動」として利用されるケースもあります。

    DDoS攻撃を理解するためには、まずDoS攻撃との違いや、どのような目的で実行されるのかを知ることが重要です。

    DoS攻撃との違い

    DoS攻撃は、単一または少数の端末からサービスを妨害する攻撃です。DDoS攻撃は、多数の端末から分散して通信を送るため、攻撃元の特定や遮断が難しくなります。

    DoS攻撃とDDoS攻撃の違いについては、以下の記事で詳しく解説しています。ぜひあわせてご覧ください。「DoS攻撃とDDoS攻撃の違いとは

    なぜDDoS攻撃が行われるのか

    DDoS攻撃の目的は、単にWebサイトやサービスを停止させることだけではありません。企業活動を妨害したり、金銭を要求したり、別のサイバー攻撃を成功させるための陽動として利用されたりするなど、さまざまな目的で実行されます。

    例えば、ECサイトや予約システムを停止させることで売上機会の損失を狙うケースや、競合他社への業務妨害を目的とした攻撃が報告されています。

    また、サービス停止による混乱の中で、不正アクセスや情報窃取を試みることもあります。このような「陽動攻撃」として、DDoS攻撃が利用されるケースもあります。

    近年では、IoT機器の普及やボットネットの大規模化が進んでいます。その結果、専門的な知識がなくても、攻撃サービスを利用して大規模なDDoS攻撃を実行できる環境が問題視されています。

    こうしたサービスは、DDoS-for-Hire、すなわちDDoS請負サービスなどと呼ばれます。そのため、企業規模を問わず、DDoS攻撃を想定した備えが重要になっています。

    DDoS攻撃の仕組み

    DDoS攻撃は、多数の端末やサーバから、標的へ一斉に大量の通信を送る攻撃です。サーバやネットワーク機器に過剰な負荷をかけ、正常なサービス提供を妨げます。

    攻撃対象は、Webサイトだけではありません。DNSサーバやVPN、API、クラウドサービスなど、多岐にわたります。

    攻撃者は、自ら大量の通信を送るのではありません。マルウェアに感染したIoT機器やパソコン、サーバーなどを遠隔操作します。そして、ボットネットを構築して攻撃を実行するのが一般的です。

    また、DDoS攻撃は、大量の通信によって回線帯域を圧迫するものだけではありません。ネットワーク機器に負荷をかける攻撃や、Webアプリケーションへ大量のリクエストを送る攻撃など、複数の手法があります。

    そのため、自社サービスを守るためには、攻撃の仕組みを理解し、それぞれの手法に応じた対策を講じることが重要です。

    ボットネットによる分散攻撃

    DDoS攻撃では、多くの場合「ボットネット(Botnet)」と呼ばれるネットワークが悪用されます。ボットネットとは、マルウェアに感染したパソコンやサーバ、IoT機器などが攻撃者の遠隔操作下に置かれた状態のネットワークです。攻撃者はこれらの端末へ一斉に指示を送り、標的に大量の通信を発生させます。

    近年では、監視カメラやルーター、ネットワーク機器など、十分なセキュリティ対策が施されていないIoT機器がボットネットに組み込まれる事例も確認されています。機器の所有者が気付かないまま攻撃に加担しているケースも少なくありません。

    ボットネットを利用したDDoS攻撃では、世界中に分散した多数の端末から同時に通信が送られるため、単一の送信元を遮断するだけでは十分な対策が難しくなります。

    攻撃の流れ

    DDoS攻撃は、一般的に次のような流れで実行されます。

    1. ボットネットの構築
      攻撃者は、マルウェアに感染したパソコンやサーバー、IoT機器などを遠隔操作できる状態にし、ボットネットを構築します。
    2. 攻撃対象の選定
      WebサイトやECサイト、VPN、DNSサーバー、APIなど、攻撃対象となるシステムを選定します。
    3. 攻撃命令の送信
      攻撃者がボットネットへ攻撃命令を送ると、多数の端末が一斉に標的へ通信やリクエストを送信します。
    4. サービスへの影響
      大量の通信によってネットワーク回線やサーバー、ネットワーク機器、Webアプリケーションに負荷がかかり、応答遅延やサービス停止などが発生します。

    攻撃の種類によっては、ネットワーク帯域を圧迫するだけでなく、ファイアウォールやロードバランサーなどのネットワーク機器に負荷をかけるものや、Webアプリケーションへ大量のリクエストを送るものもあります。そのため、攻撃の種類に応じた対策を講じることが重要です。

    DDoS攻撃の主な種類

    DDoS攻撃にはさまざまな手法がありますが、大きく分けると「ボリューム攻撃」「プロトコル攻撃」「アプリケーション層攻撃」の3種類に分類できます。

    攻撃対象や攻撃方法が異なるため、サービスへの影響や有効な対策もそれぞれ異なります。攻撃の種類を理解することは、自社サービスがどのようなリスクにさらされているのかを把握し、適切な対策を講じるための第一歩です。

    ここでは、代表的な3つの攻撃手法について解説します。

    ボリューム攻撃

    ボリューム攻撃は、大量の通信を送り付けてネットワーク回線の帯域を圧迫し、正規の利用者がサービスへアクセスできない状態にする攻撃です。DDoS攻撃の中でも代表的な手法であり、回線容量を超える通信が発生すると、サーバーが正常に稼働していてもサービスを利用できなくなることがあります。

    代表的な手法として、UDP FloodDNS Amplification(DNSリフレクション攻撃)NTP Amplificationなどがあります。特にDNSやNTPなどの公開サーバーを悪用する反射・増幅型攻撃では、小さなリクエストを利用して何倍もの通信量を発生させるため、攻撃者は比較的少ない通信量でも大きな負荷を与えることができます。

    プロトコル攻撃

    プロトコル攻撃は、TCP/IPなどの通信プロトコルの仕組みを悪用し、サーバーやファイアウォール、ロードバランサーなどのネットワーク機器に負荷をかける攻撃です。通信回線そのものを埋め尽くすボリューム攻撃とは異なり、ネットワーク機器やサーバーの処理能力を消費させることで、正常な通信を妨害します。

    代表的な手法としては、SYN Floodがあります。TCP通信の接続要求(SYNパケット)を大量に送り付けることで、サーバは接続待ちの状態を維持し続けることになり、新たな正規ユーザからの接続を受け付けられなくなる場合があります。このほか、Ping FloodSmurf攻撃などもプロトコル攻撃の一種として知られています。

    アプリケーション層攻撃

    アプリケーション層攻撃は、WebサイトやWebアプリケーション、APIなどを標的とするDDoS攻撃です。利用者が直接アクセスするサービスが狙われます。

    通信量そのものはそれほど多くなくても、サーバーが処理に時間を要するリクエストを大量に送ることで、CPUやメモリなどのリソースを消費させ、サービスの応答遅延や停止を引き起こします。

    代表的な手法としてHTTP Floodがあります。通常のWeb閲覧と同じHTTPリクエストを大量に送信するため、正規のアクセスと見分けにくく、単純な通信量の監視だけでは検知が難しい場合があります。また、検索機能やログイン画面、APIなど、サーバー負荷の高い処理を集中的に狙う攻撃も確認されています。

    DDoS攻撃による被害

    DDoS攻撃による影響は、単にWebサイトが一時的に閲覧できなくなるだけではありません。サービス停止による売上機会の損失や業務の停滞、顧客対応の負荷増加など、企業活動全体へ影響が及ぶ可能性があります。

    また、長時間にわたってサービスが利用できない状態が続くと、企業の信頼低下やブランドイメージの毀損につながるおそれもあります。

    近年では、DDoS攻撃を単独で行うだけでなく、その混乱に乗じて不正アクセスや情報窃取など別の攻撃を試みるケースも報告されています。そのため、DDoS攻撃は単なる通信障害ではなく、企業の事業継続に関わるセキュリティリスクとして捉えることが重要です。

    ここでは、企業が受ける代表的な被害について解説します。

    サービス停止

    DDoS攻撃による代表的な被害は、Webサイトやオンラインサービスの停止です。

    大量の通信やリクエストが送られると、サーバーやネットワーク機器に過剰な負荷がかかります。その結果、Webページの表示遅延やタイムアウト、エラーが発生し、正規の利用者がサービスを利用できなくなることがあります。

    特に、ECサイトや予約システム、会員向けサービス、決済サービスなど、インターネットを通じて提供されるサービスでは、短時間の停止であっても売上機会の損失や顧客満足度の低下につながる可能性があります。

    さらに、DDoS攻撃ではサーバー自体に障害が発生していなくても、回線帯域の逼迫やネットワーク機器への負荷によってサービスが利用できなくなる場合があります。そのため、システムが正常に稼働しているように見えても、利用者からは「サービスが停止している」と認識されるケースも少なくありません。

    業務への影響

    DDoS攻撃の影響は、Webサイトの停止だけにとどまりません。公開サービスと社内システムが同じネットワークや認証基盤を利用している場合には、VPNや業務システム、クラウドサービスなどへ影響が及び、日常業務に支障をきたすことがあります。

    また、サービス停止に伴い、顧客や取引先からの問い合わせが急増し、カスタマーサポートや営業部門の対応負荷が高まることもあります。

    ECサイトでは注文処理や決済が滞り、BtoBサービスでは取引先の業務に影響を与えるなど、事業継続にも大きな影響を及ぼす可能性があります。さらに、障害対応のために情報システム部門やセキュリティ担当者が長時間の対応を余儀なくされ、本来予定していた業務が停滞するケースも少なくありません。

    企業の信頼低下

    DDoS攻撃によるサービス停止が長時間続いたり、繰り返し発生したりすると、企業に対する信頼の低下につながるおそれがあります。利用者は「サービスが安定して利用できない企業」という印象を持つ可能性があり、顧客離れや新規顧客の獲得機会の損失につながることもあります。

    さらに、DDoS攻撃をきっかけに、自社のセキュリティ対策やインシデント対応体制が十分であるかを取引先や顧客から問われることもあります。そのため、平時から適切な対策を講じるとともに、攻撃発生時には迅速かつ適切な対応を行うことが、企業の信頼維持につながります。

    企業が実施すべきDDoS攻撃対策

    DDoS攻撃は、完全に防ぐことが難しいサイバー攻撃の一つです。そのため、攻撃を受けることを前提に、被害を最小限に抑えるための対策を講じることが重要です。ここでは、企業が押さえておきたい代表的なDDoS攻撃対策を紹介します。

    通信の監視と異常検知

    DDoS攻撃による被害を最小限に抑えるためには、通信状況を継続的に監視し、通常とは異なるアクセスを早期に検知できる体制を整えることが重要です。

    アクセス数や通信量、リクエスト数などの推移を日頃から把握しておくことで、異常な増加が発生した際に迅速な対応につなげることができます。

    近年では、SIEM(Security Information and Event Management)やネットワーク監視ツールを活用し、異常な通信を自動で検知・通知する仕組みを導入する企業も増えています。

    DDoS攻撃は短時間で通信量が急増するケースが多いため、異常を検知してから対応を開始するまでの時間が重要です。

    CDN・WAF・DDoS対策サービスの活用

    DDoS攻撃は、攻撃元が世界中の多数の端末に分散しているため、自社設備だけで防ぎきることは難しく、外部サービスとの連携が対策の基本方針になります。特に、大量の通信が発生するボリューム攻撃では、自社ネットワークに到達する前に不要な通信を分散・遮断する仕組みが重要になります。

    • CDN(Content Delivery Network):コンテンツを複数のサーバーに分散して配信することで、通信負荷を分散し、サービスの継続性向上に役立ちます。
    • WAF(Web Application Firewall):Webアプリケーションへの不正なアクセスや不審なリクエストを検知・制御する機能を備えており、特にアプリケーション層を狙った攻撃への対策として有効です。
    • DDoS対策サービス:専用の設備で攻撃トラフィックを検知・吸収・フィルタリングし、正常な通信のみを自社環境へ転送する仕組みを提供しています。

    攻撃の規模やサービスの重要度に応じて、ISPやクラウド事業者が提供する対策サービスも含め、自社に適した構成を検討するとよいでしょう。

    自社の対策状況に不安がある場合

    「どのサービスを、どこまで導入すべきか」の判断が難しい場合は、専門会社によるDDoS耐性評価・セキュリティ診断を活用するのも一つの方法です。現状のリスクを可視化したうえで、優先度をつけて対策を進めることができます。

    インシデント対応体制の整備

    DDoS攻撃は、技術的な対策だけで完全に防ぐことは困難です。そのため、攻撃を受けた際に迅速かつ適切に対応できる体制をあらかじめ整備しておくことが重要です。

    具体的には、攻撃発生時の連絡体制や対応手順を文書化し、情報システム部門だけでなく、経営層や広報部門、カスタマーサポート部門など、関係者の役割を明確にしておくことが求められます。

    また、ISPやクラウド事業者、セキュリティベンダーなどの連絡先や支援体制を事前に確認しておくことで、緊急時の対応を円滑に進められます。

    まとめ

    DDoS攻撃は、大量の通信によってWebサイトやネットワークサービスを利用できない状態にするサイバー攻撃です。攻撃手法にはボリューム攻撃、プロトコル攻撃、アプリケーション層攻撃などがあり、それぞれ特徴や有効な対策が異なります。

    企業は、通信の監視や異常検知、CDN・WAF・DDoS対策サービスの活用に加え、インシデント対応体制の整備など、多層的な対策を講じることが重要です。また、攻撃を完全に防ぐことは難しいため、被害を最小限に抑えるための備えも欠かせません。

    攻撃発生時の具体的な対応手順や、復旧までの流れについては、以下の記事で詳しく解説しています。あわせてご覧ください。
    DDoS攻撃を受けたらどうする?初動対応から復旧までの流れを解説

    【関連記事】

    DDos攻撃について、SQAT.jpでは以下の記事でも解説しています。こちらもあわせてぜひご覧ください。

    【参考情報】


    DDoS対策や公開システムのセキュリティに不安はありませんか?

    DDoS攻撃への備えには、ネットワークやWebアプリケーションのリスクを把握することが重要です。BBSecでは、脆弱性診断をはじめ、お客様の環境に応じたセキュリティ評価をご提供しています。

    Webアプリケーション脆弱性診断バナー

    アクセス急増の原因が複雑で判断が難しい場合や、継続的な運用に不安がある場合は、第三者の視点を取り入れることも有効です。定期的なセキュリティ診断や評価を通じて、自社では気づきにくいリスクを把握することができます。


    公開日:2021年6月23日
    更新日:2026年7月29日

    編集責任:木下


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

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

    APT攻撃事例から学ぶ ―国内外の被害事例と企業が取るべき対策―

    Share
    APT攻撃事例から学ぶ ―国内外の被害事例と企業が取るべき対策―アイキャッチ画像

    APT攻撃は、企業や政府機関、研究機関などを標的に、長期間にわたって情報窃取や諜報活動を行う高度なサイバー攻撃です。侵入経路は標的型メールや脆弱性の悪用、サプライチェーン攻撃などさまざまで、被害は組織内にとどまらないこともあります。本記事では、国内外の代表的なAPT攻撃事例を紹介し、企業が学ぶべき教訓と対策のポイントを解説します。

    APT攻撃の定義や特徴について詳しく知りたい方は、まずこちらの記事をご覧ください。APT攻撃とは?標的型攻撃との違いと企業リスクを解説【2026年版】

    APT攻撃事例が注目される理由

    APT攻撃事例が注目されるのは、被害が一企業にとどまらず、取引先や顧客、社会インフラへ広がる可能性があるためです。APT攻撃では、標的となった組織の機密情報が盗まれるだけでなく、取引先、顧客、グループ会社、委託先、政府機関などへ影響が広がることがあります。特に近年のAPT攻撃では、サプライチェーンやクラウドサービス、リモートアクセス環境が狙われるケースが目立ちます。攻撃者は、最も守りが固い本丸を正面から攻撃するのではなく、比較的侵入しやすい周辺システムや取引先、公開サーバ、保守用アカウントなどを足がかりにします。

    また、APT攻撃は発見までに時間がかかることがあります。侵入直後に大規模な障害やランサムウェア被害が起きるとは限らず、攻撃者が長期間にわたって潜伏し、情報収集や権限拡大を続ける場合があります。そのため、事例を通じて攻撃の流れを理解し、侵入前の防御だけでなく、侵入後の検知や初動対応を整えることが重要です。

    APT攻撃の具体的な手口の流れは、こちらで解説しています。ぜひあわせてご覧ください。
    APT攻撃の手口とは?侵入から情報窃取までの流れを解説

    SolarWindsへのサプライチェーン攻撃(2020年12月)

    SolarWinds事件は、APT攻撃の代表的な事例として広く知られています。SolarWinds社が提供するIT管理ソフトウェア「Orion」の正規アップデートが攻撃に悪用され、利用組織に不正なコードが配布されたサプライチェーン攻撃です。この事件の特徴は、攻撃者がソフトウェアの利用企業を直接攻撃したのではなく、多くの組織が信頼して利用していた正規ソフトウェアの更新プロセスを悪用した点にあります。企業や政府機関にとって、利用中のソフトウェアベンダーから提供されるアップデートは、通常は信頼できるものとして扱われます。攻撃者はこの信頼関係を逆手に取り、正規の更新に紛れ込む形で侵入の足がかりを作りました。

    この事例から学べることは、「正規のアップデートだから安全」という前提そのものが攻撃対象になり得るということです。ベンダーのセキュリティ体制を確認するだけでは不十分で、正規プロセスを経た通信であっても、通常と異なる挙動(普段アクセスしない外部ホストへの通信など)を検知できる仕組みが必要になります。

    Microsoft Exchange Serverを狙った攻撃(2021年3月)

    Microsoft Exchange攻撃は、オンプレミス版のMicrosoft Exchange Serverに存在した複数の脆弱性が悪用された事例です。攻撃者は脆弱性を悪用してExchange Serverへアクセスし、メールアカウントへのアクセスや、長期的な侵入を可能にする追加のマルウェア設置を行っていました。これを受け、Microsoftは2021年3月、Exchange Serverを狙ったゼロデイ攻撃を公表し、セキュリティ更新プログラムの適用を強く呼びかけました*6

    この事例の重要な点は、公開サーバの脆弱性がAPT攻撃の入口になり得ることです。メールサーバは多くの組織で外部と通信するために利用され、インターネットからアクセス可能な状態で運用されることがあります。そのため、脆弱性が存在すると、攻撃者にとって非常に価値の高い侵入経路になります。

    この事例から学べることは、「パッチを当てて終わり」にしてはいけないということです。すでに攻撃者が侵入していた場合、更新プログラムを適用しても、設置済みのバックドアや不正アカウントが残る可能性があります。実際、この攻撃では公表後も被害が拡大し、パッチ適用と並行した侵害有無の確認(ログ調査、IOC確認、認証情報のリセットなど)の重要性が浮き彫りになりました。

    日本企業を狙ったAPT攻撃

    APT攻撃は海外だけの問題ではありません。日本企業や日本の組織も、APT攻撃の標的になっています。日本を標的とするAPTグループとしては、APT10、Kimsuky、Lazarusなどが広く知られており、標的型メールやVPN機器の脆弱性悪用など複数の手口が確認されています。日本には、製造業、研究機関、重要インフラ、防衛関連、先端技術、金融、通信、行政機関など、攻撃者にとって価値の高い情報を持つ組織が多く存在します。そのため、技術情報、知的財産、政策関連情報、取引情報、認証情報などを狙った攻撃が継続的に確認されています。

    たとえば、APT10に関しては、内閣サイバーセキュリティセンター(NISC)2018年12月に注意喚起を行っています*2。APT10は、標的型メール攻撃や知的財産の窃取などとの関連で国際的に注目された攻撃グループです。

    またJPCERT/CCは2024年3月、日本組織を標的としたKimsukyの攻撃活動を公表しました*3。外交・安全保障関連組織を装った標的型メールを送付し、PowerShellを利用した情報窃取やキーロガーの展開など、侵入後に発見されにくい手口が確認されています。

    この事例から学べることは、国内拠点だけでなく、海外拠点やグループ会社、委託先も攻撃経路になり得るという点です。海外拠点では、本社と比べてセキュリティ人材や監視体制が不足している場合があります。攻撃者はそのような弱点を利用し、グループ全体のネットワークへ侵入しようとする可能性があります。本社だけでなく、グループ会社・海外拠点・委託先との接続点を含めたリスク管理が欠かせません。

    事例から見える共通点

    SolarWinds事件、Microsoft Exchange攻撃、日本企業を狙ったAPT攻撃には、それぞれ異なる背景があります。しかし、複数の事例を比較すると、いくつかの共通点が見えてきます。

    第一に、APT攻撃では信頼された経路が悪用されやすいという点です。SolarWinds事件では正規ソフトウェアの更新経路が悪用され、Microsoft Exchange攻撃では業務に不可欠なメールサーバが狙われました。日本企業を狙った攻撃でも、取引先や関係機関を装った標的型メール、VPNなどの業務上必要な接続経路が悪用されています。

    第二に、脆弱性や設定不備が侵入の足がかりになる点です。公開サーバやVPN、メールシステムなどに未修正の脆弱性が残っていると、攻撃者はそこから内部へ侵入できます。特に、悪用が確認された脆弱性への対応が遅れると、APT攻撃だけでなく、ランサムウェア攻撃や情報窃取にもつながる可能性があります。

    第三に、侵入後の発見が難しい点です。APT攻撃者は、正規アカウント、管理ツール、暗号化通信、業務時間帯の通信などを利用し、通常業務に紛れるように活動します。そのため、入口対策だけでは不十分であり、EDR、SIEM、ログ監視、認証ログの分析などを通じて、侵入後の異常を見つける体制が必要です。

    第四に、サプライチェーン全体へ被害が波及する可能性がある点です。サプライチェーン攻撃では、自社が侵害されることで取引先に被害が広がる可能性があります。逆に、取引先や委託先が侵害され、自社が被害を受けることもあります。

    事例から企業が学ぶべきこと

    3つの事例を通じて見えてくるのは、対策を個別の製品導入で終わらせず、「侵入されることを前提とした備え」を組織全体で作ることの重要性です。

    • SolarWinds事件からは、信頼している経路ほど疑う視点を持つ必要性
    • Microsoft Exchange攻撃からは、パッチ適用後も侵害有無を確認する姿勢の必要性
    • 日本企業を狙った攻撃からは、本社以外の拠点・委託先を含めたリスク管理の必要性

    いずれの事例にも共通するのは、「侵入を完全に防ぐ」だけではなく、「侵入後を見据えた検知・監視・対応体制」が被害の最小化につながるという点です。

    まとめ

    APT攻撃事例を見ると、攻撃者は標的組織へ直接侵入するだけでなく、ソフトウェア更新、公開サーバ、VPN、標的型メール、取引先、海外拠点など、さまざまな経路を悪用していることがわかります。SolarWinds事件はサプライチェーン攻撃のリスクを示し、Microsoft Exchange攻撃は外部公開システムの脆弱性管理の重要性を示しました。日本企業を狙ったAPT攻撃からは、国内組織も継続的に標的となっている現実が見えてきます。

    過去の攻撃事例は単なるニュースではなく、自社のセキュリティ対策を改善するための実践的な教材です。事例から学び、自社の弱点を具体的に見直すことこそが、APT攻撃の被害を最小限に抑える第一歩といえます。

    APT攻撃への備えでは、侵入前の対策だけでなく、侵入後の検知・監視・初動対応まで含めた多層的な対策が重要です。具体的な対策については、「APT攻撃対策とは?検知・監視・初動対応の考え方」で詳しく解説しています。

    【参考情報】

    編集責任:木下


    APT攻撃への備えをご検討中の方へ

    APT攻撃は、侵入を完全に防ぐことが難しい高度なサイバー攻撃です。侵入経路の把握や脆弱性管理、監視体制の強化など、継続的な対策が求められます。弊社、ブロードバンドセキュリティ(BBSec)では、脆弱性診断、アタックサーフェス管理調査、セキュリティ運用サービス、コンサルティングサービスなど、企業のセキュリティ対策を支援するサービスを提供しています。


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

    最新情報はこちら


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

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

    APT攻撃対策とは?検知・監視・初動対応の考え方

    Share
    APT攻撃対策とは?検知・監視・初動対応の考え方アイキャッチ画像

    前回記事で解説した通り、APT攻撃は標的組織を事前に調査したうえで侵入し、権限昇格や横展開を重ねながら目的の情報に近づいていきます。一度侵入を許すと長期間にわたり情報窃取や不正活動が継続するケースも少なくありません。そのためAPT攻撃対策では「侵入させない」ことだけを目指すのではなく、侵入前対策・侵入後対策・インシデント対応体制を組み合わせ、早期発見と被害最小化を実現する仕組みが欠かせません。本記事では、その具体的な対策内容について解説します。

    APT攻撃の侵入経路や攻撃の流れについて詳しく知りたい方は、「APT攻撃の手口とは?侵入から情報窃取までの流れを解説」で、初期侵入から情報窃取までのプロセスを解説しています。ぜひあわせてご覧ください。

    なぜAPT攻撃は防ぎにくいのか

    APT攻撃が防ぎにくい理由は、攻撃者が特定の組織を狙い、時間をかけて侵入経路を探すためです。一般的なマルウェア感染やばらまき型攻撃とは異なり、APT攻撃では、攻撃者が標的組織の業務、取引先、利用システム、従業員の役割などを事前に調査します。そのうえで、標的型メールや脆弱性の悪用、正規アカウントの不正利用など、検知されにくい手口を選びます。また、APT攻撃では、最初の侵入後すぐに目立つ被害が発生するとは限りません。攻撃者は内部ネットワークに潜伏し、権限昇格や横展開を行いながら、機密情報や認証情報の所在を探ります。正規の管理ツールや盗まれたID・パスワードを使って活動する場合もあり、従来型の境界防御だけでは不審な動きを見落とす可能性があります。そのため、APT攻撃対策では、入口を守る対策に加えて、侵入後の異常を検知する仕組み、ログをもとに調査できる体制、被害を最小化する初動対応が欠かせません。さらに、入口対策だけでなく、「侵入を前提」とした検知・監視・対応体制も必要です。

    侵入前対策

    APT攻撃への備えとして、まず重要になるのは侵入前対策です。侵入前対策とは、攻撃者が組織内へ入り込む可能性を下げるための基本的な防御策です。完全な防御は難しいものの、攻撃者にとって侵入しにくい環境を作ることで、被害の発生確率を下げることができます。 なかでも重要なのが、多要素認証、脆弱性管理、標的型メール対策です。これらは単独ではなく、多層防御の考え方で組み合わせることが重要です。複数の対策を組み合わせ、攻撃者が一つの弱点を突破しても、次の段階へ進みにくい状態をつくることが求められます。

    MFA(多要素認証)

    IDとパスワードだけに頼らず、スマートフォンアプリ、セキュリティキー、生体認証など、複数の認証要素を組み合わせて本人確認を行う仕組みです。APT攻撃では、フィッシングメールやマルウェアによって認証情報が盗まれることがあります。IDとパスワードだけで社内システムやクラウドサービスへアクセスできる環境では、攻撃者が正規ユーザになりすましてログインするリスクが高まります。MFAを導入することで、パスワードが漏えいした場合でも、不正ログインを防げる可能性が高まります。ただし、MFAを導入すればすべての攻撃を防げるわけではありません。近年は、MFAを突破しようとするフィッシングや、認証疲れを狙った攻撃も確認されています。そのため、可能であればフィッシング耐性の高い認証方式(例:FIDO2、パスキーなど)を採用し、管理者アカウントやリモートアクセス、クラウド管理画面など、重要度の高い環境から優先的に適用することが重要です。

    脆弱性管理

    APT攻撃では、VPN機器、公開サーバ、メールサーバ、業務システム、クラウド環境などの脆弱性が侵入経路として悪用されることがあります。特に、インターネットからアクセス可能な機器やシステムに未修正の脆弱性が残っている場合、攻撃者にとって侵入の足がかりになります。脆弱性管理では、単に脆弱性情報を収集するだけでなく、自社のどのシステムに影響があるのか、外部公開されているのか、悪用事例があるのか、業務上の重要度は高いのかを踏まえて、対応の優先順位を決める必要があります。すべての脆弱性へ同時に対応することは現実的ではないため、実際に悪用されている脆弱性や、外部から攻撃可能なシステムを優先して修正する考え方が重要です。また、パッチ適用がすぐに難しい場合には、一時的な回避策、アクセス制限、監視強化、不要サービスの停止などを組み合わせる必要があります。APT攻撃では、脆弱性の放置が初期侵入や横展開につながる可能性があるため、脆弱性管理は単なる情報システム部門の運用作業ではなく、経営リスクを下げるための重要な取り組みといえます。

    標的型メール対策

    標的型メールは、APT攻撃の代表的な侵入経路の一つです。現在はメールだけでなく、チャットやクラウドサービスを悪用した攻撃も増えています。標的型メール対策では、メールセキュリティ製品による検査だけでなく、従業員教育、訓練、報告しやすい仕組みの整備が重要です。攻撃メールを完全に遮断することは難しいため、従業員が不審なメールに気づき、開封前または開封後すぐに報告できる体制を作る必要があります。また、メールをきっかけに認証情報が入力されるケースもあるため、MFAやアクセス制御と組み合わせて対策することが効果的です。標的型メール対策は、単独で完結するものではなく、認証管理、端末防御、ログ監視、インシデント対応と連動させることで、初めてAPT攻撃への実効性が高まります。

    標的型攻撃の手口の詳細は「標的型攻撃とは?代表的な手口と企業が取るべき対策を解説」をご参照ください。

    侵入後対策

    APT攻撃では、侵入前対策をすり抜けられる可能性があります。そのため、侵入後に攻撃者の活動を検知し、被害拡大を防ぐ仕組みが必要です。侵入後対策の中心になるのが、EDR、SIEM、ログ監視です。従来のセキュリティ対策では、外部からの攻撃を境界で防ぐことに重点が置かれてきました。しかし、クラウド利用、テレワーク、サプライチェーン連携が広がる現在では、社内と社外の境界があいまいになっています。APT攻撃への対策では、端末、サーバー、ネットワーク、クラウド、IDの動きを継続的に監視し、通常とは異なる振る舞いを早期に見つけることが重要です。

    EDR

    EDRは、Endpoint Detection and Responseの略で、PCやサーバーなどのエンドポイント上の不審な挙動を検知し、調査や対応を支援する仕組みです。APT攻撃では、マルウェアの実行、認証情報の窃取、管理ツールの悪用、不審なプロセスの起動などが端末上で発生することがあります。EDRは、こうした端末上の動きを可視化し、攻撃の兆候を把握するために有効です。EDRの重要な役割は、単にマルウェアを検知することではありません。侵入後に何が起きたのか、どの端末からどの端末へ移動したのか、どのファイルが操作されたのか、どのアカウントが使われたのかを調査するための情報を提供する点にあります。APT攻撃では、発見時点で攻撃がすでに横展開している場合もあります。そのため、EDRによって端末単位の挙動を把握し、感染端末の隔離、プロセス停止、調査対象の特定などを迅速に行える状態を整えておく必要があります。最近では、EDRに加え、メールやクラウドも含めて分析するXDRを導入する企業も増えています。

    SIEM

    SIEMは、Security Information and Event Managementの略で、複数のシステムからログを集約し、相関分析(複数のログを組み合わせて関連性を分析すること)を行う仕組みです。APT攻撃では、個々のログだけを見ると小さな異常に見える行動が、複数のログを組み合わせることで攻撃の流れとして見えてくることがあります。たとえば、通常とは異なる国や地域からのログイン、深夜帯の管理者権限利用、短時間での大量アクセス、普段使わない端末からの認証、ファイルサーバへの大量アクセスなどは、単独では見逃されることがあります。しかし、SIEMで複数のログを関連付けることで、初期侵入、権限昇格、横展開、情報窃取の兆候を把握しやすくなります。SIEMを有効に活用するには、ログを集めるだけでなく、どのログを監視対象にするのか、どのような条件でアラートを出すのか、誰が確認するのか、アラート発生後にどのような初動を取るのかを事前に決めておく必要があります。そしてツールを導入するだけではなく、運用設計まで含めて整えることも重要です。社内で運用が難しい場合は、SOCサービスなど外部監視サービスを利用する方法もあります。

    ログ監視

    ログ監視は、APT攻撃対策の基盤となる取り組みです。攻撃者の行動は、認証ログ、端末ログ、プロキシログ、DNSログ、VPNログ、クラウドサービスの監査ログ、ファイルアクセスログなどに痕跡として残ることがあります。しかし、ログが取得されていなかったり、保存期間が短かったり、必要な項目が記録されていなかったりすると、インシデント発生後に攻撃の流れを追跡できません。特にAPT攻撃では、侵入から発見までに時間がかかることがあるため、一定期間のログを保管し、過去にさかのぼって調査できる状態を作る必要があります。ログ監視では、単に大量のログを保存するだけでは不十分です。重要なのは、通常時のアクセス傾向を把握し、そこから外れた動きを見つけることです。普段アクセスしないサーバーへの接続、短時間での権限変更、退職者アカウントの利用、海外からのVPN接続、大量のファイル圧縮や外部送信など、攻撃の兆候となる行動を継続的に確認する必要があります。保持期間は法令や業種要件、インシデント対応を考慮して決める必要があります。

    ゼロトラストの考え方

    ここまで紹介した侵入前対策・侵入後対策は、いずれもゼロトラストという一つの考え方の実装例と捉えることができます。

    ゼロトラストとは、社内ネットワークにいるから安全、正規ユーザだから安全といった前提を置かず、ユーザ、端末、アプリケーション、データへのアクセスを継続的に確認する考え方です。従来の境界防御では、社内ネットワークの内側を比較的信頼する考え方が一般的でした。しかし、APT攻撃では、一度内部へ侵入した攻撃者が正規アカウントや管理ツールを悪用し、横展開する可能性があります。そのため、社内ネットワーク内の通信であっても、常に正当性を確認し、必要最小限の権限だけを付与することが前提になります。ゼロトラストの実現には、MFA、ID管理、端末管理、アクセス制御、ログ監視、ネットワーク分離、継続的なリスク評価などが関係します。単一の製品を導入すれば完成するものではなく、組織の業務やシステム構成に合わせて段階的に整備していく必要があります。

    APT攻撃への対策としてゼロトラストを取り入れることで、攻撃者が一つのアカウントや端末を悪用しても、重要情報へ簡単に到達できない環境を作りやすくなります。侵入を前提に、被害範囲を限定し、異常を早期に検知するという点で、ゼロトラストはAPT対策と相性のよい考え方です。

    インシデント対応体制

    APT攻撃への対策では、検知した後の初動対応によって被害の大きさが大きく左右されます。初動対応では「封じ込め(Containment)」「根絶(Eradication)」「復旧(Recovery)」の順で進める考え方が一般的です。不審な挙動を発見しても、対応手順や判断基準が決まっていなければ、関係者への連絡、端末隔離、証拠保全、外部報告、復旧判断が遅れてしまいます。その間に攻撃者が横展開を進めたり、情報を外部へ持ち出したりする可能性があります。

    インシデント対応体制では、まず「誰が判断するのか」を明確にする必要があります。情報システム部門、セキュリティ担当、経営層、法務、広報、事業部門、外部専門家など、関係者の役割を事前に決めておくことが重要です。特にAPT攻撃では、技術的な調査だけでなく、事業影響、顧客対応、取引先対応、法的対応、広報対応が必要になる場合があります。 また、初動対応では、証拠を消さないことも重要です。感染が疑われる端末をすぐに初期化してしまうと、侵入経路や攻撃範囲を調査するための情報が失われる可能性があります。端末の隔離、ログ保全、アカウント停止、通信遮断、影響範囲の確認などを、状況に応じて慎重に実施する必要があります。平時からインシデント対応手順を整備し、訓練を行っておくことで、実際の攻撃発生時に混乱を減らすことができます。APT攻撃対策は、技術的な防御だけではなく、組織としてどのように判断し、対応するかまで含めた取り組みです。

    まとめ

    APT攻撃対策では、侵入を完全に防ぐことだけを目指すのではなく、侵入前対策、侵入後対策、インシデント対応体制を組み合わせることが重要です。MFA、脆弱性管理、標的型メール対策によって侵入リスクを下げ、EDR、SIEM、ログ監視によって侵入後の不審な動きを早期に検知します。さらに、インシデント対応体制を整備し、攻撃が疑われる場合に迅速な初動対応を取れるようにしておくことで、被害の拡大を抑えることができます。APT攻撃は、攻撃者が時間をかけて目的達成を狙う攻撃であるため、企業側も継続的な監視と改善を前提に備える必要があります。

    次の記事はこちら
    APT攻撃事例から学ぶ ―国内外の被害事例と企業が取るべき対策―」
    APT攻撃は実際にどのような企業・組織で発生しているのでしょうか。代表的な国内外の事例から、攻撃の特徴や企業が学ぶべきポイントを解説します。

    【参考情報】

    編集責任:木下


    APT攻撃への備えをご検討中の方へ

    APT攻撃は、侵入を完全に防ぐことが難しい高度なサイバー攻撃です。侵入経路の把握や脆弱性管理、監視体制の強化など、継続的な対策が求められます。弊社、ブロードバンドセキュリティ(BBSec)では、脆弱性診断、アタックサーフェス管理調査、セキュリティ運用サービス、コンサルティングサービスなど、企業のセキュリティ対策を支援するサービスを提供しています。


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

    最新情報はこちら


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

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

    IT資産管理を効率化する方法とは?担当者が押さえたい運用のポイント

    Share
    IT資産管理を効率化する方法とは?アイキャッチ画像

    IT資産管理を継続するには、台帳を作成するだけでは十分ではありません。定期的な棚卸しや資産台帳の整備、ツールの活用、運用ルールの見直しなど、継続して管理できる仕組みづくりが重要です。本記事では、IT資産管理を効率化するための基本ステップと、実務で押さえたい運用のポイントを解説します。

    IT資産管理の基本について知りたい方は、まず「IT資産管理とは」をご覧ください。
    IT資産管理とは?企業のセキュリティ対策で最初に取り組むべき理由を解説

    IT資産管理は重要だと分かっていても、実際の運用では「台帳が更新されない」「管理対象が多すぎる」「クラウドやSaaSまで把握しきれない」といった悩みが起こりがちです。特に、少人数の情報システム部門や兼任体制の企業では、手作業だけでIT資産を正確に管理し続けるのは現実的ではありません。

    IT資産管理で押さえるべき基本ステップ

    IT資産管理を効率化するには、いきなりツールを導入するのではなく、基本ステップを整理することが大切です。最初に行うべきことは、管理対象の範囲を決めることです。PC、サーバー、ネットワーク機器、スマートフォン、タブレット、ソフトウェア、クラウドサービス、SaaS、アカウント、ライセンスのうち、どこまでをIT資産管理の対象にするのかを明確にします。次に、現在のIT資産を棚卸しします。棚卸しによって、台帳に載っていない端末、使われていないSaaS、放置されたクラウド環境、サポート期限が近いソフトウェアなどを洗い出します。その後、資産台帳を整備し、資産の種類、利用者、管理責任者、重要度、バージョン、サポート期限、最終確認日などを記録します。

    棚卸しを定期的に行う

    IT資産棚卸しは、IT資産管理の出発点です。棚卸しでは、以下のような複数の情報源を突き合わせます。ひとつの情報源だけに頼ると、見落としが発生しやすいため、複数の情報を照合することが重要です。

    • 購買台帳・リース契約
    • MDM/EDR
    • Active DirectoryやID管理基盤
    • クラウド管理画面
    • SaaSの契約情報 – ネットワーク接続情報

    たとえば、購買台帳には存在するのにEDRには表示されない端末があれば、未セットアップ、未接続、廃棄漏れの可能性があります。逆に、EDRやネットワーク上には存在するのに購買台帳や資産台帳にない端末があれば、未登録端末や持ち込み端末の可能性があります。クラウド環境では、誰が作成したか分からないインスタンス、公開設定のまま放置されたストレージ、検証後に削除されていないリソースを確認します。棚卸しの頻度は、企業規模やIT環境によって異なりますが、少なくとも年1回の一斉棚卸しだけでは変化に追いつきにくくなっています。端末の入れ替え、SaaS契約、クラウド環境の作成など、変化が多い領域については、月次や四半期単位で確認する運用が望ましいでしょう。

    どのような資産が見落とされやすいかについては「見落としがちなIT資産がセキュリティ事故を招く?企業で起こりやすい5つの管理課題」もあわせてご覧ください。

    資産台帳を整備する

    棚卸しで見つけたIT資産は、資産台帳に整理します。台帳は、単に資産名を並べるためのものではありません。脆弱性対応、パッチ適用、ライセンス管理、費用管理、インシデント対応に使える情報でなければ、実務では役に立ちません。資産台帳には、資産ID、資産種別、製品名、メーカー、OSやソフトウェアのバージョン、利用者、所属部門、管理責任者、設置場所、IPアドレス、利用目的、業務上の重要度、保存・処理する情報の種類、サポート期限、ライセンス情報、最終確認日などを記録します。すべてを最初から完璧に埋める必要はありませんが、脆弱性対応やインシデント対応に必要な項目は優先して整備するべきです。

    NIST SP 1800-5では、有効なIT資産管理は物理資産と仮想資産を結びつけ、資産が何で、どこにあり、どのように使われているかを把握できるようにするものと説明されています。 この視点を踏まえると、台帳は固定的な一覧ではなく、現場の利用実態を反映する情報基盤として設計する必要があります。

    ツールで自動化する

    IT資産管理を効率化するうえで、ツールによる自動化は有効です。管理対象が少ないうちは手作業でも対応できますが、端末、クラウド、SaaS、アカウント、ソフトウェアが増えると、人手だけで最新状態を維持するのは難しくなります。IT資産管理ツールを使えば、端末情報、インストール済みソフトウェア、OSバージョン、利用者情報、接続状況などを自動収集しやすくなります。MDMはモバイル端末やPCの管理に役立ち、EDRは端末の稼働状況やセキュリティ状態の把握に活用できます。クラウド環境では、クラウド管理ツールやCSPMによって、リソース、設定、公開状態、権限の可視化を進められます。SaaSについては、ID管理基盤やSaaS管理ツールと連携し、利用アカウントや不要ライセンスを確認します。

    IT資産管理ツールによって可視化した資産情報は、脆弱性管理にも活用できます。資産台帳とスキャン結果を結びつけることで、どの資産にどの脆弱性が存在するのかを把握しやすくなります。

    運用ルールを整備する

    IT資産管理は、ツールを導入するだけでは定着しません。新しい端末を購入したとき、SaaSを契約したとき、クラウド環境を作成したとき、従業員が異動・退職したとき、機器を廃棄したときに、誰が、いつ、どの情報を更新するのかを決めておく必要があります。

    ライフサイクル管理

    調達から廃棄までのライフサイクルにIT資産管理を組み込むことも重要です。購入申請時に資産登録を行い、利用開始時に管理責任者を設定し、定期的に利用状況を確認し、不要になったらアカウント停止やデータ消去、契約解除、廃棄証跡の保管まで行う。この流れが決まっていないと、台帳はすぐに古くなります。

    シャドーIT対策

    シャドーIT対策では、禁止だけでなく申請しやすい仕組みも必要です。現場が必要なツールを安全に使える申請ルート、承認済みSaaSの一覧、例外利用時の確認項目を整備することで、非公式な利用を減らしやすくなります。英国のサイバーセキュリティ機関NCSCも、「シャドーITは従業員が業務上の課題を解決しようとして発生することが多く、責めるのではなく、報告しやすいセキュリティ文化を作ることが重要」だと説明しています*4

    IT資産の可視化を脆弱性管理やパッチ管理につなげる

    近年では、社内で管理しているIT資産だけでなく、インターネット上に公開されている資産を継続的に把握・管理するために、ASM(Attack Surface Management)を活用する企業も増えています。

    IT資産の可視化はゴールではありません。可視化した資産情報を、脆弱性管理やパッチ管理につなげることが重要です。NIST SP 800-40 Rev.4では、パッチ管理を、パッチやアップデートを識別し、優先順位付けし、取得し、適用し、適用結果を検証するプロセスとして説明しています。 その前提として、どの資産が存在し、どのソフトウェアやバージョンを利用しているかを把握している必要があります。たとえば、重大な脆弱性が公開された場合、資産台帳が整備されていれば、対象バージョンを利用している端末やサーバーをすばやく抽出できます。重要システム、外部公開システム、個人情報を扱うシステムなどを優先して対応する判断も可能になります。逆に、資産情報がなければ、全社に一斉確認を依頼するしかなく、対応に時間がかかります。

    IT資産管理、脆弱性管理、パッチ管理は別々の業務ではなく、つながった運用として設計することが重要です。IT資産を把握し、リスクを評価し、優先順位をつけ、対策し、結果を確認する。この流れができて初めて、セキュリティ対策は継続的に機能します。

    まとめ:効率化の目的は、管理を楽にすることではなく対応を早くすること

    IT資産管理を効率化する目的は、単に運用負荷を減らすことではありません。IT資産を継続的に把握し、脆弱性への対応やインシデント発生時の初動対応を迅速に行える状態を維持することが重要です。そのためには、定期的な棚卸しや資産台帳の整備、ツールによる自動化、運用ルールの見直しを組み合わせ、自社のIT環境に合わせた継続的な運用を構築しましょう。

    【参考情報】

    CIS(Center for Internet Security)「The 18 CIS Critical Security Controls」(https://www.cisecurity.org/controls/cis-controls-list

    【関連記事】

    編集責任:木下


    公開IT資産を可視化してみませんか?

    社内で管理しているIT資産と、インターネット上から見える資産は必ずしも一致しません。攻撃者視点で公開資産を可視化する「アタックサーフェス調査サービス」をご紹介します。

    BBSecのアタックサーフェス調査サービス

    インターネット上で「攻撃者にとって対象組織はどう見えているか」調査・報告するサービスです。攻撃者と同じ観点に立ち、企業ドメイン情報をはじめとする、公開情報(OSINT)を利用して攻撃可能なポイントの有無を、弊社セキュリティエンジニアが調査いたします。


    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

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

    見落としがちなIT資産がセキュリティ事故を招く?企業で起こりやすい5つの管理課題

    Share
    「見落としがちなIT資産管理の課題5選」アイキャッチ画像

    前回記事では、IT資産管理の基本と重要性を解説しました。管理されていない端末やクラウド環境、シャドーIT、サポート終了製品など、見落とされたIT資産が被害につながるケースも少なくありません。今回は、管理が行き届かない場合に実際どのような問題が起こりやすいのか、企業で起こりやすい5つの管理課題を具体的に見ていきます。

    IT資産管理の基本について知りたい方は、まず「IT資産管理とは」をご覧ください。
    IT資産管理とは?企業のセキュリティ対策で最初に取り組むべき理由を解説

    セキュリティ事故は、必ずしも高度な攻撃だけで起こるわけではありません。実際には、管理されていない端末、放置されたクラウド環境、退職者のアカウント、サポート終了ソフトウェアなど、見落としがちなIT資産がきっかけになることがあります。IT資産管理が不十分な状態では、脆弱性情報が公開されても対象資産を特定できず、インシデント発生時にも影響範囲をすばやく把握できません。

    なぜ管理漏れが起こるのか

    IT資産の管理漏れは、担当者の怠慢だけで起こるものではありません。むしろ、事業スピードに管理体制が追いつかないことで発生します。新しいSaaSを部門単位で契約する、検証用にクラウド環境を作成する、テレワーク用に端末を追加する、業務委託先にアカウントを付与する。こうした日常的な業務の中で、台帳更新や承認プロセスが後回しになると、実態とのズレが広がっていきます。

    企業で起こりやすい5つの管理課題

    台帳が更新されない

    IT資産管理で最も起こりやすい課題は、資産台帳が更新されないことです。導入時には正確だった台帳も、ソフトウェア更新やクラウド環境の追加が反映されなければ、すぐに実態とずれていきます。特にExcelやGoogleスプレッドシートで管理している場合、更新担当者が限られ、現場の変更が反映されないまま時間が経過しがちです。その結果、台帳上は存在するのに実際には廃棄済みの機器、逆に台帳にはないが稼働している資産が発生します。インシデント対応時にこの状態だと、影響範囲の特定に時間がかかり、初動対応の遅れにつながります。

    シャドーITが増える

    シャドーITとは、情報システム部門や管理部門が把握していないIT資産やサービスが、業務目的で利用されている状態を指します。英国のサイバーセキュリティ機関NCSCでは、「シャドーITは悪意によって生まれるとは限らず、従業員が業務を進めるために、承認済みのツールやプロセスでは対応できない課題を解決しようとして発生することが多い」と説明しています。たとえば、ファイル共有が不便だから個人用クラウドストレージを使う、社内承認に時間がかかるため部門でSaaSを契約する、開発検証のために個人名義に近い形でクラウド環境を作る、といった行動です。本人に悪意がなくても、会社のセキュリティポリシー、バックアップ、アクセス制御、監査ログ、退職時のアカウント削除の対象外になるため、情報漏洩や不正アクセスのリスクが高まります。シャドーIT対策で重要なのは、単に禁止することではありません。なぜ現場が非公式な手段を使わざるを得なかったのかを把握し、業務に必要なツールを安全に使える仕組みに変えることです。

    クラウド資産が把握できない

    クラウド環境では、サーバやストレージ、データベース、コンテナ、API、アカウント、権限設定などが短時間で作成・変更・削除されます。オンプレミス環境のように物理的なサーバーが目に見えるわけではないため、管理対象から漏れやすいのが特徴です。検証用に作ったクラウド環境が放置され、インターネットに公開されたままになる。開発者が一時的に広い権限を付与し、その後も戻されない。ログ設定やバックアップ設定が本番環境と異なる。こうした状態は、クラウド利用が進む企業ほど起こりやすくなります。米国サイバーセキュリティ・インフラストラクチャセキュリティ庁(CISA)の「Cybersecurity Performance Goals」でも、既知の資産だけでなく、未知の資産、シャドー資産、未管理資産を特定し、新たな脆弱性への検知・対応を速めることが目的として示されています。

    EOL(End of Life)・EOS(End of Service)を見逃す

    サポートが終了したOS、ネットワーク機器、VPN機器、業務アプリケーション、ミドルウェアを使い続けることも、IT資産管理上の大きな課題です。サポートが終了した製品は、脆弱性が発見されても修正プログラムが提供されない可能性があります。資産台帳にサポート期限や保守期限が記録されていなければ、更新計画を立てることもできません。

    EOL・EOSについては前回記事でも触れていますので、あわせてご覧ください。

    また、ソフトウェア資産の構成管理まで行いたい場合、EOL・EOS対策の延長としてSBOM(ソフトウェア部品表)も重要になります。経済産業省「ソフトウェア管理に向けたSBOMの導入に関する手引 Ver.2.0」では、資産管理台帳だけでは、下位コンポーネントとして利用されるOSSなどに脆弱性が見つかった場合に、間接的な影響を検知できない場合があると説明されています。

    SBOMについては、「SBOMとは?ソフトウェア部品表の基本と企業が導入すべき理由」でも解説しています。あわせてご覧ください。

    部門ごとに管理している

    IT資産管理が部門ごとに分断されていることも、企業でよく見られる課題です。情報システム部門はPCとネットワーク機器を管理し、開発部門はクラウド環境を管理し、総務部門はリース契約を管理し、各事業部がSaaS契約を管理している。このような状態では、全社としてどのIT資産が存在するのかを把握できません。部門ごとの管理は、現場のスピードを保つうえでは便利です。しかし、セキュリティ事故が起きたときには、誰が責任者なのか、どの情報が保存されているのか、どの範囲に影響があるのかが分からなくなります。特に、SaaSやクラウドサービスでは、管理者権限を持つ担当者が異動・退職した後に、契約やアカウントだけが残り続けるケースもあります。

    管理課題を解決するポイント

    IT資産管理の課題を解決するには、台帳を作るだけでは不十分です。重要なのは、資産が増える、変わる、使われなくなるタイミングで、台帳や管理システムが自然に更新される運用を作ることです。まず、IT資産管理の対象範囲を明確にします。PCやサーバだけでなく、クラウド環境、SaaS、アカウント、ネットワーク機器、ソフトウェア、ライセンスまで含めるかを決めます。次に、資産ごとに管理責任者を定めます。所有者が曖昧な資産は、脆弱性対応や費用管理、廃棄判断が遅れやすくなります。そのうえで、購買、入社、異動、退職、クラウド作成、SaaS契約、機器廃棄といった業務フローにIT資産管理を組み込みます。ツールを導入する場合も、単体で完結させるのではなく、ID管理、EDR、MDM、脆弱性管理、クラウド管理と連携させることで、実態に近い情報を保ちやすくなります。

    課題を解決する具体的な運用方法については「IT資産管理を効率化する方法とは?担当者が押さえたい運用のポイント」をご覧ください。

    まとめ:見えていないIT資産は、守れない

    IT資産管理の課題は、すぐに大きな障害として表面化するとは限りません。しかし、管理漏れ、シャドーIT、クラウド資産の放置、サポートが終了した製品・機器の見逃し、部門ごとの分断が積み重なると、セキュリティ事故の温床になります。

    次回は、こうした課題を解決するための具体的な運用方法について解説します。

    【参考情報】

    編集責任:木下


    公開IT資産を可視化してみませんか?

    社内で管理しているIT資産と、インターネット上から見える資産は必ずしも一致しません。攻撃者視点で公開資産を可視化する「アタックサーフェス調査サービス」をご紹介します。

    BBSecのアタックサーフェス調査サービス

    インターネット上で「攻撃者にとって対象組織はどう見えているか」調査・報告するサービスです。攻撃者と同じ観点に立ち、企業ドメイン情報をはじめとする、公開情報(OSINT)を利用して攻撃可能なポイントの有無を、弊社セキュリティエンジニアが調査いたします。


    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

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

    APT攻撃の手口とは?侵入から情報窃取までの流れを解説

    Share
    APT攻撃の手口とは?侵入から情報窃取までの流れを解説アイキャッチ画像

    前回記事では、APT攻撃の全体像と、標的型攻撃との違い、企業が直面するリスクについて解説しました。今回はその中でも、攻撃者が実際にどのような手順で組織へ侵入し、情報を窃取するに至るのかという「攻撃の流れ」に焦点を当てて解説します。

    APT攻撃は、マルウェアを送り付けて終わる単純な攻撃ではありません。攻撃者は事前に標的組織を調査し、侵入後も長期間にわたり潜伏しながら、社内システムの構造や重要情報の保管場所を探ります。そのうえで、認証情報の窃取、権限昇格、横展開、情報収集、外部送信といった複数の段階を踏み、最終的な目的を達成しようとします。本記事では、APT攻撃の侵入経路、侵入後の流れ、そして発見が難しい理由について解説します。

    APT攻撃の定義や特徴について詳しく知りたい方は、まずこちらの記事をご覧ください。「APT攻撃とは?標的型攻撃との違いと企業リスクを解説【2026年版】

    APT攻撃の特徴

    初期侵入

    APT攻撃の最初の段階は、標的組織の内部ネットワークへ入り込むことです。攻撃者は、いきなり重要サーバーを攻撃するのではなく、従業員の端末、リモートアクセス環境、取引先、公開Webサイトなど、比較的侵入しやすい入口を探します。

    初期侵入でよく使われる手口のひとつが、標的型メールです。攻撃者は、実在する取引先や社内関係者を装ったメールを送り、添付ファイルの開封や不正URLへのアクセスを誘導します。メールの文面は業務連絡に見えるよう作り込まれていることが多く、受信者が不審に感じにくい点が特徴です。また、VPN機器やリモートアクセス製品の脆弱性も、APT攻撃の侵入経路になり得ます。テレワークの普及により、外部から社内システムへ接続する仕組みは多くの企業で利用されています。しかし、脆弱性が残ったままの機器や、認証設定が不十分な環境は、攻撃者にとって格好の入口になります。

    標的型メールについて詳しくは、「標的型攻撃とは?代表的な手口と企業が取るべき対策を解説」をご覧ください。

    水飲み場攻撃も、APT攻撃で使われることがあります。これは、標的となる組織の従業員がよく閲覧するWebサイトを改ざんし、アクセスした利用者の端末にマルウェアを感染させる手口です。攻撃者が標的企業の業務や関係先を調査したうえで仕掛けるため、通常のWeb閲覧の中で侵入が発生する可能性があります。

    このように、APT攻撃の侵入経路は一つではありません。メール、VPN、Webサイト、取引先、クラウドサービスなど、業務で日常的に使われる経路が悪用される点に注意が必要です。

    権限昇格

    初期侵入に成功しても、攻撃者がすぐに目的の情報へアクセスできるとは限りません。多くの場合、最初に侵入できるのは一般従業員の端末や、限定的な権限しか持たないアカウントです。そこで攻撃者は、より強い権限を得るために権限昇格を試みます。権限昇格とは、一般ユーザーの権限から管理者権限へ、あるいは一部システムの権限から社内全体に影響する権限へと、アクセス範囲を広げる行為です。攻撃者は、端末内に保存された認証情報、設定ミス、未修正の脆弱性、過剰に付与された権限などを悪用します。

    特に認証情報の窃取は、APT攻撃の流れの中で重要な意味を持ちます。IDとパスワードを奪われると、攻撃者は正規ユーザーのようにシステムへアクセスできます。正規の認証情報を使った操作は、不審なマルウェア通信よりも見逃されやすく、発見を難しくする要因になります。 企業側では、管理者権限の利用状況、特権IDの管理、不要な権限の削除、多要素認証の導入などを通じて、攻撃者が権限を広げにくい環境を作ることが重要です。

    横展開

    権限を得た攻撃者は、次に社内ネットワーク内を移動します。この段階を横展開と呼びます。横展開の目的は、最初に侵入した端末から、ファイルサーバー、認証サーバー、業務システム、開発環境、クラウド環境などへアクセス範囲を広げることです。APT攻撃では、攻撃者が最初から機密情報の保管場所を正確に把握しているとは限りません。そのため、侵入後に社内ネットワークを調査し、どの端末やサーバーに価値のある情報があるのかを探ります。

    横展開では、リモートデスクトップ、共有フォルダ、管理ツール、正規のリモートアクセス機能などが悪用されることがあります。攻撃者が正規の管理ツールや認証情報を利用すると、通常業務との見分けがつきにくくなります。 この段階で重要なのは、ネットワーク内部の通信を「信頼しすぎない」ことです。境界防御だけに頼っていると、一度侵入された後の移動を見逃しやすくなります。社内ネットワーク内であっても、不自然なログイン、通常とは異なる時間帯のアクセス、大量のファイル閲覧、普段接続しないサーバーへのアクセスなどを監視する必要があります。

    情報窃取

    APT攻撃の多くは、最終的に機密情報や認証情報、知的財産、顧客情報、技術情報、経営情報などを盗み出すことを目的とします。攻撃者は、横展開によって目的の情報に近づいた後、必要なデータを収集し、外部へ送信します。情報窃取は、単純にファイルをそのまま外部へ送るだけではありません。攻撃者は、複数の端末やサーバーから情報を集め、一時的な保管場所にまとめることがあります。その後、ファイルを圧縮したり、分割したり、暗号化したりして、通常の通信に紛れ込ませながら外部へ送信します。

    このような手口を取る理由は、検知を避けるためです。大量のデータが一度に外部送信されると監視に引っかかる可能性があります。そのため、攻撃者は通信量や送信タイミングを調整し、業務上の通信に見えるように偽装することがあります。情報窃取を防ぐには、重要情報の保管場所を把握し、アクセス権限を最小限に抑えることが前提になります。加えて、通常とは異なるデータアクセスや外部通信を検知できる仕組みが求められます。

    長期潜伏

    APT攻撃の大きな特徴は、攻撃者が長期間にわたって潜伏する点です。侵入直後に情報を盗んで終わるのではなく、継続的に情報を収集したり、再侵入のための経路を確保したりすることがあります。ここまで便宜上、初期侵入から情報窃取までを順を追って説明してきましたが、バックドアの設置やアカウントの作成といった潜伏のための準備は、情報窃取の後にまとめて行われるわけではありません。攻撃者は多くの場合、初期侵入や権限昇格の段階から並行してこれらの仕込みを進めており、万が一発見されて一部のアクセス経路を塞がれても、環境内にとどまり続けられるようにしています。こうして確保された足場をもとに、攻撃者は認証情報の保持や正規ツールの悪用などにより、長期間にわたって環境内にとどまり続けようとします。また、検知された場合に備えて、複数の侵入経路やアクセス手段を用意することもあります。

    なぜ発見が難しいのか

    APT攻撃が発見されにくい理由は、攻撃者が目立たない行動を重ねるためです。攻撃者は、短時間で大きな被害を出すのではなく、正規ユーザーの操作や通常業務の通信に紛れるように活動します。特に、盗まれたIDとパスワードを使ったアクセス、正規の管理ツールの利用、業務時間に合わせた通信、少量ずつのデータ送信などは、従来型のセキュリティ対策だけでは見逃される可能性があります。また、APT攻撃では侵入経路が複数に分かれることもあります。標的型メール、VPN脆弱性、サプライチェーン、クラウドアカウント、公開サーバなど、複数の入口から攻撃が行われる場合、単一の対策だけでは全体像を把握しにくくなります。

    発見を難しくしているもう一つの要因は、ログの不足です。攻撃の痕跡はログに残ることがありますが、必要なログを取得していなかったり、保存期間が短かったり、分析体制が整っていなかったりすると、侵入後の流れを追跡できません。 APT攻撃に備えるには、侵入を完全に防ぐという発想だけでなく、侵入された場合に早く気づく、攻撃の範囲を把握する、被害を最小限に抑えるという考え方が重要になります。

    まとめ

    APT攻撃は、標的組織を調査し、初期侵入、権限昇格、横展開、情報窃取、長期潜伏といった段階を踏んで進行する高度なサイバー攻撃です。APT攻撃の手口は一つではなく、標的型メール、VPN脆弱性、水飲み場攻撃、正規アカウントの悪用など、複数の侵入経路や技術が組み合わされます。 企業が注意すべき点は、侵入を防ぐ対策だけでは不十分だということです。APT攻撃では、侵入後にどれだけ早く異常を検知できるか、横展開や情報窃取をどこで止められるかが被害の大きさを左右します。

    次の記事では、APT攻撃への対策として、侵入前の防御、侵入後の検知・監視、インシデント対応体制などを解説します。
    APT攻撃対策とは?検知・監視・初動対応の考え方

    【参考情報】

    なお、本記事で解説した初期侵入・権限昇格・横展開・情報窃取・長期潜伏といった各段階は、MITRE ATT&CKが提供する脅威フレームワークにおける戦術(Tactics)分類にも対応しています。より詳細な技術的分類を確認したい方は、MITRE ATT&CK,Enterprise Tactics(https://attack.mitre.org/tactics/enterprise/)をご参照ください。

    編集責任:木下


    APT攻撃への備えをご検討中の方へ

    APT攻撃は、侵入を完全に防ぐことが難しい高度なサイバー攻撃です。侵入経路の把握や脆弱性管理、監視体制の強化など、継続的な対策が求められます。弊社、ブロードバンドセキュリティ(BBSec)では、脆弱性診断、アタックサーフェス管理調査、セキュリティ運用サービス、コンサルティングサービスなど、企業のセキュリティ対策を支援するサービスを提供しています。


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

    最新情報はこちら


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

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