Tag Archives: zeroaccess

ZeroAccess は、これまでも常に P2P プロトコルを使って侵入先のコンピュータに悪質なペイロードを拡散してきました。P2P プロトコルを使うと、悪質なペイロードを配布する際に中央のコマンド & コントロール（C&C）サーバーを管理する必要がなくなるからです。2011 年には、ZeroAccess の P2P プロトコルは TCP 上で通信されていましたが、2012 年の第 2 四半期に、UDP を使うように変更されました。2013 年 6 月 29 日を迎えるまで、ZeroAccess の P2P に対する大きい更新はこれが最終でした。

シマンテックは、発見以来 ZeroAccess の P2P ネットワークを厳重に監視し続けています。2013 年 6 月 29 日、シマンテックは ZeroAccess ピアで新しいモジュールが拡散していることを確認しました。このときの通信にはポート 16464 と 16465 で動作する UDP ベースの P2P ネットワークが使われていましたが、ZeroAccess はポート 16470 と 16471 で動作する UDP ベースネットワークも確保しています。ZeroAccess のピアは同じネットワークに接続された他のピアと通信するので、ピアどうしがネットワーク上で通信することはありません。

6 月 29 日に発見されたモジュールは、ZeroAccess の P2P 機能を更新し、P2P ネットワークの堅牢性を高くして外部からの操作に対する耐性を強化するものです。2013 年 6 月 29 日に実施され、ZeroAccess の P2P 機能に影響する主なコード変更を以下にまとめます。

• サポートされる P2P プロトコルメッセージの数が、3 つから 2 つに減った。
• セカンダリの内部ピアリストが使われるようになり、リストに含めることができるピアの IP アドレスが 256 個から 1,600 万個に増えた。
• セカンダリの内部ピアリストは、Windows NTFS の代替データストリームとして格納されている。
• ZeroAccess のピアが他のピアと通信する方法のロジックが変更された。
• 悪質なファイルをダウンロードする TCP 接続に、エラーチェックとタイムアウトが追加された。

既存のピアについては UDP 16464/16465 のピアネットワーク上でコードの更新を利用できるほか、2013 年 6 月 29 日以降は、UDP 16464/16465 を対象としてコンピュータを ZeroAccess に感染させる ZeroAccess インストーラにも、新しい P2P プロトコルとコード変更が含まれていることが確認されています。

興味深いことに、ZeroAccess の UDP 16470/16471 ネットワークにはまだコード更新が適用されていません。UDP 16470/16471 を対象とする新しい ZeroAccess インストーラのサンプルにも、新しいコードは含まれていません。これまでは、UDP 16464/16465 と UDP 16470/16471 のネットワークはほぼ同じ時期に新機能とコード変更を適用されるのが通例でした。

ZeroAccess の作成者が今回の更新で実施したコード変更は、ZeroAccess に関して公開された研究に対応したため、または作成者がコード中に明らかな弱点を発見したためと考えられます。今回の変更は、ZeroAccess が今もなお鋭意開発中であり、依然として脅威であることの証拠とも言えます。シマンテックは、ZeroAccess の開発が今後も続くものと予測し、この脅威に変化が起きないかどうか全力で監視を続ける予定です。

次節では、P2P プロトコルについて技術的に詳しく説明し、ZeroAccess で実施された関連のコード変更についてもまとめます。
 

変更された P2P プロトコル

2012 年に発見されたとき、ZeroAccess の UDP ベース P2P プロトコルは getL、retL、newL の 3 つのメッセージタイプをサポートしていました。このメッセージについては多くのセキュリティ研究で説明されており、プロトコルの欠陥、特に newL メッセージタイプに関する欠陥も指摘されています。newL タイプのメッセージは、ZeroAccess がピア間で直接ルーティング可能な IP アドレス（スーパーノードまたはスーパーピアとも言う）を共有するために使われます。newL メッセージを受け取ったピアは、newL メッセージタイプに含まれている IP アドレスを内部のピアリストに追加します。ピアは newL メッセージを既知の他のピアにも転送し、メッセージの効果が増強されます。6 月 29 日より前には、newL メッセージを作成して ZeroAccess のピアに送信すると、感染した ZeroAccess ピアの内部ピアリストに悪質な IP アドレスを追加することができ、その悪質な newL メッセージを ZeroAccess ピアに拡散させることができました。

