マルウェアを使用せずにAmazon S3上のデータを暗号化するランサム攻撃
耐久性、可用性、スケーラビリティ、低コストを謳うAmazon S3。S3自体が提供する暗号化機能を悪用し、マルウェアも脆弱性も使用しないランサム攻撃が観測されました。その手口を解説し、対策を考えます。
Amazon S3とは？
「Amazon S3（Amazon Simple Storage Service）」はAWSが提供するオブジェクトストレージサービスであり、特長として次の点が挙げられます。
●スケーラビリティ……容量無制限で利用可能。
●高耐久性・高可用性……複数のAZ（アベイラビリティゾーン）にデータを格納することにより、ストレージの故障などによるデータ損失はほぼ発生しない。また、いつでも安定してデータにアクセス可能。
●コストパフォーマンス……「使った分だけ」の従量課金で利用可能。
●アクセスコントロール……外部への公開・非公開をバケットごとに設定したり、AWS環境にアクセスする「IAMユーザ」単位でアクセス権を指定したりすることが可能。
●暗号化機能の提供……クライアント側の暗号化のほか、下表のとおりサーバ側での暗号化によるデータ保護が可能
| 略称 | 名称 | 概要 |
|---|---|---|
| SSE-S3 | Server-Side Encryption with S3-managed keys | Amazon S3によって管理される暗号化キーを使用する(キー変更不可) |
| SSE-KMS | Server-Side Encryption with AWS KMS keys | Amazon Key Management Systemで保護されている暗号化キーを使用する |
| DSSE-KMS | Dual-layer Server-Side Encryption with AWS KMS keys | SSE-KMSと同じ方法で暗号化キーを使用して、2重層の暗号化を実施する(米政府セキュリティ基準に沿ったもの) |
| SSE-C | Server-Side Encryption with customer-provided keys | ユーザが管理する暗号化キーを使用 |
表：Amazon S3で対応しているサーバ側での暗号化方法
利便性が高くセキュリティ機能も備え、コストパフォーマンスにも優れているという特長から、多くの組織に利用されています。
しかし、このS3上のデータを暗号化して身代金を要求するランサム攻撃が発生しています。しかも攻撃者は、従来のようなランサムウェアによる暗号化ではなく、上記のS3自体が持つ暗号化機能を悪用したということです。この事例は、他の類似のサービスでも起こりうるため注意が必要です。その攻撃手法を次に見ていきます。
①攻撃者：AWSアクセスキーを入手（次章を参照）
②攻撃者：入手したAWSアクセスキーの権限を確認
ここでは、標的のS3に対して「s3:GetObject（S3上のオブジェクトをダウンロード）」メソッドと、「s3:PutObject（S3上にオブジェクトをアップロード）」メソッドを実行できる権限があるかどうかを確認していると見られます。
③攻撃者：SSE-Cの暗号化キーを生成
上記のサーバ側の暗号化のうち、SSE-Cの暗号化キーを生成します。
SSE-Cの特徴として、AWS側では暗号化キーを保管せずユーザ自身が生成・管理・保管を行う点や、コンソールにアクセスできても暗号化キーがなければオブジェクトを容易に復号できない点などがあります。これらの特徴は、正規ユーザにとってはセキュリティ上の利点と言えますが、攻撃者はこれを逆手に取ったと考えられます。
④攻撃者：SSE-Cによるデータ暗号化を標的組織のS3に指示（CLIまたはAPIを使用）
⑤標的組織のS3上でデータが暗号化される
⑥攻撃者：データ削除の期間を設定
S3のObject Lifecycle Management APIを使用して、暗号化されたデータが数日後に削除されるよう設定。標的が身代金の支払いに応じるよう、時間制限を設定して心理的に追い詰めようとしたと推測されます。
⑦攻撃者：ランサムノート（脅迫文）をアップロード
復号に必要な対称暗号キーと引き換えに身代金を要求するランサムノートを、侵害された各ディレクトリにアップロードします。
上記のように、S3の知識と標的のAWSアクセスキーがあれば、従来のようなランサムウェアを用いなくても攻撃が成立してしまうのです。AWSアクセスキーは、過去に侵害されたものか、公開されているものを使用しているようです。
このような被害を避けるためには、そもそもAWSアクセスキーを窃取されないことが重要ですが、意外にも、AWSをはじめとするクラウドサービスのアクセスキーを侵害された事例や、AWSアクセスキーを誤って公開してしまったという例が散見されます。そのいくつかを次に紹介します。
AWSアクセスキーの侵害と悪用事例
AWSやその他のクラウドサービスのアクセスキー侵害としては次のような事例があります（公開情報をもとにトレンドマイクロで整理。Codefingerとの関連が確認できたわけではありません）。
| 公表時期 | 被害組織 | 事例概要 | 原因 |
|---|---|---|---|
| 2024/2/16 | 自動車関連サービス企業 | AWSへの不正アクセスにより、社用車の管理運用を支援するクラウドサービスの顧客の個人情報が流出した可能性 | 開発委託先企業におけるアクセスキーの不適切な取扱いが原因。委託先企業が以前から使用しているAWSアクセスキーが悪用された |
| 2024/2/20 | システム開発企業 | パブリッククラウドへの不正アクセスにより、仮想通貨マイニング目的とみられるサーバインスタンスが不正に作成される | パブリッククラウドのアクセスキーの不正利用 |
| 2024/3/7 | 自動車関連サービス企業 | Amazon S3への不正アクセスにより、カーシェアサービスの顧客の個人情報が削除され、漏洩した可能性 | 同サービスを以前運営していた企業が利用していて無効化していなかったAWSアクセスキーを悪用された |
| 2024/6/3 | マーケティングサービス企業 | クラウドストレージへの不正アクセスによるデータの削除 | クラウドサービスのアクセスキーを悪用された |
| 2024/6/6 | 製造企業 | 同社が提供するオンラインサービスを管理するサーバへの第三者からの不正アクセスにより、顧客の個人情報が漏洩し削除された | アプリケーションの脆弱性を悪用した不正アクセスによりアクセスキーを詐取された |
| 2025/4/18 | エネルギー関連企業 | 海外の複数のIPアドレスから、Amazon S3クラウドストレージにおける特定のIAMユーザのアクセスキーが不正に使用され、当該クラウドストレージ上のバケットに対するアクセス・削除操作が行われ、45件のS3バケットが削除された | AWSアクセスキーの不正利用。 （当該IAMユーザのアクセスキーが不正に使用された原因（流出経路）は不明。） |
また、次のように、開発者がアクセスキーをGitHubのパブリックリポジトリに誤ってプッシュすることで外部に公開してしまい、場合によっては実害が生じた例もあります。
●アクセスキーを含むテストスクリプトを複数の作業環境で使用するために、GitHubのリポジトリにプッシュした。その際、.gitignoreファイル（このファイルに書かれたファイルはコミットの際に無視される）にこのテストスクリプトを記入しておいたが、誤字があったためにプッシュされ、公開されてしまった。
●アクセスキーを.envファイル（環境変数を管理するためのファイル。機密情報などをコードから分離して管理できる）で管理し、その.envファイルを.gitignoreファイルに記入しておいた。しかし.gitignoreファイルを誤って削除したままコミットを行い、.envファイルがパブリックリポジトリにプッシュされてしまった。
●開発者が誤ってアクセスキーをGitHubのパブリックリポジトリにプッシュしてしまった。1時間程度で対処完了したが、その間、第三者がこのアクセスキーを不正に利用し暗号資産のマイニングを行ったため、数万円のAWS利用料金が発生した。
チェックリストで対策を
このようなクラウドサービスへのランサム攻撃の被害に遭わないようにするには、どのような対策が必要でしょうか？
次のチェックリストを参考に、組織の状況を確認し、必要な措置を講じてください。
① 組織内でのAWSアクセスキーの利用有無を把握していますか？
基本的なことですが、組織内で使用されているアクセスキーの棚卸を定期的に行うことをおすすめします。
② AWSアクセスキーを適切に管理できていますか？
アクセスキーに多要素認証を導入し、また定期的なローテーション（新しいアクセスキーを作成し、既存のアクセスキーと置き換え、既存のアクセスキーを無効化し、削除する）を実施することによりリスクを低減できます。ローテーションの頻度は90日以内が推奨されています。
③ Amazon S3のデータ保管時の暗号化について考慮していますか？
S3が提供する複数の暗号化機能のうち、組織にとってより適切なものを選択し、不要であればSSE-Cなどの暗号化機能は制限することを検討しましょう。また、第三者によるデータ暗号化への対策として、データの定期的なバックアップの取得が推奨されます。なお、「AWS Backup」ではクラウド側でのバックアップが可能です。
④ クラウド上の権限を含む、組織内でのクラウドサービスの設定状況とセキュリティリスクの把握・統制はできていますか？
クラウドサービスのアカウントに付与する権限を把握し最小化するなど、設定状況を確認してリスクを把握、低減を図りましょう。
今回はAmazon S3へのランサム攻撃に焦点を当てましたが、前述のように同様のクラウドサービスでも発生する可能性があります。対策のポイントは同じですので、まずは組織の状況を確認し、リスクを低減することで、新たな攻撃に備えることが重要です。
Trend Vision OneのCREM-CRMのライセンスを利用すると、AWSのWell Architectedフレームワーク6つの柱に照らして、組織のAWS環境の設定状況、フレームワークへの対応状況を可視化できます。この例のように、AWSアクセスキーのルール（例：アクセスキーのローテーションを90日以内に行うなど）に沿って評価を行い、その結果（成功、失敗）から、組織で保有しているキーの棚卸を行えます。
② AWSアクセスキーの適切な管理やリスクの低減
AWSアクセスキーを評価するルールに対し、アクセスキーのローテーションや、多要素認証が有効になっているかどうかなどについて「失敗」と評価された高リスクの設定の洗い出しと、是正の検討を支援します。
③ Amazon S3のデータ暗号化方式の検討
S3の暗号化方式で、たとえばSSE-KMS CMK（Customer Managed Key）の利用有無を評価するルールに対して、「失敗（SSE-KMS CMK以外が使用されている）」と評価されたS3バケットの洗い出しと、データ暗号化方式の検討に役立ちます。
④ クラウドサービスの設定状況とセキュリティリスクの把握・低減や、不要・過度な権限の把握と設定変更
Cloud Security Posture Management（CSPM）により次のセキュリティ状態の把握が可能です。
・クラウドの管理アカウントごとのコンプライアンスの概要を参照、管理アカウントやグループのコンプライアンススコアを比較
・クラウド連携したアカウントで管理するクラウド資産のセキュリティ状態をリアルタイムで監視
・AWS Well-Architectedフレームワークの6つの柱に基づいたコンプライアンス対応状況をスコアで確認し、クラウド環境のコンプライアンススコアの変化を時系列で把握
・リージョンのコンプライアンス状況の一元把握と脆弱なリージョンの特定、対応促進
・緊急の対応が必要と考えられる設定、操作ミスを最も重大な障害として参照、対応を促進
Cloud Infrastructure Entitlement Management（CIEM）では、組織におけるクラウドリソースの権限/IAMを把握し、それらに関連する様々なリスク（過剰な権限設定、多要素認証の未導入、重要資産への攻撃経路になりえるリスクイベント、不審な挙動など）を評価・可視化できます（現在開発中です。今後機能など変更になる可能性があります）。
＜関連記事＞
・開催決定！サイバーセキュリティカンファレンス「Trend World Tour 25」～8.1東京、8.29大阪開催～
・CNAPPがなぜ今必要とされているのか？
・クラウドサービスのリスク審査はなぜ疲弊するのか？～実態と業務のヒント～
Security GO新着記事
マルウェアを使用せずにAmazon S3上のデータを暗号化するランサム攻撃
（2025年6月18日）
MITRE ATLASとは何か？：第3回（実行～防御回避）
（2025年6月17日）
アメリカ「CIRCIA（サイバーインシデント報告に関する重要インフラ法）」の概要を理解する
（2025年6月13日）
