PYSA で多用される ChaChi：新しい GoLang RAT

図 1 - ChaChi が遂げた進化のおおよそのタイムライン

私たちの推定では、ChaChi が最初に開発されたのは 2019 年の半ば以降です。実際の開発時期は、2020 年の初めである可能性が高いと思われます。

2020 年の第 1 四半期の攻撃で最初に確認された後、3 月後半または 4 月前半に ChaChi のコードは難読化と永続性を組み込むために変更されました。その直後に、DNS トンネリングとポート転送/プロキシ機能を追加した ChaChi 亜種が出現するようになりました。それ以来、特筆すべき変化はほとんどありません。

難読化

Golang マルウェアは何年も前から存在していますが、このマルウェアの難読化は今でも比較的まれです。Ekans ランサムウェアは、2019 年 12 月に Go の新しい難読化手法を 利用した ように思われますが、この時点ではこの手法に明確な名前は付いていませんでした。

2020 年末、調査担当者は Go で作成された ELF バックドアである "BlackRota" を発見したことを 報告 しました。調査担当者は、BlackRota が「これまでに発見した中で最も難読化された Go 言語による ELF 形式のマルウェア」であると宣言しました。

Ekans、BlackRota、その後の ChaChi で使用されている難読化は "gobfuscate" でした。この Golang 難読化ツールは GitHubで公開されています。BlackBerry のアナリストは、Ekans のリリース直後、BlackRota を発見する数か月前に gobfuscate を積極的に使用している ChaChi のサンプルを確認しました。

gobfuscate は、難読化された多くの情報の復元をきわめて困難にしようと試みます。これらの情報は、通常なら調査担当者が容易に利用できるものです。このツールは、ランタイムシンボルテーブルとタイプの情報（パッケージ名や関数名など）を難読化します。これは、ランダムに生成された名前でこれらの名前を置き換えることで行います。さらに、文字列を関数に置き換えることで文字列を難読化します。

図 3 - gobfuscate で難読化され、関数に置き換えられた文字列

この難読化は、文字列、パッケージパス、フィールド名といった Go ソースコードの関連情報が漏れないように配慮して設計されました。その後、解析やリバースエンジニアリングの取り組みを妨害する手段として、マルウェアの作成者が採用しています。

予防を回避するツールとして gobfuscate が認識されて以来、いくつかの試みが大きな成功を収めています。Binary Ninja と Cutterのプラグインを使用して、文字列の難読化を自動的に解除する方法を解説したブログ記事も作成されています。とはいえ、この記事の執筆時点では、このようなプラグインやスクリプトは IDA には存在しません。

BlackBerry のアナリストは、内部ツールの IDAPython スクリプトを開発しました。gobfuscate で難読化された文字列の難読化解除に対処し、その後に行われる、gobfuscate で難読化されたバイナリの解析に要する時間を短縮することが目的です。IDA にロードされた ChaChi バイナリに対して、この難読化を解除するスクリプトを実行すると、すべての文字列デコード関数の検索、エンコードされたバイトの抽出、必要な XOR 演算が実行され、元の文字列が復元されます。その後、これらの文字列は、すべてのデコード関数内での名前変更に使用されます。その際、エンコードされた文字列が検知され、必要に応じて逆アセンブリコードビューにコメントが追加されます。

図 4 - gobfuscate で難読化された文字列関数の難読化解除

gobfuscate を使用した文字列の難読化を克服しても、ランダムに命名されたパッケージなどの問題がまだ残っていました。表面的には、名前の難読化は解析に対する効果的な抑止手段であるように思われます。しかし、さらに詳しく調査すると、解決が特に難しいというわけではありませんでした。

パッケージ名の変更は、統一された一貫性のある方法で行われます。たとえば、同じパッケージや関数のコンポーネントは同じランダム名を共有するといった具合です。この知識と、関数メソッドの名前は難読化の影響をほとんど受けないという事実を結びつけます。その結果、特定のパッケージの使用法さえ突き止めれば、シンプルな IDAPython ヘルパースクリプトを使用して、同じランダム名を共有しているすべてのエントリの名前も変更できることが分かります。

図 6 – gobfuscate で難読化された関数名の難読化解除

文字列の難読化を克服したので、ChaChi の機能と意図を分析する作業に再び取り組みます。

永続性

最初の実行後すぐに、ChaChi はサービス名とサービスの説明をデコードします。

図 7 - サービスの名前と説明のデコード

