ランサムウェア
クラウドストレージ「S3」を狙うランサムウェア攻撃のパターンと対策
近年のランサムウェアグループは、クラウド環境への攻勢を強め、AWS内の業務基幹データを侵害する戦略を展開しています。本稿では、その攻撃パターンと対策を解説します。
目次
- 概要
- 古くからの脅威が新たな環境を侵食：クラウド環境に移行するランサムウェア
- クラウド型ランサムウェアの標的
- Amazon S3におけるサーバサイドの暗号化
- S3ランサムウェア攻撃の計画と進行：攻撃者の考えを理解する
- S3ランサムウェア：過去の攻撃例と将来を見越した対策
- Trend Vision One™を活用したプロアクティブなセキュリティ対策
- CloudTrailを活用してS3ランサムウェアを検知
- 「Trend Vision One™ - Cloud Risk Management」 を活用： S3 ランサムウェアに対するセキュリティ体制をチェック
- S3をランサムウェア攻撃から保護するためのプロアクティブな戦略
- 参考記事
- 「Amazon Simple Storage Service（S3）」などのクラウドストレージサービスは典型的な攻撃対象であり、特に顧客側のバケット設定ミスやアクセス制御不備を悪用される恐れがあります。
- 本稿では、S3を狙ったランサムウェアのパターンを5種類に大別し、すでに確認されている攻撃技術や、将来的に悪用されかねない侵入経路を詳しく解説します。
- セキュリティプラットフォーム「Trend Vision One™」では、ログ記録サービス「AWS CloudTrail」のイベントを可視化し、ランサムウェア活動の検知や対処を手厚く支援します。
古くからの脅威が新たな環境を侵食：クラウド環境に移行するランサムウェア
ランサムウェアは古くから続く脅威であり、長年にわたってフィッシングメールや不正な添付ファイル、期限切れソフトウェア、脆弱性、ネットワーク侵入技術などを悪用し、オンプレミスの環境を狙ってきました。
しかし最近では、多くの企業や組織がクラウド環境に移行したことに伴い、ランサムウェアグループの戦略も変化しています。具体的に攻撃者は、設定不備を抱えたクラウド環境内の顧客ストレージや、盗まれた認証情報を悪用する動きを強めています。従来からのランサムウェア活動が「マルウェア」の暗号化機能に大きく依存していたのに対し、クラウド型ランサムウェア攻撃の多くは、「クラウドサービス自体」の機能を悪用することで、データの暗号化や改ざん、削除、アクセス妨害、機密情報抽出といったタスクを実行します。しかも、こうした活動は、従来型セキュリティツールの監視をすり抜けながら進行します。
本稿では、こうしたクラウドの情報資産を狙うランサムウェア活動について、「Trend™ Research」の調査をもとに分析します。はじめに、攻撃者に狙われやすいクラウドリソースの種類や、その性質を説明します。次に、ストレージサービス「Simple Storage Service（S3）」を狙ったランサムウェア活動の手口を、5種のパターンに分けて解説します。さらに、こうした脅威を防ぐ上で有効な対策やポリシー設定を提示します。
クラウド型ランサムウェアの標的
ランサムウェアグループは、標的の資産を選定する際に、インフラや基幹業務データの復旧を妨害することに重点を置く傾向があります。以降に示す「Amazon Web Service（AWS）」のリソースは、比較的高い価値を持ち、業務への影響も大きいことから、主要な標的となっています。
スナップショット
「スナップショット」は、仮想マシンにおけるディスクやボリュームの一時コピーに相当します。具体例として、ストレージサービス「Amazon Elastic Block Store（EBS）」のスナップショットが挙げられます。こうしたスナップショットは、EC2インスタンスが停止、侵害された際の迅速な復旧手段となるため、攻撃者に狙われる可能性があります。ランサムウェア攻撃でスナップショットが消失した場合、システムをゼロから再構築するのに数日以上を要することもあります。また、EC2上で稼働する基幹アプリケーションが長時間停止して業務に深刻な影響が発生し、身代金を支払うまでデータを復旧できない場合もあります。
攻撃者がスナップショットの管理権限を入手した場合、もとのEC2ボリュームを暗号化し、そのスナップショットを削除することで、復旧手段を奪う可能性があります。また、スナップショットを攻撃者自身の環境にコピーした上で、被害環境のEC2インスタンスとスナップショットの双方を削除することで、復旧への道を完全に断ち切るケースも考えられます。
クラウド静的ストレージ
Amazon S3バケットのようなクラウド静的ストレージも、攻撃対象になります。S3ストレージには、中身としてバックアップファイルやログ、分析データ、静的Webコンテンツ、アプリケーション資産、さらにTerraformステートファイルなどのインフラ設定が頻繁に格納されるためです。
クラウド静的ストレージのアクセス設定に不備がある、または認証情報が流出すると、攻撃者はそこに存在するデータを暗号化した上で脅迫状（ランサムノート）をアップロードし、元のファイルを削除、または破損データで上書きする可能性があります。結果、そのデータを必要とするサービスや業務全般に深刻な影響が発生します。また、S3バケットに履歴情報やバックアップデータが含まれていた場合、運用復旧とフォレンジック復旧の両手段が阻害されることになります。
クラウドデータベース
Amazon RDS（PostgreSQL、MySQLなど）やAurora、DynamoDBといったクラウドデータベースも、攻撃者に狙われる可能性があります。こうしたデータベースには、顧客情報や取引履歴、認証情報、テレメトリなど、機密性の高いデータが格納されがちなためです。攻撃者がそこに不正アクセスした場合、データベース内のレコードを暗号化、流出、または削除する恐れがあります。また、復旧を阻止するために、自動バックアップやスナップショットを削除するケースも考えられます。
こうした攻撃は、アプリケーション機能に影響を及ぼす他、ユーザデータを侵害し、法的な罰則（GDPR違反など）に繋がることもあります。特に、バックアップがない場合の復旧は不可能に近く、被害者側では、身代金の支払いという選択肢を強く迫られることになります。
コンテナイメージとレジストリ
コンテナサービス「Amazon Elastic Container Registry（ECR）」や、各種コンテナレジストリ、イメージも、攻撃対象と見なされる場合があります。なぜなら、アプリやマイクロサービスなどのコンテナ化ワークロードが、ECR内に格納されたコンテナイメージに強く依存しているためです。ECRを狙う攻撃者は、イメージを削除してアプリケーションのデプロイ用パイプラインを停止させる他、イメージを不正なバージョンで置き換える可能性があります。こうして侵害されたコンテナイメージやレジストリは、CI/CDパイプラインの機能不全やアプリ再デプロイ時のエラーを引き起こすだけでなく、自動スケーリングやコンテナ置換戦略を阻害する場合もあります。仮にコード自体が安全なままでも、イメージがなければ再デプロイを行えず、本番環境の運用を継続できなくなる恐れがあります。
クラウドバックアップや災害復旧システム
ランサムウェア攻撃に遭った際には、バックアップが最後の命綱となります。そのため、S3やGlacier、AWS Backupによるバックアップもまた、攻撃者に狙われる可能性があります。狡猾な攻撃者は、バックアップを削除することで身代金交渉を有利に進められることを、十分に把握しています。バックアップデータの保管庫（Vault）やバケットにアクセスできれば、バックアップファイルを恒久的に削除、暗号化、改ざんできる他、バックアップの保持期間設定を短く書き換えることも可能です。被害者側では、メインシステムを復旧できたとしても、クリーンなバックアップが損なわれれば、データの完全性を保証しにくくなります。実際、バックアップがないために、身代金の支払い以外に復旧手段がなかったという事例が、数多く存在します。
AWSに属する各種サービスの中でも「Amazon S3」は、アプリケーションデータからメディアファイル、バックアップ、インフラ設定に至るまで、あらゆる情報を保管するためのバックボーンとして機能します。その重要性や普及率を踏まえると、ランサムウェアグループの目には、高価値な標的として映るでしょう。以降、攻撃者が標的のS3を選定する際の基準や、データ侵害から身代金要求に至る基本的な流れを解説します。
Amazon S3におけるサーバサイドの暗号化
Amazon S3は、保存データを暗号化するためのオプションとして、下記を提供しています。
- SSE-S3：AWSが暗号化キーの管理をすべて担う。
- SSE-KMS：「AWS Key Management Service（KMS）」を用いて暗号化キーを管理し、キー・ポリシーやアクセス権限のカスタマイズを通して高度な制御を可能にする。
- SSE-C：顧客側が独自に暗号化キーを提供するものであり、自身でキー管理を完全にコントロールできるようになる。この方式は、厳格なコンプライアンスやセキュリティ要件を満たすために選ばれることが多いが、キーの安全な保管や管理を顧客側に委ねる形となり、複雑さが増大する。なお、AWS側はSSE-Cのキー自体を保持せず、代わりにキーのHMAC（ハッシュベースのメッセージ認証コード）を記録し、アクセス要求時の検証に利用する。
- バージョニングが無効であること：バージョニングが無効の場合、被害者側では、暗号化または上書きされたファイルを元のバージョンに復旧できなくなる。
- オブジェクトロックがかかっていないこと：オブジェクトロックが設定されていないバケットであれば、データの上書きや削除操作を無制限に行える。これは、ランサムウェア攻撃の成功に不可欠な条件と考えられる。
- 「MFA Delete（削除操作時に多要素認証を要求する仕組み）」が無効であること：MFA Deleteが無効の場合、攻撃者は多要素認証なしでオブジェクトやバケットのバージョン履歴を完全に削除できるようになる。これにより、クリーンアップ作業が容易になると同時に、標的に損害を与えやすくなる。
- 書き込み権限設定に不備があること：攻撃者がファイルを再アップロードまたは上書きする際には、アクセス権限「s3:PutObject」や「s3:PutObjectAcl」に加え、「SSE-KMS」の適用時には「kms:Encrypt」が必要となる。これらの権限が攻撃者の手にわたる要因として、以下が考えられる。
- 顧客定義によるIAM（Identity and Access Management）ポリシーの適用範囲が広すぎる（例：リソースやアクションに「*」を指定）
- クロスアカウントロールの設定不備
- 認証情報の侵害や流出
- 高価値なデータを含むこと：バックアップや設定ファイル、データベースのダンプ、私有コードのように重要な資産を格納したバケットは、主要な攻撃目標になる。そうしたバケットの判定材料として、ファイル名（例：「backup.sql」や「prod.env」）やバケット名（例：「company-archive」や「db-backup」）などが挙げられる。
攻撃者の目標 – データを被害者側で復旧できない状態にする
標的のS3を選定し、そこへのアクセスにも成功した場合、攻撃者の次の目標は、データを被害者側で読み取れない状態に塗り替え、かつ、復旧の手立てを失わせることです。その代表的な手段を、以下に示します。
- 標的組織がアクセスできない暗号化キーを作成または使用する：攻撃者は、標的組織のAWSユーザが技術的にアクセスできない暗号化キーを利用してS3オブジェクトを暗号化する。これによって被害側では、例えルートユーザであっても、S3ファイルを一切復号できなくなる。
- AWSサポートでもアクセスできない暗号化キーを作成または使用する：攻撃者は、AWSのサポートチームでも技術的にアクセスできない暗号化キーを利用する。こうしたキーはAWSの管理領域外、またはサービス品質保証契約（SLA）の対象外にあるため、AWSのサポートを受けたとしても、データを復旧できなくなる。
- 身代金を要求する：被害者側から元データにアクセスできなくなった時点で、攻撃者は復号キーの共有や再有効化、データの復旧などと引き換えに、身代金の支払いを要求する。こうした要求は通常、脅迫状の形で提示される。
S3ランサムウェア：過去の攻撃例と将来を見越した対策
第1種攻撃（デフォルトのAWS KMSキーを利用 - 「SSE-KMS」）
2019年、AWS環境におけるS3ランサムウェア攻撃の概念実証（PoC：Proof of Concept）が公開されました。この攻撃法では、AWS KMSキーのデフォルト設定が利用されます。攻撃の流れを、下図に示します。
1. はじめに攻撃者は、被害者のS3バケットに対する書き込み権限付きアクセスを入手する（GitHubの公開ソースコードから盗み取ったIAMロール認証情報や、侵害済みのAWSアカウントなどを利用）。
2. 攻撃者自身のAWSアカウント内でKMSを利用し、顧客管理型の対称キー（CMK：Customer Master Key）を作成する。このキーは、全アカウントから読み取り可能な状態に設定する（図2、3）。
上記のポリシーによって作成したKMSキーは、あらゆるAWSアカウントから参照し、暗号化に利用することが可能となります。
3. 手順「1」で攻撃者は標的S3へのアクセスを得ているため、そこに含まれる脆弱なバケットを検索、特定できるようになる（図4）。
4. 手順「2」で作成したKMSキーを利用し、脆弱なバケット内のオブジェクトを暗号化する（図5）。
5. KMSキーが7日後に削除されるように、スケジュールを設定する。AWS KMSの仕様上、キー削除のスケジュールを設定する際には、最低でも7日前に事前通知する必要がある。
6. 暗号化の完了後、攻撃者は、脅迫状ファイル「ransom-note.txt」をアップロードし、身代金を要求する。被害者側では、キーや元データの復旧手段が失われるまでに、7日の猶予があることになる。
この手口は、「クロスアカウント攻撃」として発生する可能性が高いと考えられます。仮にクロスアカウントではなく被害者のAWSアカウント内で実行すれば、被害組織側の特権ユーザがKMSキーにアクセスできるためです。
また、この攻撃は、現実には起こりにくいと考えられます。それは、キー削除までに最低7日間の猶予を設けねばならず、その間にAWSサポートが介入し、キーを特定される可能性が高いためです。
第2種攻撃（顧客提供のキーを用いてサーバサイドの暗号化を実行 - 「SSE-C」）
2025年初頭、SSE-Cの仕組みを悪用するランサムウェアグループ「Codefinger」の手口が公開されました。S3バケットに対する攻撃の流れを、以下に示します。
1. はじめに攻撃者は、被害者のS3バケットに対する書き込み権限付きアクセスを入手する（GitHubの公開ソースコードから盗み取ったIAMロール認証情報や、侵害済みのAWSアカウントなどを利用）。
2. S3バケットを検索し、目的に適した標的を選定する。
3. 攻撃者は、ローカルに保存したAES-256キーを指定し、下記のヘッダーを用いてサーバサイドでの暗号化を開始する。本操作は、REST APIやHTTPリクエスト、AWS SDKを通して行われる。なお、SDKやCLIツールを使用する場合、ユーザがヘッダーを直接設定することはない。
x-amz-server-side-encryption-customer-algorithm
4. AWS側では、暗号化のためにキーを使用するが、それ自体は保存しない。代わりに、キーのHMACをログ記録サービス「CloudTrail」に書き込む。このHMACを取得しても、元のキーや暗号化前のデータを復旧することはできない。
5. 暗号化の完了後、攻撃者はバケットに脅迫状をアップロードする。
この攻撃法は、他と比べて発生する可能性が高いと考えられます。なぜなら、SSE-Cの仕様上、攻撃者が暗号化キーを完全に把握、管理することになり、顧客やAWS側では、暗号化前のデータを復旧する手立てがなくなるためです。対策として、KMSの「ImportKeyMaterial（キーマテリアル・インポート）」や「External Key Store（外部キーストア）」、または「SSE-C」の悪用を防ぐ統合ポリシーを以下に示します。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenySSECEncryptionForNewWrites",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "*",
"Condition": {
"Null": {
"s3:x-amz-server-side-encryption-customer-algorithm": "false"
}
}
}
{
"Sid": "DenyKmsOperationsViaS3OnExternalKeys",
"Effect": "Deny",
"Principal": "*",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:KeyOrigin": ["EXTERNAL", "EXTERNAL_KEY_STORE"],
"kms:ViaService": "s3.<region>.amazonaws.com"
}
}
}
]
}
顧客側では、下記のポリシーをRCPに追加することで、本攻撃を防げる可能性が高まります。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RestrictSSECObjectUploads",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "*",
"Condition": {
"Null": {
"s3:x-amz-server-side-encryption-customer-algorithm": "false"
}
}
}
]
}
また、バケットのポリシーとして下記を加えることも、有効な対策となります。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RestrictSSECObjectUploads",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::<your-bucket-name>/*",
"Condition": {
"Null": {
"s3:x-amz-server-side-encryption-customer-algorithm": "false"
}
}
}
]
}
AWSアカウントの統合管理サービス「AWS Organizations」を未適用の顧客ユーザは、下記のポリシー宣言をバケットに加えることで、SSE-Cによるアップロードやコピーリクエストの全てを拒否することが可能です。なお、項目「Resource」には、実際のバケットARN（Amazonリソース名）を指定する必要があります。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenySSECEncryptionForNewWrites",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::your_bucket_arn_here/*",
"Condition": {
"Null": {
"s3:x-amz-server-side-encryption-customer-algorithm": "false"
}
}
}
]
}
第3種攻撃（S3からの情報流出と削除）
2024年の報告によると、流出したAWS認証情報を入手した攻撃者「Bling Libra」は、S3バケットにアクセスしてデータを削除し、被害者に対してデータの破壊や流出をちらつかせ、脅迫を行いました。攻撃の流れを、以降に示します。
1. はじめに攻撃者は、被害者のS3バケットに対する書き込み権限付きアクセスを入手する（流出したIAMロール認証情報や侵害済みAWSアカウントなどを利用）。
2. S3バケットを検索し、目的にあった標的を選定する。
3. S3バケット内の全データを攻撃者自身の環境に流出させる。このデータは、後の脅迫材料として利用される。
4. S3バケットの全オブジェクトデータ、またはバケット全体を削除する。
5. 元のバケットに（残されている場合）脅迫状をアップロードするか、または、脅迫を示唆する名前で新規のバケットを作成する。後者の動きは、Bling Libraの事例からも明確に確認できる。
この攻撃法も、比較的発生しやすいと考えられます。理由として、流出と削除が単純な2ステップだけで完結する点や、顧客やAWSサポート側でデータを復旧できない点が挙げられます。
第4種攻撃（AWS KMSの外部キーマテリアルを利用）
先述した「Codefinger」による攻撃がSSE-Cを悪用していたこともあり、セキュリティコミュニティの間では、SSE-Cのリスクに関する懸念が高まっています。実際に、多くの企業や組織がSSE-Cの制限や禁止に向けて動いています。しかし、同様の脅威をもたらす攻撃手段は他にも存在し、まだ十分に認知されていない可能性があります。
こうした手口の一つが、KMSの外部キーマテリアルを利用する方式です。AWSには、ユーザ自身のキーマテリアルをもとにKMSキーを作成するオプションがあり、「Bring Your Own Key（BYOK）」の名で呼ばれています。キーマテリアルをAWSに生成させるのではなく、ユーザ自身でインポートする形をとることで、キーの「保持期間」や「ライフサイクル」、「源泉」を自前で管理できるようになります。これに対してAWS KMS側では、AWSサービス内におけるキーの「利用」を管理します。
インポートした外部キーマテリアルについては、保持期間をユーザ側で任意に設定することが可能です。これは、ランサムウェア攻撃の実行者にとって、魅力的な性質と言えるでしょう。保持期間を短く設定することで、被害者やAWSが暗号化前のデータやキーにアクセスできる可能性を著しく制限できると考えられます。
こうした攻撃の流れを、以降に示します。
1. はじめに攻撃者は、被害者のS3バケットに対する書き込み権限付きアクセスを入手する（流出したIAMロール認証情報や侵害済みAWSアカウントなどを利用）。
2. S3バケットを検索し、目的にあった標的を選定する。
3. はじめにSSE-Cの暗号化を試みるが、この操作は拒否される。
4. 代替策として攻撃者は、自身のAWSアカウント内でKMSのオプション「外部キーマテリアルのインポート：External (Import Key Material)」を利用し、顧客管理型の対称キー（CMK）を作成する。このキーは、すべての人から読み取れるように設定する（図9、10）。
5. 下図のように、ラッピング用のキー（wrapping key）とアルゴリズム（wrapping algorithm）を選択する。
6. 攻撃者自身の端末にラッピング用の「公開キー」をダウンロードし、トークンをインポートする。続いて、自身の環境で新たなキーを作成し、「公開キー」によってラッピングする。
openssl rand -out mycustomkeymaterial.bin 32 <Created new key>
openssl pkeyutl \ <Wrapped the new key with downloaded wrapping key>
-encrypt \
-in mycustomkeymaterial.bin \
-out MyCustomKeyNowEncrypted.bin \
-inkey WrappingPublicKey.bin \
-keyform DER \
-pubin \
-pkeyopt rsa_padding_mode:oaep \
-pkeyopt rsa_oaep_md:sha256 \
-pkeyopt rsa_mgf1_md:sha256 \
7. ラッピング済みのキーとインポート用トークンをアップロードする（図12）。また、キーの保持期間を24時間以内に設定する。一般的に攻撃者は、キーが早い段階で削除され、AWSからもアクセスできなくなるように、保持期間をできるだけ短く設定しようとする。
8. 以上によって作成されたKMSキーのAmazonリソース名（ARN）を利用し、標的AWSアカウントのS3バケットを暗号化する。このキーは、設定した保持期間の経過後に削除され、顧客やAWS側からアクセスできなくなる。
顧客側では、下記の内容をアイデンティティ・ポリシーに追加することで、AWS KMSのキーマテリアル・インポートや外部キーストアを禁止することが可能です。なお、「kms:ViaService」の条件については、Amazon S3の対象AWSリージョンに応じて書き換える必要があります。
{
"Sid": "DenyKmsOperationsViaS3OnExternalKeys",
"Effect": "Deny",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:KeyOrigin": ["EXTERNAL", "EXTERNAL_KEY_STORE"],
"kms:ViaService": "s3.<region>.amazonaws.com"
}
}
}
本攻撃手法は、被害者のAWSアカウント内で実行される可能性もあります。つまり、攻撃者が十分な権限を取得できれば、被害者の環境内でKMSを作成し、自身のキーマテリアルをインポートできると考えられます。現時点での事例は確認されていませんが、顧客やAWS側から当該キーにアクセスできない点で攻撃者にメリットがあるため、S3に対する将来的な脅威として警戒する必要があります。
第5種攻撃（外部キーストアを利用 - XKS）
KMSの「外部キーストア（XKS：External Key Store）」は、AWSの領域外に暗号化キーを保持したまま、AWS KMSを通して暗号化を行う仕組みです。例えば、オンプレミスのHSM（ハードウェアセキュリティモジュール）や、サードパーティー製のキー管理システムに置かれたキーを利用できます。キーマテリアルをインポートする方式では、AWS側にキーのコピーが残りましたが、XKSの場合、キーが元の環境から出ることは一切なく、AWSからも見えません。この仕組みを実現するためにAWS KMSは、「XKSプロキシ」を介して顧客側の外部キーストアと通信します。XKSプロキシは、AWS KMSから送られた暗号化リクエストを顧客側の外部キーストアに安全に転送し、その結果を戻す「橋渡し役」として動作します。なお、XKSプロキシの設置や管理は、顧客側で行う必要があります。
2024年、ランサムウェア攻撃中にAWS KMSやXKSを悪用し、暗号化を突破して機密データにアクセスする概念実証が公開されました。ただし、今回の攻撃法を成立させるには、IAMロールの認証情報を入手するか、AWSアカウント自体を侵害する必要があります。以降では、XKSを通してAmazon S3を暗号化する攻撃の流れを解説します。
1. 攻撃者は、AWS XKSプロキシの参照実装をクローン（複製）する。AWSは、GitHubでクローン可能なXKSプロキシの参照実装を提供している（概念実証で提示されたものはこちら）。このプロキシは、AWS KMSと外部キーストアの橋渡し役を担う。
2. 下記の設定ファイルを編集する。
aws-kms-xks-proxy/xks-axum/configuration/settings_docker.toml
設定ファイル中のURIプレフィクス（uri_path_prefix）、「AKIA」ではじまるアクセスキーID（sigv4_access_key_id）、シークレット（sigv4_secret_access_key）、キーIDセット（xks_key_id_set）は何でもよいですが、後で確認できるように控えておく必要があります。
[[external_key_stores]]
uri_path_prefix = "/[CENSORED]/secure"
# Access key ID must have between 20 and 30 characters. Valid characters are uppercase A-Z and 2-7
sigv4_access_key_id = “[CENSORED]"
# Secret access key must have between 43 and 64 characters. Valid characters are a-z, A-Z, 0-9, /, +, and =
sigv4_secret_access_key = "[CENSORED]"
xks_key_id_set = ["foo"]
なお、ユーザが「us-east-1」以外のリージョンを使用する場合、設定ファイルの冒頭付近を以下のように修正する必要があります。
# This is a sample xks-proxy configuration file of using SoftHSMv2 with pkcs11-logger disabled in a Docker environment.
[server]
region = "eu-west-1"
3. 攻撃者自身の環境でXKSプロキシをビルド、起動する。
リポジトリの内部には、プロキシをビルドするためのDockerファイルがあります。
docker build -t xks-proxy:latest .
docker run --rm --name xks-proxy -d -p 80:80 xks-proxy:latest
以下により、プロキシが稼働しているかを検証します。
curl http://localhost/ping
これに対して返ってくるレスポンスは、以下のような形式になります。
pong from xks-proxy v3.1.2-unknown
4. AWSは、顧客に対してキーストアのHTTPSリンクを提示するように求める。しかし、攻撃者にとって独自ドメインを作成するのはコストがかかり、身元が露呈するリスクもある。代替策として攻撃者は、トンネリングツール「ngrok」を利用し、ローカルホストを一時的なHTTPSサイトとして外部に公開する。次に、自身のGoogleアカウントを用いてngrokにログインし、ngrokの認証トークンを自身のLinux端末にコピーする（図14）。
5. Dockerが稼働しているローカルホストのポートを対象に、ngrokのトンネル接続を設置する。
ngrok http http://localhost:80
6. 生成されたドメイン名をコピーして保存する。これが、XKSプロキシへのリンクとして機能する。
7. 攻撃者自身のAWSアカウント内でキーストアの設定を追加する。
KMS CMK > Symmetric（対称） > Encrypt & Decrypt（暗号化と復号） > Adv option（高度なオプション） > External Key Store（外部キーストア）
8. キーストアへの接続後、先に取得済みの情報を記入する（設定ファイル内のURIプレフィクスや、ngrokで生成したURLドメインエンドポイントなど - 図15）。
9. 指定されたすべての入力項目を埋める。外部キーIDとして、先に変更していなければ、元の値「foo」を記入する。
10. 先述の手口と同様に、キーポリシーを変更して「全員から読み取り可能」にするか、または、標的S3のアカウントを「プリンシパルAWSアカウント」として追加する。
11. 作成されたキーのARNをコピーし、それを利用して標的AWSアカウントのS3バケットを暗号化する。
顧客側で第4種と第5種の攻撃を防ぐためには、下記のポリシー設定が有効です。
{
"Sid": "DenyKmsOperationsViaS3OnExternalKeys",
"Effect": "Deny",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:KeyOrigin": ["EXTERNAL", "EXTERNAL_KEY_STORE"],
"kms:ViaService": "s3.<region>.amazonaws.com"
}
}
}
この攻撃も、被害者のAWSアカウント内で実行される可能性があります。つまり、攻撃者が十分な権限を取得できれば、被害者の環境内でXKSプロキシを作成できると考えられます。現時点での事例は確認されていませんが、顧客やAWS側から当該キーにアクセスできない点で攻撃者にメリットがあるため、将来的な脅威として警戒する必要があります。
Trend Vision One™を活用したプロアクティブなセキュリティ対策
「Trend Vision One™」は、AIを駆動したエンタープライズ・サイバーセキュリティプラットフォームであり、サイバーリスク露出管理やセキュリティ運用を一元化することで、オンプレミス、ハイブリッド、マルチクラウド環境を網羅した多層かつ堅牢な防衛体制を実現します。
CloudTrailを活用してS3ランサムウェアを検知
S3に対するランサムウェア活動を検知するためには、ログ記録サービス「AWS CloudTrail」のイベントを詳細に可視化することが重要です。CloudTrailのログには、すべてのアクセスや変更、暗号化の操作が記録されるためです。
Trend Vision Oneは、これらのログを活用して不審な挙動や暗号化のパターンを分析し、さまざまなランサムウェアに対応する高度な検知結果をワークベンチ上に提示します。
以降では、ランサムウェア攻撃のさまざまな段階（偵察、権限昇格、暗号化、脅迫状の配備）で観測される検知項目を記載します。
攻撃種別ごとのワークベンチ検知
本セクションで示す検知項目は、各攻撃法に特有の性質を反映したものです。これらの検知結果をもとに企業や組織では、さまざまな攻撃種別を迅速に特定し、的確に対応することが可能となります。
AWS S3：ランサムウェア活動の兆候（第1、4、5種） - S3バケットに対するランサムウェア攻撃と疑われる活動を検知します。この種の活動は、重要なデータの暗号化、消失、改変に加え、業務阻害や金銭的損失を含む重大な影響をもたらす恐れがあります。
AWS S3：カスタム暗号化を利用してS3にオブジェクトをアップロード（第2種）- 標準以外の暗号化設定でS3にアップロードされたオブジェクトを検知します。カスタム暗号化は、セキュリティを意識した運用に基づく場合もありますが、AWSのデフォルト暗号化を回避する試みである可能性もあります。不正な操作であれば、データを難読化され、アクセス制御や監視のプロセスを妨害される恐れがあります。
AWS S3：インポートしたキーで暗号化後、キーマテリアルを削除（第4種）- インポートしたKMSキーを用いてS3のデータを暗号化し、その後、キーマテリアルを削除する動きを検出します。この操作は、データの恒久的な消失に繋がるものであり、S3ランサムウェア攻撃の兆候とみなせます。
AWS S3：大量ダウンロードと削除によるランサムウェア活動の兆候（第3種）- S3オブジェクトを一括ダウンロードしてから削除する動きを検知します。この操作は、データの流出や破壊を意図している可能性があり、ランサムウェア攻撃の兆候とみなせます。
汎用的なワークベンチ検知（攻撃前後の段階）
上に挙げた検知項目は、各攻撃手法と明確に結びつくものですが、ランサムウェア全般に見られる汎用的な検知項目も、攻撃前後の活動を特定する際に役立つと考えられます。
AWS S3：リソースの列挙に成功した可能性 - AWS S3バケットの列挙に成功したと見られる動きを検知します。こうした動きは、情報流出や不正アクセス、アカウント侵害、運用妨害の前兆となっている可能性があります。
AWS S3：リソースの列挙に失敗した可能性 - AWS S3バケットの列挙に失敗したと見られる動きを検知します。成功時と同様、情報流出や不正アクセス、アカウント侵害、運用阻害の前兆となっている可能性があります。
AWS S3：バケットに脅迫状をアップロードした可能性 - AWS S3バケットにアップロードされたファイルを監視し、脅迫状に類似するものを検知します。攻撃者は、被害者に暗号化の事実を伝えて身代金を要求するために、侵害済みバケットに脅迫状を配置することがよくあります。
AWS S3：バケット探索とアクセス検証 - AWSアカウント内でS3バケットを探索し、そこでのアクセス権を確認する動きを検知します。こうした動きは、正規のストレージ管理作業である場合もありますが、データ流出に先立つ偵察活動として、アクセス可能なデータリポジトリを探っている可能性もあります。
AWS S3：バケットの暗号化設定を変更 - S3バケットの暗号化設定が変更されたことを検知します。不適切な変更は、データセキュリティに影響を及ぼし、暗号化の無効化や保護体制の弱体化などによって情報流出のリスクを高めます。データの安全性を堅持する上では、こうした設定変更を監視することが重要です。
AWS S3：バケットのポリシー適用に成功した可能性 - S3バケットのポリシー編集に成功したと見られる動きを検知します。これは、正規ユーザによる操作の場合もありますが、攻撃者による不正行為の可能性もあります。後者の場合、バケットのデータセキュリティやアクセス制御が弱体化し、アクセス権限の改変やデータ整合性の損失に至る恐れがあります。
AWS S3：バケットへのパブリックアクセスを許可 - S3バケットへのパブリックアクセスを許可するポリシー変更を検知します。これは、対象バケットが誰からでもアクセス可能になったことを意味し、不正アクセスや情報流出のリスクを高めるものです。
AWS S3：バケットを削除 - オブジェクト削除やバケット削除のAPI利用を検知します。これは、S3ストレージにおけるオブジェクトの削除、またはバケット自体の削除を示唆します。直接的なデータ損失や運用阻害、不正なリソース削除に繋がる点で、重大な挙動とみなせます。
AWS S3：バケットのサーバアクセス・ログを無効化 - Amazon S3バケットにおけるサーバアクセス・ログの無効化を検知します。これは、セキュリティ上の設定ミスか、または意図的にアクセス履歴を隠す活動と見られます。後者の場合、攻撃者はS3バケットへのアクセス記録を侵害することで、監査証跡やデータ操作の追跡を妨げようとしている可能性があります。
AWS S3：パブリックアクセス制御を無効化 - バケットに対するパブリックアクセスを禁止する機能の停止を検知します。この動きは、バケットを外部に公開し、機密情報の流出を招く可能性があります。
AWS S3：バケットから認証情報とみられるファイルをダウンロード - AWS S3バケットから認証情報とみられるファイルがダウンロードされたことを検知します。この行為は、アカウント侵害や情報流出、金銭的損失、なりすまし、システム障害、信用失墜に繋がる恐れがあります。
IAMに関するワークベンチ検知
ランサムウェア活動に先立って攻撃者は、まずIDやアクセス関連の操作を行い、AWSリソースに対するアクセス権の確保と拡大を目指します。以降の検知項目は、こうしたIAM（Identity and Access Management）に関する不審な操作をとらえたものです。当該操作が不正な意図によるものであれば、S3ランサムウェア攻撃に繋がっている可能性があります。
AWS IAM：ユーザ、ロール、またはグループにポリシーを適用 - AWSのIAMポリシーがユーザ、グループ、またはロールに適用されたことを検知します。これは、攻撃者が権限昇格を行い、AWSアカウントの侵害を試みている可能性を示唆します。
AWS IAM：ポリシー「AdministratorAccess」をロールに適用 - AWS管理のポリシー「AdministratorAccess」がロールに適用されたことを検知します。これは、AWS環境に対する完全管理アクセスが付与されたことを意味します。
AWS IAM：ポリシー「AdministratorAccess」をユーザに適用 - AWS管理のポリシー「AdministratorAccess」がユーザに適用されたことを検知します。これは、AWS環境に対する完全管理アクセスが付与されたことを意味します。
AWS IAM：ポリシー「AdministratorAccess」をグループに適用 - AWS管理のポリシー「AdministratorAccess」がグループに適用されたことを検知します。これは、AWS環境に対する完全管理アクセスが付与されたことを意味します。
AWS IAM：完全管理の特権付きインラインポリシーをグループ向けに作成/更新 - 完全管理の特権付きインラインポリシーがグループ向けに作成/更新されたことを検知します。これは、AWS環境に対する完全管理アクセスが付与されたことを意味します。
AWS IAM：完全管理権限のインラインポリシーをユーザ向けに作成/更新 - 完全管理の特権付きインラインポリシーがユーザ向けに作成/更新されたことを検知します。これは、AWS環境に対する完全管理アクセスが付与されたことを意味します。
AWS IAM：完全管理権限のインラインポリシーをロール向けに作成/更新 - 完全管理の特権付きインラインポリシーがロール向けに作成/更新されたことを検知します。これは、AWS環境に対する完全管理アクセスが付与されたことを意味します。
AWS IAM：ユーザのログインMFA（多要素認証）を無効化 - ユーザに対するMFAが無効化されたことを検知します。この挙動は、AWSユーザが侵害された可能性を示唆します。
AWS IAM：過大な権限を持つ信頼ポリシーをロール向けに作成 - 過大な権限を持つ信頼ポリシーがロール向けに作成されたことを検知します。これは、攻撃者がバックドアを設置した上で、外部のAWSアカウントから当該ロールを引き継ぎ、標的のAWSアカウントをさらに侵害する可能性を示唆します。
AWS IAM：新たなアクセスキーをユーザ向けに作成 - 新たなアクセスキーがIAMユーザ向けに作成されたことを検知します。これは、攻撃者がAWS環境内で持続的なアクセス手段を確保し、当該アクセスキーによって追加の攻撃を仕掛けようとしている可能性を示唆します。
「Trend Vision One™ - Cloud Risk Management」 を活用： S3 ランサムウェアに対するセキュリティ体制をチェック
「Trend Vision One™ - Cloud Risk Management」は、ランサムウェア攻撃で悪用されやすい設定不備を発見するために、S3専用のセキュリティルールを28個以上搭載しています（S3-001～S3-028）。以降に、S3ランサムウェアの対策に直接対応するルールを示します。
- S3-013: Ensures MFA Delete is enabled to prevent unauthorized deletion：不正な削除を防止するため、「MFA Delete（削除操作時に多要素認証を要求する仕組み）」を有効状態に保つ。
- S3-023: Verifies Object Lock configuration to prevent overwrites：上書きを防ぐため、オブジェクトロックの設定を検証する。
- S3-025: Detects use of customer-provided encryption keys (SSE-C), a known ransomware vector：顧客提供による暗号化キー（SSE-C）の利用を検知する。これは、ランサムウェア攻撃の主要な経路として知られている。
- S3-026: Ensures S3 Block Public Access is enabled：S3に対するパブリックアクセスをブロックする機能を有効状態に保つ。
- S3-015: Detect suspicious cross-account access patterns：不審なクロスアカウントのアクセスパターンを検知する。
これらのルールにより、S3ランサムウェアに対するセキュリティ体制をリアルタイムで監視するとともに、設定変更があった際には即時アラートを出すことが可能です。全ルールの一覧や復旧のガイドラインについては、Trend Vision Oneコンソール内の「Cloud Risk Management - Knowledge Base」をご参照ください。
S3をランサムウェア攻撃から保護するためのプロアクティブな戦略
ランサムウェアがクラウド環境を踏み台に複雑に進化していく中、クラウド上のリソースを保護するためには、プロアクティブで状況適応型の戦略が求められます。急速に高度化する脅威に対抗するためには、レガシーな境界防御に依存することなく、クラウドインフラ向けの多層型制御を取り入れることが重要です。現代型のランサムウェア攻撃からクラウド資産を保護する上で有効なベストプラクティスを、以下に示します。
- 最小権限の原則を遵守：KMSの運用や、「s3:PutObject」、「s3:DeleteObject」などの権限については、厳密に定めたロールに対してのみ付与する。IAMの条件設定や多要素認証（MFA）、職務分離を活用し、不正な操作を防止する。
- KMSガバナンスを強化：クロスアカウントでのKMS権限付与を厳格に制限し、未使用のインポート・キーマテリアルやXKS接続を無効化する。また、キー管理者とデータ所有者の役割を明確に分離する。
- オブジェクトの不変性（immutable）を有効化：S3のオブジェクトロックやバージョニングを有効化し、既存データの上書きや暗号化を防ぐとともに、迅速に復旧できる体制を整える。
- 重要なバケットに「MFA Delete」を適用：MFA Deleteを有効化し、オブジェクトのバージョン削除やバージョン変更前に、第2の認証を必ず要求する。これは、ランサムウェアによるデータ削除を防ぐ最後の手立てになる。
- パブリックまたは信頼されていないアクセスをブロック：アカウントとバケットの双方について、「S3 Block Public Access（パブリックアクセスをブロック）」を有効化する。プライベートなアクセスポイントやVPC（仮想プライベートクラウド）のエンドポイントから来たアクセス要求以外は、通さないように設定する。
- 弱い暗号化の回避：「SSE-C」の利用を制限または禁止する。可能であれば、監視された顧客管理キー付きの「SSE-KMS」を利用する。外部提供またはインポートによるキーマテリアルに対しては、定期的なチェックを徹底する。
- 統合監視を通して異常な挙動を早期に検知：CloudTrailやS3データイベント、KMSログを継続的にチェックし、不審な暗号化操作やクロスアカウント活動、一括書き込み/削除を早期に検知する。
- バックアップの分離と保護：別のAWSアカウントによるクロスアカウント・レプリケーションを維持し、独自のCMKと削除保護を設定することで、クリーンな復旧手段を確保する。
- 復旧プロセスの定期点検：バージョン管理されたオブジェクトやレプリカに基づく復旧プロセスを定期的にテストする。IAM/KMSのポリシーを監査し、不要な権限や設定不備がないかを確認する。
- 対応作業を自動化：自動アラートや応答プレイブックの設定により、侵害された認証情報の失効、不審なKMSキーの無効化、影響を受けたリソースの隔離を迅速に行えるようにする。
AWSの公式声明では、以下のように述べられています。
AWS services and infrastructure are operating as expected. AWS helps customers secure their cloud resources through a shared responsibility model. We thoroughly investigate all reports of exposed keys and quickly take any necessary actions, such as applying quarantine policies to minimize risk for affected customers without disrupting their IT environment.
We encourage all customers to follow security, identity, and compliance best practices. Customers who suspect a credential disclosure should begin by consulting the steps outlined in our post. For customers who want to disable AWS KMS Import Key Material, External Key Store, or S3’s SSE-C encryption entirely, we offer organization-level policies that can apply to all or a subset of accounts within the AWS Organization. We also offer resource and identity-level policies that can be applied to specific resources and identities.
For more information on preventing unintended encryption of Amazon S3 objects, please refer to our "Preventing unintended encryption of Amazon S3 objects" AWS Security Blog.
We encourage our customers to contact AWS Support6 for any questions or concerns about the security of their account.
日本語訳：
AWSのサービスとインフラは、期待どおりに稼働しています。AWSは、共有責任モデルを通じてお客様のクラウドリソースの保護を支援します。露出したキーに関するすべての報告を徹底的に調査し、必要に応じて隔離ポリシーを適用するなど、影響を受けたお客様のIT環境を中断させることなく、リスクを最小化するための措置を迅速に実行しています。
すべてのお客様に対し、セキュリティ、アイデンティティ、コンプライアンスに関するベストプラクティスの実践を推奨します。認証情報の漏えいが疑われる場合は、当社の投稿で示した手順をご確認ください。また、AWS KMSの「キーマテリアル・インポート」や「外部キーストア」、「S3 SSE-C暗号化」の完全無効化をご希望のお客様に対しては、組織レベルのポリシーを提供しており、AWS Organizationsの全アカウント、または一部のアカウントに適用可能です。また、リソースレベルやアイデンティティレベルのポリシーも提供しており、個別のリソースやアイデンティティにそれぞれ適用することが可能です。
Amazon S3オブジェクトの意図しない暗号化を防ぐ方法については、AWS Securityブログをご参照ください。
アカウントのセキュリティに関するご質問やご懸念がある場合は、AWSサポートまでお問い合わせください。
参考記事：
Breaking Down S3 Ransomware: Variants, Attack Paths and Trend Vision One™ Defenses
By: Yash Verma
翻訳：清水 浩平（Core Technology Marketing, Trend Micro™ Research）