新しい P2P プロトコルではこの newL メッセージタイプが削除され、ボットネットが悪質なピアの IP を除外できるようになっています。
 

内部ピアリストの拡張

ZeroAccess の P2P プロトコルについて以前から指摘されていたもうひとつの欠点は、内部のピアリストが固定サイズだったことです。6 月 29 日の更新より前、ZeroAccess の内部ピアリストは上限が 256 ピアでした。同日以降はセカンダリのピアリストが追加されてメモリも確保され、1,600 万ピアの IP アドレスを保持できるようになっています。256 ピアのリストは引き続き、ピアの「ワーキングセット」として存続し、定期的にアクセスされています。セカンダリのピアリストは、冗長性の目的で使われているのです。

ピアリストの上限が 256 ピアだったときには、ZeroAccess を十分にクリーンアップすれば、ZeroAccess ピアを P2P ネットワークから切断することが現実に可能でした。256 個の既知のピアはいずれも、オンラインではなかったからです。また、ZeroAccess ピアの 256 個の内部ピアリストを悪質な IP アドレスに置き換えることも、理屈のうえでは可能でした。セカンダリのピアリストの追加で、このどちらも難しくなっています。

セカンダリのピアリストは、256 ピアのワーキングセットとともにディスクに書き込まれます。6 月 29 日より前には、内部ピアリストに記載された 256 個のピアは「@」という名前のファイルに保存されていました。同日以降も @ ファイルは存在し、ワーキングセットに含まれる 256 ピアの IP アドレスが記載されています。セカンダリのピアリストは、最大で 1,600 万個の IP アドレスを含み、@ ファイルの NTFS 代替データストリームとして保存されます。この NTFS 代替データストリームも、@ というファイル名を使っています。
 

実行時のピアの接続動作を変更

6 月 29 日より前には、ZeroAccess の内部ピアリストにある 256 ピアのうち 1 つに毎秒 getL を使って接続し、新しい悪質なモジュール上のデータと、新しい ZeroAccess ピアの IP アドレスを確認していました。この動作は同日以降にも続いていますが、いずれかのリモートピアがメッセージに応答する場合、応答しているそのピアの IP アドレスと応答時のタイムスタンプがセカンダリのピアリストに追加されます。

セカンダリの接続先リストにある IP には、ZeroAccess の最初の起動時にも接続されます。起動時には、セカンダリのピアリストから 1 秒ごとに 16 個もの IP アドレスが接続されます。このセカンダリのピアリスト通信は、感染したホストに少なくとも 16 個のリモートピアが応答するまで続きます。感染したピアに 16 個のリモートピアが接続を完了すると、セカンダリのリストにあるピアは、感染したコンピュータが再起動されるまで接続しなくなります。ワーキングセットの 256 ピアによる通常の定期的な接続の一環としてリモートピアが応答すると、セカンダリのピアリストは追加を続行され、更新されます。この動作によって、ZeroAccess クライアントはすでに接続したことのあるピアの膨大なリストを冗長性のために保持し続けますが、ZeroAccess ネットワークを通じて悪質なペイロードを急速に拡散するために、256 ピアの小さいワーキングセットも引き続き使われています。