デコードされたサービス名を使用して、ChaChi はインストールされているすべてのサービスを列挙し、同じ名前のサービスがすでに存在するかどうかを確認します。この例では、"JavaJDBC" という名前が付けられています。指定された名前を持つサービスが見つかると、ChaChi は、ハードコードされたサービス名の文字列リストの中から別の名前をランダムに選択します。ただし、このリストは gobfuscate で難読化されています。

図 9 - 代替サービス名のデコード

サービスのインストールに使用する適切な名前が決定すると、ChaChi は、そのサービスの作成操作を実行する十分な管理者特権があるかどうかを確認します。

図 10 - 管理者特権で実行されているかどうかを確認

管理者特権で実行されていない場合、ChaChi はその永続性コードをバイパスし、コマンドアンドコントロール（C2）通信の初期化を開始します。このバックドアが管理者特権で実行されている場合は、それ自体を新しいサービスとしてインストールします。このサービスは、手動でサービスを開始する前に自動的に開始されるように設定されます。

図 11 - サービスとしてインストールしてサービスを開始

C2 通信

ChaChi は、DNS と HTTP の 2 つのプロトコルを C2 通信に使用します。C2 通信における第一の優先方法は、TXT クエリを使用した DNS トンネリングです。

TXT すなわち「テキスト」レコードの本来の目的は、ドメイン管理者が任意のテキストをドメインと関連付けられるようにすることでした。たとえば、ドメイン所有権やネットワーク、サーバーなどの情報です。脅威アクターは不正なニーズのためにこれを巧みに利用し、TXT クエリでデータをエンコードしました。その形態が DNS トンネリングです。

DNS トンネリングにより、マルウェアの作成者は、ほとんどのファイアウォールをバイパス可能な隠れチャネルで通信することができます。DNS トラフィックは広く使用されており、ほとんどまたはまったく監視されずに無条件で信頼される傾向があります。さらに、DNS 要求は内部の DNS リゾルバでプロキシ化することもできます。これにより、感染したエンドポイントの追跡はさらに困難になります。

図 12 - ChaChi によって生成された DNS トラフィック

何らかの理由で DNS 通信に失敗した場合でも、ChaChi にはフェールオーバーのメカニズムが組み込まれています。そのため、エンコードされた POST 要求の形で HTTP を使用して C2 サーバーと通信できます。一般に、HTTP POST 要求は、リソースを作成または更新するサーバーにデータを送信するために使用されます。ChaChi は、この要求を C2 通信のために使用します。C2 通信の確立を試みる前に、ChaChi は埋め込まれている C2 サーバーのドメインと IP アドレスを最初にデコードする必要があります。

C2 の IP とドメインのデコード

ChaChi には、DNS トンネリングにおける C2 ドメインのリストと、HTTP C2 フェールオーバーにおける IP アドレスのリストが事前設定されています。これらのドメインは、gobfuscate で難読化されたバイナリの他のすべての文字列と同様にエンコードされており、これには XOR デコードプロセスを実行する専用の関数が使用されています。

図 13 - gobfuscate で難読化された関数からデコードされる C2 ドメイン

使用されるドメインは、"time.Now" の事前の呼び出しで返された値によってシードされる、"rand" パッケージの "Intn" を利用してランダムに選択されます。

図 14 - C2 ドメイン選択のランダム化

C2 IP アドレスのデコードは少し複雑になりますが、それほど大きくは変わりません。C2 ドメインと同様に、C2 IP アドレスの必然的な選択も "time.Now"、"rand.Seed"、"rand.Shuffle" の呼び出しによってランダム化されます。C2 IP のデコード関数は、いくつかの引数を必要とします。すなわち、エンコードされた C2 IP 配列へのポインタ、エンコードされた IP アドレスの数を示す整数値、それぞれの IP アドレスの各オクテットのデコードで使用される 16 進数です。C2 IP アドレスのデコード処理は次のように行われます。

• 初期オフセットの単語（2 バイト）を事前のシャッフルで決定した C2 IP 配列に読み込みます。
• 取得した値から 16 進数（確認されたすべての事例で 0xA）を減算します。
• 基準となる 10 の等価値に結果を変換します（これにより、IP の単一オクテットが作成されます）。
• エンコードされた IP ごとに 4 回繰り返します。
• デコードされたオクテットを "." で結合します（そうすることで、格納されている C2 IP アドレスは完全にデコードされます）。

