Aisuruボットネット、テラビット級のDDoSで示した「量」から「面」で押し潰す新常態

今日の深掘りポイント

• 史上級の29.7Tbpsに象徴されるのは「ピーク値」ではなく、IoTボットを面展開してインターネット全体を同時多発で揺らす戦い方への構造的転換です。
• AisuruはMirai後継の量的拡大にとどまらず、UDPカーペットボンビングやランダム化でACL・レート制御の閾値を外し、秒単位の攻撃ウィンドウに最適化しています。
• 企業のDDoS対策は「帯域の太さ」やWAF単独では不十分です。BGP Flowspec/RTBHの自動化、ISP連携、Anycast冗長、L4/L7の協調防御、観測系（sFlow/NetFlow, pps/bps/rps）の三位一体が要諦です。
• 生成AI/自動車など低遅延APIの業種ほど、短時間・高出力・多拠点同時の攻撃に脆弱です。運用としては「1分以内の自動緩和」「サブプレフィックス面攻撃の早期検知」をSLO化する段階に入っています。
• 本件は確度・即時性が高い脅威で、守りの再構築は後回しにできません。とくにオンプレ単独や単一スクラビング事業者依存は、今回のスケールではリスクが顕在化します。

はじめに

CloudflareがAisuruと名付けたボットネット由来のDDoSを四半期にわたり緩和し、そのピークが29.7Tbpsに達したと報じられています。感染デバイスは最大で約400万台規模とされ、MiraiクラスのIoT軍勢が最新の攻撃手法と結びついた格好です。ネットワーク層の超大規模攻撃が常態化・多発化していること、攻撃者が「インターネット全体をストレステスト」するように観測・学習を繰り返していることが重要な示唆です。The Registerの報道はCloudflareの公開情報をもとにこの変化を伝えています。

本稿は、数値の大きさそのものに驚嘆するのではなく、攻撃面の広がり・継戦テンポ・回避手口の質的変化にフォーカスし、国内のCISO/SOCに必要な設計変更と即応アクションを提示します。

深掘り詳細

事実整理（何が起きたか）

• Aisuruボットネットは、主にハイジャックされたルーターやカメラなどのIoTから構成され、過去3カ月の観測で最大約400万台が攻撃に動員されたと報じられています。
• Cloudflareはネットワーク層の超大規模（テラビット級）攻撃を継続的に緩和し、そのピークが29.7Tbpsに達したとしています。
• 攻撃は従来型の一点集中というより、UDPカーペットボンビング（広い宛先空間へ薄く広く撒く）やパケット属性のランダム化でフィルタやレート制御の閾値回避を図るなど、回避性と持続性を重視する進化が見られます。
• 直近では生成AI企業や自動車産業に対するDDoSの増加が報告され、API/エッジ通信のレイテンシ耐性が低いワークロードの弱点が突かれています。
  出典：Cloudflareの公表内容を伝えるThe Registerの記事。

インサイト（なぜそれが重要か）

• 量から面へ：ピークの最大値よりも、/24〜/20といったサブプレフィックス全体を同時に叩く面攻撃の浸透が深刻です。設備側の「単一宛先防御」思考を無力化し、ToR〜アグリゲーション〜コアルータの各層で微小輻輳を引き起こし、APMやユーザ体感に先行してSLO違反を誘発します。
• 閾値破りの最適化：ランダム化（送信元/宛先ポート、フラグメント、IP識別子、TTLなど）により、静的ACLや単純なpps/bpsしきい値をすり抜け、検知側も「異常の定義」そのものを動的に再学習する必要が出ています。
• 攻撃テンポの高速化：短時間・高出力・頻発の三拍子で、人的オペレーションが介在する余地を削っています。緩和は「自動・即時」が前提で、BGP Flowspec/RTBH、WAFレート制御、L7行動分析を編成化したプレイブックがなければ追いつきません。
• プロトコル転換の追い風：QUIC/HTTP/3などUDP志向の普及は、UDP全面遮断や単純なポートブロックの副作用を高めます。業務を止めずに悪性トラフィックだけを刈り取る粒度が必要で、DPIや行動相関、Anycastでの負荷分散などアーキテクチャ面の投資が要ります。
• エコシステムの成熟：DDoS-for-hire市場は供給（ボット化IoT）と需要（脅迫・政治的示威）の両面で成熟し、攻撃者は「テスト→観測→改良」のループを回しています。今回の“ストレステスト”は、その学習過程の可視化と捉えるべきです。

