• HOME
    • セキュリティブログ

FortiGuardの社内用脅威インテリジェンスプラットフォーム(Kadena)のおかげで、FortiGuard Labsはロシアのサービスセンターを標的とした一連の攻撃を発見しました。これらのサービスセンターは、様々な電子製品に対する保守サービスやサポートを提供しています。

攻撃の顕著な特徴として挙げられるのが、段階式になっている点です。これらの攻撃では偽のEメールや、17年前からの脆弱性を狙うエクスプロイトを備えた悪意あるOffice文書、5層で構成される保護用パッカーに組み込まれた市販の遠隔操作ツール(RAT)が使用されています。

今回の記事では、攻撃の全段階を見ていきます。同じグループが実行している別の攻撃とのつながりも探りたいと思います。記事の最後にはIOCのセクションも設けました。


スピアフィッシングEメール

3月末、電子機器の修理やアフターサービスを行っているロシアの某サービス会社が、いくつかのEメールを受信しました。これらのEメールはサムスンの担当者からであることを装っていました。下の図がEメールの一例です。

これらのEメールは計画的な標的型攻撃の出発点であり、無作為の大規模な攻撃キャンペーンの一環ではないと私たちは考えています。結論にいたった理由を挙げてみましょう。

  • Eメールはサムスンの電子機器の修理を行うサービス会社に送られた
  • この会社はロシアに拠点を置き、Eメールはロシア語で書かれており、「From」欄にはロシアの名前が入っていた
  • 送信者はサムスンの担当者であることを名乗っている
  • Eメールには標的とされた企業の概要に関連する、Symptom_and_repair_code_list.xlsxというファイルが含まれている

Figure 1. A Part of the email sample. Exploit file is attached

図1. Eメールサンプルの一部。エクスプロイトファイルが添付されている

Eメールをじっくり調べてみた結果、この文章はロシア語を母語とする人が書いた可能性は低く、おそらく機械翻訳されたものという結論に達しました。攻撃者たちはロシアの企業を標的としたものの、ロシア語は話せないと想定できます。

Eメールのヘッダーも分析してみました。SPFの認証結果はsoftfailとなっています。つまり、送信者のIPアドレスは「From」欄のドメインと関連がないことになります。

Figure 2. Sender Policy Framework soft-fail

図2. センダーポリシーフレームワークのsoft-fail

見つけたEメールにはすべて異なるファイルが添付されていたのですが、これらには共通するパターンがありました。添付ファイルはすべて.XLSX形式になっており、どれも正規のものに見えます。下の図はファイルの中身の一例です。

Figure 3. Content of the one of the .xlsx exploits

図3. .xlsx形式のエクスプロイトの1つの中身

もう1つ、サンプルに共通する特長があります。すべてにエクスプロイトが含まれていたのです。これについては、次のセクションで詳細を述べたいと思います。

ちなみに、悪意のある文書のなかには、下図のようなプリンタ設定の文字列が入っています。

Figure 4. PrinterSettings1.bin from the malicious sample

図4. 悪意のあるサンプル内のPrinterSettings1.bin

調べた結果、文字列はこれらのファイルのソースに関連するものであり、攻撃者のものではないという結論に達しました。しかし、文字列のIPはおそらく、これらの文書が最初に作成された組織に関連するものです。文書内のプリンタはすべてサムスン製でした。攻撃者は後からこれらを改変し、エクスプロイトを入れ込んだのです。

これらの怪しい文書で動的テストをしている最中に、eqnedt32.exeの不正なアクティビティが記録されました。そこで、CVE-2017-11882が使用されている疑いが持ち上がりました。後に、新しいサンプルのすべてが同じ脆弱性CVE-2017-11882のエクスプロイトであることが判明しました。この脆弱性は現在のあらゆるWindowsプラットフォームに入ることができる安定したものであるため、マルウェアの作成者は気に入っているのでしょう。「eqnedt32.exe」というコンポーネントが17年間更新されていないのが、その理由です。

このコンポーネントは非常に古いため、リサーチャーのなかにはMicrosoftがeqnedt32.exeのソースコードをなくし、脆弱性を修正するのに既存の実行可能ファイルのバイナリパッチをする必要があったのではと考える人もいますEMBEDI.comで公開されている記事(英文)では、この脆弱性に関するより詳細な分析をご覧いただけます。

Figure 5. Malicious activity of the eqnedt32.ex

図5. eqnedt32.exeの不正なアクティビティ


シェルコードの分析

今回のシェルコードは、位置独立コード(PIC)の標準的なタスクを解決するのに使用されています。

  • 本文の残りの部分の非暗号化を行う
  • kernel32.dllのアドレスを決定する
  • kernel32.dllのエクスポートディレクトリのパースを行い、LoadLibraryAGetProcAddressという2つの関数のアドレスの位置を特定する。この2つの関数を使って、ペイロードの実行に必要な関数にアクセスできるようになる。
  • LoadLibraryAGetProcAddressを使い、必要な他の関数のアドレスを入手する。この場合、興味深いことに「hashing names」のテクニックは使用されていない。つまり、シェルコードの作成者は実際にはコードサイズに制限されていなかったため、プレーンテキストに関数名を保存する「余裕があった」ことになる。
  • シェルコードが「インポート」した2つの最も重要な関数は、URLDownloadToFileWExpandEnvironmentStringsW
  • 1つ目の目的は明らか。2つ目の関数はダウンロードしたペイロードをシェルコードが保存すべき正確な位置を決定するのに使用される。位置がプラットフォームにより異なるのがその理由。
  • 最後に、このシェルコードはhxxp://brrange.com/imm.exeというURLからファイルをダウンロードし、それを%APPDATA%server.exeに保存し、実行を試みる。

Figure 6. Shellcode: obtaining an address of URLDownloadToFileW

図6. シェルコード: URLDownloadToFileWのアドレスを取得


ペイロードの分析

今回の記事では、悪意のあるURL、Brrange[.]com/imm.exeからダウンロードされたペイロードの1つを分析してみることにしました。