これらの手順は、すべての IP アドレスがデコードされるまで繰り返されます。

デコード操作のための等価な Python コードを以下の図で見ることができます。または、エンコードされた 1 つの IP アドレスに対する CyberChef のレシピ操作の例を ここで 見ることができます。

図 15 - C2 デコードの Python コード

C2 アドレスがデコードされたので、ChaChi は C2 インフラストラクチャへの接続を開始できます。

変更された Chashell

完全にカスタマイズされた方法で DNS トンネリングを実装する代わりに、マルウェアの開発者は既成のソリューション（または、少なくともソリューションのコンポーネント）を利用することを選びました。マルウェアの開発者は、DNS 経由でリバースシェルを提供す Chashell と呼ばれるパッケージを使用しました。

Chashell の役割は、対称暗号化を使用して XSalsa20 + Poly1305 の形式でデータを暗号化する前に、シェルまたは端末からデータを取り出して プロトコルバッファ にシリアル化することです。その後、この暗号化データは 16 進でエンコードされ、TXT クエリにパックされます。TXT クエリへの応答にも同じプロトコルバッファのシリアル化、暗号化、16 進でのエンコードが適用されます。

図 16 - Chashell DNS トンネリングのクエリと応答

デフォルトの Chashell クライアントは、ビルド時にターゲットドメインと対称暗号化鍵を必要とし、いずれもハードコードされます。この 2 つは、Chashell サーバーへの暗号化された DNS トンネルを確立するために使用されます。接続が確立すると、ターゲットの OS に応じて "cmd.exe" または "/bin/sh" からの標準の入力/出力/エラーが DNS トンネルにリダイレクトされ、その結果、リバースシェルが作成されます。

図 17 - 標準の Chashell クライアントコード

ChaChi のオペレーターは DNS トンネリングのトランスポートメカニズムを Chashell から取り入れましたが、Chashell はもはや単純なリバースシェルとしては機能していません。それどころか、ChaChi のオペレーターはいくつか変更を加えることを選びました。その例として、リバースシェルを生成するデフォルト操作の除去や、DNS ストリームを通過する一部のデータに対するエンコード層の追加などが挙げられます。

事実上、Chashell は ChaChi という機械の歯車にすぎなくなっています。その結果、隠れた C2 通信が実現することになります。前述のとおり、DNS トンネルを通過するデータのすべてに追加のエンコードが施されるわけではありません。データは特定のプロトバッファフィールドのために確保されており、Chashell によって 5 つのフィールドが使用されています。

図 18 - Chashell プロトコルバッファのメッセージ

• ClientGUID: このフィールドは、特定のクライアントからのメッセージを一意に識別する ID です。これにより、メッセージはサーバーで正しく処理されます。ClientGUID フィールドは、すべてのメッセージに存在します。
• ChunkStart: このメッセージは、同じ「チャンク」に属するメッセージを識別するために使用されます。
• ChunkData: トンネルを通過するコアデータを転送するメッセージです。標準の Chashell の場合、標準ストリームの出力がこのフィールドに格納されます。これらのメッセージに含まれるデータは、"ChunkStart" メッセージが提供する情報に基づいて再構成する必要があります。
• PollQuery: これらのメッセージは、クライアントからサーバーに送られて、送信を待機中のコマンド/データの有無を照会するハートビートメッセージのようなものです。
• Infopacket:これらのメッセージは、アクティブな Chashell セッションの識別を容易にする手段として、クライアントのホスト名をサーバーに転送するために使用されます。このメッセージの特定の "packet" フィールドの "ChunkData" メッセージにのみ、標準の Chashell クライアントのソースコードには存在しない、追加のカスタムエンコードが適用されます。
  

図 19 - ChunkData メッセージの構造

"ChunkData" メッセージのエンコードは、プロトコルバッファへのデータのシリアル化の直前に行われます。このエンコードは 2 段階の処理で行われます。第 1 段階の処理では、データの Base64 エンコードを伴います。その後、このデータは別の関数に渡されて、ハードコードされた文字列を使用した XOR エンコードが実行されます。

図 20 - シリアル化に先立つ Base64 エンコードと XOR エンコード

