CAPTCHAを自動突破しクラウドリソースをフリージャッキングするAutomated LibraのキャンペーンPurpleUrchin

  • 3,006
    people reacted
  • 0
  • 3 min. read

By and

Category: Cloud

Tags: , , , , , , , , , , ,

A pictorial representation of PurpleUrchin and cryptomining. Included are the Palo Alto Networks and Unit 42 logos.

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

概要

本稿ではフリージャッキングキャンペーン「PurpleUrchin」の背後にいるクラウド脅威アクターグループ、「Automated Libra」をUnit 42のリサーチャーが詳述します。Automated Libraは南アフリカを拠点とするフリージャッキンググループです。彼らは主にクラウドリソースに試用期間を設けているクラウドプラットフォームを狙い、無料のクラウドリソース上でクリプトマイニング(暗号通貨のマイニング)オペレーションを展開します。

「フリージャッキング(freejacking、タダ乗り)」は「無料(または期間限定)のクラウドリソースを使ってクリプトマイニングオペレーションを実行すること」を指します。

キーポイント:

  • アクターは継続的インテグレーション/継続的デリバリー(CI/CD)をはじめとするDevOps自動化技術を多用して無料トライアルの提供する制限の設けられたリソースを悪用。クラウドプラットフォーム上のユーザーアカウント作成をコンテナ化し、クリプトマイニングオペレーションを自動化することでこれを実現。
  • PurpleUrchinのオペレーション用に作成された250GB以上のコンテナデータを収集した結果、同キャンペーンの背後にいる脅威アクターは2022年11月のオペレーションのピーク時に毎分3～5個のGitHubアカウントを作成していたことが判明。
  • 自動アカウント作成事例では簡単な画像解析技術でCAPTCHA画像を回避している事例があったことも判明。またHeroku、Togglebox、GitHubなどさまざまなクラウドプラットフォームサービス上に13万件以上のユーザーアカウント作成を確認。
  • これらのクラウドサービスのプラットフォームの一部ではアカウントに未払い残高がある証拠も見つかった。このことからアクターは盗んだか偽造したクレジットカードで偽アカウントを作成したと考えられる。
  • 以上よりPurpleUrchinオペレーションの背後にいるアクターは複数のクラウドサービスプラットフォームからクラウドリソースを盗み、そのさいUnit 42のリサーチャーが「プレイ&ラン」と呼ぶ戦術を使ったと評価される。この戦術は悪意のあるアクターがクラウドリソースを使い、請求書が届いた後にそのリソースに対する支払いを拒否するというもの。

パロアルトネットワークスのお客様はPrisma Cloudのコンテナ脆弱性スキャンとランタイム保護ポリシーを通じて本稿で解説したインシデントからの保護を受けています。

関連するUnit 42のトピック Cryptomining, containers, DevOps, Prisma Cloud

目次

新たなプレイ&ラン戦術
背景
GitHubのワークフローを使ったマイニング
GitHubアカウント作成の自動化
CAPTCHAの弱点を突く
以前の攻撃キャンペーン、2020年〜2021年
結論

新たなプレイ&ラン戦術

2022年10月に初めて顕在化したPurpleUrchinのクリプトマイニングキャンペーンにはフリージャッキング(freejacking)オペレーションという特徴があります。Unit 42のリサーチャーは同アクターを独自に調査するなかで、彼らがプレイ&ラン戦術(クラウドリソースを使ったあとクラウドプラットフォームベンダーのリソース使用請求書に支払いを行わない)を採用していた証拠を見つけました。

また同アクターはこうしたプレイ&ランオペレーション実行にあたり、偽アカウントを作成・使用し、偽造されたか窃取された疑いのあるクレジットカードを利用していました。これら偽アカウントには未払い残高が残っていて、高いもので190ドルの未払い残高が残るアカウントが見つかっています。ただしマイニングの規模からするとアクターが使ったほかの偽アカウントとクラウドサービスの未払い残高はさらに増えると思われます。

背景

今回Unit 42のリサーチャーは250GB以上のデータを分析しましたが、そのなかにはコンテナデータやアクターの残したシステムアクセスログ(ジオロケーション情報付き)、数百のIoC(侵害の痕跡: indicators of compromise)が含まれていました。本リサーチで収集したIoCは Unit 42 ATOMのAutomated Libraのページに公開しています。

同アクターはインフラアーキテクチャにCI/CD手法を採用し、オペレーションを構成するソフトウェアコンポーネントを個別に単一コンテナに配置しています。このコンテナはモジュール化されたアーキテクチャ内で稼働していて、モジュール化されたアーキテクチャがさらに大規模なマイニングオペレーション内に含まれています。

CI/CDアーキテクチャは高度にモジュール化された運用環境を実現します。このおかげで、オペレーションの一部のコンポーネントに故障、更新、終了、交換が生じても、全体的な環境は影響を受けません。

