Unit 42、クウェートの海運・運輸関連組織へのサイバー攻撃キャンペーン「xHunt」を発見

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

エグゼクティブサマリー

パロアルトネットワークス脅威インテリジェンス調査チームUnit 42は、2019年5月から6月にかけて、クウェートの輸送・海運組織を狙い、未知のツールを使う攻撃キャンペーンを発見しました。

この攻撃キャンペーンにおける最初の既知の攻撃はクウェートの運送会社を標的にしており、同キャンペーンで攻撃者はHisokaという名前のバックドアツールをインストールしていました。また、エクスプロイト後の活動を実行するため、後からカスタムツールがいくつかシステムにダウンロードされていました。これらのツールはすべて、同じ開発者によって作成されたようです。

私たちはこれらツールの亜種を複数収集しましたが、そのうち1つは2018年7月にまで遡ります。収集されたツールの開発者は、アニメ―ション シリーズ「Hunter x Hunter」の登場人物名を使用しており、これがキャンペーン名「xHunt」のもとになりまました。収集されたツール名には、バックドアツールSakabota、Hisoka、Netero、Killuaが含まれます。

これらツールの特定亜種は、コマンド アンド コントロール（C2）チャネルとしてHTTPだけでなくDNSトンネリングや電子メールも使用していました。DNSトンネリングはC2チャネルによく利用されますが、同攻撃グループがC2通信の実現に使った電子メールによるある方法は、かなり前からUnit 42では観測していない種類のものでした。

その方法とは、Exchange Web Services（EWS）と窃取された資格情報を使用して、電子メール「ドラフト」を作成することにより、アクター・ツールの通信を行うというものです。また私たちは前述のバックドアツールに加えてGon、EYEと呼ばれるツールも観測しました。これらのツールは、バックドアへのアクセス、エクスプロイト後の活動を実現するものです。

さらに、比較分析により、2018年7月から12月までの間にやはりクウェートを対象とした関連活動があったことを特定しました。同活動については、IBM X-Force IRISが最近レポートを公表しています。2つのキャンペーンに直接インフラの重複はありませんが、過去データの分析から、2018年と2019年の活動は関連している可能性が高いことが示されています。

活動の概要

2019年5月19日、inetinfo.sysという名前をつけられた悪意のあるバイナリが発見されました。同バイナリは、クウェートの海運・運輸セクターのある組織のシステムにインストールされていました。同ファイルinetinfo.sysはHisokaと呼ばれるバックドアの亜種で、コード内にはそれがバージョン0.8であることが明記されていました。残念ながら、このHisokaというバックドアをインストールするために、最初にシステムにアクセスした方法が何であったかについては、私たちの手元にテレメトリ データがありません。

ですが、Hisokaを介してシステムにアクセス後2時間以内に、アクターはGon、EYEという2つの追加ツールを展開していました。これらツール名は、Gon.sys、EYE.exeというファイル名に由来しています。高レベルでは、アクターはGonツールを使うことでリモート システムのオープン ポートをスキャンし、ファイルをアップロード/ダウンロードし、スクリーンショットを撮り、ネットワーク上の他のシステムを見つけ、リモート システムでコマンドを実行し、リモート デスクトップ プロトコル（RDP）セッションを作成することができるようになります。図1に示すように、アクターはGonをコマンドライン ユーティリティとしても、グラフィカル ユーザー インターフェイス（GUI）経由でも使用できます。

図1 GonのGUI

アクターはまた、EYEツールを安全に脱出するための手段としてとして使います。自身がRDP経由でシステムにログイン中に正規のユーザーがログインすると、同ツールがアクターが作成したすべてのプロセスを強制終了し、他の識別アーティファクトを削除するようになっています。付録にGonとEYEの詳細を記載しますので、詳しくはこちらを参照してください。

私たちはさらにデータセット内を探索し、同脅威攻撃グループが標的としたクウェートの海運・運送セクターの組織がもうひとつあることも特定しました。この組織の場合、2019年6月18日から30日の間に攻撃者がHisokaツールをインストールしており、使用されたバージョンは0.9であることがnetiso.sysに記載されていました。同年6月18日、このファイルは社内ITサービスデスクのアカウントからサーバー メッセージ ブロック（SMB）プロトコルを介して別のシステムに転送された様子が観測されています。そのすぐ後、otc.dllという名前のファイルも同じ方法で転送されていたことが確認されました。

このotc.dll というファイルがKilluaと名付けられた単純なバックドア ツールで、攻撃者はこれをDNSトンネリングでのやりとりを介して感染システム上で実行するコマンドをC2サーバーから発行するために使います。

文字列比較の結果、私たちは高い確度でKilluaとHisokaの両ツールが同一開発者により作成されたものと考えています。最初にKilluaが観測されたのは2019年6月で、その後私たちは同ツールがHisokaが進化形である可能性があると考えるに至りました。Killuaツールの詳細は、付録を参照してください。

