AWS 環境における暗号通貨採掘悪用に備える

記事タイトルとURLをコピーする

営業部 佐竹です。
本日は、AWS 上のリソースを悪用され Crypto Currency (仮想通貨/暗号通貨)の採掘をされてしまわないように、利用者側にどのような対策がとれるのか、また実際に採掘を行われてしまった場合の対応について記載します。

はじめに

AWS 環境上で Crypto Currency (仮想通貨/暗号通貨)を知らない間に採掘され、思いがけない利用料を請求されるようなトラブルが増えています。

詳細は記載できませんが、サーバーワークス社内用の AWS アカウント上でもこのようなトラブルが確認できています。

まずはこれらの悪用行為が増えている背景を知る必要がありますので、簡単にご紹介します。

なお、本ブログでは Crypto Currency の日本語訳を以後「暗号通貨」で統一して記載します。

キーワード

暗号通貨の採掘悪用で知っておくべきポイントは、以下の3つだけです。

  1. 暗号通貨とその種類
  2. 採掘(マイニング)
  3. ウォレットへの送金

この3点だけ理解しておけば、おおよそ攻撃される背景が理解可能です。

暗号通貨とその種類

これは代表的な2つ「ビットコイン(Bitcoin)」と「イーサリアム(Ethereum)」をまずは覚えてください。特徴としては、昔も今も人気が高いのがビットコインで、最近特に人気が高いのがイーサリアムです。

採掘(マイニング)

採掘とは、その名の通り暗号通貨を掘り出すことです。少しわかりにくいかもしれませんが、概念としては「金(Gold)を土の中から掘り起こして見つけ出す」というような行為です。これをコンピュータに搭載された CPU や GPU を利用して行います。

ざっくりと「CPU、GPU を使って暗号通貨が掘り出せる」とご理解ください。実際には「演算の協力金」でもあるのですが、これをマイニングと言い、掘り起こす個人や業者をマイナーと言います。

なお、マイニングに最も重要なのは電気代になります。CPU と GPU をブン回して採掘を行うためには電気代をどうするのかが一番の問題になります。日本では電気代が高いことからマイニングはすればするほど赤字であると言われていました。

ウォレットへの送金

暗号通貨を保存するには専用のウォレットが必要です。電子的な財布と考えてください。ウォレットは誰でも簡単に作れます。

マイニングされた暗号通貨を利用したり、「支払いに利用=譲渡」したりするにはウォレットが必須です。採掘された暗号通貨は、最終的にウォレットに入れられて保存されます。

採掘悪用の概略図

暗号通貨の採掘悪用

採掘悪用の概略図を用意しました。

EC2 インスタンスに何者かが侵入し、インスタンスのリソースを悪用して暗号通貨を採掘する。その後、ウォレットへ暗号通貨を送金して持ち出すという形になります。

※Outbound の通信にはマイニングプールへの通信が行われる場合がありますが、今回は割愛しています

悪用行為が増えている背景

暗号通貨の値上がりについて触れます。

ビットコインの高騰

ビットコインの5年間チャート(日本円)

ビットコインは、2017年末に200万円を越えたあたりで採掘の人気が出ました。ただ日本では電気代が高いため、基本的には採掘に使われる電気代とつり合いが取れないと言われていました。

しかし、他人の AWS アカウントであれば話は別です。先の図の通り、他人の AWS アカウントのリソースにタダ乗りし、採掘した暗号通貨を持ち出せば電気代は AWS アカウント保持者に肩代わりさせられます

この時にも AWS アカウントに不正に侵入し、採掘を行われるというトラブルがあったことを記憶しています。

イーサリアムの台頭

悪用行為が増えている背景には、Crypto Currency の中でも最近はイーサリアム(Ethereum)の価格が高騰していることが上げられます。

イーサリアムの5年間チャート(日本円)

主に GPU を利用して効率的に採掘が可能なイーサリアムは、日本等の先進国の電気代でも利益が上げられるようになってしまいました。それにより、イーサリアムの価格高騰と共に GPU の買い占めが行われてしまい、そこにコロナによる工場の操業停止や半導体不足が追い打ちをかけました。これらの事情により GPU の需要は高止まりしています。これはつまり、イーサリアムの採掘がそれだけ金銭的に魅力ということになります。

