ESET：東ヨーロッパで使用されるTurla Mosquitoバックドア

Turlaは、最も有名なスパイ活動サイバーグループの1つです。 その兵器庫には広範なツール セットがあり 、その中で最も高度なものは、攻撃マシンの優先順位を設定するために使用されます。 スパイプラットフォームは主にWindows指向ですが、さまざまなバックドアとルートキットを使用してmacOSとLinuxに使用できます。



少し前に、Turlaが使用するワークステーションを侵害する新しい方法を発見しました。 この手法は、ソビエト連邦の大使館や領事館の従業員を狙った攻撃で使用されます。

1.概要

Turlaは数年間、偽のAd​​obe Flash Playerインストーラーを使用して被害者を侵害しました。 そのようなベクトルは複雑なエクスプロイトを必要としません;成功は、偽物をインストールすることを確信しているユーザーの信用度に依存します。



近年、Turlaバックドアの1つに感染する異常な新しい動作が確認されています。 真のFlashインストーラーを備えたパッケージにパッケージ化されているだけでなく、adobe.comからダウンロードされているようにも見えます。 エンドユーザーの観点から見ると、リモートIPアドレスは、正規のFlash Playerインストーラーを配布するためにアドビが使用する公式コンテンツ配信ネットワーク（CDN）であるアカマイが所有しています。 プロセスを調べた結果、偽のFlashインストーラー（macOS用のSnakeバックドアインストーラーを含む）がget.adobe.com URLに対してGETリクエストを行い、新しい侵害されたマシンに関するデータを盗み出していることがわかりました。 テレメトリデータによると、IPアドレスはアドビが使用した正当なIPアドレスでした。



このレポートでは、同様の悪意のある動作につながる可能性のある方法について説明します。 データによると、このマルウェアはAdobe Flash Playerの正当な更新を使用しておらず、Adobe製品の既知の脆弱性とは関係ありません。 アドビは侵害されていないと安全に言えます。 攻撃者はブランドを使用してユーザーを欺くだけでした。



また、Turlaグループは、Google Apps ScriptサービスでホストされているWebアプリケーションをJavaScript malvariのチームサーバー（C＆C）として使用していることを発見しました。 攻撃者は可能な限り静かに作業する傾向があり、標的組織のネットワークトラフィックでの活動を隠す傾向があることは明らかです。



テレメトリによると、少なくとも2016年7月以降、Turlaプログラムがget.adobe.com URLに情報を送信しているという証拠があります。 被害者は旧ソ連の領土にいます。 Turlaが開発したもう1つのマルウェアであるGazerについては、東ヨーロッパの国の領事館と大使館を標的としています。 民間企業でいくつかの感染が確認されていますが、攻撃の主な標的ではないようです。 最後に、ComRATやGazerなど、Turlaが所有する他のマルウェアに感染した被害者もいます。

2.なぜこのキャンペーンをTurlaグループに関連付けるのですか？

異常なネットワーク接続を分析する前に、このTurlaキャンペーンの原因を説明します。



まず、Adobe Flash Playerの偽のインストーラーの一部は、一部のIB企業がTurlaに関連付けているMosquitoバックドアをダウンロードします。



第二に、ホストされたバックドアに関連付けられている一部のC＆Cサーバーは、Turlaに関連する SATCOM IPアドレスを使用するか、以前に使用したことがあります。



第三に、マルウェアはTurlaグループの他のツールと共通の機能を備えています。 類似点には、同一の文字列難読化（スタックに行をプッシュし、0x55でXORを適用する）と同じAPI解像度が含まれます。



リストされた項目を使用すると、キャンペーンとTurlaとの関係を自信を持って判断できます。

3. Adob​​e FlashおよびFlash関連ドメインの違法な使用

偽のFlashインストーラーを使用することは、Turlaにとって新しい戦術ではありません。 そのため、2014年に専門家がこの動作を文書化しました。 ただし、私たちの意見では、マルウェアはまずアドビの正当なURLとIPからHTTP経由でダウンロードされます。 これは、経験豊富なユーザーにとっても混乱を招く可能性があります。