6月30日、私たちは同攻撃者による非常に興味深い関連活動を観測しました。サードパーティのヘルプデスクサービス アカウントを使用し、ファイルをネットワーク上の別のシステムにコピーしたのです。この活動は、別のHisoka v0.9ファイルの転送から始まり、30分というタイムフレーム内で2つの異なるKilluaファイルの転送が続きました。

前述の活動で特定されたツールは、同じ開発者によって作成されたように見えます。というのも、これらはすべて「Hunter x Hunter」の登場人物にちなんだ名前が付けられているか、なんらかのアニメ番組への言及が見られるからです。

Hisokaの電子メールベースC2

分析中私たちはHisokaの2つの異なるバージョン、具体的にはv0.8とv0.9を特定しました。どちらも2つのクウェート組織のネットワークにインストールされていたものです。どちらのバージョンにも、攻撃者により侵害システムを制御できるようにするコマンド セットが含まれています。またどちらのバージョンでも、アクターはHTTPないしDNSトンネリング経由でコマンド アンド コントロール（C2）チャネルを介した通信を行うことができます。ただし、v0.9には電子メールベースのC2チャネル機能が追加されています。これら2亜種のより詳細な分析は、付録を参照してください。

Hisoka v0.9に追加された電子メールベースのC2通信機能は、Exchange Web Services（EWS）に依存しており、アクターがHisokaと通信できるようにするため、Exchangeサーバー上の正規アカウントを使用します。マルウェアは、提供された資格情報を使用してExchangeサーバーへのログインを試み、EWSを使用して電子メールを送受信し、ターゲットとアクター間の通信を確立します。ただしこの通信チャネルは、これまで確認されている電子メールベースC2チャネルのように、実際に電子メールを送受信することはありません。そのかわりHisokaマルウェアと攻撃者は、電子メールのドラフト作成機能を利用してデータをやり取りします。電子メールのドラフトと正規のExchangeアカウントを使用して通信することで、アウトバウンド/インバウンドで送受信される電子メールによる検出はできなくなります。

さらに、EWSアプリケーション プログラミング インターフェイス（API）へのリクエストはHTTPSを使用するので、EWSを活用したC2チャネルは暗号化されたチャネルを介して正規アカウントのメールボックスとやり取りできます。アクターは、電子メールベースのC2チャネルを有効にするさい、-E EWS <data>をコマンドラインに指定し、<data> には以下の構造でデータを指定します。

<ユーザー名>;<パスワード>;<そのExchangeサーバーのドメイン名>;<Exchangeサーバーのバージョン (2010|2013)>

ここでのユーザー名とパスワードは、Exchangeサーバー上の有効なアカウントである必要があります。この機能は、パスワードが「pass123!」の「hisoka」というアカウントを作成することでラボ環境でテストできました。-E EWSコマンドの後ろに文字列

hisoka;pass123!;mail.contoso.com;2010

を指定することで、C2チャネルを有効することができました。通信を開始するにあたりHisokaはコマンドを受信する準備ができていることをアクターに通知しますが、これを行うのが初回の電子メールドラフト作成で、同ドラフトは他のC2チャネルでいうところのビーコンのような役割を果たします。この初回ドラフトは件名に「Present」が含まれ、メッセージ ボディは空です。宛先の To フィールドにはひとつ電子メールアドレスが指定されていますが、これが侵害システムを一意に特定する識別子です。私たちのテストでは「ABCDEF」がその識別子にあたり、この識別子が「@contoso.com」の前に付加されます。図2は、Hisokaによって作成された最初のドラフトメールを Outlook Web App (OWA) 経由でアカウントにログインして表示したものです。

図2 ビーコンとして使用されるHisoka v0.9のメールドラフト

コマンドを発行するため、アクターは同じアカウントにログインし、件名が「Project」のドラフトを作成します。その特別に細工されたメッセージ本文には、コマンドを暗号化した文字列を含めます。私たちがコードを分析して当該メッセージ本文の構造を解読したところ、同メールには、<body>という文字列を含まれている必要があり、その次の行にbase64でエンコードされた暗号文が続くことがわかりました。実際にこの電子メールによるC2チャネルが利用された様子を確認したことはありませんが、私たちは当該電子メールがHTMLメールとして送信されたものを考えています。というのもHisokaは<body>のタグ以降に本文が3行含まれていることをチェックしているからです。このチェックは3つの改行文字（\r）をチェックすることで行われています。このチェックから私たちが推測したのは、暗号文のために1行を使い、クロージング用の</body>タグのためにもう1行を使い、さらにクロージング用の</html>タグのために最後の1行を使うのではないかということでした。

アクターは目的のコマンドを暗号化するのに、各文字と値83（0x53）とをXOR演算をしたあと、得られた暗号文をbase64でエンコードしています。図3は、コマンドを発行するC2チャネルのテストのために作成したメールドラフトで、C-get C:\\Windows\\Temp\\test.txtというコマンドを発行しています。Hisokaはこのコマンドを解析し、パスC:\Windows\Temp\test.txtのファイルのアップロード コマンドとして処理します。

