はじめに

2017 年 6 月 14 日、弊社次世代ファイアウォールと Traps 4.0 を配備した検証用ハニーポット環境に Ursnif とよばれるトロイの木馬の亜種が電子メール経由で着信しました。 そこで本稿では、お客様環境で同脅威が検出された場合に行われるべき一連の調査手順を提示しつつ、本脅威を分析した結果について以下の順で解説していきます。

  • トロイの木馬 Ursnif とは
  • Ursnif の攻撃シーケンス
  • 最初に着信した Word 検体
  • 第一段階: 弊社次世代ファイアウォールと Traps 4.0 導入環境でメールに添付されている Word 検体がどのように検出されるか
  • WildFire への接続性がない環境の場合、メールに添付されている Word 検体がどのように検出されるか
  • 第二段階: PowerShell が実行された場合、ダウンロードされた Ursnif 検体がどのように検出されるか
  • WildFire への接続性がない環境の場合、ダウンロードされた Ursnif 検体がどのように検出されるか
  • AutoFocus による調査結果
  • おわりに

トロイの木馬 Ursnif とは

Ursnif は 主に日本の銀行を狙う悪名高いトロイの木馬 であり、2017 年 2 月、パロアルトネットワークスの脅威インテリジェンスチーム Unit42 が本 Ursnif を使った攻撃配信ネットワークの存在を明らかににしたものです。

Ursnif は日本に対する攻撃に 1 年以上使用され続けていることがわかっています。その主な配信手法は悪意のある添付ファイル付きスパム電子メールで、その添付ファイルによりリモートサイトから Ursnif の実行ファイルをダウンロードします。Ursnif に感染した端末は踏み台となりさまざまな国へ攻撃を行う配信ネットワークに加えられます。

この Ursnif による攻撃の標的には、日本に加えてヨーロッパが挙げられ、銀行を狙うトロイの木馬として利用されています。 Ursnif の配信ネットワークは、電子メールを配信するスパム ボットネットと、1 組の侵害された Web サーバーという 2 つの主要要素で構成されています。このスパム ボットネットによる攻撃は、銀行を狙うトロイの木馬またはダウンロード型トロイの木馬を、日本やイタリア、スペイン、ポーランド、オーストラリア、ドイツを中心に配信する活動です。侵害された Web サーバーからは銀行を狙うトロイの木馬およびスパムボット ファイルが送られ、これらトロイの木馬やスパムボット ファイルは、スパムが配信した悪意のあるダウンローダー プログラムによってダウンロードされます。

Ursnif の攻撃シーケンス

2017 年 6 月 14 日に弊社の次世代ファイアウォールと Traps 4.0 を配備したハニーポット環境にメール経由で着信した Ursnif 亜種の攻撃シーケンスは次のようなものでした(図 1)。

  1. 攻撃者から Word の添付ファイルがついた電子メールが送付されてくる
  2. 受信者が Word ファイルを開くとマクロが実行される
  3. マクロによりコマンドプロンプトが起動されそこからさらに Powershell が起動される
  4. Powershell で %USERPROFILE%¥AppData¥Roaming に Ursnif 本体 (実行ファイル) がダウンロードされ、この実行ファイルが起動される
  5. 被害端末が感染する

img/Fig001.png

図1: Ursnif の攻撃シーケンス

最初に着信した Word 検体

次に 1 ステップずつ詳細を見ていきます。着信した電子メールは本文が日本語で、添付されていた Word ファイルの特徴は以下の通りでした(図 3)。

  • 添付ファイル名: 09987.doc
  • 添付ファイルの種類: Microsoft Word 97-2003 文書
  • 添付ファイルサイズ: 75,776 byte
  • 添付ファイルハッシュ値 (SHA-256): 784dca5b402c493126ddf4488bc482ee579292f219fe7d8e20ec95b6379dea1b

img/Fig003.png

図3: 添付されていたマクロ付き Wordファイルのプロパティ

第一段階: 弊社次世代ファイアウォールと Traps 4.0 導入環境でメールに添付されている Word 検体がどのように検出されるか

弊社検証環境で電子メールに添付されているファイルを保存し、Microsoft Word で開いてみると、即座に Traps が検出することが確認できました。 Traps はクラウドベースの WildFire サービスと連携して動作し、不審なコンテンツをすばやく遮断しますが、WildFire サービスへ接続していない場合でも、機械学習によるローカル分析によって不審な Word ファイルを遮断します (図 5)。

img/Fig005.png

図5: 添付されている Word ファイルを開いたところ。Traps は不審なマクロとして検出している

