- マルウェアは、仮想環境で動作していることを避けるため、CPUファンのようなハードウェアの有無を確認する
- CPUファン情報は WMI の Win32_Fan クラスで確認でき、このデータは SMBIOS に保存されている
- Xen でカスタム SMBIOS データを挿入するにはパッチと追加設定が必要で、Cooling Device(Type 27) と Temperature Probe(Type 28) テーブルの両方を構成する必要がある
- QEMU/KVM では追加パッチなしで -smbios オプションにより簡単にカスタム SMBIOS を適用できる
- これにより、仮想マシンに CPU ファンが存在するように見せかけ、マルウェアの検知回避を試みることができる
なぜこの作業を行うのか?
- 一部の マルウェアは、仮想環境で実行されているか確認するために、特定のハードウェア（例: CPUファン）の有無をチェックする
- Win32_Fan などの WMI クラスでハードウェアを調べ、こうした情報がないと仮想マシンだと判断して実行を回避する
- 解析者にマルウェアを分析させないことが目的である
- Win32_CacheMemory、Win32_VoltageProbe などさまざまな WMI クラスが存在するが、この記事では CPU ファンに焦点を当てて説明する
コンピュータはどのように CPU ファンの存在を認識するのか?
- コンピュータは SMBIOS 情報を読み取り、冷却装置（CPUファン）の存在を認識する
- Win32_Fan インスタンスは cimwin32.dll により提供され、この DLL が SMBIOS の type 27 エントリからファン情報を読み取る
- DLL フックなどの方法も可能だが、SMBIOS を直接操作するほうがよりよいアプローチである
SMBIOS Type 27
- SMBIOS type 27 は "Cooling Device" を意味する
dmidecode ユーティリティで SMBIOS の Cooling Device データを直接確認できる- 例:
- Type: Chip Fan
- Status: OK
- Description: CPU Fan
- Nominal Speed: 5600 rpm など
Xen でカスタム SMBIOS データを設定する方法
- Xen では domain 設定ファイルの smbios_firmware オプションを使って、バイナリ形式の SMBIOS データを直接指定できる
smbios.bin ファイルを作成して Cooling Device(type 27) データを挿入する- SMBIOS 構造体サイズ（例: 24 バイト）は 32 ビット little-endian 整数として先頭に付ける必要がある
問題点: 構造体オーバーライドの制限
- Xen は 0, 1, 2, 3, 11, 22, 39 番の構造体だけを上書きできるよう制限している
- type 27 はデフォルトでは許可されていないため、ソースのパッチが必要になる
- Xen 開発者フォーラムでも関連パッチが提案されたが、公式には受け入れられていない（パッチ適用とビルドが必要）
Type 28 も必要
- Cooling Device(type 27) は Temperature Probe(type 28) と関連付けられている
- SMBIOS に type 28 エントリがない場合、Win32_Fan クラスで正常に表示されない
- host システムの type 28 データを取得して
smbios.bin に追加する必要があり、これにより正しく認識される
最終的な smbios.bin の構造
- Type 27 と Type 28 のデータを両方含める
- 各構造体の前にサイズ情報（little-endian）を挿入する
- 例:
18 00 00 00 ... (type 27) ... 29 00 00 00 ... (type 28) ... のような形式
Xen での適用と確認
- domain 作成コマンドで Windows 仮想マシンを起動した後、WMI で Win32_Fan クラスが正常に認識されるか確認する
- Description: Cooling Device、Status: OK と表示されれば、CPU ファンの認識に成功している
QEMU/KVM での SMBIOS データ設定
- QEMU/KVM では -smbios file=パス オプションにより、簡単にカスタム SMBIOS を設定できる
- 構造体サイズ情報は不要で、生データのみを使う
- host の SMBIOS データをそのまま活用しても問題ない
参考資料
- Xen domain 設定ファイル文書、mcnewton の設定ノート、却下された Xen パッチのアーカイブ、System Management BIOS Reference、QEMU Anti Detection パッチ など
1件のコメント
Hacker Newsの意見
新しいアンチマルウェア手法としては、ファンレスPCを買う方法や、ロシア語キーボードを設定するのも詐欺系マルウェアを防ぐコツだという話もあり、関連リンク を参照できる
私は実際に Streacom FC8 Evo のファンレス Linux PC とロシア語キーボードを使っているが、
dmidecodeコマンドで見ると冷却装置情報はまだ存在しており、冷却装置も実際に検出される。センサーデータで温度情報も確認できるファンレスPCを使っても、マザーボードには通常ファンヘッダーが残っているので、実際に接続されていなくても大きな違いはないだろうという意見
「smol pp」のような言葉は使わないようにしようという指摘で、身体への嘲笑が言葉に含まれている点を問題視
私の街には「SML PP」というカスタムナンバープレートを付けた人がいるが、なぜなのかは分からない
「私たちの言語」という表現を使いながらも、ブログのコメント欄にいる人が「私たち」と言うこと自体が曖昧だという意見
OSをあたかも仮想マシンのように見せるとセキュリティが上がり、研究者にも役立つかもしれないという意見。非仮想化アクセスを望むなら必ず権限を取らせるべきで、そうすればマルウェアが研究者の分析を避けるために一般ユーザーまで標的にしない可能性があり、結局はマルウェア作者以外の全員に利益があるという主張
普通のOSをVMのように見せるのではなく、むしろ仮想マシンが自分が仮想化されていることをまったく分からないようにするべきで、IBM の lpars システムはそのように動作するという意見
この方式だとアンチチートソフト企業も損をするだろうという話。私は自分のソフトウェアがどこで動いているかを明確に知りたいが、不正行為よりもチーターのほうを嫌うマルチプレイヤー利用者も多く、現実的には変化は簡単ではないという意見
モバイル開発の世界では、すでにこうした枠組みが現実になっているという意見
これまで消費者向けマザーボードで SMBIOS の記述が本物のハードウェアと一致しているのを見たことがない、という意見。こうした SMBIOS をチェックするマルウェアは実ハードウェアの 50% で失敗するかもしれないが、100% の VM やデバッガだけ確実に避けられるなら、マルウェア側にとっては失敗しても十分価値があるという考え。ただし、この手法よりは時間計測で判定するほうが信頼性は高そうだという見方
SMBIOS の記述が実ハードウェアと合っていない現象は、特に低価格な中国製ボックスで深刻。「to be filled in by OEM」のような未記入値は実際のライブ BIOS イメージをコーディングするときによく見かけるので、そうした値だけでも十分におかしいというフィードバック
マルウェアにはバグも多い。昔、ネットワークコードのバグのせいでウイルスが本来の意図の半分の速度でしか広がらなかった例があるように、マルウェアがすべての機器に感染しなくても甚大な被害は十分に起こせる
最近は Linux がファンをどう認識しているのか気になる。ACPI や EFI を使っているのか分からないが、私の機器ではたいていファンやセンサーが正確に認識されているという話
この SMBIOS チェックは実際のマルウェアが行っているのか、それとも研究者が作ったサンプルでしか使われていないのか気になるという質問
マルウェアが分析を難しくするために API を使うトリックはかわいく見えるかもしれないが、たいていこうした API 呼び出しは静的解析で簡単に検出され、バイナリが難読化されていなければむしろ逆効果だという意見。本当に目的を持ったプログラムは通常、信頼された CA の署名を受けて配布されるため、セキュリティ分析上は怪しい挙動として検出されやすいという経験談。ジュニア時代に regex パターンでこうした API 利用を検出する仕事もしていたが、大量配布された基本的なマルウェアを捕まえるにはかなり有効だった
最近ではマルウェアもかなり頻繁にファイルへ署名している。マルウェア業者がバイナリに署名しないだろうという期待はもはや誤りで、盗まれたコード署名証明書は珍しくなく、Microsoft が既存顧客ソフトウェアを壊すことを懸念して証明書失効に消極的だという話もある。マルウェアがカーネルへ侵入するために脆弱なドライバを利用することも多い。そのため、WMI 呼び出しを行う怪しい小さなバイナリより、脆弱性だらけのオーバークロック用ユーティリティが同じクエリを実行してもあまり疑われないのが現実。実際にはこの方式は検出回避というより、アナリストの PC 上でマルウェアのペイロードを有効化させないための意図であり、検出されると第2段階のペイロードは落ちてこず、実際の攻撃を起こしうる C&C 動作も保留される構造
セキュリティの観点では、すべてのソフトウェアを VM で動かすほうがよいのではないかという提案
アンチウイルスが静的解析だけでマルウェアかどうかを推定するのも微妙で、それならいっそホワイトリスト方式で信頼済みソフトウェアだけを許可し、それ以外はすべてマルウェアと見なすのと結果は同じだという主張
CrowdStrike のような企業が、カーネルレベルで動く粗末なソフトウェアに正式な署名を付けてシステムコールをやり放題でも誰も気にしない現実。VM かどうかは関係なく、未検証のコードとリリースをそのまま本番へ投入し、実際に世界が混乱して航空便が遅延したり主要インフラで事故が起きたりしても、十分に責任を取らないという問題。むしろ正規の企業のほうがハッカーや国家級攻撃者より大きな被害を与えうるという批判で、xz ユーティリティ事件も SolarWinds や ClownStrike と比較できるほどの大型セキュリティ事故だという意見
インフォセック業界の友人が、マルウェアハニーポットを本物のハードウェアと完全に似せるためにほとんどの時間を費やしているのを見たことがある。Windows XP ベースの温度調節器から Siemens PLC コントローラ、銀行業務用デスクトップまで、実にさまざまな機器を驚くほど精密にセットアップしていたという話
Hackintosh を設定するとき、適切な SMBIOS が必須だったことを思い出した。比較的マイナーな PC API がこの数十年で数多く導入されてきており、仮想化ソフトウェアやマルウェアがそうした部分をどれだけよく反映しているかを試すのによく使われる。さらに一歩進めるなら、実際の CPU 負荷に応じて動的に変化する温度センサーのシミュレーションも必要だという分析
Mitre ATT&CK T1497.001 (VM Detection) の基準では SMBIOS チェックは既知のベクター。私も実験してみたところ、電源ユニットを
HotReplaceable=Yes、Status=OKに設定して、$5,000 のベアメタルサーバのように見せることができた。使用したコマンドはpip install dmigenの後、dmigen -o smbios.bin --type0 vendor="American Megatrends",version="F.1" --type1 manufacturer="Dell Inc.",product="PowerEdge T630" --type39 name="PSU1",location="Bay 1",status=3,hotreplaceable=1