図3 Hisokaがコマンドを取得するために使用する電子メールドラフト

件名「Project」を含むドラフト メールから取得したコマンドを解析・実行後、Hisokaはコマンドの結果をアクターに送信する別の電子メール ドラフトを作成します。この電子メール ドラフトも件名が「Present」で、「To」フィールドにはやはりシステムに一意な識別子と「@contoso.com」とを組み合わせた電子メールアドレスが指定されます。電子メール ドラフトのメッセージ本文は、コマンドの応答か結果を含むbase64エンコード済みの暗号文で、データの暗号化に使用されたのと同じ83（0x53）というキーとのXOR演算による暗号がここでも使用されます。ファイル アップロード コマンドの場合、Hisokaは対象ファイルをメール ドラフトにも添付します。図4はHisokaが作成した電子メールドラフトで、上の図3で説明したファイルアップロードコマンドを受信後に作成されたものです。このドラフトにはファイルtest.txtが添付されており、デコード・復号したメッセージ本文の文字列は、[!] C:\\Windows\\Temp\\test.txt Attached.\r\n\t\t\t\t\t\t{ Hisoka}です。

図4 ファイル アップロード コマンドの応答に使用されるHisoka v0.9の電子メール ドラフト

これは私たちが脅威アクターの活動において最初に確認した電子メールベースのC2チャネルというわけではありませんが、保存された電子メール ドラフトを使い、正規Exchangeアカウントをマルウェアと攻撃者とで共有してやりとりする方法はさほど一般的ではなく、かなり長期間観察されたことがありません。

ツールセットの重複

クウェートの当該組織で発生したマルウェアによる活動を分析中、同活動で特定された他のツールとHisokaには、文字列で観測した内容にある傾向があること浮かび上がってきました。これら文字列から、同じ開発者が作成したSakabotaと呼ばれる別のツールが特定されました。その最初のサンプルは2018年7月頃のものです。

この分析では多数のサンプルを解析することになりましたが、その結果、2つの異なるキャンペーンの存在が特定されました。1つは2018年半ばから後半にかけてのSakabotaを使用したキャンペーン、もう1つは2019年半ばごろのHisokaを使用したキャンペーンです。2つのキャンペーンを分析した結果、Sakabotaは、2019年5月に最初に観測されたHisokaの前身にあたることが明らかになりました。私たちはHisokaとSakabotaの両ツールに加え、前述の活動で特定されたツールを分析して、Sakabotaがこれら攻撃キャンペーンで使用された全ツールの開発の礎となった可能性が高いと判断しました。

Hisokaバックドア ツールは、Sakabotaから大量のコードを流用しており、HisokaはSakabotaコードベースから進化したものと考えられます。関数の数と変数名の数は、SakabotaとHisokaとでまったく同じです。このことから、同じ開発者が両方を作成し、両者のつながりを隠す努力をほとんど払わなかった様子がうかがわれます。次のスクリーンショットはHisokaとSakabotaのコード比較で、変数名には「Chenged_Host」や「Host_Port」などの重複がいくつか見られます。さらに両ツールには、ハードコードされたC2ドメイン名を使うかコマンドラインで引数として指定されたC2を使うかを決める制御構造が基本的に同じ内容になっています。

図5 SakabotaとHisokaの比較

さらに私たちは、Sakabotaと2019年の攻撃キャンペーンで使用された他のツールとの間でコードが共有されている様子も観測しました。たとえば、EYE内のSelf_Distructメソッドは、複数のSakabotaサンプル内のSelf_Distructメソッドと一致しています。また、両ツールはウィンドウに「we be wait for you boss !!!(ボス、私たちはあなたを待っています!!!)」というきわめて特異な文字列を出力します。下の図6は、EYEのSelf_DistructメソッドとSakabotaの同名メソッドの間の重複を示しています。

図6 EYEとSakabotaの比較 

これらのコード重複に加え、「Sakabota」という文字列じたいが、2019年にクウェートの活動で観測されたHisoka、エクスプロイト後に利用されるツールGon、EYE内で何度も観測されています。まず、適切なコマンドライン引数を指定すると、Hisokaは使用方法を表示します（図7参照）。使用法説明の下部には、Compatible with Sakabota v3.2（Sakabota v3.2と互換）という文字列を含む変更履歴が表示されています。ここからもHisokaとSakabotaのつながりが示唆されます。収集したすべてのHisokaサンプルの分析を通じ、私たちはSakabota v3.4までの参照を含む使用法説明を観測しました。

図7 Sakabotaとの互換性説明を含むHisokaの使用法説明 

