サイトを狙う有名な攻撃8つと防ぎ方｜5週間で257回届いた実際の攻撃の記録と、今日確かめることの判断表つき

想定読者

自社サイト（特にWordPress）の運用を任されているサイト担当者・総務担当者・経営者の方です。

有名な攻撃の名前は聞いたことがあるものの、どれが自社に関係し、今日何を確かめればよいかを整理できていない方に向けて書いています。

要点

• 当社が管理するWordPressサイト6つに、約5週間で257回（接続元51か所）のSQLインジェクション狙いの攻撃が届き、成功は0回でした。その記録を、止めた3段の防ぎとあわせて紹介します
• SQLインジェクション・XSS・総当たり・既知の弱点の探索・CSRF・フィッシング・ランサムウェア・DDoSの8つを「仕組み・起きること・防ぎ方」で整理し、判断表で自社が今日確かめることを選べます
• 攻撃は毎日来る前提で、防ぐ仕組みと、毎日の点検で気づく仕組みの両方が要ります。点検はAIに任せられますが、対処の判断は人が持ちます

約5週間で257回届いた攻撃と、すべて止まった結果｜当社サイトのアクセス記録から

「有名な攻撃」と聞くと、ニュースの中の出来事のように感じるかもしれません。

ところが、サイトを公開していれば、攻撃は特別な日ではなく普段から届きます。ここでは、当社が管理するWordPressサイトに実際に届いた攻撃の記録から始めます。

2026年10月8日〜11月14日、6サイトすべてに届いた攻撃の内訳

記録が残っている2026年10月8日〜11月14日の約5週間に、当社が管理するWordPressサイト6つへ届いたのは、次の弱点を組み合わせて狙う攻撃でした。

• CVE-2026-63030：REST API（外部のプログラムとやり取りする窓口）の一括処理（batch）で、入口を取り違える弱点
• CVE-2026-60137：SQLインジェクション（データベースへの命令を混ぜ込まれる弱点）

CVE番号とは、公表された弱点に付く識別番号のことです。この2つは2026年7月に公表されたもので、組み合わせるとログインなしでサーバーを乗っ取れるとされています。

届いた件数は257回、接続元は51か所でした。期間中ほぼ毎日届き、6サイトすべてが対象でした。

結果の内訳は次のとおりです。

WAF（ウェブアプリケーションファイアウォール）は、サイトの手前で怪しい通信を見張り、攻撃の形をしたものを止める仕組みです。

「認証なしとして拒否」は、WordPress本体が「ログインしていない人には許可しない」として断った分です。

合計はちょうど257回で、成功は0回でした。

当社のサイトは、この弱点の修正版より新しい版に更新済みだったため、そもそもこの弱点は効かない状態でした。

それでも、止めるための仕組みが何重にも働いていたことが記録から分かります。

名乗りにCVE番号をそのまま使う攻撃プログラムと、毎日のように届く遮断通知

記録を読むと、一部の攻撃プログラムは、自分の名乗り（User-Agent、通信の送り主を示す名札のようなもの）にCVE番号をそのまま使っていました。

人が狙いを定めて打ち込んでいるというより、公表された弱点の番号を掲げた自動プログラムが、世界中のサイトを順番に確かめて回っている様子がうかがえます。

当社ではWAFが遮断のたびにメールで知らせるため、毎日のように通知が届いていました。通知が届くことは「今日も攻撃が来て、止まった」という確認になります。

逆に言えば、攻撃が来ること自体は珍しいことではなく、大切なのは、止める仕組みと、来ていることに気づく仕組みの両方を持っておくことです。

SQLインジェクションと、実例で見る3段の防ぎ

最初の手口は、先ほどの実例そのものです。

SQLインジェクション

• 仕組み：入力欄やURLの値に、データベースへの命令の文（SQL）を混ぜ込み、サイト側にそのまま実行させます
• 起きること：本来は見られない情報の閲覧、データの書き換え、管理者権限の奪取などにつながります
• 防ぎ方：入力値をそのまま命令に使わない作りにすること、本体・プラグイン・テーマの更新、WAFでの遮断を重ねることです

当社の実例では、防ぎが次の3段になっていました。