実務上の論点（測り方と守り方の再設計）

• メトリクスの再定義：bpsの最大値だけでなく、pps、同時フロー数、宛先サブネット拡がり、継続時間の分布をモニタリング指標に組み込みます。特にカーペット系は「多宛先・低密度」を早期に拾うルールが要です。
• 観測の粒度：sFlow/NetFlowのサンプリング比は攻撃早期検知に直結します。攻撃窓が短いほど、粒度不足は致命的になります。
• 緩和の責務分散：オンプレ防御だけで耐える設計は限界です。エッジ（CDN/Anycast）、スクラビングセンタ、上流ISP、データセンタ網内の4層で役割を分割し、自動連係（Flowspec/RTBH/WAF API）で“秒オーダー”の発火を可能にします。
• 回避不能時の設計：アプリケーション側の優雅な劣化（機能間引き、キャッシュ利用、リードオンリー化、キュー上限）を備え、完全遮断を避ける設計原則を明文化します。

脅威シナリオと影響

以下は、Aisuru級ボットネットが取り得るシナリオの仮説と、MITRE ATT&CKに沿った整理です（技術IDは典型的なマッピングの一例です）。

• シナリオ1：UDPカーペットボンビングで企業のアドレスブロック全体をじわじわ飽和

  • 手口：/24〜/20の多数宛先へ低密度UDPフラグメントやランダムポートを散布。上流やアグリゲーション層の帯域・処理を面で圧迫。
  • MITRE：T1498 Network Denial of Service（特に直接ネットワークフラッド/回避的散布）、T1090 Proxy（多段の踏み台/C2隠蔽）、T1583 Acquire Infrastructure・T1584 Compromise Infrastructure（ボット/踏み台確保）。
  • 影響：SaaS/APIの遅延悪化、VoIP/低遅延系の劣化、監視の盲点化（遅延でアラート不達）、誤検知によるセルフDoS。

• シナリオ2：L7 HTTP/2/3の短時間・高RPS攻撃とL3/4の同時多発

  • 手口：HTTP/2の接続再利用や制御フレーム悪用（Rapid Reset系の変種など）でアプリ面を疲弊させ、同時にL3/4で帯域を消費する多層飽和。
  • MITRE：T1499 Endpoint Denial of Service（アプリ/サービス枯渇）、T1498 Network DoS（同時多発）、T1588 Obtain Capabilities（攻撃ツールの入手）。
  • 影響：APIゲートウェイや認証基盤のスローダウン、レート制御の誤作動、バックエンドのスレッド/接続プール枯渇。

• シナリオ3：反射/増幅を織り交ぜた混合流（DNS/NTP/CLDAP/WS-Discovery）

  • 手口：古典的アンプに新規のUDPサービス（IoT/産業系プロトコル）を混ぜ、署名やポートに依存したフィルタを回避。
  • MITRE：T1498.002 Network DoS: Reflection/Amplification。
  • 影響：ISP側でのブラックホール発動や経路切替による副作用（特定地域の不可用、CDNのキャッシュミス連鎖）。

• シナリオ4：産業・自動車サプライチェーンの業務窓狙い撃ち

  • 手口：生産切替/OTA配信/カットオーバーなど時限イベントに合わせて短時間高出力でAPI/ブローカーを麻痺させる。
  • MITRE：T1499（サービス枯渇）＋事前の偵察 T1598（フィッシング/社会工学による運用スケジュールの収集）※仮説。
  • 影響：ライン停止、OTA遅延、SLA違反、在庫計画の乱れ。短時間でも高額な事業損失に直結。

