オペレーション CloudKeys: 露出した AWS の IAM キーを悪用するクリプトマイニング オペレーションの追跡

  • 288
    people reacted
  • 0
  • 5 min. read

By and

Category: Cloud

Tags: , , , , , ,

A pictorial representation of exposed IAM keys. A server sits among clouds and is surrounded by icons of components often connected to the cloud: phone, password, laptop, documents among others.

This post is also available in: English (英語)

概要

Unit 42 のリサーチャーは、公開 GitHub リポジトリー内に露出 (expose) している ID およびアクセス管理 (IAM) クレデンシャルを自動的にターゲットにして実行するアクティブなキャンペーンを特定し、これを EleKtra-Leak と名付けました。AWS は、特別な隔離ポリシーを適用することで、人気ソースコード リポジトリーにおけるクレデンシャル (認証情報) 漏えいの脅威の多くを検出し、自動修復します。しかしながらこの AWS による自動保護を手動で削除することで、侵害されたクレデンシャルがなんらかの方法で取得された場合に攻撃者が実行するであろうアクティビティについて、より深い洞察を得ることができました。

これらのケースではキャンペーンに関与した脅威アクターが、クリプトジャック オペレーションに広く長く使うことになる複数の AWS Elastic Compute (EC2) インスタンスを作成可能でした。これらのオペレーションのアクティビティは少なくとも 2 年続いており、現在もアクティブであると考えられます。

このアクターは、GitHub 上での最初の露出から 5 分以内に、その露出した IAM クレデンシャルを検出して使用可能であることがわかりました。AWS が自動的に適用した隔離ポリシーのおかげでアクターのオペレーション能力は制限されていましたが、この隔離ポリシーを外したことにより、キャンペーンの背後にある設計や自動化についての深い洞察が得られました。

この発見と私たちの広範にわたる調査は、攻撃者がクリプトジャック オペレーションの拡大という目標に向け、クラウド自動化技術をどのように活用しうるのかをとくに明らかにするものでした。

本稿では、脅威アクターのオペレーションと、オペレーションの検出・監視のために私たちがどのように Prisma Cloud HoneyCloud プロジェクトを構築したかを取り上げます。HoneyCloud プロジェクトは Prisma Cloud Security チームによる研究活動の 1 つです。このプロジェクトは、好きなように侵害できる状態のクラウド環境を公開しておくことで、そこで発生する悪意のあるオペレーションを監視・追跡できるようになっています。Prisma Cloud は弊社クラウド製品をお使いのお客様に防御ソリューションを提供するために、このプロジェクトを使って潜在的攻撃ベクトルのシナリオと脅威アクターのオペレーションに関するインテリジェンスを収集しています。

8 月 30 日から 10 月 6 日にかけて EleKtra-Leak オペレーションで使われたクリプトジャック プールを監視していたさい、 私たちは、アクター制御下の Amazon EC2 インスタンスの可能性がある 474 個のマイナー (重複なし) を見つけました。このアクターは、プライバシー コントロールを行う暗号通貨の一種、 Monero をマイニングしていました。このため、彼らがそこからどれほどの利益をあげたのかの正確な数値をウォレットを追跡して得ることはできませんでした。

アクターは自動ツールを使って公開 GitHub リポジトリーのクローンを継続的に作成し、露出しているアマゾン ウェブ サービス (AWS) の IAM クレデンシャル (認証情報) をスキャンしていたようです。またこのアクターは、定期的に IAM クレデンシャルを露出させている AWS アカウントをブロックリストに登録していたようです。これにはセキュリティ リサーチャーによるオペレーション追跡を妨害する狙いがあったものと考えられます。アクターらは、これらの AWS アカウントをあからさまな罠と認識していた可能性があります。

このような対策をしているオペレーションに対抗するため、私たちは対象を絞った過度に寛容な IAM クレデンシャルを使い、ランダム化された AWS アカウントとユーザー アカウントの作成を自動化しました。これにより、アクターの動きを追跡できるようになりました。私たちはこの情報をランダムに生成された GitHub リポジトリーにコミットし、リサーチャーの IAM クレデンシャルを外部に露出させておきました。

Unit 42 のクラウド脅威レポート Volume 7 によると、組織の 83% が、本番用のコード リポジトリー内にクレデンシャルをハードコードして露出しているそうです。このレポートでは、組織が IAM クレデンシャル関連のセキュリティ向上に使える推奨事項を提供しています。

