Wiresharkによるパケット解析講座 6: Ursnif感染の調査

5 min read

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

概要

Ursnifは、GoziまたはIFSBと呼ばれることもあるバンキングマルウェア(金融マルウェア)です。Ursnifファミリのマルウェアには長年にわたり活動が見られ、現時点のサンプルには明確なトラフィックパターンがあります。

そこで本チュートリアルではWiresharkを使用し、Ursnif感染トラフィックのパケットキャプチャ（pcap）を確認していきます。セキュリティ専門家がUrsnifによる感染を検出・調査するさいはこうしたトラフィックパターンを理解しておくことが重要になります。

本チュートリアルで説明する内容は次のとおりです。

Ursnifの配布方法
Ursnifによるトラフィックの分類
Ursnifによる感染で発生した5種類のサンプルpcap

注意: 本チュートリアルは、Wiresharkに関する基本的知識があることを前提としています。また、以前のチュートリアルで設定したカスタマイズ済みの列表示を使います。またこの回で解説したWiresharkディスプレイフィルタもすでに実装されているものとしています。

なおサンプルzipファイルのパスワードはすべて「infected」です。

Ursnifの配布方法

Ursnifは、webベースの感染チェーンと悪意のあるスパム（マルスパム）を介して配信されます。また場合によっては、最近公開されたこちらのサンプルで報告されているHancitorのような、さまざまなマルウェアファミリによって引き起こされる感染のフォローアップとしてUrsnifによる感染が発生することもあります。

図1の例のように、マルスパムベースの配布キャンペーンからは、Ursnifのサンプルが頻繁に見つかります。

図1 最も一般的なUrsnif配布キャンペーンの1つを示したフローチャート。
マルスパムに添付されたパスワードつきZIPアーカイブから Word Doc ファイルを展開。マクロが有効化されるとUrsnifのHTTPにアクセスし第一段階のUrsnifバイナリをダウンロード。HTTPないしHTTPSによるUrsnifの感染後トラフィックが発生し、フォローアップマルウェアがダウンロードされてくる

Ursnifによるトラフィックの分類

本チュートリアルでは、Ursnif感染トラフィックの2つのカテゴリについて説明します。

HTTPS経由の感染後トラフィックがないUrsnif
HTTPS経由の感染後トラフィックがあるUrsnif

いずれのマルウェアサンプルも、感染Windowsホスト上に同じ種類のアーティファクト(痕跡)を残します。たとえば、図2に示すように、どちらの種類のUrsnifであっても、Windowsレジストリを更新してWindowsホストで永続化します。

図2 HTTPS経由の感染後トラフィックの有無にかかわらずUrsnifサンプルによりWindowsレジストリが更新される

例1：HTTPSを使用しないUrsnif

本チュートリアル最初のpcapファイル Ursnif-traffic-example-1.pcapをここからダウンロードし、パスワードつきzipファイルを展開して開いてください (パスワードは「infected」で以下のサンプルも同じパスワード)。このトラフィックの生じた背景となる一連のイベントに関するツイートはこちらから確認してください。なお、例1では、Ursnifによる感染と直接関連のないトラフィックはすべて取り除いてあります。

Wiresharkでpcapを開き、図3に示したとおり「http.request」を指定してフィルタリングしてください。

図3 Wiresharkでフィルタリングされた例1のpcap

この例では、Ursnifに感染したホストは、8.208.24[.]139への感染後トラフィックを発生させていますが、そのさい.atで終わるさまざまなドメイン名を使用しています。このカテゴリのUrsnifは、次のトラフィックを生成します。

初期UrsnifバイナリによるHTTP GETリクエスト
URLが.datで終わる、フォローアップデータ用のHTTP GETリクエスト
UrsnifがWindowsレジストリで永続化された後に発生するHTTP GETおよびHTTP POSTリクエスト

例1のサンプルの場合、次のHTTPデータがトラフィックに使用されています。