そのプロセスが上の図5になります。参考までに、分析したサンプルのSHA-256チェックサムは、975ddf75491e3f482a7d7941e4fd33fb98e4daf339f57a4c7843fd2b375c199bでした。


ペイロードの解凍

不正な関数を分析する前に、サンプルを解凍する必要があります。サンプルは多層かつ複数のパッカーにより保護されています。

第1段階: ConfuserEx

1層目の保護は、有名なConfuserExというパッカーです。このパッカーはオブジェクト名、メソッドやリソースの名前を難読化し、人間による解読、理解を困難にしています。また、ConfuserExには多くのケースジャンプが含まれており、実行のワークフローを変えるのに使用されます。従って、静的分析だけでは、コードのどの部分が次に実行されるのかを予測するのは困難です。

Figure 7. ConfuserEX: Obfuscated code of the sample

図7. ConfuserEX: サンプルの難読化されたコード

サンプルの自己解凍プロセスの一般的なワークフローは以下の通りです。

  • 「パディング」の記号を削除し、リソース名を復号。例えば、「ADAeAmAasAAuAAAAAsLAoAtAAaAAAsAiAAAAtAAAAAAAAoAAAAA」の文字列から大文字の「A」をすべて削除すると、「DemasusLotasito」が得られる。
  • 復号した名前のリソースから、バイトのBLOBを読み込み、配列を形成。この配列がペイロードの次の段階となっており、これはDES暗号で暗号化されている。
  • ペイロードの復号のため、パッカーは以下のパラメータでDES.decryptorを初期化。
    KEY: 0x59, 0x2F, 0x55, 0x3D, 0x17, 0x4A, 0x55, 0x10
    IV: 0x4A, 0x59, 0x36, 0x0D, 0x60, 0x59, 0x4A, 0x55

    Figure 8. ConfuserEX: Payload decryption

    図8. ConfuserEX: ペイロードの復号

  • 最後に、リソースの復号を行い、復号したファイルを実行。下の図は、「sender2」という配列の内部。DOSヘッダーのMZマジック値である0x4D, 0x5Aで始まっている。ここでは、復号したファイルの名前は「BootstrapCS」になっている。これについて次のセクションで分析します。

    Figure 9. ConfuserEX: Running the next stage of the Payload

    図9. ConfuserEX: ペイロードの次の段階を実行


第2段階: BootstrapCS

BootstrapCSは多層保護の第2段階における実行可能ファイルの内部名です。この層は難読化されていませんが、アンチウイルスチェックが数多く含まれています。どのチェックが行われるべきかは、リソース部分の「settings」構造によって決定されます(下の図を参照)。mainfileというバイナリリソースがあるのにお気付きかと思いますが、これはペイロードの暗号化された第3段階です。

Figure 10. Resource section of the BootstrapCS

図10. BootstrapCS.のリソース部分

このモジュールの主なアンチアナリシス機能:

  1. エミュレーション、サンドボックス、仮想マシンに対し様々なチェックを実行
    1. 「SbieDLL.dll」をチェック
    2. 「Win32_VideoController object」の記述にある特定の値をチェック
      • VMware
      • VM additions S3 trio32/64
      • S3 trio32/64
      • VirtualBox graphics adapter
      • VMware SVGA II
  2. 指定したプロセスを検索し、シャットダウン
    1. Fiddler Web Debugger
    2. WPE PRO
    3. Wiresharkネットワークアナライザー
  3. システムユーティリティを無効化
    1. コマンドプロンプト
    2. レジストリエディタ
    3. タスクマネージャー
    4. ユーザーアクセス制御(UAC)
  4. 以下のスタートアップレジストリキーに、ペイロードのパスを書き込む
    1. HKLM\Software\Microsoft\Windows\CurrentVersion\Run\[Specified Name]
    2. HKCU\Software\Microsoft\Windows\CurrentVersion\Run\[Specified Name]
  5. システム属性と隠し属性をファイルに割り当て、ファイルを隠す
  6. 様々なプロセスにペイロードを注入
    1. Vbc.exe
    2. RegAsm.exe
    3. AppLaunch.exe
    4. Svchost.exe
    5. Notepad.exe
    6. Current process

解凍の手順:

「settings」リソースのなかにバイナリがあり、「mainfile」という名前のものが暗号化された実行可能ファイルです。これが圧縮保護の第3段階です。ここで使用されている暗号スキームはKEY = 0x20のシンプルなXORアルゴリズムです。

Figure 11. Decrypting the Payload

図11. ペイロードを復号

復号の後、「settings 」リソースのファイルの値に基づき、ペイロードがプロセスの1つに注入されます。

Figure 12. Possible injection targets

図12. 注入される可能性のある対象


第3段階: 7Zip

復号したペイロード「mainFile」を見てみると、内部名は「im3.exe」となっており、リソースの中に「application」と「_7z」という2つの項目があります。「Imminent-Monitor-Client-Watermark」という興味深い行もあります。

Figure 13. Internals of the

図13. 「im3.exe」の内部

ここには以下の情報が含まれています。

Figure 14. The developer's watermark

図14. 開発者のウォーターマーク

ここに入っているドメイン「imminentmethods.net」を調べてみると、「Imminent Monitor」という市販の遠隔操作ツール(RAT)の公式ウェブサイトであることがわかりました。

誰でもライセンスを購入し、サーバーを設置し、独自のクライアントスタブを構築できます。このツールの開発者たちは、悪意を持ってツールを使用するのを禁止すると、ポリシーではっきりと述べています。おそらく、このウォーターマークを入れているのは、悪意のあるキャンペーンにおいて、このツールがペイロードとして利用されないようにするためでしょう。

ウォーターマークは、Imminent Monitorソフトウェアのバージョン4.4のコードに含まれています。この記事を書いている時点では、公開されているバージョンでクラックされたものは3.9と4.1しかありません。従って、ライセンスを正式に購入した人物が、コンパイルも行った可能性がありますが、はっきりと断言できません。

ファイルの分析をさらに進めると、「application」となっているリソースを解凍する必要が出てきました。解凍手順としては7zipの正規の「lzma.dll」ライブラリを使用します。