本稿の最後に一般的な推奨事項を記載しておきますので、ここで解説した脅威アクターによるアクティビティからの自組織の保護にお役立てください。最後に、クラウド リソースのすべてのユーザーがクラウドの責任共有モデルについて理解しておくことが重要です。つまり、ユーザーと組織は、クラウド アプリケーション、IAM ポリシー、使われているリソースのための構成やパッチ適用、メンテナンス、セキュリティ監視に対する責任を負っています。構築は責任をもって行わねばなりません。

パロアルトネットワークスのお客様は次の方法でこうした事象に対する保護を受けています。

  • Prisma Cloud Secrets Security モジュール は、リポジトリー内の露出の前後両方でシークレットを検出・ブロックします。そのさいは、AWS の IAM クレデンシャルに対してシークレットを検証することで、それらのシークレットに特権が付与されていて露出時により大きな影響を与えうるかどうかを判定します。
  • Prisma Cloud の CI/CD (継続的インテグレーションおよび継続的デリバリー) モジュール は、GitHub などの公開およびプライベート IaC (コードとしてのインフラストラクチャ) リポジトリー内の構成ミスや脆弱性、シークレットの漏えいを検出できます。このモジュールは、侵害された GitHub やワークロード ランナーの悪意のあるアクションを追跡することもできます。
  • GitHub リポジトリーのクローン作成などの GitHub 監査イベントを監視することで、CI/CD モジュールは本稿で解説するイベントを検出し、露出している IAM クレデンシャルを悪用する攻撃者から組織を保護できます。
  • パロアルトネットワークスの Cortex XDR for Cloud は、クラウド ホスト、クラウド トラフィック、監査ログからのデータを活用し、それらをエンドポイントからのデータやネットワークからのデータと組み合わせます。XDR はこのデータセットによりクラウド コンピューティング クレデンシャルの窃取、クリプトジャック、データ漏えいなど、既知の TTP (戦術・技術・手順) と相関する異常なクラウド アクティビティを検出できます。
関連する Unit 42 のトピック Cloud, Cryptojacking, Cybercrime

目次

オペレーション CloudKeys
背景
GitHub のスキャン オペレーション
アクターのオペレーション アーキテクチャ
インスタンスの起動と構成
マイニング オペレーションの追跡
リサーチ用アーキテクチャ
AWS クラウドの自動生成
結論
推奨事項
AWS の管理ポリシー
GitHub Enterprise リポジトリーのクローン作成監視
Prisma Cloud
Cortex XDR
IoC (侵害指標)

オペレーション CloudKeys

Unit 42 のリサーチャーは Prisma Cloud のセキュリティ研究チームと協力しあって仕事をしています。私たちはその一環で、公開された GitHub リポジトリー内で露出した状態になっている IAM クレデンシャルの監視に特化したプロジェクトを始めました。このプロジェクトの目的は、露出した脆弱な IAM クレデンシャルを利用するアクティブな脅威を発見することでした。

この調査の過程で、ある脅威アクターが露出している AWS キーを監視し、それらをクリプトマイニング オペレーションに使っていることがわかりました。私たちは、ギリシャ神話に出てくる雲の精霊エレクトラ (Elektra) と、脅威アクターがパスワードの最初の 3 文字として Lek を使うことにちなんで、この攻撃キャンペーンを EleKtra-Leak と呼んでいます。この種のクリプトジャック アクティビティはとくに目新しいものではありませんが、この特定オペレーションとその関連指標から、私たちはこの EleKtra-Leak が少なくとも 2020 年 12 月からはアクティブだったものと考えています。

2021 年に遡る調査 で、Intezer が EleKtra-Leak に関連すると思われるレポートを発行しています。ただし、このレポートでは当該アクターがクラウド サービス活用のためにさまざまな初期アクセス戦術や技術を使っていることが示されています。具体的には、本稿でこのあと説明するように、このアクターは (GitHub 内で露出している IAM クレデンシャルをスキャンして使うのではなく) 露出している Docker サービスを侵害していました。これら 2 つのキャンペーンを結び付ける要因は、カスタマイズされた同じマイニング ソフトウェアを攻撃者が使用していることです。