3.1。 adobe.comを介した模倣配布

2016年8月の初めから、admdownload.adobe.comからTurlaインストーラーをダウンロードしようとする試みがいくつか見つかりました。



一見、TCPソケットがC＆CサーバーのIPアドレスにインストールされている間に、HTTP要求のHostヘッダーを設定するという典型的なトリックが表示されるように思われました。 しかし、詳細な分析の結果、IPアドレスは正当であり、正当なFlashインストーラーを配布するためにアドビが使用する大規模コンテンツ配信ネットワーク（CDN）であるAkamaiに属していることがわかりました。



実行可能ファイルが正当なURL（たとえば、 http://admdownload.adobe.com/bin/live/flashplayer27_xa_install.exe



）からダウンロードされた場合でも、参照元フィールドは変更されたように見えます。 このフィールドがhttp://get.adobe.com/flashplayer/download/?installer=Flash_Player



に変更され、Adobeが使用するURLパターンとはhttp://get.adobe.com/flashplayer/download/?installer=Flash_Player



、リクエストで404エラーが発生することがわかりました。



収集されたデータで見つかったすべてのダウンロード試行は、HTTPSではなくHTTP経由で行われたことに注意することが重要です。 これにより、ユーザーのマシンからアカマイサーバーに至るまでの幅広い攻撃を実行できます。



次のセクションでは、潜在的な侵害シナリオについて説明します。 実際に何が起こったのかという問題は未解決のままです。 追加情報があればフィードバックをお寄せください。

3.2。 妥協の仮説

図1は、Turlaマルウェアをダウンロードするために、おそらくHTTP経由で正当なAdobe Webサイトにアクセスするユーザーを強制する方法を説明できる仮説を示しています。





図1.被害者となる可能性のあるマシンとアドビのサーバーとの間の経路上で起こりうる傍受ポイント



IPアドレスはAdobeがFlashを配布するために使用するサーバーに対応しているため、不正なDNSサーバーの仮説をすばやく排除しました。 アドビとの話し合いと調査に基づいたシナリオ5は、攻撃者がFlash Playerダウンロードサイトを侵害しなかったため、ありそうにないようです。 したがって、次のオプションが残ります。



1）ローカルネットワーク内の侵害されたマシンを使用した「中間者」（MitM）による攻撃、

2）侵害されたネットワークゲートウェイまたはプロキシ組織

3）インターネットサービスプロバイダー（ISP）のレベルでのMitM攻撃、

4）BGPルーターに対する攻撃（ Border Gateway Protocolハイジャック ）により、Turlaが制御するサーバーにトラフィックをリダイレクトします。

3.2.1。 MitMローカル攻撃

Turlaのオペレーターは、被害を受けた組織のネットワークで既に侵害されたマシンを使用して、ローカルのMitM攻撃を実行する可能性があります。 ARPスプーフィングを使用して、ターゲットマシンから侵害されたマシンに即座にトラフィックをリダイレクトできます。 そして、Turlaの兵器庫でそのようなツールが利用できることを認識していませんが、このグループの技術的能力を考えると、開発するのは難しくありません。



しかし、さまざまな組織で多くの犠牲者が見つかりました。 これは、Turlaがこれらの各組織内の少なくとも1台のコンピューター、または優先ターゲットのサブネット内のコンピューターを侵害する必要があることを意味します。

3.2.2。 侵害されたゲートウェイ

この攻撃は前の攻撃と似ていますが、攻撃者にとってははるかに興味深いものです-ゲートウェイとプロキシは通常、イントラネットとインターネット間のすべての着信および発信トラフィックを見るため、ARPスプーフィングなしで組織全体のトラフィックを傍受できます。 Turlaで同様の問題を解決するツールの有無については知りませんが、彼らのルートキットUroburosにはパッケージを分析する機能があります。 サーバーにインストールし、プロキシとして使用して、パブリックIPアドレスを持たない感染したマシンにタスクを分散できます 。 Turlaには、ウロブロスコードを変更してトラフィックを即座に傍受し、悪意のあるコンポーネントを導入したり、暗号化されていないコンテンツを変更したりするための十分な専門知識とリソースがあります。