Figure 15. Unpacking im3 internals

図15. Im3の内部を解凍


第4段階: ConfuserEx?

この段階で遭遇したのは、なんと、またもやConfuserExでした。

しかも今回はリックロール(釣り動画)です。

Figure 16. Rick-Rolling URL in the ConfuserEX

図16. ConfuserEXのリックロール用URL

残念なことに、すでに動画はTwenty Century Foxによって著作権侵害が報告され、アクセスできませんでした。

Figure 17. Rickrolling attempt ...fails

図17. リックロール、失敗


RATの分析

これはImminent Monitorという RATの市販されているバージョンです。私たちの手元にあるバージョンのIMMは5つのモジュールで構成されています。

  • Aforge.Video.DirectShow 2.2.5.0
  • Aforge.Video 2.2.5.0
  • Injector 1.0.0.0
  • ClientPlugin 1.0.0.0
  • LZLoader 1.0.0.0

最初の2つのモジュールは、被害者のウェブカメラから録画することができます。あとの3つには、様々なスパイ&コントロール機能が含まれています。IMM機能の一覧は、公式ウェブサイトでご覧いただけますので、ここでは省きます。

私たちが行った動的解析によると、侵害の兆候(IOC)は次のフォルダにあります。

%AppData%\Roaming\Imminent\

Figure 18. Filesystem activity of the Imminent Monitor

図18. Imminent Monitorのファイルシステムのアクティビティ


関連する攻撃とのつながり

これらの攻撃で使われたC2サーバーも分析してみました。レジストラントのデータに基づき、同じ日に登録された50のドメインを発見しました。これらのドメインのなかには、すでにマルウェアの拡散に使用されたものもあります。フィッシングキャンペーンには別のグループも関連していました。これらのドメインは現在、フォーティネットのWebフィルタでブロックしています。ドメイン一覧は、記事の最後にあるIOCのセクションでご覧いただけます。

また、私たちが集めたサンプルの中で検索してみたところ、攻撃のサンプルと同じC2サーバーを使用する.XLSXサンプルがいくつか見つかりました。これらは以前からあるもので、違う脆弱性を使用します。どちらのサンプル群も、同一の攻撃者グループによるものと考えられます。サンプルの一覧も、IOCのセクションでご覧いただけます。


結論

FortiGuard Labsは、ロシアのサービスセンターを標的とした多段階攻撃を発見しました。これらの攻撃パターンは現在、かなり一般的になってきています。シンプルな実行可能ファイルよりも、エクスプロイトを使用したほうが高効率なのです。その理由は、脅威に対するユーザーの意識レベルが近年、大幅に高まっているからです。以前のように、ユーザーをだまして実行可能ファイルを開かせるのは容易ではありません。エクスプロイトはまた別の話です。

ワークフローのなかで、外部ソースからのMS Office文書を開くよう要求されたら、最も確実なセキュリティソリューションは、サンドボックステクノロジーに頼ることでしょう。例えばFortiSandboxは、未知の脆弱性につけ入る試みも検知可能です。皆さんの組織にFortiSandboxによる保護が導入されていて、未知のソースからのMS文書を受け取ったら、すぐに開かないようにしましょう。3~5分待ってください。悪意のあるファイルであれば、サンドボックス実行中にファイルが検知され、特殊シグネチャがリリースされ、FortiClientからサンプルに関して警告が送信されます。FortiSandboxと一緒にFortiMailも導入していれば、FortiMailが受信者にEメールを配信するのを差し止め、サンドボックスのプロセスが終了するまで待機します。

FortiGuardでは今後も登録されている残りのドメインや、この攻撃者グループのその他のアクティビティを監視していきます。

-= FortiGuard Lion Team =-


IOC

作成されるファイル:

  • %AppData%\RegAsm.exe
  • %AppData%\Roaming\Imminent\*.*

改変されるレジストリ:

  • HKLM\Software\Microsoft\Windows\CurrentVersion\Run\Regasm
  • "%AppData%\RegAsm.exe"

関連ファイルおよび検知内容:

015ec4becebcf293e7dac0f967818fdbe277d2c8567d1579c43ca7d647edeba6 MSIL/Kryptik.NJK!tr
1cb202f9da52e50b3f13bc93a1ccd12509593754ad178d8e1d47f18d539cb03a MSOffice/CVE_2017_11882.B!exploit
286f556cf1660f740c548a491f984a423c23605a6148828b97b0b46c7e34b2bd MSOffice/CVE_2017_11882.B!exploit
403f4e1bb443f57a6f26fcef699232ebfb3f5e1adabbce46a1ef03f4d23e601d W32/Generic.TJ!tr
4bdda7e7d4e4eda48ed39d3b8cb3162f8713f0ed75398f43cbd8727af050b6df MSIL/Kryptik.NKY!tr
6083ec0d005cf548073024e6f7c9296760972304bce569614ec5df9baa330926 MSIL/Kryptik.LOA!tr
67f5c55a5a61ceb50c3d37f106bba1fa57ae2d1f0a25c52aa949736908bc879f MSIL/Kryptik.NLJ!tr
711e8a64bb3aaf032753133c90a6a9c177ec146d378de9fb99497d2474229cae W32/Generic.TJ!tr
725d4e09fd28b41c62b66dd338f19e6b5cc871cbfbea69214a460beef00e7e70 MSIL/Kryptik.LOA!tr
74e3dc19b3b2cffd60865bd8ed248e7b2fe9e0826d125117206b12338849ad37 MSIL/Kryptik.NJK!tr
83772d16c4c791d44a27637376155781d1cf1b764b59b00430573e2efa936980 MSIL/Kryptik.MVX!tr
8969c56e0d541e0ea42021d4165505474c4dd99605926ab3c391df02af2d919e MSOffice/Exploit.CVE20178570!tr
975ddf75491e3f482a7d7941e4fd33fb98e4daf339f57a4c7843fd2b375c199b MSIL/Kryptik.NKY!tr
b0da24906af16ba77019e581f810923c97d7bc4e03c901cfb0158edb3de10f39 MSIL/Kryptik.NHX!tr
c7813f9520a2d906e72036a8766e04b3679b0f89cbea5ba4ceff494b4e0472c4 MSOffice/CVE_2017_11882.B!exploit
d29393a8aad337019794eb9bfb035950893350ed4f8fd559a8457754228fb9ae MSIL/Kryptik.NKY!tr
d58ab2d37666e1d4823af3325896d1fabc2b71338032d16adc52b4228ca56da7 MSIL/Kryptik.LOA!tr
ef8fe9afc0053e6a10ca568bbe3f71ec9358232d670d14af7da072a6e60cdf5e MSIL/Kryptik.NJK!tr

