IP遮断が効かない攻撃｜40分で326IPを使い分ける手口と対策

「怪しいIPアドレスをブロックしておけば、攻撃は防げるはず」。そう考えていませんか。監視画面でアクセス数の多いIPだけを見て、安心していないでしょうか。

この記事では、国内で観測された「たくさんのIPを使い分ける攻撃」の手口と、運用の現場でどこを見れば気づけるのかがわかります。結論から言うと、IPごとの件数だけでなく、レスポンスの偏りとAPI・アカウントの動きを見ることが大切です。

326のIPを使い分ける攻撃とは?観測された手口

同じ攻撃者とみられる相手が、約40分のあいだに326のIPアドレスを入れ替えながらアクセスしていました。

これはサイバーセキュリティクラウド社が2026年10月9日に公開したレポートの内容です。マクニカが「重点的に確認するIPアドレス」として公開した2件を起点に、9月18日から10月8日までの自社の観測データを調べたところ(期間中のログがすべてそろっているわけではないと注記されています)、約40分で1,200件を超えるアクセスが複数回見つかりました。リクエストの中で同じ識別子が使い回されていたため、同じ相手だと判断したそうです。

レポートによると、攻撃は次のような流れで進んだ例がありました。

• まずSQLインジェクション(入力欄に命令文を混ぜてデータベースを操る攻撃)で、ログインを回避したり情報を抜き出したりできないか試す
• 回避できないと、事前に用意したとみられるアカウントでログインする
• ログイン後の画面や機能で、ふたたびSQLインジェクションができないか探す
• ポイント制度があれば、ほかの利用者のポイントを奪えないか試す

一通り試すと深追いせずに引き上げ、同じサイトに日を改めて来た様子はなかったといいます。

つまり、ひとつの相手が大量のIPを使い、短時間で「試して、だめなら次」を繰り返す攻撃が実際に起きています。

IP遮断が効かない理由は「1つのIPから見ると少ない」こと

この手口がやっかいなのは、IPアドレスごとに数えると、アクセスがとても少なく見える点です。

筆者の単純な計算ですが、1,200件を326のIPで割ると、1つあたり平均で4件ほどです。「同じIPから1分に100回来たら止める」といったしきい値には、まず引っかかりません。レポートも、IP単位の件数監視や、ツール特有のパターン検知では見逃すおそれがあると指摘しています。

たとえるなら、同じ人が326回、服装を変えてお店に来るようなものです。店員が「同じ顔の客が何度も来たら注意」とだけ覚えていると、気づけません。見るべきは顔ではなく、「レジでおかしな注文が続いている」といった行動のほうです。

なお、レポートはこの攻撃を「AIエージェントまたはそれに近い仕組み」による可能性があるとしています。人の手では難しい量なのに、ツールのような決まった規則性がなく、応答を1つずつ見て次の手を選んでいるような動きだからです。ただし、AIを使った直接の痕跡は確認されておらず、あくまで振る舞いからの推測だと書かれています。

IPのブロックリストは今も役に立ちますが、それだけに頼ると、この種の攻撃は素通りしてしまいます。

IPを使い分ける攻撃に気づくためにログで見る3つの点

IPの代わりに見るべきなのは、「サーバーがどう答えたか」と「どのアカウントが何をしたか」です。

レポートが挙げる対策のうち、運用・監視の担当がログで確かめやすいものを3つにしぼりました。

1. ステータスコードの偏り

4xxや5xx(エラーを表す応答の番号)が、ふだんより多い時間帯を探します。攻撃は失敗を重ねながら進むので、エラーの山として表れやすいからです。429(リクエストが多すぎるときの応答)を返した記録も、調べる手がかりになります。

2. レスポンスサイズの違い

ログイン用のAPIなどでは、成功と失敗で返すデータの大きさが決まっていることがあります。そのどちらとも違うサイズや、ふだんありえない大きさの応答は、攻撃の影響を受けたり情報を引き出されたりしたサインかもしれません。APIは、プログラム同士がデータをやり取りする窓口です。

3. APIの権限確認と回数制限

レポートは、ログイン後の機能も含めてすべてのAPIでサーバー側の権限確認がされているか、ポイントのような価値のある機能でほかの人のデータを操作できないかを点検するよう勧めています。あわせて、単位時間あたりのリクエスト数に上限を設けることも有効だとしています。

