AWS ランサムウェアについて知っておくべきこと

ランサムウェアはデータセンターにおいて深刻な問題ですが、クラウドではそれほど大きな問題ではないのではないかと、私は少し懐疑的に考えていました。個人的にインシデントに遭遇したことがなく、理論上の話にすぎないのではないかと思い始めていたのです。しかし、それは少し間違っていました。いえ、完全に間違っていました。思っていた以上に大きな問題であるばかりか、Amazon Web Services (AWS) における攻撃パターンは私の予想とは異なっていました。

AWS re:Inforce カンファレンスで、Kyle Dickinson 氏、Megan O'Neil 氏、Karthik Ram 氏が進行する素晴らしいセッションに参加しました。会場は満員で、数十人が入場を断られるほどでした。この記事は、そのセッションの内容に、AWS ランサムウェアに関する私自身の経験と推奨事項を加えてまとめたものです。誤りや記載漏れがあれば、それは登壇者ではなく私の責任です。

主なポイント

• ランサムウェアの攻撃者は Amazon Web Services (AWS) 環境を狙う傾向を強めており、多くの場合、アイデンティティアクセス、ストレージ設定、サービス全体の可視性における不備を悪用します。
• Amazon S3 バケットは一般的な侵入口であり、脆弱なポリシーや暗号化の適用不足によって、攻撃者が重要なデータを暗号化または削除します。
• クラウドにおける効果的なランサムウェア対策には、アクセス制御、リアルタイム監視、迅速な対応ワークフローを含む多層的な戦略が必要です。
• FireMon は、設定ミスを継続的に監視し、大規模にポリシーを適用し、クラウドベースのランサムウェア脅威へのチームの対応を迅速化する可視性を提供することで、データセキュリティ体制を強化します。

Amazon AWS ランサムウェアは問題なのか

はい。AWS ランサムウェアは、当初考えていたよりも大きな問題であることが判明しました。実際の顧客が被害を受けており、単なる理論上の話ではありません。

Amazon ランサムウェア攻撃はどのように行われるのか

最初の侵入経路については次の項目で扱いますが、Amazon ランサムウェアの攻撃手法には次の4つが考えられます。

• 攻撃者がインスタンスを侵害し (直接的な侵害とは限らず、ユーザーや管理者へのフィッシングによる場合が多い)、マルウェアをインストールしてデータを暗号化し、到達可能な他のインスタンスへ拡散します。これはクラウド固有の要素を含まないため、データセンターにおけるランサムウェアと実質的に変わりません。
• 攻撃者が S3 バケットからデータをコピーし、その後、元のデータを削除します。これはクラウドネイティブな Amazon ランサムウェアとして最も多く見られる手法です。
• 攻撃者が自身の管理下にある KMS キーを使用して S3 のデータを暗号化します。これは複数の要因により、現実というより理論上の手法です。オブジェクトやバケットを後から暗号化するよりも、単に削除する方がはるかに容易だからです。
• 攻撃者が別のストレージサービス上のデータに何らかの操作を加え、データをロックまたは削除します。曖昧な表現にしているのは、この手法が実際には確認されておらず、またそうしたサービスの多くには内部的な制約や組み込みの耐障害性があり、ランサムウェアを成立させにくいためです。

ランサムウェアが最も多く狙うのは AWS S3 バケットであり、攻撃者はデータをコピーした後に削除します。インスタンスやサーバーも、データセンターへの攻撃に使われるものと同じマルウェアの標的となり得ます。実環境ではほとんど確認されていない理論上の攻撃もいくつか存在します。

ただし、新たな Amazon ランサムウェア攻撃が広がりつつあります。ランサムウェア集団は、AWS の顧客提供キーによるサーバー側暗号化 (SSE-C) を利用して、データをその場で暗号化し始めています。この手法により、攻撃者はファイルを持ち出すことも通常のアラートを発生させることもなく、S3 バケット内で直接ファイルを暗号化でき、攻撃者独自の暗号化キーがなければ復旧は不可能です。

攻撃者はどのようにして Amazon Web Services へのランサムウェア攻撃を行うためのアクセス権を得るのか

認証情報の露出です。ほぼ常に静的なアクセスキーですが、侵害されたインスタンスから (メタデータサービス経由で) 取得されたキーの場合もあります。要するに、ほぼすべてのクラウドベースのセキュリティ攻撃と同じ仕組みです。

S3 ランサムウェア攻撃はどのような順序で進むのか

ここでは、注目すべきクラウドネイティブな手口である S3 バケットのランサムウェアのシナリオに焦点を当てます。