実行時のピア接続動作についてもうひとつの変更は、接続先ピアの状態テーブルが記録されることです。ZeroAccess のピアは引き続き大量の getL メッセージをリモートピアに送信しており、応答として retL メッセージを受信するものと想定します。retL 応答には、悪質なペイロードのメタデータと、新しいピアの IP アドレスが含まれています。6 月 29 日より前には、感染したピアは任意の IP アドレスから任意の UDP メッセージを受信していました。これは、感染したホストがそのリモート IP アドレスに以前に接続したことがあるかどうかを問いませんでした。6 月 29 日以降も、ZeroAccess のピアは任意のリモート IP から getL メッセージを受信しますが、retL メッセージについては、受信側のピアが以前に getL メッセージを送信したことがある IP アドレスからのみ受信します。基本的に、ZeroAccess ピアが getL メッセージをリモート IP アドレスに送信すると、そのリモート IP アドレスはメモリ内のテーブルに追加されます。ZeroAccess ピアが retL メッセージを受け取ると、以前に getL メッセージを送ったことがある送信先の IP アドレスのテーブルがスキャンされ、retL メッセージを送信したピアの IP アドレスがそのテーブルに存在しなければ、retL メッセージを受け取った ZeroAccess ピアはそれを無視します。この変更によって、大量送信される retL メッセージは無視されるので、悪質な IP アドレスを送信する手段として（以前のプロトコルで newL メッセージが使われていたのと同じように）retL メッセージを使うことは、ますます難しくなっているのです。
 

ペイロードファイル転送の耐性が向上

ZeroAccess のピアには、リモートホストから悪質なペイロードをダウンロードしないよう確認するチェックが含まれています。ペイロードファイルのメタデータは retL メッセージに含まれ、デジタル署名されているので容易には偽造されません。また、悪質なペイロードファイル自体もデジタル署名されており、ファイルのダウンロード後に署名がチェックされます。デジタル署名は、悪質なピアが実行可能な任意のモジュールを P2P ネットワークに引き込んでしまわないように防いでいます。6 月 29 日のコード変更で、TCP ファイル転送の完了までに時間がかかりすぎないよう確認するチェックも追加されました。この変更は、一種のサービス拒否攻撃を防ぐことを目的としていると考えられます。つまり、悪質なピアが ZeroAccess のピアを欺き、悪質なピアから大量のファイルをダウンロードするよう仕向けて、結果的にファイルの配信速度を遅らせるという攻撃です。この攻撃を使えば、感染したコンピュータ上ですべての TCP ポートを占有し、意図された悪質なペイロードをダウンロードできなくさせることが可能です。

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

ZeroAccess は、これまでも常に P2P プロトコルを使って侵入先のコンピュータに悪質なペイロードを拡散してきました。P2P プロトコルを使うと、悪質なペイロードを配布する際に中央のコマンド & コントロール（C&C）サーバーを管理する必要がなくなるからです。2011 年には、ZeroAccess の P2P プロトコルは TCP 上で通信されていましたが、2012 年の第 2 四半期に、UDP を使うように変更されました。2013 年 6 月 29 日を迎えるまで、ZeroAccess の P2P に対する大きい更新はこれが最終でした。

シマンテックは、発見以来 ZeroAccess の P2P ネットワークを厳重に監視し続けています。2013 年 6 月 29 日、シマンテックは ZeroAccess ピアで新しいモジュールが拡散していることを確認しました。このときの通信にはポート 16464 と 16465 で動作する UDP ベースの P2P ネットワークが使われていましたが、ZeroAccess はポート 16470 と 16471 で動作する UDP ベースネットワークも確保しています。ZeroAccess のピアは同じネットワークに接続された他のピアと通信するので、ピアどうしがネットワーク上で通信することはありません。

6 月 29 日に発見されたモジュールは、ZeroAccess の P2P 機能を更新し、P2P ネットワークの堅牢性を高くして外部からの操作に対する耐性を強化するものです。2013 年 6 月 29 日に実施され、ZeroAccess の P2P 機能に影響する主なコード変更を以下にまとめます。