3.2.3。 プロバイダーMitM攻撃

組織の内部ネットワークを離れる前にトラフィックが傍受されなかった場合、トラフィックは後で変更され、Adobeサーバーに到達します。 このセグメントの主なアクセスポイントは、インターネットプロバイダーです。 ESETは以前 、ISPレベルでのパッケージの実装によるFinFisherスパイウェアの配布を発表しました。



私たちが知っているすべての犠牲者は旧ソ連の国にいます。 少なくとも4つのインターネットプロバイダーのサービスを使用します。 したがって、このシナリオでは、Turlaがさまざまな国またはデータ伝送チャネルのトラフィックを監視する機能を持っていると想定しています。

3.2.4。 BGPルーターへの攻撃

トラフィックがサービスプロバイダーによって変化せず、Adobeサーバーに到達しない場合、Turlaオペレーターによって制御されている別のサーバーにリダイレクトされることを意味します。 これは、次のいずれかの方法を使用してBGPルーターを攻撃することで実行できます。



一方では、Turlaのオペレーターは、自律システム（AS）を使用して、adobe.comが所有するプレフィックスをアドバタイズできます。 このようにして、Turla ASによって制御される場所に近い場所からadobe.comに送信されるトラフィックは、サーバーに送信されます。 このような悪意のある活動の例は、 RIPE によって分析されました 。 ただし、これはアドビまたはBGP監視を実行するサービスですぐに認識されます。 さらに、RIPEstatの統計情報を確認しましたが、このキャンペーンで使用されたAdobe IPアドレスの疑わしいルート広告に気付きませんでした。



一方、Turlaオペレーターは、ASを使用して、Adobeサーバーへの他のASよりも短いパスを宣言できます。 したがって、トラフィックもルーターを通過し、リアルタイムで傍受および変更される可能性があります。 ただし、アドビのサーバーへのトラフィックのほとんどは許可されていないルーターにリダイレクトされます。このような戦術は偽装するのが難しく、2016年8月の開始後すぐにキャンペーンが検出される可能性があります。

3.2.5。 まとめ

図1に示されている5つのシナリオのうち、Adobeが侵害されていないと確信しているため、4つだけを調査しました。 BGPルーターへの攻撃とサービスプロバイダーレベルでのMitM攻撃は、他のものよりも複雑です。 Turlaグループは、ターゲット組織のローカルゲートウェイにインストールされた特別なツールを使用すると想定しています。これにより、トラフィックがイントラネットを離れる前に傍受および変更できるようになります。

3.3。 get.adobe.com URLから情報を取得する

ユーザーが偽のインストーラーFlashをダウンロードして起動すると、侵害のプロセスが始まります。 Turlaバックドアの導入から始まります。 これは、セクション4で説明した32ビットWindows用のマルウェアMosquitoである可能性があります。 セクション5で説明したGoogle Apps Script Webアプリケーションと通信する悪意のあるJavaScriptファイル。 または、アドビの偽のURLからダウンロードされた不明なファイル：

http://get.adobe.com/flashplayer/download/update/[x32|x64]







後者の場合、このようなURLはAdobeサーバー上に存在しないため、コンテンツをTurlaグループに転送するには、侵害されたマシンとAdobeサーバー間のパスにMitMなどが必要です。



次に、新しい侵害されたマシンに関する情報を表示するクエリが表示されます。 これはhttp://get.adobe.com/stats/AbfFcBebD/q=<base64-encoded data>



GETリクエストです。 記録によると、アドビは正当なIPアドレスを使用していますが、URLパターンはアドビが使用しているものと類似していないため、リクエスト時に404エラーが発生します。 要求はHTTP経由であるため、セクション3.2で前述したMitM攻撃スクリプトが使用される可能性が最も高くなります。





図2.偽のURL get.adobe.comのリクエストを実行するコード



