AhnLab ASEC 分析チームは、活発に出回っているマルウェアを監視している最中に、新たな形式の動的解析回避手法を確認した。最近、多数出回っているマルウェアは、診断を回避するための目的でマルウェアの実行環境を確認したあと、条件を満たしている場合は Crash を発生させて動作しないようにする。
今回紹介する手法は、特定のアセンブリ言語を使用する方法と、サイズが大きいメモリの割り当てが可能かどうかを確認する方法である。
1. AVX の対応可否(VXORPSコマンド)
「VXORPS」コマンドを使用して AVX に対応していない環境で動作する場合、 Crash が発生するマルウェアは主に Visual Basic で作成されたマルウェアである。最近紹介された「韓国国内企業を詐称して電子メールで拡散する Visual Basic マルウェア」ブログの記事でも言及したように、最近拡散しているマルウェアは、Visual Basic を利用したマルウェアが多い。

この「VXORPS」コマンドは、AVX(Advanced Vector eXtensions) コマンドセットに含まれているものであり、浮動小数点を利用した XOR 論理演算子である。このコマンドを CPU が処理するためには AVX コマンドセットに対応する CPU および OS を使用しなければならない。
AVX に対応していない環境の場合、マルウェアを実行したときに Illegal instruction により Crash が発生する。
動的解析環境は様々な脆弱性を発生させるために意図的にセキュリティ更新プログラムを適用していない旧バージョンの環境で構成する場合があり、そのため特定の技術が対応していない環境である場合がある。このような環境では、そのコマンドが含まれているサンプルが実行されるときに、AppCrash でマルウェアが動作せず、動的解析が回避される。
2011年度以降に作られたほとんどの CPU は、このコマンドセットに対応しており、対応している主なOS は [表1] の通りである。
OS | 対応バージョン |
Windows | Windows 7 SP1、Windows Server 2008 R2 SP1、Windows 8、Windows 10で対応 |
Linux | カーネルバージョン2.6.30以降に対応 |
macOS | 10.6.8(Snow Leopard)アップデート以降に対応 |
現在使用している環境の AVX 対応可否を確認するには、Windows Sysinternals が提供する Coreinfo ツールで確認する方法がある。
(https://docs.microsoft.com/en-us/sysinternals/downloads/coreinfo)


2. メモリ割り当て可否

この手法は VirtualAlloc() API を利用して0x3B9AC00(およそ1GB)ほどのメモリを割り当てる。このサイズを割り当てられなかった場合は無効なアドレスを参照するようにし、強制的に Crash を発生させる。
まず、一般的な動的解析環境(Sandbox)の場合、1つのコンピュータ内で多数の仮想マシン(VM)を同時に駆動するため、多くのリソースを必要とする。そのため、リソースを仮想マシン(VM)ごとに適切に分配することで最も高い効率を発揮することができ、この過程で通常の RAM のサイズはマルウェアが動作できる程度に割り当てられる。
そのため、1GB 以下で割り当てる場合が多く、このマルウェアはこのような部分を考慮したものである。
ここでは、コンピュータの CPU やディスクの容量を確認していた。このようなマルウェアを動作させるためには十分な RAM を割り当てるか、Windows に対応している仮想メモリを活用すれば動作が可能である。
この機能を使用すると、VM に 256MB 程度の小さいRAMサイズを割り当てたとしても、プロセスに 1GB 以上のメモリ空間を割り当てられることができ、動的解析が可能である。

当社の動的マシンである RAPIT の結果([図5]参照)を確認すると、マルウェアはこの手法の後に svchost.exe にインジェクションおよび時間遅延機能があり、特定の C2 サーバーと通信する NetWiredRC Backdoor であることが確認できる。
3. 結果
かつてマルウェアは、実行される環境をチェックして VM や Sandbox であることが検出されると直ちに終了する方式を使用していた。しかし、最近では、解析環境であることが検出されると強制的に Crash を発生させ、原因把握に時間を消費させるようにしている。
Crash は破損ファイルの場合にも発生することがあるが、上記のような手法で Crash が発生した場合、マルウェア内部で問題を引き起こしたコードを探さなければならず、解決方法を模索して仮想マシンを修正しなければならない。これだけではなく、仮想マシンの設計上の問題にまで続くと、さらに多くの時間を費やすことになり、動的解析の効率が低下してしまう。

さらには、広く知られている Cuckoo Sandbox の場合、監視プロセスを対象に Crash を引き起こす方法も存在するため、今後も様々な回避手法が出てくるものと思われる。
(https://github.com/David-Reguera-Garcia-Dreg/anticuckoo)
現在 AhnLab では、当該マルウェアを次のような診断名で診断している。
- Trojan/Win32.Inject (2020.02.20.00)
- Malware/Win32.RL_Gerneric (2020.02.14.00)
Categories:マルウェアの情報