https://blogs.sophos.com/2015/07/21/a-closer-look-at-the-angler-exploit-kit/
過去数年間、犯罪者はトロイの木馬感染活動を実行するために EK (エクスプロイト攻撃ツール) を広く使用してきました。 EK ツールは通常、「ドライブバイ」と呼ばれる攻撃フェーズで出現し、ユーザーのブラウザを悪意のある Web サイトに密かに誘導し、そこに EK が配置されます。
その後、EK はセキュリティの脆弱性を悪用して、ユーザーをトロイの木馬に感染させます。プロセス全体を完全に非表示にすることができ、ユーザーによるアクションは必要ありません。
この記事では、悪名高き Angler EK について研究しています。
Angler は 2013 年末に初めて登場しました。それ以来、犯罪市場における Angler の人気は飛躍的に高まりました。セキュリティ製品の検出を回避するために、Angler はさまざまなコンポーネント (HTML、JavaScript、Flash、Silverlight、Java など) およびこれらのコンポーネントのさまざまなバリアントを使用します。 Angler が非常にアクティブであることも言及する価値があります。たとえば、2015 年 5 月には、「ランディング ページ」とも呼ばれる新しい Angler トラップ ページが毎日何千件も発見されていました。
毎週の検出量から判断すると、Angler は 2014 年半ばに出現し始め、2014 年末に突然発生し、その後わずかに減少し、2015 年以降活動の数が再び増加し始めました。
図 1 - 毎週の検出量に基づくアングラーの成長傾向
Blackhole EK が 2013 年 10 月に活動を停止し、関連する攻撃者が逮捕されて以来、他の EK が開発され、セグメント化されて市場シェアが増加しましたが、支配的なのはアングラーEKです。 Angler の人気を示すために、3 つの異なる期間 (2014 年 9 月、2015 年 2 月、2015 年 5 月) における各 EK のアクティビティを分析しました。
図 2- 毎週の検出によって測定された EK アクティビティの分布データ、2014 年 9 月、2015 年 2 月、および 2015 年 5 月
どの EK もターゲット コンピューターのみを悪用することは明らかです 脆弱性が発見され、トロイの木馬がインストールされた場合にのみ、悪用できる可能性があります成功とみなされます。ただし、EK は潜在的な被害者に関する情報を把握するために大量の入力トラフィックも必要とします。ほとんどのドライブバイ ダウンロードでは、正規の Web サイトをハッキングし、悪意のある HTML または JavaScript を挿入することでこれが行われます。被害者の Web サイトのレベルと人気が高いほど、EK が受け取るトラフィックは増加します。
私たちは、ユーザーの Web トラフィックを Angler に送信するためのいくつかの手法を発見しました。その多くは単純な IFRAME (埋め込み HTML フレームワーク) インジェクション (通常は HTML または Javascript) を使用しますが、これはあまり興味深いものではありません。ただし、Angler で使用されるリダイレクト方法の一部はより具体的であり、ここで言及する価値があります。
前に、一般にユーザーはリダイレクト プロセスを見ることができないと述べました。実際には、これが常に当てはまるとは限りません。たとえば、2014 年 5 月の最初の例から判断すると、次のように、多数の正規の Web サイトに JavaScript と HTML の両方が挿入されていることがわかりました。通常のインジェクションとは異なり、ここでは FORM 要素と DIV 要素も一部の JavaScript に追加されます:
図 3 - ページの読み込み時に挿入された JavaScript と HTML (Troj/JSRedir-OA として検出)
を選択すると、[はい] または [キャンセル] をクリックするように求めるダイアログ ボックスが表示されます。挿入された JavaScript に従って、どれがクリックされても Go() 関数が実行されます。ポップアップ ウィンドウを削除し、IFRAME プレースホルダーを追加して、フォームを送信します。
図 4 -ユーザーのブラウザは、Troj/JSRedir-OA のときに表示されるポップアップ ウィンドウ
フォームによって送信されたデータには、おそらく犯罪者がこのリダイレクト メカニズムを管理するのを支援するための 3 つの値 (エンコードされた) が含まれています:
次に、POST フォームへの応答は HTML と JavaScript (IFRAME プレースホルダーにロードされます) )、ユーザーをリダイレクトするには:
図 5 - HTTP POST リクエストの応答にはリダイレクト用の JavaScript が含まれています
数か月後、同様の手法を発見しましたが、今回は Flash コンポーネントでした。侵害された Web サイトは、別の侵害された Web サイトから悪意のある Flash ファイルを読み込む HTML を含むように変更されています。
次に、この Flash ファイル内の ActionScript はさまざまなパラメーターを取得し、HTTP POST リクエストを作成します。
図 6 - Troj/JSRedir-OA の Flash バージョンで使用される ActionScript
HTTP POST リクエストに対する応答は以前と同じであり (図 5)、返される HTML と JavaScriptユーザーをリダイレクトします。興味深いことに、2015 年の初めに、Nuclear EK もこの後者のリダイレクト技術を使用してトラフィックを送信していることが判明しました。
さらに、Angler がリダイレクトにドメイン名生成アルゴリズム (DGA) を使用していることも観察されました。 2014 年、多数の正規 Web サイトに JavaScript が挿入され、ホスト名が現在の日付のハッシュに基づいて決定されたリモート Web サイトからコンテンツをロードするためのスクリプト要素が追加されました。このアイデアは、毎日異なるドメイン名を使用するというものですが、悪意のあるスクリプトには将来使用されるドメイン名がありません。これらの DGA リダイレクトでは、.EU および .PW ドメイン名が使用されました。
図 7 - DGA リダイレクト (Troj/JSRedir-OE) を使用した JavaScript のコード スニペット
このリダイレクト方法には欠点があります。アルゴリズムが分かれば、セキュリティ コミュニティは特定のターゲット ホスト名を予測できるようになります。日付と傍受に使用され、攻撃を効果的にブロックします。
この章の最後の例では、HTTP 応答コード 302 が使用されます。これは通常、正規の Web サイトで使用され、訪問者を次の Web サイトに誘導するために使用されます。他のウェブサイト。これには、コンテンツの挿入とリダイレクト プロセスとの接続が含まれます。 2015 年 4 月に、ユーザーが eHow Web サイトを閲覧しているときに Angler にリダイレクトされることに気づきました。図 8 に示すように、トラフィックを分析することでリダイレクト プロセスを特定しました。
JavaScript が ehowcdn.com の正規ライブラリに挿入され、Optimizely サーバーからコンテンツを読み込むように見えます (Optimizely は、通常、Web 広告の効果を評価するために、Web サイト分析サービスを提供します)。ただし、optimizelys.com のホスト名の末尾には「s」があり、有効なドメイン名は optimizely.com であることに注意してください。
図 8 - Optimizely を装った最近のリダイレクト
1: eHow Web サイトの Web ページ、2: ehowcdn.com のスクリプトが optimizelys.com からスクリプトをロードします、3: 使用悪意のある iframe スクリプトを追加するには、4:302 Angler ログイン ページにジャンプします
これが観察されてから数日間、同じリダイレクトが他の Web サイト (やはり cdn3.optimizelys.com) で見つかったという報告がありました。最終目標はNuclear EKです。
「ランディング ページ」は、脆弱性攻撃ツール コードの開始点です。通常、ランディング ページでは HTML および JavaScript コンテンツを使用して訪問者のブラウザとインストールされているプラグインを識別し、EK がドライブバイ ダウンロードを引き起こす可能性が最も高い攻撃ベクトルを選択できるようにします。
Angler ログイン ページでは複数の難読化手法が使用されています。これらの手法により、分析がより困難になるだけでなく、犯罪者がリクエストごとに異なるコンテンツを作成することが容易になり、セキュリティ製品による検出を回避できます。過去数年間、Angler は主要なスクリプト機能をデータ文字列にエンコードし、親 HTML に保存してきました。次に、ブラウザがログイン ページをロードすると、このコンテンツをフェッチしてデコードします。このアンチエミュレーション技術を使用する悪意のある脅威が数多く存在します。
難読化の最外層をデコードした後、Angler が使用する別の手法であるアンチサンドボックス化が暴露されます。 Angler は、IE ブラウザの XMLDOM 関数を使用して、ローカル システム上のファイル情報を確認します。これは、システム上のセキュリティ ツールと仮想化製品を検出するために行われます。
図 9 - さまざまなセキュリティ ツールと仮想化製品を検出する Angler ログイン ページのコード スニペット
アンチサンドボックス検出の下には、難読化の 2 番目のレイヤーがあります。いくつかの長い文字列を Unicode (2 バイト) データに変換するために関数が呼び出されます。その一部は実際には、後で Web ページに追加されるスクリプト コンテンツです。ほとんどの場合、これは JavaScript ですが、場合によっては VBScript コンテンツ (特に CVE-2013-2551 の対象) であることもあります。
図 10 - 難読化の 2 番目の層、シェルコード データとページに追加された追加スクリプトを隠す コンテンツ (CVE- 2013-2551 はターゲットとなる脆弱性なので、JS および VBS コンテンツを追加する必要があります)
ログイン ページの各バージョンで、追加されたスクリプト コンテンツは特定の脆弱性をターゲットにするものです。ただし、追加されたすべてのスクリプトには次のコードが含まれます:
Angler ログイン ページには暗号化された文字列配列が含まれており、デコード ページでは、JavaScript 関数によって各文字列をデコードするための単純な置換パスワードが提供されます。 (エンコードされた文字列は一連の変数に格納される場合もありますが、より一般的には配列です。) トロイの木馬で使用される秘密キーは通常、配列 (uhBNwdr[0] の下) の最初の文字列です:
図 11 - Angler ログイン ページで使用される置換パスワード
この配列のサイズと内容は、このバージョンの EK が対象とする脆弱性によって異なります。配列に保存されるデータには次のものが含まれます:
このデータは取得してデコードする必要があります。ここでは、動的に生成されたシェルコードに統合された関連ペイロード文字列を確認できます。
図 12 - Unicode 文字列の作成に使用される JavaScript 関数。これは、シェルコードが CVE-2014 -6332、Unicode 文字列を悪用するときに使用されます。
はデコードされます。悪意のある Flash コンポーネントをロードするために使用されるコードは単純です。アンチサンドボックス検出に合格したと仮定すると、3 つの特徴的な (get*) 関数がログイン ページの文字列を取得してデコードします。次に、これらの文字列を使用して HTML オブジェクト要素が作成され、ドキュメントに追加されます。
図 13 - 悪意のある Flash コンテンツをロードするために使用される Angler ログイン ページのコード
長年の開発を経て、Angler’s Flash コンテンツも大きな変化を遂げました。サンプルは、次のようなさまざまな手法を使用して難読化されています。
さらに、Angler は埋め込み Flash オブジェクトを使用します。ログイン ページからロードされる最初の Flash は悪意のあるものではなく、内部 Flash を介して脆弱性を提供するローダーとして機能するだけです。この内部 Flash は、binaryData オブジェクトであるか、ActionScript 内の文字列としてエンコードされている場合があります。どちらの場合も、データは RC4 を使用して暗号化されます。 1 月の例を次に示します。
図 14 - 最も外側の Flash は、RC4 および Base64 を使用してエンコードされた内側の Flash を伝送します
ログイン ページのデータは、ログイン ページ HTML A FlashVars で使用されますパラメータはフラッシュに渡されます。これは、最近 EK でよく使用されるテクノロジです。
ActionScript には、loaderInfo オブジェクトのパラメータ属性を通じてアクセスできます。多くの EK はこのメカニズムを利用して、次のようにします。
で渡されます。この柔軟性により、 Flash 自体を再コンパイルすることなく、シェルコードを動的に変更できるようにします。
図 15 は、ログイン ページからエンコードされたデータ (「exec」変数) を取得するために、最近の Angler Flash オブジェクトで使用される ActionScript コード スニペットです。あるいは、特定の関数で制御フローの難読化を使用して、分析をより困難にすることもできます。
図 15 - ログイン ページからエンコードされたデータ (「exec」変数) を取得し、ActionScript 関数を介してデコードします
2015 年初頭に、Adobe Flash Player のゼロデイ脆弱性がいくつか出現しました (CVE-2015-0310、CVE-2015-0311、CVE-2015-0313、CVE-2015-0315、CVE-2015-0336、 CVE-2015-0359)、Angler はこれらの脆弱性をすぐにターゲットにしました。
Oracle が Java 7 Update 51 でデフォルトで署名のないブラウザの使用をブロックしているため、過去 18 か月間で Java ではなく Flash の脆弱性を悪用した攻撃が増加しています。
上記のように、ブラウザがログインページをロードすると、スクリプト内でシェルコードが動的に生成されます。シェルコードの内容は対象となる脆弱性によって異なりますが、エンコード方法と構造はすべて類似しています。以下の分析では、CVE-2014-6332 をターゲットにするために使用されるシェルコードについて説明します。
一見すると、シェルコード データ (図 10 および図 12 のshellcode_part1、shellcode_part2、およびshellcode_part3) に有効なコードが含まれていないことがわかります。さらに詳しく調べてみると、その理由がわかります。追加のデータが VBScript コンポーネントからシェルコードの先頭に読み込まれているからです。図 12 の JavaScript build_shellcode() 関数は、実際には VBScript から呼び出されます (図 16)。
図 16 - CVE-2014-6332 の脆弱性に対するシェルコードの構築に使用される VBScript のコード スニペット
VBScript によって提供される追加の Unicode データを分析することで確認されました (図 16 の buildshell1) このコードは実行可能であり、ペイロード URL や復号化キーなど、シェルコードの他の部分からバイトを復号化する復号化ループが含まれています。この復号化ループは、図 12 の encData() 関数を逆に行い、ペイロード URL とペイロード シークレットが暗号化されます。
図 17 - VBScript によって提供される復号化ループを示すシェルコード スニペット
別のログイン ページのサンプルを確認しました。今回は CVE-2013-2551 を対象としています。このサンプルでは同じ手法が使用されていますが、今度は、復号化ループが JavaScript に追加されます:
図 18 - 完了時の図 17 と同じシェルコード復号化ループを示す JavaScript スニペット
このサイクルの後、メインのシェルコード本体は次のようになります。復号化されて分析できるようになります。
kernel32 のベース アドレスを解析した後、シェルコードはエクスポート アドレス テーブルを解析して、必要な関数 (ハッシュによって識別される) を見つけます。次に、シェルコードは LoadLibrary API を使用して winhttp.dll をロードし、これらのエクスポートを解析して必要な関数を見つけます:
| 模块 | 函数(根据哈希导入) |
|---|---|
| kernel32.dll | CreateThread, WaitForSingleObject, LoadLibraryA, VirtualAlloc, CreateProcessInternalW, GetTempPathW, GetTempFileNameW, WriteFile, CreateFile, CloseHandle |
| winhttp.dll | WinHttpOpen, WinHttpConnect, WinHttpOpenRequest, WinHttpSendRequest, WinHttpReceiveResponse, WinHttpQueryDataAvailable, WinHttpReadData, WinHttpCrackUrl, WinHttpQueryHeaders, WinHttpGetIeProxyConfigForCurrentUser, WinHttpGetProxyForUrl, winHttpSetOption, WinHttpCloseHandle |
エクスプロイトが成功すると、シェルコードはペイロードをダウンロードし、前述のキーを使用して復号化します。 Angler は、エクスプロイト パスに応じて異なるキーを使用します (Internet Explorer、Flash、Silverlight - 少なくとも 2 つの既知のキー)。
ペイロードを解析した後、シェルコードはヘッダーを調べて、ペイロードがシェルコード (最初は何も行わない NOP 関数を起動する) であるか、Windows プログラム (最初にテキスト文字列 "MZ" を識別する) であるかを識別します。 :
図 19 - シェルコードでペイロード タイプをチェックするロジック
復号化されたペイロードがプログラムの場合、プログラムは保存されて実行されます。これが第 2 段階のシェルコードである場合、最終的な実行可能ペイロードはシェルコードの本体に埋め込まれます (32 ビットと 64 ビットの両方)。
第 2 段階のシェルコードが実行されると、ペイロードは最初にディスクに書き込まれることなく、脆弱なアプリケーション プロセスのメモリに直接挿入されます。この「ファイル書き込みなし」機能は、Angler に最近追加された機能です。このメカニズムは、ユーザーを Bedep トロイの木馬ファミリーに感染させるために使用され、攻撃者が追加のトロイの木馬をダウンロードできるようにします。
このセクションでは、コンテンツ分析から Angler のネットワーク アクティビティに焦点を移します。
ほとんどの Web 攻撃では、Angler は最後に登録されたドメイン名を使用します。
ドライブバイ ダウンロード攻撃では、いくつかの登録アドレスが短期間に同じ IP に解決されることがよく見られます。
Angler は、EK によって広く使用されているテクノロジーである無料のダイナミック DNS サービスも使用する場合があります。
アングラーは、DNS レコードを追加するために多数のハッキングされたドメイン名も使用しています。この技術は、最近、人気が高まっているようです。また。これらの犯罪者は、いくつかの正当なドメイン名の DNS レコードを更新し、悪意のある EK を指す複数のサブドメインを追加しました。これはドメイン シャドウイングと呼ばれる手法です。
図 20 に例を示します。これらのアクティビティは 2015 年 5 月に発生しました。これらのキャンペーンでは、DNS レコードがワイルドカード エントリ ( *.foo.example.com 、 *.bar.example.com ) で更新される、より高度な手法が使用されました。この攻撃では、DNS レコードが次のように更新されました:
これこれにより、攻撃者はシャドウ ドメイン名を悪意のある IP に解決できます。この IP は、この記事の時点ではロシアのコンピュータから発信されたものです。 Angler リダイレクトで使用されている第 3 レベルのドメイン名は 6 文字の文字列であることがわかります。これは、おそらく攻撃者がトラフィックの発信元を追跡して特定できるようにするためです (おそらく会計と支払いの目的で)。
図 20 - Angler によって使用されるドメイン シャドウ (レベル 2 のサブドメイン) (2015 年 5 月)
他のいくつかの例では、Angler がレベル 1 DNS 攻撃を悪用していることがわかりました。 21 - Angler によって使用されるドメイン シャドウ (第 1 レベルのサブドメイン) (2015 年 5 月)
他の場合には、サブドメインで使用される文字列がシャドウ ドメインに関連しているように見えます。これは、プログラムによってランダムに生成された文字列ではなく、人間の関与を示しています。
ドメイン シャドウイングでは、犯罪者が正当な DNS レコードを変更できる必要があります (おそらく、盗まれた資格情報を使用して)。すべての Web サイト所有者が DNS レコードの重要性を理解しているわけではないため、多くのベンダー/レジストラは DNS 構成を気にしません。
ほとんどの Web サイト所有者が DNS レコードを更新する必要はほとんどないため、更新にはユーザーの認証情報にのみ依存するだけではなく、より強力な保護が必要です。
2 要素認証を実装する
図 22 は、2015 年 2 月 26 日の DNS クエリ アクティビティを示しています。これには、3 つのドメイン名のデータ (すべて同じ侵害されたアカウントからのもの) が含まれています。緑色の円は全体のクエリ量を表し、紫色の四角形は平均を超えるクエリ量を示し、白い円は攻撃者が Angler のトラフィックでこれらのドメインを使用し始めたときに急速に増加したクエリ量を示しています。
図 22-2015 年 2 月 16 日の 3 つのドメイン名の DNS クエリ時間
これらのデータから、この攻撃には 2 つの段階があることがわかります。まず、攻撃者は午前 10 時に少数の DNS クエリを使用して DNS レコードをテストしました。これらのクエリはレベル 1 サブドメイン (foo.domain.co.uk) をテストし、すべてのクエリは同じソースからのものです。
攻撃者がドメインの解決に満足すると、大量の悪意のある Angler トラフィックがレベル 2 のサブドメインを使用していることが判明しました。図 22 では、攻撃者が異なるドメイン名を使用しており、それぞれのドメイン名が短期間しかアクティブにならないことがわかります。これは、テレメトリ データの検出とも一致しており、各ホスト名で同様のアクティビティが大量に見つかっています。
この情報を通じて、これらのインフラストラクチャをより深く理解し、ユーザー トラフィックを制御および管理できます。
ドライブバイ攻撃の複数のコンポーネントは、ユーザー トラフィック内の悪意のあるアクティビティを識別するために使用できる URL 構造を使用します。これまで、EK はさまざまなコンポーネントで予測可能な URL 構造を使用し、セキュリティ ベンダーが悪意のあるコンテンツを検出してブロックすることを容易にしてきました。 Nuclear および Blackhole EK の一部のサンプルに含まれています:
同様の欠陥は初期の Angler にも現れましたが、Angler はそれ以来進化を続け、コンポーネントで使用される簡単に識別できる URL を含め、これらの弱点を徐々に除去してきました。
この最後のセクションでは、Angler を介してインストールされるトロイの木馬の概要を説明します。これらのトロイの木馬を調査するために、私たちは 2015 年 4 月に使用されたペイロードを分析しました。
この期間中に収集されたすべてのペイロードは、IE (59%) または Flash (41%) の脆弱性を介して配信されたことがわかります。
図 23 - 2015 年 Angler の配信時に悪用された脆弱性2019 年 4 月のペイロード
これは、最近発見された Angler ログイン ページ データとも一致していますが、Angler が Silverlight または Java の脆弱性を悪用したことは見つかりませんでした。ただし、Angler はインストールされていないコンポーネントを悪用しないため、結果は Angler 自体よりも被害者のコンピュータ構成をより多く示しています。
これらのドライブバイ ダウンロード キャンペーンでは、次のトロイの木馬ローダーがインストールされました。
図 24 - 2015 年 4 月に Angler によってインストールされたトロイの木馬ファミリー
明らかに、ランサムウェアが存在します - ラベルが付けられたものアスタリスクは、トロイの木馬攻撃の 50% 以上を占めるランサムウェア ファミリです。最も一般的に使用されているランサムウェアは Teslacrypt です。
この記事では、Angler EK を上から下まで分析し、Angler が Web ページに感染することでどのようにより多くのトラフィックを獲得するかを強調しました。
保護を提供する場合、この動作を理解することが重要です。アングラーは、あらゆるレベルで検出を回避しようとします。レピュテーション フィルターをバイパスするために、Angler はホスト名と IP をすばやく交換し、ドメイン名シャドウイングを使用して正規のドメイン名を偽装します。コンテンツ検出をバイパスするために、Angler は被害者に基づいてコンポーネントを動的に生成し、さまざまなエンコードおよび暗号化技術を使用します。最後に、Angler は難読化およびアンチサンドボックス技術を使用して、サンプルの収集と分析をより困難にします。
上で述べたように、アングラーはここ数カ月間、対戦相手を上回っています。考えられる理由は数多くあります。たとえば、Angler は Web ページに感染することでより多くのトラフィックを獲得でき、犯罪コミュニティ内での脆弱性悪用の成功率が高くなります。言い換えれば、Angler の使用から「設置「料金」の方が還元率が高いです。
1 つ明らかなことは、Angler は今日 Web を閲覧するすべての人に重大な影響を与えるだろうということです。
EK アクティビティの追跡に貢献していただいたセキュリティ コミュニティの皆様に感謝いたします。ただし、この記事を準備する際の @kafeine と @EKwatcher の努力に敬意を表したいと思います。
シェルコード コンポーネントへの貢献に対して、SophosLabs の Richard Cohen と Andrew O'Donnell にも感謝します。
DNS ドメイン シャドウイングの技術的知識を提供してくださった Nominet の Ben Taylor、Sion Lloyd、および Roy Arends に感謝します。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