悪意のあるドメイン:

  • Brrange[.]com
  • cb4cb4.ddns[.]net
  • cb5cb5.noip[.]me
  • cb7cb7.ddns[.]net
  • derani[.]ir
  • frpfrp.ddns[.]net

フィッシング用ドメイン:

  • Brtory[.]com
  • Flscap[.]com

登録されているドメイン(現在監視中):

  • Agspre[.]com
  • Agtory[.]com
  • Agvill[.]com
  • Agworl[.]com
  • Bransio[.]com
  • Brcosm[.]com
  • Brdoma[.]com
  • Brfie[.]com
  • Brscap[.]com
  • Brspac[.]com
  • Brsphe[.]com
  • Brspre[.]com
  • Brteri[.]com
  • Brverse[.]com
  • Brvill[.]com
  • brworl[.]com
  • dacosm[.]com
  • dasphe[.]com
  • daspre[.]com
  • daworl[.]com
  • facosm[.]com
  • faspan[.]com
  • faverse[.]com
  • faworl[.]com
  • flcosm[.]com
  • flfie[.]com
  • flrange[.]com
  • flspac[.]com
  • flspan[.]com
  • flsphe[.]com
  • flspre[.]com
  • flteri[.]com
  • fltory[.]com
  • flval[.]com
  • nimatio[.]com
  • nimcosm[.]com
  • nimfie[.]com
  • nimfin[.]com
  • nimrange[.]com
  • nimrea[.]com
  • nimscap[.]com
  • nimspac[.]com
  • nimsphe[.]com
  • nimspre[.]com
  • nimter[.]com
  • nimteri[.]com
  • nimtop[.]com

最新の脅威に関する詳細につきましては、脅威レポートの最新版をご覧ください。

FortiGuard Labsでは、脅威インテリジェンス情報(英文)を毎週お届けしていますので、ぜひご購読ください。


Fortinet FortiWeb Web Application Firewall

サイバー犯罪者たちが、パブリックWebアプリケーションや社内Webアプリケーションを標的にすることが増えています。データブリーチの半数近くが、Webアプリケーションの脆弱性を標的にした攻撃によって引き起こされています。攻撃から組織を守るためには、Webアプリケーションファイアウォール(WAF)が効果的です。しかし、こうしたデバイスの使用をためらう組織もあります。正規のユーザーやアプリケーションをブロックしないようすばやく誤検知に対処する際に、膨大なリソースが必要とされているからです。


従来のWAFによる脅威検知

ほとんどのWAFソリューションで誤検知が多い主な理由には、振る舞いベースの脅威検知法が中心として使われていることがあります。現在のWAFは、アプリケーション学習(AL: Application Learning)という観測に基づく脅威検知法のみに頼っているからです。

アプリケーション学習(AL)は、ウェブベースアプリケーションの構造と利用パターンに関するプロファイル構築を、自動的に行います。十分な情報を収集したら、ALは監視してきた内容に基づきポリシーを構築します。その後のユーザーアクティビティは、これらの保護ポリシーを守る必要があります。そうでないとアノマリーとして特定され、何らかの対応がトリガーされてしまいます。こうした対応には、ロギングやアラートの発行、検知されたアクティビティのブロックなどがあり、それらが組み合わされることもあります。この検知&レスポンスの方法は、高度な知識を持つハッカーによる既知の脆弱性の利用やゼロデイ攻撃の開始を阻止するうえで効果的です。


アプリケーション学習の限界

第一世代のWAF機能によって、Webアプリケーションの脅威を特定して対処する能力が確かに向上しましたが、正確性については改善の余地があります。WAFソリューションは誤検知が多いため、悪意のない重要なトラフィックをブロックしてしまう可能性があり、多くの企業ではポリシーや例外を管理するために限られたリソースを費やさなければなりませんでした。アノマリーベースのフィルターをトリガーすることなく、正常なアプリケーション利用のあらゆるバリエーションを把握する、もしくはアプリケーションでの変化に容易に適応するための適切な方法がALにはないのです。

根本的な問題は、アプリケーション学習(AL)にあります。ALはもっぱら観測ベースなので、監視してきた内容のみに基づいてアノマリーに対するフラグを立てます。このテクノロジーには、検知したアノマリーが攻撃なのか、悪意のないものかを見分けるのに必要なインテリジェンスが備わっていません。


ALを機械学習に置き換える

FortiWebの新たな機械学習(ML: Machine Learning)テクノロジーは、ウェブセキュリティ市場に今までにない脅威検知のアプローチを提供します。このアプローチでは、観測したアクティビティに対して厳密なマッチングを行うのではなく、統計モデルを用いて脅威を特定します。

ALと同様、MLはユーザーが通常のアプリケーションインタラクションを行う際、各アプリケーションエレメントに関するデータを収集します。しかしALとは異なり、MLは統計モデルを使用して、HTTPリクエストが以前観測したリクエストと大幅に違うかを見極めます。リクエストが「正常」から大きく外れている場合のみ、FortiWeb MLはリクエストがアノマリーであるフラグを立てます。

