OilRig、QUADAGENTを使用してテクノロジ サービス プロバイダと政府機関を標的に

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

概要

OilRigグループは引き続き戦略を適応し、新しく開発されたツールでツールセットを強化しています。OilRigグループ(別名APT34、Helix Kitten)は諜報を動機に持つ攻撃者で、主に中東地域で活動しています。当社は、2016年中頃にこのグループを初めて発見しましたが、このグループの活動はそれ以前に始まっていた可能性もあります。この攻撃グループの執拗さはよく知られており、攻撃の手を緩める兆候はありません。このグループの過去の活動を現在のイベントとともに調査すると、OilRigグループの活動が近い将来さらに加速する可能性が高いことがわかります。

2018年5月と6月の間に、Unit 42はOilRigグループによる複数回の攻撃を確認しました。これらは中東の政府機関が送信元のように見えました。しかしながらこれまでに確認された戦略を鑑みれば、本来の標的に向けた攻撃を開始するためのプラットフォームとして、OilRigグループがこれら政府機関で収集した資格情報や侵害済みアカウントを利用した可能性が非常に高いといえます。

これらの攻撃の標的には、テクノロジ サービス プロバイダや別の政府機関が含まれていました。これらの標的は両方とも同じ国家の組織でした。また、これらの標的への攻撃は、同じ国のさらに別の機関から行われたように見えます。しかし、実際の攻撃者自身は同国国外に存在し、中間組織から窃取した資格情報を使用して攻撃を実行した可能性が高いのです。

この攻撃では、QUADAGENTというPowerShellのバックドアが配信されました。このバックドアは、ClearSky Cyber SecurityとFireEyeの両方がOilRigグループに起因するとしているツールです。当社独自の分析でも、OilRigグループによって以前使用されたツールから再使用された特定のアーティファクトおよび以前の攻撃から再使用された戦略を検査することによって、このツールがOilRigグループに帰属することを確認できました。スクリプトベースのバックドアの使用は、当社が以前報告したようにOilRigグループがよく使う手法です。しかし、これらのスクリプトをポータブル実行可能(PE)ファイルにパッケージすることは、当社が確認した、OilRigグループが頻繁に使用する戦略ではありません。QUADAGENTの詳細分析およびそのOilRigとの関連はこのブログの最後の付録に記載します。QUADAGENTは、Unit 42が報告した12番目のカスタム ビルド ツールで、OilRigグループが攻撃に使用しています。

当社の分析によって、当社が取得した2つのQUADAGENT PEファイルがお互いに若干異なることが明らかになりました。まず、一方はMicrosoft .NET Frameworkベースのドロッパーを使用しており、これはおとりのダイアログ ボックス(図1)も開きます。他方のサンプルはbat2exeツールから生成されたPEファイルでした。

表1.QUADAGENT PEファイル

ホストにドロップされたQUADAGENTバックドアはお互いにほぼ同じものでした。唯一の相違点は、コマンド&コントロール(C2)サーバーおよびランダムの難読化でした。当社は、ClearSky Cyber Securityで報告しているように、QUADAGENTバックドアの3番目の配信パッケージも見つけることができました。これらの例では、OilRigグループは、悪意のあるマクロ文書を使用してバックドアを配信しました。これはこのグループがより一般的に使用する戦略です。

詳しく調査すると、これらのQUADAGENTサンプルでOilRigグループが使用した難読化はInvoke-Obfuscationというオープンソースのツールキットを使用した結果である可能性が高いことが明らかになりました。このツールは元来、難読化されたPowerShellコマンドをシミュレーションして防御を向上する際に防御側を支援することを意図していました。Invoke-Obfuscationは、PowerShellスクリプトの難読化に非常に効果的であることが明らかになっていましたが、今回の攻撃者は本ツールを解析対策として使い、それによって侵害のチャンスを拡大してきました。

攻撃の詳細

この最新の攻撃は2018年5月と6月の間の3回の波から構成されていました。3回の波すべてに、中東にある政府機関から送信されたと見せかけた一通のスピア フィッシング メールが関連していました。ただし、当社のテレメトリから見て、この攻撃の開始に使用された電子メール アカウントは、OilRigグループに資格情報を窃取されて侵害されたものだったということはほぼ間違いないでしょう。

