近年日本国内で発生しているサイバー攻撃について調査分析
攻撃の手口と被害の原因を調べて対策を考える
皆さんもニュースを見て実感していると思いますが、とにかく日本国内で毎日のように情報漏洩が発生しています。まるで「今までも漏洩して社内では知っていたのを、この混乱のさなかどさくさに紛れて企業が公表しているのではないか」と疑ってしまうくらいです。
【注意喚起】 相次ぐ情報漏えい、その原因の一つは「アプリ解析からのサーバ攻撃」 NICT（情報通信研究機構）が最近の国内のサイバー攻撃の手順を分析した結果、大きく分けて4つの攻撃パターンがあることが判明しました。
- VPN機器等の脆弱性
- 標的型メールやフィッシング
- 公開サーバ・APIの脆弱性
- MetabaseのSQLインジェクションの脆弱性（CVE-2026-72898）
1つ目と2つ目は恒例の攻撃ですが、3つ目は昨日発生したソースネクストの情報漏洩でも使われた手口です。
「セキュリティソフトも売ってるのに」ソースネクスト会員情報漏えい、パスワード含む最大2252万件 API不正利用される
そんなことだろうと思いましたよ>『パスワードについては暗号化して保管していたものの、不正アクセスがあった会員情報の管理システムの中にパスワードを元の状態に戻すのに必要な情報も入っていた』 / “ソースネクスト パスワード暗号化がない状態で流出 再設定 | NHK…” https://t.co/jzTI0rWDYw
— 徳丸 浩 (@ockeghem) October 16, 2026
4つ目は今年8月に発覚した脆弱性ですが、この脆弱性もAPIへの不正なリクエストを通じて悪用されるものになります。認証なしでリモートから管理者権限を奪取される恐れがあるためたいへんきけん、BIツールであるMetabaseは内部外部のデータソースを利用しているため、管理者権限を窃取されると、機密情報を含むデータベースが漏洩する可能性があります。
昨今の状況を踏まえ、私も会社では連日セキュリティ対策を進めています。社外からのセキュリティチェックシート、ヒアリング。社内では情報資産に対する現状と対策の検討などなど。セキュリティ担当が忙しいというのは、世の中が乱れていることを意味します。今はまさに乱世です。 このサイバー攻撃の大嵐を乗り切るには、敵を知ることが必要。日本国内で起きている私の所属するIT業界に対してのサイバー攻撃にはどのような脆弱性が突かれていて、自社はそれが対策できているのかを分析する必要があると考えました。 なお、本分析は私の所属するIT業界に絞って調査を行った結果であり、実際の件数や被害の割合は日本国内全体とは異なる可能性があります。
まず2026年（2025年12月も含みます）の日本国内のサイバー攻撃における公表数を調べました。
| 公表日・第一報の月 | 件数 |
|---|---|
| 2025年12月 | 2 |
| 2026年01月 | 2 |
| 2026年02月 | 1 |
| 2026年03月 | 0 |
| 2026年04月 | 5 |
| 2026年05月 | 5 |
| 2026年06月 | 5 |
| 2026年07月 | 4 |
| 2026年08月 | 5 |
| 2026年09月 | 5 |
| 2026年10月 | 24 |
今年の春から毎月5件前後で安定していましたが、今月はまだ半分なのに20件越えと、群を抜いています。この数字だけでも、日本国内組織は緊急的な対応が必要だということは明らかだと思います。
54件のサイバー攻撃被害のうち、ランサムウェアによるものは7件（12%）、業務停止が18件(33%)、実に3社に1社は業務停止が発生し、金銭的にも大きな損失を受けてしまいました。 余談ですが、この状況により、最近サイバー保険も費用が増加してしまっているとのことです。
次に、公表されたサイバー攻撃54件に対して、原因をカテゴリ別に分析した結果が以下になります。件数順に記載します。
| 順位 | 原因 | 件数 |
|---|---|---|
| 1 | 不明・未公表 | 20 |
| 2 | Webアプリ・APIの脆弱性 認証認可の不備 | 16 |
| 3 | 認証情報の管理不備による窃取 | 13 |
| 4 | 第三者製品・N/W機器の脆弱性 | 9 |
| 5 | サプライチェーン攻撃 SaaSや委託先、共有先システム経由での侵害 | 6 |
| 6 | 自社開発基盤のセキュリティ不備 | 6 |
| 7 | VPN 保守用アカウントを経由した不正侵入 | 4 |
| 8 | 外部非公開を想定していたツール・管理画面の外部公開 | 3 |
※「件数」は主原因と副次的な原因の合計になります。そのためサイバー攻撃の合計件数よりも大きな数字となっています。
最も多かったのは認証認可の問題。認証（Authorization）と認可（Authentication）は異なる概念です。認証の実装不備によりほかの人のデータを閲覧できてしまったり、認可の不備により読み取り専用のはずのデータに書き込み出来てしまったりします。 単独の原因が理由でサイバー攻撃を受けることはまれで、多くは複数の原因の組み合わせです。最初紹介したソースネクストは、(2)認可の原因によりデータが漏洩し、(3)認証が原因により暗号化されたデータが復号化されてしまったようです。
次に、原因が多かったサイバー攻撃の実例を参考に、原因と自社での対策を検討します。多くの会社の報告書を読みました。報告書は書きたくない内容も多いと思います、また対策についても「ぼんやりした内容だな」と思うこともあります（我が身になった時にちゃんと書けるか、と言われると、ですが・・）その中で報告書をしっかり書いてくださっている企業には頭が下がる思いです。
Webアプリ・APIの脆弱性(認証認可の不備)
Eストアー「ショップサーブ」
リモートで任意のプログラムを実行できる脆弱性はたびたびアナウンスされており、その被害にあったことが想像できます。 Eストアーさんはきちんとログを取得していたこと不幸中の幸いだったと思います。いつからいつまで、どのアカウントのデータが漏洩したのかが調べられなければ、調査はより長期化していたでしょう。
Gyazo
「Gyazo」への不正アクセスによる情報漏えいに関するお知らせとお詫び
こちらも画像ファイルをアップロードできる機能を持つサーバへの脆弱性とのことです。 Gyazoは無料で簡単に画像共有ができる一方、アクセス制限のような機能がないので個人情報や機密情報のやり取りに利用するのは危険です。 Gyazoの画像URLはランダムな文字列（画像ID）で構成されており、URLを知らなければアクセスできない「推測困難性」によって非公開状態を保つ仕組みですが、今回、この「画像URLを構成する画像ID」が流出しました。あとはAIに「この画像IDとURLを組み合わせて手に入れた画像をダウンロードして」と言えば簡単ですよね。
スマレジ
スマレジはWordPressをベースとしたECサイトを構築していたことが推測されます。WordPressを使う＝危険、ではないのですが、どうしても古いソフトウェアであるが故、セキュリティ部分には穴が多いです。便利なソフトウェアなのですが脆弱性が多数出ること、無料のテーマなどはメンテがおろそかになっていることから、使うことにリスクがある印象です。
楽天
発生したばかりのためまだ調査中と思われますが、管理用アカウントの認証情報を不正に取得し、個人情報が盗み見られたとのことです。多要素認証のうちメール認証やワンタイムパスワード（6桁の数字）は比較的容易に実装できる一方、メールアカウントに不正ログインされたり、パスワードを盗聴されたり、適当な6桁の数字を高速で入力することで突破するなどのスキがあります。本当に大事なアカウントは物理的なYubikeyなどで保護したいですよね。
これら他社の事例から、自分たちができることは以下が考えられます。
- 利用しているサーバソフトウェアが脆弱性に対応しているかを確認。セキュリティに対して弱いソフトウェアの利用は代替を検討する。
- 自社が利用しているサービス・システムがログを取得できるようにする。
- ログを確認する定常作業をおこなう。
- 不審なログを検知する振る舞い検知のソリューションを導入する。
- 検証環境での脆弱性がないことを確認するペネトレーションテストの実施。今ならAIの力も借りることで敷居が下がっているかも。
認証情報の管理不備による窃取
脆弱性とは異なり、認証の設定ミスなどが起因した不正ログインによる情報漏洩、業務停止です。
いえらぶ
【第二報】当社のクラウドサービスへの不正アクセスに関する調査状況および今後の対応について
いえらぶさんのサービスは複数の不動産会社が利用しているため、多くの企業に影響が出てしまったようです。
ジーニー
ジーニーさんは不幸中の幸いで、不正アクセスされたサービス内に個人情報および機密情報は含まれていなかったものの、報告書を読む限り、AWS内に勝手にサーバが建てられてマイニングなどに使われてしまった印象を受けます。不正アクセス関連損失として 1 億 8,100 万円を「その他の費用」に計上
エン
こちらはサービス提供側の不備ではなく、リスト型攻撃（攻撃者が大量のIDおよびパスワードを入手して、ターゲットのサイトにログインを試みる攻撃）の被害にあったとのことです。漏洩した大量のログインID・パスワードはダークウェブで二束三文で売られています。
Have I Been Pwnedを使うと、自分のメアドやパスワードが漏洩しているかをチェックできます。最近はGoogle Chromeでも「そのパスワードは漏洩を確認しました」という通知が来ますよね。
よくセキュリティ担当が「パスワードを使いまわししていた場合、一か所からパスワードが漏洩するとほかのサイトでも不正ログインされてしまうので使いまわししないこと」とアナウンスしています。しかしユーザからすれば、「パスワード管理ソフト使っているのにコピペや自動入力許可しないなら覚えやすいパスワードを入れるに決まっているだろうが」となりますよね。作り手側で対応できることはあります。チェックリストで提案します。
さくらインターネット
さくらのレンタルサーバの「さくら用メンテナンス用サーバー」に対する不正アクセスから、一部ユーザーのレンタルサーバー環境へ不正アクセスし、マルウェアを設置したようです。メンテナンスサーバの詳細は分かりませんが、メンテ機能ということから、特権ユーザのようなものを利用してレンタルサーバ環境にパスワードなしにログインできたのかもしれません。、同じく管理環境を経由して「販売管理システム（契約情報等を管理するシステム）」にも不正ログインして情報漏洩が起きたようです。
これらを参考に、対策を検討しました。 一般ユーザに向けて提供しているサービスの対策アカウント向けと、会社側（管理者アカウント）向けに異なる対策が考えられると思います。
- 自社が提供するサービスに多要素認証を実装する
- 自社が提供するサービスにアカウントロック（連続してログインに失敗した場合、そのアカウントへのログインを一時的に無効化する）を実装する
- 同一IPアドレスから連続してログイン試行があった場合そのIPアドレスからのアクセスをブロック。ただし最近はIPアドレスを変更して連続ログインしてくるため、効果は限定的
- パスワードテキストボックスはコピペを可とする。”パスワードを表示する（目のアイコン）”トグルボタンを設置し、ユーザー自身が目視確認できるようにする
- ユーザの権限は必要最小限に
- 管理者アカウントは特に厳重に守る（物理的YubiKeyなど）
- 少しでも被害を防ぐために、振る舞い検知機能を導入
また、自分の会社で利用しているクラウドサービスに多要素認証が設定できる場合、設定するのも大切ですね。会社で従業員の認証基盤を持っていたら、そちらに多要素認証を設定して、各サービスにSSOでログインできるようにしたいと思いました。
第三者製品・N/W機器の脆弱性
これについては大手クラウドサービスベンダーの話なので、自社へのフィードバックは薄めですが、報告書を確認しました。
ブロードバンドタワー
当社へのサイバー攻撃に関する調査結果と今後の対応について（最終報）
脆弱性が存在した「c9 Flex（シーナイン フレックス）」サービスは、Amazon EC2のような仮想サーバーサービスです。VMwareやF5などいくつかのベンダーの製品の集合で作られたサービスで、今回それらに脆弱性があり、それを突かれたとのことです。
TOKAIコミュニケーションズ
OneOffice メールソリューションにおける不正アクセスによる個人情報漏洩についてのお知らせとお詫び（第三報）
こちらもメールサービスを構成するCisco製機器の脆弱性を悪用されたことによるものでした。この脆弱性は不正アクセス発生時点では未発見の、ゼロデイ攻撃をうけたものです。
アイコムソフト
【重要なお知らせ】弊社サーバーへの不正アクセスに関するお知らせ(最終報)
こちらも自社のサーバーインフラの中に組み込んで使っていた、他社製ソフトウェアの弱点を突かれたサプライチェーン攻撃でした。
KDDI
ISP 事業者向けメールシステムに対する不正アクセスについてのお詫びとご報告
こちらも第三者のソフトウェアによるゼロデイ攻撃とのことです。
サプライチェーン攻撃対策としてはSBOMが挙げられますが、クラウドサービス提供者が利用している第三者製品は膨大ですし、サービス基盤の根幹にもかかわるうえ無停止が求められれば即座に最新アップデート、という選択肢は不可能です。かつてそのような基盤を提供する会社で働いていたこともあり、心中察するものがあります。
サプライチェーン攻撃(SaaSや委託先、共有先システム経由での侵害)
上記に似ていますが、私たち側でも比較的対策ができる分野のサイバー攻撃です。
スマレジ
「外部アプリ」と強調されているように、スマレジ自体からはデータが漏洩しておらず、APIを通じてデータを連携していた外部の提携先アプリからデータが漏れたとのことです。
マイナビ転職
当社が利用するクラウドサービスに対する不正アクセスの発生および個人情報流出の可能性について
本件は当社が提供する各サービスサイト、およびそのデータベースに対する不正アクセスによるものではありませんので、サービスのご利用に影響はございません。 本件は、当社が利用するクラウドサービスに対し、通常のセキュリティ対策を回避する不正アクセスが行われたことに起因するもの
自分なりに解釈しましたが、こちらもマイナビの基幹システムが直接破られたわけではないものの、従業員が業務で使っていた「外部のクラウドサービス」にマイナビ転職のデータを利用していてその脆弱性から個人情報が漏れた事案のように読めます。これもサプライチェーン攻撃と言えるでしょう。
Sansan
オンラインコミュニティー「Sansan User Forum」における会員情報漏えいに関するお詫びとお知らせ
Sansanがユーザーコミュニティを運営するために利用していた外部SaaS「Commune」に脆弱性があり、本来参加が許されないコミュニティに攻撃者が参加、そこから管理者権限を得て不正アクセスを行ったとのことです。SanSanのデータベース自体に不正アクセスはなかったものの、Communeの会員情報にはSanSanのデータから引っ張ってきたデータもあることから、SanSan側の情報漏洩という形でアナウンスを行ったようです。
他にも、マウスコンピュータ（メール基盤のIDCFクラウドへのサイバー攻撃による情報漏洩）など、外部SaaSを起因としたサプライチェーン攻撃が多発しています。 しかし自前で同機能を実装するより、SaaSを利用するほうが、コストもセキュリティも優れているのが実情。利用する側としての対策は
- SaaSに同期・提供しているデータは最小限として使わない機密情報を渡さない
- 保持期限を決め、不要になったデータはSaaSから削除
- APIキーで外部連携しているのであれば、スコープは最小に。
- 利用するSaaSのセキュリティがしっかりしているか調査（ISMSやPマークを取得しているか、など）を導入時に行い、また定期的に実施する
直接関係ありませんが
- CASB（Cloud Access Security Broker）などを利用してシャドーITを検知する もやっておきたいですね。
自社開発基盤のセキュリティ不備
イノベーション
GitHubへの不正アクセスに関する詳細調査の完了および セキュリティ対策強化のお知らせ（確定報）
現場の開発者が気を付けるよう口酸っぱくして言われている
- 認証情報をGitHubリポジトリに直書きしてしまった
- 個人情報が書かれた設定ファイルをGitHubリポジトリにアップロードしてしまった
ただ、分かっていても人間はミスをするものです。再発防止策にあるように
- 認証情報はSecretsに格納してコードに直書きしない。
- コードのレビューをきちんとする（「きちんと」した結果がこれ、というのも分かるのですが、それしか言えない…）
- GitHub Organization設定で従来の「Classic PAT」を禁止し、「Fine-grained personal access tokensのみを許可する
- Secret Scanning Push Protectionを導入する。ただし1人あたり月額約3,000円の費用はなかなか
- なので、Gitleaks × pre-commitでシークレット混入を防ぐのが良いと思う
- AIによるコードレビューを行う
報告書にあるような「GitHubリポジトリへのアクセス状況の監視を強化し、不審なアクセスを早期に検知できる」はGitHubの標準プランではありません。高価な上位プランだとあるようですが。 Audit LogをAWSのCloudWatch Logsに送れば実現できるかもですが、結構作りこみが必要そうです。コスパを考えると、まずは上記のようなチェック項目を行うのがコスパ良いのではないでしょうか。今流行りのAIによるコードレビューを導入すると、人間では気が付かない場所も気づいてくれてよいと思います。
まとめ
サイバー攻撃があまりに連日のように起きており、感覚がマヒしてしまってます。
【重要】不正アクセスによる情報流出に関するお詫びとお願い（第一報）
StudioおよびStudioを利用しているユーザ企業からのサプライチェーン被害が発生しています。 「どうせみんな漏洩する」と諦めの気持ちに加え「どうせ攻撃者のほうが圧倒的に有利なんだし、もう頑張らなくてもいいよね」と闇堕ちしそうな気持ちになります。が、今日リストアップしたセキュリティ対策を自組織の情報資産に少しずつ取り入れていくことがセキュリティ担当としてのミッションになります。
また、今回の事例を読み解く中で、原因ではないものの被害の拡大につながった重要な要素があります。それが「検知の遅れ」です。攻撃を受けてからさくらインターネットは3年間、楽天ドライブは8か月、KDDIは1か月経過していました。ログを取得することは当然のこと、ログを定期的に監査したり、動的に異常を検知したりする機構を取り入れるべきと痛感しました。マンパワーだと真っ白に燃え尽きるので、これもAIの力を借りないとですね。