Wireshark によるパケット解析講座9：Dridex感染トラフィックの調査

4 min read

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

概要

本シリーズは、疑わしいネットワークアクティビティの調査やネットワークトラフィックのパケットキャプチャ（pcap）の確認を業務で行っておられるセキュリティ専門家を読者として想定しています。このため本稿での手順説明は読者の皆さんがWiresharkの使いかたをご存知であることを前提としています。また、本稿にて利用するWiresharkのバージョンは主に3.xとなります。

Dridexはバンキング型トロイの木馬とも呼ばれることもある、情報窃取型マルウェアファミリの一種です。このマルウェアは2014年に初めて出現し、それ以降、アクティブな状態が続いています。

今回のパケット解析講座では、Dridexのアクティビティを確認し、トラフィック分析から本ファミリを特定するのに役立つヒントを提供していきます。

注意: 本チュートリアルは、以前の『Wireshark によるパケット解析講座1: Wiresharkの表示列をカスタマイズする』で設定したカスタマイズ済みの列表示を使います。

また、本チュートリアルで使うpcapファイルの入ったZIPアーカイブを格納しているGithubリポジトリからサンプルファイルをあらかじめ取得しておいてください。解凍用パスワードは「infected」です。

注意: 本稿のチュートリアルに利用するpcapファイルはWindowsで動作するマルウェアを含んでいます。したがって、Windowsコンピュータを使っている場合感染リスクがあります。できるかぎり BSD系、Linux系、macOSなど、Windows環境以外の環境でpcapを確認することをお勧めします。

Dridexの配布

Dridexのネットワークトラフィックを理解するには、感染につながる一連のイベントを理解する必要があります。Dridexはたいてい悪意のあるスパム（マルスパム）を介して配布されており、このマルスパムの波は、少なくとも週に2〜3回は発生するのが普通です。Dridexを配布する電子メールにはMicrosoft Officeドキュメントが添付されていることもありますし、悪意のあるファイルをダウンロードするリンクが含まれていることもあります。図1〜4に最近のサンプルをいくつか示します。

Dridexをプッシュする悪意のあるExcelファイルが添付された「DHL Invoices for Aug 2020（2020年8月のDHL請求書）」という件名の電子メール — 図 1 2020年9月のDHLを偽装したマルスパム。添付ファイルを使ってDridexをプッシュする

添付された悪意のあるExcelファイルを使用してDridexをプッシュする電子メール。件名は「UPS Invoice Notification.(UPS請求書通知)」。 — 図 2 2020年10月のUPSを偽装したマルスパム。添付ファイルを使ってDridexをプッシュする

悪意のあるリンクを使用してDridexをプッシュする電子メール。件名は「FedEx Shipment 747958837531 Delivered(FedEx出荷番号747958837531の配送が完了しました)」。 — 図 3 2020年9月のDHLを偽装したマルスパム。リンクを使ってDridexをプッシュする

悪意のあるリンクを使用してDridexをプッシュする電子メール。件名は「Notification : invoice 796636.(通知: 請求書796636)」。 — 図 4 2020年10月のQuickBooksを偽装したマルスパム。リンクを使ってDridexをプッシュする

最初の悪意のあるファイルは、悪意のあるマクロを含むMicrosoft Officeドキュメントの場合もあれば、ある種のドキュメントを装ったWindows実行可能ファイル（EXE）の場合もあります。いずれにせよ、この最初のファイルをクリックすることで感染にいたります。ここでは初期ファイルがDridexインストーラを取得してきますが、初期ファイル自体がDridexインストーラであることもあります。Dridexインストーラは、暗号化されたコマンド&コントロール（C2）ネットワークトラフィックを介して、64ビットのDridexDLLファイルを取得します。図5と図6に最近のDridexアクティビティの感染チェーンでよく見られるサンプルを示します。

Dridexをプッシュするスプレッドシートが添付されたマルスパム。イベントのチェーンは次のとおりです：添付ファイル付きのマルスパム、添付されたExcelスプレッドシート、有効化マクロ、インストーラーDLLのHTTPSトラフィック、DridexのインストーラーDLL、HTTPS C2トラフィック、64ビットDridex DLLファイル、HTTPS C2トラフィック、更新された64ビットDridex DLLファイル — 図 5 Dridexがマルスパムの添付ファイルとして配布されるケースでよく見られる感染イベントフロー