背景

リサーチの観点から見ると、AWS キーを意図的に漏えいするさいの課題の 1 つは、脅威アクターがキーを特定すると、対応する AWS アカウントにそのキーを簡単に帰属できてしまうことです。アクターはたびたび登場してくる AWS アカウント ID を認識して、その後の攻撃や自動化スクリプトからそうしたアカウント ID をブロックできるらしいことがわかりました。このため私たちは、帰属ができないような AWS キーを動的に作成・漏えいする新たな調査用アーキテクチャを設計しました。これについては、本稿の 2 つめのセクションに後述します。

攻撃者は長い年月をかけて、侵害の初期ベクトルとしての GitHub の使用を増やしてきました。GitHub の強力な機能の 1 つとして、すべての公開リポジトリーを一覧表示できることがあげられます。この機能は、ユーザーが興味をもったトピックの開発を容易に追跡できるようにしてくれます。この機能を使うことで、開発者、そして残念ながら脅威アクターまでもが、新しいリポジトリーをリアルタイムで追跡できるようになります。

この機能があることから、私たちは AWS キーの漏えいに関する実験プラットフォームとして GitHub を選びました。私たちは、公開 GitHub リポジトリーの一覧からランダムなリポジトリーを選んでクローンを作成し、新しい GitHub リポジトリーを作成しました。そしてそのリポジトリー内のファイルに、漏えいしたキーを平文で書き込みました。私たちは、クローンを作成したリポジトリーの中にランダムにファイルを作成しました。そして、そのファイル内に AWS キーを漏えいさせ、正常にコミットされた後で削除しました。

漏えいしたキーをリポジトリーにコミットしてすぐに削除したのは、脅威アクターへの撒き餌があからさまになり過ぎないようにするためです。当初これらの IAM キーは Base64 でエンコードされていました。ところが、公開された Base64 IAM キーを見つける trufflehog のようなツールがあったにもかかわらず、どの脅威アクターもこのキーを発見することはありませんでした。

私たちは、特定されたこのアクターが、この時点では Base64 でエンコードされたクレデンシャルを解読できるツールを使っていないものと考えています。その理由の 1 つはおそらく、こうしたツールにはノイズが多く、多くの偽陽性が発生するからと考えられます。

続いて平文で AWS キーを漏えいする実験を行ったところ、今度は彼らに発見されました。これらは平文で書かれ、クローンしたリポジトリーに追加されたランダムなファイル内の過去のコミットの背後に隠されていました。

GitHub のスキャン オペレーション

私たちが GitHub で AWS キーを露出させたさい、GitHub のシークレット スキャン機能がそれらのキーを検出し、GitHub から AWS へ、露出しているクレデンシャルについての通知がプログラム的に送られました。この結果、AWS はこれらのキーに関連付けられたユーザーに、AWSCompromisedKeyQuarantine と呼ばれる隔離ポリシーを自動適用しました。このポリシーが適用されると、脅威アクターは特定のオペレーションを行えなくなります。なぜなら、露出した IAM クレデンシャルに関連付けられたほかの API サービスオペレーションのなかでもとりわけ AWS の IAM と EC2 を正常に利用するための機能を AWS が自動的に削除するためです。

当初私たちは、AWS の AWSCompromisedKeyQuarantine ポリシーを適用状態のままにしておいて、アクターが露出したキーをテストするさいの偵察活動をパッシブ (受動的) に監視していました。その後、次のセクションで説明するように、キャンペーン オペレーション全体をさらに可視化できるよう、AWS の隔離ポリシーを当初の過度に寛容な IAM ポリシーに意図的に置き換えました。

なお、この AWS 隔離ポリシーが適用された理由は、脅威アクターが攻撃を開始したからではなく、AWS が GitHub でキーを見つけたことが理由ですので、その点はご注意ください。私たちは、AWS が自動検出しなかった露出した AWS キーをこの脅威アクターが見つけ、その後、これらのキーを AWSCompromisedKeyQuarantine のポリシー外で制御しうるのではないかと考えています。私たちの証拠も、どうもそうだったらしいことを示しています。その場合この脅威アクターは、被害者からリソースを盗むという悪意のある行為で、なんらポリシーに邪魔されることなく攻撃を続けられることになります。

