検索
連載

System32に潜むGatherNetworkInfo.vbsの謎を追え！：その知識、ホントに正しい？ Windowsにまつわる都市伝説（8）

Windows 7以降に存在する「GatherNetworkInfo.vbs」を知っていますか。このスクリプトは「タスクスケジューラ」にも登録されていますが、タスクを手動で実行してもエラーになります。ただのバグか、それとも別の使命があって潜んでいるのか……。

[山市良，テクニカルライター] PC用表示 関連情報
Share
Tweet
LINE
Hatena
「Windowsにまつわる都市伝説」のインデックス

連載目次

GatherNetworkInfo.vbsは正真正銘、Windowsのシステムファイルです

　Windows 7およびWindows Server 2008 R2以降のWindowsには、「％Windir％（通常、C:\Windows）\System32」フォルダーに「GatherNetworkInfo.vbs」が存在します（画面1）。

画面1
画面1　「GatherNetworkInfo.vbs」は、Windowsファイル保護（WFP）の対象でもあるWindows正規のファイル

　このファイルはWindows Script Host（WSH）で実行可能なVBScriptのスクリプトです。「Windowsファイル保護」（Windows File Protection：WFP）の対象となっているシステムファイルであり、悪意のあるファイルに置き換えられないようにシステムで保護されています。通常の方法では書き換えることはもちろん、削除することもできません。

　「GatherNetworkInfo.vbs」には、ハードウェアやOSのシステム情報から、ネットワーク、ユーザー、ドメイン、適用されているグループポリシー、ファイル共有、Windowsファイアウォール、レジストリ、イベントログといった広範囲の情報を収集し、ファイルに出力するように1000行以上のコードが記述されています。

　Windowsの管理者やITプロフェッショナルには、システム管理情報へのアクセス方法を学ぶよい教材となるでしょう。筆者自身、“自作”の管理用スクリプトを作成する際、コピペしたことが何度もあります。

　管理者権限でこのスクリプトを実行すれば、どのような情報が収集できるのかを確認できます。でも、試してみるのはちょっと待ってください。

　このスクリプトは、カレントディレクトリ（作業中のパス）の下の「config」および「reg」フォルダー内に大量のファイルを出力します。安易に「％Windir％\System32」から実行してしまうと、Windowsで最も重要といってよいレジストリハイブやSAMデータベースが存在する「％Windir％\System32\Config」フォルダー内に、大量のファイルが作成されてしまいます。

　もし、試すのであれば、別途作業ディレクトリを作成して、そこからフルパスで指定して実行しましょう。そうすれば、作業ディレクトリの下に「config」と「reg」サブフォルダーが作成され、これらのサブフォルダーに出力されます。

ネット上ではなぜかマルウェア扱い？

　インターネットで「GatherNetworkInfo.vbs」を検索すると、マルウェアであるかのように説明しているサイトが数多くヒットします（画面2）。もしかしたら、同名のマルウェアが存在するのかもしれませんが、「％Windir％\System32」フォルダーにあるものは、何らかの不正な方法で置き換えられていない限り、マルウェアではありません。

画面2
画面2　インターネットで「GatherNetworkInfo.vbs」を検索してみた結果

　「GatherNetworkInfo.vbs」の検索結果のページを開くと、「GatherNetworkInfo.vbs」よりもっと怪しげな製品やツールのダウンロードや購入に誘導されることになると思うのでご注意ください。

タスクスケジューラに登録されている“怪しげなタスク”

　筆者は「GatherNetworkInfo.vbs」が正規のファイルであり、無害であることは承知していたのですが、それでも怪しさというか、なぜそこにあるのかという疑問を長い間感じていました。

　例えば、次の画面を見てください。Windows 7上でWindows Sysinternalsの「Autoruns」を実行したものです。Autorunsは、Windowsの起動問題やマルウェアの疑いのあるファイルの調査、解決に使える便利なツールです。Autorunsは、タスクスケジューラに登録された「GatherNetworkInfo.vbs」を赤色で強調表示します。しかも、マイクロソフトやWindowsのエントリを非表示にしても、「GatherNetworkInfo.vbs」は非表示になりません（画面3）。

画面3
画面3　Windows SysinternalsのAutorunsが、タスクスケジューラに登録された「GatherNetworkInfo.vbs」を検出