データのエンコード、シリアル化、暗号化がどのように行われるのか理解したので、ChaChi トラフィックを復号可能にする難読化解除により、XOR 鍵と対称暗号化鍵を共に復元することができます。復号プロセスについては、追って詳しく説明します。確認および解析されたすべてのサンプルでは、"d*ck" （* は i に置き換えられる）の XOR 鍵が使用され、"37c3cb07b37d43721b3a8171959d2dff11ff904b048a334012239be9c7b87f63" の暗号化鍵が使用されていました。これにより、ChaChi バイナリが確認されたすべての攻撃の背後にいるのは、単独の脅威アクターまたは脅威グループであることがほぼ明確になりました。

代替/フェールオーバー C2

すでに述べたとおり、ChaChi は、Chashell DNSストリームを使用した DNS 経由の C2 通信をまず確立しようとします。この最初の試みに失敗すると、HTTP へのフェールオーバーが行われます。

図 21 - C2 通信のフェールオーバー

ChaChi のオペレーターにとって、このフェールオーバーは最適な方法ではありません。DNS トンネリングで利用できた暗号化は提供されず、隠れた通信にはほど遠いからです。

この HTTP C2 通信は、すでにデコードされている、ランダムに選択された C2 IP の 1 つに対する POST 要求を使用して実行されます。HTTP POST の内容は Base64 および XOR のエンコードを使用してエンコードされ、ある程度のデータ保護を提供します。これは、"ChunkData" メッセージにシリアル化される前にデータがエンコードされた DNS トンネリングの場合と同様です。

C2 のチェックインに失敗すると、デコードされた他の C2 IP を順番に試して接続を試みます。接続が確立されると、ChaChi は POST 要求をエンコードして C2 に送信し、その応答を処理します。

図 22 - HTTP POST 要求と応答処理

C2 トラフィックの復号

DNS トンネリングの場合と比べると、C2 通信での HTTP の使用はより単純で、必要とされる手順も少ないので、このセクションでは DNS トラフィックの復号に主に焦点を当てます。

HTTP と DNS の いずれの C2 トラフィックも復号できます。XOR 鍵と暗号化鍵を入手すれば、プレーンテキストのデータを受け取って暗号化形式に変換したプロセスの逆をたどることができるからです。エンコードと暗号化のプロセスの各フェーズは可逆的です。

図 23 - TXT クエリを生成するエンコードと暗号化のプロセス

復号するには、次の手順を実行します。

• パケットキャプチャまたは DNS ログから DNS TXT クエリを取得する。
• ドメイン名と区切り記号 "." を取り除く。
• 16 進数から元のバイトに文字列をデコードする。
• デコードした内容を、復元した暗号化鍵とともに XSalsa20+Poly1305 復号プロセスで実行する。
• "ChunkData" メッセージの packet フィールドにアクセスするために、復号したデータを非シリアル化する（他のメッセージタイプはこの時点で完全に復号）。
• 復元した XOR 鍵を使用して、各 "ChunkData" メッセージの packet フィールドに XOR デコードを適用する。
• XOR 演算の結果に Base64 デコードを適用する。

上記のプロセスを実行すると、復号および非シリアル化されたプロトコルバッファと、エンコードされて "ChunkData" パケットにパックされていた元のデータが得られます。Chashell のプロトコルバッファのメッセージ構造に関する私たちの知識を考慮すれば、必要なのは "ChunkStart" メッセージを求めてプロトバッファメッセージを検索することだけです。これらのメッセージは、元のデータを構成するチャンクの数の他、そのデータを含む正確な "ChunkData" メッセージについても知らせてくれます。

図 24 - ChunkStart メッセージの構造

この作業に成功すると（そして書式設定を適用すると）、ChaChi サーバーとクライアントの間でやりとりされる C2 トラフィックを復号できます。ChaChi のオペレーターが標準の Chashell ビルドを利用していた場合は、復号されたトラフィックの内容が以下のように表示されます。その内容から、リバースシェルが確立されていることは明らかです。

図 25 - 標準の Chashell から復号されて再作成されたトラフィック

C2 のチェックインとコマンド

C2 サーバーに送信される最初のチェックインデータは、次の形式をとります。

図 26 - C2 のチェックイン構造

"ID" はハードコードされた文字列値であり、サンプルによって異なりますが、通常は 1、2、または 9 で始まり、その後に 3 桁が続きます（例："1018"）。最後の 3 桁は gobfuscate で難読化された文字列からデコードされ、最初の桁はチェックインの直前にチェックイン文字列の先頭に追加されます。

MD5 ハッシュは、ランダムに生成された整数値をハッシュ化した結果です。この整数値は ChaChi を実行するたびに変わります。

