ここ数日ホンダがサイバー攻撃を受けたというニュースが世界各国で報じられています。

本記事では、一部で関連性が指摘されているVirusTotalにアップロードされたSNAKEランサムウェアの検体(※)について解析を行い、現時点までに判明した内容を簡単ですが共有します。海外ではすでにいくらか情報は出ているものの、日本語での解析記事はあまりないと思われるため何かの参考になれば幸いです。

※ハッシュ値：d4da69e424241c291c173c8b3756639c654432706e7def5025a649730868c4a1

なお弊社では、本検体がホンダに対するサイバー攻撃と関連があるかどうかは把握しておらず、本記事はあくまで上記ハッシュ値の検体の解析結果に終始している点をご了承ください。

■検体調査

まず、当該検体は以下の通り、日本国内から6/8頃にVirusTotalにアップロードされています。

SNAKEランサムウェアは別名EKANS（SNAKEの逆さ読みになっている）とも呼ばれ、2019年12月に出現した新しいランサムウェアです。

SNAKE本体は１０年程前にgoogleが開発した比較的新しいオープンソース開発言語であるGO言語で開発され、EXE形式にコンパイルされています。GO言語で作成されている背景の一つに、マルチプラットフォームで開発できるという点が開発者側のメリットとして考えられます。

以下の図はマルウェア内部の文字列を確認した様子ですが、GO言語で開発されたことを示すソースコードのファイル名と、Admin3というアカウント名を持つ攻撃者がWindows環境で開発したということを知ることができます。

（補足情報）GO言語で開発されたPEファイルはTime Date Stampが0x0に設定されるため、コンパイル日時が1970/1/1固定となります。

SNAKEは起動されると、”EKANS”というミューテックスをシステムに登録します。
これにより、すでにSNAKEが動作中の環境では他のEKANSの検体が起動しないようになり、意図せず被害端末へSNAKEが多重感染しないようにしています。

次に、今回のSNAKEの個体に特に特徴的な挙動として、以下の特定ドメインの名前解決が行えるかどうかをチェックします。

• MDS[.]HONDA[.]COM

さらに、上記のドメインに対する名前解決が以下のIPアドレスと等しくなるかどうかを確認し、等しくない場合は動作を終了、等しい場合は動作を継続します。

• 170[.]108[.]71[.]15

つまり、今回の個体は、上記ドメインの名前解決結果が特定のIPアドレスになる環境でのみ感染するように特別に作り込まれたランサムウェアであると言えます。
これまでのブログでもお伝えしている通り、近年の標的型ランサムウェアはターゲットに合わせて挙動を作り変える傾向があるため、一見同じ種類のランサムウェアであっても、このように検体により動きが異なることが少なくありません。

なお、調査時点において、170[.]108[.]71[.]15は以下のホスト名として逆引きできます。

• unspec170108[.]amerhonda[.]com
(Organization: American Honda Motor Company, Inc. (AHMC-Z))

このあたりに関する挙動を少し踏み込んで解説します。

まず、以下は該当ドメインの名前解決ができない環境でSNAKEを動かした場合の挙動の様子です。
（以下の画面では上から下へ時系列にSNAKEの挙動が並んでいます）

赤枠で囲っている部分が該当ドメインの名前解決を行う処理ですが、名前解決ができない環境では、GetAddrInfoWの呼び出しにエラーが応答され名前解決が失敗し、SNAKEはその後の挙動をやめて終了します。つまり、MDS[.]HONDA[.]COMの名前解決ができないPCでは動作しないことを意味します。

一方で、MDS[.]HONDA[.]COMの名前解決に対し170[.]108[.]71[.]15が応答されるよう偽装した環境でSNAKEを動作させると、以下のように成功（=ERROR_SUCCESS）の応答が返り、SNAKEはその後の動作を継続します。
つまり、MDS[.]HONDA[.]COMの名前解決に対し170[.]108[.]71[.]15が応答される特定環境でしか、このランサムウェアは動作しないように作られていることがわかります。

こうした手口により、SNAKEが期待する名前解決が行えない自動解析環境や即席の調査環境などでは本検体の挙動を把握することができなくなり、効果的な解析/調査妨害の一つといえます。

■名前解決ができる環境での動作

SNAKEが動作して良い環境（つまり上記の名前解決が成功する環境）であることを認識すると、続いてWindowsファイアウォールの設定を変更します。
具体的には、netsh.exe（Windowsに初めからあるネットワーク設定を行うツール）に、以下のコマンドラインを渡して実行します。

netsh advfirewall set allprofiles firewallpolicy blockinbound,blockoutbound

