2019 年 4 月 12 日 Emil Hozan 著

ウォッチガードは先日、2018 年第 4 四半期版インターネットセキュリティレポート（ISR）を発表しました。ISR では、マルウェア攻撃、IPS ヒット数、主なセキュリティインシデントに関する興味深い詳細情報に加えて、脅威研究のセクションでは、Exobot マルウェア攻撃を取り上げ、詳しく解説しています。ISR の概要については、The 443 Podcast でもご紹介していますが、この記事では、レポートの解説をそのまま紹介することではなく、脅威ラボのチームと私が手に入れたソースコードの分析をどのように進めたのかを解説します。

Exobot が何であるかを理解していただくため、レポートでも説明した、このマルウェアの概要を最初にご紹介してから、サーバのセットアップ時に実施した、サーバのデバッグについて説明します。このマルウェアパッケージの機能については ISR で詳しく説明されているため、Android アプリケーションの部分について詳しく知りたい方は、この記事の後に ISR をぜひお読みください。

Exobot の概要

Exobot の作成者は 2016 年に、オンラインで販売する目的で、いくつものハッカーフォーラムやダークウェブでバージョン 2 のソースコードを公開しました。Exobot は、Android デバイスを標的とする高度なボットネットパッケージで、我々が分析した亜種は、標的から除外する国を指定するリストを使うことで、攻撃の標的をいくつかの国に限定していました。Exobot は金融機関を標的にするトロイの木馬でもあることから、バンキングアプリやその他の金融サービスを主な標的としており、オーバーレイ攻撃を使用しています。オーバーレイ攻撃では、既知のアプリを検知し、ユーザ名やパスワードなどのユーザが入力した情報を傍受する目的で、アプリの実際のユーザインタフェース（UI）の上に目に見えないインタフェースを「オーバーレイ」します。Exobot は、システムレベルのアクセスを付与する管理機能セットである、Android の DevicePolicyManager API も悪用して、アンチウイルスプログラムを無効にするなどの不正行為を実行します。

たとえば、ユーザが非公式の Android リポジトリからサードパーティのアプリケーションをダウンロードすると、Exobot も誤って入手してしまう可能性があり、ユーザがいつも利用している金融機関のモバイルアプリケーション（またはマルウェアが認識しているその他の金融取引アプリケーション）を開くと、Exobot がそのアプリケーションを検知して制御を手に入れ、正規のアプリケーションの上に目に見えないウィンドウをオーバーレイします。そして、ユーザがログインフォームに自分の認証情報を入力すると、Exobot のオーバーレイが入力された情報をキャプチャし、攻撃者に送信します。

Exobot の開発者は、このマルウェアを売り出す前に、レンタルサービスとして提供し、顧客が週単位あるいは月単位でサービスを購入して利用できるようにしましたが、現在は、技術的な知識がある人であれば誰もが流出したソースコードをダウンロードして手を加え、新しいマルウェア攻撃を開始できます。

シェル構造

パスワードを復号化してコンテンツを展開すると、exo、loader、socks という 3 つの主要ディレクトリが作成されます。

exo ディレクトリ

exo ディレクトリには、マルウェアのエコシステム全体が格納されており、これには、正規のアプリケーションフロントエンドの不正バージョン、さらには、ユーザや管理者が使用するバックエンドパネルも含まれます。exo には、以下のディレクトリがネストされています。

• backend_server
  ここには、コマンド＆コントロール（C2）インフラストラクチャが格納されており、これには、顧客がボットとやり取りするためのパネルや管理パネル、さらには、コンパイル済み APK が含まれます。
• frontend_server
  バックエンドを別のフロントエンド Nginx プロキシの背後に隠す目的で使用されます。
• builder_server
  顧客のアカウントやボットのテンプレートの管理、APK のビルドに使用します。

図 1：README.txt ファイル – 各サーバの目的が記述されている

loader ディレクトリ

• bot
  不正 Android アプリケーションのソースコード
• panel
  バックエンド Web サーバのファイルとボット管理データベースをセットアップするためのスクリプトが含まれています。

パネル構造は完成形ではないようであり、他のさまざまなスクリプトで使用されるボットデータベースを作成するためのファイルが同じディレクトリにありますが、ファイルそのものは空です。

socks ディレクトリ