2019年の攻撃キャンペーンに使用されたポスト エクスプロイト ツールGonにも、スキャンの出力ログ内に、自身が利用するSakabotaが「Sakabota」という文字列として含まれています。Gonのスキャン機能はは発見したシステムをファイルに書き込みます。このファイル パスは <working directory>\wnix\Scan_Result.txtです。スキャンが終了すると、GonはSakabota_v0.2.0.0という文字列を含むフッタを書き込みます。このことから、GonもまたSakabotaツールと関連していることが示唆されます。図8は、スキャン活動でうまく別のシステムが検出されるとGonがファイルScan_Result.txtに書き込む出力内容の例です。

図8 ポスト エクスプロイト ツールGonからの出力内容のサンプル

Sakabotaという文字列は、EYEやGonのデバッグ パスにも登場します。そのデバッグ パスは

Z:\TOOLS\Sakabota_Tools\Utility\Micosoft_Visual_Studio_2010_Experss\PRJT\Sync\Sakabota\EYE\EYE\obj\Release\EYE.pdb

というもので、EYEツールは「Sakabota_Tools」というフォルダ内でコンパイルされています。また、Gon内のデバッグ パスは

C:\Users\sakabota\Desktop\Gon\Gon\obj\Debug\Gon.pdb

ですが、ここからはGonがユーザー名に「sakabota」を使用するシステム上で作成されたことがわかります。

最後に、GonにもSakabotaにも等しく正規アプリケーションであるplinkとdsqueryが組み込まれていることも確認されました。これらの正規アプリケーションは、RDPセッションのポート転送とActive Directoryからの情報収集に使用されています。

2018年、2019年の両攻撃キャンペーンで使用されたマルウェアには重複がありますが、これら2つの攻撃キャンペーンが同じ攻撃グループによって実行されたのかどうかは不明です。ただ、マルウェアの開発レベルでは何らかの関係があるとだけは言えます。

2018年の攻撃キャンペーンへとの関連

HisokaとSakabotaの関連を特定後、さらに探索を続けたところSakabotaのサンプルが複数見つかりました。これらのサンプルはすべて、ドメインpasta58[.]comをC2サーバーとして使用するように構成されていました。インフラ全体を分析していくなかで、同ドメインは、2018年4月から11月にクウェートの組織への攻撃において観測されたインフラでも重複して確認されていたことがわかりました。これに関連する活動は2018年7月に観察されており、同活動には、マクロを有効にしたドキュメントを配信し、PowerShellベースのペイロードをインストールするスピアフィッシング メールが含まれていました。現時点では、これらの攻撃に関する追加のテレメトリは確認できていません。

以下のドメインがpasta58[.]comの関連ドメインとして特定されています。

表1 Sakabotaのドメインpasta58[.]comに関連付けられたドメイン

オープン ソースの情報によれば、 alforatsystem[.]com というドメインは、ZIP アーカイブをホスティングしていたことがあり、この中にはLNKショートカット ファイルが含まれており、そこから悪意のあるPowerShellベース/VBScriptベースのトロイの木馬を実行していました。これらZIPアーカイブの1つに、ビーコンをfirewallsupports[.]comに送信する実行可能ファイルが含まれていました。ドメインalforatsystem[.]comはサウジアラビアの企業であるForat Electronic Systems Co.をミラーリングしている可能性があります。ただし私たちの分析中、これ以外にサウジアラビアを標的とした様子は観測されませんでした。

手元のドメイン登録情報の詳細をもとに、一通りピボット分析を行ったところ、sakabota[.]comというドメインの存在も特定されました。同ドメインでは、webサーバーが「Outlook Web App」というタイトルのページを提供していました。直接重複しているわけではないものの、同ドメインはcheck-updates[.]comドメインと登録者情報が類似しています。またcheck-updates[.]comは最初に観測されたSakabotaサンプルの後で登録されている点が興味深いといえます。

表2 Sakabota[.]comの登録情報詳細

リンク分析

インフラの歴史的分析を実施した結果、いくつかの例ではHisokaとSakabotaの活動には潜在的重複があることが示されています。さらにOilRig ISMAgent攻撃キャンペーン、DNSハイジャックの活動で利用されたインフラとの重複も見られました。なおこれらインフラ重複には共通するドメインへの解決が含まれるものの、名前解決が行われたタイミングは期間的にかなり開いていることから、この間にインフラを使用するアクターが入れ替わった可能性はあります。ここで見られるインフラの重複は、IBM X-Force IRISによる最近のレポートでも注目されていたものです。網羅的なものではありませんが、次のリンク分析グラフは、観察されたインフラ重複のスナップショットです。

図9 インフラのリンク分析

結論

クウェートの組織という標的の選定のしかた、ドメインの命名のしかた、ベースとなるツールセットなどに類似点はあるものの、2018年7月から12月にかけて行われた攻撃キャンペーンと2019年5月から6月にかけて行われた攻撃キャンペーンの2つが同じ攻撃グループによって実施されていたかどうかは現時点ではわかっていません。

リンク分析チャート（図9）が示すとおり、インフラの歴史的分析では、Hisokaのインフラ、Sakabotaのインフラ、既知のOilRigインフラとの間には密な関連性が見られます。こうした重複が見られることや、中東の海運・運輸セクターの組織に標的が絞られていることに鑑み、私たちは今後も同活動を緊密に追跡し、既知の脅威グループとさらに強固な結びつきがないかどうか判断できるよう分析を続けます。