Dridexをプッシュするリンクを持つマルスパム。イベントのチェーンは一般的に次のとおりです：HTTPSリンクを使用したマルスパム、WordドキュメントのHTTPSトラフィック、ダウンロードしたWordドキュメント、有効化マクロ、インストーラーDLLのHTTPSトラフィック、DridexのインストーラーDLL、HTTPS C2トラフィック、64ビットDridex DLLファイル、HTTPSC2トラフィック、更新された64ビットDridexDLLファイル — 図 6 Dridexがマルスパム内のリンクとして配布されるケースでよく見られる感染チェーンのイベントフロー

図7にやはりマルスパムを使った別種のDridexによる感染チェーンを示します。こちらは、図5と図6で使用されていたOfficeドキュメントほど一般的な配布方法ではありません。2020年9月24日のDridexをプッシュするマルスパムのリンクでは、Officeドキュメントを返す代わりにWindowsの実行可能ファイルを返していました。詳細は図7を参照してください。

Malspamが2020-09-24木曜日にDridexをプッシュします。注：同じHTTPSリンクが、ZIPアーカイブではなく.scrファイル拡張子を持つEXEを返す場合がありました。確認された一連のイベントは次のとおりです。HTTPSリンク付きのマルスパム、ZIPアーカイブのHTTPSトラフィック、ダウンロードされたZIPアーカイブ、DridexインストーラーEXE（.scrファイル拡張子）、HTTPS C2トラフィック、64ビットDridex DLLファイル、HTTPS C2トラフィック、更新64ビットのDridexDLLファイル — 図 7 2020年9月に確認された一連のイベント。リンクからDridexインストーラEXEにつながった

図5〜図7に示したように配布トラフィックはほとんどの場合HTTPSです。暗号化されているので、初期ファイルやDridexインストーラの検出が難しくなっていますが、DridexのC2のアクティビティがトリガーする感染後トラフィックは特徴的なので識別は可能です。

証明書とHTTPSトラフィック

Dridexの感染アクティビティを理解するには、HTTPSトラフィックに使用されるデジタル証明書も理解しなければなりません。

HTTPSトラフィックのSSL/TLS暗号化にはデジタル証明書が使用されます。HTTPSを使っているWebサイトを表示するさいは、WebサーバーからクライアントのWebブラウザに証明書が送信されます。このデジタル証明書のデータがHTTPS接続確立に利用されます。この証明書にWebサイトの公開鍵が含まれていて、これで対象Webサイトの身元を確認するわけです。

さまざまな認証局（CA）が、やはりさまざまなWebサイトのデジタル証明書を発行していて、商用サイト用に有料で企業相手に販売する認証局もあれば、Let’s Encryptのように証明書を無料で提供している認証局もあります。

証明書の情報はWiresharkのHTTPSトラフィックに表示させることができます。ここでは次の2つのセクションを主に確認します。

認証局の「Issuer(発行者)」データ
webサイトに関する「Subject」データ

「Issuer」のデータからはデジタル証明書を発行した認証局がわかります。また「Subject」のデータからはWebサイトの身元が確認できます。図8に弊社（www.paloaltonetworks.com）のHTTPSトラフィックをサンプルとして証明書の「Issuer」と「Subject」のデータを確認する方法を示します。

スクリーンショットは、例としてwww.paloaltonetworks.comを使用して、HTTPSトラフィックの証明書発行者とサブジェクトのデータを見つける方法を示しています。ここでは赤い矩形でWebサイトを識別するテーマとなっているデータをハイライト表示しています。 — 図 8 www.paloaltonetworks.comにHTTPSで接続したトラフィックの証明書データ

ただしWebサーバーをセットアップするさい、管理者は自己署名証明書を生成することもできます。自己署名証明書はローカルで生成されるもので、認証局が発行したものではありません。Firefoxなど最新のブラウザで表示すると、自己署名証明書を利用しているサーバーのHTTPSトラフィックではエラーメッセージが生成されることがよくあります（図9参照）。