• サポートされる P2P プロトコルメッセージの数が、3 つから 2 つに減った。
• セカンダリの内部ピアリストが使われるようになり、リストに含めることができるピアの IP アドレスが 256 個から 1,600 万個に増えた。
• セカンダリの内部ピアリストは、Windows NTFS の代替データストリームとして格納されている。
• ZeroAccess のピアが他のピアと通信する方法のロジックが変更された。
• 悪質なファイルをダウンロードする TCP 接続に、エラーチェックとタイムアウトが追加された。

既存のピアについては UDP 16464/16465 のピアネットワーク上でコードの更新を利用できるほか、2013 年 6 月 29 日以降は、UDP 16464/16465 を対象としてコンピュータを ZeroAccess に感染させる ZeroAccess インストーラにも、新しい P2P プロトコルとコード変更が含まれていることが確認されています。

興味深いことに、ZeroAccess の UDP 16470/16471 ネットワークにはまだコード更新が適用されていません。UDP 16470/16471 を対象とする新しい ZeroAccess インストーラのサンプルにも、新しいコードは含まれていません。これまでは、UDP 16464/16465 と UDP 16470/16471 のネットワークはほぼ同じ時期に新機能とコード変更を適用されるのが通例でした。

ZeroAccess の作成者が今回の更新で実施したコード変更は、ZeroAccess に関して公開された研究に対応したため、または作成者がコード中に明らかな弱点を発見したためと考えられます。今回の変更は、ZeroAccess が今もなお鋭意開発中であり、依然として脅威であることの証拠とも言えます。シマンテックは、ZeroAccess の開発が今後も続くものと予測し、この脅威に変化が起きないかどうか全力で監視を続ける予定です。

次節では、P2P プロトコルについて技術的に詳しく説明し、ZeroAccess で実施された関連のコード変更についてもまとめます。
 

変更された P2P プロトコル

2012 年に発見されたとき、ZeroAccess の UDP ベース P2P プロトコルは getL、retL、newL の 3 つのメッセージタイプをサポートしていました。このメッセージについては多くのセキュリティ研究で説明されており、プロトコルの欠陥、特に newL メッセージタイプに関する欠陥も指摘されています。newL タイプのメッセージは、ZeroAccess がピア間で直接ルーティング可能な IP アドレス（スーパーノードまたはスーパーピアとも言う）を共有するために使われます。newL メッセージを受け取ったピアは、newL メッセージタイプに含まれている IP アドレスを内部のピアリストに追加します。ピアは newL メッセージを既知の他のピアにも転送し、メッセージの効果が増強されます。6 月 29 日より前には、newL メッセージを作成して ZeroAccess のピアに送信すると、感染した ZeroAccess ピアの内部ピアリストに悪質な IP アドレスを追加することができ、その悪質な newL メッセージを ZeroAccess ピアに拡散させることができました。

新しい P2P プロトコルではこの newL メッセージタイプが削除され、ボットネットが悪質なピアの IP を除外できるようになっています。
 

内部ピアリストの拡張

ZeroAccess の P2P プロトコルについて以前から指摘されていたもうひとつの欠点は、内部のピアリストが固定サイズだったことです。6 月 29 日の更新より前、ZeroAccess の内部ピアリストは上限が 256 ピアでした。同日以降はセカンダリのピアリストが追加されてメモリも確保され、1,600 万ピアの IP アドレスを保持できるようになっています。256 ピアのリストは引き続き、ピアの「ワーキングセット」として存続し、定期的にアクセスされています。セカンダリのピアリストは、冗長性の目的で使われているのです。

ピアリストの上限が 256 ピアだったときには、ZeroAccess を十分にクリーンアップすれば、ZeroAccess ピアを P2P ネットワークから切断することが現実に可能でした。256 個の既知のピアはいずれも、オンラインではなかったからです。また、ZeroAccess ピアの 256 個の内部ピアリストを悪質な IP アドレスに置き換えることも、理屈のうえでは可能でした。セカンダリのピアリストの追加で、このどちらも難しくなっています。