最後の socks ディレクトリには、攻撃者が感染デバイス経由で SOCKS プロトコルを使用してプロキシに接続するための別のモジュールが含まれています。このディレクトリには、以下のサブディレクトリが存在します。

• android_service
  ボットクライアントに埋め込むことができる Android SOCKS サービスのソースコードで、攻撃者はこれを使用することで、Android の感染デバイス経由でネットワークトラフィックを迂回させることができます。
• linux_server
  ここには、そのまま展開できる、構築済みのサーバの例が含まれています。
• php_panel_example
  ボットパネルの古いバージョンのすべてのファイルが含まれています。

入手したソースコードサンプルに含まれるファイルとディレクトリの正確な数は表 1 の統計のとおりですが、同じディレクトリが複数の場所にネストされている場合もあります。

この記事では、Exobot の詳細をいくつかのセクションに分けて説明し、その中でも、exo ディレクトリの backend_server ディレクトリについて詳しく説明し、frontend_server ディレクトリについても簡単に説明します。また、管理パネルのバックエンドと顧客用パネルについてもバーチャルツアーで紹介します。ボットクライアントそのものの機能の詳細については、この記事の最初の段落のリンクから第 4 四半期版 ISR にアクセスし、参照してください。

バックエンドサーバ

最初の backend_server ディレクトリは、Exobot のソースコードのほぼ中核と言えるものです。SETUP.txt ファイル（README ファイルに似ています）にバックエンドサーバのセットアップに関するガイダンスが記述されていますが、セットアッププロセスの説明はあまりわかりやすいものではありません。このファイルは、以下の 4 つの主要パートに分けることができます。

• Server setup
  バックエンドサーバに割り当てる必要があるサーバリソースやインストールするソフトウェアパッケージに関する詳細
• Structure
  ルートディレクトリ内の他のファイルやネストされているディレクトリの説明
• Setup
  サーバの実行に必要なプロセスの詳細
• Admin panel usage
  サーバの起動時に実行する処理や Web アプリのレイアウトの説明

backend_server のコンテンツを図示すると、図 2 のようになります。これ以外の最上位のディレクトリとしては、apache_ip_block（バックエンドサーバへのアクセスを却下する IP アドレスのリスト）、sites-enabled（Web ページのサービスに必要な構成ファイル）、SQL（データベースの作成に必要なコンテンツが保存されています）、www（World Wide Web を意味し、Web サーバ経由で処理されるコンテンツが保存されています）があります。

これらのコンテンツについては後述しますが、名前からおおよその役割は判断できるはずです。ルーズファイルとしては、「backend_backup.sh」、「customers.passwd」、「INSTALL.sh」、「panel.passwd」、「remove_logs.sh」、「SETUP.txt」があります。

図 2：backend_server にネストされているコンテンツ

SETUP.txt の処理

本セクションでは、SETUP.txt を上記の 4 つのパートごとに説明します。

サーバのセットアップ

手順 1：

表示される 3 つの手順のうちの 1 つは、すべてのコンテンツを「/var/data」という名前の新しく作成されたディレクトリに移動するためのものです。

手順 2：

次に、必要なソフトウェアをインストールします（図 3 を参照）。

図 3：サーバの実行に必要なパッケージ

パッケージのインストールと Apache2 モジュールの有効化

現在のディレクトリに INSTALL.sh という名前のファイルがあり、その名前から、サーバを起動して実行するためのスクリプトであると推察できます。ファイルを開いて確認すると、わかりやすい記述のインストールスクリプトが見つかり、いくつかのパートに分かれているため、簡単に処理を理解できます（図 4 を参照）。最初がインストールする必要があるソフトウェアで、有効化する必要がある 3 つの Apache モジュールがそれに続き、さらに、rewrite（URL の操作を許可にします）、ssl（セキュア Web ソケット通信）、rpaf（Reverse Proxy Add Forward）と続きます。

図 4：コマンド、インストールする必要があるパッケージ、有効化する Apache Web サーバモジュール

実行を自動化するために、execute 属性をスクリプトに追加してから実行してみましたが、エラーが発生したため、トラブルシューティングが必要になりました。その結果、このソースコードは数年前に発表されたものであり、それ以降にいくつかの必要なパッケージが更新されたり、おそらくは非推奨になったりしたために（少なくとも、php5 はこれに該当します）、エラーが発生したことがわかりました。

図 5：PHP5 をインストールしようとすると表示されるエラーメッセージ