Base64で暗号化されたデータには、被害者のマシンに関する機密情報が含まれています。 彼女が実際にアドビのサーバーに行ったのは奇妙だろう。 図3は、復号化されたレポートの例を示しています。 データには、一意のID（図4に示すように、Flashインストーラーの偽のインストーラーの最後の8バイト）、ユーザー名、インストールされているセキュリティ製品のリスト、およびARPテーブルが含まれます。





図3.偽のURL URL get.adobe.comに送信されたインストールレポート





図4.インストーラーの最後にある一意のID



興味深いことに、 macOS用のSnakeインストーラー （Turla関連のバックドア）は、図5と同じURLを使用します。送信される情報は、ユーザー名とデバイス名のみを含むため、base64でエンコードされますが、わずかに異なります。 ただし、この動作は、分析の公開時にFox-ITによって文書化されていませんでした。





図5. macOSのSnakeインストーラーの代替URL get.adobe.comでリクエストを実行するコード



最後に、偽のインストーラーが正当なFlash Playerアプリケーションを挿入またはダウンロードして起動します。 正規のインストーラーは、偽のインストーラーに組み込まれるか、GoogleドライブURLへの次のパスを使用してダウンロードされます： https://drive.google[.]com/uc?authuser=0&id=0B_LlMiKUOIstM0RRekVEbnFfaXc&export=download



: https://drive.google[.]com/uc?authuser=0&id=0B_LlMiKUOIstM0RRekVEbnFfaXc&export=download

4. Win32バックドア分析

このセクションでは、主に2017年にインザワイルドで発見されたサンプルについて説明します。 キャンペーンが数年間続いているという証拠が見つかりました。2017年のサンプルは、 InstructionerDLL.dll



ファイルへのバックドアの進化の結果です。 以前のサンプルは難読化されていませんでした;ローダーなしのバックドアDLLのみが含まれていました。 古いサンプルの一部には、2009年のコンパイルタイムスタンプがありますが、ほとんどの場合調整されています。

4.1。 インストーラー

偽のFlashインストーラーとして提供され、さらにディスクにフラッシュされる2つの追加コンポーネントが付属しています。 上記で説明したように、アドビが正規のインストーラーを配布するために使用したURLおよびIPから偽のFlashインストーラーをダウンロードしたユーザーがいくつか見つかりました。

4.1.1。 暗号化

新しいバージョンでは、暗号化を使用して、インストーラーは常に難読化されています。 図6は、このツールで難読化された関数の例を示しています。





図6.難読化された関数



まず、この暗号化プログラムは、算術演算とともにファジー述語を広く使用します。 たとえば、難読化された関数は、ハードコーディングされた値から数値を計算し、別のハードコーディングされた値と大きさを比較します。 したがって、各実行中、プロセスのフローは同じになりますが、正しいパスを決定するにはエミュレーションが必要です。 そのため、アナリストと自動セキュリティソフトウェアアルゴリズムの両方を分析するには、コードが複雑すぎます。 これにより、時間制限のためにオブジェクトがスキャンされない程度にエミュレーションが遅くなり、その結果、示された（難読化されていない場合）マルウェアが検出されなくなります。



次に、難読化解除の最初の段階の後、Win32 API SetupDiGetClassDevs(0,0,0,0xFFFFFFFF)



呼び出しが行われ、暗号化プログラムは受信した値が0xE000021Aと一致するかどうかを確認します。 この関数は通常、システム内のデバイスに関する情報を取得するために使用されます。 テストによると、 Flags (0xFFFFFFFF)



の特定の値は文書化されていませんが、Windows 7およびWindows 10のマシンでは、結果の値は常に0xE000021A



に対応します。方法。



第三に、このコードはいくつかのフラグメントに分割され、特別な関数を使用して解読され、実行時にメモリ内にPEを作成するように順序付けられます。 次に、PEエンコーダーのブートローダー機能を使用して実行されます。 このPEローダーには、図7に示すように、いくつかのデバッグ行が含まれています。





図7. PEローダー機能のデバッグ行

4.1.2。 設置

復号化後、インストーラーは%APPDATA%



サブフォルダーを検索し、2つのファイルを最長パスのフォルダーにドロップします。 このようなフォルダーを検索する場合、名前にAVAST