パロアルトネットワークスの各製品は、以下の方法でこれらの脅威を検出し、同脅威からお客様を保護します。

• AutoFocusをお使いのお客様は、当該攻撃者グループを次のタグでさらに詳しく調査できます。 xHunt, Sakabota, Hisoka, Killua, Gon, EYE
• 本稿で参照されているDNSトンネリング活動は、DNS Securityによる自動検出で検出されます。
• 特定されたすべてのツールは、WildFireおよびTrapsにより悪意のあるものとして検出されます。

IOC

これらの活動に関連するすべてのIoCは、こちらのGitHubリポジトリにおいてあります。

付録

Hisoka v0.8の分析

2019年5月から2019年6月の間に、私たちはmicrosofte-update[.]comというドメインにビーコンを送信するように構成されたHisoka v0.8サンプルを7つ特定しました。これら各サンプルには

C:\\Users\\bob\\Desktop\\Hisoka\\Hisoka\\obj\\Debug\\inetinfo.sys.pdb

というデバッグ パスが含まれていました。ここでは、ファイルのSHA256値が 892d5e8e763073648dfebcfd4c89526989d909d6189826a974f17e2311de8bc4のものを以下のHisoka v0.8の分析に利用しています。 Hisokaはバックドア マルウェアで、HTTPとDNSトンネリングの両方を使ってC2と通信します。通信はファイル内にハードコードされており、DNSチャネルはC2ドメインを解決して

public static string Replay_Keyword = "245.10.10[.]11";

public static string Itrupt_Keyword = "244.10.10[.]10";

public static string Instruction_Keyword = "66.92.110[.]";

に含まれているIPアドレスを探します。上記3番目のIPアドレスの最後のオクテットは Total_Package_Rows に使われます。Total_Package_Rowsは、Hisokaに「何個分のIPアドレスをデータとして扱うべきか」を伝えます。  当該マルウェアはC2チャネルからコマンドを取得するための文字列を組み立てますが、それは ID:<uniq_ID>-> という構造になっています。次にマルウェアは組み立てた文字列をPOSTリクエストに含め、HTTPS経由で

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36

というハードコードされたUser-Agent情報とともに送信します。C2からの応答を得たマルウェアは、文字列の最初の文字が「C」であることを確認し、それをコマンドとして処理します。次にマルウェアは残りのデータが以下にリストされた引数のいずれかと一致しなければ、それをコマンドとして実行します。

図10 Hisoka v0.8のスクリーンショット

Hisokaは、DNSクエリまたはHTTPリクエストを使用してC2サーバーにデータを送信します。どちらのチャネルを使うかは、設定やコマンドラインで現在選択中のエンジンに準じます。HTTPを使用するように構成されている場合、Hisokaはリクエストの「Accept-Language」ヘッダ内に一意の識別子を含め、POSTデータ内に送信したいデータを含めて前述のHTTPSと同じPOSTリクエストを使います。DNSを使用するように構成されている場合、DNSクエリを発行することでnslookupアプリケーションを実行し、

<一意の識別子><base64エンコードされたデータを暗号化したもの（1回につき24バイト分がAリソースレコード用、64文字がTXTリソースレコード用>.<C2の場所>

という構造をもつドメインを解決します。私たちが分析したサンプルの場合、サブドメインにランダム値は含まれていなかったので、2つのクエリが同じサブドメインを持っており、キャッシュされた応答で解決された可能性があります。マルウェアそのものを詳細に分析したところ、開発者は乱数を保存する変数は作成したものの、実際のサブドメインにこの値を含めることを忘れていたようです。

Hisoka v0.9の分析

2019年6月には、Hisokaの更新された亜種（SHA256： a78bfa251a01bf6f93b4b52b2ef0679e7f4cc8ac770bcc4fef5bb229e2e888b）を目にするようになりました。これらの亜種も、同じ組織に対して使用されていました。私たちは同亜種のサンプルを4つ特定しましたが、これらはドメインgoogle-update[.]comまたはlearn-service[.]comへビーコンを送信するように設定されていました。

このバージョンで開発者はHisokaから一部の機能を削除し、削除された機能を含む「Netero」という名前の新しいツールを作成しました。Neteroは、Hisokaツールのmsdtdという名前付きリソース内に組み込まれており、HisokaがNeteroの機能を利用する必要が生じた段階でシステム上に保存されます。機能の一部をHisokaから別のツールに移すというこの行為は、アーキテクチャのモジュラー度を高めることにより作者が検出の回避を狙ったからではないかと考えられます。Neteroのペイロードはbase64でエンコードされており、証明書の体裁をとっています。 Hisoka v0.9はこのbase64エンコードペイロードに

certutil.exe -decode <cwd>\msdtd.txt <cwd>\msdtd.sys