しかも、このインテリジェントで柔軟性の高いアプローチは、この新たな機械学習機能の2つの層のうちの1つ目にあります。アノマリーが特定されると、今度は2つ目の層の機械学習を使用して、それが脅威なのか、タイプミスか、もしくは未使用の新たな文字や記号か、あるいはアプリケーションへの正当な変更のように無害な差異かを見極めます。その際、検知したアノマリーを学習済みの複数の脅威モデルにかけて、攻撃か否かを判断します。攻撃であれば、ALと同様、ロギング、アラートの発行、アノマリーのブロックなどの対応が可能です。

さらに脅威検知の効率を上げるため、フォーティネットは人工知能(AI)による高度な脅威検出機能をFortiWeb WAFと組み合わせ、様々な脅威モデルを構築しました。モデルは特定の攻撃カテゴリ(SQLインジェクション、クロスサイトスクリプティング、OSコマンドインジェクションなど)に対応しています。これらの脅威モデルは、CVEやExploit DB 、当社のFortiGuard Labsの脅威インテリジェンス、大手サードパーティの脆弱性スキャナーが収集したデータなど、FortiWeb開発チームが様々なソースから得た何千もの実際の攻撃サンプルを使用して、広範に学習したものです。モデルの再学習と試験を必要とするような新たな脅威からリアルタイムに保護するため、これらのモデルは、FortiWebソリューションの一環として含まれており、またFortiGuard WAF Security Serviceの一環として常に更新されています。


正確性の向上とオーバーヘッドの削減

この2段階アプローチを使用することで、MLによる攻撃検知の正確性はほぼ100%まで向上しました。すべてのアノマリーにフラグを立ててブロックする代わりに、FortiWebの新たな機械学習テクノロジーは、アノマリーにフラグを立てて対応する前に脅威か否かをすばやく正確に見極められるため、重要なアプリケーションやトランザクションが遮断されることはありません。こうした高度なFortiWebのMLエンジンは、従来のALベースのWAFソリューションによる誤検知だけでなく、一般的にアプリケーション学習を使用したWAFを回避する攻撃として知られる、「False Negative(検出漏れ)」を大幅に削減します。

アプリケーション環境の安全確保は、ITチーム特有の課題です。先日のIDGによる調査によると、企業のITエグゼクティブの83%が、自社のIT戦略においてアプリケーションのセキュリティが重要だと考えています。現在、WAFの導入を検討している組織の皆さまや、膨大なITリソースを消費する既存のソリューションを替えたいと考えている皆様、そして、すでにFortiWebをご利用いただいているお客様も、是非今回リリースしたFortiWeb 6.0の導入をご検討ください。

FortiWeb 6.0における機械学習

FortiWeb 6.0における機械学習

すでにFortiWebをご利用で、有効なサブスクリプションをお持ちのお客様は、Customer Service & SupportウェブサイトからFortiWebバージョン6.0への無料アップグレードをダウンロードいただけます。Webアプリケーションベースへの攻撃から組織を保護する機械学習の詳細については、FortiWebの製品ページ(英文)をご覧ください。

同製品に関するニュースリリースは、こちらからご覧いただけます。


2016年9月、Hack ForumsでMiraiのソースコードがリークされました。あの重大な出来事以来、IoTデバイスを標的とするマルウェアが爆発的に増え、それぞれに日本のアニメに登場する、超人的な力を持つ主人公の名前が付けられています。FortiGuard Labsでは、お客様に最善の保護を提供するため、これらのIoTボットネットの追跡を行ってきました。

例えばMiraiは、アニメシリーズ「境界の彼方」の主人公、栗山未来から取った名前です。Owariとして知られるマルウェアの名前は、漫画「終わりのセラフ」から取ったものです。最近では5月17日、当社のネットワークテレスコープが、Shinoaという新たな亜種を発見しました。これも同じく「終わりのセラフ」のヒロインの名前です(この名前はマルウェアサンプルに含まれるフォルダの名前から付けられたもの)。

ホスト自体は非常に新しいものです。

Figure 1 Malicious Host

図1. 悪意のあるホスト

VirusTotal(VT)の巧妙なトリックをいくつか使ってみたところ、新たなShinoaマルウェアのソースコードを発見できました。このソースコードはわれわれの好奇心をあおりました。マルウェア作成者の進化と思考をたどる絶好の機会だからです。そこで、ソースコードをさらに深く掘り下げることにしました。「マルウェア亜種の名前には何か意味があるのか」という疑問の答えも見つかるかもしれません。


Shinoaの概要

ソースコードはRar5形式のアーカイブになっており、ハッシュは 499b4c2bc3396a215682d42ba0f2bdf96492e7f45a15129422f9ecd6134bd3b8です。

Figure 2 Shinoa's Source Code

図2. Shinoaのソースコード

すでにMiraiのコードベースはわかっていましたので、Miraiと何らかの関係がある予感がありました。さらに掘り下げてみると、ソースコードを手直しした跡がいくつかありました。いくつかのヘッダーファイルが「shinoa\bot\headers」に移動されていたので、それを元に戻しました。

その後、クリーンなside-by-side形式のdiffを取ることができ、ソースコードを分析できました。

Figure 3 Side by side

図3. side-by-side形式でdiffを取ったところ

ご覧の通り、すべてのデータポイントが非常に類似しており、Miraiの亜種という先ほどの予感が裏付けられました。また、お客様を保護するためにホスト(185.244.25.197)を見つけ出し、ブロックしました。

Figure 4 Configurations

図4. コンフィギュレーション


新たな攻撃手法

次に、攻撃手法を見ていくことにしました。ここでは多くの違いがありそうです。

Figure 5 Attack Methods

図5. 攻撃手法

ご覧の通り、Miraiの元々のソースコードからいくつかの攻撃手法(具体的には「DNS resolver flood」、「TCP stomp flood」、「HTTP flood」)が削除されていますが、同時に新たな2つの攻撃手法「XMAS flood」と「LYNX flood」が追加されています。

Figure 6

図6. 「XMAS flood」と「LYNX flood」

次に、attack_meth.cの新たな攻撃手法の実装を掘り下げてみました。

Figure 7 Implementation of the Attacks

図7. 攻撃の実装

興味深いことに、ShinoaではMiraiの元々の攻撃手法が1つの大きなファイル(attack_meth.c)に統合されていました。しかし、コード自体は変わっていません。