最近は EC2 インスタンスに機械学習用のリソースとして、GPU を多く積載したインスタンス(P3/G4)も登場しており、これらを悪用することでイーサリアムを効率的に採掘が可能となっています。

暗号通貨採掘悪用の攻撃経路

暗号通貨を悪用して採掘するための攻撃経路は、以下の方法が考えられます。

  1. EC2 インスタンスに侵入し、侵入したインスタンス上で採掘を行う
  2. EC2 インスタンスに侵入し、侵入したインスタンスの IAM Role を用いて悪意のある AMI から採掘用インスタンスを大量に横展開して採掘を行う
  3. 漏洩した IAM Credentials を利用し、悪意のある AMI から採掘用インスタンスを大量に横展開して採掘を行う

攻撃は、凡そこの3つのいずれかです。

なお、最近は SageMaker 用のインスタンスが悪用されるケースもあり、EC2 インスタンスだけが乗っ取られるわけではありません。場合によっては、GPU 搭載の WorkSpaces が悪用される可能性もあります。

以下に図を示します。

EC2 インスタンスに侵入し、侵入したインスタンス上で採掘を行う

先にご紹介した構成図の通りの悪用です。

暗号通貨の採掘悪用

侵入したインスタンスがリソースリッチであるほど採掘の効果が高くなります。反対に、スペックの低いインスタンスに侵入した場合は採掘の効果が低くなるため、悪用側としては採掘効率が著しく低下します。また、AWS リソースが増やされてしまうわけではないため、コストとしての被害も大きくありません。

IAM Role を悪用し、悪意のある AMI から採掘用インスタンスを大量に横展開して採掘を行う

IAM Role にて採掘用インスタンスを大量に横展開された場合

図のように、侵入したインスタンスの IAM Role が悪用されることで採掘用のインスタンスが大量に作成されてしまう場合があります。大量に作成されないものの、巨大な1つのインスタンスを構築される場合もあります。

このような場合は、既に採掘用に最適化された Public 公開の AMI からインスタンスが Launch されることとなり、AWS リソースが増加し、コストに甚大な被害を及ぼすことがあります。

漏洩した IAM Credentials を悪用し、採掘用インスタンスを大量に横展開して採掘を行う

IAM Credentials にて採掘用インスタンスを大量に横展開された場合

先ほどと同様に、漏洩した IAM Credentials が悪用された場合にも、採掘用のインスタンスが大量に作成されてしまう場合があります。この場合も AWS リソースが増加し、コストに甚大な被害を及ぼすことがあります。

暗号通貨採掘悪用の防御手段

防御手段を以下の4つに大別します。

  1. 侵入させない
  2. 適切な権限を付与する
  3. 採掘を即座に検知する
  4. 検知された場合のオペレーションを事前に確立する

それぞれについて説明します。

侵入させない

EC2 インスタンスへの直接の侵入経路を以下の2つに大別します。

  1. SSH や RDP が意図せず解放されてしまいその経路からアクセスされる
  2. 脆弱性を利用される

SSH や RDP が意図せず解放されてしまいその経路からアクセスされる

1つ目は、SSH や RDP のポートが不用意に全世界に開放されていることで、そこから侵入されてしまう場合があげられます。これらに対処するには、以下の対策を行ってください。

  • Public Subnet に EC2 インスタンスを配置しない
  • Security Group を 0.0.0.0/0 で解放しない
  • Session Manager を利用する

Security Group については「Security Hub」や「Trusted Advisor」によって予め検知可能ですので、これらの定期的な棚卸運用が有効となります。また Systems Manager の Session Manager を利用することで、SSH のポートが解放されておらずとも対象のインスタンスに SSH 接続が可能となり、セキュアに OS アクセスが可能となります。

docs.aws.amazon.com

SSM を利用して RDP 接続を行う場合はポートフォワーディングが有効です。SSM ポートフォワーディングについては以下のブログをご参考ください。

blog.serverworks.co.jp