PHP は Web 開発でよく使用されるスクリプト言語であり、幸いにも、「5」を削除して「apt-get -y install php」にして実行しただけで簡単に修正でき、PHP 7.0 がインストールされました。最後に、記述されている Apache モジュールを有効化して、INSTALL.sh のサーバセットアップ部分を完成させました。

PHP と Apache2 の構成変更

インストールスクリプトの調査を続けたところ、PHP 5 に依存する構成ファイルの変更点がいくつかあったため、PHP 7 のディレクトリ構造に合わせて変更しました。具体的には、1 つは一部のコンテンツアップロード送信の制限を上げるためのもの、もう 1 つは PHP エラーの表示を有効にするためのものです。この変更にあたっては、変更するファイルのバックアップを作成してから修正を始めました。次に、Apache に関する変更として、サーバの Web リスンポートを調整し、サイトの構成ファイルが保存されているディレクトリ（Web サーバのルートディレクトリ）を変更しました。最初に説明したとおり、メインディレクトリには sites-enabled ディレクトリが存在します。最後に、apache2ctl restart コマンドで Apache サービスを再起動し、変更を有効にしようとしましたが、ここでも図 6 に示すエラーメッセージが表示されました。

図 6：Apache Web サーバを再起動しようとすると表示されるエラーメッセージ

この画像にあるように、「SSLv3 not support by this version of OpenSSL（このバージョンの OpenSSL では SSLv3 はサポートされていません）」というエラーが表示されて、Apache のサービスを再起動できませんでした。sites-enabled ディレクトリにネストされている 2 つの構成ファイル（../bot.conf と ../cp.conf）をそれぞれ開くと、サポートされている SSLProtocol が表示されているセクションが見つかりました（図 7 を参照）。

図 7：OpenSSL サーバでサポートされている暗号化プロトコル

ログディレクトリの作成と匿名性の追加

次に、構成ファイルの説明に従って、/var/data/ にログファイルを保存するための logs/ ディレクトリを作成し、このディレクトリに対するユーザ権限を www-data ユーザ（Apache サービスに関連するアカウント）に合わせて調整しました。匿名化に関するこれ以外の手順として、ログイン追跡を無効にし、SSH キーの変更を却下するようにしました。

最後の重要な手順として、コントロールパネルに管理者としてアクセスし、オプションで顧客用パネルにアクセスできるようにするために、いくつかの認証情報をセットアップする必要がありました。

手順 2：この手順はこれで終了です。

手順 3：

最後の手順で、/var/data/ のコンテンツを暗号化するか、あるいはシステムのハードドライブでサポートされている場合はディスク暗号化を使用するよう推奨されていますが、制御された環境で実行するという前提で、この手順は省略します。

手順 3：この手順はこれで終了です。

構造

本セクションでは、ルートディレクトリ内のコンテンツと各ファイルまたはディレクトリの目的の説明が記述されている SETUP.txt の詳細を説明します。図 2 の説明で簡単に述べましたが、ここでは、www ディレクトリに注目し、詳しく見てみることにしましょう。

このディレクトリには、以下の追加サブディレクトリが含まれています。

• apks
  （Android パッケージ）顧客用の APK ファイルが保存されています。
• base/bot/
  顧客ごとに固有の構成に基づいて顧客用パネルをレンダリングするために使用するスクリプトが含まれます（顧客の専用ディレクトリに自動生成されます）。
• bot
  このディレクトリは、Apache がボットクライアント要求を転送するデフォルトディレクトリとして bot.conf
• 構成ファイルで構成されていますが、www の名前のクライアントの別のディレクトリにシンボリックリンクされています。
• clients
  顧客ごとに固有のすべての構成が保存され、新しい顧客の実際のテンプレート構造が保存される場所。
• cp
  バックエンド制御パネルそのものがここに保存されます。

セットアップ（および、バックエンドコントロールパネルの概要）：

本セクションでは、上記の INSTALL.sh スクリプトについて説明しますが、セットアップする他のプロセス、主として、いくつかのリソースに対する認証アクセスが必要とされるプロセスについて詳しく解説します。これには .htaccess と呼ばれるファイルが使用され、このファイルで、Apache Web サーバのさまざまな設定を指定しますが、その 1 つが、認証要件の設定です。顧客用（customer.passwd）とバックエンド管理パネル（panel.passwd）のアクセスに一意のパスワードファイルが必要です。