これにより、全てのプロファイルに対し、受信規則および送信規則に一致しない送受信接続をWindowsファイアウォールの機能を用いて全てブロックします。

続いて、同じくnetsh.exeへ以下のコマンドを渡すことで、設定したファイアウォールを有効にします。

netsh advfirewall set allprofiles state on

この結果、ファイアウォールの既存規則に一致しない通信が全てブロックされるようになり、多くのアプリケーションが通信不可能になります。暗号化中に正規のWindowsファイアウォールを利用してネットワーク通信を妨害するこの仕組みは、他のランサムウェアにはあまり見られない特徴といえます。

次に、システムやセキュリティ系などの複数のサービスを停止させる処理を試みます。

さらに、暗号化や復旧活動の邪魔になるような複数の正規プロセスを一斉に強制終了していきます。

■暗号化処理

それらが終わると、ランサムウェアのメインの処理となるファイルの暗号化が開始されます。
ファイルの暗号化はシステムで使用可能な全てのドライブを取得し、ドライブの先頭から順番に暗号化していきます。
以下の画像は暗号化処理の始まりの挙動の様子であり、Cドライブの先頭に見つかったRecycle.Bin(ゴミ箱のフォルダ)の中のファイルを暗号化するために検索していることがわかります。その後、順番に端末の各フォルダの中に含まれるアクセス可能なファイルを次々と暗号化していきます。

暗号化対象とするファイルの拡張子(一部)は以下のようなものが予め用意されています。

SNAKEは、MegaCortexやLockerGogaなどのように複数プロセスで暗号化を分担するような処理は行わず、単一のプロセスで暗号化を行います。

暗号化の過程では、以下のようなシステム系のファイルやWindowsフォルダなど一部のシステムフォルダの中身は暗号化の対象から除外しており、SNAKEに感染してもWindowsは動作できる状態が保たれます。ただし、上で述べた通り様々なサービスやプロセスが停止され、EXEファイルを含む多くのプログラムも暗号化されるため、本検体に感染した端末のシステムは全体的に不安定となります。

一般的なランサムウェアは暗号化したファイルの拡張子を特定の文字列 (例えば.lockedなど)に変更または追加することが多いですが、SNAKEによって暗号化されるファイルは全て、ランダムな文字列が元の拡張子の末尾に追加されます。

SNAKEにより暗号化されたファイルの末尾には、暗号化前のファイル名やRSA公開鍵により暗号化されたAESキーなどを含むフッダーが追加され、さらにSNAKEによって暗号化されたことを示す”EKANS”マーカーが最後尾の５バイトに追加されます。

これにより、暗号化されたファイルの末尾は以下のような構造になり、ファイルの末尾５バイトを確認することでSNAKEに暗号化されたファイルであるかどうかの判断ができます。

なお、ランサムウェア内に含まれているRSA公開鍵は以下となります。

-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEAt1GCKUHXITsiWc1d8V0vo1Y9Jm18RDZEmMS6OkHI7pZT0RHAThlR
BFITZY9bXrl6RFdUwmIX0WYn5ZqIlhLAEe1cqd8RpJ/KK2OeiTn0CJ1CGmOOJvfm
5rFa8whVAU9cnh/iVCcf+aEHJVcHhzB5tTtiT3lBIdfzaLL6GR5EmytbQ3V3O1Uk
Y4FCKxYOMVoPzPtRG3vo3688uUWpZIKBV7e6dht/mAhuCEIlRGcdpAEf6f4zUUYf
dtHcDafMVEA4Sy/DDsd76wAyBIM0XKLv1+vH476TN1K1tIRBrR98QFl5mlXkgqz6
h+Wpb/5KYWWvG0ZLZcu6eWOCGmLEmorvWQIDAQAB
-----END RSA PUBLIC KEY-----

暗号化の際のファイル操作は以下の流れで実装されています。GO言語で開発されている場合でも、WindowsAPIの観点で見ればWriteFileとReadFileによる標準的なランサムウェアに見られるファイル操作が最終的にコールされていることがわかります。

なお、SNAKEは、一般的なランサムウェアによく見られるような、一ファイルずつファイルを暗号化→拡張子変更の流れをとるのではなく、全てのファイルに対する暗号化を（拡張子を変更しない状態で）一通り実施した後に、最後にまとめてファイルの拡張子だけを変更していきます。この手法による効果としては、ランサムウェアによる暗号化が行われている最中に拡張子が変更されないため、暗号化されていることを途中でユーザーに気付かれにくいという点と、リネーム処理を一箇所でまとめて行うことで正規のリネーム処理の挙動と類似性が生まれることから、ランサムウェアに特有の動き（一ファイルずつファイルを暗号化→拡張子変更の流れ）をチェックするような挙動検知などに対する検知逃れの効果などが考えられます。

