世界を動かす技術を、日本語で。

VMにCPUファンがあると思わせることに成功しました

2025年6月29日原文(wbenny.github.io)

概要

  • マルウェアは 仮想マシン検出 のためにハードウェア構成を確認
  • CPUファン情報 の有無をWMI経由でチェックする手法が存在
  • SMBIOSデータ改ざん で仮想マシンにCPUファンを偽装可能
  • XenとQEMU/KVMでは 設定方法や注意点 が異なる
  • SMBIOS構造体や WMIクラスの関係 が重要なポイント

マルウェアによる仮想マシン検出とCPUファン偽装

  • 一部の マルウェア は、仮想マシンかどうかを判別するために特殊なハードウェア構成をチェック
  • Win32_Fan クラスをWMI経由で参照し、CPUファンの存在を確認する手法が代表例
  • これは仮想環境では通常 CPUファン情報が存在しない ため、分析回避のために利用される
  • WMIには他にも多くの 仮想ハードウェア特有の情報 を取得できるクラス(Win32_CacheMemoryなど)が存在

WindowsがCPUファンを認識する仕組み

  • Windowsは SMBIOSデータ を読み込み、CPUファンの存在を判断
  • Win32_Fanクラスの情報は、 cimwin32.dll がSMBIOSタイプ27(Cooling Device)から取得
  • SMBIOSデータは dmidecode コマンドでダンプ・編集が可能

XenでSMBIOSデータをカスタマイズする方法

  • Xenでは smbios_firmware オプションでSMBIOSデータファイルを指定可能
  • ファイル作成時、各SMBIOS構造体の前に 32ビットのサイズ情報 を付加する必要
  • 例:CPUファン(タイプ27)と温度プローブ(タイプ28)の両方を定義し、 バイナリデータを組み合わせて1ファイル化
    • 例:18 00 00 00 ...(タイプ27), 29 00 00 00 ...(タイプ28)
  • Xenの制約により、 一部のSMBIOSタイプのみ上書き可能 (タイプ27,28はパッチ適用が必要)
  • パッチ適用後、仮想マシン起動時に Win32_FanクラスでCPUファンが認識

QEMU/KVMでのSMBIOS偽装

  • QEMU/KVMでは -smbios file=... オプションでSMBIOSデータを簡単に指定可能
  • Xenと異なり、 サイズ情報の付加は不要 で、純粋なSMBIOSバイナリデータのみでOK
  • ホストのSMBIOSデータをそのまま流用することも可能
    • 例:cat /sys/firmware/dmi/tables/DMI > /path/to/smbios.bin

まとめと応用

  • マルウェアの 仮想マシン検出回避 や解析環境の偽装に有効な手法
  • SMBIOSデータの編集 は他のハードウェア情報(例:Win32_CacheMemory等)にも応用可能
  • Xenの場合は パッチ適用や構造体サイズの管理 に注意、QEMU/KVMは比較的容易

参考リンク

Hackerたちの意見

こういうトリックを使うのは、マルウェアが分析を難しくするための可愛い方法に見えるかもしれないけど、実際にはこういうマイナーなシステムAPIを呼び出すのは静的に検出されることが多いんだよね。AVソフトに怪しいってフラグが立つのは間違いないよ。もしマルウェアのバイナリがそういう呼び出しを隠すために難読化されていなかったら、むしろマルウェア作者にとって「逆効果」だと思う!これらのAPIに興味がある正規プログラムは、ほとんどが有名で信頼できるCAに署名されたバイナリだから、分析が怪しい挙動を報告するのも納得だよね。俺はこの分野でジュニアとして働いてたけど、似たようなAPIの使用を検出するために正規表現パターンマッチングを実装するのが仕事の一つだったんだ。意外と効果的で、大量に配布されている低ハンギングフルーツを捕まえるのに役立ったよ。

じゃあ、セキュリティの観点からすると、すべてのソフトウェアをVMの中で動かすべきなのかな?