　「GatherNetworkInfo.vbs」はテキストファイルなので、発行元やデジタル署名、説明はファイルの属性からは取得できず、Autorunsはこのように検出せざるを得ません。不安な人は検出された項目を選択して、［Ctrl］＋［V］キーを押してみてください。発行元（Publisher）に「（Verified）Microsoft Windows」と表示され、署名された正規のシステムファイルであることが分かります（ファイルそのものへの署名ではなく、Windowsのカタログファイルを使用した署名）。

　なお、64bit版Windows上では、Autorunsによるカタログファイルの署名検証に不具合があるようです。カタログファイルによる署名を検証したい場合は、「AutorunsC -v」（AutorunsC.exeはコマンドライン版）を使用するか、同じくWindows Sysinternalsの「SigCheck」を利用できます。

　Autorunsはタスクスケジューラに登録された「\Microsoft\Windows\Netrace\GatherNetworkInfo」というタスクを検出しました。タスクスケジューラを開いてこのタスクを確認してみると、トリガーの設定されていない、つまり自動実行されることのないタスクでした。試しにタスクを右クリックして「実行する」をクリックしてみたところ、「ディレクトリ名が無効です。（0x8007010B）」というエラーで失敗します（画面4）。このタスクも謎です。

画面4
画面4　Autorunsが検出したタスクを手動で実行してみてもエラーで失敗する

　タスクのプロパティを開いて「操作」タブを開くと、ここに「％Windir％\System32\gatherNetworkInfo.vbs」のコマンドラインが設定されていることを確認できます。「編集」ボタンをクリックしてさらに詳細を確認すると、「開始（オプション）」のテキストボックスに「$（Arg1）」という値が設定されていました（画面5）。

画面5
画面5　作業ディレクトリを指定する「開始（オプション）」に「$（Arg1）」という謎の文字

　「開始（オプション）」は、プログラムの実行時に使用する作業ディレクトリを指定するオプションです。「$（Arg1）」というパスはコンピューターに存在しないので、作業ディレクトリに移動できずに「％Windir％\System32\gatherNetworkInfo.vbs」の実行に失敗したということのようです。

　ちなみに、最新のWindows 8.1でも全く同じように「\Microsoft\Windows\Netrace\GatherNetworkInfo」タスクが登録されており、手動で実行すると同じエラーで失敗します。ちょっと昔に戻ってWindows Vistaの場合はどうかというと、「\Microsoft\Windows\Netrace\GatherNetworkInfo」タスクや「GatherNetworkInfo.vbs」のファイルは存在しないのですが、同様の機能を持つと思われる次の2つのタスク（かっこ内はプログラムの開始に設定されたスクリプト）が登録されていました。

  • \Microsoft\Windows\Wired\GatherWiredInfo（％Windir％\System32\gatherWiredInfo.vbs）
  • \Microsoft\Windows\Wireless\GatherWirelessInfo（％Windir％\System32\gatherWirelessInfo.vbs）

　これらのタスクのプログラムの「開始（オプション）」にも、「$（Arg1）」という謎の指定がなされていました（画面6）。

画面6
画面6　Windows Vistaの場合は「GatherWiredInfo.vbs」と「GatherWirelessInfo.vbs」の2つが同じようにタスクに登録されていた

今まで誰も説明してくれなかった本当の使い方！

　「Arg」は引数（Arguments）の略であることはすぐに想像できますが、「$（Arg1）」という独特の記述方法が気になります（画面7）。

画面7
画面7　「Arg」は「Arguments」の略。画面はWSHスクリプトでコマンドライン引数を取得する簡単な例

　「$（Arg0）」や「$（Arg1）」の形式や「タスクスケジューラ」での使用をヒントに、インターネットをいろいろと検索してみたところ、ちょっと古いですがマイクロソフトのTechNet Blogsに以下の記事を見つけました。

　この記事では、「パフォーマンスモニター」にある「データコレクターセット」の「パフォーマンスカウンターの警告」を使用して、タスクを自動実行する際に「$（Arg0）」と指定してタスクに引数を引き渡す方法が示されています。

　パフォーマンスモニターのデータコレクターセットの「タスクの引数」に指定したものを、「タスクスケジューラ」側では「$（Arg0）」で受け取ることができるというものです。例えば、「タスクの引数」を利用して、カウンターの値（{value}）やしきい値（{threshold}）、しきい値を超えた時の日時（{date}）をタスクスケジューラで実行するプログラムの引数として渡すことができます。

　しかし、「データコレクターセット」の「タスクの引数」では、1つの引数しか指定できません。では、2つ目の引数を示す「$Arg（1）」はどうやって渡すのでしょうか。筆者の予想は、パフォーマンスデータの出力先である「ディレクトリ」の値を「$Arg（1）」で受け取れるのではというものです。

