社内の複数端末で謎の windowsupdate.exe が動作し、さらに nslookup が自動実行されている――この状況は、多くの場合「たまたま」ではなく、意図的なマルウェア活動のサインです。本記事では、windowsupdate.exe は正規ファイルなのか？という疑問に答えつつ、インシデント対応・調査・再発防止までを、情報システム部門・SOC・情シス担当者向けに実務ベースで整理します。
windowsupdate.exe と nslookup の組み合わせが危険な理由
まず結論から整理します。
- Microsoft 公式の Windows Update コンポーネントに
windowsupdate.exeというファイルは存在しない - Windows Update の正規コンポーネントは、サービス
wuauservやクライアントwuauclt.exe、UsoClient.exe、WaaSMedicSvcなど windowsupdate.exeを名乗るファイルは、正規プロセスを装ったマルウェア（Masquerading）である可能性が非常に高い- そのプロセスが後続で
nslookupを実行している場合、DNS を利用した C2 通信や情報外送を強く疑うべき
特に、以下のような条件がそろっている場合は「ほぼインシデント」と考えて動いた方が安全です。
C:\Users\<ユーザー名>\AppData\配下など、ユーザーディレクトリにwindowsupdate.exeが置かれている- タスクスケジューラやレジストリ
Runキーから自動起動している windowsupdate.exe→nslookup.exeの親子関係が継続的に発生している- 不審なドメイン名や TXT レコードに対する DNS クエリが大量に発生している
逆に言えば、「Windows Update っぽい名前だから大丈夫だろう」と放置してしまうと、長期間にわたって情報漏えい・追加ペイロードのダウンロード・横展開を許してしまうリスクがあります。
正規の Windows Update コンポーネントとの違い
windowsupdate.exe が怪しい理由を理解するために、代表的な正規コンポーネントと比較してみましょう。
| 役割 | 正規ファイル名 | 代表的なパス | 署名 | 備考 |
|---|---|---|---|---|
| Windows Update サービス | wuauserv（サービス名） | C:\Windows\System32\svchost.exe 内のサービス | Microsoft Windows Publisher | サービスマネージャーから確認可能 |
| 旧来の更新クライアント | wuauclt.exe | C:\Windows\System32\wuauclt.exe | Microsoft 署名あり | 最近の Windows では出番は少なめ |
| 更新オーケストレーション | UsoClient.exe | C:\Windows\System32\UsoClient.exe | Microsoft 署名あり | タスクスケジューラから呼び出されることが多い |
| Windows Update Medic Service | WaaSMedicSvc | C:\Windows\System32\WaaSMedicSvc.dll など | Microsoft 署名あり | 更新機能が壊れた際の自己修復要素 |
| 怪しい自称アップデータ | windowsupdate.exe | C:\Users\... や C:\Temp\... など様々 | 署名なし / 不明 | 公式には存在しない名称。要調査・要隔離。 |
ポイントは、「System32 直下の正規ファイルだから安全」ではなく、
- ファイル名（公式に存在するか）
- 配置パス（ユーザープロファイルや Temp 直下は要注意）
- デジタル署名（Microsoft 正規署名か、不明・なし・無効か）
を総合的に見て判断することです。
nslookup がマルウェアに悪用されるパターン
nslookup 自体は DNS 解決を行うだけの正規ツールです。しかし、マルウェアはこの正規ツールをうまく悪用し、検知回避や通信経路のカモフラージュに利用します。
| 悪用パターン | 概要 | よくある兆候 |
|---|---|---|
| DNS ベースの C2 通信 | DNS クエリにコマンドやトークンを埋め込み、応答を通じて指令を受け取る | 短い間隔で同じサブドメインへの問い合わせが繰り返される |
| 情報外送（データ流出） | 機微情報を Base64 等でエンコードし、長いサブドメイン名として送出 | 異常に長いドメイン名への TXT/NULL レコードの問い合わせ |
| ネットワーク疎通確認 | ファイアウォールで HTTP/HTTPS が制限されていても DNS は通る場合を悪用 | プロキシやブラウザを使わないのに外部ドメインだけへの DNS クエリが多い |
特に EDR や Sysmon のログ上で、
windowsupdate.exe→nslookup.exe- ユーザープロファイル配下の謎の EXE →
nslookup.exe
といった親子関係が大量に見られる場合、かなり高い確度で悪意ある活動と考えてよいでしょう。
windowsupdate.exe を見つけたときの初動対応フロー
現場で慌てないために、最低限これだけは踏むべきステップを整理しておきます。
| ステップ | 目的 | 具体例 |
|---|---|---|
| 1. 隔離（封じ込め） | 被害拡大と外部通信を止める | 有線 LAN ケーブルを抜く、Wi‑Fi を無効化、SOC から該当端末を VLAN 隔離 |
| 2. 横展開確認 | 組織全体の影響範囲を把握 | 資産管理・EDR を使って windowsupdate.exe を全端末検索 |
| 3. 事実確認・証拠保全 | 後で振り返り・法的対応に耐えうるログを残す | ファイル属性・署名・ハッシュ・プロセスツリー・イベントログを採取 |
| 4. マルウェアスキャン・駆除 | 不審ファイルと関連コンポーネントを除去 | Microsoft Defender フルスキャン、オフラインスキャン、他社 AV 併用 |
| 5. 再発防止策の実装 | 同じ攻撃パターンをブロック | AppLocker/WDAC、EDR ルール、DNS 監視、権限制御の強化 |
特に、1. 隔離 と 2. 横展開確認 はスピード勝負です。「詳細が分かるまで様子を見る」のではなく、疑わしきは止めるのがインシデント対応の鉄則です。
PowerShell を使った事実確認と証拠保全の手順
ここからは、管理者権限の PowerShell を前提に、実際にどう調べるかを具体的なコマンドで示します。
同名ファイルの探索
# ドライブ直下から windowsupdate*.exe を再帰的に検索
Get-ChildItem -Path $env:SystemDrive\ -Filter "windowsupdate*.exe" -Recurse -ErrorAction SilentlyContinue
windowsupdate.exe以外にも、windowsupdate.excや.cxeなど、似た名前の亜種が存在するケースもあります。- 資産管理ツールを併用し、他端末にも同名ファイルが存在しないか並行して確認すると効率的です。
デジタル署名の確認
# 署名情報の確認
Get-AuthenticodeSignature "C:\path\to\windowsupdate.exe"
ここで注目すべきは、
- Status が
Validか、Unknownか、NotSignedか - SignerCertificate.Subject が「Microsoft Windows」関連か、聞いたことのない組織か
です。署名がないから必ずしも悪とは限りませんが、「Windows Update を名乗るのに無署名」はかなり不自然です。
ハッシュ値（SHA‑256）の採取
# SHA256 ハッシュの取得
Get-FileHash "C:\path\to\windowsupdate.exe" -Algorithm SHA256
取得したハッシュは、後で以下の用途に使えます。
- 他端末に同一ファイルが存在するかどうかの判定
- 自社内 IOC リストや、各種インシデント管理システムとの紐付け
- セキュリティベンダーや CSIRT への報告・照会
プロセス・自動起動の確認
# 実行中プロセスの確認
Get-Process -Name windowsupdate -ErrorAction SilentlyContinue
# 自動起動（Run キー）
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"
# タスクスケジューラ
schtasks /query /fo LIST /v | findstr /i windowsupdate ここで「Run キーに windowsupdate.exe が登録されている」「謎のタスク名から呼び出されている」といった痕跡があれば、永続化（Persistence）の仕組みとして組み込まれている可能性が高いと判断できます。
Microsoft Defender を使ったマルウェアスキャン・駆除
Windows 10 / Windows 11 では、標準搭載の Microsoft Defender Antivirus だけでもかなり強力な検知・駆除が可能です。特にエージェントを追加インストールできない環境では、Defender のコマンドライン活用が重要になります。
フルスキャンの実行
# PowerShell からフルスキャン
Start-MpScan -ScanType FullScan
# コマンドラインからフルスキャン
"%ProgramFiles%\Windows Defender\MpCmdRun.exe" -Scan -ScanType 2
- スキャン中は CPU 使用率が上昇するため、業務影響を考慮した時間帯で実行するのが理想です。
- インシデント対応中は、多少のパフォーマンス劣化よりも早期検知・早期駆除を優先すべき場面も多いです。
オフラインスキャンの検討
高度なマルウェアは、起動中に自身を保護し、ファイルロックやプロセス監視によって削除を妨害することがあります。この場合、OS 起動前の オフラインスキャン が有効です。
# Windows Defender オフラインスキャンを予約
Start-MpWDOScan
これにより、再起動後に Windows Defender オフラインが起動し、システムドライブをより低レイヤーからスキャンします。
スキャン後に必ず行うべき確認
- 検出された脅威の一覧と、その処理結果（隔離・削除・許可）を確認
windowsupdate.exeが再生成されていないか、一定期間モニタリング- 関連するスケジュールタスク・レジストリ・サービスが残っていないか再チェック
特に「一度削除したのに、再起動後に同じハッシュのファイルが復活する」場合、別の感染源や横展開の存在を疑うべきです。
恒久対策：同じ手口を繰り返させないために
インシデントの鎮火だけで終わらせず、仕組みとして再発を防ぐことが重要です。代表的な対策をいくつか挙げます。
アプリケーション制御（AppLocker / WDAC）の活用
- 原則として、「署名付きの正規ベンダー製アプリ」と「許可リストに登録された社内アプリ」以外は実行を禁止する設計に近づける
- 特に、
%USERPROFILE%や%TEMP%配下からの EXE 実行は強く制限する - 段階的に「監査モード」から始め、業務影響がないことを確認しながらブロックへ移行する
EDR での検知ルール整備
EDR（Defender for Endpoint など）を導入している場合は、以下のような検知ルールが有効です。
*windowsupdate.exe*がnslookup.exeを子プロセスとして起動したらアラート- ユーザープロファイル配下の EXE から
nslookup.exeが一定回数以上起動したらアラート - 短時間に大量の DNS クエリを発生させるプロセスがあればアラート
こうした「振る舞いベース」のルールを一度作ってしまえば、亜種がファイル名を微妙に変えてきても検知しやすくなります。
DNS ログ監視の強化
- 社内 DNS サーバーのログを SIEM に集約し、外部向けの異常なクエリを可視化する
- 長いサブドメイン・ランダム文字列・TXT レコードへの頻繁な問い合わせなどを検知条件に組み込む
- 既知の悪性ドメインリスト（threat intelligence）との照合も有効
最小権限とパッチ適用の徹底
- ローカル管理者権限を必要最小限に絞り、一般ユーザーが勝手に EXE を配置・実行できないようにする
- OS やブラウザ、Office、Java、各種ランタイムなどの脆弱性パッチを継続的に適用する
- メールゲートウェイや Web フィルタリングのルールも合わせて見直し、初動侵入を減らす
軽量スクリプトで社内一斉スキャン：実践例
掲示されていた簡易スクリプト案を、実務でそのまま使えるようにした一例が以下です。
指定したパス配下を走査し、疑わしいファイルのパス・サイズ・署名・ハッシュなどを CSV にまとめることができます。
# SuspiciousBinarySweep.ps1
param(
[string]$ScanPath = "$env:SystemDrive\",
[string[]]$SuspiciousNames = @("windowsupdate.exe","windowsupdate.cxc","windowsupdate.exc","windowsupdate.cxe"),
[string]$ExportPath = "$env:Temp\SuspiciousBinaryScan.csv"
)
$results = foreach ($name in $SuspiciousNames) {
Get-ChildItem -Path $ScanPath -Filter $name -Recurse -ErrorAction SilentlyContinue | ForEach-Object {
$sig = Get-AuthenticodeSignature $_.FullName
$hash = Get-FileHash $_.FullName -Algorithm SHA256
[PSCustomObject]@{
FileName = $_.Name
Path = $_.FullName
SizeKB = "{0:N2}" -f ($_.Length / 1KB)
LastWrite = $_.LastWriteTime
Owner = (Get-Acl $_.FullName).Owner
Signature = $sig.SignerCertificate.Subject
SigStatus = $sig.Status
SHA256 = $hash.Hash
}
}
}
if ($results) {
$results | Export-Csv -Path $ExportPath -NoTypeInformation
Write-Host "`n疑わしいファイル一覧を出力しました:`n$ExportPath" -ForegroundColor Yellow
} else {
Write-Host "`n該当する不審ファイルは見つかりませんでした。" -ForegroundColor Green
}
このスクリプトで出力される CSV のカラムは、次のように解釈できます。
| 列名 | 意味 | 分析のポイント |
|---|---|---|
| FileName | ファイル名 | windowsupdate.exe 以外の紛らわしい名前がないか確認 |
| Path | フルパス | System32 以外の怪しい場所（ユーザーフォルダ等）にないか |
| SizeKB | ファイルサイズ | 同名ファイルでもサイズがバラバラなら別物の可能性が高い |
| LastWrite | 最終更新日時 | インシデント発生日周辺と一致しないか、過去ログと照合 |
| Owner | ファイル所有者 | 不自然に一般ユーザー名が所有者になっていないか |
| Signature | 署名者 | Microsoft 以外の聞き慣れない発行元や空欄に注意 |
| SigStatus | 署名ステータス | NotSigned や UnknownError は要調査 |
| SHA256 | ハッシュ値 | 同一ハッシュの端末数を数えると感染範囲の把握に役立つ |
小規模環境であれば、このスクリプトを USB メモリや共有フォルダから各端末で実行し、集中管理用ファイルサーバーに CSV を集約するだけでも、かなり効率的な横展開調査が可能です。
判断の目安：どこまでいけば「黒」とみなすべきか
現場で悩みがちなポイントが、「どの時点でマルウェア感染と確定してよいのか」です。あくまで一例ですが、次のような観点で総合判断するとよいでしょう。
「ほぼ黒」と判断してよいパターン
windowsupdate.exeがC:\Users\<ユーザー>\AppData\Roamingなどに存在- 署名がない、あるいは不明な第三者名義の署名
- タスクスケジューラやレジストリから自動起動している
- EDR ログ上で
windowsupdate.exe→nslookup.exeの親子関係が継続的に見られる - DNS ログに謎のドメインへの大量クエリが記録されている
グレーゾーンのパターンと対応
- 署名はあるが、ベンダー名が聞き慣れないソフトウェア（サードパーティのアップデータ等）
- ハッシュ値で検索しても既知の IOC 情報がヒットしない
このような場合は、
- 開発・運用チームに確認し、「社内開発ツールではないか」を確認
- 必要に応じてサンドボックス環境で挙動解析する（インターネットは疑似環境に限定）
- ベンダーやセキュリティコミュニティにハッシュを照会する
といった手順で慎重に判断するのがおすすめです。
まとめ：windowsupdate.exe は正規バイナリではない。すぐに隔離と調査を
本記事のポイントをあらためて整理します。
windowsupdate.exeという Microsoft 公式の実行ファイルは存在しない- Windows Update の正規コンポーネントは
wuauclt.exeやUsoClient.exe、サービスwuauservなどであり、これらには正規の Microsoft 署名が付与されている windowsupdate.exeがnslookupを呼び出している場合、DNS を利用した C2 通信や情報外送の可能性が高い- 見つけたらまず端末をネットワークから隔離し、署名・ハッシュ・自動起動痕跡を採取したうえで、Microsoft Defender などでフルスキャンを実施
- その後、AppLocker/WDAC、EDR の振る舞い検知、DNS 監視、権限制御などの恒久対策を実装し、同じ手口をブロックする
windowsupdate.exe のような「もっともらしい名前」を悪用したマルウェアは、今後も名前を少し変えながら繰り返し登場すると考えられます。ファイル名だけに頼らず、位置・署名・挙動・ログという複数の軸で冷静に分析し、組織としてのインシデント対応力を継続的に高めていきましょう。
コメント