脆弱性を利用される

2つ目は、Log4j2 に代表されるような重大な脆弱性を利用されることで発生します。これらの対処は以下の2つです。

  • Public Subnet に EC2 インスタンスを配置しない
  • セキュリティパッチを定期的に正しく適用する

AWS のベストプラクティスとしては、EC2 インスタンスを Public Subnet に配置するべきではなく、ALB を前段に置いて AWS WAF を挟む構成としてください。今回、Log4j2 の脆弱性緩和には以下の通り AWS WAF による防御が有効でした。

blog.serverworks.co.jp

セキュリティパッチについては Systems Manager の Run Command を利用した定期的なパッチ適用が可能で、それに特化した機能「Systems Manager Patch Manager」が有効活用可能です。

ソフトウェアベンダーから提供されるパッチについては、ベンダー協力のもと対応が必要となります。特に重大な脆弱性が発表された場合には、すぐにベンダーに直接問い合わせが可能となるよう、その経路を予め準備しておく必要があります。

適切な権限を付与する

IAM Role や IAM ユーザ に付与されている IAM ポリシーを悪用されるような場合に備え、以下の点で権限が適切か確認ください。

  • EC2 インスタンスにアタッチされている IAM Role のポリシーに EC2FullAccesss 等の強力かつ構築が可能な権限が付与されていないか確認する
  • IAM ユーザにアタッチされているポリシーに EC2FullAccesss 等の強力かつ構築が可能な権限が付与されていないか確認する
  • EC2 インスタンスのメタデータサービスが IMDSv2 となっているか確認する

強力かつ構築が可能な権限が付与されていないか確認する

侵入されてしまった EC2 インスタンスに付与されている IAM Role を悪用されてしまう場合、その Role にアタッチされた各ポリシーの権限が強すぎることが二次被害を拡大させる原因になります。またこれは IAM ユーザの Credentials が漏洩する場合も同様です。

なお、IAM ユーザの Credentials はセキュリティリスクが高いため、可能であれば払い出されない方が良いでしょう。加えて Credentials は定期的なローテーションが推奨されています。IAM については合わせて MFA の設定が推奨されます。

aws.amazon.com

組織レベルで MFA を必須とする場合は、Organizations の SCP による設定が有効です。

blog.serverworks.co.jp

また、既存の IAM Role もしくはユーザの権限を最適化するには「IAM Access Analyzer によるポリシーの自動生成」機能が有効です。以下のブログをご参考ください。

blog.serverworks.co.jp

メタデータサービスが IMDSv2 となっているか確認する

そして、3つ目のインスタンスメタデータサービスですが、IMDSv2 に切り替えが推奨されます。IMDSv2 については以下のブログをご参考ください。

blog.serverworks.co.jp

IMDSv1 は実際にその脆弱性を突かれた攻撃を受けたことで、IMDSv2 が開発&リリースされた経緯があります。IMDSv2 にすることで、EC2 インスタンスにアタッチされている IAM Role の悪用を予め回避ください。特に CLB 配下の EC2 インスタンスで本脆弱性を突かれてしまうことが多い状況です。ただし、IMDSv2 に対応していないアプリケーションも存在しており、切り替えには動作確認を前もって行ってください。

その他の手段として、予め Launch に利用してもよい AMI を定めておき、コンプライアンスに違反しているインスタンスを強制的に Terminate と通知を行うような Config Rules も設計が可能です。このような設計であれば、意図しない EC2 インスタンスが大量に展開されるような状況を未然に防げます。この設定には Managed Rule の approved-amis-by-id を利用します。

docs.aws.amazon.com

採掘を即座に検知する

検知については、以下の4つのパターンが考えられます。

  1. GuardDuty を活用する
  2. CPU 監視を行う
  3. RunInstances を検知する
  4. AWS 利用料を確認する

GuardDuty を活用する

docs.aws.amazon.com

GuardDuty の EC2 の検知項目には CryptoCurrency:EC2/BitcoinTool.BCryptoCurrency:EC2/BitcoinTool.B!DNS が用意されており、これにより EC2 インスタンスが採掘に悪用された場合に検知が可能です。