コンピューター名とユーザー名は、関連する環境変数に格納されている値を取得する、2 つの PowerShell コマンドを実行すると得られます。

図 27 - PowerShell を使用したコンピューター名とユーザー名の取得

ID のみを含む 2 番目のチェックインが行われます。今回は、1 ではなく 2 が先頭に追加され、最初のチェックインと同じ MD5 が使用されます。2 番目のチェックインでは、コンピューター名やユーザー名は使用されません。どちらのチェックインでも、文字列のエンコードと暗号化は前述の方法で行われますが、個々のチェックインに対するそれぞれの応答によって次に何が起こるか決まります。

次の図は、2 つの C2 チェックインとサーバーからの応答を示しています。

図 28 - 復号された C2 チェックインと応答

スクリーンショットの上側には、最初のチェックインの文字列が表示されています。この最初のチェックインに対するサーバーからの応答は、チェックインで渡された、生成された MD5 ハッシュを含む文字列です。ただし、この文字列には "-zig" が追加されています。

この応答の最初の文字（この例では"9"）は、XOR 鍵の最初の文字で XOR されています。この文字は、C2 のエンコードプロセスでも使用されています（上記のトラフィックが生成されたサンプルの "d"）。この XOR 演算の結果は、2 番目の C2 チェックインに対する応答として返された最初の（この事例に限定）文字でさらに XOR されます（文字 "m"）。この 2 つの XOR 演算の結果は数値 "0" です。

結果として得られたこの整数値は（必ずしも 0 とは限りません）、関数に渡される長い文字列のコマンド ID コンポーネントです。この関数は、ChaChi が取るように指示される次のアクションを決定します。コマンド選択関数で予想される引数は、下記の画像のような形をとります。予想される引数の数は、ChaChi に提供される コマンド ID によって異なりますが、コマンド ID に続く引数は 2 個を超えないはずです。それぞれの要素は 3 個のスラッシュ（///）で区切られます。

図 29 - コマンドの選択と引数の構造

使用可能なコマンド ID オプションとホストでの対応するアクションが以下の表に記載されています。無効なコマンド ID は処理されません。

表 1 -　操作への ChaChi コマンド ID のマッピング

コマンドの実行

ChaChi のオペレーターが感染したホストでコマンドやプログラムを実行する場合、予想されるコマンド構造は下記の例のようになります。実行されるコマンド（引数とスイッチを含む）は、1 つの Base64 文字列にエンコードされます。ChaChi は、コマンドライン配列への文字列のデコードと解析を処理し、発生したすべてのスペースでこのデコードされた文字列を分割します。

図 30 - ChaChi のコマンド実行構造

攻撃者が "whoami" のような単純なコマンドを実行する場合、ChaChi が受け取るコマンドは以下のような文字列になります。"whoami" は Base64 のエンコード形式です。

図 31 -　"whoami"　コマンドの形式

ChaChi はこの文字列を解析し、コマンドであることを確認して Base64 からデコードし、コマンドライン文字列を再構成します。

図 32 - コマンド引数の Base64 デコード - "whoami".

（この例の場合のように）プログラム名自体にパス区切り記号が含まれていない場合は、基本的な Go 関数の "os.exec.Command" が完全なパス名を解決します（可能な場合）。そうでない場合は、コマンドを実行する前にパスとして名前がそのまま使用されます。

図 33 - コマンドの実行

リバース SOCKS5 プロキシ

SOCKS プロキシは、レッドチームや脅威アクターがよく使用するツールです。実際には異なるマシンから送られてきているトラフィックが 1 つのマシンから発信されているように見せかけることで、このツールはある程度の匿名性を提供するからです。SOCKS プロキシ、特にリバース SOCKS プロキシは、他の方法ではアクセスできないプライベートネットワークへの永続的なアクセスを、インターネット上のマシンから行う手段を攻撃者に提供することもできます。

SOCKS プロキシの機能を ChaChi に追加することを決めた ChaChi の開発者は、ここでも無駄な労力を費やすことは避けることにしました。今回、開発者は rsocks と思われるものからさらに多くのコードを取り入れました。

"rsocks" は、リバース SOCKS5 クライアント/サーバーです。ただし、サーバー側コードのみが ChaChi に組み込まれています。デフォルトの rsocks ビルドでは、プロキシを通過するトラフィックの暗号化形式は利用できません。そのため、ChaChi の作成者は、作成するコードのバージョンにこの機能を追加することにしました。作成者は、これを行うために "net.Dial" の標準呼び出しをよりセキュアな "crypto[.]tls[.]DialWithDialer" の呼び出しに交換しました。この呼び出しは、プロキシされたトラフィックを TLS で暗号化します。