という単語が含まれるフォルダーはすべてバイパスされます。 次に、このフォルダー内の隠されていないファイルの1つの名前を、拡張子が切り取られたものをダンプファイルのベース名として使用します。 ディレクトリ内のすべてのファイルが非表示の場合、またはディレクトリが空の場合、 %WINDIR%\System32



DLL名が使用されます。 リセットブートローダーの拡張子は.tlb



で、メインのバックドアは.pdb



です。 興味深いことに、2つのDLLをフラッシュするためにWriteFile



を使用しません。 代わりに、ファイルを作成してメモリ内にマークし、 memmove



を呼び出してデータをコピーします。 おそらくこれは、 WriteFile



セキュリティ製品とサンドボックスへのフックをバイパスするために行われます。



また、 .tlb



拡張子を持つファイルを1つだけダウンロードする以前のインストーラーオプションも確認しました。 この場合、同じファイルにブートローダー機能とバックドア機能が含まれています。 DllMain



は、実行するコードを選択します。



彼は、単純な暗号化されていないログファイルを%APPDATA%\kb6867.bin



ます。 完全なファイルは、これら2つのDLLと同じディレクトリに作成され、拡張子は.tnl



です。





図8.ランダムな子ディレクトリに作成されたファイル％APPDATA％



次に、Runレジストリキーを使用するか、 COMをインターセプトして永続性を提供します。 Windows Management Instrumentation（WMI）によって取得されたウイルス対策表示名がTotal Securityと一致する場合、 rundll32.exe



[バックドアへのパス]エントリStartRoutine



をHKCU\Software\Microsoft\Windows\CurrentVersion\Run\auto_update



ます。



それ以外の場合、 HKCR\CLSID\{D9144DCD-E998-4ECA-AB6A-DCD83CCBA16D}\InprocServer32



またはHKCR\CLSID\{08244EE6-92F0-47F2-9FC9-929BAA2E7235}\InprocServer32



のレジストリエントリを置き換えます。 これらのCLSIDは、それぞれEhStorShell.dll



とntshrui.dll



です。 これらのDLLは、 explorer.exe



（Windows GUI）を含む多くのプロセスによって正当に起動されます。 したがって、ブートローダーはexplorer.exe



起動されるたびに呼び出されます。 最後に、図9に示すように、元のインターセプトされたDLLとメインバックドアへのパスを格納するレジストリエントリを追加します。





図9.持続可能性のためのレジストリの変更



残りのCLSIDはバイナリにハードコーディングされていますが、使用されたことは確認していません。 完全なリストは、侵害の兆候を示すセクションで入手できます。



前のセクションで説明したように、インストーラーは一意のサンプルID、ユーザー名、ARPテーブルなどの情報をAdobeドメインURL get.adobe.com



送信します。 また、実際のAdobe Flashインストーラーも起動します。これは、Googleドライブからダウンロードするか、偽のインストーラーに組み込むことができます。



メインバックドアを開始する前に、インストーラーはsysQ!123



パスワードでHelpAssistant



管理者HelpAssistant



（または一部のサンプルではsysQ!123



）をsysQ!123



ます。 LocalAccountTokenFilterPolicy



が1



に変更され、リモート管理アクションが許可されます。 このアカウント名は正当なリモートアシスタンスセッション中に使用されるため、このアカウント名は気付かないために必要であると考えています。

4.2。 DebugParser（ランチャー）

DebugParser.dll



と呼ばれるランチャーは、インターセプトされたCOMオブジェクトの読み込み中に呼び出されます。 彼は、メインのバックドアを起動し、インターセプトされたCOMオブジェクトをロードする責任があります。 コンポーネントの簡略化された擬似コードを図10に示します。





図10.擬似コードの起動



ただし、インターセプトされたライブラリをロードして正しいアドレスに戻るためにいくつかのトリックを使用します。 プロセスは以下のとおりです。



1. LoadLibrary



正当な呼び出しの後、元の返信先アドレスを取得します。 DllMain



の開始時DllMain



ESPレジストリ値が保存されます。 次に、彼はESP-6でFF 15