収集したコンテナデータを解析した結果、アクターの活動を2019年8月まで遡れました。彼らの活動は複数のクラウドプロバイダと暗号取引所に広がっていました。

また同アクターは、従来型の仮想サービスプロバイダ(VSP)経由でのクラウドサービス利用を好むことがわかりました。従来型VSPの多くはクラウドアプリケーションプラットフォーム(CAP)やアプリケーションホスティングプラットフォーム(AHP)などのクラウド関連サービスにサービスポートフォリオを拡張しています。PurpleUrchinのアクターが標的としたCAPやAHPサービスを提供しているクラウドサービスにはHerokuやToggleboxなどが含まれます。

Unit 42のリサーチャーはPurpleUrchinのオペレーションには40個以上の個別暗号ウォレットと7種類の暗号通貨やトークンが使われていることを確認しています。さらに、同アクターが作成したインフラ内の特定のコンテナ化済みコンポーネントでは、マイニング機能実行のほか、複数の暗号取引プラットフォーム(CRATEX ExchangeMarket、crex24、Lunoなど)で収集した暗号通貨の取引プロセス自動化が組み込まれていることも確認しています。

GitHubのワークフローを使ったマイニング

GitHubでのオペレーションは「プレイ&ラン」と「フリージャッキング」戦術を組み合わせて行われていました。GitHubを利用した理由はアカウント作成を阻む要素が少ないためと思われます。彼らはGitHubのCAPTCHAチェックの弱点を突いていました(次セクションで詳述)。

GitHubのアカウントは1分に平均3〜5個の割合で自動作成されていました。アカウントベースの確立後はフリージャッキング活動を開始していました。

その後、GitHubの各アカウントはプレイ&ラン戦略に参加して計算資源を使いますが、最終的にこの請求書は未払いのままにされます。これがPurpleUrchinの標準作業手順のようで、さまざまな仮想プライベートサーバ(VPS)プロバイダやクラウドサービスプロバイダ(CSP)で13万件以上のアカウントが作成された証拠があります。

フルサーバーやクラウドインスタンスを予約したり、AHPなどのCSPサービスを利用することもあったようです。その目的は大規模なマイニングオペレーションを監視・追跡するのに必要なWebサーバーのホスティングを容易にすることでした。

私たちは高い確度で「この脅威攻撃グループが作成したアカウントの一部は偽のプロフィールや偽のクレジットカード情報で作成されたもの」と考えています。この戦術をとることでマイニング終了後はCSPへの未払い請求書を残していけます。

Unit 42のリサーチャーは、PurpleUrchinの背後にいるアクターが、プレイ&ランやフリージャッキング戦術を洗練させ、その活動を継続的に進化させているようすを確認しています。

以下、同アクターがGitHubアカウント作成の自動化を洗練させていったようすを詳しく見ていきます。

GitHubアカウント作成の自動化

この脅威アクターによる直近のデプロイメントには、AHPサービスを使ったToggleboxの実行が含まれます。ToggleboxはフルマネージドのSSD (Solid State Drive)クラウドVPSとアプリケーションホスティングプラットフォームを提供しています。

彼らはこのプラットフォームを使ってrepo_name/vgenerated_name:latestという命名規則の一連のコンテナを実行していました。これらの各コンテナはGitHubアカウントの自動作成機能を備えていました。

前述のコンテナに含まれていたユーザーアカウント作成Pythonプロセスには、「名前付き(辞書単語に基づくという意味)」ベースのアカウントと呼ばれるスイッチが見つかっています。この処理ではMD5ハッシュをもとにランダムに生成された名前付きアカウントを使います。

アカウント自動作成処理に必要なツールはコンテナとして共有(Ship)されていました。最新版のコンテナでは以下のような一般的に入手できる正規ツールを複数組み合わせてオペレーションを行っていました。

必要なツールを揃えた脅威アクターはアカウント作成を開始します。GitHubアカウント作成の最初の手順はメールアドレス、パスワード、ユーザー名フィールドへの入力です(図1)。

画像1はGitHubのフォーム入力の流れを示した図。ここではコードのスクリーンショットを右と下に2枚表示しており、右はxdotoolのもの、下は高次の処理を示したコードスニペット。
図1. GitHubのフォーム入力処理

このコンテナはdisplay:1上でVNC(仮想ネットワークコンピューティング)サーバーを実行し、このVNCサーバー上でIronブラウザを起動していました。そのさいに使ったコマンドが以下図2のコマンドです。

画像2はVNCサーバー上でコマンドでIronブラウザを起動するようすを示すコード行のスクリーンショット。
図2. VNCサーバー上のIronブラウザ表示