1段目のWAFは、通信の形を見て、攻撃らしいものを入口で止めます。止め切れなかった分は、2段目のWordPressの認証が「ログインしていない人には出せません」と断ります。

さらに、仮に要求が奥まで届いても、3段目として、WordPressはIDの値をSQLに入れる前に整数へ変換します（wp_parse_id_list → absint）。

数字だけになった値には命令の文を混ぜられないため、SQLの文を書き換えることができません。

この3段の読みどころは、「1段だけに頼らない」ことです。WAFは新しい攻撃の形をすり抜けられることがありますし、認証にも抜け道が見つかることがあります。

それぞれ弱点が違う防ぎを重ねておくと、どれか1つが破られても、次の段が受け止めます。自社のサイトでも、「更新」「入口の遮断」「権限の絞り込み」のように、役割の違う防ぎを重ねる発想が役に立ちます。

ほかの手口7つ｜仕組み・起きること・防ぎ方

ここからは、サイトを狙う有名な手口のうち、残りの7つを同じ順番で整理します。ここでは一般的な仕組みと防ぎ方に絞って書きます。

入力・ログイン・既知の弱点を狙う手口

クロスサイトスクリプティング（XSS）

• 仕組み：コメント欄や検索窓などに、ほかの閲覧者のブラウザで動くプログラム（スクリプト）を紛れ込ませます
• 起きること：訪問者の画面に偽の表示が出たり、ログイン状態を示す情報が盗まれたりします。管理者が見てしまうと、管理者の権限を悪用される恐れもあります
• 防ぎ方：テーマとプラグインを更新すること、使っていない入力欄や機能を減らすこと、管理者権限を持つ人を必要最小限にすること、WAFで怪しい入力を止めることです

総当たり・パスワードリスト攻撃

• 仕組み：IDとパスワードを機械的に次々と試します。パスワードリスト攻撃は、ほかのサービスから漏れた組み合わせを使い回しの前提で試す手口です
• 起きること：当たると管理画面に入られ、改ざんや不正な書き込み、ほかの攻撃の踏み台にされることがあります
• 防ぎ方：パスワードを使い回さず長く設定すること、多要素認証（パスワードに加えてスマートフォンなどで確認する仕組み）を入れること、ログインの失敗回数を制限すること、「admin」のような推測されやすいIDを使わないことです。パスワードの考え方はパスワード管理の見直し方の記事で、WordPressの不正ログイン対策はWordPressの更新と不正ログインの記事で詳しく扱っています

既知の弱点を狙った自動の探索

• 仕組み：公表された弱点の番号を手がかりに、自動プログラムが世界中のサイトへ「この弱点は残っていないか」と順番に確かめて回ります。導入で紹介した実例が、まさにこれにあたります
• 起きること：更新していないサイトが見つかると、その弱点を使って乗っ取りや改ざんが行われます。狙われるのは企業の規模ではなく、古い状態で放置されたサイトです
• 防ぎ方：最大の防ぎは更新です。WordPress本体・テーマ・プラグインに加えて、サイトが動く土台のPHPも、最新の状態に保ちます。使っていないプラグインは削除します。更新が追いつかない間は、WAFのような入口の防ぎが時間を稼いでくれます。更新と不正ログインの基本は、WordPressの更新と不正ログインの記事にまとめています

CSRF（クロスサイトリクエストフォージェリ）

• 仕組み：ログインしたままの人に、攻撃者が用意したリンクやページを開かせ、本人の意図しない操作を、本人の権限で送らせます
• 起きること：管理者が開いてしまうと、設定の変更やユーザーの追加など、管理画面でできることを勝手に実行される恐れがあります
• 防ぎ方：WordPressは、操作ごとに確認用の合言葉（トークン）を使ってこれを防いでいるため、本体とプラグインを更新して、その仕組みが正しく働く状態を保つことが基本です。あわせて、管理作業のあとはログアウトすること、管理画面にログインしたまま見知らぬリンクを開かないこと、管理者の権限を持つ人を絞ることが有効です

人とサービスの止まりを狙う手口

フィッシング