図 35 - TLS 暗号化が追加された変更済みの "rsocks"

ChaChi のオペレーターが感染したホストでプロキシサーバーを開始する場合、予想されるコマンド構造は以下に示す画像の例のようになります。リバース SOCKS5 プロキシの場合、2 または 3 のコマンド ID を受け入れます。というのも、この 2 つはまったく同じ効果を生むからです。

図 36 - リバース SOCKS5 プロキシのコマンド構造

クライアントアドレスは、IP またはドメインの形態をとることができます。下記の画像の例では、同じマシン（127.0.0.1）とポート 8080 をリッスンしているクライアントへの接続を試みています。これは、“rsocks -connect 127.0.0.1:8080” を実行することに相当します。ChaChi のオペレーターの場合は、パブリック C2 IP またはドメインの 1 つで “127.0.0.1” を置き換えることもできます。

図 37 - リバース SOCKS5 プロキシのコマンド例

Base64 エンコードは、リバース SOCKS プロキシの必要条件ではありません。ChaChi はクライアントのアドレスとポートを単に解析し、それをコロンで結合して、その新しい文字列をリバース SOCKS5 プロキシの設定コードに渡します。このコードがプロキシセッションを設定します。

図 38 - リバース SOCKS の Go ルーチンに渡される解析済みの "client:port" 文字列

SOCKS5 プロキシセッションが確立すると、ChaChi のオペレーターは、侵害された内部ネットワークをスキャンするために nmap などのツールをプロキシ経由で実行できるようになります。これはリバースプロキシであるため、サーバーコンポーネントがクライアントへの接続を開始します。ChaChi のオペレーターにとって、これは明らかに優れた選択肢です。というのも、オペレーターは、いわば敵陣の背後から操作することになるからです。

ここで特筆すべきは、rsocks による文字列 "Starting server" が ChaChi に存在しないことです。代わりに、Golang ベースの他の SOCKS プロキシコード（rsockstun の rclient コンポーネントなど）で見られる "Starting client" に置き換えられています。これは、開発プロセス中の実験の名残である可能性があります。go-socks5 を使用している ChaChi の最初のバージョンが BlackBerry のアナリストによって確認されたからです。go-socks5 は、Golang ベースのもう 1 つの SOCKS5 サーバーです。ChaChi の開発者が必要なものとそうでないものを取捨選択していることがうかがえます。

図 40 - 変更済みの "Starting client" 文字列

新しい C2 セッション

コマンド ID 4 は新しい C2 セッションをトリガーします。他の引数は予期されていません。他の引数が提供されても解析は行われません。このオプションは、セッションタイムアウトが発生した場合に役立ちます。または、セッションが応答しなくなった場合に、攻撃者が新たなセッションを確立するときに役立ちます。DNS 経由と HTTP 経由のどちらで接続するかという選択も行われますが、外部のアクションによってではなく、それまでの試みでどちらの接続プロトコルが成功したかによって自動的に決まります。

図 41 - コマンド ID 4 がトリガーする、DNS または HTTP 経由の新しい C2 接続

Chisel クライアント

Chisel はポート転送を簡素化するアプリケーションであり、攻撃者が SSH のクライアントまたはサーバーにアクセスできないシナリオで役立ちます。SSH が利用可能な場合は、一般に SSH がポート転送に最適なツールとなります。ただし、ほとんどの Windows OS で SSH はインストールされていません。または、デフォルトで無効になっています。

ポート転送には、ChaChi の作成者に役立つことが分かるメリットが他にもあり、作成者がこのバックドアに Chisel クライアントを組み込むことを決めた一因にもなっています。

GitHub の README には次のように記載されています。「Chisel は高速の TCP/UDP トンネルであり、HTTP 経由で転送され、SSH によって保護されます … Chisel は安全なエンドポイントをネットワークに提供するときにも使用できますが、主に役立つのはファイアウォールをパススルーするときです」。

Chisel クライアントは、コマンド ID 7 を使用してアクティブになります。Chisel クライアントは、Chisel サーバーおよびポートの IP またはドメイン名を受信することになっています。後述するように、この情報は Chisel サーバー（攻撃者の詰め所）で無防備な状態に置かれており、ローカル SOCKS ポート（1080）に転送されます。