セカンダリのピアリストは、256 ピアのワーキングセットとともにディスクに書き込まれます。6 月 29 日より前には、内部ピアリストに記載された 256 個のピアは「@」という名前のファイルに保存されていました。同日以降も @ ファイルは存在し、ワーキングセットに含まれる 256 ピアの IP アドレスが記載されています。セカンダリのピアリストは、最大で 1,600 万個の IP アドレスを含み、@ ファイルの NTFS 代替データストリームとして保存されます。この NTFS 代替データストリームも、@ というファイル名を使っています。
 

実行時のピアの接続動作を変更

6 月 29 日より前には、ZeroAccess の内部ピアリストにある 256 ピアのうち 1 つに毎秒 getL を使って接続し、新しい悪質なモジュール上のデータと、新しい ZeroAccess ピアの IP アドレスを確認していました。この動作は同日以降にも続いていますが、いずれかのリモートピアがメッセージに応答する場合、応答しているそのピアの IP アドレスと応答時のタイムスタンプがセカンダリのピアリストに追加されます。

セカンダリの接続先リストにある IP には、ZeroAccess の最初の起動時にも接続されます。起動時には、セカンダリのピアリストから 1 秒ごとに 16 個もの IP アドレスが接続されます。このセカンダリのピアリスト通信は、感染したホストに少なくとも 16 個のリモートピアが応答するまで続きます。感染したピアに 16 個のリモートピアが接続を完了すると、セカンダリのリストにあるピアは、感染したコンピュータが再起動されるまで接続しなくなります。ワーキングセットの 256 ピアによる通常の定期的な接続の一環としてリモートピアが応答すると、セカンダリのピアリストは追加を続行され、更新されます。この動作によって、ZeroAccess クライアントはすでに接続したことのあるピアの膨大なリストを冗長性のために保持し続けますが、ZeroAccess ネットワークを通じて悪質なペイロードを急速に拡散するために、256 ピアの小さいワーキングセットも引き続き使われています。

実行時のピア接続動作についてもうひとつの変更は、接続先ピアの状態テーブルが記録されることです。ZeroAccess のピアは引き続き大量の getL メッセージをリモートピアに送信しており、応答として retL メッセージを受信するものと想定します。retL 応答には、悪質なペイロードのメタデータと、新しいピアの IP アドレスが含まれています。6 月 29 日より前には、感染したピアは任意の IP アドレスから任意の UDP メッセージを受信していました。これは、感染したホストがそのリモート IP アドレスに以前に接続したことがあるかどうかを問いませんでした。6 月 29 日以降も、ZeroAccess のピアは任意のリモート IP から getL メッセージを受信しますが、retL メッセージについては、受信側のピアが以前に getL メッセージを送信したことがある IP アドレスからのみ受信します。基本的に、ZeroAccess ピアが getL メッセージをリモート IP アドレスに送信すると、そのリモート IP アドレスはメモリ内のテーブルに追加されます。ZeroAccess ピアが retL メッセージを受け取ると、以前に getL メッセージを送ったことがある送信先の IP アドレスのテーブルがスキャンされ、retL メッセージを送信したピアの IP アドレスがそのテーブルに存在しなければ、retL メッセージを受け取った ZeroAccess ピアはそれを無視します。この変更によって、大量送信される retL メッセージは無視されるので、悪質な IP アドレスを送信する手段として（以前のプロトコルで newL メッセージが使われていたのと同じように）retL メッセージを使うことは、ますます難しくなっているのです。
 

ペイロードファイル転送の耐性が向上

ZeroAccess のピアには、リモートホストから悪質なペイロードをダウンロードしないよう確認するチェックが含まれています。ペイロードファイルのメタデータは retL メッセージに含まれ、デジタル署名されているので容易には偽造されません。また、悪質なペイロードファイル自体もデジタル署名されており、ファイルのダウンロード後に署名がチェックされます。デジタル署名は、悪質なピアが実行可能な任意のモジュールを P2P ネットワークに引き込んでしまわないように防いでいます。6 月 29 日のコード変更で、TCP ファイル転送の完了までに時間がかかりすぎないよう確認するチェックも追加されました。この変更は、一種のサービス拒否攻撃を防ぐことを目的としていると考えられます。つまり、悪質なピアが ZeroAccess のピアを欺き、悪質なピアから大量のファイルをダウンロードするよう仕向けて、結果的にファイルの配信速度を遅らせるという攻撃です。この攻撃を使えば、感染したコンピュータ上ですべての TCP ポートを占有し、意図された悪質なペイロードをダウンロードできなくさせることが可能です。

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

