AI攻撃Bot対策 ― 高度なBotの特徴と検知の仕組み

AIを利用する攻撃では、応答を解釈しながら探索先や入力を変える自動化が問題になります。これに、IPの分散、ブラウザの模倣、低頻度での継続といった回避手法が組み合わさると、送信元や一件のリクエストだけを見る防御では、一連の攻撃を捉えにくくなります。

本稿では、まず攻撃の特徴と既存防御で捉えにくい点を整理し、その不足を補う高度なBot対策の仕組みを説明します。行動分析、ブラウザ検証、セッションの追跡、フィンガープリントの役割を示したうえで、AWS WAF Bot Control Targetedを具体例として扱います。対象読者はWebサイト・APIの設計・運用担当者です。

製品仕様の参照日は2026年11月13日です。

本稿の「AI攻撃Bot」は、AIを用いてページや応答を解釈し、次のアクセス先、入力内容、操作順序を選ぶ悪意ある自動化を指します。Fangらの実験では、LLMエージェントがWebサイトに対して、複数段階の操作を必要とする攻撃を人の逐次的な指示なしに実行したと報告されています。[13]

防御上の論点は、あらかじめ固定した要求を反復するだけでなく、結果に応じて試行を変えられることです。例えば、応答に合わせて別の入力や経路を試す場合、一つの文字列や操作順の一致だけでは、活動全体の判定に必要な情報が不足します。

高度なBotでは、住宅プロキシの利用やブラウザの模倣など、通常の利用者に通信を近づける回避手法も問題になります。AWSは住宅プロキシを利用する回避型Botや、複数IPに分散する低強度・長時間の活動を説明しています。[1][2] これらはAIだけに固有の手法ではなく、AIによる判断・操作の自動化と組み合わせて考えるべき特徴です。

AIを使うクローラや代理操作には許可できる用途もあるため、自動化の有無と、その操作を許可するかは分けて判断します。

IP制限、レート制限、攻撃パターン検査は、それぞれに合う攻撃を防ぐために引き続き必要です。ただし、前章の特徴を持つ活動に対しては、何を単位として判定しているかによって見えない部分が残ります。次の表に、判定方法ごとの対象と限界を整理します。

住宅プロキシの通信をIPだけで正常利用者から分離しにくいことは、AWSも説明しています。[2] また、OWASPは、購入や予約などの正規の業務フローを過剰に自動利用すること自体が被害を生む問題を挙げています。[3] 正規形式の通信が続く場合には、一件ずつの内容検査に加え、誰がどのように利用しているかを評価する必要があります。

不足を補うには、観測対象を単一のIPや要求から、クライアントの特性、セッション内の行動、複数クライアントの活動へ広げます。IPが変わっても共通する特性がないか、ブラウザの申告と実態が整合するか、複数の送信元が同じ対象へ協調してアクセスしていないかを組み合わせて評価します。

このように複数の情報から回避型の自動化を判定する機能を、本稿では「高度なBot対策」として扱います。必要性が生じるのは、攻撃にAIという名称が付くからではなく、既存の判定単位では活動の関連性や自動化の兆候を十分に捉えられないためです。次章では、その判断材料を構成する要素を整理します。

行動分析では、アクセスの時刻、ページ遷移、頻度などを継続して評価します。さらに複数クライアントを合わせて見ることで、個別のIPでは小さなアクセスでも、集団として共通する活動を検討できます。AWSのTargetedは、ブラウザ特性や行動の分析に加え、サイトのトラフィックを用いたMLで協調活動を検知します。[1][2]

例えば、複数IPが同じ対象を似た順序・時刻で取得するケースでは、IPごとの要求数以外にも調査の手掛かりが生じます。一方、正規のイベントでも似たアクセスが集中し得るため、類似性だけで悪性と断定せず、正常時の挙動や他の検知要素と照合する設計が必要です。

ブラウザ検証は、User-Agentの文字列だけでなく、クライアントから得られる環境情報や自動化の兆候を判定に使います。セッションの情報は、一回の要求では見えない継続的な操作や、同じトークンが異なる送信元で使われる状況を把握する手掛かりになります。AWSは、これらの情報を得るためにTargetedとクライアントSDKの併用を推奨しています。[2]

トークンは、取得時の環境と、その後の利用状況を分けて観測します。取得元と利用元のネットワーク種別の比較は、後述するToken Provenanceの例で説明します。