これ以外に、SQL フォルダに移動して README.txt ファイルの記述を調べて必要な手順を実行する手順がありますが、これについては別のセクションで説明するため、ここでは説明を省略します。ここで、既に存在する TestUser アカウントに対応する構成ファイルで編集し、2 箇所を変更する必要があります。1 つ目は、対応するユーザのデータベースの情報の変更で、これについては SQL ディレクトリに関する別のセクションで説明します。もう 1 つは、前述の /base/bot/ ディレクトリへのディレクトリパスを確立するための変更です。

データ構造の何も削除しないようにと明確に記載されており、削除すると、バックエンドパネルや顧客用パネルのアカウントのすべての機能が動作しなくなる可能性があります。さらに、Android OS の開発を可能にするために C++ 標準ライブラリ（libc++.so）を有効にする方法の記述もあります。そして最後に、Apache2 に対して、自分の仮想ホストファイルが保存されている /var/data/sites-enabled/ ディレクトリを指示する必要がありました。これ以外にもかなりの作業が必要でしたが、以上の手順によって、少なくともコントロールパネルを表示し、動作させることができました（図 8）。

図 8：デバッグ前に Exobot の管理パネルの概要を理解する

管理パネルの使い方：

前のセクションで説明を省略した部分（少なくとも SQL の詳細）があるため、図 8 で説明した SETUP.txt の最後のセクションでは、いくつかの異なるメニューオプション、すなわち、[Add customer（顧客の追加）]、[Customers（顧客）]、[Backups（バックアップ）] などについて簡単に紹介することにします。ほとんどのメニューオプションの機能は一目瞭然ですが、例外として、[Injects list] については、スクリーンショットと編集フォームのすべてのインジェクションを表示するオプションだという説明が必要でしょう。データベースが稼働を開始したら、ここに戻る必要があります。

データベースのセットアップと認証要件の構成

データが保存され、永続的に利用できなければ、どのようなアプリケーションもほとんど機能しません。上記のセクションで説明を省略した SQL ディレクトリは、単独で 1 つのセクションとして説明する価値があるものです。このディレクトリには、README.txt ファイルと 3 つの .sql 実行ファイル（blank_bot、general、is_online）が存在します。本セクションでは、これらの実行スクリプトごとに作成されるデータベースについて説明します。

blank_bot.sql

このマルウェアインフラストラクチャは、マルチテナントをサポートしているため、それぞれのユーザアカウント（顧客）が専用のボットネットワークを管理でき、このファイルには、新しいユーザの追加にあたってサーバが作成する必要があるすべてのテーブルのテンプレートが含まれています。作成されるテーブルを図 9 に示します。

図 9：「blank_bot.sql」の実行時に作成されるデータベーステーブル

最も興味深いものの 1 つであるボット（bot）は、感染した Android 携帯からさまざまな情報を取得し、保存します。具体的には、電話の IMEI 番号、IP アドレス、国、マルウェアが管理 API にアクセスできたかどうかなどの 20 を超える情報を取得して保存します。

t_cards テーブルには、名前、住所、誕生日、さらにはそれ以外の多数の個人を識別する属性などの、携帯電話のユーザに関する個人情報が保存されます。

最後の bot_tasks テーブルには、コマンドサーバが感染した Android 携帯に送信する、保留状態のコマンドが保存されます。

is_online.sql

この短いファイルには、ボットの最終チェックインからのタイムスタンプをチェックすることでボットがオンラインかどうかを確認する SQL 関数が含まれています。

general.sql

このファイルは、ボットの感染と回避の機能に関連するテーブルを生成します。マルウェアが標的にできるアプリ、ブロックできるアンチウイルス（AV）やセキュリティプログラムといったさまざまな情報を保存するテーブルが作成されます。

作成されるデータベーステーブルを図 10 に示します。

図 10：「general.sql」の実行時に作成されるデータベーステーブル

この中で特に興味深いのが minim_apps_list テーブルで、ここに登録されているアンチウイルス（AV）製品であれば、ボットアプリを常に最小化して検知を逃れることができます。AV 製品の例としては、AVG、Avast、BitDefender などがありますが、全リストについては、2018 年第 4 四半期版 ISR の付録 A を参照してください。