SNAKEは暗号化が全て終わると、以下のコマンドでファイアウォールを全て無効にします。

netsh advfirewall set allprofiles state off

つまりSNAKEは、ファイルの暗号化前にWindowsファイアウォールでネットワーク通信の送受信をブロックするように設定することで、ファイルの暗号化の最中に復旧活動や監視をネットワーク越しで行えないようにしつつ、ファイルの暗号化が終えた後に、それらのブロックを解くという一連の挙動を行なっています。

■ドメインコントローラにおける特別な挙動

本検体に特徴的な点として、実行された環境がドメインコントローラであると判断した場合、特別な挙動を行う事が挙げられます。

一般的なランサムウェアは感染した環境であれば基本的に併せて脅迫文を作成するものですが、今回のSNAKEはユーザー端末やサーバーに感染した場合、ファイルの暗号化は行うものの、脅迫文を一切作成しません。

しかし一方で、感染した環境がドメインコントローラであると判断した場合、ファイルの暗号化は一切行わず、代わりに脅迫文をPublicのデスクトップ（およびC:¥直下）に作成します。

■ドメインコントローラで挙動を変える仕組み

ここでは、上記で述べたドメインコントローラで挙動を変化させる仕組みを少し踏み込んで解説します。

まずSNAKEは、WMIのクエリを利用して、ドメインロールという値を参照します。

ドメインロールの値は以下の数値で定義されており、ドメインコントローラではドメインロールの値が“４”または”5”となります。

SNAKEはドメインロールが「３以下であるか」をチェックし、3以下である場合はファイルを暗号化しますが脅迫文は作成しません。一方で、「3以下でない場合」は、ファイルを暗号化せず、脅迫文を作成します。
以下は例として、ドメインコントローラ以外のサーバ（StandaloneServer）とドメインコントローラ（Primary domain controller）の環境におけるSNAKEの挙動を比較した様子です。

以下は、SNAKEがドメインロールの値により、挙動を分岐させる処理となります。

ドメインコントローラと判断した場合、Publicのデスクトップのパスを取得します。

その後、以下のようにメモリに脅迫文を展開し、上記で取得したPublicのデスクトップへテキストファイルとして出力します。

これ以外の挙動として、横展開やファイル窃取の動きは特に現時点で確認していません。

途中で行うnetshによるWindowsファイアウォールの操作は管理者権限/システム権限が必要であり、SNAKEがユーザー権限で実行された際に権限昇格を要求する挙動も存在しないため、本検体ははじめから管理者権限/システム権限で実行されることを前提にして開発されている可能性があります。

また、ランサムウェアはその性質から、連絡先を記載した脅迫文をターゲットに見せることが最も重要な位置づけの一つとなりますが、本検体においてはユーザー端末や一般サーバーに感染した場合は脅迫文を作成しないため、そのままでは脅迫して金銭を得るというランサムウェアとしての目的が達成できません（破壊目的を持つワイパーでない限り）。
その点を考慮すると、ドメインコントローラでのみ脅迫文を作成しシステム管理者へ脅迫文を見せるというこの効果的な挙動は、あらかじめドメインコントローラへ侵入できる前提で開発されていることを示唆します。

加えてそうした状況から、本検体の一般ユーザー端末への感染経路としては、ユーザーのダブルクリックなどではなく、 ドメインコントローラ等を経由した管理者権限/システム権限による各端末への配布という経路が可能性の一つとして考えられます。

以上で述べた解析結果により、本検体に感染した端末には以下の症状が発生することがわかります。

■まとめ

冒頭で述べたように、弊社では本検体以外の情報は持ち得ていないため、本検体がホンダのサイバー攻撃で実際に使用されたものかの確証はありません。事実として言えるのは、今回解析した検体が、特定のドメイン（MDS[.]HONDA[.]COM）に対し、特定のIPアドレス（170[.]108[.]71[.]15）ヘ名前解決できる環境下の端末でしか動作しないように開発されているということです。

これまでのブログ記事でも言及してきたとおり、近年の標的型ランサムウェアは攻撃対象組織に合わせ挙動をチューニングした上で送り込んでくる傾向があります。一般的な標的型ランサムウェアの侵入経路としては、RDPやVNCなどを狙った侵入経路が狙われる場合があるため、今一度不必要なRDP等のサービスがインターネット側に公開されていないかなどを重点的に確かめることをお勧めします。