IPやUser-Agentだけでは通信元を比較しにくい場合、TLSなどの通信特性を一定の形式へ整理したフィンガープリントを補助情報に使います。送信元の表面的な情報が変わっても、同じ通信実装に由来する特徴が残る可能性があるためです。ここではTLSフィンガープリントの一例としてJA4を取り上げます。

JA4はTLSのClientHelloなどに現れる通信特性を整理したフィンガープリントです。TLSバージョン、暗号スイート、拡張などを使い、並び順の正規化やGREASE値の除外を行います。送信元IPはJA4の算出要素ではないため、TLS実装・設定が同じなら、IP変更後も一致し得ます。[6]

ここから導けるのは「通信特性が共通する」という相関です。同じブラウザやライブラリを使う別の利用者にも共通値が生じるため、JA4一致だけでは個人や攻撃者を識別できません。また、ClientHelloを模倣する実装も公開されています。[7] 本稿では、JA4をURI、時刻、操作結果と組み合わせ、調査対象を絞る補助情報として使います。

フィンガープリントが変われば行動やセッションを、セッションが変われば集団としての関連性を検討します。

高度なBot対策は、自動化や異常の兆候を捉える層です。入力検証や対象データへの認可は引き続きアプリケーション側で行います。OWASPのREST Security Cheat Sheetも、APIのアクセス制御、入力検証、処理順の検証を扱っています。[4] これらを前提とし、本稿では回避型Botの検知と、その有効性の確認に焦点を当てます。

Bot ControlのCommonは、既知または自己識別するBotの分類・管理に使います。TargetedはCommonを含み、ブラウザ検証、TLSフィンガープリント、行動分析などを加えて、身元を隠すBotを検出します。AWSはTargetedとクライアントSDKの併用を推奨しています。[2]

前章の検知要素をAWSで具体化する例として、以下ではTargetedを扱います。TLSフィンガープリントの利用は公開されていますが、個別ルールがJA4を直接条件に使うか、各情報をどの重みで評価するかは参照資料から確認できません。JA4を使うカスタムルールと、Targeted内部の判定は区別します。

主要ルールの標準アクションは次のとおりです。表のスラッシュは複数ルールの省略表記です。[1]

協調活動MLは、多数のIPへ分散する低強度・長時間のBotを検出対象に含みます。ベースラインの形成に最大24時間かかる場合があり、導入直後の短い試験だけでは評価できません。MLの確信度と、トークン再利用系列のしきい値は異なる意味を持ちます。[1]

設計上は、IPが変わっても共通する行動が残るケースと、トークンまで変更して継続性が失われるケースを分けて検証します。MLのHighも標準はCAPTCHAであることから、全ルールを一律にBlockへ変える方針は採用せず、標準動作を評価の起点とします。

Token Provenanceは、トークンを取得したときと提示したときのIPカテゴリを比較します。AWSは、データセンター等で取得したトークンを住宅回線等から提示する例を示しています。ラベルだけで強制処理は行われず、後続のカスタムルールで処理を定義します。公式例にはHighにCAPTCHAを要求する構成と、自動化ブラウザのラベルとのAND条件でBlockする構成があります。[9]

本稿では、複合条件を追加遮断の精度を評価するために用います。すべての検知にAND条件を課すと、片方の兆候しか出ない攻撃を取りこぼすためです。ラベルを参照するルールの順序と、先行ルールの終端アクションによって後続まで届くかを確認します。Countへ変更する範囲には責任者を置き、意図せず検証や遮断を失わないようにします。

AWS WAFでは、レートベースルールの集約キーにJA4、URI、HTTPメソッドなどを指定できます。複数のキーを選んだ場合は、その組合せごとに集計されます。必要なリクエスト要素がない場合の扱いにも注意が必要です。[8] JA4の対応リソースはCloudFrontとApplication Load Balancerで、算出に十分なTLS情報がある要求に値が記録されます。[12]

JA4とIPを組み合わせたキーは、IPごとに集計が分かれます。IPをまたいだ合計を見たい設計では、この違いを試験で確認します。JA4による集計はまず観測に使い、対象URI、正常ピーク、欠落時の挙動を確認してから制限へ進む方針とします。

一般利用者のブラウザ、モバイルアプリ、外部連携API、監視Botを分類し、それぞれが実行できる検証方式を決めます。ブラウザの操作確認を、すべてのAPI呼出しへ一律に要求する構成は適合性の問題を生みます。