図 42 - Chisel のコマンド構造の例

ChaChi は Chisel サーバーのアドレスを解析し、先頭に "http://" を追加し、最後に ":443" を追加します。

図 43 - Chisel サーバーのアドレス構成

指定されたポートには他の 2 つのデコードされた文字列が連結され、“R:0.0.0.0:<port>:socks" の形式をとる文字列が形成されます。

図 44 - Chisel のポート転送文字列の構成

構成されたコンポーネントは、新しい Chisel クライアントを生成する関数に渡されます。スタンドアロンの Chisel バイナリで実行された場合、この Chisel クライアントは次のようになります。

図 45 - 相当する Chisel コマンド

evildomain[.]xyz にある、ポート 443 をリッスンしている Chisel サーバーへのリバースポート転送接続は、事実上、これで確立されます。サーバーポート 1337 に対して行われた接続は、侵害されたホスト上のローカル SOCKS ポート 1080 にすべて転送されるようになります。

アドレス "0.0.0.0" はサーバー側のローカルアドレスとして指定されているため、ローカルホストだけでなく、サーバー上のどのインターフェイスからもポート 1337 へのアクセスが許可されます。したがって、攻撃者はインターネット上のどこからでも、侵害されたネットワークに evildomain[.]xyz:1337 を介して直接接続し、自身のトラフィックをポート 1080 に出現させることができます。

攻撃者が望めば、Chisel トンネル経由で rsocks サーバーに接続させることもできます。ここで興味深いのは、ChaChi のオペレーターは、この Chisel コマンド文字列で使用される一部の文字列をハードコードしていることです。すなわち、"HTTP" とポート "443" の使用です。これにより、HTTP トラフィックは非標準ポート（すなわち 443）のネットワークを通ることになり、観察の鋭いネットワークアナリストの注意を引く可能性があります。

バックドアのアンインストール

コマンド ID 4 と同様に、コマンド ID 9 では引数をさらに指定することは予期されていません。ChaChi のオペレーターがコマンド ID 9 を実行すると、感染したホストマシンから ChaChi 自体をアンインストールするプロセスが開始されます。このプロセスは 2 段階で行われます。第 1 段階では、以前にインストールされたサービスが Windows のユーティリティ "sc" を使用して削除されます。

図 46 - "sc" を使用してサービスを削除し、一時パスを取得

上の図が示すように、サービスを削除した直後に、ChaChi は PowerShell を使用して %TEMP% ディレクトリへのパスを取得します。この操作は、ChaChi がバッチファイル "del.bat" を作成して一時ディレクトリに書き込むために行われます。このバッチは、ChaChi バイナリをディスク上の格納場所から削除するタスクを実行します。

図 47 - ChaChi バイナリの削除に使用される "del.bat" の内容

ChaChi のオペレーターにとって、このコマンドは特別な用途を担います。というのも、侵害した環境内でオペレーターが目的を達成すれば、その証拠を隠したいと考えるからです。

ネットワークインフラストラクチャ

ネットワークの侵入の痕跡（IOC）を抽出して解析すると、TTP として利用できる情報が得られます。この情報は、過去の標的を（潜在的には現在の標的も）示唆します。ChaChi バイナリから抽出されたドメインに対する最初の確認日のタイムラインを示すことで、2019 年の後半から、PYSA のオペレーターが最も活動的だった 2021 年の第 1 四半期までの期間を観察することができます。

この期間を通じて計 19 のドメインが新規に作成され、ChaChi の C2 としての役割を果たしました。私たちが得たデータから判断すると、ChaChi のドメインは実際の攻撃が発生する数か月前に作成されたものと思われます。同じ ChaChi バイナリ（したがってドメイン）が複数の攻撃で使用されたこともありました。

図 48 - 最初の確認日によるドメインのタイムライン

これらのドメインを少し詳しく調べれば、PYSA のオペレーターが TTP として何を使用していたのか知ることができます。オペレーターがもっぱら好んで使用していたドメイン名の登録機関は Namecheapでした。

表 2 - 登録機関へのドメインのマッピング

ChaChi バイナリから IP アドレスを取り出して、それぞれの ASN と地域にマッピングします。これにより、IP アドレス全体の半分以上がルーマニアかドイツのアカウントを拠点としていることが分かります。IP アドレスの約 60% は、この 2 つの ASN から提供されています。