を実行してデコードします。

機能をNeteroに移行したことに加え、Hisoka v0.9では、Hisoka v0.8サンプルで観測されていたDNSトンネリングとHTTPSによるC2チャネルにさらに電子メールベースのC2通信機能を追加しています。標的とアクター間での通信を確立するため、Exchange Web Services（EWS）を使用し、指定された資格情報を使用してExchangeサーバーへのログインを試みます。アクターは、コマンドライン (-E EWS <data>) により設定内容を与える必要があります。ここで<data>は

<domain\username>;<password>;<domain for Exchange server>;<Exchange version (2010|2013)>

という構造を持ちます。アクターがこの形式で文字列を与えなかった場合、ハードコードされたデータ

shadow\\boss;P@ssw0rd;cas;2013

が使用されます。このshadow\\boss;P@ssw0rd;cas;2013というデータは、この機能を開発者がテストしたさいの名残りのようです。ここから、デフォルトではユーザー名「shadow\boss」、パスワード「P@ssw0rd」、URL 「https://cas/EWS/Exchange.asmx」でアクセスを試行するということがわかります。

その後、Hisokaは提供された資格情報を使用してExchange Serverへのログインを試行し、アクターによるインバウンド通信に利用・処理する電子メールをチェックします。インバウンド通信を受信するために、EWSを使用して「Drafts」という名前のフォルダ内（WellKnownFolderName 列挙体内では列挙値3）から「Project」という名前のついた電子メール スレッドを含むメッセージを抽出します。

アウトバウンド通信の場合、Hisokaは件名が「Present」のメールを作成します。電子メールの本文には暗号化されたメッセージが含まれ、C2がファイルのアップロードコマンドを発行する場合はそのファイルが電子メールに添付されます。「To」フィールドには、

<一意な識別子>@contoso.com

という形式の電子メール アドレスが配置されます。Hisokaはメールを送信せず、代わりに「Drafts」フォルダにメールを保存します。「Drafts」フォルダを使用すれば、アクターが同一ユーザー アカウントにログインして電子メールの存在を確認でき、Hisokaからの通信受信機能が有効であることをさらに検証することができます。また、攻撃者は「To」フィールドの一意の識別子を使用して、侵害されたシステムのなかのどのシステムが電子メールベースのC2チャネル経由でデータを送信しているかを判断している可能性があります。

観測されたHisoka v0.9サンプルは、ドメインlearn-service[.]comにビーコンを送信するよう設定されており、次の引数が含まれていました。

図11 Hisoka v0.9のスクリーンショット

スクリーンショット下部にある使用方法の詳細から開発者がパロアルトネットワークスのTrapsに対して「バイパス」を追加した様子が示されています。このことは、標的が現在配備しているセキュリティ メカニズムを、ある程度マルウェアの開発者が認識していることを示しています。

EYE

EYEは、2019年5月に最初に確認されたポストエクスプロイト ツールです。ただしEYEには2019年1月21日というWindows Portable Executable（PE）のコンパイル時間が含まれています。このツールの目的は、攻撃者が侵害システムにログイン中に正規ユーザーがシステムにログインしてきたら、活動を隠蔽して検出を回避することです。ローカル ログインとRDPセッションを監視し、のちに漏出させる目的でレジストリに記録するHisokaとは異なり、EYEはこれらのログインを監視し、プロセスを強制終了してアクターのセッション中に作成されたレジストリ キーとファイルを削除します。

ユーザーがEYEアプリケーションを実行すると、「Log off モード」と呼ばれる設定内でyesの場合は「y」をnoの場合は「n」を入力するよう要求してきます。

Choose -> Log off Mode  ?:

[y]

[n]

ユーザの入力内容にかかわらず、EYEはローカルないしリモートのRDPセッションで開始されたインバウンドのログイン試行の監視を開始します。まずバージョン番号である「v0.1」が表示され、その後になにかよくわからないアスキー アートが表示されます。アスキー アート表示につづけて、EYEはコンソールにメッセージを書き込み、インバウンドのログイン試行監視を開始したことを示し、さらにアクターがEYEツールを実行してから作成されたプロセスのリストを表示します。図12は、私たちが行ったテストでのEYEツールの出力内容です。これは、ローカルのログイン試行が発生するまで、EYE実行中に作成されたプロセスが複数ある様子（calc、SnippingToolなど）を示しています。

図12 インバウンドのログイン試行前、アクターによるセッション中に確認されたEYEのプロセス名とID

ローカルないしRDP経由でログインが試行されると、EYEはユニークな文字列である「we be wait for you boss !!!」をコンソールに書き込んでから、アクターの痕跡のクリーンアップを始めます。クリーン アップのさい、EYEはアクターがEYEツールを開始して以降に作成された全プロセスを終了することで、アクターが作成したすべてのアプリケーションとツールをクローズできるようにしています。EYEはその後、最近使用されたドキュメントとjump list の利用によって作成されたファイルをすべて削除します。この削除には、

