【任天堂が被害？】AWSをハッキングするCrimson Collective：防御対策の詳細

Xで活動しているサイバーセキュリティインテリジェンスアカウントのHackmanacが2025年10月11日日本時間午後3時頃に報じた所によると、任天堂のAWSサーバーがハッカー集団Crimson Collectiveにハッキングされた模様で、AWSのディレクトリの一部のスクリーショットがハッキング証拠として公開されています。

RedHatでAWSを利用している世界中の企業ユーザーが狙われる可能性がある

日本からは想像もできないようなシリコンバレークオリティのITナレッジベースを持っているChatGPT 5とGoogle Gemini Proは、サイバーセキュリティについても既知のランサムウェア等ハッキング事案を網羅的に把握しており、その知識レベルはゆうに世界トップの専門家レベルです。また最新の情報をRAGと呼ばれる技術によりいくらでも必要なだけ見つけ出してきて、我々に提供してくれます。
任天堂のAWSハッキング事案の報に接し、すぐにChatGPT 5とGemini Proの双方でハッカー集団Crimson Collectiveのことを調べてみました。
由々しき事実が判明しました。

簡単にまとめると...。
・最近出現したハッカー集団Crimson CollectiveはAWSサーバーにも使われているLinux OSのRedHatをハッキングし、まず、RedHatを利用しているAWSユーザー（その中に任天堂も含まれている）に関する情報を窃取。
・RedHatを採用している企業が利用しているクラウド環境であるAWS、Mictosoft Azure、Google Cloudの企業ユーザーのサーバー内に管理者権限で侵入できるようになった。
・管理者権限によってサーバー内の全てのディレクトリをスキャニングし、その中から彼らにとって価値があるファイルを窃取。彼らのファイル保管サーバーに移転できる。
・その後ハッキング事実をネットで公開し、攻撃対象となった企業に対して何らかの犯罪者メッセージを送りつけるという犯罪手口。
以上の様なことをします。

報道に先回りしてCrimson Collectiveの攻撃に遭わないための対策を調査しました

従って、任天堂は大手AWSユーザー（RedHatユーザー）として被害に遭った訳ですが、可能性としてはその他の全てのRedHatを使っているAWSユーザーが同じようなハッキング被害に遭うことを予期する必要があります。AzureでもGoogle Cloudでもこれが起こる可能性があります。
ということで、いち早く、関連資料を精査した上で、企業ユーザーが取ることのできる対策を含む詳細なレポートをGemini Proに作成させました。レポート作成に用いたサイバーセキュリティ専門家向け資料のリストも巻末に付しています。

このような危機事態に際して即応的な専門調査を行い、ここのブログで共有することは2025年2月にChatGPT + Deep Researchが使える様になって以来、何度も行ってきていることです。小職は元々海外市場調査屋であり、その前はITジャーナリストだった時期もあります。エンタープライズコンピューティングが自分のテリトリーでした。

クラウド環境を標的とする新興脅威グループ Crimson Collective の技術的分析とAWS防御戦略

序章：Crimson Collectiveの脅威概観と戦略的示唆

本報告書は、2025年9月に出現が確認された新興のサイバー脅威グループ「Crimson Collective」に焦点を当て、Amazon Web Services (AWS) クラウド環境を標的とした彼らの高度な戦術、技術、手順（TTPs）を分析し、それに基づいた専門的な防御戦略を提示することを目的とする。Crimson Collectiveは、従来のランサムウェア攻撃とは一線を画し、データ暗号化ではなく、クラウドインフラストラクチャからの機密情報（特に認証情報と設計図）の窃取とそれに続く金銭要求（エクストーション）を主たる動機とするクラウド特化型のアクターであるとRapid7 Labsによって報告されている 。

0.1. 脅威グループのプロファイルと歴史的背景

Crimson Collectiveは、2025年9月以降に活動が増加した、極めて新しい脅威アクターである 。このグループは、9月24日にTelegramチャンネルを開設して活動を公にし、同日に任天堂のウェブサイト改ざんを主張した 。さらに、翌9月25日には通信事業者Claro Colombiaへの侵害を主張し、5,000万件以上の顧客請求書や内部開発者リポジトリの窃取を訴えた 。これらの高プロファイルな初期活動は、グループがサイバー犯罪界隈における信憑性を急速に確立し、その後のRed Hat侵害（2025年10月1日公表）の威力を最大化するための戦略的なブランディングおよびプロモーション活動であったと推察される 。