• 仕組み：取引先や社内システムを装った偽のメールやログイン画面で、ID・パスワードを入力させてだまし取ります
• 起きること：サイトの管理画面やメールのアカウントを乗っ取られ、自社名義の迷惑メールの送信元（踏み台）にされることもあります
• 防ぎ方：送信元とリンク先をよく見る習慣をつけること、多要素認証を入れること、なりすましメールを見破りやすくする設定を整えることです。メールの乗っ取りと踏み台の仕組みはメールアカウントの乗っ取りと踏み台の記事で、なりすましメールへの備えはなりすましメール対策の記事で扱っています

ランサムウェア

• 仕組み：端末やサーバーのデータを暗号化し、元に戻すことと引き換えに金銭を要求する不正プログラムです
• 起きること：サイトや共有データが使えなくなり、業務が止まります。攻撃者は、つながっているバックアップまで壊そうとすることがあります
• 防ぎ方：入口になりやすい機器やリモート接続の更新と設定の見直し、別の場所に分けたバックアップ、そして実際に元へ戻せるかの確認です。さらに、感染が疑われたときの初動の手順を決めておくことも大切です。詳しくはランサムウェア対策とバックアップの記事にあり、実際に動けるかを試す方法は事故の机上訓練の記事で紹介しています

DDoS

• 仕組み：大量の通信を一度に送りつけ、サイトやサーバーが処理しきれない状態にします
• 起きること：サイトが表示されなくなり、問い合わせや予約などの窓口が止まります。ほかの手口と違い、サイトに侵入されるのではなく、使えなくされるのが特徴です
• 防ぎ方：通信を分散して受け止める仕組みや、短時間の大量アクセスを制限する機能を使うこと、利用しているサーバー会社のDDoS対策の内容を知っておくこと、止まったときの連絡先と手順を決めておくことです

8つの手口は、入口が違うだけで、「更新」「権限の絞り込み」「分けて持つ備え」「気づく仕組み」という共通の防ぎに行き着きます。

次の章では、そのうち「気づく仕組み」を、毎日続けるにはどうするかを見ます。

防ぎ方を続ける仕組み｜毎日の点検をAI社員「まもる」に任せている例

WAFや更新は「防ぐ仕組み」です。

一方で、防ぎを突破された兆しや、設定が知らないうちに変わっていることに気づくには、「気づく仕組み」が別に要ります。

この2つは役割が違うため、片方があればもう片方は要らない、という関係にはなりません。

当社では、社内のバーチャルオフィス「クリエイティブオフィス」で、Webサイトのセキュリティ担当のAI社員「まもる」が、当社が管理するサイトを毎日点検しています。

オフィスの全体像はクリエイティブオフィスのAI社員の記事で紹介しています。ここでは、点検の中身だけを取り上げます。

外からの1時間おきの点検と、サーバーの中の毎朝の点検・前日のアクセス記録の読み込み

点検は、外から見るものと、サーバーの中を見るものの2つに分かれています。

外からの点検は1時間おきです。利用者と同じようにサイトを見て、次の点を確かめます。

• サイトにつながるか
• 証明書（安全な通信を支える電子的な証明書）の残り日数
• 改ざんの兆し（見覚えのない外部のスクリプトや、スパムのリンク）
• 不審な転送
• DNS（サイトの住所を管理する設定）が勝手に変わっていないか

サーバーの中の点検は、毎朝6時台に1回です。次の点を見ています。

• WordPress本体とプラグインのファイルが書き換えられていないか（公式の配布物との照合）
• 更新が出ているプラグインとテーマ
• 管理者ユーザーの増減
• 不審な予約処理
• 前回から増えた、または変わったPHPファイル、画像置き場の中のPHP、.htaccessの変更
• 不正なプログラムの埋め込み（ファイル名ではなく、中身の特徴で探す）

さらに、毎朝、前日のアクセス記録も読んでいます。秘密のファイルを探る通信、見慣れない接続元から管理画面へのアクセス、ログインの試行の多さ、エラーの急増を見ています。

導入で紹介した「届いた攻撃」のような通信は、こうした記録の中に残ります。

点検は読むだけ・結果は3段階に振り分け・重大と注意のときだけ申請：AIが担う範囲と人が決める範囲

この点検の特徴は、AIが担う範囲をはっきり区切っていることです。

点検は読むだけで、サーバーは変えません。結果は「重大」「注意」「情報」に、決まった基準で振り分けます。