自己署名証明書を使うHTTPSトラフィックはFirefoxの警告のように最新ブラウザで表示するとエラーメッセージを生成することがよくあります。この警告には、「Warning: Potential Security Risk Ahead.(警告：潜在的なセキュリティリスクがあります)」と記載されています。 — 図9 自己署名証明書を使用したWebサイトのページを表示しようとすると最新のFirefoxではエラーになる

マルウェア開発者はC2サーバーに自己署名証明書をよく利用します。なぜなら自己署名証明書はすばやく簡単に作成できるからです。くわえて、マルウェアのHTTPS C2トラフィックにはWebブラウザを使わないので、暗号化されたトラフィックはエラーや警告が表示されることもなく機能します。

自己署名証明書を生成するときは、以下のフィールドに値を入力します（ただし一部空白のままにされることもよくあります）。

Country name (国名、2文字のコード)
State or province name (州名や都道府県名)
Locality name (通常は市区町村名)
Organization name (組織名)
Organizational unit name (部門名)
Common name (たとえば完全修飾ホスト名)
Email address (電子メールアドレス)

これらのフィールドは、Webサイトを識別するSubjectデータに使用されます。ただし、この証明書はWebサーバー上でローカルに生成されているので、Issuer (発行者) にも同じフィールドと値が使用されます。

マルウェアの作成者は、自己署名証明書のこれらのフィールドにランダムな値や、デフォルト値、偽の値を使用することがよくあります。たとえば、TrickbotのHTTPSC2トラフィックは「example.com」をCommon Nameフィールドの値としてよく使用します。このほか最近のIcedIDマルウェア感染によるHTTPSC2トラフィックでは、証明書のIssuerフィールドに次の値を使用していました。

Country name: AU
State or province name: Some-State
Organization name: Internet Widgits Pty Ltd
Common name: localhost

DridexのHTTPS C2トラフィックの証明書Issuerデータのパターンは、他のマルウェアファミリと比べてやや特徴的です。このためこうしたパターンをDridex感染特定の鍵に使えることがあります。

Dridex感染アクティビティのPcapファイル

最近のDridexネットワークトラフィックのpcapを含む5つのパスワード付きZIPアーカイブ（パスワードは「infected」）をこちらのGitHubリポジトリから取得してください。Githubページに移動してZIPアーカイブのエントリをクリックし、図10と図11に示す手順でダウンロードします。

これは、このチュートリアルで使用するZIPアーカイブをGitHubリポジトリpan-unit42/wireshark-tutorial-Dridex-trafficからダウンロードする方法を示しています。 — 図 10 この講座で使用するZIPアーカイブへのリンクを含むGitHubリポジトリ

スクリーンショットは、このWiresharkチュートリアルのファイルを格納しているGitHubリポジトリからZIPアーカイブ2020-06-03-Dridex-infection-traffic-pcap.zipをダウンロードする例を示しています。 — 図11 本講座のZIPアーカイブを1つダウンロードしているところ

本ZIPアーカイブファイルを解凍するパスワードは「infected」です。展開すると次の5つのpcapファイルが作成されます。

2020-06-03-Dridex-infection-traffic.pcap
2020-09-24-Dridex-infection-traffic.pcap
2020-09-29-Dridex-infection-traffic.pcap
2020-10-05-Dridex-infection-traffic.pcap
2020-10-07-Dridex-infection-traffic.pcap

例1: 2020-06-03-Dridex-infection-traffic.pcap

2020-06-03-Dridex-infection-traffic.pcapを開いたら、『Wireshark によるパケット解析講座 2: 脅威インテリジェンス調査に役立つフィルタリング設定』のチュートリアルで解説した「basic」の web 用フィルタを適用します。Wireshark 3.xでのbasicフィルタは次のとおりです。

(http.request or tls.handshake.type eq 1) and !(ssdp)

Dridexの感染トラフィックは、次の二段構えになっています。

初期感染アクティビティ
感染後C2トラフィック