観測された複数の事例において、Crimson Collectiveは脅迫文中で「we（私たち）」という表現を使用している 。また、同一の侵害された環境内で、複数の異なるIPアドレスからの操作が確認されている事実も相まって、このグループが単独の個人によるものではなく、複数のオペレーターによって構成される集団である可能性が高いことを示唆している 。彼らは、従来のオンプレミス環境の暗号化に焦点を当てるグループとは異なり、クラウド環境のアクセス制御モデル（IAM）の脆弱性を狙うことで、単一の漏洩した認証情報から迅速に広範なアクセス権を獲得し、企業データへの影響を最大化する戦術を採用している。

0.2. サイバーセキュリティコミュニティに対する挑発的洞察

Crimson Collectiveの出現は、クラウドセキュリティに対する従来の防御戦略の有効性に疑問を投げかけている。彼らはRapid7に向けて残したメッセージの中で、「海岸線をマッピングしている間に、真の潮流は深部で動いている」と挑発的な言葉を述べている 。このメッセージは、防御側が依然として、表層的な静的構成チェックや既知のシグネチャベースの検出に焦点を当てすぎているという、厳しい現実を指摘している。

彼らの攻撃が成功している要因は、まさにこの「深部」にある。彼らは、クラウドの運用において合法的に使用されるAPIコールやツールを悪用する、いわゆる「Living off the Cloud (LotC)」戦術を採用しているため、その行動はしばしば正規の管理者の振る舞いと見分けがつきにくい 。この戦術の採用は、従来の境界防御（ファイアウォールやエンドポイント保護）では初期の侵害を検出できないだけでなく、侵害後のラテラルムーブメントも、クラウドの内部ロギングと行動分析に特化した高度なシステムがなければ捕捉が困難であることを意味する。これにより、防御側は、パッチ適用や脆弱性管理だけでなく、設定ミスや漏洩した認証情報の即時的なライフサイクル管理を、従来のネットワーク防御と同等以上に最優先しなければならないという戦略的な示唆が得られる。

第1章：AWS環境における攻撃のライフサイクルとTTPsの詳細分析

Crimson Collectiveの攻撃手法は、AWS Identity and Access Management (IAM) 構造の弱点を突くことに特化しており、最小限の初期アクセスから、システム全体を掌握するに至るまで、高度なオペレーション・セキュリティ（OpSec）を維持しながら実行される。

1.1. 初期アクセスベクター：長期アクセスキーの不正取得

Crimson Collectiveの観測された攻撃の起点は、長期アクセスキーの侵害である 。このキーは、IAMユーザーまたはAWSアカウントのルートユーザーに関連付けられたものであり、通常「AKIA」で始まる形式を持つ 。長期キーは、短期間で期限が切れるAWS Security Token Service (STS) によって生成された一時的な認証情報（「ASIA」で始まる）とは異なり、ローテーションされにくい、あるいは有効期限が設定されていないことが多く、侵害された場合に広範な初期アクセスと永続性を提供する 。

長期アクセスキーの漏洩経路について、セキュリティリサーチは、その多くがパブリックなソースコードリポジトリ、特にGitHubなどへの意図しないハードコーディングによって引き起こされることを示している 。攻撃者は、これらのリポジトリを継続的にスキャンし、キーが公開されてからわずか数分以内に検出・利用する能力を持つことが知られている 。したがって、Crimson Collectiveの初期アクセスは、従来のネットワーク侵入ではなく、デベロッパー側の設定ミス（シークレット管理の不備）を悪用する、サプライチェーンの上流を狙った攻撃であると分析される。これは、防御側が従来の境界線に焦点を当てていても、クラウド環境の認証情報レイヤーの保護が不十分であれば、脅威を完全に検出できずに侵入を許してしまうという構造的な課題を浮き彫りにする。

1.2. 権限昇格と持続性確保：IAM構造の悪用

初期アクセスに成功した後、Crimson Collectiveは、侵害したアカウントの権限を利用して、迅速に権限を拡大し、持続性を確保する。