テクノロジ サービス プロバイダへの2回の波(5月30日と6月3日)での被害者の電子メール アドレスは、一般的な検索エンジンで簡単に見つかるものではありませんでした。つまりこの被害者の電子メールアドレスは、過去に収集済みの標的リストに含まれていたか、すでに攻撃元として利用したことのある侵害済みのアカウントが存在していて、その侵害済みアカウントの関係者を標的としたか、の可能性が高いでしょう。悪意のある添付ファイルは単純なPEファイル(SHA256: 5f001f3387ddfc0314446d0c950da2cec4c786e2374d42beb3acce6883bb4e63

)で、そのファイル名は<redacted> Technical Services.exeでした。このファイルはbat2exeツールを使用してコンパイルされたようです。このツールはバッチ ファイル(.bat)を取り込み、これらをPE (.exe)ファイルに変換します。この唯一の目的はQUADAGENTバックドアをインストールして実行することです。

被害者が電子メールの添付ファイルをダウンロードして実行すると、これが暗黙のうちに実行されます。追加のおとり文書やおとりのダイアログ ボックスは表示されません。この実行ファイルは、ファイル名Office365DCOMCheck.ps1およびファイルの実行を支援する同じファイル名のVBScriptファイルを使用して、パッケージ化されたQUADAGENT PowerShellスクリプトをドロップします。スケジュール化されたタスクも生成され、ペイロードの永続性を維持します。QUADAGENTペイロードが実行されると、これは、まずHTTPSを介して、次にHTTP、さらにDNSトンネリング(前者が失敗した場合にそれぞれが対応するフォールバック チャンネルとして使用されます)を使用してC2としてrdppath[.]comを使用します。

政府機関に対する波(6月26日)も単純なPEファイルの添付ファイル(SHA256: d948d5b3702e140ef5b9247d26797b6dcdfe4fdb6f367bb217bc6b5fc79df520)が関連していて、これに使用されたファイル名はtafahom.exeでした。このPEは、その他の攻撃と若干異なっていて、bat2exeツールを使用して生成されたのではなくMicrosoft .NET Frameworkを使用してコンパイルされ、図1に示すようなおとりのダイアログ ボックスが含まれていました。

おとりのダイアログ ボックスを使用する戦略は複数の攻撃者によくある手口で、通常は、被害者に不審がられないように配置されます。暗黙に実行される場合と比べると、被害者はダイアログやエラー メッセージを怪しむことは少ないのです。というのは、添付ファイルを開こうとしてエラーが返されるのは一見正常な応答であるかのように見えるからです。これに対しファイルが暗黙的に実行された場合、ユーザーのアクションに対する応答がないことから、被害者が不審がったり、実際に何が起こっているのかについて興味を抱くかもしれません。

.NET PEファイルが実行された後、当社は、上記のQUADAGENTサンプルと同じ動作、つまりファイル名SystemDiskClean.ps1を同じ名前のPowerShellスクリプトをVBScriptファイルとともにドロップする動作を確認しました。C2の手法は同じままでした。唯一の相違点はサーバーがcpuproc[.]comになったことでした。

rdppath[.]comを基軸とし、当社は同様にこのC2 (SHA256: d7130e42663e95d23c547d57e55099c239fa249ce3f6537b7f2a8033f3aa73de )と通信した追加のQUADAGENTサンプルを収集しました。このC2についてはClearSky Cyber Securityで初めて報告されました。これらの攻撃に使用された2つのサンプルと対照的に、これはPE添付ファイルを使用しませんでした。代わりに、配信手段として悪意のあるマクロを含むMicrosoft Wordの文書を使用しました。悪意のあるマクロ配信文書の使用は、当社がOilRigグループを追跡している3年間にわたってこのグループが使用を繰り返していることを当社が確認している戦略です。ClearSkyサンプルで使用された実際のQUADAGENTスクリプト ペイロードは、前記のテクニカル サービス プロバイダに対して使用されたbat2exeバージョンで当社が発見したものと全く同じでした。決定的ではありませんが、配信文書もその同じ国家内の別のテクノロジ サービスまたはメディア組織と関連する可能性があるファイル名を使用していました。この文書には、悪意のあるマクロ文書で見つかることが多いイメージと似ている誘いのイメージも含まれていました。これは図2に示すように「Enable Content」をクリックすることをユーザーに求めます。このグループが使用するその他多くの配信文書と異なり、マクロが有効になった後には追加のおとりコンテンツはありませんでした。