初期感染アクティビティは被害者が電子メールのリンクからの悪意のあるファイルをダウンロードした段階で発生します。初期感染アクティビティにはDridexのインストーラをロードする悪意のあるファイルが含まれます。なお、最初のダウンロードについては、確認できない場合もあります。たとえば悪意のあるファイルが電子メールの添付ファイルだった場合などです。このほか、初期ファイル自体がインストーラだったためにDridexインストーラのロードが確認されない場合もあります。たいていこのアクティビティはHTTPS経由で行われるので、URLは表示されずドメイン名のみが表示されます。

感染後のアクティビティは、被害者が感染した後に発生するHTTPSC2トラフィックです。このアクティビティはDridex感染が続いているかぎり発生します。このC2トラフィックはIPアドレスを使って直接通信するので関連付けられたドメイン名は存在しません。また以下に詳述するとおり、証明書のIssuerデータも普通の内容とは違っています。

図12はWiresharkで開いた最初のサンプルに「basic」Webフィルタを適用したものです。ドメイン名の表示されていない行がDridexのHTTPSC2トラフィックです。

このスクリーンショットは、WiresharkでフィルタリングされたDridex感染トラフィックを示しています。The screen is labeled 2020-06-03-Dridex-infection-traffic.pcap — 図 12 Wiresharkで最初のpcapのトラフィックを開いて「basic」Webフィルタでフィルタリングした内容

図12に示した最初のpcapには、ドメイン名ではなくIPアドレスで直接接続している次のトラフィックが示されています。これがおそらくDridexによるHTTPSC2トラフィックでしょう。

185.86.148[.]68 443/tcp
212.95.153[.]36 453/tcp

「basic」Webフィルタで表示される他のドメインは、microsoft.comやoffice.net、windows.comなどのよく知られた名前で終わるドメインを使用しているシステムのトラフィックです。唯一の例外がtruepenesonga[.]comへのHTTPSトラフィックで、これは19:38:18 UTCのpcapのはじめあたりで確認できます。これがおそらくDridexインストーラーでしょう。ちょっとGoogleで検索した結果からは、truepenesonga[.]comがマルウェアに関連付けられていることがわかります。

では感染後のDridexC2トラフィックに注目してみましょう。Wiresharkで次のフィルタで、これら2つのIPアドレス宛のHTTPSトラフィックの証明書のIssuerデータを確認してみます。

tls.handshake.type eq 11 and (ip.addr eq 185.86.148.68 or ip.addr eq 212.95.153.36)

フィルタを適用したら、Wiresharkの列表示で最初のフレームを選択して、フレームの詳細パネルに移動します。次に図13に示したとおりに値をクリックして展開していき、RDNSequence item:で始まる行のリストに移動します。

スクリーンショットは、Dridex HTTPSC2トラフィックの証明書発行者データを見つけるために使用できる重要なスポットを強調しています。赤い矢印は、トランスポート層のセキュリティ、証明書、ハンドシェイクプロトコル、署名された証明書、発行者、およびrdnSequenceを特に示しています。 — 図 13 DridexによるHTTPS経由のC2トラフィックで、証明書のIssuerデータを検索しているところ

ここでは185.86.148[.]68へのHTTPSトラフィックのRDNSequence itemとその値に注目してみましょう。

id-at-countryName=Vu
id-at-stateOrProvinceName=Uererarnk4
id-at-localityName=Port Vila
id-at-organizationName=Whensean Imegdtc SICAV
id-at-organizationUnitName=6Tbuthinalq
id-at-commonName=1andfhtittbly.fan

Dridexの証明書のIssuerフィールドには、1つか2つ数字を含ませたランダム文字列が設定されることがよくありますが、Country NameとLocalityの値は一致することが多いです。上記の例では、Vuというのがバヌアツを表す2文字の国コードで、Port Vilaというのはバヌアツの首都です。

212.95.153[.]36のHTTPSトラフィックを同様の手順で確認すると、次の情報が見つかります。

id-at-countryName=AO
id-at-localityName=Luanda
id-at-organizationName=Msorest KGaA
id-at-organizationUnitName=aghat@yongd
id-at-commonName=arashrinwearc.Ourontizes.ly

