Category Archives: Security Response News

最近、Microsoft Windows XP 上では動作しないバックドア型のトロイの木馬プログラム（Backdoor.Trojan として検出されます）が確認されました。今回はこの脅威について、なかでもマルウェア作成者がこのトロイの木馬の機能に組み込んだ特殊なテクニックについて詳しく報告しようと思います。このマルウェアを標的型攻撃で使うために設計されたと思われるテクニックです。

fseek 関数

この脅威で作成者は fseek 関数を使っています。通常はデータ処理に使われる関数なので、これは異例なことです。たとえば、ファイルの先頭から 100 バイトのデータを読み込むプログラムでは、fseek 関数のプロセスを使って 100 バイトを移動します。

図 1. マルウェアで使われている fseek コードのテクニック

ところが、今回見つかったマルウェアには、ループで連続する 3 つの関数が存在します。

1. 別の文字列に文字列を追加する（strcat）。
2. ファイルの末尾から 0 バイトを移動する（fseek）。
3. 文字列をトークンに分割する（strtok）。

通常、コードは fseek 関数の後でデータを読み書きしますが、このマルウェアの場合にはそのプロセスが発生していません。このような関数がループで記述されているのも奇妙です。

このコードをさらに詳しく見てみると、fseek 関数はファイルハンドルに NULL ポインタを指定して動作していることがわかります。つまり、制御するファイルがないということです。fseek 関数が存在しないファイルを制御するため、このマルウェアは Windows XP 上で実行されるとクラッシュします。

図 2. Windows XP 上で実行されるとマルウェアがクラッシュする

同じファイルを Windows Vista 以降で実行すると、正常に動作します。では、Windows XP と Vista 以降の Windows では何が違うのでしょうか。

Microsoft Visual Studio 2005 以降の MSDN ライブラリによれば、fseek 関数は次のように説明されています。

「stream が null ポインタの場合、または origin が次に説明するいずれの値でもない場合、「パラメータの検証」に説明されているように、fseek および _fseeki64 は無効なパラメータ ハンドラを呼び出します。実行の継続が許可された場合、これらの関数は errno を EINVAL に設定し、-1 を返します。」

しかし、Microsoft Visual Studio .NET 2003 の MSDN ライブラリには、この説明がありません。

以上のことから、NULL ポインタを指定したファイルハンドルをパラメータとして渡されたときの fseek コードの動作が変更されたのだと考えられます。マルウェア作成者は、この変更を意図的に利用して、Windows XP 上では動作しないプログラムを作成したのです。

Windows XP は、2013 年 3 月の時点でもオペレーティングシステム市場において 40% を若干下回る程度のシェアを保っています。Windows XP で動作しないプログラムを作成したら、大量のコンピュータに感染させる絶好のチャンスを逃していることになります。とすれば、わざわざそのようなマルウェアを作成した理由はどこにあるのでしょうか。

Windows XP で動作しない理由

1 つ考えられるのは、マルウェアの真の動作がサンドボックスで明らかにされるのを回避しようと試みている可能性です。インターネット上で見つかった 8 つの自動脅威解析システムにサンプルファイルを送信してみたところ、どのシステムでもサンプルファイルの動作はログに記録されませんでした。これは、fseek 関数によるテクニックの後で悪質なコードが見つかったためと考えられます。サンプルのテストに使われるサンドボックスが Windows Vista など、Windows XP よりも新しいオペレーティングシステムで実行されている場合、マルウェアの動作が記録されない可能性があります（セキュリティ企業が自動の脅威解析システムを利用してマルウェアを解析する方法について詳しくは、以前のブログを参照してください）。

有害あるいは破壊的な活動を実行することなく密かに動作するマルウェアは、長期にわたってコンピュータへの侵入を続けることができるので、マルウェア作成者にとってそのメリットは無視できません。

バックドア型のトロイの木馬プログラムは通常、オペレーティングシステムや CPU のクロック数、インストールされているウイルス対策ソフトウェアを調べますが、今回のマルウェアは、以下の情報も収集する点で独特です。

• 侵入先のコンピュータに無線ネットワークカードが搭載されているかどうか
• シンクロナス DRAM、キャッシュ DRAM、3DRAM、SDRAM など、ダイナミックランダムアクセスメモリ（DRAM）のタイプ
• BIOS のメーカー設定、シリアル番号、バージョン
• プリンタのキャプション
• バッテリの詳細とデバイス ID

通常、マルウェア作成者はコンピュータ上のバッテリのことまで考えたりしません。ところが、今回のマルウェアの作成者は明らかに、標的企業に強い関心を示しているようです。

まとめ

このブログの執筆時点で、シマンテックの大口のお客様からこのマルウェアのサンプルが集まったのはわずかに 2 例だけで、大規模な感染は記録されていません。

これまでの解析結果から言えるのは、このマルウェアは標的型攻撃に使われ、作成者は、標的企業のコンピュータで Windows Vista 以降が使われていることを知りつつ、Windows XP では動作しないマルウェアでネットワークへの感染を試みたということです。