• 攻撃者が認証情報を入手します。
• 攻撃者はその認証情報を使って偵察を行い、許可されている API 呼び出しを把握し、アクセス可能なリソースを特定します。
• 攻撃者は、S3 への書き込み権限と、バケットを特定するための一覧表示・読み取りアクセス権があることを発見します。なお、攻撃者に List 権限がなくても、DNS や GitHub などの他の情報源からバケット名を入手できる場合があります。ただし、その可能性はかなり低いと言えます。
• 攻撃者はデータを別の場所にコピーまたは移動します。その移動先は必ずしも AWS 内とは限りません。
• 攻撃者が元のオブジェクトやファイルを削除します。
• 攻撃者が脅迫文をアップロードします (またはメールで送付します)。

最近のキャンペーンでは、攻撃者が S3 オブジェクトライフサイクル管理ポリシーを使用して、暗号化したファイルを7日以内に削除対象としてマークし、身代金支払いへの切迫感を高める手口も始まっています。多くの場合、影響を受けたディレクトリに、ビットコインのウォレットアドレスと固有の被害者 ID を記載した warning.txt ファイルを残します。

これらはすべて自動化されているため、認証情報が露出してから1分以内にプロセスが開始される可能性があります。

Amazon S3 ランサムウェアはどのように検知できるのか

さて、S3 ランサムウェアの防止策まで読み飛ばせない場合は…

攻撃者は通常、ビットコインを送金できるよう連絡先を記した脅迫文を残していきます。親切なことです。しかし、ほとんどの方はその前に問題を把握したいはずです。Amazon S3 ランサムウェアの攻撃手順を追いながら、どの段階で検知できるかを見ていきましょう。

まず、機密性の高いバケットについて、より詳細な監視を有効にする必要があります。この記事はすでに想定より長くなっているため、そうしたバケットを特定・管理する方法の詳細は省き、検討すべき主要な情報源にしぼって説明します。コストの観点から、すべてに対して有効化することは想定しないでください。

• 当然ながら CloudTrail。
• 対象としたいバケットに対する CloudTrail データイベント。これには追加費用がかかります。
• GuardDuty。
• 任意: Security Hub。すべてのアカウントにまたがる GuardDuty やその他の AWS セキュリティサービスを集約するには、これが最適な方法です。
• 場合によっては: S3 サーバーアクセスログ。 CloudTrail データイベントがあれば、必要な情報のほとんどは得られます。ただし、S3 ログは作成自体は無料で (保存費用のみ発生)、CloudTrail が取りこぼす可能性のあるイベント (認証失敗など) をいくつか捕捉します。一方で、確認できるまでに数時間かかるため、進行中のインシデント対応には役立ちません。詳しくはこちらのユーザーガイドをご覧ください。

監視について説明したところで、検知プロセスの7つのステップを見ていきましょう。

1. 露出した認証情報と偵察活動の検知

検知プロセスは、公開または侵害された AWS キーと、あらゆる不審なアクティビティを、自社または第三者が特定するところから始まります。通常は GitHub などの一般的なリポジトリをスキャンすることで発見されます。Amazon Web Servicesはかつて私のキーの1つを発見し、メールで知らせてくれました。お恥ずかしい限りです。

アカウント認証情報に関する偵察の検知がここで機能します。選択肢としては次のようなものがあります。

• 認証情報の窃取など、GuardDuty の検出結果。ただし、約20分の遅延があり、回避手法も存在します
• GetCallerIdentity API 呼び出しは必ずしも悪意あるものではありませんが、本番アカウントで頻繁に見られるべき呼び出しではありません
• GetAccountAuthorizationDetails は、発生するたびにアラームを発報させるべきです
• 単一の IAM エンティティからの複数回の API 呼び出し失敗

2. S3 の列挙の監視

ここからは、攻撃者が S3 に狙いを定めていることを示す AWS ランサムウェアの検知に焦点を当てます。ノイズが多いため、これらの段階での早期検知は難しいとお気づきかもしれません。しかし、CI/CD で管理され人による操作が限定されている本番アカウントなどでは、より実用的になります。これを機に、クラウドネイティブなパターンの活用を進める動機になるかもしれません。

Discovery イベントに関するGuardDuty の S3 検出結果は、アカウントや組織の構成によっては、GuardDuty を有効にするだけでなく、別途有効化する必要があります。S3 サービスにおける、失敗した Read および List の管理イベントとデータイベントでフィルタリングしてください。攻撃者の偵察行為を捕捉できる可能性があります。SIEM で実施することもできますが、これらについては CloudWatch メトリクスフィルターを構築するのも簡単です。

3. オブジェクトの読み取りとコピーの監視

ここでは、継続的に監視することで、攻撃者がオブジェクトを読み取ってコピーを作成しているかどうかを確認できます。攻撃者が各オブジェクトを読み取り（コピー）した後に削除する場合、この動きは次のフェーズと重なることがあります。

4. 大量削除と身代金要求メモの設置を検知する

ここが「まずい」段階です。攻撃者は単に周囲を調べているのではなく、攻撃を実行し、コピーしたデータを削除しています。GuardDuty の S3 に関する情報漏洩／影響の検出結果が作動します。作動までに少なくとも20分かかり、オブジェクト数によっては遅れた兆候となる点にご留意ください。CloudTrail Insights を利用している場合は、データ移動に使用された多数の Write イベントについてアラートが発生します。