JPCERT/CCの注意喚起でも、ログインやパスワードリセットなど悪用されやすい機能には、個別に回数制限を設けるよう挙げられています。IPを変えられてもログインに使うアカウントは同じなので、制限をIPだけでなくアカウント単位でも考えておくと、こうした攻撃に強くなると筆者は考えます。

どれも「誰が来たか」より「何が起きたか」を見る、という考え方でそろっています。なお、レポートやJPCERT/CCが公開しているIPアドレスなどの指標も、自分のログと照らし合わせる手がかりになります。ただし正規の利用者と重なることもあるため、該当があっただけで被害と決めつけず、前後の通信とあわせて確かめるよう注意されています。

IPAの注意喚起が求める点検と、IPを使い分ける攻撃の関係

同じ10月9日、IPAも相次ぐ不正アクセスを受けて、速やかに行うべき点検をまとめました。

IPAは、現段階では特定の製品やサービスの脆弱性を狙った攻撃とは断定されていないとしています。そのうえで公表事例の傾向から、外部に公開しているアプリやサービス、アカウントの侵害が起点になっているとみています。点検の項目には、次のようなものがあります。

• 公開しているアプリのログに異常がないか、エラーの量や平時との差を見る。まず直近1か月、その後3か月へ広げる
• 使っているクラウドやVPNなどの外部サービスを洗い出し、ログイン失敗の量や、ログイン元のIP・時間帯を平時とくらべる
• 作った覚えのないアカウントや、無効のはずのアカウントが有効になっていないか確かめる

1つ目の「エラーの量」は、先ほどのステータスコードの偏りと同じ発想です。3つ目のアカウント確認は、自分の組織が使うクラウドやVPNのアカウントが対象で、レポートにある「攻撃者が事前に作ったとみられる利用者アカウント」とは別の話です。それでも、IPではなくアカウントの側から異常を探すという点では同じ考え方です。

JPCERT/CCの注意喚起(2026年10月8日公開・9日追記)でも、公開しているスマホアプリを解析してAPIの入口やキーを特定し、不正なリクエストを送る手口が報告されています。IPを変えても変わらない「アカウント」と「API」が、守りの軸になるということです。

筆者の考察:IP遮断に頼る監視を見直す順番

1〜3年目の運用担当なら、まず「自分の監視がIPの件数しか見ていないか」を確かめるところから始めるのがよいと考えます。

新しい製品を入れなくても、すでにあるログで調べられることは多いからです。筆者の見立てで、手をつける順番を表にしました。公式の手順ではないので、目安として使ってください。

順番	確かめること	わかること
1	監視のアラート条件が、IPごとの件数だけになっていないか	分散した攻撃を見逃す作りかどうか
2	アクセスログに、ステータスコードとレスポンスサイズが残っているか	あとから偏りを調べられるかどうか
3	ログの保存期間が、IPAが例に挙げる「直近1か月、その後3か月」の確認に足りる長さか	過去の侵入を確かめられるかどうか
4	回数制限が、アカウント単位でもかかっているか	IPを変えられても止められるかどうか

とくに3つ目は、いざ調べようとしたときに「ログが1週間分しかない」と気づく場面が多いところです。ログの設定は、平時にしか変えられません。答えがわからない項目は、それ自体が先輩に聞くきっかけになります。

アクセスログで侵害の兆しを探す集計のしかたは、アクセスログの404より怖い200で詳しくまとめています。気づいたあとの動き方は、インシデント初動で新人がやる5つのこともあわせて読んでみてください。

まとめ:IP遮断が効かない攻撃は「応答」と「アカウント」で見つける

• 約40分で326のIPを使い分け、1つのIPあたりは数件しか来ない攻撃が観測されている
• IPごとの件数だけに頼らず、ステータスコードとレスポンスサイズの偏りを見る
• APIの権限確認・回数制限と、覚えのないアカウントの点検を進める

まずは担当システムの監視アラートが、何を条件に鳴る設定なのかを確かめてみましょう。

参考リンク

• 国内で相次ぐ不正アクセス、AIエージェントによる攻撃の可能性(サイバーセキュリティクラウド) ― 2026年10月9日
• 不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について(IPA) ― 2026年10月9日
• 直近で相次いでいる国内組織における不正アクセスに関する注意喚起(JPCERT/CC) ― 2026年10月8日(9日追記)