もう 1 つの興味深いテーブルである injects には、ボットネットがオーバーレイする、金融機関、ショッピング、ソーシャルメディアのサイトのリストが保存されており、その数は 150 近くに上ります。全リストについては、ISR の付録 B を参照してください。Web サーバはこのリストを使用して、Exobot の潜在的な標的を顧客に提示します。

管理ユーザの更新

最後に、新規ユーザの作成時に設定されるパスワードと一緒に使用される、自動生成されるソルト値があります。ソルト値とは、ユーザが希望するパスワードとして入力した値に追加される文字列値です。この 2 つがハッシュアルゴリズム（md5）を使用して処理され、保存されて、以降の呼び出しと検証で使用されます。こうすることで、平文のパスワードが保存されるのを防ぎ、一意のソルト値によって文字列を追加することで、ハッシュ値の重複の可能性を排除します。

当然ながら、ハッシュ値から返されるのは一意のハッシュ値であり、2 つのハッシュが同じになることはないはずですが、2 人のユーザが同じパスワードを使用したとしても、ソルト値が異なることで、同じパスワードに対して同じハッシュが重複することはなくなります。

トラブルシューティング

トラブルシューティングの過程で、データベースにアクセスするために root ユーザを指定する箇所がいくつかありました。root ユーザとは Linux ベースのシステムのスーパーユーザですが、残念ながら、このユーザで MySQL データベースに直接アクセスする機能は、現在は PHP でサポートされていません。

PDO（PHP Data Objects）と呼ばれる、PHP がデータベースとやり取りするためのインタフェースがあり、現在は非推奨である MySQL に代わる MySQLi の関数と組み合わせて使用されます。必要な情報を更新し、予め設定されているユーザ（TestUser/panel2）によるデータベースアクセスを修正すると、図 11 のようになります。

図 11：バックエンドサーバのセットアップ後のスクリーンショット（ただし、エラーを完全にトラブルシューティングする前の状態）

最終的なスクリーンショット

これまでの説明にあるように、調査したソースコードは、「実行すればインストールが完了する」という単純なものではなく、上記の手順を実行したところ、修正を必要とするエラーがいくつも発生しました。図 11 でわかるように、すでにいくつかのエラー（/usr/lib/… エラーは省略した手順です）が表示されていますが、他のどのメニューオプションをクリックしたとしても、無視できないエラーメッセージが表示されます。

ほとんどのエラーは、ログに問題があるといった単純な理由によるものででしたが、それ以外に、構文的には正しいものの、意味的に正しくないエラーが発生しました。すなわち、コンテンツはレンダリングされるものの、コンテンツが本来の形で表示されず、admin バックエンドパネルを構成している多数の異なるコンポーネントを手動で見直す必要がありでした。そして、これらすべての作業の実行後に、コードを正しく動作させることができました。

図 12 に示すように、バックエンド管理アクセスの許可にあたっては、Apache Web サーバから認証が要求されます。これは、Web サーバそのものからの認証の要求であり、Web アプリケーションからの要求ではありません。

図 12：バックエンド管理パネルへのアクセスにあたって、Apache からユーザ認証が要求される

管理者は、図 13 に示すランディングページから顧客用 Web ページに移動し、プラットフォームのスペースを貸し出している顧客の概要を参照できます。

図 13：バックエンド管理パネルのランディングページ

図 14 は、Exobot に含まれ、オーバーレイ攻撃の標的にすることができる既知のアプリケーションのサンプルリストです。ただし、事前にロードされるアプリケーションの全リストというわけではありません。

図 14：[Injects list] メニューオプション – サンプルアプリケーション

顧客用管理パネル

バックエンドの詳細を構成できたので、今度は、顧客用ログインポータルの機能を見てみることにしましょう。顧客向けには、主として 3 つのビューが提供されています。1 つ目のボットアクセスには、モバイルアプリケーションとバックエンドパネルとの通信が表示され、2 つ目の統計アクセスには、利用状況の統計と関連する詳細が表示され、3 つ目のパネルアクセスには、不正アプリケーションによって収集された情報が表示されます。

図 15 は、Apache Web サーバによって表示される顧客用認証画面です。図 16 に示すように、Web アプリケーションによってユーザ認証が要求されます。

図 15：バックエンド顧客用パネルへのアクセスにあたって、Apache からユーザ認証が要求される

図 16：顧客用パネルのログイン画面

