【AWS re:Invent 2022】Amazon S3 のデータを狙うランサムウェア事件の実態とは？

re:Invent 2022 に現地参加しています、CI 事業部セキュリティセクションの村上です。
2日目に聴講した Chalk Talk “The anatomy of a ransomware event targeting data residing in Amazon S3” (SEC402-R) についてレポートします。

Amazon S3 でランサムウェア被害はあまり聞かない気がするので、実態はどのようなものなのかと気になっていたセッションです。
どのような攻撃が行なわれ、どのような対策が可能なのか、実際に AWS の顧客にあった例に基づき紹介がありました。

Chalk Talk とは何ぞや？という方は、土田さんの記事をご覧ください。

概要

Ransomware events can cost governments, nonprofits, and businesses billions of dollars and interrupt operations. Early detection and automated responses are important steps that can limit your organization’s exposure. In this chalk talk, walk through the anatomy of a ransomware event that targets data residing in Amazon S3 and hear detailed best practices for detection, response, recovery, and protection.
ランサムウェアは、政府、非営利団体、企業などに何十億ドルもの損害を与え、業務を中断させる可能性があります。早期発見と自動対応は、組織の被害を最小限に抑えることができる重要なステップです。このチョークトークでは、Amazon S3 に保存されているデータを標的としたランサムウェアイベントの構造を学び、検出、対応、回復、および保護のための詳細なベストプラクティスをお聞きいただけます。

スピーカー

• Kyle Dickinson, Sr. TDIR Solution Architect
• Megan O’Neil, Principal Security Specialist SA

内容

さて、ランサムウェアが初めて現れたのは何年でしょうか？
というクイズから始まりました。

答えは1989年です。随分古くからありますね…。

最初はランサムウェアの簡単な説明から。
データを暗号化または破壊して利用不可にしてしまい、元に戻すのと引き換えに被害者に身代金を要求し脅迫するのが特徴です。

S3 をターゲットにしたランサムウェア被害に遭った AWS 顧客で見られたこととして、以下が挙げられていました。

• CloudWatch メトリクスで、S3 のオブジェクト数が減少した
• ランサムノート (身代金を要求する文書) が S3 に配置されていた
• GuardDuty で IAM / S3 の findings を検出
• オブジェクトが顧客保有でない KMS キーで暗号化されていた

オブジェクト数が減少した例では、データは盗まれてしまったのでしょうか…？
後ほど補足があります。

攻撃者の S3 へのアクセス方法は、以下などが考えられます。

• (漏えいした) 一時クレデンシャル
• (漏えいした) IAM ユーザーのクレデンシャル
• パッチされておらず脆弱性のあるアプリ

クレデンシャル漏えいを検知する方法としては、上図にあるように GuardDuty や、CloudTrail、AWS からの通知などがあります。

S3 のランサムウェア被害を検知する方法としては、下記のようなものがあります。

• CloudWatch メトリクスでデータの削除やバケットの削除を検出する
• S3 のオブジェクトの暗号化状況を確認する
• ランサムノートの配置状況を確認する
• CloudTrail で破壊的な API コールがないか確認する
• S3 サーバーアクセスログを確認する

上記で横線より下にある 2つのオブジェクトレベルの API コールは、サーバーアクセスログまたは CloudTrail のデータイベント記録を有効化しないと記録されません。

データイベントを記録できていなかったとしても、間接的にデータの漏えいを推測する方法がないわけではありません。
Billing です。
Transfer out が多い場合は漏えいの可能性も考えられます。

上図は、攻撃の流れを示しています。

S3 をターゲットにしたランサムウェア被害では、暗号化されるのではなくデータが削除されることが多いそうです。
暗号化するとログに残るなどして、検知されやすいのに対し、S3 からのデータ削除は数秒で完了し、前述のようにログに残らない場合もあるので、検知されにくく簡単だからだそうです。
攻撃者は、全データを削除前にダウンロードしておかなくても、被害者を脅迫できてしまいます。

最後に、被害に遭ってしまった時の対応です。

身代金は払わないでください。

GitHub にて、AWS の対応ガイドラインが公開されています。
https://github.com/aws-samples/aws-customer-playbook-framework

続いて、漏えいしたクレデンシャルの対応方法です。

いきなり無効化してしまうとアプリが動かなくなるなども考えられるため、まずは新しいクレデンシャルを作って、アプリのクレデンシャルを置き換えてから、旧クレデンシャルを無効化・削除する方法が紹介されていました。
(常にアプリ稼働を優先とは限らないので、要件によりけりかと思います。)
いずれにしても、クレデンシャル漏えい時の対応手順を用意しておく必要があります。

また、クレデンシャルを IAM Role で代用できるのであれば、移行を計画することを推奨します。
ポリシーでクレデンシャルへのアクセスを制限する (IP アドレスや利用時間など) ことで、不正アクセスのリスクを減らすこともできます。

最後に、 S3 のデータの復旧です。
バックアップや旧バージョンから、データを復元しましょう。

削除されてしまったデータを復元することは、AWS にはできません。
データをバックアップするのはユーザーの責任です。

データ保護について。
保護の程度はデータの重要度によって考えましょう。人間のデータを犬猫のデータと同様に保護しますか？といった問いかけがあり、「猫なら… (同様に保護する)」という参加者回答が笑いを誘っていました。

S3 のデータは消すのが一瞬 (数秒) なので、Detect より Protect を推奨とのことでした。
被害を検知した頃には既にデータがなくなっている可能性大のため、保護設定やバックアップを事前に行なう必要があります。

所感

ランサムウェア = 暗号化 のイメージだったため、S3 のデータを暗号化して脅迫するのは逆に面倒では？と思っていたのですが、単純に削除して身代金を要求すると聞いて起こりそうだなと納得がいきました。

ランサムウェアによるものであっても、誤操作であっても、「削除されてしまったデータを復元することは、AWS にはできない」という点は変わらないので、事前の保護設定やバックアップは重要です。