Figure 8 Code in C

図8. Cのコード

次に、「XMAS flood」と「LYNX flood」の実装に焦点を当ててみました。 attack_tcp_xmas()は、計算能力を最大限消費させ、帯域幅を飽和状態にするようすべての選択肢が設定された、昔からある実装形式です。

一方、「LYNX flood」は新しいようです。「コードはデザイン」と昔から言いますから、掘り下げてみることにしました。 すると、attack_tcp_lynx()は、attack_tcp_xmas()とかなり似ていることがわかりました。コードは複雑ですが、簡単に言えば、ヘッダーの2つのフラグ(ATK_OPT_RSTとATK_OPT_FIN)がFALSEに設定されています。

Figure 9 LYNX Flood (left) vs Xmas Flood (right)

図9. LYNX Flood(左)とXmas Flood(右)

上のデータベーステーブルの名前(「miori」)、さらにはMIORI(これもXmasフラッディングを導入している)に驚くほど似ていることから、ShinoaとMIORIが関連していると結論付けることができます。

Figure 10 MIORI

図10. MIORI


Miraiの亜種は一体何なのか

数多くのMiraiの亜種のリバースエンジニアリングを行うなか、「スクリプトキディが再び活動しているのでは」という考えが、しばしば頭をよぎりました。そしてリークされたShinoaのソースコードを見て、考えが裏付けられました。

例えば、以下のビルドスクリプトをご覧ください。メインロジックが基本的にMiraiと同じであることがわかります。Shinoaの作成者は、デバッグバイナリをビルドするコードを削除しただけです。

Figure 11 Build Script

図11. ビルドスクリプト

他の多くのケースでは、コードはほとんど同じで、一般的なヘッダーをheaders\'に移動するなど、少々手直しを行った程度です。

Figure 12 Minimal changes

図12. 最小限の変更

FortiGuard Labsのチームは、Kill All IoT Botnets(KAIB)と呼ばれる社内プロトタイプを保有しており、これが新たなMirai亜種の追跡、ダウンロードを行っています。

Figure 13 Kill All IoT Botnets

図13. Kill All IoT Botnets

ご覧の通り、時とともに数多くの亜種が登場してきています。ソースコードの「質が高い」ことを踏まえると、スクリプトキディたちは容易に新たな亜種を作り出せるのでしょう。2016年9月にMiraiのコードが公表されて以来、その派生物が増加していることからも明らかです。幸いにも、フォーティネットのお客様は常に、FortiGuard Antivirusのシグネチャで、あらゆる新しい亜種から保護されています。


まとめ

Miraiのコードがオンライン上で公表されて以来、多くがその改変を試みてきました。その結果、多くの亜種が登場しています。単純な改変(新たな認証情報を追加しただけのものなど)から、感染させたIoTデバイスを、マルウェアのプロキシクリプトマイナーに変えるような高度なものまで、様々です。こうした動向を踏まえると、今後も亜種は増え続けるでしょう。

FortiGuard Labsでは今後もIoTの脅威ランドスケープを監視し、皆様に鋭い調査内容をお伝えしていきます。

追加分析を行い、意見を提供してくれた同僚のDavid Maciejakに感謝します。

-= FortiGuard Lion Team =-


ソリューション

フォーティネットのユーザーは、以下のソリューションでMiraiの亜種から保護されています。

  • FortiGuard Antivirusでファイルを検知
  • FortiGuard Web Filtering Serviceで悪意のあるダウンロードURLやC2をブロック

IOC

ソースコード: 499b4c2bc3396a215682d42ba0f2bdf96492e7f45a15129422f9ecd6134bd3b8
FortiGuard Web Filtering ServiceはShinoaのCCとホスティングサーバーにも対応
91.229.20.98 - Malicious
185.244.25.197 - Malicious


VPNFilterというボットネットが新たに報告されました。SCADA/ICS 環境を標的として、MODBUS SCADAプロトコルを監視し、ウェブサイトの認証情報を盗み出すもので、500,000台以上のルーターやネットワーク接続サーバーがすでに感染しています。また、標的とした単一のデバイスを使えない状態にするだけでなく、大規模な攻撃で感染させたすべてのデバイスも同時に使えない状態にできる、「ブリッキング(Bricking: レンガ化)」コンポーネントも含まれています。

先日、CiscoのTalos脅威リサーチチームから Cyber Threat Alliance(CTA)のメンバーに連絡があり、発見が報告されました。今回のように、責任を持って脅威インテリジェンスへの「早期警告」を行い、他の主要セキュリティリサーチャーたちと情報を共有することこそ、CTAが立ち上げられた理由です。これにより、脅威の詳細が公開される前に、参加するセキュリティベンダーが新たなリスクを把握し、必要な対応を取ることができます。また、フォーティネットなどのメンバーが、追加の詳細やコンテクストを見つけ出し、共有することも可能になります。

当初の調査では、VPNFilterはおそらく、国家の関与が疑われる高度なモジュール式のマルウェアシステムであり、主に家庭用ルーターやスモールビジネス向けルーター、NAS(Network-attached storage)を広範囲にわたり感染させたことが判明しています。今回のキャンペーンのアクティビティは当初、ウクライナの特殊な標的型攻撃で見られましたが、100か国以上において、デバイスがポート23、80、2000、8080でスキャンされていることがデータから判明し、脆弱なMikrotikデバイスやQNAP NASデバイスのスキャンもさらに行われると考えられます。


VPNFilterは3つのステージで展開

ステージ1では執拗さと冗長性が重視されており、再起動しても執拗に生き残ります。

ステージ2にはデータの窃取、ファイルの収集、デバイスの管理、そしてバージョンによっては自己破壊モジュールが含まれます。

ステージ3は様々なタスクを実行するモジュールで構成されています。現在、3つのモジュールが特定されていますが、他にも存在する可能性があります。これまでに判明しているモジュールは以下の通りです。

  1. トラフィックの分析とデータ窃取を行う可能性があるパケットスニッファー
  2. MODBUS SCADAプロトコルの監視
  3. 難読化したアドレスでTOR経由の通信