上記の 2 つの図を比べると、2 つの異なるユーザ名が使用されているのがわかります。これは、Apache 認証が特定のユーザに関連しているためであり（認証にあたっては、customer.passwd ファイルがチェックされます）、顧客用パネルのユーザ名は、ハードコーディングで「admin」に指定されています。また、このパスワードは Apache と顧客用ログインでは異なり、ユーザアカウントごとに異なるデータベースが作成され、後者が顧客に公開されることはありません。このパスワードは、Apache へのアクセスとパネルアクセスのアクセスにのみ使用されます。

図 17 に示す顧客用ランディングページがレンダリングされると、メニューオプションがいくつも表示されます。ほとんどは名前から機能を判断できるものですが、少し詳しく見てみることにしましょう。

図 17：認証後に表示される顧客用パネルのランディングページ

図 18 は My Injects メニューオプションを、図 19 は Extras メニューオプションを展開したものです。顧客が攻撃の標的にしたい地域に応じて、国（トルコやルーマニアなど）、ソーシャルネットワークやメッセージングのアプリ、さらにはカスタムアプリに対応するアプリが表示されます。この表示とブロックされる IP の長いリストが存在することから判断すると、これが標的型マルウェア攻撃であるのは明らかです。攻撃の標的にする地域ごとに、その地域で利用されているアプリケーションが表示されます。

図 18：顧客用パネルでオーストリアを選択した場合の「My injects」メニューオプション（傍受可能なフィールドが表示される）

図 19：「Extras」/「Get more injects」

図 20 に示す「Inject packs」には、標的として対応している国ごとのパッケージがすべて表示されます。

図 20：追加料金で利用できる国ごとの「Inject packs」

frontend_server の概要

このサーバの機能はかなり限定的であり、ここに存在するのは、SETUP.txt ファイル、setup_client_vps.sh スクリプト、自己完結型の backend_server の複製だけでした。

最初の SETUP.txt ファイルの構成要素は、このサーバに割り当てるリソースだけであり、バックエンドパネルがアクセスできる本当のバックエンド IP アドレスをここに入力してから、関連するインストールスクリプトを実行します。インストールスクリプトである setup_client_vps.sh スクリプトで必要なパッケージは、nginx-full と openssl だけです。次に、SSL 証明書を作成してから、ssl 構成ファイルに合わせてデフォルトの Nginx 設定を上書きします。このファイルにバックエンドサーバの本当の IP アドレスを入力しますが、ヘッダ定義もいくつか存在します。そして、このスクリプトの最後のセクションは、匿名性と Nginx のアクセスログとエラーログの無効化に関する記述です。

frontend_server の内容は以上であり、構成は簡単なものでした。ソースコードのコンテキストとエコシステムから判断すると、顧客ごとに異なる専用のフロントエンドアクセスポイントを作成できるようであり、そうすることで、複数のユーザが同じフロントエンドを使用するのを防止でき、バックエンドサーバの実際の場所を隠すこともできます。また、ある顧客のこの MaaS（Malware-as-a-Service）のレンタル期間が終了した場合も、サーバを削除するだけですみ、他のユーザへの影響を心配する必要はありません。

まとめ

セキュリティの防御側と攻撃側が高度化を競う中で、学習曲線も変化し、マルウェアの開発者が提供する MaaS（Malware-as-a-Service）も登場しています。Exobot がそうであるように、技術的な知識がある犯罪者がマルウェアのエコシステム、すなわち、バックエンドサーバ、バックエンドサーバと感染デバイスの通信手段、さらにはスキルセットが必要とされるあらゆる要素をプログラミングし、技術的な知識を持たない犯罪者にプラットフォームを提供することができます。

そのようなサービスがあれば、攻撃を始めるにあたって、技術的な知識は必要ありません。攻撃を仕掛けたいと考える犯罪者に必要なのは、マルウェアを拡散することだけであり、ソーシャルエンジニアリングや大量のスパムメールの添付ファイルやリンクを攻撃手段として悪用します。

MaaS は、今では珍しいものではなくなりました。ダークウェブに実際に侵入して調べてみましたが、Exobot と同じような機能を持つ、新しいサービスが見つかりました。決まった金額のビットコインを払えば、プラットフォームのスペースを一定期間レンタルできます。最近の調査では、公開されているソースコードのサンプルは見つかりませんでしたが、いずれかの段階で見つかるのではないでしょうか。