モノのインターネット(IoT )デバイスで発見されるマルウェアのサンプル数は、過去数年間で増加している。その原因は、IoT デフォルトの認証情報が変更されていないことと、IoT デバイスが適切に設定されていない、および/または、必要な頻度で更新されていないことの2つである。その結果、これらのデバイスはハッカーの格好の標的になってしまう。攻撃者は、ユーザーをスパイできるようにデバイスをコントロールしたり、別のネットワークやシステムに対して攻撃を仕掛けたりします。さらに、マルウェアの作者は、オープンソースのツールを使用して、アンチウイルス・ソフトウェアによる検出を回避できるようにマルウェアを修正している。
IoT デバイスの進化する脅威の状況を理解するための継続的な取り組みにおいて、当社は最近、当社のIoT ハニーポットから 15 日間にわたり 728 件のマルウェア・サンプルを収集しました。そして、マルウェアのサンプルを分析した結果、マルウェアの作者が検出を回避するために使用している新たな修正テクニックを発見しました。また、マルウェア作成者は、悪意のあるファイルを作成したり、IoT デバイスのさまざまな脆弱性を悪用したり、コマンド・アンド・コントロール(C&C)サーバを使用して侵害されたデバイスの制御を維持したりする新しい手法を採用しています。
このブログでは、収集したサンプルを分析し、新たな検出および分析テクニックを提供するとともに、脅威をネットワークから検索するために使用できるIoC(Indicators of Compromise)を共有します。
背景
2022年3月にリリースした前回のブログ「HowIoT Botnets Evade Detection and Analysis」では、Ultimate Packer for Executables(Upx)でパックされた後のマルウェア・サンプルについて、解凍をより困難にするために広く使用されている修正技術について説明しました。そして2022年8月、私たちは、セキュリティ研究者が容易に解凍できるように解凍プロセスを自動化するために作成したUPXリカバリツールの詳細をブログで発表しました。
過去数ヶ月間、一貫してこのツールを使用していたところ、マルウェア作者がサンプルで使用している回避テクニックを新たに発見した。これらの小さな修正の背後にある考え方は、ファイルを実行可能な状態に保ちながら、完全に解析することも部分的に解析することも不可能にすることです。これは、変更されたExecutable and Linkable Format (ELF)ヘッダが原因でリカバリ実行に失敗している図2に見ることができます。
私たちは、Kaiten/Tsunamiをはじめとする複数のマルウェアファミリーとコードを共有する標準的なボットネットサンプルに実装されているいくつかの保護技術を分析しました。このマルウェア ファミリの動作と機能は、MalwareMustDieとStratosphere Labが実施した技術解析ブログで把握されています。
MalwareMustDieがブログで取り上げた最初のいくつかの保護方法は、UPX！シグネチャが0A 00 00 00で上書きされ、エントリーポイントが元のエントリーポイントのコードを指すコール命令で始まるように変更されたサンプルについてだった。
その後、Stratosphere Labによると、マルウェアの作者は、ファイルの最後(オーバーレイ内)にジャンクバイトを追加するなどの追加対策を行った。たとえアナリストがすべてのUPXシグネチャの元のオフセットを見つけて修正できたとしても、標準のUPXツールはファイルの最後にPackHeader構造があることを想定しているため、PackHeader構造を見つけることはできません。
分析の結果、このファミリーのサンプルには、自動解析や分析をより困難にするような新たな変更が加えられていることに気づきました。他のブログで報告されている保護と比較して)私たちが確認した唯一のUPX関連の新しい保護は、オーバーレイに加えて、作者がPackHeader構造を上書きしたいくつかのサンプルで発見されました。
ELFヘッダーの修正
非UPXプロテクションに焦点を当て、私たちがUPXでパックした実行ファイルと、私たちのハニーポットで見つけたサンプルの1つを比較してみます。
図3のスクリーンショットは、通常のUPXパックファイルのELFヘッダー(左)と、ハニーポットを使って採取したこれらの標準ボットサンプルの修正ヘッダー(右)を示している。
図4に見られるように、最も顕著な違いはe_shoff(オフセット0x20)、e_shnum(0x30)、e_shstrndx(0x32)フィールドに見られ、これらは0xFFFF値で上書きされています。これらの人為的な変更は、マルウェアの実行には影響しませんが、サンプルを異なるツールで処理した場合に異なる種類のエラーを発生させます。
セクションには、実行ファイルをリンク、再配置、ビルドするための重要なデータが含まれているが、実行ファイルを直接実行するためのものではないため、これらのフィールドの変更がファイルの実行に影響しないという事実は理にかなっている。
調査中、ELFヘッダーをファジングした後、これらの3つのフィールド(e_shoff、e_shnum、e_shstrndx)を自由に変更することができ、いくつかの解析ツールでエラーを誘発し、サンプルの実行可能性を維持することができるという研究を発見した。この研究者はまた、私たちのサンドボックス内のサンプルで見られるのと同じ方法でELF実行可能ファイルを変更するCコードも共有しています。私たちは、これらのマルウェア作成者がこの同じツールを使用していると考えています。マルウェア作成者と研究者のツールの両方が、サイズが4であるe_shoffフィールドの2バイトのみを上書きしています。
例えば、Interactive Disassembler (IDA)ツールはいくつかの警告を表示したが、それでもファイルを開いて解析することができた。Hiewは、もうひとつの一般的なツールですが、このファイルをまったく開くことができず、すぐに終了してしまいました。私たちのUPXリカバリツールでさえ、ELFヘッダを解析する際にクラッシュしたため、これらのサンプルの処理に問題がありました。この場合、pyelftoolsはサンプルに対して行われた解析のチェーンの中のリンクでした。これらの異常な値は、存在するELFファイルのごく一部にしか現れないため、このライブラリはこれらのマルウェア・ファイルを開く準備ができていませんでした。このプロジェクトはオープン・ソースであるため、この種の予期せぬ値に対してライブラリをより耐性のあるものにするために、いくつかの改良を提出することができました。
QEMUユーザーモードエミュレーションを使用したデバッグ
悪意のある動作のあらゆる側面を適切に分析するためには、静的分析のみを行うのではなく、対象サンプルをデバッグすることが理にかなっています。今回のケースでは、アナリストのホストマシンで一般的なx86(32ビットまたは64ビット)ではなく、IoT デバイス(主にARMおよびMIPSアーキテクチャ)で一般的なLinux環境で動作するように作成されています。ARMやMIPSハードウェアをセットアップすることなくデバッグできるように、エミュレーターを使用するのが一般的です。フルシステムエミュレーションモードではなく、QEMUユーザーモードエミュレーションを使用することにしました。このツールはセットアップが非常に簡単で、Linuxディストリビューションのリポジトリから直接インストールし、x86ハードウェア上でIoT 、すぐにサンプルを実行することができます。スナップショットを図5に示します。
しかし、この単純さには大きな欠点がある。GDBプロトコルでサンプルをリモート・デバッグすることにした場合、まず、サンプルにローカル・ファイル・システムの実行パーミッションが必要になることが異常に思えるかもしれません。また、何度かサンプルを再起動すると、サンプルの動作が変化することに気づくかもしれません。例えば図6では、最初はARMサンプルは何もプロンプトを出さずに実行されましたが、連続して実行すると次のようなメッセージが表示されました：
これが、OS全体をエミュレートする仮想化ソフトウェアと、このQEMUユーザーモードセットアップの主な違いだ。エミュレートされたサンプルは、エミュレート先のローカルのx86-64ベースのホストマシンにフルアクセスでき、ローカルファイルを変更したり、新しいcrontabタスクを追加したりすることができた。そのため、QEMU をユーザー モードで使用する場合、異なるアーキテクチャ用にコンパイルされたサンプルをエミュレートする際には細心の注意が必要です。最初はわからないかもしれませんが、アーキテクチャが不一致であっても実害が生じる可能性があります。そのため、常に専用の(物理または仮想の)分離されたマシン上で解析を実行してください。
ELFヘッダーの修正 YARAの検出
ハニーポットで受け取ったサンプルの分析により、適切にロードされないことでいくつかのツールを回避することができたいくつかのアンチ解析テクニックを検出することができました。私たちは、同様のテクニックを実装したサンプルをさらに受信しているかどうかを知り、それらからすべての情報を抽出していることを確認し、IoT マルウェア環境における最新のテクニックをさらに学びたいと考えています。
私たちの研究は、ELFファイルを実行可能なままにしておくが、解析ソフトによってはエラーを返してしまうような卑劣な修正を記述し、検出するいくつかのYARAルールに行き着いた：
統計
図 7 に示すように、私たちがIoT ハニーポットから 15 日以内に収穫した 728 の悪意のあるサンプルを見てみましょう。全体の696(95%)はELFファイルで、最も標的とされたアーキテクチャはARM(539サンプル)、次いでMIPS(40サンプル)、386(35サンプル)とサンプルの10分の1以下です。ELFファイル以外のその他のファイルは、主にマシンの感染のさまざまな段階で使用されるbashとpythonスクリプトです。
結論
サンプルの絶え間ない分析により、マルウェアの進化を追跡し、マルウェア開発者が分析ツールからどのように作品を保護しているかを理解することができます。このような攻撃から身を守るためには、外部ネットワークからアクセス可能なデバイスに強力なパスワードを導入すること、ネットワークと外部接続の間にファイアウォールを設定すること、すべてのデバイスにウイルス対策ソフトウェアをインストールすること、デバイスの動作やパフォーマンスの変化(CPU使用率の増加など)を監視することをお勧めします。
IoC
- 5befe5c9e0ca212361cd8f5a7490bcd358d721f2dd8644d70b0f81bbc3e3e307
- 8b9bfe8d5d32d7218059fcd24660a15a177a4ee75670cc1af86b357d59903cc7
- 9f07137bc6e4d7e58ea0fe22285599fd56d62f61141a2a745e2d6583c332c9a8