LuandaというLocalityはアンゴラの首都で、AOというのがアンゴラを表す国コードです。ただし他のフィールドはランダムな値のようです。この手の証明書Issuerデータが見つかれば、それはDridexのC2トラフィックであることを示す強力な指標といえます。

例2: 2020-09-24-Dridex-infection-traffic.pcap

2020-09-24-Dridex-infection-traffic.pcapをWiresharkで開いて、「basic」Webフィルタを適用します（図14参照）。

このスクリーンショットは、WiresharkでフィルタリングされたDridex感染トラフィックを示しています。画面には2020-09-24-Dridex-infection-traffic.pcapというラベルが付いています — 図 14 Wiresharkで2つめのpcapのトラフィックを開いて「basic」Webフィルタでフィルタリングした内容

最初の3行が暗号化されていないHTTPのGETリクエストである点に注目してください。これは図3で示した電子メールからのリンクです。このリンクからは、図7の感染チェーンのZIPアーカイブが返されました。

ここではTCPストリームではなくHTTPストリームの追跡をしてみましょう。図15と図16に示すとおり画面下にスクロールし、返されたスクリプトを確認します。

ここではTCPストリームではなくHTTPストリームの追跡をしてみましょう。スクリーンショットは、Wiresharkでそのオプションを見つける方法を示しています。 — 図 15 最初のHTTP GETリクエストのHTTPストリームを追跡

Dridex感染トラフィックのHTTPストリームを追跡する場合は、下にスクロールして、最初のHTTP GETリクエストで返されたスクリプトを表示します。 — 図 16 下にスクロールして、HTTP GETリクエストで返されたスクリプトを表示

adv.epostoday[.]ukへの3つのHTTP GETリクエストはすべて同じTCPストリーム内にあります。一番下あたりまでスクロールしていき、favicon.icoへの最後のHTTP GETリクエストの前までスクロールしてください。すると、ASCII文字の長い文字列の終わりが見つかります。この文字列がblobに変換され、Ref_Sep24-2020.zipとして被害者に送信されます（図17参照）。

赤い矢印は、被害者がブラウザから保存するように促されるZIPアーカイブであるRef_Sept24-2020.zipを示しています。 — 図 17 このスクリプトはブラウザからからのZIPアーカイブを被害者に表示し、保存させるようになっている

HTTPオブジェクトのエクスポート機能を使えばこれらのスクリプトをエクスポートすることができます（図18参照）。

「HTTPオブジェクトのエクスポート」機能を使用すると、app.phpで終わるURLから返されたスクリプトを保存できます。赤い矢印は、選択するオプションを示しています。 — 図18 app.phpで終わるURLから返されたスクリプトを保存

ここでも感染後のDridexC2トラフィックに着目しましょう。Wiresharkで次のフィルタを使い、HTTPSトラフィックのうち、ドメイン名をもたないこれら2つのIPアドレス宛のHTTPSトラフィックの証明書のIssuerデータを確認してみます。

tls.handshake.type eq 11 and (ip.addr eq 151.236.219.181 or ip.addr eq 62.98.109.30)

フィルタを適用後、最初のフレームを選択し、フレームの詳細セクションに移動します。1つ目のpcapで行ったようにRDNSequence itemで始まる行のリストを探します。図19に、2つ目のpcapで、151.236.219[.]181をRDNSequence itemまでドリルダウンした様子を示します。

証明書のIssuerのデータは1つ目のサンプルのデータと似ています。両方のIPアドレスの証明書のIssuerデータで以下のデータを確認しましょう。

151.236.219[.]181へのDridexによるHTTPS C2トラフィックの証明書Issuerデータは次のようになっていました。

id-at-countryName=IL
id-at-stateOrProvinceName=Anourd Thiolaved Thersile5 Fteda8
id-at-LocalityName=Tel Aviv
id-at-organizationName=Wemadd Hixchac GmBH
id-at-organizationUnitName=moasn@emanc
id-at-commonName=heardbellith.Icanwepeh.nagoya