最近、マルウェアが意外と署名されてることが多いから、もうマルウェア会社がバイナリに署名しないって期待できないよ。ハッキングされたコード署名証明書があちこちにあるし、Microsoftは元の顧客のソフトウェアを壊すのを恐れて、信頼を取り消すのに非常に消極的みたい。マルウェアがカーネルに入るために読み込むのが好きな一般的な脆弱なドライバーも同じだね。WMIコールをする変な小さなバイナリは目立つかもしれないけど、同じクエリをする脆弱性だらけの5年前のオーバークロックユーティリティは目立たないだろうね。俺が読んだ研究によると、これは検出を避けることよりも、マルウェアアナリストのマシンで本物のペイロードを起爆させないことに関することみたい。AVがバイナリをフラグ付けしたり、検出がトリガーされたりすると、2段階目はダウンロードされないし、ニュースになるようなことをするマルウェアは実行されない(まだね)。

アンチウイルスソフトが静的コールを分析して、何がマルウェアかを推測するのって本当にイライラするよね。だったら、信頼できるソフトの許可リストを作って、そのリストにないソフトをマルウェアとしてマークすればいいじゃん。それでほぼ同じように機能するし。

コツは「CrowdStrike」みたいな会社になることだね。カーネルレベルで動くクソみたいなソフトウェアに署名をもらって、あとは「疑わしい」システムAPIの呼び出しを好きなだけ行えるようにする。VMかどうかを判断するのは忘れちゃえ。顧客の生産機に未テストのコードやリリースを押し込むだけ。そしたら、世界が燃え上がるのを見て、フライトが遅れたり、重要なインフラが壊れたり、_本物_の人々が影響を受ける。_正当な_企業は、アメリカの企業に対して、ブラックハットハッカーや国家の行為者が夢にも思わないほどの被害を与えてきた。libzma内のxz utilの背後にいる人たちは、ClownStrikeやSolarWindsが引き起こしたのと同じくらいの被害を与えようとしているんだ。

消費者向けのマザーボードで、SMBIOSの説明が実際のハードウェアと関係しているのを見たことがないんだけど。もしこのマルウェアが実際のハードウェアの50%でも失敗するなら、驚かないよ。でも、マルウェアはこの失敗率を許容できるんじゃないかな。100%のVMやデバッガーで失敗することが保証されているなら、それは価値があると思う。もしこれが本当なら、マルウェア作者は単純に「エミュレーション可能」なSMBIOSよりもタイミングチェックをするんじゃないかな。

消費者向けのマザーボードで、SMBIOSの説明が実際のハードウェアと関係しているのを見たことがないんだけど。特に安い中国製のボックスに当てはまるみたい。もし「OEMが記入することになっている」っていう文字列を「ライブ/プロダクション」のBIOSイメージで見るたびに1ドルもらえたら…もう引退してるよ :).

最近のLinuxはファンをどうやって見つけてるの?今はACPI/EFIのことなのかな?俺のマシンはほとんど正しいファンやセンサーを持ってるみたい。

これをチェックしてるのは実際のマルウェアなの?それとも研究者が作ったマルウェアサンプル?

マルウェアにはバグがあるんだ。実際、いくつかのウイルスはバグのせいで著者が意図した以上に被害を与えたこともある。数年前に、90分で世界中に広がった非常に効果的なウイルスがあったんだけど、ネットワークコードのバグが原因で、本来の半分の速さで広がったんだ。つまり、45分でどこにでもあったはずなのに。存在するすべてのマシンに当たらなくても、かなりの被害を与えることはできるよ。

へぇ、新しいアンチマルウェア対策か: パッシブ冷却のPCを買う :) それとロシア語キーボードもセットアップしよう: https://krebsonsecurity.com/2021/05/try-this-one-weird-trick...

パッシブ冷却のPCは多分無理だね。ボードにはファンヘッダーがあるから、何も接続してなくても関係ないし。

Hacker Newsで議論の続きを見る