CryptoCurrency:EC2/BitcoinTool.B

実際に GuardDuty で CryptoCurrency:EC2/BitcoinTool.B が検知された場合、上の通りにコンソールへ表示されます。Severity は「High」になります。

この機能は、採掘した暗号通貨を送金する場合に、EC2 インスタンスから外部のウォレット(or マイニングプール)への通信が発生するため、この通信をフックして検知するものです。EC2 インスタンス以外ではフックされない点は懸念として残りますが、GuardDuty の検知は暗号通貨の悪用検知に非常に有効です。

なお、GuardDuty は有効化しただけでは通知が行われませんため、有効化と通知設定は合わせて行ってください。

Organizations(組織)全てで GuardDuty を有効化し、統合を行うには以下のブログを参考ください。

blog.serverworks.co.jp

メール通知については以下のブログを参考ください。

blog.serverworks.co.jp

通知については AWS Chatbot にも対応しておりますので、EventBridge の設定で Slack へと直接連携が可能です。以下は Security Hub での Slack 通知設定例ですが、合わせて参考ください。

blog.serverworks.co.jp

CPU 監視を行う

暗号通貨の採掘を最大限行うために、侵入された EC2 インスタンスの CPU や GPU は最大限消費され尽くします。つまり、CPU (場合によっては GPU) が 100% に張り付くことになります。

そのため、EC2 インスタンス内にて CPU/GPU 使用率の監視を行うことで、これに気付ける可能性があります。

これらの監視には CloudWatch と SNS による通知を有効活用ください。

docs.aws.amazon.com

RunInstances を検知する

侵入された EC2 インスタンスで採掘が行われる場合は RunInstances (インスタンスを Launch する API)が実行されることはありませんが、悪意のある AMI を用いて大量に EC2 インスタンスが展開されるような場合があります。

また、悪用されるリージョンは東京ではなく、海外のリージョンが悪用されることが多いため、このような場合には「普段東京リージョンのリソースしか確認していない」という日本のエンドユーザはなかなかこの攻撃に気付けない場合があります。

このような悪用に気付くために、特にメインで活用している(日本のエンドユーザであれば東京リージョンや大阪リージョン)以外のリージョンで RunInstances が行われた場合に通知する仕組みが有効です。これらの設定と通知には、EventBridge を活用が可能です。

docs.aws.amazon.com

付け加えると、この設定に加えて CloudTrail の有効化も必須となります。RunInstances をリアルタイムで検知できずとも、追って調査を行う必要が出る場合があります。CloudTrail は Organizations の機能で全 AWS アカウントに強制的に有効化できるため、有効活用ください。

blog.serverworks.co.jp

AWS 利用料を確認する

意図せず EC2 インスタンスが大量に展開されたような場合は、AWS 利用料が突然跳ね上がります。AWS 利用料は反映までに少し時間がかかるため即効性は低いのですが、最終的には利用料に反映されるため、利用料で確実に気付けることになります。

ただし、1ヶ月に一度しか利用料を確認しないというオペレーションでは、1ヶ月間悪用を許すことになってしまい兼ねません。可能な限り早く AWS 利用料の意図しない増加に気付くためには、以下の2つの機能が有効です。

  • AWS Cost Anomaly Detection
  • AWS Budgets
AWS Cost Anomaly Detection

AWS Cost Anomaly Detection は、突発的な利用料の増加を検知するサービスです。弊社ではリリース当初から社内検証環境で運用を行っており、コスト削減に一役買っています。

blog.serverworks.co.jp

注意点としては、全サービスが対象ではないということです。一部のサービスは突発的な利用料の増加として検知されてない点にご留意ください。

AWS Budgets

AWS Budgets は名前の通り、予算を設定して通知を行う予算管理サービスです。

Budgets で予算を定めておくことで、想定よりも早い予算の消化(つまり、AWS 利用料の増加)に気付くことが可能です。

以下のブログも併せてご参考ください。

blog.serverworks.co.jp

検知された場合のオペレーションを事前に確立する