しかし、今回の攻撃における最大の脅威は、一挙に感染させられた全デバイスにおける自己破壊モードです。現在、どの程度のデバイスが侵害を受けたのかについて追加情報がないのですが、こうした機能がトリガーされることで、標的とする地域で広範囲にわたりインターネットの機能停止が起こる可能性があります。


脅威の緩和

侵害を受けた様々なIoTデバイスから防御することは、非常に困難です。こうしたデバイス、特に家庭用、スモールビジネス用の装置の多くは何のセキュリティも配備されず、直接インターネットに接続しているからです。つまり、デバイスのメーカーそれぞれがアップデートを提供する必要があるのですが、攻撃者たちはそれを追跡し、適応していくことができます。

このマルウェアの重大さから、FortiGuard Labsは影響を受ける可能性があるデバイスの更新をできるだけ速やかに行い、パッチが提供されていない場合は、影響を受けたデバイスを交換するなどの措置を取ることを推奨しています。

また、Talosでは以下の事項を推奨しています。

  • 破滅型、非永続型と考えられるステージ2、ステージ3のマルウェアを排除するため、SOHO向けルーターやNASデバイスの再起動を実施してください。影響を受けたSOHO向けルーターをユーザーに提供するインターネットサービスプロバイダーは、顧客に代わってルーターの再起動を行ってください。
  • この脅威に影響受けたことが判明しているデバイス、影響が疑われるデバイスを保有している場合には、メーカーと協力し、最新のパッチを適用してデバイスを最新の状態に保つことが重要です。まだ対処を行っていない場合は、速やかに最新のパッチを適用してください。
  • ISPは、デバイスのファームウェアやソフトウェアのバージョンを最新のものにするため、顧客と積極的に協力していくことが必要です。

FortiGateによるAVおよびIPS

既知のサンプルに関しては、Elf/Agent.1731!trとしてアンチウイルスの対応を行っています。

FortiGuardウェブフィルタリング:

Cyber Threat Alliance でのパートナーシップを通して最初のレポートを受け取っているため、Talosが指摘するURLはすべてブラックリストに登録済です。

IOC:

CTAのメンバーシップの一環として、この新たな脅威の公表前に私たちはサンプルおよびIOCを受け取りました。

ステージ1と関連するURI

photobucket[.]com/user/nikkireed11/library
photobucket[.]com/user/kmila302/library
photobucket[.]com/user/lisabraun87/library
photobucket[.]com/user/eva_green1/library
photobucket[.]com/user/monicabelci4/library
photobucket[.]com/user/katyperry45/library
photobucket[.]com/user/saragray1/library
photobucket[.]com/user/millerfred/library
photobucket[.]com/user/jeniferaniston1/library
photobucket[.]com/user/amandaseyfried1/library
photobucket[.]com/user/suwe8/library
photobucket[.]com/user/bob7301/library
toknowall[.]com

ステージ2と関連するURI

91.121.109[.]209
217.12.202[.]40
94.242.222[.]68
82.118.242[.]124
46.151.209[.]33
217.79.179[.]14
95.211.198[.]231
195.154.180[.]60
5.149.250[.]54
91.200.13[.]76
94.185.80[.]82
62.210.180[.]229
91.200.13[.]76
91.214.203[.]144
6b57dcnonk2edf5a[.]onion/bin32/update.php
tljmmy4vmkqbdof4[.]onion/bin32/update.php
zuh3vcyskd4gipkm[.]onion/bin32/update.php
6b57dcnonk2edf5a[.]onion/bin32/update.php

ファイルハッシュ

ステージ1のマルウェア

50ac4fcd3fbc8abcaa766449841b3a0a684b3e217fc40935f1ac22c34c58a9ec
0e0094d9bd396a6594da8e21911a3982cd737b445f591581560d766755097d92

ステージ2のマルウェア

9683b04123d7e9fe4c8c26c69b09c2233f7e1440f828837422ce330040782d17
d6097e942dd0fdc1fb28ec1814780e6ecc169ec6d24f9954e71954eedbc4c70e
4b03288e9e44d214426a02327223b5e516b1ea29ce72fa25a2fcef9aa65c4b0b
9eb6c779dbad1b717caa462d8e040852759436ed79cc2172692339bc62432387
37e29b0ea7a9b97597385a12f525e13c3a7d02ba4161a6946f2a7d978cc045b4
776cb9a7a9f5afbaffdd4dbd052c6420030b2c7c3058c1455e0a79df0e6f7a1d
8a20dc9538d639623878a3d3d18d88da8b635ea52e5e2d0c2cce4a8c5a703db1
0649fda8888d701eb2f91e6e0a05a2e2be714f564497c44a3813082ef8ff250b

ステージ3のプラグイン

f8286e29faa67ec765ae0244862f6b7914fcdde10423f96595cb84ad5cc6b344
afd281639e26a717aead65b1886f98d6d6c258736016023b4e59de30b7348719


最新のIoTボットネットを追い続けるなかで、FortiGuard LabsチームはMiraiの亜種の増加を観測してきました。このマルウェアのソースコードは2年前に公開されており、それ以来、脅威アクターたちは元のレシピに独自のフレーバーを加えてきたというわけです。

感染したデバイスを、マルウェアのプロキシクリプトマイナーの大群に変える機能を追加するなど、大幅な修正を行った者もいます。現在WICKEDと呼ばれる、FortiGuard Labsが先日発見した新たな亜種のように、既知、未知の脆弱性の両方を標的とする複数のエクスプロイトと、Miraiのコードを統合させた者もいます。

この新亜種には少なくとも3つのエクスプロイトが追加されており、未パッチのIoTデバイスを標的とします。今回の記事では、その仕組み、このボットの主な目的、その他の既知のボットネットとの関係性を見ていきましょう。


ボット内部

Miraiとこの新たな亜種の違いをざっと見ていくためには、コンフィギュレーションテーブルを見る必要があります。これは鍵0x37を持つXORで復号できます。