62.98.109[.]30へのDridexによるHTTPS C2トラフィックの証明書Issuerデータは次のようになっていました。

id-at-countryName=SS
id-at-LocalityName=Khartoum
id-at-organizationName=Hedanpr S.p.a.
id-at-commonName=psprponounst.aquarelle

両方ともLocalityとCountry Nameは合致しているようですが、他のフィールドはランダムな値のようです。これは1つ目のpcapで見たDridexによるHTTPS C2トラフィックのパターンとも一致しています。

例3: 2020-09-29-Dridex-infection-traffic.pcap

2020-09-29-Dridex-infection-traffic.pcapをWiresharkで開いて、「basic」Webフィルタを適用します（図20参照）。

このスクリーンショットは、WiresharkでフィルタリングされたDridex感染トラフィックを示しています。画面には2020-09-29-Dridex-infection-traffic.pcapというラベルが付いています — 図 20 Wiresharkで3つ目のpcapのトラフィックを開いて「basic」Webフィルタでフィルタリングした内容

ドメインを確認すると、HTTPSトラフィックを使用しているMicrosoft以外のドメインが3つあり、これらは初期感染アクティビティに関連したものである可能性があります。

dsimportaciones[.]com
murfreesboro.fairwayconcierge[.]com
ryner.net[.]au

これらはそのURL特有のもので内容は表示されないので、Dridex C2の感染後トラフィックに注目してみます。Wiresharkで次のフィルタを使い、HTTPSトラフィックのうち、ドメイン名をもたないこれら2つのIPアドレス宛のHTTPSトラフィックの証明書のIssuerデータを確認してみます。

tls.handshake.type eq 11 and (ip.addr eq 67.79.105.174 or ip.addr eq 144.202.31.138)

フィルタを適用後、最初のフレームを選択してフレームの詳細セクションに移動し、1つ目と2つ目のpcapで行ったようにRDNSequence itemで始まる行のリストを探します。図21に、3つ目のpcapで、67.79.105[.]174をRDNSequence itemまでドリルダウンした様子を示します。

証明書のIssuerのデータは最初の2つのサンプルのデータと似ています。両方のIPアドレスのIssuerデータで以下のデータを確認しましょう。

67.79.105[.]174へのDridexによるHTTPS C2トラフィックの証明書Issuerデータは次のようになっていました。

id-at-countryName=MN
id-at-stateOrProvinceName=Listth Thearere8 berponedt tithsalet
id-at-LocalityName=Ulaanbaatar
id-at-organizationName=Massol SE
id-at-commonName=Atid7brere.Speso_misetr.stada

144.202.31[.]138へのDridexによるHTTPS C2トラフィックの証明書Issuerデータは次のようになっていました。

id-at-countryName=SS
id-at-LocalityName=Khartoum
id-at-organizationName=Hedanpr S.p.a.
id-at-commonName=psprponounst.aquarelle

2020-09-29の3つ目のサンプルの144.202.31[.]138の証明書Issuerデータは、2020-09-24の2つ目のサンプルの62.98.109[.]30のそれと同じである点に注意してください。

例4: 2020-10-05-Dridex-infection-traffic.pcap

2020-10-05-Dridex-infection-traffic.pcapをWiresharkで開いて、「basic」Webフィルタを適用します（図22参照）。

このスクリーンショットは、WiresharkでフィルタリングされたDridex感染トラフィックを示しています。The screen is labeled 2020-10-05-Dridex-infection-traffic.pcap — 図 22 Wiresharkで4つ目のpcapのトラフィックを開いて「basic」Webフィルタでフィルタリングした内容

ドメインを確認すると、HTTPSトラフィックを使用しているMicrosoft以外のドメインが1つあり、これは初期感染アクティビティに関連したものである可能性があります。

vardhmanproducts[.]com

tls.handshake.type eq 11 and (ip.addr eq 85.114.134.25 or ip.addr eq 85.211.162.44)

フィルタを適用後、最初のフレームを選択してフレームの詳細セクションに移動し、これまでの3つのpcapで行ったようにRDNSequence itemで始まる行のリストを探します。