今回このファイルが WildFire とローカル分析のどちらで遮断されたのかを確認するため、Traps の統合管理を行う ESM サーバー(Endpoint Security Manager) にログインし、該当する検出内容を確認しました(図 6)。Event Type が WildFire Malware、Module が WildFire であることから、本検体がメール着信前にすでに WildFire で検出可能な状態であったことがわかります。また WildFire レポートを生成して確認すると、最初に WildFire が認識した時間帯 (First Seen Timestamp) が 2017-06-14 07:34:02 UTC であり、日本時間で 2017-06-14 16:34:02 だったことも確認できます(図 7)。この時刻をメールを受信した時刻 (図 8) と比較すると、WildFire への登録のほうが メールの着信より 2 分早かったことが分かります(図 8)。

img/Fig006.png

図6: ESM サーバーで該当する検出の内容を確認したところ。Event Type が WildFire Malware、Module が WildFire であることから、本検体がメール着信前に WildFire で検出可能な状態であったことがわかる

img/Fig007.png

図7: ESM サーバーの該当する検出で、WildFire レポートを生成して確認したところ、最初に WildFire が認識した時間帯 (First Seen Timestamp) が 2017-06-14 07:34:02 UTC であることから、日本時間で 2017-06-14 16:34:02 であったことが確認できる

img/Fig008.png

図8: WildFire が最初に検体を認識した時刻の 2 分後当該メッセージを POP した

以上より、本検体についてはローカル解析ではなく Traps 4.0 の新機能である Microsoft Office に対する WildFire の機能によって検体をブロックできていたこと、メール着信の 2 分前にすでに WildFire によって認識されていた検体であったことが確認できました。

WildFire への接続性がない環境の場合、メールに添付されている Word 検体がどのように検出されるか

今回の検体は、最初の関門である WildFire の脅威データベースによって実行が阻止されていました。しかし常にそうなるとは限りません。なんらかの理由から ESM サーバーとの通信が行えず WildFire のデータを利用できない場合もありえますし、WildFire がまだ見たことのない検体が着信する場合もあります。

そこで、「WildFire からの情報が利用できなかった場合は何が起こるか」を検証しました。WildFire が阻止しなかったマルウェアは、 機械学習によるローカル分析が行われて実行を阻止されると予期されます。

これを検証した結果、予想どおり Traps によるローカル分析が本検体の実行を「不審なマクロ」として阻止することが確認できました (図 9)。

img/Fig009.png

図9: WildFire が利用できない状況でのローカル分析による阻止。不審なマクロとして検知される

さらにここで、「故意にマクロを実行させた場合に何が起こるか」についても検証してみました。その結果、ここでも マルウェアによく見られる子プロセス生成の動作 (Word.exe から cmd.exe を呼び出そうとした) を検知し、実行が阻止されることが確認できました (図 10)。

img/Fig010.png

図10: マクロを敢えて実行した場合でもマルウェアによる子プロセス生成を不審な動作として検出する

Traps が実行を阻止した際の動作をより詳細に確認するため ESM サーバーの該当記録も併せて確認してみます。 ここでは、Microsoft Word プロセスが cmd.exe の子プロセスを生成しようとしたために、不審な動作として実行が阻止されたことがわかります(図 11)。さらに Traps から取得されたダンプ情報の <CommandLine> の部分からは、Powershell を起動してマルウェアをダウンロードしようとした様子も確認できます(図 12)。

img/Fig011.png

図11: 不審な子プロセス生成が検出され、実行が阻止される

img/Fig012.png

図12: ダンプから PowerShell で実行しようとしたコマンド (難読化されている)。別の実行ファイルをダウンロードしようとしていることがわかる

第二段階: PowerShell が実行された場合、ダウンロードされた Ursnif 検体がどのように検出されるか

最初のメッセージ受信時刻は 2017-06-14 16:36 でした。Traps は期待されたとおり Word 検体を検出しますので、侵入が次の段階に進むと何が起こるかを確認するため、受信後の 2017-06-14 17:12 に故意にマクロを有効化して PowerShell を強制的に実行させることでマルウェアをダウンロードすることにしました。

以下がこの「ダウンロードを指示する PowerShell コマンドが実行された場合何が起こるか」についての検証結果です。2017-06-14 17:12 にダウンロードされた検体は以下の通りです。

  • ファイル名: 34388.exe
  • ハッシュ値(SHA-256): b534c41b182295e9a988d496b2c9af17cd0d1e7145c7344ea4285cc74bd867d4

同検体を検出した際の Traps ログを ESM サーバー上で確認してみます。Event Type が WildFire Malware であることから、Traps のローカル分析ではなく WildFire による検出であることが分かります。

