【AWS re:Invent 2025】AWS の壮大な脅威インテリジェンスについて

どうも Security Engineering の西川（@nishikawaakira）です。今回は AWS の脅威インテリジェンスについてセッションでお伺いしてきたのでシェアしたいと思います。

どういうセッションだったか

まず AWS 社がどういった脅威インテリジェンスの取り組みを行っているかという話があり、それらの知見をサービスに落とし込んでくれていて、我々ユーザーがどのようにそのナレッジを検知や防御に活かせば良いかという内容でした。こんなに簡単にまとめていますが、とても長い記事なので覚悟してください。

AWS の観測範囲

IPv4 アドレスは約43億あるわけですが、AWS が毎日何らかの形でやり取りしている IP アドレスはなんと 26億にも及ぶそうです。つまりインターネットの約60%とやり取りがあるということです。

で、これらの数値というのは下記から観測しています。

• ネットワークフロー
  • 1 秒あたり約 48 億フロー
  • IP 間通信、ポート情報
  • その IP アドレスがどのアカウント・インスタンスに紐づくかも把握
• DNS クエリ
  • 1 秒あたり約 3,400 万リクエスト
  • ドメイン名と解決先 IP アドレスを観測
• AWS API ログ
  • 1 秒あたり約 1 億リクエスト
  • どの API が、どのように呼ばれているか
• ホストテレメトリ
  • Amazon が管理するホストからのログ
  • 1 秒あたり約 10 億イベント
  • プロセスの開始・終了など
• 欺瞞技術（ハニーポット類 で AWS Deception Tech と書かれていました）
  • MadPot（AWS 内部の脅威インテリジェンスシステム） ハニーポット、ダークスペース監視など
  • 世界中で 1 秒あたり約 1.5 万インタラクション
  • 正当な理由がない通信が来るので、ほぼ全部が「悪意寄り」ではあるとのこと

これらすべてを合計すると、1 秒あたり約 60 億件のセキュリティテレメトリイベントになるそうです。

このうち、ハニーポットとの通信のように「ほぼ全部が悪い」ものもあれば、フローレコードや API コールのように「ほぼ全部が正しい」データもあり、後者からは、パターンや振る舞い的な異常を探して「脅威ハンティング」する必要があります。

脅威ハンティングを支えるプラットフォーム

上記のように超巨大なテレメトリを扱うために、AWS 内部には専用のデータプラットフォームがあり、役割は大きく 3 つに分けられています。

1. リアルタイムストリーム検知
   • すべてのイベントを高速に取り込み
   • 構造化＆エンリッチし
   • ルールや検知ロジックをストリーム上で適用してリアルタイム検知
2. 蓄積して後から深掘り
   • 全イベントを S3 に保存し、クエリに最適化
   • 「インシデントが発生してから時間をさかのぼり、前後の状況を見る」
   • 新しい検知ロジックの開発、フォレンジック・調査に活用
3. 長期保存向けの要約
   • 全データを永遠に保持することはできないので、
   • 時間解像度を落として（日単位・時間単位など）要約し、
   • 数年単位の長期的なトレンド分析や後方参照を可能にする

ユーザー側の観測手段

一方で、我々ユーザーが自分のアカウント内でできることは下記のようなものがあります。

• VPC Flow Logs
• DNS Query Logs
• CloudTrail
• アプリケーションログ など

これらを自分で集約・分析してもいいし、GuardDuty をオンにして AWS に任せることもできます。

ここで重要なのは、AWS はデータの中身までは見ずに幅広く浅く見てくれるというところで、逆に我々ユーザーは狭く深く見れるということと、自分たちのビジネス上の文脈やどこまでリスクを受容できるかということを理解しているという違いがあります。

脅威インテリジェンスの 4 つのレベル

セッションでは、脅威インテリジェンス（Threat Intelligence）が 4 段階に整理されていました。

1. Strategic（戦略）
   • 年次ブリーチレポートなど
   • 「どんな攻撃が増えているか」
   • 「動機・トレンドは何か」
   • この情報を活かせる期間は数ヶ月〜数年
2. Tactical（戦術）
   • MITRE ATT&CK に対応する TTP（戦術・技術・手順）
   • 初期アクセス、永続化、防御回避など
3. Operational（運用）
   • 特定のキャンペーン・特定の攻撃者
   • どのツールを使い、どのように攻撃しているか
   • アトリビューション（誰がやっているか）との結びつき
4. Technical（技術）
   • IP、ドメイン、URL、ファイルハッシュなどの IOC
   • すぐにブロックや検知に活用可能
   • この情報が活かせる期間は短い場合数分で変わってしまう可能性がある

※ Threat Intel というのは Threat Intelligence の略です。

この中で AWS が特に強くフォーカスしているのは Technical レベルで、理由は可視性があり、すぐにブロックや隔離といったアクションに繋げることができるからというものでした。同時にこの情報を活かせる期間は短いので、常に新鮮な状態を維持する必要があります。

AWS 内部の「脅威インテリジェンスプール」

AWS 内部では、脅威インテリジェンスは 1 つの「プール」に集約され、常に更新され続けています。

プールの主な供給源は下記の通りです。

• AWS Deception Tech
  • ハニーポット
  • ダークスペース監視
  • 「普通なら誰も触らない場所」に来た通信を全部拾う
• 人間のアナリスト
  • 特定の攻撃者・キャンペーンの追跡
  • レポートから抽出される IOC
• 検知・分析チーム
  • 先ほどの 60 億イベント/秒のテレメトリから脅威を見つける
  • 見つかった検知結果もプールに追加

各チームはプールに「書き込み」もするし、「読み出し」もします。これにより、

• ハニーポットが強化されれば検知も強くなり、
• 検知が強くなればアナリストもより高度な攻撃を追える