Del /F /Q %APPDATA%\\Microsoft\\Windows\\Recent\\* & Del /F /Q %APPDATA%\\Microsoft\\Windows\\Recent\\AutomaticDestinations\\* & Del /F /Q %APPDATA%\\Microsoft\\Windows\\Recent\\CustomDestinations\\*

というコマンドを実行します。

EYEはさらに、後述するレジストリ キーで見つかったすべての値と、ユーザー フォルダにある「Default.rdp」 ファイルと、システム上で開始されたすべてのRDPセッションを削除することにより、当該システム上のアクターの活動や隠蔽します。

Software\\Microsoft\\Terminal Server Client\\Default

SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\WordWheelQuery

SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\TYPEDPATHS

Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\RunMRU

EYEは最後にシステムから自身の削除を試行します。この処理には

taskkill /f /im <EYEの実行ファイル名> & choice /C Y /N /D Y /T 3 & Del "<EYEは実行ファイルへのパス>"

というコマンドを実行します。EYEには興味深いアーティファクトが複数あります。たとえばEYEには「ExecuteCommand」 とよばれるメソッドが存在しますが、同メソッドは一度も利用・呼び出しを受けていません。使われないメソッドの存在は、これが以前のバージョンからのコードの名残りであるか、同ツールのもとになった別のコードベースのアーティファクトであるか、このいずれかを示唆しています。メソッドと変数名にかなりの重複があること、PDBデバッグ パスにSakabotaへの参照があることから、私たちはHisokaとSakabotaのコードを使用してEYEが作成されたものと考えています。このPDBデバッグ パスは

Z:\TOOLS\Sakabota_Tools\Utility\Micosoft_Visual_Studio_2010_Experss\PRJT\Sync\Sakabota\EYE\EYE\obj\Release\EYE.pdb

です。

Gon

Gonツールは、2019年5月に初めて確認されました。このツールにはさまざまな機能が含まれています。Gonの機能はその大半が、アクターによるシステムへのアクセス確立後、ポストエクスプロイト ツールとして活動を支援するために使われる可能性が高いことを示しています。Gonを使うことで、アクターは、リモート システム上のオープン ポートのスキャン、ファイルのアップロードとダウンロード、スクリーンショットの取得、ネットワーク上の他のシステムの探索、WMIまたはPSEXECによるリモート システムでのコマンド実行、plinkユーティリティによるRDPセッション作成ができるようになります。Gonはコマンドライン ユーティリティとしても、グラフィカル ユーザー インターフェイス（GUI）をもつデスクトップ アプリケーションとしても使用できます。GUIを利用すると、Gonは内部に組み込まれた「dsquery」ツールで

DS.exe computer -limit 0 > computer_DS.txt

DS.exe user -limit 0 > Users_DS.txt

DS.exe group -limit 0 > Group_DS.txt

というコマンドを発行して、コンピューター、ユーザー、グループ名をActive Directoryから取得することができます。また、コマンドラインを利用すると、アクターはGonのもつ機能を"-help"オプションで簡単に確認できます。-helpオプションが出力する使用方法説明は次のようなものです。

図13 Gonの機能についてのコマンドラインの出力内容

GUIを使用するさい、Gonはユーザーにパスワード「92」を入力するよう要求してユーティリティを使えるようにします。正しいパスワードを入力すると、図14に示すように、「Hunter x Hunter」アニメの登場人物であるゴンとキルアを元にした画像を含むUIがユーザーに表示されます。

図14 「Hunter x Hunter」の登場人物ゴンとキルアを元にした画像を表示するGonのGUI

GUIにはコマンドライン オプションと同じ機能が含まれていますが、「Personal Use（個人的利用）」を有効にするボタンも含まれています。このオプションは、ユーザーが80秒間（タイマーインターバル800ミリ秒で100回チェック）GUI内にカーソルを置かなかった場合にGonのGUIウィンドウを非表示にするタイマーを無効にします。スキャン機能を使用する場合、Gonは結果を<working directory>\wnix\Scan_Result.txtに書き込みます。その内容は次のようなものです。

172.16.107[.]140[WIN-<redacted>] --> SMB

**************Sakabota_v0.2.0.0*****2019-06-14|#|13:32************** 

GonとSakabota、Hisokaの間にも大きなコード重複があります。このことは、同じ開発者が開発に関与していることを示唆しています。

Killua 

私たちは、Hisokaの作者が作成したと思われる別のツールがクウェートで見つかった2番目の組織にインストールされていることを確認しました。このツールを同作者はKilluaと呼んでいます。Killuaもアニメ「Hunter x Hunter」の別の登場人物の名前です。KilluaはHisokaに似たバックドアとして機能しますが、Hisokaとは異なり、KilluaはC#ではなくVisual C++でコーディングされていました。Killuaのサンプルは2019年6月25日、30日までコンパイルされていなかったので、既知のHisokaサンプルより新しいようです。Hisoka同様、Killuaは設定をレジストリに書き込みます。この書き込みには、