証明書のIssuerのデータは最初の3つのサンプルのデータと似ています。両方のIPアドレスのIssuerデータで以下のデータを確認しましょう。

85.114.134[.]25へのDridexによるHTTPS C2トラフィックの証明書Issuerデータは次のようになっていました。

id-at-countryName=NZ
id-at-stateOrProvinceName=Cepli thade0 ithentha temsorer
id-at-LocalityName=Wellington
id-at-organizationName=Lling Lovisq NL
id-at-organizationalUnitName=Punddtln
id-at-commonName=Onshthonese.vyrda-npeces.post

85.211.162[.]44へのDridexによるHTTPS C2トラフィックの証明書Issuerデータは次のようになっていました。

id-at-countryName=MY
id-at-LocalityName=Kuala Lumpur
id-at-organizationName=Ointavi Tagate Unltd.
id-at-commonName=Ateei7thapom.statonrc.loan

例5: 2020-10-07-Dridex-infection-traffic.pcap

2020-10-07-Dridex-infection-traffic.pcapをWiresharkで開いて、「basic」Webフィルタを適用します（図23参照）。

このスクリーンショットは、WiresharkでフィルタリングされたDridex感染トラフィックを示しています。The screen is labeled 2020-10-07-Dridex-infection-traffic.pcap — 図 23 Wiresharkで5つ目のpcapのトラフィックを開いて「basic」Webフィルタでフィルタリングした内容

newmg532.wordswideweb[.]com

感染後のDridexC2トラフィックを確認してみましょう。Wiresharkで次のフィルタを使い、HTTPSトラフィックのうち、ドメイン名をもたないこれら2つのIPアドレス宛のHTTPSトラフィックの証明書のIssuerデータを確認してみます。

tls.handshake.type eq 11 and (ip.addr eq 177.87.70.3 or ip.addr eq 188.250.8.142)

フィルタを適用後、最初のフレームを選択してフレームの詳細セクションに移動し、これまでの4つのpcapで行ったようにRDNSequence itemで始まる行のリストを探します。

証明書のIssuerのデータは最初の4つのサンプルのデータと似ています。両方のIPアドレスのIssuerデータで以下のデータを確認しましょう。

177.87.70[.]3へのDridexによるHTTPS C2トラフィックの証明書Issuerデータは次のようになっていました。

id-at-countryName=BS
id-at-stateOrProvinceName=Sshopedts Inccofrew
id-at-LocalityName=Nassau
id-at-organizationName=Mesureder S.p.a.
id-at-commonName=avothelyop.thedai9neasysb.author

188.250.8[.]142へのDridexによるHTTPS C2トラフィックの証明書Issuerデータは次のようになっていました。

id-at-countryName=UA
id-at-stateOrProvinceName=avandi0
id-at-LocalityName=Kiev
id-at-organizationName=Icccodiso Icloneedb Oyj
id-at-organizationalUnitName=4Zenyfea
id-at-commonName=rebydustat.tci

これら5つのサンプルから、DridexのHTTPS C2トラフィックの証明書Issuerデータがどのように見えるかについてだいたい予想がつくようになったと思います。これらのパターンは他の多くのマルウェアファミリとは異なるものの、HTTPS C2からの証明書Issuerデータは多少Qakbotネットワークトラフィックのそれに似ています。

ただしQakbotの場合stateOrProvinceNameは常に2文字の値でLocalityNameはランダムな文字で構成されます。

Dridexの場合はstateOrProvinceNameはランダムな文字で、LocalityNameにはCountryNameに使用されたいずれかの国の首都が利用されます。

結論

今回はDridexのネットワークトラフィックを含むpcapを使って、Dridexのアクティビティを識別する方法を確認しました。Dridex感染の最近の5つのpcapを確認し、感染後のC2トラフィックを見ることで、証明書のIssuerデータに特定のパターンがあることを確認できました。これらのパターンはおそらくDridexに特有のものなので、証明書のIssuerデータの確認はDridex感染の識別の鍵となります。

『Wiresharkによるパケット解析講座』シリーズの以前の講座は以下から確認してください。