重大と注意のときだけ、何が起きたか・根拠・影響・対策案・元に戻す方法をまとめた「申請」を出します。

その申請を受けて、対処するかどうかはCEOが判断します。AIは点検と申請まで、判断は人、という分担です。

毎日の点検は、同じことを同じ基準で繰り返す作業なので、AIに任せやすい部分です。

一方で、「サイトを止めてでも直すか」「元に戻すか」といった対処の判断には、業務への影響や優先順位が絡むため、人が持つ必要があります。

自社で同じことをする場合も、まず「読んで気づくところまで」を仕組みにし、「変える」判断は人に残す、という切り分けから始めると安全です。

判断表：手口ごとに、自社で今日確かめること

ここまでの8つの手口を、「自社で今日、まず何を確かめるか」に置き換えた判断表です。すべてを一度にやる必要はありません。

自社で使っている機能に近い行から、1つずつ選んでください。

表の使い方を、迷いやすい点にしぼって補足します。

• 何から手をつけるか迷うときは、「既知の弱点の探索」の行から始めてください。実例のとおり、攻撃は更新していないサイトを探して届くため、更新が済んでいるかを確かめることが、最も多くの手口に効きます
• 「総当たり・リスト攻撃」と「フィッシング」は、どちらも最後はIDとパスワードの問題に行き着きます。多要素認証を入れておくと、2つの手口に同時に備えられます
• 「ランサムウェア」の行で確かめるのは、バックアップがあるかどうかではなく、実際に元へ戻せるかどうかです。取るだけで確認していないバックアップは、必要になったときに使えないことがあります
• 共用のレンタルサーバーを使っている場合、PHPやサーバー側の設定は、利用者ではなくサーバー会社の担当範囲のことがあります。その場合は、サーバー会社の告知を読み、対応が済んだか、利用者側でやることがあるかを確かめてください

毎日・毎週・毎月の点検チェックリスト

判断表で「今日確かめること」を選んだあとは、確かめることを習慣にします。次のチェックリストは、一般的な点検項目を、見る頻度ごとに分けたものです。

サイトの毎日・毎週・毎月の点検チェックリスト

毎日

• [ ] サイトが開けて、見覚えのない表示やリンクが混じっていないことを確認した。
• [ ] 防御や通知のメールに、いつもと違う増え方がないことを確認した。

毎週

• [ ] 本体・プラグイン・テーマに更新が出ていないことを確認した。
• [ ] 管理者ユーザーの一覧に、身に覚えのない人がいないことを確認した。
• [ ] ログインの失敗が急に増えていないことをアクセス記録で確認した。

毎月

• [ ] バックアップから実際に元へ戻せることを確認した。
• [ ] 証明書とドメインの期限を一覧にできる。
• [ ] 退職者や使っていない人のアカウントが残っていないことを確認した。

最初から全項目を完璧にこなそうとすると続きません。頻度が高い項目ほど軽くしておき、見る人が代わっても同じように確かめられる形にしておくと、続けやすくなります。

自社で人手が足りない部分は、読むだけで済む点検から、道具や外部のサービスに任せることも選択肢になります。

まとめ｜防ぐ仕組みと気づく仕組みの両方を持つ

当社が管理するWordPressサイト6つには、2026年10月8日〜11月14日の約5週間に、257回・51か所からSQLインジェクション狙いの攻撃が届きました。

成功は0回でした。止まった理由は、WAFが形で止め、WordPressの認証が断り、さらにIDの値が整数に変換されてSQLの文を書き換えられない、という3段が重なっていたからです。

ここから分かることは3つです。

• 攻撃は、サイトの規模に関係なく、毎日来る前提で備える必要があります
• 1段の防ぎに頼らず、役割の違う防ぎを重ねると、1つ破られても次で止まります
• 防ぐ仕組み（更新・WAF）と、気づく仕組み（毎日の点検）は役割が違うため、両方が要ります。点検はAIに任せられますが、対処するかどうかの判断は人が持ちます

まずは判断表から、自社で関係が深い手口を1つ選び、今日確かめることを1つだけ実行してみてください。

そこから、チェックリストの項目を1つずつ増やしていけば、無理なく「防ぎ続ける」状態に近づけます。