参考（MITRE ATT&CK）：

• Network Denial of Service（T1498）: https://attack.mitre.org/techniques/T1498/
• Endpoint Denial of Service（T1499）: https://attack.mitre.org/techniques/T1499/

セキュリティ担当者のアクション

優先順位と現実性を重視した打ち手です。可能な限り自動化・契約整備・テストを前倒しします。

• ネットワーク防御の再設計

  • 上流連携の自動化：BGP Flowspec/RTBHの事前合意とAPI自動発火。プレイブックに「誰が・何を・何秒で」実施するかを明文化します。
  • Anycast＋マルチスクラビング：単一事業者依存を避け、フェイルオーバー手順を定期演習します。GRE/Direct Connectなど戻り経路の健全性も併せて検証します。
  • 観測強化：sFlow/NetFlowの粒度を見直し、pps/フロー数/宛先拡がり/サブプレフィックス単位の異常を可視化します。面攻撃の早期検知ルール（多数宛先へ低密度トラフィック）を導入します。
  • カーペット対策：宛先/サブネット別のしきい値と局所的レートリミット、ToR/アグリゲーションでのマイクロバースト緩和（キュー管理、ECN活用）を検討します。

• アプリ・エッジ側の耐性強化

  • L7耐性：HTTP/2/3のコネクション/ストリーム上限、ヘッダサイズ、リクエスト/秒の動的制御を導入し、BOT動作（JA3/TLS FPやUser-Agent/ヘッダの行動相関）で遮断します。
  • 優雅な劣化：キャッシュ前段化、読み取り専用モード、バックグラウンド処理の遅延許容、機能間引きで「完全停止」を避けます。
  • エッジの分散：Anycast/マルチリージョンでホットスタンバイ化し、地理的・AS的にトラフィックを拡散します。

• インシデント準備と運用

  • SLO設定：検知から緩和発動までの上限時間、残余トラフィック量、誤検知率をサービス単位で設定し、可観測性のダッシュボードに実装します。
  • ゲームデイ：スクラビング事業者/ISPと合同で年数回の演習を実施し、Flowspec/RTBHの伝播時間・復旧時間を計測します。
  • サプライチェーン保護：重要イベント（リリース、OTA、決算、キャンペーン）のカレンダーを共有し、事前の帯域・スクラビング枠確保とレート上限見直しを行います。

• ボットネット供給側への対策（自社IoT/OTの衛生管理）

  • 既設機器の棚卸し：露出した管理インタフェース（Telnet/SSH/HTTP、TR-069/UPnP等）を遮断し、デフォルト認証情報を排除します。
  • 監視：外向きの不審なUDPフラッドやNTP/DNS/SSDP等の反射トラフィックを監視し、自社からの加担を未然に防ぎます。
  • セグメンテーション：IoT/OTは分離し、帯域とレート制御を独立運用します。

• 組織・契約

  • 事前合意：スクラビングやISPとのSLA/OLAに「緊急発動」「連絡チャネル」「費用」の明記を徹底します。
  • 情報共有：国内外のCSIRT、業界ISACを通じてシグネチャやIoC、手口の変化を継続共有します。

本件は、信頼度と即時性が高い観測に基づくシグナルで、攻撃者の能力曲線が上方にシフトしたことを示しています。単発の“過去最大”ではなく、短時間・多発・面展開・回避性の四点セットに備える設計への移行を、年明けを待たずに進めるべき局面です。

参考情報

• Cloudflareの公表内容を伝えるThe Register: https://www.theregister.com/2025/12/04/cloudflare_aisuru_botnet/
• MITRE ATT&CK T1498 Network DoS: https://attack.mitre.org/techniques/T1498/
• MITRE ATT&CK T1499 Endpoint DoS: https://attack.mitre.org/techniques/T1499/