/bin/busybox WICKEDWICKED: applet not foundなど、いくつか興味深い文字列が含まれています。亜種の名前はここに由来しています。さらに、SoraLOADER という文字列は、このボットがMiraiの亜種であるSoraボットネットのダウンローダーやスプレッダーとして機能していることの手掛かりかもしれません。しかし分析を進めると、そうではないことが判明しました。そして、さらに興味深い仮説にたどり着きました。

Fig 1. Decrypted configuration table

図1. 復号したコンフィギュレーションテーブル

Miraiをベースとしたボットネットには通常、Attack、Killer、Scannerという3つの主なモジュールが含まれています。今回の分析では、ボットネットの拡散メカニズムが含まれるScannerのモジュールのみを取り上げます。元のMirai はIoTデバイスにアクセスするため、従来の総当たり攻撃を使っていました。一方、WICKEDボットは既知かつ現在利用できるエクスプロイトを使用します。その多くはすでにかなり古いものです。

WickedボットはrawソケットSYN接続を開始して、ポート8080、8443、80、81のスキャンを行います。

Fig 2. Socket file descriptor

図2. ソケットファイル記述子

接続が確立されると、デバイスの脆弱性を突き、ペイロードのダウンロードを試みます。その際、システムコールwrite() を使ってソケットにエクスプロイトの文字列を書き込みます。システムコールwrite() は、ゼロに設定されたflags引数(余分な動作は何もなしということ)の入ったシステムコール send() を呼び出すのと同じです。

Fig 3. Sending a request by writing to a socket

図3. ソケットに書き込みを行い、リクエストを送信


Wickedが標的とするデバイス

使用されるエクスプロイトは、ボットが接続に成功したポートによって異なります。エクスプロイトおよびそれが標的とするポートは以下の通りです。

ポート8080: Netgear DGN1000 およびDGN2200 v1 ルーター(Reaperボットネットも使用)

Fig 4. Netgear exploit

図4. Netgearエクスプロイト

ポート81: CCTV-DVR Remote Code Execution(遠隔でのコード実行)

Fig 5. CCTV-DVR RCE exploit

図5. CCTV-DVR RCEエクスプロイト

ポート8443: Netgear R7000およびR6400コマンドインジェクション (CVE-2016-6277)

Fig 6. CVE-2016-6277 exploit

図6. CVE-2016-6277エクスプロイト

ポート80: 侵害したウェブサーバーから呼び出されるシェル

以下は直接デバイスの脆弱性を突くことはしませんが、すでに侵害を受け、悪意のあるウェブシェルがインストールされたウェブサーバーを利用します。

Fig 7. Invoke shell

図7. シェルを呼び出す

このボットは脆弱性の利用に成功すると、悪意のあるウェブサイト、今回のケースではhxxp://185.246.152.173/exploit/owari.{拡張子}からペイロードをダウンロードします。このことから、このボットの目的は先ほど述べたSoraボットではなく、Miraiの別の亜種、Owariボットのダウンロードであることが明らかとなりました。しかし、分析の時点ではすでに、Owariボットのサンプルを、ウェブサイトのディレクトリに見つけることはできませんでした。また、以下のサンプルに差し替えられていることが判明し、これらは後々、Omniボットであることがわかっています。

Fig 8. Exploit repository of Omni botnet

図8. Omniボットネットのエクスプロイトレポジトリ

この悪意のあるウェブサイトの履歴を念のためチェックしてみたところ、過去にOwariボットを配信していたことが確認できました。

このウェブサイトの /binsディレクトリのファジングを実行してみると、ディレクトリに他のOmniサンプルがありました。これはGPON脆弱性(CVE-2018-10561)を使って配信されたことが報告されています。タイムスタンプから、ペイロードが定期的に更新されていることがわかります。

Fig 9. Bins repository of Omni botnet

図9. Ombiボットネットのbinsレポジトリ


点と点を線でつなぐ

Wicked、Sora、Owari、Omniボットネットのつながりを見つけたことで、これらのボットネット亜種の作成者と想定されるセキュリティリサーチャーに対して、4月に行われたインタビューにたどり着きました。「Wicked」というハンドルネームを使用している作成者は、SoraとOwariの作成者であることを認めています。SoraとOwariの今後について尋ねられると、Wicketは「SORAは現在すでに中止したプロジェクトで、今後はOWARIを継続していく。自分は現在のプロジェクトを拡張していくので、第三のプロジェクトは立ち上げない」と答えています。

/binsレポジトリを見る限り、SoraとOwariのボットネットサンプルはすでに廃止され、Omniに差し替えられています。


結論

同じホスト上に複数のボットネットがホストされていることに関しては、先述の作成者がインタビューで答えた内容に基づけば、原則的にWicked、Sora、Owari、Omniの作成者は1人であり、同一人物であるということになります。つまり、WICKEDボットはもともと、Soraボットネットを配信する目的で作られたものが、作成者のその後のプロジェクトに使われるようになった、と結論づけることができます。

FortiGuard Labsでは今後もIoTの脅威ランドスケープの進展を監視し、IoTデバイスを感染させるために新たなエクスプロイトの追加を行うボットネットを追跡していきます。

追加分析を行い、意見を提供してくれた同僚、David Maciejak、Joie Salvio、Jasper Manuel、Tony Loiに感謝します。

-= FortiGuard Lion Team =-


上記の攻撃は以下のIPSシグネチャで対処を行っています。

  • NETGEAR.DGN1000.CGI.Unauthenticated.Remote.Code.Execution NETGEAR.DGN1000B.Setup.CGI.Remote.Command.Execution
  • NETGEAR.WebServer.Module.Command.Injection
  • Multiple.CCTV.DVR.Vendors.Remote.Code.Execution

IOC

Sha256:

  • ELF/Mirai.AT!tr
  • 57477e24a7e30d2863aca017afde50a2e2421ebb794dfe5335d93cfe2b5f7252 (Wicked)

ダウンロードサイト:

  • hxxp://185.246.152.173/bins/
  • hxxp://185.246.152.173/exploit/