まず、攻撃者は侵害したIAMアカウントの権限を利用して新規のIAMユーザーを作成する 。この新規ユーザー作成の行動は、観測されたすべての侵害事例で確認されている 。次に、攻撃者はこの新規ユーザー、または侵害した既存のアカウント自体に対して、iam:AttachUserPolicy APIコールを実行し、AWSリソース全体への無制限のアクセスを可能にするAdministratorAccessポリシーを付与することで、管理権限を最大化する 。この一連のステップは、攻撃者が一度クラウド環境に侵入すると、そのアカウントの最小限の特権レベルに関係なく、迅速に垂直的な特権昇格を達成しようとする明確な意図を示す。

さらに、このグループは高度なオペレーション・セキュリティ意識を持って行動する。侵害したIAMアカウントの権限が不十分であると判断した場合、攻撃者はそのアカウントをただ放棄するのではなく、AWSの正規の機能であるiam:SimulatePrincipalPolicy APIコールを利用する 。このAPIコールは、特定のアクション（例：S3バケットへのアクセス）を実行する前に、現在のIAMアカウントに付与されているポリシーがそのアクションを許可するかどうかをシミュレーションするために用いられる。Crimson Collectiveがこの偵察ツールを利用する目的は、データ窃取や破壊的なアクションを伴わずに、最も効率的なラテラルムーブメントの経路を特定することにある。これにより、セキュリティ監視システムが検知しやすい失敗したAPIコールを回避し、ノイズを最小限に抑えながら、確実な攻撃計画を練ることができる。

1.3. 内部偵察、データ収集、およびTTPsマッピング

権限昇格が完了すると、攻撃者は内部偵察フェーズに移行し、価値のあるデータ資産の特定と窃取を行う。この段階では、ユーザー、インスタンス、S3バケット、アプリケーション、クラスターなどのAWSリソースが網羅的に列挙される 。

特に標的となるのはデータベースであり、観測事例では、Relational Database Service (RDS) のマスターパスワードが改変され、その後のデータエクスポート活動に利用されたことが報告されている 。データベースには通常、顧客の機密情報や企業の核心データが含まれるため、これはCrimson Collectiveの主要な標的がデータ窃取とエクストーションにあることを裏付けている 。データが特定され次第、攻撃者はAWSのサービスを経由してデータを外部に流出させ、被害者に脅迫状を送付する。

以下の表は、Crimson Collectiveの主要なTTPsを技術的に分類し、MITRE ATT&CK for Cloudフレームワークにマッピングしたものである。

第2章：重要事例分析：Red Hat Consultingインスタンス侵害とサプライチェーンの連鎖

Crimson Collectiveの活動の中で最も深刻な影響をもたらしたのが、2025年10月に公表されたRed Hatのセキュリティインシデントである 。この事例は、クラウド特化型脅威アクターがサプライチェーンの単一障害点をどのように戦略的に悪用するかを示す典型例である。

2.1. インシデントの経緯と侵害データの詳細

2025年10月1日、Crimson Collectiveは、Red Hatの内部コンサルティング部門が使用していたGitLabインスタンスに不正アクセスし、非公開データを窃取したと公表した 。Red Hatもこの事態を認め、内部コンサルティングコラボレーションに使用されていたGitLabインスタンスへの不正アクセスを確認した 。

攻撃者は、約570 GBのデータ、約28,000の内部リポジトリ、そして約800のCustomer Engagement Reports (CERs) を盗み出したと主張している 。流出したデータは、Red Hat Consultingが顧客に対して提供したサービスに関連する極めて機密性の高い技術情報を含んでいた 。

具体的には、以下の種類の情報が窃取されたことが確認されている：

1. 認証情報とシークレット: AWSアクセスキー、データベースクレデンシャル、CI/CDシークレット、パイプライン構成、VPNプロファイル 。

2. インフラ設計図: 顧客のインフラストラクチャ設計図、Ansible Playbooks（自動化スクリプト）、OpenShiftクラスターのインストール設計図 。

3. 顧客エンゲージメントレポート (CERs): 顧客の技術評価、ネットワーク情報、セキュリティ分析レポート 。

流出したリポジトリのファイルツリーは、2020年から2025年にわたる顧客プロジェクトが体系的に整理されていたことを示している 。影響を受けた組織のリストには、Citi、Verizon、Siemens、JPMC、HSBC、Telstraなどの世界的な金融機関、通信会社、製造業、さらには米国上院を含む公共部門の組織が挙げられている 。

2.2. サプライチェーンリスクの増幅