（オペレーションコードCALLの呼び出し）をチェックします。存在する場合、レジストリは元の返信先アドレスを残します。





図11. LoadLibraryを呼び出した後のアドレスの検索



2.次の値を含むRWXメモリを割り当てます。





図12.メモリ割り当て



3. DllMain



応答DllMain



変更して、代行受信機能に移動しDllMain



。



4.インターセプト機能で：

a。 ntshrui.dll



（または他のインターセプトされたライブラリ）の読み込みを担当する関数の呼び出し

b。 DebugParser.dll



（バックドアローダー）へのFreeLibrary



呼び出し

c。 代行受信前の元の応答アドレスへのナビゲーション。



元のDLLがロードされているため、ユーザーはバックドアが実行されていることに気付かないでしょう。



ブートローダーとバックドアの機能が1つのファイルにまとめられている初期のバージョンでは、 DllMain



は実行するコードを選択します（図13を参照）。





図13. 1つのライブラリのローダーとバックドア

4.3。 メインバックドア

このキャンペーンのメインのバックドアであるCommanderDLL.dll



は、作成者によって命名されたものであり、選択された永続化メカニズムがレジストリのRunキーである場合、上記のブートローダーによって起動されるか、起動時に直接起動されます。 どちらの場合も、図14に示すように、 StartRoutine



ライブラリのエクスポートがStartRoutine



れますが、このエクスポートはDLLエクスポートテーブルにはありません。





図14. DLLの.relocセクションにEXPORTアドレステーブルがありません



DllMain



関数で、出力用のエクスポートテーブルが作成されます。

1.単一のエクスポートの名前としてIMAGE_EXPORT_DIRECTORY



を使用してIMAGE_EXPORT_DIRECTORY



構造を作成します

2.メモリ内のPEイメージの最後にあるパーティションを移動した後、この構造をコピーします

3.エクスポートテーブルの相対仮想アドレス（RVA）を含むPEのヘッダーフィールドを、新しく作成されたエクスポートテーブルのアドレスに変更します。



これらの変更により、図15および16に示すように、インメモリライブラリにはStartRoutine



というエクスポートがあります。図17は、このエクスポートを追加するプロセス全体のコードを示すHex-RaysデStartRoutine



のスクリーンショットです。





図15.新しく作成されたエクスポートテーブル





図16.新しいエクスポートの名前





図17.エクスポートテーブルのパッチ適用プロセス

4.3.1。 カスタマイズ

まず、 CommanderDLL



モジュールはドロッパーファイル（偽のFlashインストーラー）を削除します。 パスは、 \\.\pipe\namedpipe



という名前のパイプを介してドロッパーから渡されます。 次に、新しいプロセスで、2番目の名前付きパイプ\\.\pipe\ms32loc



を作成し、別のプロセスがこのチャネルに接続するまで待機します。その後、プログラムは終了します。



次に、CommanderDLLはいくつかの内部構造を構成し、構成値をレジストリに保存します。 表1では、 HKCU\Software\Microsoft\[dllname]



格納されているさまざまなレジストリ値について説明しています。



表1.レジストリのバックドア値





レイアウトエントリを除くすべてのレジストリ値は、セクション4.3.2で説明されている特別なアルゴリズムを使用して暗号化されます。



3 番目に、C＆Cサーバーの追加アドレスは、Google Docs （https://docs.google [。] Com / uc？Authuser = 0＆id = 0B_wY-Tu90pbjTDllRENWNkNma0k＆export = download）に保存されているドキュメントからダウンロードされます。 4.3.2で説明されているアルゴリズムを使用して暗号化されます。

4.3.1。 暗号化

バックドアは特別な暗号化アルゴリズムを使用します。プレーンテキストの各バイトは、Blum Blum Shubアルゴリズムに類似した関数によって生成されたストリームにモジュロ2で追加されます。暗号化または復号化の場合、キーとモジュールは暗号化機能に転送されます。



異なるサンプルは異なるキーとモジュールを使用します。一部はハードコーディングされており、一部は実行中に生成されます。表2に、マルウェアが使用するさまざまなキーとモジュールを示します。