AWS キーが漏えいした場合、GitHub と AWS が連携して一定レベルの保護は実装してはいますが、すべてのケースをカバーしてくれるわけではありません。コミット時のリポジトリー スキャンなどの CI/CD セキュリティの実践は、独立して実装することを強くお勧めします。

なお、本稿の説明とは異なる方法で攻撃者が標的にした可能性のある、このキャンペーンの潜在的な被害者がほかにも見つかりました。

漏えいキーを使ったこの実験において、このアクターは AWS が隔離ポリシーの適用から 4 分以内にオペレーションを開始していました。図 1 は、これらのアクティビティのタイムラインを示しています。

画像 1 は、攻撃者のアクティビティのタイムラインを表として示したものです。列名は eventName、userAgent、_time です。これらのイベントは 2023 年 8 月の非常に短いタイムスパン (分単位) で開始・終了しています。
図 1. 攻撃者のオペレーションのタイムライン

上の図 1 の最後の行は CloudTrail イベントの AttachUserPolicy から始まり、AWS はタイムスタンプでは 13:30:22 に隔離ポリシーを適用しています。それからわずか 4 分後の 13:34:15、このアクターは AWS API の DescribeRegions を使って偵察活動を開始していました。CloudTrail は、構成されたクラウド リソース内で発生するアクションやイベントを記録する監査ツールです。

アクターのオペレーション アーキテクチャ

図 2 は、脅威アクターの自動化アーキテクチャの全体像です。GitHub の公開リポジトリーはリアルタイムでスキャンされ、キーが見つかると攻撃者の自動オペレーションが開始されます。

画像 2 は、オペレーション CloudKeys アーキテクチャ図です。3 つの GitHub アイコンは VPN を指しています。VPN からの矢印が脅威アクターを指しています。3 つの入れ子になった四角形が、アーキテクチャを表しています。これらの四角形は、外側から AWS Cloud、Honey Organizational Management AWS Account、Honey AWS Account の順です。Honey AWS Account 内には、IAM と Designed Policy のエリアと、その下の 3 つの Avaiability Zone の Compute のエリアが表示されています。Availability Zone の 1 つに対して矢印が伸びています。双方向矢印が XMR との間に表示され、矢印には「Text」と表示されています。Google Drive アイコンの下には「Encrypted Payload」という説明があり、ここから同じ Availability Zone の 1 つに矢印が伸びています。
図 2. オペレーション CloudKeys のアーキテクチャ

図 3 は、脅威アクターがはじめに AWS アカウントの偵察オペレーションを実行していることを示しています。

画像 3 は、脅威アクターが実行した AWS アカウントの偵察を示した表です。さまざまなアクションには、DescribeAccountAttributes、DescribeInstanceTypeOfferings、DescribeInstanceTypes などが含まれます。
図 3. アクターによる AWS の偵察

偵察オペレーションの後、アクターは AWS セキュリティ グループ (図 4) を作成します。そして最後に、アクセス可能な全 AWS リージョンについて、リージョンごとに複数の EC2 インスタンスを起動します。

画像 4 は、脅威アクターが変更したセキュリティ グループの表です。
図 4. セキュリティグループを変更して最初の EC2 インスタンスを起動

私たちが収集したデータは、攻撃者の自動オペレーションが VPN の背後で行われていることを示しています。CloudTrail のログによると、彼らは複数リージョンで同じオペレーションを繰り返し、合計で 400 回を超える API 呼び出しが生成されていました。その所要時間はわずか 7 分でした。つまりこのアクターは、身元をうまく隠しながら AWS アカウント環境に自動攻撃を仕掛けられたことになります。

インスタンスの起動と構成

AWS キーを発見すると、このアクターは自動化の一部として、さまざまなリージョンをまたいでインスタンスを実行していました。図 5 は、複数のリージョンをまたいだインスタンス タイプとその分布に関する統計です。

攻撃者はインスタンス サイズの大きなクラウド仮想マシンを使ってオペレーションを実行していました。具体的には、c5a.24xlarge という AWS インスタンスが利用されていました。クリプトマイニング オペレーションでは大規模なクラウド インスタンスの利用が一般的です。使える処理能力が高ければ、クリプトジャック オペレーターはより短時間で多くの暗号通貨をマイニングできるからです。