Red Hatインシデントの最も重大な影響は、そのデータに含まれる認証情報が、数十の Red Hat Consulting顧客に対する二次的なサプライチェーン攻撃のための武器庫となった点にある 。コンサルティング関連の資料は、顧客のインフラ詳細や認証情報を集中管理しているため、標的としては非常に価値が高い 。

Crimson Collectiveは、盗まれた認証トークンやクラウドアクセスキーを利用して、Red Hatの顧客のインフラストラクチャにラテラルムーブメント（横展開）を行い、不正アクセスを試みる可能性が極めて高い 。実際、このグループは、窃取したデータを用いてRed Hat Consultingの一部の顧客インフラストラクチャ（OPIS）に既にアクセスしたと主張している 。

コンサルティング企業やマネージドサービスプロバイダーの侵害は、複数の顧客のセキュリティが単一のソース（この場合はGitLabインスタンス）に依存していることを悪用するため、単なるデータ漏洩ではなく、企業セキュリティの信頼性そのものを揺るがす戦略的脅威である。企業は、サードパーティベンダーが自社の認証情報やインフラ設計図をどのように管理しているかについて、極めて厳格なデューデリジェンスを要求する必要があることがこの事例から明確に示される。

以下の表は、流出データの類型と、それが引き起こす潜在的な二次的リスクをまとめたものである。

流出データの類型と潜在的二次リスク

第3章：防御戦略：Crimson Collective対策のためのクラウドセキュリティ強化策

Crimson Collectiveのようなクラウド特化型エクストーションアクターに対抗するためには、従来の防御概念を脱却し、クラウドのアイデンティティレイヤーとAPI操作に特化した検出・防御メカニズムを構築する必要がある。

3.1. アイデンティティとアクセス管理（IAM）の厳格化

Crimson Collectiveの攻撃は長期アクセスキーの侵害から始まるため、その初期アクセスベクターを根絶することが最優先事項となる。

3.1.1. 長期アクセスキーの廃止とSTSへの移行

IAMユーザーに関連付けられた長期アクセスキー（AKIA）は、即座にローテーションまたは無効化し、利用を全面的に禁止すべきである 。すべての自動化プロセスおよびユーザーアクセスを、AWS Security Token Service (STS) によって生成される一時的認証情報（ASIA）に移行する必要がある 。一時的認証情報は有効期間が短く、侵害されたとしても悪用可能な時間枠が劇的に制限されるため、防御の回復力（Resilience）が大幅に向上する。

3.1.2. 最小特権原則の徹底とポリシー監査

攻撃者が権限昇格に利用する、AdministratorAccessポリシーのような広範な権限を持つポリシーを、カスタムIAMユーザーに付与することを禁止しなければならない 。IAM Access Analyzerなどのツールを利用し、組織内のIAMプリンシパル（ユーザーやロール）が付与されているアクセス権限を継続的に監査し、利用されていない過剰な権限や、外部に共有されたリソースが存在しないかを確認する必要がある。

3.2. 検出と可視性の強化：LotC戦術の封じ込め

Crimson Collectiveは正規のAWS APIコールを悪用する（LotC）ため、防御は静的な構成チェックではなく、振る舞いの異常の検出に依存する必要がある 。AWS CloudTrailログを主要な監視データソースとし、Amazon GuardDutyやSIEMと連携させることで、攻撃者が実行する一連のステップを捕捉可能となる。

3.2.1. 高リスクAPIコールの監視

以下のAPIコールは、Crimson Collectiveの権限昇格および偵察フェーズを明確に示す指標であるため、即座にアラートの対象とすべきである 。

1. 新規ユーザーの作成 (iam:CreateUser): 侵害されたアカウントから新しいIAMユーザーが作成される試みは、持続性確保の明確な試みである 。

2. ポリシーのアタッチ (iam:AttachUserPolicy): 特に、AdministratorAccessや、機密性の高いリソース（例：S3へのフルアクセス）への広範な権限を付与するカスタムポリシーがターゲットである 。

3. 権限シミュレーション (iam:SimulatePrincipalPolicy): このコールは、攻撃者が偵察を行っていることを示す高度な指標であり、通常は管理作業として頻繁に使用されるものではないため、発生した場合は直ちに調査を開始すべきである 。

4. RDSマスターパスワードの変更 (rds:ModifyDBInstance): データベースのマスターパスワードの変更は、データ窃取に先行する行動として観測されている 。

3.2.2. 地理的および時間的異常の検出