最初のGETリクエストのドメイン：w8.wensa[.]at
フォローアップデータのリクエスト： hxxp://api2.casys[.]at/jvassets/xI/t64.dat
Ursnifが永続化された後のGETリクエストとPOSTリクエストのドメイン：h1.wensa[.]at

20:13:09 UTCに発生した最初のHTTP GETリクエストのフレーム(フレームNo.9)を選択して右クリックし、[追跡]、[TCPストリーム] の順にクリックしてください。TCPストリームが追跡されます。

このTCPストリームウィンドウに完全なURLが表示されます。GETリクエストが/api1/で始まっていること、その後ろにバックスラッシュやアンダースコアを含む英数字の長い文字列が続いていることに注意してください。図4はこのGETリクエストをハイライトしたものです。

図4 最初のUrsnifサンプルにより発生したHTTP GETリクエストの例。GETリクエストは/api1/で始まり、その後にバックスラッシュとアンダースコアを含む長いアルファベットと数字の文字列が続く

2019年12月10日にHancitorへの感染で生成されたUrsnifの活動内容からも、これと同じパターンが確認できます。そのさいのpcapはこちらにあります。他のマルウェアによる活動に混じって、この12月10日のサンプルには次のようなUrsnifの痕跡が残っています。

最初のGETリクエストのドメイン：foo.fulldin[.]at
フォローアップデータのリクエスト： hxxp://one.ahah100[.]at/jvassets/o1/s64.dat
Ursnifが永続化された後のGETリクエストとPOSTリクエストのドメイン： api.ahah100[.]at

例1で見たトラフィックパターンと、12月10日のサンプルで見たUrsnifトラフィックパターンとの類似性に注意してください。これらのパターンは、HTTPSトラフィックを使用しないUrsnifサンプルでよく見られます。

例2：HTTPSを使用するUrsnif

本チュートリアル2つ目のpcapファイルUrsnif-traffic-example-2.pcapはここからダウンロードして開いてください。例1同様、Ursnifによる感染と直接関連のないトラフィックはすべて取り除いてあります。

Wireshark 2.xをお使いの場合はpcapを開いたら図5に示したとおり「 http.request or ssl.handshake.type == 1 」を指定してフィルタリングしてください。Wireshark 3.0またはそれ以降をお使いの場合は「 http.request or tls.handshake.type == 1 」を指定してフィルタリングすれば正しい結果が得られます。

図5 Wiresharkでフィルタリングされた例2のpcap

本サンプルには、次の一連のイベントが含まれています。

初期Ursnifバイナリを返すHTTP GETリクエスト
初期UrsnifバイナリによるHTTP GETリクエスト
UrsnifがWindowsレジストリで永続化された後に発生するHTTPSトラフィック

では、ghinatronx[.]comへの最初のHTTP GETリクエストのTCPストリームを例1と同じ手順で追跡してください。このTCPストリームにはWindows用実行可能ファイルないしDLLファイルが含まれていることがわかります(図6参照)。以前のチュートリアルでも説明したように、pcapからは、Ursnifのバイナリファイルをエクスポートすることができます。

図6 Ursnifバイナリを返す最初のHTTP GETリクエスト。最初の2バイトが文字列「MZ」だがこれはWindows の実行ファイルないしDLLファイルであることを示す。また「This program cannot be run in DOS mode.」という文字列が確認できるが、これはほとんどのWindows実行ファイルとDLLファイルに含まれる文字列

続く4つの bjanicki[.]com に対するHTTPリクエストは、このUrsnifバイナリが生成したものです。18:46:21 UTCから始まる、 bjanicki[.]com への最初のHTTP GET リクエストのTCPストリームを追跡してください。このTCPストリームから、完全なURLを確認できます。GETリクエストが /images/ で始まっていること、その後ろにバックスラッシュやアンダースコアを含む英数字の長い文字列が続き、最後が .aviで終わることに注意してください。このURLパターンは例1のpcapに含まれていたUrsnifトラフィックにどこか似ています。図7は、2番目のpcapからのGETリクエストをハイライトしたものです。