img/Fig013a.png

図13a: 17:12 時点で PowerShell コマンドを強制的に実行させた結果。WildFire が同検体 (b534c41b182295e9a988d496b2c9af17cd0d1e7145c7344ea4285cc74bd867d4) を既知の検体として検出している様子

さらにこのファイル ハッシュ値で WildFire レポートを生成すると、2017-06:14 06:28:03 UTC、日本時間で 2017-06-14 15:28:03 時点で WildFire が検体を確認していることがわかりました。つまり、テスト実施時刻の 1 時間 40 分前には、WildFire による検知が可能な状態となっていたことになります。

img/Fig013b.png

図13b: 17:12 時点で PowerShell コマンドを強制的に実行させた結果。WildFire が同検体 (b534c41b182295e9a988d496b2c9af17cd0d1e7145c7344ea4285cc74bd867d4) を2017-06:14 06:28:03 UTC (日本時間 2017-06-14 15:28:03) に検出している

この後さらに日本時間 2017-06-14 23:28 にも同じ検証を繰り返したところ、今度は 61178.exe という名前で実行ファイルがダウンロードされました。ファイル名が前回の検証時と異なるのは、PowerShell コマンドで保存するファイル名がランダム化されているためです。

  • ファイル名: 61178.exe
  • ハッシュ値 (SHA-256): 3e762e25659a218b1811b5cea9f7080fa96562629eec453144490edbc2466fb9

同ファイルも 17:12 の検証時のハッシュ値 b534c41b182295e9a988d496b2c9af17cd0d1e7145c7344ea4285cc74bd867d4 の検体同様、Traps により実行が阻止されることが確認できました(図 13b)。

img/Fig013c.png

図13c: PowerShell コマンドによりダウンロードされた実行ファイル 61178.exe を Traps が検出した様子

図 13a と図 13c の間では、検体のハッシュ値が異なっています。詳細は後述しますが、次世代ファイアウォールから確認した接続先サーバーは同一で、URL も同一だったことから、攻撃者は 17:12 以降 23:28 以前のいずれかの時点でファイルを置き換えたものと推測されます。

2017-06-14 23:28 の検証についても WildFire とローカル分析のいずれの方法で阻止したのかを確認するため、ESM サーバーにログインして Traps の検出ログを確認しました。するとこの回も Event Type が WildFire Malware、Module が WildFire であったことから、当該マルウェアが WildFire にとって既知のものであったことが確認されました。つづけて WildFire が最初に同検体を確認した時刻を確認するために WildFire レポートを生成したところ、その時刻は 2017-06-14 13:07:40 UTC、つまり日本時間で 2017-06-14 22:07:40 時点であったことが確認できました(図14)。つまりこの検証でダウンロードされた検体についても、検証時刻の 1 時間 30 分前には、WildFire で入れ替えられた検体が検出される状態となっていました。

img/Fig014.png

図14: ESM サーバーにログインして Traps の検出した際のログを確認したところ。Event Type が WildFire Malware、Module が WildFire であることから WildFire の既知のマルウェアであったことが確認できる。さらに WildFire レポートを生成すると最初に確認された時刻が 2017-06-14 13:07:40 UTC となっており、日本時間で 2017-06-14 22:07:40 には最初の検体を検出済みであったことが確認できる

この検証ではさらに調査を進め、PowerShell コマンドでアクセスした 2 つのサーバーについても調べてみました。まず検証環境の次世代ファイアウォールの接続記録を確認してみると、被害端末からアクセスされていたのは 80/tcp の HTTP サーバー 2 つで、それぞれの IP アドレスのリージョンはチェコと日本となっていることが分かりました。また、通信量から考え、実際にマルウェアをダウンロードしたのは日本のサイトからだったと推測されます (図 14)。

img/Fig015.png

図15: PowerShell コマンドにより接続された web サーバー(tcp/80) は 2 つ。通信量 (チェコの IP アドレスからが 3.4KB、日本 の IP アドレスからが 321.6KB) からは、日本のサイトからマルウェアをダウンロードした様子が伺える

WildFire への接続性がない環境の場合、ダウンロードされた Ursnif 検体がどのように検出されるか

第一段階の検体同様、23:28 にダウンロードされた検体についても、WildFire からの情報がなかった場合や ESM サーバーにアクセスできない状態を想定し、ローカル分析で Traps がどのように実行を阻止するかを確認してみます。ここでも Traps が不審なプロセスとしてこの実行を阻止する様子が確認できます (図 16)。

img/Fig016.png

