Windows Server 2016でKB4025339未適用と脆弱性スキャンに出る原因と対策（Nessus/Tenable・累積更新SSU/LCU）

Windows Server 2016 Datacenter を最新まで更新しているはずなのに、脆弱性スキャンで「KB4025339 が未適用」と指摘され、Microsoft Update Catalog でも見つからない――そんな“古いKB問題”を、累積更新（LCU）とサービススタック更新（SSU）の考え方から整理し、WSUS運用・Tenable/Nessusの誤検知・追加設定要件まで含めて解決手順をまとめます。

起きていることを整理：KB4025339 を「探して入れる」発想がハマりやすい理由

まず押さえておきたいのは、Windows Server 2016（LTSC/1607）の月例更新は、基本的に累積更新（Cumulative Update / LCU）として提供される点です。累積更新は「その時点までの修正をまとめて含む」形式なので、原則として最新のLCUを入れていれば、過去のKB（KB4025339 相当の修正）も包含されます。

このため、脆弱性スキャンが「KB4025339が未適用」と出たとしても、直近の累積更新を適用済みなら、KB4025339を単体で探してインストールする必要は基本的にありません。古いKBがMicrosoft Update Catalogで見つからないこと自体も珍しくなく、後続の累積更新に置き換え（superseded）されることで、検索に出にくくなったり、配布対象外になったりします。

用語	役割	ポイント
SSU（Service Stack Update）	更新処理の基盤（サービススタック）を更新	SSUが別提供されている場合、古いSSUのままだとLCUが正しく入らない／途中で失敗することがある
LCU（Latest Cumulative Update）	月例の品質更新（セキュリティ含む）	基本は「最新のLCU＝過去の修正を全部含む」ため、途中のKBを追いかけない
Superseded（置き換え）	後続更新により旧更新が不要になる状態	Catalogに「単体で存在しない／検索できない」ように見えることがある

原因は大きく3系統：OS側の未反映／配布経路（WSUS）／診断ツール側（誤検知・定義）

同じ「KB4025339 未適用」でも、実際の原因は複数あります。やみくもに手当たり次第で直すより、どの系統の問題かを短時間で切り分けるのが現場では重要です。

系統	典型症状	まず確認するもの
OS側（更新が本当に入っていない／有効化されていない）	ビルド番号が古い、再起動待ち、更新失敗ログがある	OSビルド、再起動待ち、更新履歴とDISMのパッケージ一覧
配布経路（WSUS/更新の承認・分類）	「最新にしているつもり」でもSSUが配られていない	SSU/LCUの承認状況、製品/分類、クリーンアップ設定
診断ツール側（検出ロジック、プラグイン定義、スキャン方式）	最新LCU適用済みでもKB未適用扱いが残る	プラグイン更新状況、認証スキャンの成否、プラグイン出力（根拠）

最短で効くチェック：OSの「実際の状態」を数字で見る

まずは「更新した気になっている」状態を排除するために、OSビルド番号とインストール済み更新を機械的に確認します。ここが曖昧だと、WSUSも診断ツールも議論が空転します。

OSビルド（Build / UBR）を確認する

Windows Server 2016では、同じ1607でもLCUによりビルド（例：14393.xxxx）が更新されます。スキャン結果のKB名より、ビルドが最新の更新履歴に追随しているかの方が、実態に近い指標です。

PowerShell（管理者）:
$cv = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
$build = "$($cv.CurrentBuildNumber).$($cv.UBR)"
$cv.ProductName
$build

インストール済みKB（HotFix）を確認する

PowerShell:
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 30

ただし、更新の種類によっては Get-HotFix に出ないものもあります。確実性を上げるなら、DISMでパッケージとして確認します。

コマンドプロンプト（管理者）:
dism /online /get-packages /format:table

「再起動待ち」を潰す（意外と多い落とし穴）