表2.暗号化キーとモジュール

4.3.3。ログ

プログラムはと呼ばれるログファイルを保持します[dllname].tnl



。興味深いことに、各レコードのタイムスタンプが含まれているため、侵害されたマシンで発生する一連のイベントを追跡できます。これは、サイバー犯罪者にとって有用です。上記のアルゴリズムを使用して暗号化されます。キーは、ログファイルのヘッダーの0x20のインデントの後にあり、モジュールは常に0x5DEE0B89です。図18に、このファイルの構造を示します。





図18.ログファイルの構造





図19.ログファイルの開始

4.3.4。C＆Cサーバーのデータ交換とバックドアコマンド

メインのバックドアループは、C＆Cサーバーとのデータ交換を管理し、送信されたコマンドを実行します。それらのそれぞれの開始時に、彼はランダムな期間非アクティブですが、通常は約12分です。



サーバーへの要求は常に同じスキームにURLを使用していますhttps://[C&C server domain]/scripts/m/query.php?id=[base64(encrypted data)]



。ユーザエージェントは、ハードコードされた試料であり、変更することはできません。

Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36







このデフォルト値は、Google Chromeの41のパラメータの構成に使用されるid



図20に記載されている





図20のC＆Cへのクエリの構造-パラメータIDのデータとGETサーバ要求



前のパターン- id



GET要求パラメーターに構造が含まれる場合Data



。ただし、データはCookie（フルネーム）またはPOSTリクエストに含まれている場合があります。図21は、さまざまな可能性を説明しています。



これらすべての場合において、暗号化キーはid



URL 構造の最初のDWORDです。 0x7DFDC101モジュールと組み合わせたキーは、構造id



、POSTデータ、およびCookie値を解読できます。次に、データ構造からのペイロードが復号化されます。





図21は、要求を選択する



元の要求は、コマンドの結果として侵入したマシンの一般的な情報が含まれipconfig



、set



、whoami



およびtasklist



。



その後、C＆Cサーバーは一連の指示の1つを応答として発行します。この答えの構造を図21に示します。パケットは、セクション4.3.2で説明したBlum Blum Shubから借用した同じアルゴリズムで完全に暗号化されます（最初の4バイトを除く）。各命令セットは、キーが0x3EB13、モジュールが0x7DFDC101で個別に暗号化されます。





図22. C＆C応答パケットの構造



バックドアは、バイナリファイルにハードコードされた事前定義済みのアクションを実行できます。表3に、使用可能なコマンドの簡単な説明を示します。



表3.使用可能なバックドアコマンドの説明





一部の分析サンプルでは、​​バックドアはPowerShellスクリプトも実行できます。

5. JavaScriptバックドア分析

一部の偽のFlashインストーラーは、Mosquitoの代わりに2つのJavaScriptバックドアを提供します。これらのファイルは、フォルダー内のディスクにフラッシュされます%APPDATA%\Microsoft\



。彼らは呼ばれgoogle_update_checker.js local_update_checker.js



ます。