図16: ESM サーバーに接続できないなどの理由で WildFire 情報が利用できない場合でもローカル分析により不審なプロセスが検出される

調査時点 (23:28 の検出) で他社アンチウイルス ソリューションでの本検体の対応状況がどのようなものであったか VirusTotal で調べた結果を図 17 に示します。VirusTotal への最初の検体提供は 2017-06-14 12:41:56 UTC ですので日本時間では 2017-06-14 21:41:56 が VirusTotal での同検体の初認時刻だったようです。

WildFire で最初の検体が提供されたのは日本時刻 2017-06-14 22:07:40 でしたので、VirusTotal に最初に検体が提供されてから 25 分 44 秒後には WildFire で検出・実行阻止が可能だったということになります。

残念ながら VirusTotal に最初の検体が提供された時刻での各社の対応状況はわかりませんでしたが、VirusTotal で分析した時刻 2017-06-14 14:43:58 UTC、日本時間で 2017-06-14 23:41:56 時点では、VirusTotal での検体初認から 2 時間が経過した時点で 60 社中 11 社のアンチウイルス ソリューションのみが同検体を検出するという結果 (図17) が得られました。WildFire での初認時刻 2017-06-14 22:07:40 時点では、さらに検出可能なアンチウイルス ソリューションは少数であったものと推測されます。

img/Fig017.png

図17: VirusTotal 参加アンチウイルスソリューションでの検出状況。参加 60 製品中、11 製品が検出し、49 製品が検出していない

AutoFocus による調査結果

ダウンロードされた検体についてさらに情報を得るため、弊社脅威インテリジェンス分析サービス AutoFocus で当該検体のハッシュ値 (b534c41b182295e9a988d496b2c9af17cd0d1e7145c7344ea4285cc74bd867d4 および 3e762e25659a218b1811b5cea9f7080fa96562629eec453144490edbc2466fb9) にどのようなタグが紐付けられているかを確認したところ、いずれの検体にも Ursnif に紐付いた IOC が存在することから Ursnif タグが付与されていることがわかりました。つまり両検体とも Ursnif の亜種であったと考えられます。

Ursnif は冒頭のブログからの引用でも説明したとおり、銀行を狙うトロイの木馬に利用されるマルウェアであることから、今回の攻撃者のねらいも、感染ホストを配信ネットワークに加え、銀行を攻撃させる目的のばらまき型攻撃であった可能性があります。

img/Fig018a.png

図18a: AutoFocus で 17:12 の検証でダウンロードされた検体のハッシュ値 (b534c41b182295e9a988d496b2c9af17cd0d1e7145c7344ea4285cc74bd867d4) を検索したところ。Ursnif の亜種であることを示す IOC が見つかったことがこのタグから読み取れる

img/Fig018b.png

図18b: AutoFocus で 23:28 の検証でダウンロードされた同検体のハッシュ値 (3e762e25659a218b1811b5cea9f7080fa96562629eec453144490edbc2466fb9) を検索したところ。同じく Ursnif の亜種であることを示す IOC が見つかっている

最後に同検体への今後の対策を検討するため、今後どのような侵入経路が取られそうか、またどの国が標的と考えられているかについても AutoFocus で確認しました。今回は、メールに添付されている Word ファイルと、マクロにより実行された PowerShell コマンドがダウンロードする Ursnif 亜種検体の 2 種類がありますが、侵入経路として利用されているのは Word ファイルであるため、ここでは Word ファイルについて調査しています。

メールに添付されていた Word 検体のハッシュ値 (784dca5b402c493126ddf4488bc482ee579292f219fe7d8e20ec95b6379dea1b) をすべてのサンプルを対象に検索し、統計データを表示させた結果を以下図 19 に示します。最初の検索実行日時は 2017-06-15 16:38 です。

img/Fig019.png

図19: AutoFocus でメールに添付されていた Word 検体のハッシュ値 (784dca5b402c493126ddf4488bc482ee579292f219fe7d8e20ec95b6379dea1b) を検索し、統計データを表示したところ。図 19 は 2017-06-15 16:38 時点のデータだが本稿初版作成日から 5 日経過した 2017-06-20 12:10 時点でのデータでも侵入経路として SMTP が好まれている (SMTP/POP3/IMAP) こと、攻撃対象国として日本が大多数を占めることは 2017-06-15 16:38 時点からほぼ変わっていない

おわりに

本稿では、弊社内にハニーポット環境に着信した Word ファイルの添付されたメッセージを使い、弊社 Traps と Traps が連携している WildFire がどのようにして同 Word ファイルや最終的にダウンロードされてくる Ursnif 亜種の実行ファイルを検出するかを順に解説しました。