その後、xdotoolを使ってメインスクリプトがGitHubのフォームを完成させます。フォームへの入力が済むとGitHubは図3に示すCAPTCHAチャレンジを提示します。

画像3はGitHubで「渦巻き型銀河(spiral galaxy)」を選ばせるCAPTCHAチャレンジのスクリーンショット。
図3. GitHubのCAPTCHAチャレンジ

アクターはごく単純なしくみを使ってCAPTCHAを解いていました。私たちはこのCAPTCHA解決プロセスの有効性評価はしていませんが、次のセクションで同アクターが3ヶ月間にわたって作成したGitHubアカウント数の統計を示します。この統計情報からはこのプロセスとほかの戦術との組み合わせは効果が高かったものと考えられます。

CAPTCHAの弱点を突く

今回この特定の「渦巻き銀河 (spiral galaxy)」を識別するというCAPTCHAを解くのに、アクターはImageMagicツールキットの2つのツール、convertとidentifyとを使っていました。

まずconvertツールで赤・緑・青(RGB)の補色画像に変換します。図4はその変換例です。

図4はCAPTCHA変換のスクリーンショット。脅威アクターはCAPTCHAの画像をRGB補色画像に変換してから赤チャンネルのskewness(歪度)を抽出している(画像5)。
図4. 画像をRBGの補色に変換しているところ

画像を変換したら次に各イメージに対してidentifyコマンドを実行して赤(Red)チャンネルの「歪度(正規分布からの分布のゆがみ)」の特徴量を抽出します(図5)。

画像5はskewコマンドでRBG画像から赤チャンネルを抽出しているようすを示すコード行。
図5. 赤チャンネルの歪度の特徴量を抽出しているコマンド

最終結果を順番に並べ(図6)、値がより小さい画像を「渦巻き銀河」の画像として選びます。たとえば先の画像の値を使うと以下の順となります。

画像6は赤チャンネルの数値の出力結果
図6. 各画像の赤チャンネルの出力結果例

この場合画像2(図4参照)が「渦巻き銀河」と識別されます。CAPTCHAを解くとGitHubは「起動コード」を要求します(図7)。

画像7はGitHubが起動コードを要求している画面。「You're almost done! We sent a launch code to test@yah.com」というテキストと「Enter code」というテキストが表示されている
図7 GitHubが起動コードを要求

このアクターはGmailアカウントを使って起動コード取得を自動化していました。これにはIMAP (Internet Message Access Protocol)と受信したIMAPメッセージを読み込むPHPスクリプトを使っていました。

起動コードを入力すると、ワークフローのパーミッションを持つパーソナルアクセストークン(PAT)が自動生成されます。GitHub登録作業の最終結果はGitHub上でワークフローをデプロイするさいに使うユーザー名とPATです。このユーザ名とトークンを使って別のコンテナを呼び出します(図8)。

画像8は実行中のコンテナを呼び出す2行のコード。
図8. 実行中のコンテナを呼び出し

このコンテナが続いて以下を行います。

  • SSHキーの設定
  • GitHub APIを使ったGitHubリポジトリの作成
  • 作成したリポジトリのパーミッションの設定

最近のオペレーションでは命名規則を変更し、リポジトリにMD5ハッシュをベースにしたランダムな名前を使っています。これは前述のユーザー名作成と同じ要領です。図9に示したコマンドがこの命名規則の処理を表しています。

画像9はランダムな命名規則コマンドを示したコード行のスクリーンショット。
図9 ランダムな命名規則コマンド

GitHubにリポジトリを作成したら、Bashスクリプトを呼び出して任意のワークフローでリポジトリを更新します。このワークフローはあるPHPスクリプトを使って生成されていました。このPHPスクリプトがテンプレートの役割を果たし、ワークフロー構成の属性にランダム化されたさまざまな名前をつけます。図10はこのワークフロー用PHPテンプレートのコーディングサンプルです。

画像10はスクリプトの属性をランダム化するためのPHPテンプレートのスクリーンショット。ワークフローがどのようにコーディングされているかを示したもの。
図10 スクリプトの属性をランダム化するPHPテンプレート

あるバージョンでは、ワークフロー(図10に示したテンプレートから生成したもの)に64個のジョブがありました。生成されたワークフローは、イベントgithub.event.client_payload.app下でrepository_dispatchとして実行されるよう設定されていました。

アクターはこのワークフローのしくみを使って外部アプリケーションを実行できるようにしていました。この事例では外部のBashスクリプトとコンテナを実行しています(図11)。

画像11は脅威アクターが外部アプリケーション実行に使っていたワークフローのしくみ。多数のコード行からなる
図11 外部アプリケーションを実行するワークフローのしくみ

このワークフローは外部ドメインからアクセスされるBashスクリプトを実行します。私たちが観測した最後の設計変更では、暗号通貨のマイニング機能をインストール・開始するコンテナを作成・実行していました(図12)。