表 3 - ASN および地域への IP のマッピング

BlackBerry の調査担当者は、C2 サーバーの追跡と監視を継続しています。これは、フィンガープリントと検知のさまざまな手法を使用して、発見されたすべての C2 インフラストラクチャを社内の脅威インテリジェンスシステムに保管することで行われます。

上記の IP アドレスの 1 つは、2020 年の 12 月前半に当社のインテリジェンスプラットフォームの 1 つが偶然捉えたものであり、それがアクティブだった期間は 24 時間にすぎませんでした。この IP（45.147.230[.]212）は、ドイツの AS30823 Combahton によってホストされています。この IP によって PowerShell Empire に対する当社のセンサーの 1 つがトリガーされ、そのアーティファクトが PYSA ランサムウェアの インシデント 後にシステムで確認されています。

図 49 - 公開サーバー上の PowerShell Empire に対するアラート

さらに、抽出した IP アドレスのドメイン解決を確認すれば、興味深い結果と情報が得られます。C2 サーバーとして使用されていたドメインとともに IP アドレス 194.187.249[.]102 が ChaChi のサンプルから抽出されました。このドメインは sbvjhs[.]xyz でした。当然ながら、そのドメインのネームサーバー "ns1" と "ns2" も同じ IP アドレスに解決されています。しかし、興味深いことに、他のドメインもこの同じ IP に解決されています。それは login.bancocchile[.]com です。

図 50 - 偽の Banco Chile ドメインに解決される ChaChi の IP

Banco Chile の正規ドメインは ".cl" 最上位ドメイン（TLD）でホストされており、"Banco" と "Chile" の単語間にある余分な "c" はありません。このドメインは、次の 2 つの目的のいずれかを意図したものと思われます。

• Banco Chile （チリ銀行）の従業員または顧客を標的とするフィッシングドメイン
• ChaChi のコピーをステージングおよび配布して、疑いを持たないユーザーに悪意のあるリンクをクリックさせるために使用するドメイン

選択肢のどちらか一方、さらには両方であることが考えられます。これらのドメインが数か月にわたって同時にアクティブだったことを考慮した結果、最後の確認日はごく最近の 2021 年 6 月 1 日となりました。偶然にも、2 つのネームサーバーのドメインと偽の Banco Chile ドメインは、チリの別の銀行（Banco Estado）で報告されたセキュリティ侵害の発生前、発生中、発生後にもすべてアクティブでした。このセキュリティ侵害は 2020 年 9 月に報告され、REvil ランサムウェア に起因するものでした。

まとめ

ChaChi は、比較的新しいプログラミング言語である Go （別名 Golang）を使用して開発されたカスタム RAT です。Go を使用して ChaChi を開発することで、PYSA ランサムウェアのオペレーターは、この言語に精通していないアナリストとツールによる検知と予防の取り組みを阻止できます。ChaChi の最も古いバージョンは成熟したマルウェアの機能をいくつか欠いていましたが、その急速な進化と、政府機関、医療機関、教育機関に対する最近の展開は、このマルウェアの開発と改良が活発に行われていることを示唆しています。

サイバー攻撃を受けやすいことで有名な業界を標的とする、悪意のあるアクターの管理下に置かれたとき、ChaChi は強力なツールとなります。ChaChi は有能な脅威であることを自ら実証しています。さらに、PYSA ランサムウェアのオペレーターによる ChaChi の使用が懸念を呼び起こしています。REvil、 Avaddon、DarkSide によって行われたキャンペーンなど、注目を集める一連の攻撃でランサムウェアが驚くべき成功を収めている昨今にあってはなおさらです。サイバーセキュリティの重大な事件が 1 年のうちに次から次へと起きる状況下で、こうした脅威を無視する組織は、そのリスクを自ら負うことになります。

付録

YARA ルール

以下の YARA ルールは、この記事で説明した脅威を捕捉するために BlackBerry の脅威調査チームが作成しました。

侵入の痕跡（IOC）

BlackBerry では、サイバーセキュリティに対して、予防ファースト の AI 主導アプローチを採用しています。予防を第一とすることで、キルチェーンの悪用段階の前にマルウェアを無力化できます。

BlackBerry ソリューションは、この段階でマルウェアを阻止することで、組織の回復力向上に役立ちます。また、インフラストラクチャの複雑さが削減され、セキュリティ管理が合理化されて、業務、スタッフ、エンドポイントが確実に保護されます。

MITRE ATT&CK