また、Traps に WildFire からの情報を伝える ESM サーバーと通信できない場合に、Traps のローカル分析がどのようにマルウェアの実行を阻止するかについても確認しました。Traps が脅威を検出するプロセスについては、概要図を本稿文末付録 B として添付しておきます。

つぎに、故意にマクロを許可し、故意に PowerShell の実行をさせた場合でも、Traps がそれぞれの段階でマルウェア実行を阻止する様子を確認しました。メッセージの着信時刻、WildFire でのそれぞれの検体の初認時刻、VirusTotal での初認時刻を比較することにより、どの程度迅速に検体へ対応ができていたかについても確認しました。このことは、感染が発生した場合に、ネットワークが脆弱であった時間帯 (攻撃ウィンドウ) がいつからいつまででありえたかを特定することにつながります。また時刻を変えて実行することで、ダウンロードされる検体が攻撃者により変更された場合であっても、WildFire による事前の検出に成功している様子も確認しました。

最後に、AutoFocus を活用してダウンロードされた検体のマルウェア ファミリを調査することで、今回の攻撃が Ursnif 感染による配信ネットワーク形成とその配信ネットワークを利用した金銭詐取を目的としたばらまき型攻撃だったのではないかと推測しました。そして AutoFocus の統計データからは考えられる侵入経路が主にメールであること、主な攻撃の対象が日本であることを確認し、同攻撃に対して今後どのように組織で対策をとるべきかについての基礎となる情報を得ました。

弊社 Traps、次世代ファイアウォールを導入している環境で、特定検体からの調査をどのように進めれば良いかについてお困りであれば、ぜひ本稿を活用していただければと思います。

なお本稿は Traps の動作検証を目的としているため、検証環境内の次世代ファイアウォール側の設定はタップモード (検出しても遮断しない) に設定してある点にご注意ください。次世代ファイアウォールと Traps の両方が導入されている環境で次世代ファイアウォール側の設定が遮断モードに設定されているのであれば、Traps に到達する「前」、次世代ファイアウォールに着信した時点で弊社 Threat Prevention 技術による脅威検出・遮断が実行されることになり、侵入経路となった Word 検体が添付されたメッセージがエンドポイントに到達することはなかったでしょう。

最後に WildFire による初検出時刻、Traps による検出タイミング、検証実施時刻のタイムラインを付録 A として記載します。とくにばらまき型攻撃においては、世界中で共有された脅威データベースを利用してマルウェア阻止する WildFire の仕組みが非常に有効であることが確認できる結果となっています。

付録 A: 発生した事象の時系列

img/Timeline.png

付録A: 発生した事象の時系列

付属 B: Traps による「マルウェアの防止」と「脅威の防止」の仕組み

img/exploit_malware_prevention.png

付録 B: Traps による「マルウェアの防止」と「エクスプロイトの防止」の仕組み


 関連コンテンツ

パロアルトネットワークス管理者ガイド日本語版

このガイドで、パロアルトネットワークスのファイアウォールのWeb管理画面の使用方法を説明します。対象は設置、運用管理、メンテナンスを行うシステム管理者向けです。 ※このページで提供する管理者ガイドが最新版でない可能性があります。最新版に関しては、製品をご購入された販売代理店にご相談ください。  

  • 0
  • 6472

PA-800 シリーズ

主なセキュリティ機能: すべてのアプリケーションをすべてのポートで常時識別 • 使用されているポートや暗号化(SSLまたはSSH)、セキュリティの回避技術に関わらず、アプリケーションを識別します。 • 許可、拒否、スケジュール、スキャン、帯域制御の適用などのセキュリティ ポリシー決定の要素として、ポートではなくアプリケーションを使用します。 • 不明なアプリケーションを、ポリシー制御、脅威のフォレンジック、またはApp-ID™アプリケーション識別テクノロジの開発が行えるよう分類します。

  • 0
  • 5462

PA-3000シリーズ スペックシート

PA-3000シリーズの主な機能、パフォーマンスと容量、および仕様。

  • 0
  • 4188

PA-5200 シリーズ

パロアルトネットワークス® PA-5200シリーズの次世代ファイアウォール アプライアンスは、PA-5260、PA-5250、PA-5220から構成されており、高速データセンター、インターネット ゲートウェイ、およびサービス プロバイダでの導入に適しています。PA-5200シリーズは、ネットワーキング、セキュリティ、脅威からの防御と管理の重要な機能領域専用の処理機能とメモリを使用して、最大80Gbpsのスループットを提供します。

  • 0
  • 2233