HKCU\Control Panel\International\_ID: <unique identifier>

HKCU\Control Panel\International\_EndPoint: "learn-service[.]com"

HKCU\Control Panel\International\_Resolver_Server: " "

HKCU\Control Panel\International\_Response: "180"

HKCU\Control Panel\International\_Step: "3"

という一連のレジストリ キーが使われます。KilluaはDNSトンネリングによりC2サーバーと通信を行いますが、このトンネリングのDNSクエリには組み込みnslookupツールのみが利用できます。これはHisokaがDNSクエリを送信するときと同じ手法です。Killuaは、侵害システムの一意の識別子をサブドメインとして使用し、最初のビーコン クエリを発行することで通信を開始します。分析中、私たちは「EVcmmi」という一意の識別子を観測しました。この識別子をbase64デコードすると「Result goes here（結果がここに入る)」になります。このアクションにより、

EVcmmi.learn-service[.]com

というドメインのクエリを行うビーコンが生成されます。私たちが分析を行っていた時点では、DNSサーバーはこのクエリに対して「66.92.110[.]4」というレスポンスを返してきました。このレスポンスでは、最初の3オクテットがKilluaに対し、「C2であるDNSサーバーからのコマンドを受信できるよう追加のクエリ送信を開始せよ」と合図しています。C2であるDNSサーバーは、クエリに対するIPv4のAnswerセクション内に、これらコマンドを含めて送信します。4番目のオクテットは、C2サーバーからデータ全体を受信するために発行すべきDNSクエリ数を決定するのに使用されています。この「66.92.110[.]4」というレスポンスの場合、Killuaはクエリを4つ発行するよう指示されています。それにより、C2であるDNSサーバーのAnswerセクションで4つのIPv4アドレスを取得するためです。

DNSサーバーが発行する4つのDNSクエリは、一意の識別子「EVcmmi」で始まり、次のようにbase64でエンコードされたデータが続きます。

EVcmmiYg==.learn-service[.]com

EVcmmiYA==.learn-service[.]com

EVcmmiYQ==.learn-service[.]com

EVcmmiZw==.learn-service[.]com

最初のうち私たちは、等号(=)を含むサブドメインは解決されないと考えていました。ところがこれらDNSサーバーは、標準ではない文字をラベルに含むドメインに対してのクエリにも応答することがわかりました。データをbase64でエンコードする前に、Killuaは各文字を83（0x53）でXORすることでクリアテキストを暗号化していました。つまり

"Yg=="は1

"YA=="は3

"YQ=="は2

"Zw=="は4

となります。この復号された数字が、C2サーバーから要求されたデータ チャンクを取得するためのシーケンス番号となります。私たちが分析をした時点では、C2サーバーはこれらのクエリに対し、IPv4アドレス

69.67.1[.]81

73.43.3[.]79

55.80.2[.]68

103.61.4[.]61

で応答していました。

ご覧のとおり、3番目のオクテットにはシーケンス番号が含まれていますが、他のオクテットにはKilluaが正しいシーケンスに並べかえてデータとして扱うべきデータが含まれています。3番目のオクテットに従ってIPアドレスを正しい順序で並べ、他の3つのオクテットを文字として扱った場合、

69.67.1[.] 81は「ECQ」に

55.80.2[.]68は「7PD」に

73.43.3[.]79は「I+O」に

103.61.4[.]61は「g==」に

なります。

base64文字列をデコードし、各バイトを0x53とXORして復号すると、C2サーバーが 「C」というコマンドを発行し、その後にデータ「whoami」がつづくことがわかります。

>>> out = ""

>>> for c in base64.b64decode("ECQ7PDI+Og=="):

...  out += chr(ord(c)^0x53)

... 

>>> out

'Cwhoami'

コマンド「C」は、システムで実行するコマンドを受信しようとするときにHisokaが使用する文字と同じです。「C」の直後の文字がハイフン（ "-"）でなければ、Killuaは続くデータをコマンドとして実行します。この実行のさいは、cmd / cを使ってCreateProcessWを呼び出し、この文字列にデータを追加します。そうでなければ、Killuaは提供されたコマンドをチェックし、見た目が次のコマンド ライン スイッチのいずれかに似ているものがないか確認します。

-R

-doer

-S

-status

-change

-id

-resolver

-help

「-help」 スイッチは以下に示す使用方法の説明を表示します。この内容から、どのようなスイッチが利用可能なのか、このツールの目的がどのようなものなのかがわかります。

+-+-+-+Killua-+-+-+-+ -change

+-+-+-+Killua-+-+-+-+

-change [HOST.com]  ****** Change endPoint

-doer ;[command] ****** Executer

-status  ****** info

-resolver [8.8.8.8]  ****** Resolver

-R[num]s  ****** Response

-P[num]  ****** packect

-id [SIXLTR]  ****** ID

リンク分析チャート表

Table 3. SakabotaおよびHisokaのドメインのインフラ分析