という循環が生まれます。

ただし、プールに入れたものをそのまま全ブロックするわけではなく、AWS 全体でのリスク評価（誤ブロックの影響を含めて）を行った上で、ネットワークレベルのブロックなどに適用しています。

このプールからの脅威インテリジェンスは、

• AWS 全体を自動的に守るために使われるだけでなく
• WAF / GuardDuty / Network Firewall / DNS Firewall / Inspector など

のマネージドセキュリティサービスにも供給されます。WAF のルールが日々追加されているというのはこういう脅威インテリジェンスがきちんと機能しているからということです。

つまり、これらのサービスを使うことによって我々ユーザーは、直接的に幅広いデータを持っていなくても、それを活かして防御することができます。

具体的な 3 つの脅威カテゴリ

セッションでは、以下の 3 つのカテゴリを例に深掘りしていました。

1. ネットワーク偵察・スキャン
2. 資格情報の侵害
3. マルウェア

ネットワーク偵察・スキャン

攻撃者は、

• 広い IP 範囲にパケットを投げ、
• どの IP がどのサービスに割り当てられているか、
• どんなポートが開いているか

を探ります。

AWS 側では、

• 1 つの送信元 IP が
• 非常に多くの IP／アカウント／リソース／インスタンスに対して通信している

というパターンを検出し、これを「広範囲のスキャナー」として識別します。

ハニーポットがこのリクエストを観測した場合は、そこから

• TLS フィンガープリント
• User-Agent
• Exploit の中身

などを抽出し、即座に脅威インテリジェンス化します。一方で、Tor など正当な利用もある（ほんとか？）インフラは、機械的にはブロックしないとのことでした。最終的に「安全にブロックできる」と判断されたものは、ネットワークスタックでブロックされます。

その結果として、

• AWS 内に展開したハニーポットと
• AWS 外に展開したハニーポットを比較すると、

AWS 上の方が攻撃が約 73% 少ないという数字も出ているとのことです。

---

資格情報の侵害（Compromised Credentials）

AWS の CSIRT が扱うインシデントの約 2/3 は、初期侵入が「資格情報の漏えい」だそうです。

共通点は、

• 認証方式
  • シングルファクター（1 つの要素だけで認証できてしまう資格情報）
    • ユーザー名 + パスワード
    • Access Key など
• 認証期間
  • 長期クレデンシャル

AWS の可視性から見える典型的な攻撃パターンは、

1. 攻撃者が入手した大量の Access Key を順番に API コールで試す
2. 無効な Access Key はエラーで弾かれ、有効な Access Key が見つかる
3. GetCallerIdentity 等で、どのアカウントの Access Key かを特定する
4. SES でスパム送信、EC2 でマイニング、S3 操作、アカウント作成などを実行する

ここで、1 つの IP アドレスから複数アカウントにまたがる大量の Access Key を使用するという振る舞いは極めて不自然（普通に使っていたらそんな振る舞いしないよね、ということです）なので、「Access Key を用いた攻撃者」として識別されます。

こうして得られた

• 攻撃者の IPアドレス
• TLS フィンガープリント
• 漏えいキーの集合

などは、脅威インテリジェンスプールに追加され、同じキーが別の攻撃者に再利用されても即座に検知できるようになります。

唯一の根本対策は、キーのローテーション or 無効化です。 一部のケースでは、AWS 側で

• Compromised Key Quarantine Policy の適用
• 特定 API の選択的ブロック（例：S3 ランサムウェア対策）
• お客様への通知（メール + GuardDuty finding）

などを行います。

私たちユーザー側としては、

• GuardDuty を有効化し、検知結果を“運用に組み込む”こと
• サービスのアカウント乗っ取り対策としては AWS WAF の ATP（Account Takeover Prevention）ルールグループ を使うこと

が推奨されていました。

マルウェア

マルウェアに関しては、まずハニーポットでの観測からスタートします。

スキャン → エクスプロイト → 初期ペイロード → マルウェア本体 → C2 接続

という一連の流れを、ハニーポット上で丸ごと観測できます。

ここから、

• マルウェアバイナリ
• C2 ドメイン
• 配布サイト URL

などを抽出し、静的・動的解析してマルウェアの挙動や利用インフラを特定します。

一方、「ハニーポットに当たらなかった場合」は、

1. 被害者側から見ると、ある瞬間に大量トラフィックが集中し「グラフが垂直に上がる」
2. そこから攻撃元を特定
3. データプラットフォームを使って、時間をさかのぼり、攻撃直前に、その攻撃元がどのホストと通信していたかを見る
4. それらのホストが一斉に通信している C2 を特定
5. C2 や配布サイトを、リスク評価のうえでブロック

という流れになっていました。こうすることで、

• すでに感染していても、C2 に接続できないのでマルウェアが機能しない
• あるいは、そもそも配布サイトからダウンロードさせない

といった防御が可能になります。AWS Backup や S3 に対するマルウェアスキャン、EC2/EKS/ECS/Lambda のランタイム検知なども GuardDuty に統合されています。

さらに、Route 53 の DNS Firewall によって、DNS レベルで悪性ドメインへのアウトバウンド通信をブロックすることで、サイバーキルチェーンのかなり初期段階で攻撃を止めることも可能であるという話でした。

まとめ

AWS の脅威インテリジェンスの取り組みはとても興味深く、脅威インテリジェンスの結果を我々ユーザーが享受できているということを実感しました。当たり前に GuardDuty を使っていたり、 WAF のマネージドルールを適用したりしている背景にこのような大規模な運用がされているということ本当に痛み入ります。皆さんもぜひこの壮大な背景に想いを馳せながら AWS のセキュリティサービスを活用していきましょう！