画像 5 は、インスタンス タイプの統計とその分布の表です。列の名前は requestParameters.instanceType、awsRegion、count です。リージョンには、AP Northeast、EU Central、EU West、US East などが含まれています。
図 5. リージョンをまたいでインスタンス化された AWS EC2 のインスタンス タイプ

このアクターは RunInstance API を使って Amazon EC2 インスタンスをインスタンス化していました。この API には、AWS Cloud-Init スクリプトを受け取るためのパラメーターがあります。この Cloud-Init スクリプトは、インスタンスの起動処理中に実行されます。攻撃者はこのしくみで EC2 インスタンスの構成を自動化し、必要な処理を実行していました。

このユーザー データは CloudTrail ログには記録されません。データを取得するため、私たちは EC2 ボリュームのフォレンジック分析を実行しました。

図 6 に示すように、このマイニング自動オペレーションは、起動時のマイナーによる EC2 の構成中にユーザー データを自動的に表示していました。

画像 6 は多数のコード行からなるスクリーンショットです。これは、マイニング オペレーションのための構成スクリプトです。
図 6. マイナーの構成スクリプト

図 7 は、このペイロードが Google ドライブに保存されたことを示しています。なお、Google ドライブの URL は意図的に匿名化されています。この URL を Google Cloud ユーザー アカウントにマッピングすることはできません。6 行目に示すように、ダウンロードされたペイロードは暗号化して保存されていて、ダウンロード時に復号されていました。

このペイロードは既知のマイニング ツールで、そのハッシュは以前のリサーチ (おそらく本稿と同じアクターが外部に露出した Docker サービスを使ってクリプトジャック オペレーションを実行していた) と相関させることが可能です。私たちは、同じハッシュと同じ永続化用命名規則 (「appworker」) を使っている VirusTotal への提出レポートも特定しました (図 7)。

画像 7 は、同じメタデータを共有する既知のクリプトマイニング バイナリーの表です。列名は Date、Name、Source、Country です。
図 7. 同じメタデータを共有する既知のクリプトマイニング バイナリー

攻撃者が使った Amazon Machine Images (AMI) のタイプも特徴的でした。特定されたイメージはプライベートで、AWS Marketplace には掲載されていませんでした。図 8 は、次の AMI インスタンスの ID が使われたことを示しています。

画像 8 はプライベートな AMI イメージの ID とその数を示す表です。表の列名は requestParameters.instancesSet.items().imageid と count です。
図 8. プライベート AMI イメージの ID 一覧

イメージの一部は Ubuntu 18 というバージョンです。これらすべての侵害指標 (IoC) から、私たちはこれが少なくとも 2020 年に遡る長期的マイニング オペレーションであるものと考えています。

マイニング オペレーションの追跡

前述のように、これらの EC2 インスタンスは EC2 のユーザー データ経由でマイニング用の構成を受け取っていました。この構成には、各マイナーがマイニングした Monero の配信に使う Monero ウォレットのアドレスが含まれていました。

このオペレーションのアーキテクチャからすると、このウォレット アドレスは この AWS のマイニング オペレーションに固有で使われていたものと推測できます。その場合、このプールに接続されているすべてのワーカーは、個々の Amazon EC2 インスタンスを表していることになります。

脅威アクターがこのオペレーションに使ったマイニング プールは、SupportXMR マイニング プールでした。マイニング プールは、複数のマイナーで協力しあって暗号通貨報酬の獲得チャンスを上げるためのワークスペースとして、クリプトマイニング オペレーションで使われています。報酬が付与されると、その収益はそのプールに貢献したマイナーに均等に分配されます。

SupportXMR サービスは一定期間の統計しか提供していないので、私たちはこのウォレットを監視して数週間にわたるマイニングの統計を取得しました。図 9 は、一意なマイナーの数を示しています (これはおそらく、このキャンペーンの標的から盗まれたリソースを表しています)。

画像 9 は、2023 年 8 月 30 日から 2023 年 10 月 6 日まで続く一意な XMR マイナーのグラフです。青いトレンド ラインは、3 か月にわたって緩やかに上昇しています。
図 9. XMR マイナー数の統計