図7 2番目のUrsnifサンプルにより発生したHTTP GETリクエストの例。GETリクエストは/images/で始まり、後ろにバックスラッシュやアンダースコアを含むアルファベットと数字の長い文字列が続く。最後は.aviで終わる

ところが最初のサンプルとは異なり、この2番目のpcapのUrsnifは、感染Windowsホスト上での永続化後、HTTPSトラフィックを生成します。前回までの講座で説明した「basic」webフィルタを適用し、ざっとHTTPSトラフィックを確認してみましょう。prodrigo29lbkf20[.]comへのHTTPSトラフィックを図8に示します。

図8 Wiresharkでwebトラフィックをフィルタリングし、Ursnifが生成したHTTPSトラフィックをハイライト表示したところ

このUrsnif亜種が生成したHTTPSトラフィックが暗号化通信の確立に使用する証明書には際立った特徴があります。見やすくするため、「 ssl.handshake.type == 11 」(Wireshark 3.0またはそれ以降の場合は「 tls.handshake.type == 11 」)をフィルタリングで指定してください。結果画面で最初のフレームを選択し、フレーム下部にある詳細ウィンドウを確認します。フレームの詳細ウィンドウで対象行を展開していき、証明書の発行者データを表示させましょう。図9にその手順を示します。

図9 対象の行を順次展開して証明書の発行者データをたどる。
Wireshark2.x系の場合はSecure Sockets Layer の行を展開し、3.x 系の場合は Transport Layer Security の行を展開する

図9で示したように、フレームの詳細ウィンドウでSecure Sockets Layer (Wireshark 3.0の場合はTransport Layer Security)を展開します。つづいてTLSv1.2 Record Layer: Handshake Protocol: Certificateという行を展開し、Handshake Protocol: Certificateの行を展開します。

こうして順に展開していき、図10に示した証明書の発行者データが表示されるまで続けます。

図10 Ursnifが生成したHTTPSトラフィックの証明書発行者データ

図10に示したHandshake Protocol: Certificateの行以降は次の順で展開します。

