- 2018/12/07
- サイバー攻撃
依然活発な活動を続ける、EternalBlueの脆弱性を狙ったWannaMineクリプトマイナー
Post by : CYBEREASON NOCTURNUS RESEARCH
Team Nocturnusは、新たに発生したWannamineという脅威についての調査を行いました。この攻撃は昨年、NSAが明らかにしたEternalBlueという脆弱性を狙った攻撃をベースとしています。この脆弱性攻撃は昨年発生したWannaCry攻撃やNotPetya攻撃に利用されているため、記憶にある方もいらっしゃるのではないでしょうか。
WannamineはEternalBlueのパッチが適用されていないSMBサービスを介してコンピューターシステムに侵入すると、高い権限でコードを実行する能力を獲得してネットワーク全体に拡散し、可能な限り多くのマシンで持続的かつ自由にコードを実行します。
そもそも、WannaMineはもはや目新しい脅威ではありません。すでにほかの研究者たちがWannaMineついてレポートを発表しており、さまざまなテクノロジーニュースの記事がこの件を扱っています。そして、WannaMineが新しい脅威でないという点こそが問題の一端であり、この調査レポートを公開した理由もそこにあります。
EternalBlueの脆弱性は誰もがよく知っているのです。また、この攻撃を防ぐ方法も広く知られています。Microsoftが2017年3月に公開したパッチを適用すればよいのです。しかし企業は、EternalBlueの脆弱性を悪用した脅威に依然として直面しています。組織がコンピューターにパッチを適用しコンピューターをアップデートしようとしているあいだにも、攻撃者は執拗にこの脆弱性を狙った攻撃を仕掛けてきます。
理由はいたってシンプルです。攻撃の成功する確率が高いからです。セキュリティを強化する措置を取れば、防御する側が有利になり、攻撃者の活動を難しくします。脆弱性パッチの適用、それもEternalBlueのパッチ適用の場合は特に、これが当てはまります。
さて、パッチの件はひとまず置いて、最近発生したWannamineのケースに関してテクニカルな面の詳細を確認していきましょう。
初回の攻撃は、昨年の5月に発生したWannaCry攻撃の場合と同様に、EternalBlueのパッチが適用されていないSMBサーバーのこの脆弱性を突いて行われています。コードが実行されるとすぐに、PowerShellのインスタンスが拡散します。
Get-WmiObject コマンドレットに関する留意事項::攻撃者は、標的のマシンが32ビットのマシンであるのか64ビットのマシンであるのか、その情報を列挙するためにWMIを使用しています。列挙が完了すると、個々のマシンに合わせて、32ビットのマシンの場合にはin3.ps1のペイロードが、また、64ビットのマシンではin6.ps1のペイロードがそれぞれダウンロードされ、実行されます。
ダウンロードされたペイロードは非常大きなテキストファイルでした。その大半はBase64でエンコードされており、また、ここでは、別のテキストエンコーディングの手法や難読化の手法なども使われています。実際のところ、ダウンロードしたペイロードは難読化の処理が施されているためにあまりにも巨大であり、大半のテキストエディターではこれを開こうとしてもハングしてしまい、また、対話形式のIPythonセッションにBase64の文字列全部をロードすることも全く不可能でした。
難読化の処理を解除すると、さらに別のPowerShellコードが現れました。そして、PowerShellのコードの内容を解析したところ、その目的がいとも簡単に明らかになりました。WannaMineはネットワーク上でラテラルムーブメントを行うためにWMIやPowerShellを大規模に使用していたのです。
平文のASCII文字列で書かれたPowerShellコードに加え、大量のテキストのなかには、不明な文字列やいくつかのバイナリBLOBも含まれていました(これは、ファイル内のすべてのデータを単純にBase64でデコードしたことによるものです)。
このバイナリBLOBは実際には難読化が施されたほかのテキストと同様に、.NET DLLファイルをコンパイルする目的で.NETコンパイラを実行するコードでありコマンドです。
重要なポイント:DLLには、コンパイルの処理ごとに別々の名前がランダムに付けられます。
このDLLを.NETのディスアセンブラにロードしたところ、これがPingCastleスキャナーであることがはっきりとわかりました。PingCastleスキャナーについては、WannaMineに関する過去のレポートにも記述があります。PingCastleの役目は、まず、ネットワークをマッピングすることにあります。そして、SMBサーバーが送信する応答パケットからSMBの情報を傍受し、次に狙うマシンにたどり着くための最短のルートを見つけ出すのです。
PingCastleが実行されているあいだには、PowerShell Mimikatzの実装など、メインのPowerShellスクリプトの別の処理が同時に行われています。興味深いことに、PowerShellスクリプトのコードの大半は、さまざまなGitHubリポジトリの内容をそのままコピーしたものでした。
たとえば、PowerShell Mimikatzの実装は、以下のように、invoke-mimikatzリポジトリから直接行われます。:
投下されたPowerShellスクリプトから実装されたPowerShell Mimikatzコード
オリジナルのGitHubリポジトリから実装されたPowerShell Mimikatzコード
投下されたPowerShellスクリプトから実装されたPowerShell Mimikatzコード
オリジナルのGitHubリポジトリから実装されたPowerShell Mimikatzコード
このPowerShellスクリプトでは、感染先のマシンにマイナーを投下する直前に、マシンの電力管理設定の変更も行います。その目的はマシンがスリープ状態になるのを防ぎ、マイニングのパワーを最大限に利用することにあります。
マシンの電力管理の設定が再構成されると、数百に上るpowershell.exeプロセスが確認されるようになり、この結果、CPUのサイクルが大幅に増加し、またこれらのプロセスとマイニングプールサーバーとの通信も始まりました。
この結果わかったことがあります。クリプトマイナーは実際にはPowerShell内で実行されていたのです。ただし、実行されたPowerShellのコマンドラインを見ても、クリプトマイニングを示す挙動は何も確認できません。
“C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe” -NoP -NonI -W Hidden “$mon = ([WmiClass] ‘root\default:systemcore_Updater’).Properties[‘mon’].Value;$funs = ([WmiClass] ‘root\default:systemcore_Updater’).Properties[‘funs’].Value ;iex ([System.Text.Encoding]::ASCII.GetString([System.Convert]::FromBase64String($funs)));Invoke-Command -ScriptBlock $RemoteScriptBlock -ArgumentList @($mon, $mon, ‘Void’, 0, ”, ”)”
コマンドラインを確認すると、root\default:systemcore_UpdaterというWMIのクラスに対してアクセスが行われていることがわかります。このクラスは、Wannamineマルウェアのバージョンを、現在インストールされているバージョンに維持します。
また、攻撃の持続性を維持するために、マルウェアは、WMIのフィルタやコンシューマー、バインダーをインストールし、組み込みのWMIイベントを通じて持続的な処理の実行を実現しています。
組織全体を対象としてWMIパーシステントオブジェクトを照会
組織全体でWMIパーシステントオブジェクトについて確認してみると、このオブジェクトに関連したWMI Autorunが多くのマシンに存在することがわかりました。そして、consumer action(組み込みのWMIイベントが使用、処理された場合に行うアクションを定義)について調べてみると、ここでも、Base64でエンコードされたデータのBLOBが確認されました。
これをデコードした結果、約120行のPowerShellコードが得られています。次にこの内容で注目すべきポイントを示します。
このブロックでは、root\default:Office_Updater WMIクラスからBase64形式で関数を抽出し、この関数をデコードします。デコードが完了すると、スクリプトは関数(iex $defun)を呼び出してコマンドを実行します。
次にスクリプトは別にFilterToConsumerBindersを探し、これを見つけて削除します。
重要なポイント:さらにスクリプトは、IPアドレスが3333、5555、7777のポートに接続している全プロセスのリスト化を試み、アクティブなプロセスがあった場合には、そのプロセスをターミネートします。この攻撃のほかのバリアントが3333や5555、7777のような標準のポートでマイニングプールに接続するのに対し、ここで取り上げたWannamineのバリアントはポート14444でマイニングプールと接続します。このマシンのほかのいずれかのプロセスが標準ポートのマイニングプールに接続している場合には、それらのプロセスはターミネートされます。
このプロセスが完了すると今度は、WMIクラスに格納されているデータからさらに値を抽出する処理が行われます。この内容を以下に示します。
画面に示すコマンドは変数、$funsに格納されているコマンドすべてを呼び出してクリプトマイナーを実行しようとしています。なお、このコマンドは非常に長くそのままではスクリーンショットに収まらないため、この画面では一部を省略しています。これに続き、Office_Updaterクラスのほかの値から、さらに関数が抽出されます。
以下に示すのは、特に注目すべき変数です。
- $mimi :PowerShell Mimikatz
- $NTLM :ラテラルムーブメントを行うために抽出されたNTLMハッシュ
- $scba :処理を持続的に行うための、タスクのスケジューリング情報
- $i17 :ターゲットのIPアドレスのリスト。以下に示す$i17のIPアドレスはPingCastleスキャナーが収集したもので、EternalBlueの脆弱性を意味します。
先に述べたように、WannaMineはもはや目新しい脅威ではありません。WannaMineが悪用するEternalBlueの脆弱性は、約1年半ほど前に攻撃の対象となり、これによって世界中で大きな被害が発生しています。しかし、1年以上が経過した現時点においても、組織は依然として、この脆弱性を狙った攻撃の影響を大きく受けています。
セキュリティアナリストがいつまでも、EternalBlueの脆弱性を悪用する攻撃者を相手にしたインシデントに関わらねばならない理由はどこにもありません。これらの脆弱性にパッチを適用しないままにしておく理由は何もありません。組織はセキュリティパッチをインストールし、マシンをアップデートする必要があります。
しかし、それで十分というわけではありません。Wannamineサーバーに関係するIPアドレスのいくつかは、それらが1年以上も前にセキュリティレポートで公開されているにもかかわらず、依然として利用可能な状態になっているのです。
これらのサーバーをホスティングしているプロバイダーにメールで問い合わせをしてみましたが、まだ何の回答も得られていません。一方、これらのIPアドレスはブロックするよう我々は強くお勧めします。具体的なアドレスは次のとおりです。
118.184.48.95
104.148.42.153
107.179.67.243
172.247.116.8
172.247.116.87
45.199.154.141
Wannamine攻撃の背後にあるコードやメカニズムは全く洗練さを欠いています。それらは、PingCastleスキャナーのようなサードパーティのコードを改変したものであり、Githubのリポジトリにあるコードの大部分をコピー&ペーストして使っており、そっくりそのまま同じコードを使用しているケースも見受けられます。
ホワイトペーパー「すべての組織が狙われている」
企業、組織がどんなにセキュリティを強固にしてもハッカーが悪用できる脆弱性は必ず存在します。侵入されることが避けられないことを受け入れ、新たな対策を立てる必要があります。本書で、なぜ避けられないのか、どのように対処するのかをご覧ください。
https://www.cybereason.co.jp/product-documents/input/?post_id=606