2023 年 8 月 30 日から 2023 年 10 月 6 日までに、合計で 474 個の一意なマイナーが出現しました。これは、この期間中にマイニング オペレーションの実行が記録された 474 個の一意な Amazon EC2 インスタンスであると解釈できます。このアクターは、プライバシー コントロールを行う暗号通貨の一種、 Monero をマイニングしていました。このため、彼らがそこからどれほどの利益をあげたのかの正確な数値をウォレットを追跡して得ることはできませんでした。

このアクターは仮想プライベート ネットワーク (VPN) と Google ドライブにエクスポートされたドキュメントを使ってペイロードを配信していたため、地理的情報の分析はしづらくなっています。私たちは、このマイニング キャンペーンを引き続き監視していきます。Unit 42はこれまでも攻撃者が信頼性の高いビジネス アプリケーションを使って検出を回避するようすを観測してきましたが、今回の手口もそうした傾向と一致しています。

リサーチ用アーキテクチャ

リサーチの実施にあたり、Prisma Cloud Security Research チームは HoneyCloud というツールを作成しました。HoneyCloud は、好きなように侵害・再生が可能なクラウド環境で、リサーチャーに次の機能を提供します。

  • 悪意のあるオペレーションの追跡
  • クラウド脅威アクターの動きの追跡
  • 新しいクラウド攻撃経路の発見
  • よりよいクラウド防御ソリューションの構築

私たちは Terraform 用の IaC テンプレートを使って、なかばランダムな AWS インフラストラクチャを作成しました。Terraform というのはクラウド インフラを管理・保守する IaC プロビジョニング ツールです。このツールを使うことで、タイミングによる指定と人手による分析を組み合わせて、インフラストラクチャを作成したり破棄したりできます。

以前リサーチに使っていた私たちの AWS のアカウント ID が攻撃者のブロックリストに追加されてしまったことが直接のきっかけとなって、リサーチャーが Terraform での設計を実装しました。この設計では、生成される AWS アカウントがある程度ランダムになります。これによって新しく作成されたインフラストラクチャは、私たちが過去に露出させていた IAM クレデンシャルを脅威アクターのオペレーションが照合・特定するのを防ぐのに役立ちました。

また、脅威アクターが AWS アカウントで実行しているアクティビティに応じて、さまざまなタイプの IAM ポリシー (つまり多かれ少かれ制限をかけた IAM アクセス許可) を使うように Terraform の自動化を設計しました。

この調査で私たちが体験した最大の障害の 1 つは、悪意のあるオペレーションを防ぐために隔離ポリシーを適用する AWS の反応のすばやさでした。AWS は、AWS クレデンシャルが GitHub で漏えいしてから 2 分以内に隔離ポリシーを適用していました。

AWS の隔離ポリシーがあればこの攻撃はうまく防げたはずです。しかし、マイニング オペレーションを分析した結果、このキャンペーンにはほかにも潜在的被害者と思われる追加のマイニング インスタンスがありました。おそらく、そのキーは別の方法や別のプラットフォームで露出していたのでしょう。

今回の調査の場合、脅威アクターのオペレーションを確実に追跡できるよう、隔離ポリシーを上書きする必要がありました。今回のオペレーションの実行では、べつの監視ツールを作って、元の過度に寛容な AWS セキュリティ ポリシーを復元することにより、意図的に侵害を受けられるようにしました。

AWS クラウドの自動生成

図 10 は IaC アーキテクチャの全体図です。このアーキテクチャを使って AWS の IAM クレデンシャルを露出させ、その後の侵害で取られたアクションを監視します。

画像 10 は、AWS を使った GitHub リポジトリーのクローン作成・監視のアーキテクチャ図です。緑色のフィールド内の 3 つの GitHub アイコン (ランダムに選択されたリポジトリー) は、AWS キーを使ってクローン作成されています。そこから、1本の矢印がリサーチ用のアーキテクチャを示す 3 つの入れ子になった四角形を指しています。外側 2 つの四角形は、AWS Cloud と Honey Organization Management AWS Account です。Honey Organization Management AWS Account の中には、AWS Lambda、Simple Storage Service Standard、Container が含まれています。べつの矢印が、Honey Organization Management AWS Account の中の Container からさらに内側の四角形である Honey AWS Account 内の IAM とDesigned Policy、Text の入った四角形を指しています。その下には、3 つの Compute を含むエリアがあります。
図 10. AWS を使った GitHub リポジトリーのクローンと監視