Certificates (615 bytes)
Certificate: 30820260308201c9a003020102020900c692c94106d77dfc…
signedCertificate
Issuer: rdnSequence (6)
rdnSequence: 6 items (id-at-commonName=*,id-at-organizationalUnitN…

rdnSequence以下の個々の項目の行が、証明書発行者に関するプロパティです。これらのプロパティから、以下の特徴があることがわかります。

countryName=XX
stateOrProvinceName=1
localityName=1
organizationName=1
organizationalUnitName=1
commonName=*

この発行者データは有効ではありません。Ursnif感染トラフィックに無効な証明書データが使われることはよくあるので、ここで有効な証明書データの見えかたも押さえておきましょう。

図11は、DigiCertが発行した証明書の有効なデータを示しています。

図11 有効な証明書発行者データ

Ursnifに関して最後に取り上げる項目は、Ursnif感染ホストによるIPアドレスのチェックについてです。このチェックはopendns[.]comをリゾルバとして使用するDNSトラフィックによって行われます。一般のIPアドレス確認サービス同様、こちらのリゾルバもそれ自体は正当なサービスですが、マルウェアからもよく使用されています。

IPアドレスがチェックされている様子を確認するには、「dns.qry.name contains opendns.com」でフィルタリングし、その結果をレビューします(図12参照)。

図12 Ursnifに感染したWindowsホストによるIPアドレスのチェック。感染WindowsホストのIPアドレスが表示される

図12からもわかるとおり、感染Windowホストは、「resolver1.opendns[.]com」へのDNSクエリを生成しています。その後には208.67.222[.]222に対し、myip.opendns[.]comを解決するためのDNSクエリが続きます。myip.opendns[.]comへのDNSクエリは、感染したWindowsホストのパブリックなIPアドレスを返しています。

例3：フォローアップマルウェアを伴うUrsnif

3番目のpcapはUrsnif-traffic-example-3.pcapです。ファイルはここからダウンロードしてください。Ursnifによる感染と直接関連のないトラフィックはすべて取り除いてありますが、トラフィックは1つ前のサンプルから組み立てたものです。3番目のpcapには、おとり(decoy、デコイ)のトラフィックと思われるものも含まれています。またここにはフォローアップマルウェアのHTTP GETリクエストも含まれています。イベントのシーケンスは次のとおりです。

初期Ursnifバイナリを返すHTTP GETリクエスト
初期UrsnifバイナリによるHTTP GETリクエスト (おとりのURLを含む)
UrsnifがWindowsレジストリで永続化された後に発生するHTTPSトラフィック
フォローアップマルウェア用のHTTP GETリクエスト

前回までの講座で説明した「 basic 」webフィルタを適用し、ざっとHTTPSトラフィックを確認してみましょう(図13参照)。

図13 Wiresharkでフィルタリングされた例3のpcapのwebトラフィック

図13では、 sinicaleer[.]com への最初のHTTPリクエストがUrsnifのWindows実行可能ファイルを返しています。図13に表示されている残りのトラフィックはUrsnifの実行可能ファイルによるもので、永続化が完了するまで続いていました。

google[.]com に対する3つのHTTPリクエストは、Ursnifトラフィックが実際の悪意のあるドメイン ghdy656262oe[.]comへリクエストするURLパターンを踏襲しています。これらgoogle[.]comへのHTTP GETリクエストはおとりのトラフィックのようで、これらのトラフィックは感染に寄与していません。また、TCPポート443経由のgmail[.]com、www.google[.]comへのHTTPSトラフィックも感染に直接寄与している様子はなく、この活動もおとりトラフィックに分類されるべきものかもしれません。図14は、google[.]comに対するおとりHTTP GETリクエストの例を示しています。

図14 Ursnif感染ホストからGoogleドメインへのおとりHTTP GETリクエスト。
google.comへのデコイURLは、先頭が/images/の GETにリクエストで、バックスラッシュやアンダースコアを含む長いアルファベットと数字の文字列が続く。最後は .avi で終わる。

ghdy656262oe[.]comへのHTTPトラフィックに注意してください。 ghdy656262oe[.]com に対する最初の2つのGETリクエストは「404 Not Found 」応答を返します(図15参照)。3番目のHTTP GETリクエストは「200 OK」を返し、感染プロセスは続きます(図16参照)。

図15 悪意のあるUrsnifドメインへの最初の2つのHTTP GETリクエスト。「404 Not Found」応答が返される

図16 Ursnif感染が進む前に何度か失敗している

ghdy656262oe[.]com への最初のHTTPリクエストで「200 OK」が返ってこないので、感染Windowsホストはほかの悪意のあるドメインを順に指定して感染を進めようとします。そのさいに使われていた2つのドメインはtnzf3380au[.]topとxijamaalj[.]comでした。ただし、これら2つのドメインに対するDNSクエリへの応答は「Non-existent domain」という結果になるので、感染Windowsホストは再び ghdy656262oe[.]comに戻ってきています。

次のWiresharkフィルタを使って、この一連のイベントをよく観察してみましょう。

((http.request or http.response) and ip.addr eq 194.1.236.191) or dns.qry.name contains tnzf3380au or dns.qry.name contains xijamaalj

結果は図17に表示されている列のようになります。

図17 HTTPトラフィックで「200 OK」が返される前に感染WindowsホストがUrsnif関連ドメインを試している様子をフィルタリングして表示したところ

感染の残りの部分を確認するには「basic」webフィルタを適用し、結果の画面を一番下までスクロールします。図18は、Ursnifが永続化した後の感染後トラフィックを示しています。

図18 Ursnifが被害Windowsホスト上で永続化した後に発生する感染後トラフィック

図18からは、ghdy656262oe[.]comへの5つのHTTP GETリクエストの後、Ursnifが永続化され、さらに感染Windowsホストによるトラフィックが生成されることがわかります。このトラフィックにもgoogle[.]com、gmail[.]comへのHTTPSトラフィックが含まれています。

vnt69tnjacynthe[.]com へのトラフィックには、2番目のpcapで見たものと同じ種類の証明書発行者データが含まれているはずです。ただしこのトラフィックにはcarresqautomotive[.]comへのHTTP GET リクエストが含まれており、そのリクエストの末尾は .rarで終わっています。

.rarで終わるこのURLは、フォローアップマルウェアを返すものでした。ただし、このフォローアップマルウェアがネットワーク経由で送信される場合、エンコードされるか暗号化されています。感染Windowsホスト上ではバイナリがデコードされますが、このバイナリは感染トラフィック内では見られません。carresqautomotive[.]comへのHTTP GETリクエストのTCPストリームを追跡してください。図19に示したものと同じデータが表示されるはずです。

図19 Ursnif感染Windowsホストに送信されるフォローアップマルウェア。Content-Type には application/x-rar-compressed と表示される。ただしバイナリはエンコードないし暗号化されているデータで実際にはrarアーカイブではない

このデータは暗号化されているので、pcapからフォローアップマルウェアのコピーをエクスポートすることはできません。したがって、Ursnif感染ホストに送信されたマルウェアの種類は、他の感染後トラフィックから判断する必要があります。

私たちはこれまでにもUrsnif感染からくる多様なフォローアップマルウェアを確認してきました。たとえば Dridex、 IcedID、 Nymain、 Pushdo、 Trickbotなどです。

次に見ていくのは、Ursnif感染後のフォローアップマルウェアとしてDridexが使われたサンプルです。

例4：Dridexを使用するUrsnif

4番目のpcapはUrsnif-traffic-example-4.pcapです。このファイルはここからダウンロードしてください。最初の3つの例とは異なり、このpcapの場合、トラフィックから無関係な活動は取り除いてありません。

「 basic 」webフィルタを適用してHTTPSトラフィックを眺めてみれば内容が大まかにつかめるでしょう。結果は図20のようになります。

図20 Wiresharkでフィルタリングされた例4のpcap

このpcapで発生するイベントのシーケンスは例3のものと同じです。ただし、このpcapにはフォローアップマルウェアによる感染後活動が追加されています。

初期Ursnifバイナリを返すHTTP GETリクエスト
初期UrsnifバイナリによるHTTP GETリクエスト (おとりのURLを含む)
UrsnifがWindowsレジストリで永続化された後に発生するHTTPSトラフィック
フォローアップマルウェア用のHTTP GETリクエスト
フォローアップマルウェアによる感染後活動

この4番目の例では、初期UrsnifバイナリのためのHTTP GETリクエストはoklogallem[.]comに対して行われます。Ursnifは感染を永続化する前にkh2714ldb[.]comへのHTTP GETリクエストを送信します。

図21は、Ursnifが永続化した後の活動を示しています。この活動においてUrsnifは、s9971kbjjessie[.]comに対するHTTPトラフィックを生成しています。その後、 startuptshirt[.]my に対するHTTP GET リクエストがフォローアップマルウェア用に送信されています。最後に、フォローアップマルウェアによる感染後トラフィックが発生する様子が確認できます。

図21 Ursnifが永続化した後の感染活動。Ursnif感染後、永続化が行われた後はHTTPSトラフィックとフォローアップマルウェアを求めるHTTPリクエストが生成される。最後にフォローアップマルウェアがHTTPSトラフィックを生成している

例4のpcapの感染パターンは例3のそれにならったものですが、関連付けられたドメイン名のない94.140.114[.]6、5.61.34[.]51へのHTTPS/SSL/TLSトラフィックも見られます。これがDridexによる感染後トラフィックです。

Dridexの証明書発行者データは、Ursnifの証明書発行者データとは異なります。次のフィルタで例4のpcapに含まれるDridexの証明書データを確認してください。

Wireshark 2.x の場合:
(ip.addr eq 94.140.114.6 or ip.addr eq 5.61.34.51) and ssl.handshake.type eq 11
Wireshark 3.x の場合:
(ip.addr eq 94.140.114.6 or ip.addr eq 5.61.34.51) and tls.handshake.type eq 11

結果画面で最初のフレームを選択してフレームの詳細ウィンドウに移動し、例2の図9と図10で見てきたように証明書関連の行を展開してください。例4のpcapからの証明書の発行者データを調べると、図22、図23のようになります。

図22 Dridexのトラフィックで対象の行を順次展開して証明書の発行者データをたどる

図23 DridexのIPアドレスの1つからの証明書発行者データに到達したところ

rdnSequence という行の下に証明書発行者に関するプロパティが表示されています。 94.140.114[.]6 のHTTPS/SSL/TLSトラフィックの証明書発行者には次のような特徴がありました。

countryName=NP
localityName=Kathmandu
organizationName=Buvecoww Fftaites O.V.E.E.
organizationalUnitName=Olfo Dusar Latha
commonName=ndltman-dsamutb.spiegel

証明書発行者のデータは 5.61.34[.]51用のそれとは異なりますが似たような形式を踏襲しています。

countryName=MU
localityName=Port Louis
organizationName=Ppoffi Sourinop Cooperative
organizationalUnitName=ipeepstha and thicioi
commonName=plledsaprell.Byargt9wailen.voting

この種の発行者データは、Dridexの感染後トラフィックではよく見られます。
では次の最後の例でもっとDridex証明書の発行者データを確認してみましょう。

例5：ハンズオン

本チュートリアル最後のpcapはUrsnif-traffic-example-5.pcapです。ファイルはここからダウンロードして開いてください。これまでの例と同様、このpcapにはUrsnif感染につづくDridex感染が含まれています。ここまでで学んだスキルを活かしましょう。

これまでに学んだことをふまえ、Wiresharkで例5のpcapを開いて、次の質問に答える情報を探してください。

初期UrsnifバイナリではどのURLがWindows実行可能ファイルを返しているか
初期Ursnifバイナリ送信後、感染WindowsホストはHTTP GETリクエスト用に別ドメインにアクセスしていたが、通信の成功により感染の継続を可能にしたドメインは何というドメインだったか
Ursnifが感染Windowsホスト上で永続化した後のHTTPSトラフィックにはどのドメインが使用されていたか
感染Windowsホストにフォローアップマルウェアを送信するために使用された .rar で終わるURLは何か
Dridexの感染後トラフィックに使用されたIPアドレスは何か

答えは次の通りです。

質問1: 初期UrsnifバイナリではどのURLがWindows実行可能ファイルを返しているか

答え: hxxp://ritalislum[.]com/obedle/zarref.php?l=sopopf8.cab

このpcapに含まれるWindows実行可能ファイルは、Ursnif用の初期Windows実行可能ファイルだけです。Wiresharkに次の検索フィルタを設定してこの実行可能ファイルをすばやく見つけてください。

ip contains "This program"

このフィルタによって表示されるフレームは1つだけのはずです。図24に示すように、このフレームのTCPストリームを追跡します。

図24 Windows実行可能ファイルの含まれるフレームを見つけるためのフィルタリング設定。この結果表示されたフレームのTCPストリームを追跡する

TCPストリームのウィンドウには、図25に示すように、GETリクエストのドメインとURLが含まれています。

図25 TCPストリームのURL情報。このHTTPリクエストのURL情報とこのURLが返すのがWindows実行ファイルであるという痕跡が確認できる

質問2: 初期Ursnifバイナリ送信後、感染WindowsホストはHTTP GETリクエスト用に別ドメインにアクセスしていたが、通信の成功により感染の継続を可能にしたドメインは何というドメインだったか

答え: k55gaisi[.]com

「 basic 」webフィルタを適用すればwebトラフィック内容が大まかにつかめるでしょう。Ursnifのこの亜種によって引き起こされるHTTPリクエストが「GET /images/」から始まるのは、このチュートリアルの例2〜4で見てきたとおりです。k55gaisi[.]comへの最初のHTTPリクエストが15:36 UTCに発生しています(図26参照)。ただし、TCPストリームを追跡すると、応答として「404 Not Found」が返されていることがわかります。

図26 Ursnifが生成したHTTP GETリクエストのwebトラフィックを検索。k55gaisi[.]comへのリクエストでは「404 Not Found」が返りbon11ljgarry[.]comへのリクエストはwww.search-error[.]comにリダイレクトされる

また、これも図26に示されていますが、Ursnifの形式を踏襲したURLに対する次のHTTP GETリクエストは、bon11ljgarry[.]comに対するもので、15:37 UTCに記録されています。これに対応するリクエストのHTTPストリームからは、www.search-error[.]comというURLへリダイレクトされることがわかります。

さらに下にスクロールすると、同様のトラフィックはleinwqoa[.]comに対しても発生しています(図27参照)。

図27 「検索エラーページ(www.search-error[.]com)」にリダイレクトされるUrsnif形式のURLがほかにも見つかる

さらに下にスクロールすると200 OK応答を返しているk55gaisi[.]comへのHTTP GETリクエストが4つ見つかります。この時点からUrsnifの感染が進行し、GET /images/で始まるUrsnif形式のHTTPリクエストはそれ以上は見つからなくなります。

図28 「200 OK」を返すUrsnif形式のHTTP GETリクエストが見つかる

質問3: Ursnifが感染Windowsホスト上で永続化した後のHTTPSトラフィックにはどのドメインが使用されていたか

答え: n9maryjanef[.]com

いったん永続化すれば、Ursnif形式の GET /images/で始まるHTTPリクエストは生成されなくなります。その代わり、Ursnif関連のHTTPSトラフィックが生成されるようになります。最後のUrsnif形式HTTP GETリクエストの直後、図29でハイライト表示したように、185.118.165[.]109上でn9maryjanef [.]comへのHTTPSトラフィックが始まります。これはUrsnifによるトラフィックです。

図29 UrsnifによるHTTPSトラフィック

ip.addr eq 185.118.165.109 and ssl.handshake.type == 11 (Wireshark 3.x系はip.addr eq 185.118.165.109 and tls.handshake.type == 11)をフィルタリングに設定し、証明書発行者のデータを確認すると、これがUrsnifトラフィックであることが確認できます。この証明書発行者データには、図10の例2と同じ内容のものが表示されるはずです。

質問4: 感染Windowsホストにフォローアップマルウェアを送信するために使用された .rar で終わるURLは何か

答え: hxxps://testedsolutionbe[.]com/wp-content/plugins/apikey/uaasdqweeeeqsd.rar

フォローアップマルウェア用にUrsnifが生成するHTTP GETリクエストは.rarで終わるので、次のフィルタを使用すればpcap上のこのURLを見つけられます。

http.request and ip contains .rar

この結果は図30に示した内容になるでしょう。

図30 Ursnif感染でフォローアップマルウェア用のURLを見つける

この図30ではHTTP GETリクエストがHTTPS URLにリダイレクトされている様子をよく確認してください。

質問6: Dridexの感染後トラフィックに使用されたIPアドレスは何か

答え: 185.99.133[.]38 と 5.61.34[.]51

これらIPアドレスの1つは例4のpcapのDridexと同じで、同一の証明書発行者データが含まれています。Dridexの 185.99.133[.]38 へのトラフィックには、例4でみたものと同じ形式の証明書発行者データが含まれています。両IPアドレスへのトラフィックにドメイン名は含まれていません。

この例では、.rarで終わるドメインを含まないHTTP GETリクエストに続いて発生するHTTPS/SSL/TLSトラフィックを検索すると、Dridexによる感染後トラフィックを簡単に見つけることができます(図31参照)。

図31 例5のpcap内のDridexトラフィックを検索。URL末尾が.rarで終わるリクエストの後、Dridexによるトラフィックが発生する。その後ろには、UrsnifによるHTTPSトラフィックが生成されている