画像12は脅威アクターがリモートのマイニング用コンテナを作成・実行したようすを示す多数のコード行からなるスクリーンショット。
図12. リモートのマイニングコンテナ設置

生成されたワークフローは64個のジョブを実行します。各ジョブは一意な構成を5つ与えられており、そこから1つをランダムに選んでいました。

最終的な設計でこのしくみがどの程度有効に機能したかは評価していません。ただし調査ではこのアクターが3ヶ月間で作りえたGitHubアカウントを多数回収できました。

次の図13のグラフはこのシステムを動かしてGitHubに作成したアカウントに関する統計情報です。すべてのGitHubアカウントが同一設計メカニズムで作成されたかどうかわからない点に留意する必要はありますが、この統計は実際にアクターのインフラが作成したアカウントを示しています。

このグラフはGitHubで作成が確認されたアカウントから推定したものです。なお、調査で確認できる範囲は限られていたので全アカウントを網羅することは意図していません。

画像13は、PurpleUrchinアクターが作成したGitHubのアカウント数を示すグラフ。2022年9月や10月と比べ、同年11月の作成数が激増している。
図13. PurpleUrchinのアクターが作成したGitHubアカウント数

以前の攻撃キャンペーン、2020年〜2021年

2021年にアクターが好んで利用したクラウドサービスの1つが、クラウドアプリケーションプラットフォーム(CAP)を提供するHerokuです。こうしたプラットフォームを使えば、アプリケーションを作成・デプロイするのにユーザーがホスティング用クラウドインフラを維持する必要がありません。PurpleUrchinのアクターはこの機能をオペレーション全般に活用していました。

収集したコンテナ内のデータを分析した結果、Herokuプラットフォームで作成されたアカウントは全部で10万723件(重複なし)特定されました。図14のグラフはHerokuでのアカウント作成数推移を年月別に示したものです。

画像14はHerokuクラウドアプリケーションプラットフォームで作成された重複なしのアカウント数を計測したグラフ。全部で10万723件のアカウントが確認された。計測範囲は2022年7月から11月まで。
図14 Herokuのクラウドアプリケーションプラットフォームで作成されたユニークアカウント数

上のグラフがもわかるとおり、このアクターは少なくとも2021年11月にはHerokuを使って活動していました。

このアクターはLet's Encryptサービスで証明書を複数作成し、生成されたドメインにそれらの証明書を使っていました。ここから私たちは「2020年の早い時期にオペレーションが開始された」と中程度の確度で評価しています。それらのドメインの1つlinux84[.]distro[.]cloudns.clでは2020年11月17日を発行日とするSSL証明書を使っていました(図15)。

画像15はlinux84.distro.cloudns.clのSSL証明書のスクリーンショット。
図15. linux84.distro.cloudns.clのSSL証明書

結論

フリージャッキング攻撃キャンペーン「PurpleUrchin」の背後にいるクラウド脅威アクターAutomated Libraは、HerokuやGitHubなどの無料または使用制限のあるクラウドプラットフォームに13万件以上のアカウントを作成していました。彼らはこれらのプラットフォームからクラウドリソースを不正に窃取する行為にも手を染めていました。

Automated LibraはCI/CDオペレーションとインフラアーキテクチャを常に改善して次の行為を行います。

  • アカウント作成時にGitHubが提示するCAPTCHAを避けるまたは解く
  • 1分間に作成できるアカウント数を増やす
  • リソースへのアクセスを失う前に可能な限り多くのCPU時間を使う

Automated LibraがCD/CIツールを最大限活用するインフラを設計している点には留意する必要があるでしょう。従来型VSPがサービスポートフォリオを拡張してクラウド関連サービスを含めるようになってきたことから、時間がたつにつれ、こうしたインフラの設計がやりやすくなってきています。これらのクラウド関連サービスが利用できるようになったことで、アプリケーションをデプロイするインフラを維持する必要がなくなり、状況は脅威アクターに有利になっています。多くの場合、コンテナをデプロイするだけでことたります。

PurpleUrchinはフリージャッキングのクリプトマイニングオペレーションですが、Automated Libraは計算資源へのアクセスを得るためにプレイ&ラン戦術も採用しています。Automated Libraのアクターは割り当てられた時間や金額いっぱいまでこれらの使用制限のあるクラウドリソースを使い、使いきったところで利用をやめます。未払い金が発生することも多いですが支払いはしません。

パロアルトネットワークスのPrisma Cloudを使うと、クラウドリソース、とくにコンテナ環境で開始されたリソースの使用状況を監視できます。また、デプロイ前に全コンテナをスキャンして脆弱性や不正利用がないかを確認し、それらコンテナのランタイム状態を監視できます。これにより、クラウド環境内でのAutomated Libraによる活動の継続を抑止できます。