LCUやSSUを入れた直後に再起動が必要な状態だと、診断ツールが「未適用」と判定することがあります。とくにVMでは、メンテ枠の都合で再起動が先送りされがちです。

PowerShell:
$pending =
  (Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending') -or
  (Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired')
$pending

$trueなら、まず再起動してから再スキャンします。再起動後も残る場合は、次の手順に進みます。

更新が「失敗」していないかログで当たりを付ける

「更新を当てたつもりでも、裏で失敗していた」ケースは意外にあります。以下は現場でよく見る確認先です。

• イベントビューアー：WindowsUpdateClient、Setup、Servicing 関連のエラー
• CBSログ：C:\Windows\Logs\CBS\CBS.log
• Windows Updateログ：Server 2016では Get-WindowsUpdateLog で生成する運用が一般的

PowerShell:
Get-WindowsUpdateLog

ログの深掘りまでしなくても、「失敗が多発している」「再試行している」程度が見えれば、まずはSSU/LCUの適用手順を見直す価値があります。

王道の解決策：最新SSU → 最新LCU を「確実に」適用して再スキャン

質問の状況（最新更新は入れている／Catalogに該当KBがない）で最も再現性が高いのは、SSUとLCUを最新に揃え、適用が成功していることを証拠付きで確認し、再スキャンする流れです。途中のKBを時系列で追いかける必要はありません。

手順の全体像

• 対象OS（Windows Server 2016）向けの最新SSUを適用（SSUが別提供されている場合）
• 続けて最新LCUを適用
• 必ず再起動（保留状態の解消）
• OSビルドとパッケージ一覧で「入った」ことを確認
• 脆弱性診断ツールをプラグイン更新したうえで再スキャン

なぜSSU→LCUの順なのか

SSUは更新エンジンそのものの部品です。古いSSUのままLCUを適用すると、インストールが失敗したり、適用済みに見えても内部的に欠けが出たりします。現場では「LCUは入っているはず」でも、実際にはSSU不足が原因でLCUの適用が中途半端なケースがあり、診断ツールがそれを拾ってしまうことがあります。

「手動適用」するときのコツ（オフライン/閉域網でも崩れない考え方）

Microsoft Update CatalogからMSUを取得して手動適用する運用でも、基本は同じです。SSU（必要なら）→LCU→再起動→ビルド確認の順で、途中のKBを埋める発想は捨てます。

• 同じ月の更新でも、LCUが複数の派生（プレビュー等）に分かれることがあるため、運用ポリシーに合うものを選ぶ
• 適用コマンドは wusa.exe（MSU）または dism /add-package（CAB）を状況に応じて使い分ける
• 適用後は必ず再起動し、ビルドとパッケージ一覧で反映確認する

WSUS環境でハマりやすいポイント（“最新のつもり”を潰す）

WSUS環境だと、「最新にしているつもり」が最も起きやすいです。理由は、LCUは承認しているがSSUを承認していない、または自動承認の分類からSSUが漏れている、など運用上のズレが起きやすいためです。

チェック項目	確認の観点	改善の例
製品と分類	Windows Server 2016 の「Updates/セキュリティ更新」が対象になっているか	SSUが含まれる分類を見直し、承認・配布対象に含める
Superseded更新の扱い	置き換え更新を早期に削除しすぎていないか	クリーンアップのポリシーを調整し、必要な期間は保持する
自動承認ルール	LCUだけ承認してSSUが漏れていないか	SSUも自動承認の対象に含める（環境により慎重に）
クライアント側状態	WSUS到達・グループ割当・検出結果が最新か	検出の再実行、レポート更新、再起動の徹底

WSUS配下で「適用できていない」時にありがちな実務パターン

• 承認はされているが、配布タイミングが遅い：メンテ前にクライアントが取得できておらず、再起動後に未反映が残る
• 容量逼迫やクリーンアップでファイルが消えている：承認済みでも実体がなく再ダウンロード待ちになる
• グループポリシーの適用ズレ：想定外のWSUSへ向いている、または更新停止ポリシーが混入している

ここは「WSUS側の承認画面」と「サーバー側の実際のビルド」を突き合わせるのが最短です。

それでも「KB4025339未適用」が消えない場合：診断ツール側の根拠を読む

最新SSU/LCU適用と再起動を行っても、スキャン結果が変わらない場合は、診断ツールが何を根拠に「未適用」と言っているのかを確認します。ここを見ないと、いつまでもKB名だけを追いかけてしまいます。

最優先：認証スキャン（Credentialed Scan）になっているか

Nessus/Tenable系では、認証スキャンに失敗すると、外形情報だけで推測するため誤判定が増えます。たとえば、WMI/Remote Registry/SMBのどれかが遮断されている、ローカル管理者権限がない、UACリモート制限が影響している、などです。

• スキャン設定でWindows認証情報（ドメイン/ローカル）を投入しているか
• 対象サーバーで管理共有（ADMIN$）やWMIが利用できる状態か
• スキャン結果に「認証失敗」や「ローカルチェックできない」旨が出ていないか

プラグイン（定義）が古いと「置き換え」を理解できず誤検知する

脆弱性スキャンは、プラグインが「この脆弱性はどの更新で直るか」を知っています。しかし、プラグインが古いと、後続LCUによる置き換え関係を追従できず、旧KB名（KB4025339）を固定で要求してしまうことがあります。

• Nessusの場合：プラグインが最新か（更新日時）
• Tenable.sc / Tenable.ioの場合：プラグイン更新後に再スキャンしたか
• オフライン環境の場合：プラグイン更新が止まっていないか

プラグイン出力（Plugin Output）を必ず確認する

「KB4025339を入れろ」という表示だけでは判断できません。出力には、次のような手掛かりが書かれていることが多いです。

• 紐づくCVE番号（例：CVE-20xx-xxxx）
• 検出に使った根拠（ファイルバージョン、レジストリ、インストール済みKBの照合など）
• “パッチ適用だけでなく設定変更が必要” という注記

この情報が揃うと、OS側が悪いのか、ツール側の誤検知なのか、追加設定が必要なのかを短時間で判断できます。

「パッチは入っているのに未対策扱い」になる代表例：追加設定（レジストリ/GPO）が要件のケース

セキュリティ修正には、コード修正（パッチ）＋既定値では無効の緩和策（mitigation）という形のものがあります。このタイプは、パッチだけ当てても“安全側の動作”に切り替わらないため、診断ツールが「未対策」と判定することがあります。

質問にあるTenable系の注記でも、レジストリ／グループポリシー変更が必要な可能性が示唆されています。たとえば、LDAPのチャネルバインディング強制（LDAPEnforceChannelBinding）のように、互換性への影響がある設定は、パッチ適用後も既定では緩めのモードのままになりやすく、ここを変えないと“対策済み”と見なされないことがあります。

追加設定が必要かどうかを見抜くコツ

• プラグイン出力に「Enable」「Set registry」「Group Policy」などの記述がある
• KB名だけでなく、具体的なレジストリキー名や推奨値が書かれている
• “対応を有効化するには設定変更が必要” と明記されている

設定変更を行うときの実務注意（Active Directory/LDAP系の例）

LDAP関連の強制（署名、チャネルバインディング等）は、古いクライアントや一部機器（NAS、複合機、古いJavaアプリなど）で認証が失敗するリスクがあります。いきなり本番で強制すると、障害対応に追われます。実務では次の順が安全です。

• まずは監査・ログで未対応クライアントの存在を可視化
• 影響が出る端末・アプリを改修／更新／代替
• 検証環境→段階展開（OU単位など）で強制度を上げる
• 最終的に全体で強制し、診断ツールの判定も確認

「どのCVEの、どの設定が必要か」は環境と診断プラグインによって異なるため、必ずスキャン結果の根拠（CVE/キー/推奨値）に沿って対応します。

現場で使える：切り分けチェックリスト（そのまま作業手順に落とせる形）

順番	チェック内容	合格条件	NGなら次にやること
1	再起動待ちがない	RebootPendingが存在しない	再起動→再スキャン
2	OSビルドが最新更新に追随	更新履歴ページの最新ビルド相当	SSU/LCUの適用状況を確認
3	SSUが最新（別提供されている場合）	DISMでSSUパッケージが最新	SSUを適用→再起動
4	LCUが最新	DISM/HotFixで最新LCUが確認できる	LCUを適用→再起動
5	WSUS配布が正しい	SSU/LCUが承認・配布されている	分類/自動承認/クリーンアップを見直す
6	認証スキャンが成功	スキャンログに認証成功の記録	資格情報/WMI/SMB/権限を見直す
7	プラグインが最新	更新日時が直近	プラグイン更新→再スキャン
8	追加設定要件の有無	プラグイン出力で要否が明確	必要ならレジストリ/GPOを段階的に適用

ベンダー問い合わせを最短化する：Tenable/Nessusに渡すと話が早い情報

「それでも残る」場合、ツール側の誤検知や検出ロジックの問題としてベンダーに確認するのが現実的です。その際、丸投げではなく、再現性と根拠を揃えて渡すと解決が早まります。

渡す情報	例	目的
対象サーバー情報	OSエディション、ビルド番号、Server Core/GUI	適用される更新系統の特定
インストール済み更新の証跡	Get-HotFix結果、dism /get-packages抜粋	「最新LCUを入れた」ことの裏付け
スキャン方式	認証スキャンか、認証成功したか	外形推測による誤判定の切り分け
該当プラグイン情報	プラグインID、バージョン、Plugin Output	検出ロジックの確認・修正依頼
紐づくCVEと要求事項	CVE番号、要求されるレジストリ/GPO（ある場合）	「パッチ＋設定」問題の整理

よくある質問（FAQ）

KB4025339がCatalogにないのは異常ですか？

異常とは限りません。累積更新の置き換えにより、古いKBが「単体で探して入れるもの」ではなくなり、結果として見つけにくくなることがあります。重要なのはKB番号そのものより、最新SSU/LCUが適用されていてビルドが最新かです。

Get-HotFixにKBが出ません。未適用ですか？

未適用とは限りません。Get-HotFix は取得できる更新とできない更新があるため、確実に見るなら dism /online /get-packages でパッケージ一覧を確認してください。診断ツールがどちらを根拠にしているかも、Plugin Outputで把握できます。

「最新更新は入れているのに指摘が消えない」場合、最短の落としどころは？

（1）再起動待ち排除 →（2）最新SSU/LCUの適用証跡（ビルド・DISM出力）を揃える →（3）プラグイン更新・認証スキャンで再スキャン、の順で潰します。それでも残るなら、誤検知/定義不備としてベンダー確認が最短です。追加設定が必要なタイプなら、根拠に沿って段階的に設定を入れていきます。

まとめ：KB名ではなく「最新状態＋根拠」で解決する

• Windows Server 2016の更新は累積更新が基本のため、KB4025339を単体で探して入れる必要は原則ない
• まずは最新SSU→最新LCU→再起動で、OSを最新状態に揃える（SSUが別提供されている場合）
• WSUS環境ではSSUが配られていないなど運用由来のズレを疑う
• それでも残る場合は、診断ツールのプラグイン更新と認証スキャン、Plugin Output（根拠）の確認が決め手
• 一部の指摘は「パッチ＋レジストリ/GPO」で初めて有効化されるため、CVEと要求設定に沿って段階的に対応する

結局のところ、古いKB番号は“症状のラベル”に過ぎません。OSを最新のSSU/LCUで固め、再起動で反映させ、スキャナの根拠（CVE・検出方法・追加設定）に沿って潰していく――この手順が、再現性の高い最短ルートです。