私たちが設計したアーキテクチャ用の IaC テンプレートは、GitHub リポジトリーをランダムに選択し、AWS の IAM キーを複製し、ランダムなファイル内に過去のコミットとして露出させる、という役割を担っています。AWS 側では、同じ AWS 管理組織と一元化された CloudTrail ログ ストレージを使い、IaC テンプレート実行の反復ごとに新しい AWS アカウントが動的に作成されます。

さらに私たちは、その AWS 管理アカウント内に追加の Lambda 関数を開発してデプロイし、これがインフラの変更収集と IAM ユーザー ポリシーの変更追跡用モニターとして機能するようにしました。

この IaC テンプレートの主たる目的の 1 つは、AWS インフラストラクチャのコンポーネントを可能な限りランダムに保ち、脅威アクターによるブロックを避けることでした。もう 1 つの目的は、インフラストラクチャを定期的かつ正確に破棄し、新しい環境と変数を迅速かつ体系的に開始できるようにすることでした。そうすれば、脅威アクターはこの AWS の IAM キーをまったく新しい AWS 環境の一部として認識し、これがリサーチ用の環境であるとは認識できなくなります。

結論

私たちは、公開 GitHub リポジトリー内に露出している AWS の IAM クレデンシャルをスキャンする脅威アクターのオペレーションを発見しました。AWS の IAM クレデンシャルが公開 GitHub リポジトリーに露出してから 5 分以内に、脅威アクターはこれを検出して本格的なマイニング オペレーションを始められることがわかりました。

私たちが発見したこのオペレーションは、少なくとも 2020 年からアクティブでした。AWS の隔離ポリシーは正常に適用されているにもかかわらず、当該キャンペーンによる侵害被害アカウント数とその頻度は継続的に変動しています。このキャンペーンが依然アクティブである理由はいくつか推測できますが、このキャンペーンが標的に据えているのは露出した GitHub クレデンシャルや Amazon EC2 インスタンスだけではない、ということがその 1 つとして考えられます。

私たちは、この脅威アクター グループのアクティビティ追跡のために、半自動の IaC Terraform アーキテクチャを開発しました。このアーキテクチャには、意図的に侵害を受け、破棄されるよう設計した AWS アカウントの動的な作成が含まれています。

パロアルトネットワークスは、ファイル サンプルや IoC (侵害指標) をふくむ調査結果を Cyber Threat Alliance (CTA: サイバー脅威アライアンス) のメンバーと共有しました。CTA のメンバーはこのインテリジェンスを使って、お客様に保護を迅速に提供し、悪意のあるサイバー攻撃者を体系的に阻害できます。詳細は Cyber Threat Alliance にてご確認ください｡

推奨される対策

AWS の隔離ポリシー

最初におとりの GitHub リポジトリー内で AWS の IAM クレデンシャルを露出させたさい、AWS は AWS ポリシー AWSCompromizedKeyQuarantineV2 を使い、露出した IAM クレデンシャルをきちんと隔離してくれました。このポリシーは、以下を含む複数の AWS サービスへのアクセスを拒否します。

  • EC2
  • S3
  • IAM
  • Lambda
  • Lightsail

この隔離オペレーションは、露出した IAM クレデンシャルが GitHub リポジトリーにコミットされてから数分以内に AWS によって開始されていました。潜在的な攻撃者が機微なクラウド データやサービス、リソースを利用することのないよう、この隔離ポリシーをそのまま適用しておくことが重要です。

AWS の IAM クレデンシャルを誤って露出させてしまった組織は、そのクレデンシャルを使って行われた API 接続を直ちに無効化する必要があります。またその組織は、GitHub リポジトリーから AWS の IAM クレデンシャルを削除し、必要な機能の実現のために新しい IAM クレデンシャルを生成する必要があります。組織の皆さんには、本番環境で動的な機能を実行するさい、有効期間の短いクレデンシャルを使うことを強くお勧めします。

GitHub Enterprise リポジトリーのクローン作成監視

攻撃者が GitHub リポジトリー内の AWS の IAM クレデンシャルを検出して取得するには、対象のリポジトリーのクローンを作成してから、その内容を表示する必要があります。GitHub の Enterprise アカウントには、関連 GitHub リポジトリーで発生するクローン作成イベントの監査機能があります。