さらに、普段利用されない地理的リージョンや、通常の運用時間外に実行される認証情報利用の異常を検出する必要がある 。特に、長期間アクセスキー（AKIA）が使用された場合、そのキーが通常とは異なるパターン（例：複数のアカウントでの同時アクセス、異常なAPIコールの頻度）を示す際にフラグを立てることで、侵害後の悪用を早期に発見できる 。

3.3. 開発環境セキュリティ（DevSecOps）の強化

Red Hatインシデントは、開発リポジトリとコンサルティング関連データにおけるシークレット管理の致命的な欠陥を露呈した 。

3.3.1. シークレットスキャンとリポジトリ監査

シークレットスキャンツールをCI/CDパイプラインに統合し、AWSキーやDB接続文字列などの認証情報がコードやドキュメントにハードコードされることを継続的に防止する必要がある 。ソースコード管理システム（GitLab、GitHubなど）を対象とした外部スキャンを定期的に実施し、意図せず公開された認証情報を検出する必要がある。

3.3.2. サードパーティリスク管理の強化

Red Hatのようなコンサルティングパートナーや外部ベンダーと連携する場合、顧客インフラへのアクセスが必要な外部パートナーに対しては、必ず一時的で最小限の権限を持つ認証情報のみを提供し、アクセススコープを厳しく制限する必要がある。また、顧客の機密情報を含むドキュメント（CERsなど）の管理と保管場所を厳格に監査し、不必要な認証情報や設計図が長期間リポジトリ内に残置されないようにするポリシーを徹底すべきである。

以下の表は、Crimson CollectiveのTTPsに対抗するための優先度の高い防御策と、関連するAWSサービスをマッピングしたものである。

AWS環境におけるCrimson Collective対策のための優先度の高い防御策

第4章：結論と戦略的提言

4.1. 総括：クラウドセキュリティ態勢の危機

Crimson Collectiveは、従来のサイバー犯罪グループが抱える技術的な制約を克服し、クラウド環境のアイデンティティとアクセス管理（IAM）の設計上の弱点を戦略的に悪用する、極めて洗練された脅威アクターである。彼らの成功は、パッチ未適用の脆弱性を突くことではなく、長期アクセスキーの漏洩と、過度に広範なIAMポリシー設定という、クラウドセキュリティ態勢の根本的な欠陥に依存している 。

特にRed Hatインシデントは、コンサルティングサービスやマネージドサービスプロバイダーを通じて、数十社の高プロファイル企業が連鎖的な二次攻撃の危機に晒されるという、現代のサプライチェーンリスクの深刻な側面を明確に示した 。このインシデントは、クラウド環境における防御の焦点が、もはやネットワーク境界ではなく、アイデンティティとクラウドAPIの振る舞いを監視する層に移る必要があることを示唆している。

4.2. 喫緊の対応と戦略的提言

Red Hat Consultingと連携していた、またはRed Hatの技術を利用していた企業は、窃取されたリポジトリに含まれていた可能性のある以下の認証情報を直ちにローテーションし、インフラ設計図の悪用リスクを評価する必要がある ：

1. すべてのAWS、Azure、GCPなどのクラウドアクセスキー。

2. データベース接続文字列およびサービスアカウントの認証情報。

3. CI/CDパイプラインで使用されるシークレットとVPNプロファイル。

企業セキュリティ責任者（CISO）および上級セキュリティアーキテクトに対し、Crimson Collectiveの脅威に対抗するための以下の戦略的行動を強く推奨する：

1. 長期IAMアクセスキーの即時廃止: AWSにおける永続的なIAMアクセスキーの使用を全面的に停止し、AWS STSによって提供される短期の一時的認証情報への移行を義務付ける。これにより、初期アクセスが成功した場合でも、攻撃者が利用できる時間を劇的に制限する。

2. 行動分析に基づく監視の強化: AWS CloudTrailおよびGuardDutyを利用し、特に権限昇格に関連するAPIコール（iam:CreateUser, iam:AttachUserPolicy）や、攻撃者が偵察に用いるiam:SimulatePrincipalPolicyの使用を異常行動として定義し、即時調査可能なアラート体制を確立する。

3. DevSecOps原則の徹底によるシークレット管理: 開発者リポジトリへの認証情報のハードコーディングを防止するための継続的なシークレットスキャンを導入し、サードパーティとの間で共有される認証情報のライフサイクルとスコープを最小限に制限する厳格なガバナンスモデルを確立する。