ZeroAccess has always distributed its malicious payloads to infected computers using a peer-to-peer protocol. The use of a peer-to-peer protocol removes the need to maintain centralized command-and-control (C&C) servers to distribute malicious payloads. In 2011, ZeroAccess’ peer-to-peer protocol communicated over TCP, but in the second quarter of 2012 the protocol was modified to use UDP. This was the last significant update to the ZeroAccess peer-to-peer protocol until June 29, 2013.

Symantec has been closely monitoring the ZeroAccess peer-to-peer networks since its discovery. On June 29, 2013, we noticed a new module being distributed amongst ZeroAccess peers communicating on the UDP-based peer-to-peer network that operates on ports 16464 and 16465. ZeroAccess maintains a second UDP-based network that operates on ports 16470 and 16471. ZeroAccess peers communicate to other peers connected to the same network; peers do not communicate across networks.

The module discovered on June 29 modifies the peer-to-peer functionality of ZeroAccess to make its peer-to-peer network more robust and resilient against outside manipulation. The following is a summary of the key code changes made on June 29, 2013, affecting ZeroAccess peer-to-peer functionality:

• The number of supported peer-to-peer protocol messages has been decreased from three to two.
• A secondary internal peer list is now used that can hold over 16 million peer IP addresses, up from 256 IP addresses.
• The secondary internal peer list is stored as a Windows NTFS alternate data stream.
• The logic of how a ZeroAccess peer will contact other peers has been modified.
• Error checks and timeouts have been added to the malicious file download TCP connections.

In addition to the code update being available on the UDP 16464/16465 peer network for existing peers, after June 29, 2013, we have observed new ZeroAccess installers for the UDP 16464/16465 network which infect computers with ZeroAccess also contain the new peer-to-peer protocol and code changes.

Interestingly, the ZeroAccess UDP 16470/16471 network has not yet received the code update. The new ZeroAccess installer samples for the UDP 16470/16471 network also do not contain the new code. In the past, both the UDP 16464/16465 and UDP 16470/16471 networks generally received new features and code modifications at approximately the same time.

Most of the code changes made by the ZeroAccess authors in this update seem to be in response to published research on ZeroAccess or other perceived weaknesses the authors found in the code. These changes are also further evidence that ZeroAccess continues to be actively developed and remains a threat. Symantec expects development of ZeroAccess to continue and will actively monitor the threat for those changes.

The following sections provide further technical details on the peer-to-peer protocol and related code changes made to ZeroAccess.
 

Modified peer-to-peer protocol

When discovered in 2012, ZeroAccess’ UDP-based peer-to-peer protocol supported three message types: getL, retL, and newL. A number of security researchers have described the messages and pointed out flaws in the protocol, especially regarding the newL message type. The newL message type is used by ZeroAccess to share directly routable IP addresses (often called super nodes or super peers) amongst its peers. When a peer receives a newL message it adds the included IP address within the newL message type into its internal peer list. The peer also forwards the newL message to other peers it knows about, magnifying the message’s effect. Prior to June 29, by crafting a newL message and sending it to a ZeroAccess peer it was possible to introduce a rogue IP address into an infected ZeroAccess peer’s internal peer list and have that rogue newL message distributed to other ZeroAccess peers.

The new peer-to-peer protocol removes the newL message type, allowing the botnet to filter out rogue peer IPs.
 

Expanded internal peer-list