この機能を使うと、セキュリティ チームは、GitHub リポジトリーを対象とした潜在的に悪意のあるオペレーションを監視できるようになります。個人用 (または無料の) アカウントの場合、リポジトリー内で実行されるアクションの監査機能は限られていて、クローン作成イベントは監査できません。GitHub アカウントの種類とその機能について詳しくはこちらから確認してください。

GitHub の Enterprise アカウントには、組織のコード リポジトリーのセキュリティ維持に役立つ監査機能が複数用意されています。ツールやアプリケーション、またはコンテンツを公開している組織には Enterprise アカウントの利用が強く推奨されます。

Prisma Cloud

Prisma Cloud の CI/CD モジュールは、以下のような潜在的に悪意のあるイベントについて GitHub リポジトリー所有者に警告できます。

  • 露出している IAM クレデンシャル
  • リポジトリーのクローン作成イベント
  • 構成ミスのあるコードまたは脆弱なコードの存在
  • 侵害されたワークロード ランナー

これにより、組織は公開しているコード リポジトリーの可視性とセキュリティを維持できるようになります。

Prisma Cloud Code Security もまた、リポジトリー内でフックを受け取る前やコミットを行う前に、開発者 IDE 内にあるハードコードされたクレデンシャルの漏えいなどの脆弱性や構成ミスをスキャンして検出することにより、ソースの段階でクレデンシャルの露出を防止します。

Prisma Cloud Anomaly Detection は、不審なクリプトマイナー アクティビティからのトラフィックやクリプトマイニングを実行する DNS リクエストのアクティビティなど、平時とは異なるエンティティの振る舞い分析 (UEBA) により、異常なコンピュートのプロビジョニング アクティビティを検出可能です。 さらに Prisma Cloud は、攻撃者にたびたび採用される戦略である不審な Tor ネットワークのトラフィックも検出可能です。

Prisma Cloud CIEM は、以下の機能によりリスクの高い、権限過剰なアクセスを緩和できます。

  • リスクの高い権限を可視化し、アラートを発報し、自動修復する
  • 最小特権のアクセス修復により使われていない権限を自動検出する

Prisma Cloud Threat Detection 機能は、クラウド内部や外部からクレデンシャルが異常な使われ方をした場合など、さまざまな ID 関連の異常なアクティビティについてアラートを発報できます。

Prisma Cloud はまた、ランタイム オペレーションの監視を実行し、クラウド環境に関連付けられたコンポーネントにガバナンス、リスク、コンプライアンス (GRC) 要件を提供することもできます。

Cortex XDR

Cortex XDR for Cloud はクラウド ホスト、クラウド トラフィック、監査ログからのアクティビティの内容と、エンドポイントやネットワークのデータとを統合します。この統合により SOC チームはデジタル ドメイン全体を俯瞰したインシデントのストーリーを得ることができます。XDR はこれらすべてのデータセットを使って、クラウド コンピューティング クレデンシャルの窃取、クリプトジャック、データ漏えいなど、既知の TTP (戦術・技術・手順) と相関する異常なクラウド アクティビティを検出します。

IoC (侵害指標)

暗号化されたドキュメント:

  • Backup.tib
    SHA256: 87366652c83c366b70c4485e60594e7f40fd26bcc221a2db7a06debbebd25845

マイナーのハッシュ

  • Appworker
    SHA256: 240fe01d9fcce5aae311e906b8311a1975f8c1431b83618f3d11aeaff10aede3

スクリプトのハッシュ

  • EC2 のユーザーデータ
    SHA256: 2f0bd048bb1f4e83b3b214b24cc2b5f2fd04ae51a15aa3e301c8b9e5e187f2bb

ドメイン

  • XMR プールのアドレス: pool[.]supportxmr[.]com:443

Monero ウォレットのアドレス

  • 82sdgJwuAMTF6w76Q7KrN4jJL72v23gvf9K2favHYHKxCNP4UabmBsJMwAVGWDLYagW5UmykC2D1zaMoQegZLy2bF9ynM1E

2023-10-31 13:40 JST 英語版更新日 2023-10-30 12:00 PDT の内容を反映し、Prisma Cloud による保護情報をさらに追記 

2023-11-07 09:30 JST 英語版更新日 2023-11-06 12:07 PDT の内容を反映し、概要がよりわかりやすくなるよう文言を変更