2013年8月頃よりマルウェア開発者らのコミュニティ内でマルウェアをVBScriptへ変換を依頼するなどのスレッドを見かけるようになりました。
下図は一例で、或るRAT（Remote Administration Tool）をVBScriptへ変換して欲しい、といった依頼のものです。
既存のマルウェアをわざわざ他の開発言語で作り直す主な理由として、
・一時的なセキュリティ対策ツールの回避
・VBScriptなどのスクリプト言語ではエンコード処理が容易
・スクリプト言語への変換、公開により別の開発者が登場し、機能面などで機能向上が期待
などが挙げられます。
最終的にエンコードや暗号処理を用いていますので、検体そのものを被害PC上よりピンポイントで発見することはなかなか骨が折れそうです。また、暫くはサイバー攻撃手法に変化が起こるというよりは、このような回避手法とのいたちごっこが続くと考えています。このような状況を踏まえますと、利用頻度が低いスクリプトなどは予め動作制限をしておき、脅威レベルを軽減しておいた方が安心かもしれません。
下図は一例で、或るRAT（Remote Administration Tool）をVBScriptへ変換して欲しい、といった依頼のものです。
既存のマルウェアをわざわざ他の開発言語で作り直す主な理由として、
・一時的なセキュリティ対策ツールの回避
・VBScriptなどのスクリプト言語ではエンコード処理が容易
・スクリプト言語への変換、公開により別の開発者が登場し、機能面などで機能向上が期待
などが挙げられます。
いずれにせよ、マルウェア開発者側にこのような動きがあるということは、次のサイバー攻撃の流れとして融通がきき易いスクリプト言語ベースのマルウェアの脅威が増大すると予測できそうです。
ちなみに、現在ちらほら確認しているのはZeuSの亜種でも利用されているとされるAutoItScriptからVBScriptへの変換です。
ちなみに、現在ちらほら確認しているのはZeuSの亜種でも利用されているとされるAutoItScriptからVBScriptへの変換です。
＃ZeuS自身の変換は見た事ありませんが、ソースコードが流出していることを考えると有り得るかも？
傾向からしますと、VBScriptの利用が目立っていますので、そういった意味では対応策を考え始めた方が良いかもしれません。
下の記事に主な対応策が記載されていますので、参考にしてみては如何でしょうか。
VBScript Malware Demo using FileSystemObject
AutoItScriptで開発されたマルウェアについて
傾向からしますと、VBScriptの利用が目立っていますので、そういった意味では対応策を考え始めた方が良いかもしれません。
下の記事に主な対応策が記載されていますので、参考にしてみては如何でしょうか。
VBScript Malware Demo using FileSystemObject
AutoItScriptで開発されたマルウェアについて
補足で、上述のAutoItScriptについて触れてみたいと思います。
AutoItScriptはAutoItがインストールされた環境下でなければ動作しません。そこで、AutoItによりスクリプトをコンパイルしますとUPXによりパックされEXEファイルとして出力することができます。
AutoItScriptはAutoItがインストールされた環境下でなければ動作しません。そこで、AutoItによりスクリプトをコンパイルしますとUPXによりパックされEXEファイルとして出力することができます。
但し、コンパイルした結果は、
・UPXの利用はプログラムの善悪に関係無く、一部のセキュリティ対策ツールに検出されてしまう
・UPXの利用はプログラムの善悪に関係無く、一部のセキュリティ対策ツールに検出されてしまう
・EXEファイルはサンドボックス型のセキュリティ対策ツールで検出されてしまう可能性がある
・AutoItで作成したことはすぐに分かってしまう
などの理由によりセキュリティ対策ツールに処理されてしまう可能性が高まります。
そこで、攻撃者らは試行錯誤した結果、解決策のひとつとしてソースコードの変換を考えたと推測されます。
・AutoItで作成したことはすぐに分かってしまう
などの理由によりセキュリティ対策ツールに処理されてしまう可能性が高まります。
そこで、攻撃者らは試行錯誤した結果、解決策のひとつとしてソースコードの変換を考えたと推測されます。
参考までに変換前と後は下のサンプルのような内容となります。（イメージだけ・・・）
実際はサンプル２からさらにエンコードされますので、可読性のあることは殆どありません。意識せずにみると、複数のマルウェアが存在するように見えます。ここまでのイメージとしては、次のようになります。元はひとつの検体なのですが、自由度の高い（？）言語に変換することで形体を変化させ生存率を高めているわけです。
サンプル１：AutoItScript
FUNC __IS_SPREADING ()
LOCAL $W_KEY = STRINGSPLIT (@SCRIPT,".")
$SPREADING = REGREAD ("HKEY_LOCAL_MACHINE\SOFTWARE\" & $W_KEY[1],"")
IF $SPREADING = "" THEN
$SPREADING = "FALSE"
IF STRINGUPPER (STRINGMID (@FULLPATH,2)) = STRINGUPPER (":\" & @SCRIPT) THEN $SPREADING = "TRUE"
REGWRITE ("HKEY_LOCAL_MACHINE\SOFTWARE\" & $W_KEY[1],"","REG_SZ",$SPREADING)
ENDIF
ENDFUNC
サンプル２：VBScript
spreading = shellobj.regread ("HKEY_LOCAL_MACHINE\software\" & split (install,".")(0) & "\")
if spreading = "" then
if lcase ( mid(wscript.scriptfullname,2)) = ":\" & lcase(install) then
spreading = "true - " & date
shellobj.regwrite "HKEY_LOCAL_MACHINE\software\" & split (install,".")(0) & "\", spreading, "REG_SZ"
else
usbspreading = "false - " & date
shellobj.regwrite "HKEY_LOCAL_MACHINE\software\" & split (install,".")(0) & "\", spreading, "REG_SZ"
end if
end If
実際はサンプル２からさらにエンコードされますので、可読性のあることは殆どありません。意識せずにみると、複数のマルウェアが存在するように見えます。ここまでのイメージとしては、次のようになります。元はひとつの検体なのですが、自由度の高い（？）言語に変換することで形体を変化させ生存率を高めているわけです。
最終的にエンコードや暗号処理を用いていますので、検体そのものを被害PC上よりピンポイントで発見することはなかなか骨が折れそうです。また、暫くはサイバー攻撃手法に変化が起こるというよりは、このような回避手法とのいたちごっこが続くと考えています。このような状況を踏まえますと、利用頻度が低いスクリプトなどは予め動作制限をしておき、脅威レベルを軽減しておいた方が安心かもしれません。