多数の削除呼び出しを対象とした独自の検知を構築することも可能です。環境や通常のアクティビティパターンによっては、しきい値を低く設定でき、GuardDuty より早く作動させられます。SIEM や CloudWatch Metrics Filters が有効な選択肢です。

5. SSE-C の悪用（サイレント暗号化）を特定する

PutObject などの API 呼び出しで SSE-C ヘッダーが突然適用されていないか監視してください。これはデータが攻撃者の鍵で暗号化されている兆候です。AWS は操作の HMAC ハッシュのみを記録するため、事前の監視なしに通常のフォレンジックによる復旧を行うことはできません。

6. カナリアバケットと KMS 検知の活用

成熟した組織であれば、アカウントにカナリアバケットやカナリアオブジェクトを配置し、それらのバケットに対する操作を検知してアラートを出すことができます。攻撃パターンとしては一般的ではありませんが、アカウント外からの KMS キーの使用について関係者に通知することも可能です。

7. エスカレーションとインシデント対応

この段階で攻撃を検知した場合、すでに侵害されています。対応すべき時です。法執行機関に連絡し、AWS カスタマーインシデントレスポンスチームに支援を依頼してください。

AWS ランサムウェア対策：企業を守るには

AWS へのランサムウェア攻撃を成功させるために、攻撃者には次の3つの条件が必要です。

• 認証情報へのアクセス
• S3 での読み取りおよび書き込みの権限
• 復旧不可能な形でオブジェクトを削除できること

ランサムウェアを防止するための第一の層は、IAM を厳格に制限し、そのうえでレジリエンス確保のために AWS の組み込みツールを使用することです。口で言うのは簡単ですが実行は困難です。ここでは S3 に焦点を当てたチェックリストを示します。一般的な衛生管理やコントロールの大半は省略します。

• 静的アクセスキーを伴う IAM ユーザーは一切許可しないでください。それが不可能な場合は、必ずツールを使用して S3 の削除権限を持つユーザーを特定してください。
• SSO／フェデレーションユーザーには MFA を必須としてください。常に、例外なく。
• 管理者が削除操作を実行する必要がある場合は、別のIAM ロールに昇格させてください。読み取り権限と削除権限を完全に別々のロールに分離することもできます。
• インスタンスが S3 へのアクセスを必要とする場合は、必要最小限のリソースに対する必要最小限の API 呼び出しに権限を可能な限り厳密に絞り込んでください。
• どうしても必要な場合を除き、SSE-C は無効にしてください。これにより、復旧手段のないままデータへのアクセスを失わせるサイレント暗号化攻撃を防ぎやすくなります。
• バケットへのアクセスには VPC エンドポイントを使用し、送信元 VPC からの削除のみを許可するリソースポリシーを重ねて適用してください。これにより、攻撃者はその VPC の外部で認証情報を使用できなくなります。
• バージョニング、AWS Backup、バケットレプリケーションのいずれか、または複数を有効にしてください。これらにより、データへのアクセスを失わないようにできます。ただし、IAM ポリシーを大きく誤り、攻撃者に自由を与えてしまった場合は別です。一部の機能はバケット作成時に有効化する必要があるため、実現には移行作業が必要になる場合があります。

ここで Block Public Access に触れていない点にお気づきかと思います。優れた機能ですが、公開バケットを必要とする組織も多く、大規模に実装するのは困難です。また、漏洩した認証情報を利用した攻撃には効果がありません。

これらはいずれも手間とコストを伴うため、まずは本当に重要なバケットに絞って取り組むことをお勧めします。特に大規模な環境を運用している場合には、さらに高度な戦略もありますが、本記事には収まりません。ご関心があればご連絡ください。

Re:Inforce のセッションで S3 ランサムウェアについて新たに得た知見

S3 ランサムウェアがこれほど一般的だとは知りませんでした。また、コピー後に削除する手法が好まれていることも知りませんでした。KMS 暗号化が使われていると考えていましたが、それが理論上の話にとどまり、まれである理由は十分に納得できます。検知手段や防御策については理解していましたが、AWS の登壇者はそれらを非常に明確かつ実用的な形でまとめていました。期待を大きく上回る講演でした。

FireMon による S3 ランサムウェア対策の支援内容

当社では、Just in Time 権限に対応した新しい IAM 製品をベータ版で提供しており、まもなくリリース予定です。また、DisruptOps ではポスチャチェックと脅威検知機能を提供し、リスクのあるバケットを特定して、ランサムウェア攻撃などの悪意ある活動を通知します。これらについてご相談されたい場合、また本記事で触れた AWS の各オプションに関する一般的な助言をご希望の場合も、ご連絡ください。

デモを予約することで、FireMon が AWS ランサムウェアから企業を保護する方法をご確認いただけます。