AWS WAFのChallengeとCAPTCHAは、トークンの状態によって後続評価を継続するか、リクエストを止めて検証応答を返すかが変わります。検証用のHTMLやスクリプトを処理できるクライアントが前提となるため、JSONを期待する呼出しではSDK統合や応答処理も含めた確認が必要です。[5]

本稿の構成例では、機械間APIは資格情報・署名などによる呼出し元の検証と、サーバー側で確定した利用主体ごとの上限を中心に保護します。ブラウザ向けの検査から外す場合も、入力検査、認可、利用量制限は残します。送信者が自由に設定できるUser-Agentやヘッダーだけを、重要操作の許可条件にしない設計とします。

AWSは、モバイルアプリの非ブラウザUser-Agent、監視・自動テスト、プロキシを通る検証済みBotなどを、調整が必要となる例として挙げています。[10] これらに加え、本稿では以下の正常シナリオを試験対象とします。

例外には対象、理由、所有者、見直し期限を設けます。例外をBot検査に限定するのか、他の検査まで通過させるのかを明確にし、経路全体を安易に許可する設定を避けます。

AWSはテスト環境での調整後、本番通信でもCountで評価してから有効化する手順を示しています。[11] 本稿では、既存の保護を維持したまま、新しく導入するBot Controlルールを観測対象にする運用を提案します。

切替前に、問題が出たルールをCountへ戻す条件、変更担当者、連絡経路を決めます。費用は検査量や追加検証の利用量を含めて比較し、保護対象を削る際は、情報取得や業務操作の見逃しも合わせて評価します。

以下の試験では、固定条件と変更条件を分け、同一の業務目的に対して、防御構成の有無・違いを比較します。

AIを用いた試験を行う場合は、モデル・版、与えた目的、利用できるツール、試行予算、人の介入を記録します。同じシナリオの固定スクリプトとも比較し、AIの有無とIP・頻度・入力の違いを混同しないようにします。AIの成功例だけでなく、失敗・中断した試行も母数へ含めます。

検証ログには、取得できる範囲のWAFルール・ラベル・アクション、JA4、IP、URI、時刻と、アプリ側の操作結果を残します。相関には信頼できるリクエスト識別子などを使い、機密情報や認証情報そのものの保存は避ける設計とします。

MLの評価では、Web ACL設定、ルールグループの版、SDKの有無、観測期間、正常ピーク、試験順序を記録します。しきい値は業務の許容損失と利用者への影響から事前に定め、満たせなかった条件も導入判断へ含めます。

本文中の番号に対応する公開一次資料です。製品仕様は適用するルールグループ・SDKの版でも確認してください。

1. AWS WAF Bot Control rule group — ルールと標準アクション、協調活動ML。https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-bot.html
2. Choosing and configuring Bot Control for your use case — 保護レベル、SDK、AI Botを含む用途。https://docs.aws.amazon.com/waf/latest/developerguide/waf-bot-control-use-cases.html
3. OWASP API6:2023 Unrestricted Access to Sensitive Business Flows — 業務フローの自動化による悪用。https://owasp.org/API-Security/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows/
4. OWASP REST Security Cheat Sheet — APIのアクセス制御、入力検証、処理順の検証。https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html
5. CAPTCHA and Challenge action behavior — 検証トークンと応答の扱い。https://docs.aws.amazon.com/waf/latest/developerguide/waf-captcha-and-challenge-actions.html
6. FoxIO JA4 — フィンガープリントの仕様。https://github.com/FoxIO-LLC/ja4
7. uTLS — ClientHelloの模倣を扱う実装。https://github.com/refraction-networking/utls
8. Aggregating rate-based rules in AWS WAF — JA4などの集約キー。https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based-aggregation-options.html
9. Challenging clients whose token came from a different type of network — Token Provenanceと後続ルールの例。https://docs.aws.amazon.com/waf/latest/developerguide/waf-bot-control-example-token-provenance.html
10. Example scenarios of false positives with AWS WAF Bot Control — 正常通信の調整例。https://docs.aws.amazon.com/waf/latest/developerguide/waf-bot-control-false-positives.html
11. Testing and deploying AWS WAF Bot Control — Count評価と段階導入。https://docs.aws.amazon.com/waf/latest/developerguide/waf-bot-control-deploying.html
12. JA4Fingerprint — 対応リソースと算出条件。https://docs.aws.amazon.com/waf/latest/APIReference/API_JA4Fingerprint.html
13. Fang et al., LLM Agents can Autonomously Hack Websites（2024）— 研究条件下でのLLMエージェントによる複数段階のWeb攻撃。https://arxiv.org/abs/2402.06664