標的企業の管理者が、疑わしいファイルの不審な動作に気付き、自動の脅威解析システムでそのファイルをテストしたとしても、テスト段階で悪質な活動は見られず、管理者もこのファイルの本当の動作については何もわからなかった可能性があります。

シマンテックは、今回ご報告した悪質なコードとそのテクニックを引き続き監視していく予定です。疑わしいプログラムは実行しないようにして、オペレーティングシステムやウイルス対策ソフトウェアを最新の状態に保つことをお勧めします。

* 日本語版セキュリティレスポンスブログの RSS フィードを購読するには、http://www.symantec.com/connect/ja/item-feeds/blog/2261/feed/all/ja にアクセスしてください。

Nearly every week now we can read about a data breach case somewhere, where millions of user accounts and potential other sensitive data has been compromised. Most people are not even shocked by such news anymore, as it is starting to become humdrum.
O…

Recently, I discovered a back door Trojan horse program that does not work on Microsoft Windows XP. I would like to present some of the details of this threat, especially as the malware author encoded a special trick into the functionality of the Trojan. The trick appears to have been designed to allow the threat be used in targeted attacks.

The fseek function

In this threat, the author uses the fseek function, which is unusual as it is normally used to process data. For example, if the program reads 100 bytes of data from the top of the file, the fseek function process is used to move the 100 bytes.

Figure 1. The fseek code trick used by the malware

However, in the case of this Trojan, there are three functions that continue in a loop:

1. Append one string to another string (strcat)
2. Move zero bytes from the end of the file (fseek)
3. Split a string into tokens (strtok)

Usually, code reads or writes data after the fseek function, but in this case this process does not happen. It is also strange that such a function is written in a loop.

Looking at the code in greater detail, the fseek function works with a NULL pointer as a file handle. This means that there is no file to control. Because the fseek function controls a non-existent file, the threat crashes when it is executed on Microsoft Windows XP.

Figure 2. The threat crashes when it runs on Microsoft Windows XP

If the file is executed on Microsoft Windows Vista or later, it works fine. So what is the difference between Microsoft Windows XP and later versions of Windows?

According to the MSDN Library for Microsoft Visual Studio 2005 or later, the fseek function is documented as follows:

“If stream is a null pointer, or if origin is not one of allowed values described below, fseek and _fseeki64 invoke the invalid parameter handler, as described in Parameter Validation. If execution is allowed to continue, these functions set errno to EINVAL and return -1.”

However, there is no mention of this in the Microsoft Visual Studio .NET 2003 MSDN Library.

I think the fseek code changed when a file handle with a NULL pointer is passed as a parameter to the function. The malware author used this change intentionally in order to create a program that doesn’t run on Microsoft Windows XP.

Microsoft Windows XP has just under 40% usage share of the operating system market as of March 2013. If a malware author creates a program that doesn’t run on Microsoft Windows XP, valuable opportunities to compromise a large number of computers will be lost. So, why would someone create malware such as this?

Why not run on Microsoft Windows XP?

One possibility is an attempt to avoid revealing the true behavior of the threat in sandboxes. I submitted a sample file to eight Automated Threat Analysis Systems found on the Internet and none of these systems logged the sample file behavior. I believe the reason for this is that the malicious code is found after the fseek function trick. If the sandboxes used for testing samples ran on Microsoft Windows Vista, or rather any operating system later than Microsoft Windows XP, they may not have logged the malware’s behavior. (Please see this blog for further details regarding how Automated Threat Analysis Systems are used by antivirus companies to analyze malware.)

If malware runs without performing any destructive or disruptive activities in silence, it can continue to compromise computers for a long time, for which the merits to the malware author cannot be overstated.

Back door Trojan horse programs usually check the operating system, CPU clock, and the installed antivirus product, if any. This threat is unusual because it also gathers the following information:

• Whether the compromised computer has a wireless network card
• The dynamic random-access memory (DRAM) type, such as Synchronous DRAM, Cache DRAM, 3DRAM, or SDRAM
• The BIOS manufacturer settings, serial number, and version
• The printer caption
• The battery description and device ID

Normally malware authors wouldn’t worry about the battery on the computer. However, the author of this threat evidently has a strong interest in the targeted company.

Conclusion

At the time of writing this blog, Symantec has only received two samples of this threat from large customers and no major infections have been recorded.

From what I can gather from my analysis of this threat, it was used in a targeted attack and the author knew that the targeted company uses Microsoft Windows Vista or later on their computers and hence attempted to infect their network with malware that does not work on Microsoft Windows XP.

If the administrator of the targeted company were to notice suspicious behavior in a suspect file and decide to test it on an Automated Threat Analysis System, it is possible that malicious activity may not be seen at all during the testing and the administrator would be none-the-wiser about the file’s true behavior.

Symantec will continue to monitor malicious code and techniques outlined in this blog. We also recommend that users not run suspicious programs and keep their operating system and antivirus software up to date.