Another flaw previously identified regarding ZeroAccess’ peer-to-peer protocol is the fixed internal peer list size. Prior to the June 29 update, a ZeroAccess’ internal peer list was capped at 256 peers. After June 29, a secondary peer list was added and memory reserved to hold up to 16 million peer IP addresses. The list of 256 peers continues to be the “working set” of peers that are periodically contacted. The secondary peer list is used for redundancy purposes.

When the peer list was only 256 peers in length it was feasible that a significant ZeroAccess clean-up action could cut off ZeroAccess peers from the peer-to-peer network because none of their 256 known peers were online. It also became theoretically feasible to replace a ZeroAccess peer’s 256 internal peer list with rogue IP addresses. The secondary peer list makes both of these actions more difficult.

The secondary peer list is written to disk, along with the 256 peer working set. Previous to June 29, the 256 peers from the internal peer list were stored in a file named “@”. After June 29, the @ file still exists and continues to contain 256 peer IP addresses from the working set of peers. The secondary peer list, containing up to 16 million IP address, is stored as an NTFS alternate data stream of the @ file. The NTFS alternate data stream also uses the @ filename.
 

Altered run-time peer contact behavior

Prior to June 29, one of the peers from the 256 peers in ZeroAccess’ internal peer list would be contacted using a getL each second to ask for any data on new malicious modules and new ZeroAccess peer IP addresses. This behavior continues after June 29. However, for any remote peer that responds to a message, that responding peer’s IP address and response time-stamp will be added to the secondary peer list.

The IP’s in the secondary contact list are also contacted when ZeroAccess first starts up. At startup, as many as 16 IPs from the secondary peer list will be contacted each second. This secondary peer list communication will continue until at least 16 remote peers have responded to the infected host. Once an infected peer has been contacted by 16 remote peers, peers from the secondary list will not be contacted until the infected computer is restarted. The secondary peer list will continue to be added to and updated as remote peers respond as part of the normal periodic contact with the 256 peers from the working set. This behavior allows a ZeroAccess client to keep a large list of previously contacted peers for redundancy and still operate with a small working set of 256 peers in order for malicious payloads to be quickly distributed throughout the ZeroAccess network.

Another runtime peer-contact behavior change is the keeping of a contacted-peer state table. ZeroAccess peers continue to send unsolicited getL messages to remote peers and expect to receive retL messages in response. The retlL responses contain malicious payload metadata as well as new peer IP addresses. Prior to June 29, an infected peer would accept any UDP message from any IP address, regardless of whether the infected host had contacted that remote IP address before or not. After June 29, a ZeroAccess peer will continue to accept getL messages from any remote IP, but will only accept a retL message from an IP address that the receiving peer had previously sent a getL message to. Basically, when a ZeroAccess peer sends a getL message to a remote IP address it will add that remote IP address to a table in memory. When a ZeroAccess peer receives a retL message, it will scan its table of IP addresses that it previously sent a getL message to, if the peer’s IP address that sent the retL message does not appear in the table the ZeroAccess peer that received the retL message will disregard it. This change ensures that unsolicited retL messages are ignored and makes using retL messages as a means of introducing rogue IP addresses (like newL messages could be used in the previous protocol) more difficult.
 

Improved payload file transfer resiliency

A ZeroAccess peer already contains checks to ensure it does not download a rogue payload file from a remote host. A payload file’s metadata in retL messages is digitally signed and cannot be easily forged. In addition, the malicious payload files themselves are digitally signed, the signature is checked after the file is downloaded. The digital signatures prevent a rogue peer from introducing an arbitrary executable module into the peer-to-peer network. The June 29 code change adds checks to ensure that TCP file transfers are not taking too long to complete. These changes seem to be designed to protect against a kind of denial-of-service attack where a rogue peer attempts to trick a ZeroAccess peer into downloading a large number of files from a rogue peer that would deliver the file data too slowly. Using this attack it would be possible to occupy all TCP ports on an infected computer, not allowing it to download the intended malicious payloads.