ここまでにご紹介した設定を行ったとして、実際に AWS アカウント内で暗号通貨の採掘悪用が発覚した場合にはどのように対処をすべきなのか、予め決めておく必要があります。対応を先に決めておくことで、判断から対応までの時間を短くし、被害を最小限に留めることを目的とします。

以下に具体的な対応方法の例を記載します。

侵入されたインスタンス上で採掘を行われている場合

侵入されたインスタンスを直ちに停止します。もしそれができない場合は、Security Group の Outbound を閉じることで、ウォレットへの送金を食い止めることが可能です。SSH/RDP が可能な場合は、採掘に利用されているプロセスを Kill します。

侵入される前のクリーンな環境に戻す場合は、日々取得している AMI から再構築を行うのがベターです。ただし、長期間侵入に気付かなかったような場合に、バックアップ AMI が世代管理の都合クリーンなものが残存していない場合もあるでしょう。復旧に利用することが可能な AMI がない場合は、新規に EC2 インスタンスを構築し再セットアップが必要になります。このような障害に備え、バックアップ AMI の世代数は適切に設定ください。具体的には、30日間や60日間などの設定が上げられます。

インスタンスの復旧後は再発防止のために侵入経路を特定し、その穴を塞ぐ必要があります。脆弱性を悪用された場合は、修正パッチの適用や AWS WAF 等を用いてブロックを行ってください。

採掘用インスタンスを大量に横展開された場合

EC2 インスタンスが構築されているリージョンと、悪意のある AMI から構築されたインスタンスを特定し、それら全てのインスタンスを直ちに停止、もしくは削除(Terminate)します。

先ほどと同様に侵入経路を特定し、その穴を塞いでください。この調査には CloudTrail の履歴を有効活用できます。このためにも、予め CloudTrail は必ず有効化しておきます。

この場合の悪用では、IAM Role か IAM ユーザの持つ権限が悪用されていることが大半です。悪用された IAM リソースを特定し、不要な権限をはく奪してください。Credentials が悪用された場合は直ちにその Credentials を無効化し、ローテーション後に削除してください。

強力な権限が悪用された場合、IAM ユーザのパスワード変更や MFA の無効化がされる場合があります。これらの攻撃を合わせて受けていないか、CloudTrail の履歴から念入りに調査ください。

まとめ

本ブログでは、AWS リソースの悪用による「暗号通貨の採掘」への対策と、実際に悪用をされてしまった場合の対応について記載しました。

最後に、以下のテーブルにてサマリーを記載します。

手段 有効なサービス
1. 侵入させない Security Hub
Trusted Advisor
AWS WAF
Security Group
Systems Manager Session Manager
Systems Manager Patch Manager
2. 適切な権限を付与する IAM Role
IAM Policy
MFA
IAM Access Analyzer
IMDSv2 (EC2)
Config Rules
3. 採掘を即座に検知する GuardDuty
CloudWatch
EventBridge
AWS Cost Anomaly Detection
AWS Budgets
SNS or Chatbot
4. 検知された場合のオペレーションを事前に確立する EC2 (Stop/Terminate)
AWS WAF
Security Group
CloudTrail

最後に、改めて本攻撃の恐ろしさについて記載します。この攻撃で最も恐ろしいのは、IAM Role もしくは ユーザの権限が悪用されて EC2 インスタンスが大量に構築された場合です。

例えば p3.16xlarge がアメリカのリージョンに1台構築されたとします。このインスタンスの利用料は、$24.48/h という非常に高額なものです。30日間気付かず放置されると、$17,625.6 が請求されてしまいます。

1台であればまだ良いでしょう。これが10台となると、被害は10倍です。このような悪用がされた場合に AWS に返金を要請したとしても、対応してくれないこともあるでしょう。その場合は泣き寝入りするしかありません。このような甚大なコストの被害を出す前に、できる限りの対策を啓蒙したいと考え本ブログを記載させて頂きました。

これで本記事は終わりとなります。何かのお役に立てれば幸いです。

それでは、またお会いしましょう。

佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ

営業部カスタマーサクセス課所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 Japan AWS Partner Ambassador/2020-2022 APN ALL AWS Certifications Engineer。AWSのコスト削減、最適化を得意としています。