最初は、Google Apps ScriptサービスでホストされているWebアプリケーションとやり取りし(https://script.google[.]com/macros/s/AKfycbwF_VS5wHqlHmi4EQoljEtIsjmglLBO69n_2n_k2KtBqWXLk3w/exec)



ます。base64でエンコードされた応答を期待しています。次に、evalを使用してデコードされたコンテンツを実行します。追加のバックドアの正確な目的はわかりませんが、追加のマリバリをダウンロードしたり、悪意のあるJavaScriptコードを直接実行したりするために使用できます。永続性を確保するために、値Shell



をに追加しますHKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon



。



2番目のJavaScriptファイルは%ProgramData%\1.txt



、関数を使用してコンテンツを読み取り、実行しますeval



。永続性を確保するために、価値を追加しますlocal_update_check



c HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run



。

6.結論

このキャンペーンは、Turlaサイバーグループが悪意のあるトラフィックを正当なものとしてマスクする多くのツールを持っていることを示しています。使用する方法は、経験豊富なユーザーにとっても混乱を招く可能性があります。 HTTPを使用すると、このような攻撃の有効性が低下する可能性があります。このプロトコルでは、マシンからリモートサーバーへの途中で暗号化されたトラフィックを傍受して置き換えることはより困難です。 Adobeインストーラーとは異なり、Turlaが使用するファイルは署名されていないため、ファイル署名の検証は疑わしいはずです。



さらに、この新しいキャンペーンは、東ヨーロッパにある領事館と大使館に対するトゥルラの関心を示しています。グループは、これらの情報源へのアクセスを提供するために多くの努力をしています。



キャンペーン関連の質問については、threatintel @ eset.comにお問い合わせください。

7.侵害の指標

7.1。 コマンドサーバーアドレス（年単位）

2017: smallcloud.ga

2017: fleetwood.tk

2017: docs.google.com/uc?authuser=0&id=0B_wY-Tu90pbjTDllRENW

NkNma0k&export=download (adstore.twilightparadox.com)

2017: bigpen.ga

2017: https://script.google.com/macros/s/AKfycbxxPPyGP3Z5wgwbs

mXDgaNcQ6DCDf63vih-Te_jKf9SMj8TkTie/exec

2017: https://script.google.com/macros/s/AKfycbwF_VS5wHqlH

mi4EQoljEtIsjmglLBO69n_2n_k2KtBqWXLk3w/exec

2017-2015: ebay-global.publicvm.com

2017-2014: psychology-blog.ezua.com

2016: agony.compress.to

2016: gallop.mefound.com

2016: auberdine.etowns.net

2016: skyrim.3d-game.com

2016: officebuild.4irc.com

2016: sendmessage.mooo.com

2016, 2014: robot.wikaba.com

2015: tellmemore.4irc.com

7.2。 アドビの偽アドレス

http://get.adobe[.]com/stats/AbfFcBebD/?q=<base64-encoded data>

http://get.adobe[.]com/flashplayer/download/update/x32

http://get.adobe[.]com/flashplayer/download/update/x64

7.3。 正当なFlashインストーラーの非公式アドレス

https://drive.google[.]com/uc?authuser=0&id=0B_LlMiKUOIsteEtraEJYM0QxQVE&export=download

https://drive.google[.]com/uc?authuser=0&id=0B_LlMiKUOIstM0RRekVEbnFfaXc&export=download

7.4。 ハッシュ

7.5。 Windowsアーティファクト

7.5.1。インターセプトされたCLSID

{D9144DCD-E998-4ECA-AB6A-DCD83CCBA16D}

{08244EE6-92F0-47F2-9FC9-929BAA2E7235}

{4E14FBA2-2E22-11D1-9964-00C04FBBB345}

{B5F8350B-0548-48B1-A6EE-88BD00B4A5E7}

{603D3801-BD81-11D0-A3A5-00C04FD706EC}

{F82B4EF1-93A9-4DDE-8015-F7950A1A6E31}

{9207D8C7-E7C8-412E-87F8-2E61171BD291}

{A3B3C46C-05D8-429B-BF66-87068B4CE563}

{0997898B-0713-11D2-A4AA-00C04F8EEB3E}

{603D3801-BD81-11D0-A3A5-00C04FD706EC}

{1299CF18-C4F5-4B6A-BB0F-2299F0398E27}

7.5.2。 ファイル

フォルダー内の同じ名前で異なる拡張子（.tlb、.pdb、および.tnl）を持つ3つのファイル%APPDATA%





%APPDATA%\kb6867.bin



（簡略化されたログファイル）

7.6。ESET検出

7.6.1。最近のサンプル

Win32/Turla.CQ

Win32/Turla.CP

Win32/Turla.CR

Win32/Turla.CS

Win32/Turla.CT

Win32/Turla.CU

Win32/Turla.CV

Win32/Turla.CW

Win32/Turla.CX

7.6.2。古いオプション

Win32/TrojanDownloader.CAM

Win32/TrojanDownloader.DMU

7.6.3。JavaScriptバックドア

JS/Agent.NWB

JS/TrojanDownloader.Agent.REG