　早速試してみました。適当なテンプレートを選択して、システム情報を収集するユーザー定義のデータコレクターセットを作成し、データコレクターセットの「プロパティ」を開いて、「タスク」の「データコレクターセットの停止時にこのタスクを実行」に次のように記述します（画面8）。

\Microsoft\Windows\NetTrace\GatherNetworkInfo


画面8
画面8　パフォーマンスモニターのデータコレクターセットの終了時タスクとして「\Microsoft\Windows\NetTrace\GatherNetworkInfo」を指定する

　「ディレクトリ」タブの指定は既定の「％Systemdrive％\PerfLogs\...」のままにして、データコレクターセットを実行し、しばらくしたら停止します。すると案の定、タスクスケジューラ側の「\Microsoft\Windows\NetTrace\GatherNetworkInfo」が実行中になり、しばらくすると「前回の実行結果」に「この操作を正しく終了しました。（0x0）」と表示されました。

　パフォーマンスデータの出力先を開いてみると、予想どおり、「config」および「Reg」フォルダーが作成されており、「GatherNetworkInfo.vbs」が出力した大量のファイルが確認できます（画面9）。

画面9
画面9　パフォーマンスデータの保存先フォルダーの下に「config」と「Reg」サブフォルダーが作成され、「GatherNetworkInfo.vbs」の出力先として使用された

　ちなみに、「パフォーマンスの警告」のみのデータコレクターセットで同様の設定を行う場合は、監視対象のパフォーマンスカウンターのプロパティの「警告のタスク」タブに「\Microsoft\Windows\NetTrace\GatherNetworkInfo」タスクを指定します。

　また、「パフォーマンスの警告」のみの場合は、パフォーマンスデータが出力されないため、既定の出力先は作成されません。そのため、「\Microsoft\Windows\NetTrace\GatherNetworkInfo」タスクは「ディレクトリ名が無効です。（0x8007010B）」エラーで失敗してしまいます。この問題を回避するには、データコレクターセットのプロパティの「ディレクトリ」タブで既存のパスを指定するようにしてください（画面10）。

画面10
画面10　「パフォーマンスの警告」のタスクとして「\Microsoft\Windows\NetTrace\GatherNetworkInfo」を自動実行させる設定例

知ってました？ タスクスケジューラのタスク指定

　今回紹介した方法を用いれば、パフォーマンスモニターを利用したシステム情報やパフォーマンス情報の取得と同時に、「GatherNetworkInfo.vbs」が収集する大量のデータの取得を自動化できます。あるいは、パフォーマンス異常時にその時点のシステム情報を吸い上げるのに利用することもできます。なかなか便利な機能に思えるのですが、どこにも説明されていないのはもったいないですよね。

　そもそも、パフォーマンスモニターの「タスク」の自動実行機能は知っていても、タスクスケジューラのタスクを指定することを知っている人はあまりいないのではないでしょうか。恥ずかしながら、筆者はWindows Vista以降の変更を知りませんでした。Windows XPやWindows Server 2003 R2までは、実行するプログラムのパスと引数を書いていました。そのため、新しいWindowsでも同じようにコマンドラインを直接書いて、タスクが実行できないと悩んだ人は多いかもしれません。

　なお、パフォーマンスモニターのヘルプ（http://technet.microsoft.com/ja-jp/library/cc749267.aspx）には「データコレクターセットの停止時にこのタスクを実行」について次のように説明しています。英語版のヘルプと比べても誤訳ではないようです。しかも、オプションを参照したくても、WMIタスクのドキュメントへのリンクが設定されていません。このヘルプって間違っていませんかねぇ。

［データコレクターセットの停止時にこのタスクを実行］ボックスにコマンドを入力すると、データコレクターセットの収集の完了時にWindows Management Instrumentation（WMI）タスクを実行できます。オプションについては、WMIタスクのドキュメントを参照してください

「その知識、ホントに正しい？ Windowsにまつわる都市伝説」バックナンバー

筆者紹介

山市 良（やまいち りょう）

岩手県花巻市在住。Microsoft MVP：Hyper-V（Oct 2008 - Sep 2014）。SIer、IT出版社、中堅企業のシステム管理者を経て、フリーのテクニカルライターに。マイクロソフト製品、テクノロジを中心に、IT雑誌、Webサイトへの記事の寄稿、ドキュメント作成、事例取材などを手がける。個人ブログは『山市良のえぬなんとかわーるど』。


Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る