オープン ソース ツールの使用

検出回避を狙い、また解析対策戦術として、OilRigグループは、Invoke-Obfuscationと呼ばれるオープン ソース ツールを悪用して、QUADAGENTで使用されるコードを難読化しています。Invoke-ObfuscationはGithubリポジトリを介して無償で入手可能で、ユーザーは希望する難読化手法を選択するだけで、PowerShellスクリプトの視覚的な表示を変更できます。Invoke-Obfuscationはさまざまな難読化手法を提供しており、私たちはスクリプトを分析することで、この攻撃での特定のオプションを突き止めることができました。QUADAGENTを難読化するために使用された特定のオプションを特定した後、PowerShellスクリプトの難読化を解除し、さらに分析を行うことができました。

スクリプトに適用された2つの難読化手法が判明しました。1つ目は変数の表示を変更するもので、2つ目はスクリプト内の文字列の表示を変更するものでした。

Invoke-Obfuscationは、このスクリプトを難読化するために攻撃者によって使用された変数難読化手法Random Case + {} + Ticksを呼び出します。この手法は、スクリプト内のすべての変数を、ランダムに大文字/小文字に変換された文字に変え、波括弧で囲み、PowerShellによって無視されるようにバッククォート(`)文字を含めます。Invoke-Obfuscationは、このスクリプトをさらに難読化するために攻撃者によって使用された文字列難読化手法Reorderを呼び出します。この手法は、PowerShellの文字列フォーマット機能を使用して、部分文字列の順序を変えて文字列を再構成します(例:  "{1}{0}" -f 'bar','foo')。

分析中に、Invoke-Obfuscationをインストールし、それを使用して以前に収集されたQUADAGENTサンプルを難読化し、私たちの分析結果を確認しました。このQUADAGENTサンプルに対して、Invoke-Obfuscation内で前述の2つの難読化オプションを使用しました。その結果、このブログで説明した攻撃で配信されたOffice365DCOMCheck.ps1およびSystemDiskClean.ps1ペイロードと非常によく似たスクリプトが生成されました。以下の図3のアニメーションで、Invoke-Obfuscation内で実行したコマンドをキャプチャしました。これは、この攻撃で配信されたペイロードを作成するために攻撃者が利用した可能性の手順を視覚化しています。

結論

OilRigグループは、中東地域に長く存在し続けている攻撃者グループです。配信手法こそシンプルですが、これまで OilRig グループ由来であることが特定されてきたツールはどれも非常に洗練されています。この例でも、同じツールを複数の攻撃で再利用するという、攻撃者グループの典型的な行動が見られたものの、セキュリティ対策を回避するためにつどインフラストラクチャを変更し、難読化を追加し、再パッケージ化をするといった変更が加えられていました。このタイプの攻撃者グループは、指令の任務を遂行するのに必要最小限の労力しかかけない、というキーポイントを常に心にとめておくべきでしょう。

パロアルトネットワークス製品をご利用のお客様は、本稿に述べた脅威から以下の方法で保護されています。

• WildFireはQUADAGENTサンプルを悪意があるものとして分類します
• QUADAGENT C2ドメインは悪意があるものとして分類されます
• AutoFocusのお客様はQUADAGENTを同タグにより追跡できます

IOC

SHA256ハッシュ

QUADAGENT

• d948d5b3702e140ef5b9247d26797b6dcdfe4fdb6f367bb217bc6b5fc79df520
• d7130e42663e95d23c547d57e55099c239fa249ce3f6537b7f2a8033f3aa73de
• 5f001f3387ddfc0314446d0c950da2cec4c786e2374d42beb3acce6883bb4e63
• ThreeDollars
• 1f6369b42a76d02f32558912b57ede4f5ff0a90b18d3b96a4fe24120fa2c300c
• 119c64a8b35bd626b3ea5f630d533b2e0e7852a4c59694125ff08f9965b5f9cc

ドメイン

• rdppath[.]com
• cpuproc[.]com
• acrobatverify[.]com

ファイル名

• Office365DCOMCheck.ps1
• Office365DCOMCheck.vbs
• SystemDiskClean.ps1
• SystemDiskClean.vbs
• AdobeAcrobatLicenseVerify.ps1
• c:\Users\<username>\AppData\Roaming\Out.jpg

付録

QUADAGENTと他のOilRigツールとの関係

数ヶ月前、定期的なデータ収集機能の実行時に、ある配信文書(SHA256: 1f6369b42a76d02f32558912b57ede4f5ff0a90b18d3b96a4fe24120fa2c300c)を収集しました。これには、後からQUADAGENTであることが明らかになった、当時は未知のペイロードが含まれていました。標的情報またはテレメトリをサポートするデータはありませんが、文書が2018年1月に作成されたもので、同時期の攻撃に使用された可能性があることはわかっています。さらに、配信文書は、ThreeDollars配信文書(SHA256: 119c64a8b35bd626b3ea5f630d533b2e0e7852a4c59694125ff08f9965b5f9cc)とメタデータの アーティファクトを共有していました。この文書は、OilRigが2018年1月に中東の政府機関に対する標的型攻撃でISMAgentペイロードを配信するために使用したものです。

配信文書がドロップしたQUADAGENTペイロードは、ファイル名がAdobeAcrobatLicenseVerify.ps1で、そのC2としてacrobatverify[.]comが使用されていました。acrobatverify[.]comのサブドメインを調べると、www、resolve、およびdnsが判明します。サブドメインのパッシブDNSデータは、2017年12月から2018年1月まで、IP解決が185.162.235[.]121であることを示しています。この期間以前にも、このIPに解決される、msoffice-cdn[.]com、ns1、ns2、wwwといった、いくつかのサブドメインを観察しています。このIPとmsoffice-cdn[.]comはどちらも、ThreeDollars配信文書を使用したOilRig攻撃に関する最初のレポートで以前に言及されています。

私たちは、このブログで述べたInvoke-Obfuscationツールのテスト時にこのQUADAGENTペイロードを使用しました。Invoke-Obfuscation内の2つの特定の難読化手法を適用することで、このブログで説明した攻撃で配信されたQUADAGENTペイロードに非常によく似た、難読化されたPowerShellスクリプトを作成できました。

QUADAGENTの分析

全3回の攻撃波で配信された最終のペイロードは、他の調査研究組織によってQUADAGENTと呼ばれているPowerShellダウンローダです。これらの攻撃のダウンローダは、C2サーバーとしてrdppath[.]comとcpuproc[.]comの両方を使用するように構成されていました。C2サーバーと通信するときに、ダウンローダは複数のプロトコル、具体的には、HTTPS、HTTP、またはDNSを使用します。それぞれ、その順序でフォールバック チャネルを提供します。たとえば、ダウンローダは最初にHTTPSリクエストを使用してC2サーバーとの通信を試みます。HTTPSリクエストが成功しない場合、ダウンローダはHTTPリクエストを発行します。最後に、HTTPリクエストが成功しない場合は、ダウンローダはフォールバックして、DNSトンネリングを使用し、通信を確立します。このセクションでこのマルウェアの内部の仕組みを説明する際に、これらのプロトコルの具体的な使用方法について詳しく説明します。

ダウンローダは、スクリプトのファイル名(例: Office365DCOMCheckまたはSystemDiskClean)をスケジュールされたタスクの名前として使用し、感染ホストへの永続性を維持します。スケジュールされたタスクを作成するため、PowerShellペイロードは、タスク名と同じ名前のVBScriptファイル(例: Office365DCOMCheck.vbsまたはSystemDiskClean.vbs)(%TEMP%フォルダ内)に以下を記述することから開始します。

その後、スケジュールされたタスクは、5分ごとに稼動し、ダウンローダ スクリプトは永続的に実行されます。タスク自体はかなりシンプルで、QUADAGENTペイロードを実行するために引数としてPowerShellの1行を含むVBScriptファイル(例: Office365DCOMCheck.ps1およびSystemDiskClean.ps1)を呼び出します。

永続的なアクセスをセットアップした後、ペイロードは、スケジュールしたタスクと同じ名前(例: Office365DCOMCheckまたはSystemDiskClean)のHKCUハイブのレジストリ キー内に以下のような値が存在するかどうかをチェックします。

HKCU\Office365DCOMCheck

ペイロードは、このレジストリ キーを使用して、侵害したシステムに固有のセッションID、およびシステムとC2サーバーとの通信の暗号化と復号に使用される事前共有キーを保存します。ペイロードの最初の実行時には、このレジストリ キーは空です。ペイロードは、C2サーバーと通信してセッションIDと事前共有キーを取得し、それを以下の形式でこのレジストリ キーに記述します。

<session id>_<pre-shared key>

セッションIDと事前共有キーを取得するために、ペイロードは最初に、以下のURLへのHTTPS GETリクエストを介してC2への接続を試みます。

hxxps://www.rdppath[.]com/

HTTPSを使用した上記リクエストの結果がHTTP 200 OKメッセージでない場合、または応答データに英数字が含まれていない場合は、コードはHTTPを使用し、以下のURLを介して、C2との通信を試みます。

hxxp://www.rdppath[.]com/

HTTPを介してC2と通信するためのコードは、例外ハンドラー内に存在します。HTTPSリクエストが動作しない場合は、これをトリガーするために、ペイロードは1を0で除算して、例外の発生を試みます。この例外は、例外ハンドラーを呼び出し、それによって、そこに含まれているHTTP通信コードを実行できます。

いずれかの試行が成功すると、C2サーバーは、平文のセッションIDと事前共有キーで応答します。それは、前述のレジストリ キーに保存されます。C2サーバーは、応答データに含めて事前共有キーを提供し、セッションID値は、応答内のSet-Cookieフィールドを介して、具体的には、cookieのPHPSESSIDパラメーターの後の文字列として提供します。

両方の試みが失敗し、ペイロードがHTTPまたはHTTPSを介してセッションIDおよび事前共有キーを取得できない場合、DNSトンネリングを使用しようとします。セッションIDおよび事前共有キーを取得するために、ペイロードは、クエリを発行して次のドメインを解決します。

mail.<random number between 100000 and 999999>.<c2 name>

このリクエストは、ペイロードが最初のハンドシェイクの一部としてシステム固有データを送信しようとしていることをC2サーバーに通知します。スクリプトは、システムが属しているドメインや現在のユーザー名などのシステム固有データを収集します。これらは以下の形式で構成されます。

<domain>\<username>:pass

上記の文字列は、カスタムbase64エンコーダを使用してエンコードされ、英数字でない文字(=、/、+)をデータから取り除き、それらの値をドメインの安全な値(それぞれ01、02、03)に置き換えます。

<encoded system data>.<same random number between 100000 and 999999 above>.<c2 name>

セッションIDおよび事前共有キーを取得すると、PowerShellスクリプトは、引き続きC2サーバーと通信して、コマンドとして扱うデータを取得します。このスクリプトは、まずHTTPS(うまくいかない場合はHTTP)を使用してC2サーバーとの通信を試みます。ここで使用されるGETリクエストでは、リクエストのcookie内のPHPSESSIDフィールドでセッションIDが使用されます(GETリクエストの例を参照)。

GET / HTTP/1.1

ペイロードがHTTPS/HTTPを介してC2に到達できない場合、ペイロードは再度DNSトンネリングにフォールバックします。ペイロードは次のドメインにDNSクエリを発行して、C2に、後続のクエリでデータ(セッションID値)を送信しようとしていることを通知します。
ns1.<random number between 100000 and 999999>.<c2 name>

ペイロードは、クエリに対するC2サーバーの応答について何もしません。代わりに、次のドメインを解決するために即座にクエリを発行します。このドメインには、C2に送信するためのセッションID値が埋め込まれています。

<encoded session id>.<same random number between 100000 and 999999>.<c2 domain name>

DNSトンネリングを介してデータを送信するために、C2サーバーは、IPv6アドレスを使用して上記のクエリに応答します。これには、後続のIPv6の返答からデータ全体を取得するためにペイロードが発行する必要があるDNSクエリの数が含まれています。スクリプトは、次の形式を使用して指定された数のDNSクエリを送信します。それぞれについて、C2サーバーは、IPv6アドレスで応答し、スクリプトはそれらをデータの文字列として扱います。

www.<sequence number>.<same random number between 100000 and 999999>.<c2 domain name>

ペイロードは、C2が提供したデータをメッセージとして扱います。次のような構造をしています。

hello<char uuid[35]><char type[1]><data>

メッセージは、helloから始まり、35文字のUUID文字列が続きます。typeフィールドには、ペイロードが処理するコマンドが指定されます。この特定のペイロードの亜種は、1つのコマンド タイプ、xしか処理できません。メッセージ内のdataフィールドは、カスタムbase64エンコード データの文字列で、マルウェアは前述した同じカスタムbase64ルーチンを使用してデコードし、AESおよび事前共有キーを使用して復号します。xコマンドは、提供されたデータをPowerShellスクリプトとみなし、現在のPowerShellスクリプト(Office365DCOMCheck.ps1/SystemDiskClean.ps1)に書き込んで、最初のPowerShellスクリプトを2番目のペイロード スクリプトで効果的に上書きします。また、xコマンドは、生成されたレジストリ キーおよびOffice365DCOMCheck/SystemDiskCleanスケジュール済みタスクを削除します。そして、以下のコマンドをcmd /c:によって実行して、新しくダウンロードしたPowerShellスクリプトを実行します。

bye<char uuid[35]>d

上記のメッセージは、C2サーバーに対する単純なHTTPS/HTTP POSTリクエストによって送信されます。失敗した場合、ペイロードは、以下のドメインを解決するために最初にDNSクエリを発行してDNSトンネリングを使用し、ペイロードが後続のDNSクエリでデータを送信することをC2に通知します。

ns1.<random number between 100000 and 999999>.<c2 name>

次にペイロードは、メッセージを60バイトのチャンクに分割し(この場合は1つのみ)、次のようなドメイン構造を解決するために、DNSクエリを介してC2に送信します。

<encoded/encrypted data of message>.<same random number between 100000 and 999999>.<c2 name>

ペイロードは、次のようなドメイン構造を解決するために、DNSクエリを発行することでデータ送信を完了したことをC2に通知します。

ns2.<same random number between 100000 and 999999>.<c2 name>

QUADAGENTサンプルのパッケージ比較

bat2exeバージョン(SHA256: 5f001f3387ddfc0314446d0c950da2cec4c786e2374d42beb3acce6883bb4e63)には、バッチ スクリプト、PowerShellスクリプト、およびいくつかのリソース内に埋め込まれた関連ファイル名があり、RC4およびさまざまなMD5ハッシュをキーとして使用して復号します。実行ファイルは、埋め込みPowerShellスクリプトを取得し、RC4を使用して復号してから、ZLIBを使用して解凍し、平文をC:\Users\<username>\AppData\Roaming\Out.jpgに保存します。次にバッチ スクリプトがOut.jpgをOffice365DCOMCheck.ps1に名前変更し、次のコマンドで実行します。

.NET亜種(SHA256: d948d5b3702e140ef5b9247d26797b6dcdfe4fdb6f367bb217bc6b5fc79df520

)はよりシンプルです。このドロッパーは、次のコマンドによって、前に示して議論した図1のダイアログ ボックスをまず表示します。

次にこのドロッパーは、.NETアセンブリ内のリソースに平文として存在するペイロードの内容を、 C:\Users\<username>\AppData\Local\Temp\SystemDiskClean.ps1に書き出します。そして、シェル オブジェクトとして実行します。

悪意のあるマクロ攻撃では、PEバージョンで使用されたものと同じOffice365DCOMCheck.ps1スクリプトがペイロードとして使用されます。文書が開かれると、図2に示したルアー(わな)のイメージが表示され、被害者に強制的にマクロを有効化させようとします。

マクロが有効化され実行されると、Word文書内のマクロが文書のセクションを検索して、以下のコードを使用してヘッダーの内容を取得します。

前述のコードによってヘッダーの内容が取得され、マクロはこの内容をC:\programdata\Office365DCOMCheck.ps1のファイルに書き込みます。これで配信文書の作成者は、図4に示すように、テキストのフォント サイズを2に、フォント色を白に設定することで、ヘッダーにあるPowerShellスクリプトを視覚的にうまく隠しています。

小さな白いフォントを使用して悪意のある内容を隠すというこの技法は、今回の脅威グループに固有のものではありません。最近では、Sofacyグループがこの技法を使用して、DDE命令を配信文書の1つに隠していたことが観測されています。