概要
ホストが感染した、または侵害されたとき、セキュリティ専門家は、ネットワークトラフィックのパケットキャプチャ（pcaps）にアクセスして、活動の内容を理解し、それがどのような種類の感染であるかを特定しなければなりません。
本チュートリアルでは、Trickbotを特定する方法についてのヒントを提供します。Trickbotは情報窃取を行うバンキングマルウェアで、2016年以降、感染被害が確認されています。Trickbotは悪意のあるスパム（マルスパム）を介して、またはEmotet、IcedID、Ursnifなどのマルウェアによって配信されます。
Trickbotには明確なトラフィックパターンがあります。本チュートリアルでは、2つの異なる経路で起こったTrickbot感染pcapsを確認していきます。1つめはマルスパム経由でのTrickbot感染、2つめはほかのマルウェア経由で配信されたTrickbot感染です。
注意: 本チュートリアルの解説は、この回で行ったカスタマイズ済みWireshark列表示を前提としています。またこの回で解説したWiresharkディスプレイフィルタもすでに実装されているものとしています。まだ完了していない場合はこれらの内容を完了してから読み進めてください。
マルスパム経由のTrickbot
Trickbotは多くの場合マルスパム経由で配信されます。マルスパムには、請求書や文書を偽装したリンクが含まれていて、そのリンクから悪意のあるファイルをダウンロードさせようとします。ダウンロードされるファイルは、TrickbotのWindows実行可能ファイルの場合もあれば、Trickbot実行可能ファイルのためのダウンローダーである場合もあります。あるいは、電子メール内のリンクを使い、Trickbotの実行可能ファイルや、ダウンローダーを含むzipアーカイブを返してくる場合もあります。
下図は、2019年9月に発生した感染事例のフローチャートです。この事例では、メールにリンクが含まれていて、クリックするとzipアーカイブを返すようになっていました。このzipアーカイブには、Windowsショートカットファイルが含まれていて、そのショートカットファイルがTrickbot実行可能ファイルをダウンロードします。このTrickbot感染に関連するpcapは、こちら（バックアップ）に保存してあります。
このトラフィックからは、最近のTrickbot感染でよく見られる次の活動が確認できます。
- 感染したWindowsホストがIPアドレスの確認をしている
- 447/tcp、449/tcp経由でHTTPS/SSL/TLSのトラフィックが発生している
- 8082/tcp経由でHTTPのトラフィックが発生している
- 「.png」で終わるHTTPリクエストがあり、Windows実行可能ファイルを返している
このTrickbot感染に特有なのは、www.dchristjan[.]comに対するHTTPリクエストがzipアーカイブを返していること、そして144.91.69[.]195に対するHTTPリクエストがWindows実行可能ファイルを返していることでしょう。
ではここで、下図に示す手順でwww.dchristjan[.]comあてのリクエストを確認してみましょう。パケットを右クリックしてコンテキストメニューを開き、[Follow(追跡)]、[HTTP Stream(HTTPストリーム)]の順に選択してトラフィックを確認します。
表示されたHTTPストリームから、zipアーカイブが返されている痕跡を確認できます(下図参照)。
上図からは、zipアーカイブに含まれるファイル名が「InvoiceAndStatement.lnk」であることも確認できます。
Wiresharkでは、トラフィックからzipアーカイブをエクスポートすることができます。
[File(ファイル)]、[Export Objects(オブジェクトをエクスポート)]、[HTTP]を選択
HTTPオブジェクトのリストからContent Typeがapplication/zipの行を選んで[Save(保存)]をクリック
さて、144.91.69[.]195へのHTTPリクエストはWindows実行可能ファイルを返していました。これはTrickbotが初期に利用するWindows実行可能ファイルです。このHTTPリクエストのHTTPストリームを追跡すると、これが実行可能ファイルであることを示す痕跡を見つけることができます。
またpcapからは、この実行可能ファイルを抽出することができます。
初期感染トラフィックに見られるのは、443/tcp、447/tcp、449/tcp経由のHTTPS/SSL/TLSトラフィックと、感染WindowsホストからのIPアドレス確認です。この例での感染の場合、Trickbot実行可能ファイルのHTTPリクエストの直後に443/tcp経由で複数のIPアドレスに対してTCP接続が試行され、その後449/tcp経由で187.58.56[.]26へのTCP接続が成功している様子が確認できます。
以前の講座で作成したディスプレイフィルタ「basic+」を使うと、これらのTCP接続試行を確認できます。
447/tcp、449/tcp経由で行われたさまざまなIPアドレスへのHTTPS/SSL/TLSトラフィックからは、まともなものではない証明書のデータが見つかります。
証明書の発行者を確認するには、Wireshark 2.xでは「ssl.handshake.type == 11」でフィルタリングします。Wireshark 3.xを使っている場合は、「tls.handshake.type == 11」でフィルタリングします。次に、フレームの詳細セクションに移動して情報を展開し、下図に示した手順に従って証明書発行者データを見つけます。
上図からは、以下の証明書発行者データが、449/tcpを介した187.58.56[.]26へのHTTPS/SSL/TLSトラフィックで使用されていることがわかります。
- id-at-countryName=AU
- id-at-stateOrProvinceName=Some-State
- id-at-organizationName=Internet Widgits Pty Ltd
まともなHTTPS/SSL/TLSトラフィックであれば、州や県の名前が「Some-State」であったり、組織名が「Internet Widgits Pty Ltd」になっていたりすることはありえません。これらは、これが悪意のあるトラフィックであることを示す痕跡です。また、証明書発行者データにこうした異常が見られるのは、Trickbotに限ったことではありません。
では、まともなHTTPS/SSL/TLSトラフィックの正常な証明書発行者とは、どのように見えるものなのでしょうか。これについては、同じpcap内で先に発生していたMicrosoftのドメイン72.21.81.200への443/tcpのトラフィックを見るとよいでしょう。これは、下図に示すような内容であることがわかります。
- id-at-countryName=US
- id-at-stateOrProvinceName=Washington
- id-at-localityName=Redmond
- id-at-organizationName=Microsoft Corporation
- id-at-organizationUnitName=Microsoft IT
- id-at-commonName=Microsoft IT TLS CA 2
Trickbotに感染したWindowsホストは、さまざまなIPアドレス確認用サイトを使用してIPアドレスを確認します。これらの確認サイト自体は悪意があるものではありませんし、トラフィックそのものも本質的には悪意はありません。ただし、この手のIPアドレス確認行為は、Trickbotその他のマルウェアファミリ全般によく見られるものです。なおTrickbotの場合、以下を含む正当なIPアドレス確認サービスを利用しています。
- api.ip[.]sb
- checkip.amazonaws[.]com
- icanhazip[.]com
- ident[.]me
- ip.anysrc[.]net
- ipecho[.]net
- ipinfo[.]io
- myexternalip[.]com
- wtfismyip[.]com
繰り返しますが、IPアドレスの確認自体はとくに悪意のある行為ではありません。ただ、IPアドレスの確認と他のネットワークトラフィックでの行為があわされば、本事例で見てきたとおり、感染の指標として使えるようになります。
それ自体に悪意はないものの、このIPアドレス確認はTrickbot感染によって起こる活動の一部
現時点のTrickbotによる感染は、8082/tcp経由のHTTPトラフィックを生成します。このトラフィックは、感染ホストからのシステム情報、ブラウザキャッシュとメールクライアントのパスワードといった情報を送信します。この情報は、感染ホストからTrickbotが使うコマンド&コントロール(C2)サーバーに送信されます。
C2とのトラフィックを確認するには、次のWiresharkフィルタを使用します。
http.request and tcp.port eq 8082
このフィルタを適用すると、以下のHTTPリクエストを確認できるようになります。
- 170.238.117[.]187 port 8082 - 170.238.117[.]187 - POST /ono19/BACHMANN-BTO-PC_W617601.AC3B679F4A22738281E6D7B0C5946E42/81/
- 170.238.117[.]187 port 8082 - 170.238.117[.]187 - POST /ono19/BACHMANN-BTO-PC_W617601.AC3B679F4A22738281E6D7B0C5946E42/83/
- 170.238.117[.]187 port 8082 - 170.238.117[.]187 - POST /ono19/BACHMANN-BTO-PC_W617601.AC3B679F4A22738281E6D7B0C5946E42/81/
- 170.238.117[.]187 port 8082 - 170.238.117[.]187:8082 - POST /ono19/BACHMANN-BTO-PC_W617601.AC3B679F4A22738281E6D7B0C5946E42/81/
- 170.238.117[.]187 port 8082 - 170.238.117[.]187:8082 - POST /ono19/BACHMANN-BTO-PC_W617601.AC3B679F4A22738281E6D7B0C5946E42/90
- 170.238.117[.]187 port 8082 - 170.238.117[.]187:8082 - POST /ono19/BACHMANN-BTO-PC_W617601.AC3B679F4A22738281E6D7B0C5946E42/90
「81」で終わるHTTP POSTリクエストは、webブラウザや電子メールクライアントなどのアプリケーションにキャッシュされたパスワードデータを送信しています。「83」で終わるHTTP POSTリクエストは、webブラウザなどのアプリケーションが送信したフォームデータを送信しています。また、「90」で終わるHTTP POSTリクエストは、システム情報を送信していることが確認できます。これらHTTP POSTリクエストのどれか1つをTCPストリームないしHTTPストリームとして追跡すれば、この感染で窃取されたデータを確認できます。
TrickbotはHTTP GETリクエストを使い、「.png」で終わるWindows実行可能ファイルをさらに送信してきます。Trickbotのフォローアップを行うこれらの実行可能ファイルは、感染WindowsホストがActive Directory環境のクライアントの場合、脆弱なドメインコントローラ（DC）に感染するために使用されます。
次のWiresharkフィルタを使うと、pcap内にあるこれらHTTP GETリクエストのURLを見つけることができます。
http.request and ip contains .png
フィルタリングで見つかった3つのGETリクエストそれぞれについて、TCPストリームないしHTTPストリームを追跡してください。Windows実行可能ファイルの痕跡が見つかるはずです。ただしこの事例でのHTTPレスポンスヘッダは、それが明らかにWindows実行可能ファイルやDLLファイルであっても、返されたファイルを「image/png」だと識別しています。
これらのファイルについても、先に説明した手順でWiresharkからエクスポートし、Windows実行可能ファイルであることを確認し、SHA256ファイルハッシュを取得することができます。
他のマルウェアによって配信されるTrickbot
Trickbotはほかのマルウェアによって配信されることも多くあります。たとえばTrickbotはEmotetによる感染でフォローアップ用マルウェアと見なされることが多いですし、IcedIDやUrsnifなど別のマルウェアに感染した場合のフォローアップにもよく使われます。
ただやはりEmotetがTrickbotを配信する例が多いので、ここではEmotetとTrickbotの感染について確認してみることにしましょう。本チュートリアルではTrickbotの活動に焦点を当てたいと思います。
対応するpcapはこちらのページ（バックアップ）からをダウンロードしてください。このpcapは、パスワードで保護されたzipアーカイブファイル「2019-09-25-Emotet-infection-with-Trickbot-in-AD-environment.pcap.zip」内にあります。パスワードには「infected」と入力し、zipアーカイブからpcapを抽出してWiresharkで開いてください。前回までの講座で作成したディスプレイフィルタ「basic」を適用して、webベースの感染トラフィックを確認します(下図参照)。
経験豊かなアナリストであれば、Emotetの生成するトラフィックとTrickbotの生成するトラフィックとをひと目で識別できるでしょう。Emotetによる感染後活動は、HTTPトラフィックでサーバーからエンコードデータを受信する内容となっています。これはコマンド&コントロール通信にHTTPS/SSL/TLSトラフィックを使うTrickbotの感染後の活動とは明らかに異なります。たとえば、下図に2019年9月の感染事例で確認されたEmotetとTrickbotの感染トラフィックを示していますが、この図からも両者が極めて異なっていることがわかります。
この特定の感染例は、感染Windowsクライアントが10.9.25.102、DCが10.9.25.9というActive Directory環境で発生したものです。トラフィックの最後のあたりに、DCがTrickbotに感染した兆候が見られます（下図参照）。
では、クライアントからどのようにしてDCに感染が広がったのでしょうか。Trickbotはある特定のEternalBlueエクスプロイトを使い、MicrosoftのSMBプロトコルを介して横展開します。この事例で感染Windowsクライアントは、445/tcp経由で10.9.25.9のDCに情報を数回送信した後、Trickbot実行可能ファイルを185.98.87[.]185/wredneg2.pngから受信していました。
「basic+」フィルタを使い、DCが185.98.87[.]185に通信を張る直前の、10.9.25.102のクライアントと10.9.25.9のDCとのトラフィックのSYNセグメントをフィルタリング表示してみましょう(下図参照)。
TCPストリームをどれか1つ選び、右クリックしてコンテキストメニューから[追跡]を実行してください。ここでは、接続元が10.9.25.102、接続元のTCPポートが49321、接続先が10.9.35.9、接続先TCPポートが445の行を追跡しています。このトラフィックはクライアントがDCに送るものとしてはかなり特異な内容であるため、EternalBlueエクスプロイトに関連したものと考えられます。このトラフィックを表示したのが下図です。
この特異なSMBトラフィックとDCの感染を除けば、こちらのpcapで見られたTrickbot特有の活動は、マルスパムのpcapで見られた内容と非常によく似ています。