Microsoft Defender が Trojan:Win32/Wacatac.B!ml を検出した一方で、Microsoft Safety Scanner（MSERT）のフルスキャン完了後は「脅威なし」と表示される——この矛盾に見える現象は珍しくありません。本記事では、なぜ途中経過で大量の「感染候補」がカウントされ、最終結果がクリーンになるのかを仕組みから解説し、具体的な確認・対処手順、誤検知の正式な解消方法、再発防止のコツまでを実務目線でまとめます。
現象の要点と結論
まず結論から整理します。
- Safety Scanner のスキャン画面で増えていく「感染数」は、最終判定前の 仮検出（suspect/候補） を含む概数です。最終レポートが「脅威なし」なら、実害（確定した感染）はありません。
- Defender の通知と Safety Scanner の最終レポートは、判定タイミング・エンジン構成・クラウド保護の有無 などが異なるため、結果が一致しないことがあります。
- 自身で「許可（Allow）」したファイルは、その項目のみ検出対象外になりますが、ほかのファイルやシステム全体の保護は継続されます。不要なら「許可」を取り消せます。
- 誤検知を恒久的に解決したい場合は、サンプル提出（誤検知報告） により定義調整が行われ、今後の検出が解消されることがあります。
Trojan:Win32/Wacatac.B!ml とは何か（実務的な理解）
Wacatac.B!ml は、Defender の機械学習（ML）が高リスク挙動のパターンに一致した際に付与される汎用（ジェネリック）名です。これは特定の亜種名ではなく「検出ロジックに合致した疑い」であることを示す場合が多く、以下の要素で誤検知が生じやすくなります。
- 未署名の自作ツール・社内ツール・ユーティリティ
- パッカー/インストーラ（NSIS, Inno, SFX など）や 自己展開・自己更新の振る舞い
- スクリプト実行、プロセス注入、ブラウザの一時領域走査などの高感度ヒューリスティック
つまり、Wacatac.B!ml の検出だけで直ちに「確実な感染」とは限らず、最終判定（再スキャン・クラウド判定・サンドボックス評価）を経て無害とみなされることが現場ではしばしば起こります。
なぜ「途中で 250 件」→「最終は脅威なし」になるのか
Safety Scanner の内部処理を実務者向けに要約すると、以下の多段階です。
- 走査段階（一次）：膨大なファイルをヒューリスティック＋既知定義で走査。容疑（suspect）に該当した項目を「感染候補」として暫定カウントします。
- 精査段階（二次）：候補に対して詳細シグネチャ・ML・振る舞い関連のルールで再評価。アーカイブ内の重複・一時ファイル・キャッシュなどを除外/合算調整します。
- 確定段階（最終）：駆除・隔離・修復の可否を判断。最終的に 「脅威なし」＝確定感染なし と結論づけられれば、途中の暫定カウントはレポートから除外されます。
途中で数が膨らむ主な要因は次のとおりです。
- アーカイブ/コンテナの多重展開（ZIP・NUPKG・パッケージキャッシュ等で同一ペイロードが多数出現）
- ビルド/一時フォルダでの多数の中間成果物（開発マシンで顕著）
- ブラウザキャッシュやダウンロード一時領域のヒット
- PUA/評価対象（望ましくない可能性のあるアプリ）が候補として計上されたが、最終的にはユーザー選好やルールで除外
したがって、「最終レポート＝脅威なし」が出ている限り、そのジョブにおける確定感染はゼロと解釈して差し支えありません。
Defender と Safety Scanner の違い（結果が食い違う理由）
| 項目 | Microsoft Defender | Microsoft Safety Scanner（MSERT） |
|---|---|---|
| 更新 | エンジン/定義が日常的に更新。クラウド保護を併用可能。 | ダウンロード時点の定義を内包。実行中は原則固定。 |
| クラウド判定 | 既定で有効化される構成が多い。 | クラウドへの依存度が低く、ローカル定義重視。 |
| 常駐保護 | リアルタイム。挙動監視・ブロックが豊富。 | オンデマンド・単発のスキャンツール。 |
| 結果の扱い | 「許可」「隔離」「除外」など多彩なポリシー。 | 実行ジョブ内での検出/駆除に限定。最終判定で候補が消えることがある。 |
この差分により、Defender の通知ではヒットしたが、Safety Scanner 最終報告ではクリーンという結果の不一致が起こり得ます。
「許可（Allow）」にした場合の扱いと注意点
Defender の「保護の履歴」で手動「許可」したファイルはそのファイル単体のみ検出対象から外れます。これは「除外（Exclusions）」や「フォルダ丸ごと除外」とは性質が異なります。
| 機能 | 対象範囲 | 代表的な使い所 | リスク |
|---|---|---|---|
| 許可（Protection History） | そのイベント対象ファイルのみ | 信頼する自作 EXE を単発で実行したい | 誤操作で本物の脅威も許可するリスク |
| 除外（設定 > ウイルスと脅威の防止） | フォルダ/拡張子/プロセスなど広範 | ビルドフォルダなど誤検知が多い領域 | 範囲が広すぎると攻撃面が拡大 |
| 許可されたアプリ（ランサムウェア防止） | 特定アプリのフォルダ保護バイパス | 正規アプリの書込みを確実に通す | 誤登録で書込みが広がる |
許可を取り消すには、Windows セキュリティの「保護の履歴」を開き、該当イベントを表示して「操作」から許可解除/削除を実行します。表示語はバージョンにより「許可の削除」「ブロックに戻す」など差異があります。
誤検知を正式に解消する（サンプル提出）
社内配布やプロダクトでの誤検知は、一時的な許可では再発します。恒久対策として以下を推奨します。
- サンプル提出（誤検知報告）：Microsoft のファイル提出ポータルから該当バイナリを提出し、false positive として報告します。承認されると、定義更新で検出が解消されることがあります。
- コード署名：信頼できる証明書で署名し、タイムスタンプも付与。未署名より誤検知率が低下し、ユーザー環境での信頼度が向上します。
- 挙動の健全化：自己展開・自己更新・スクリプト埋め込み等、“防御側から怪しく見える”処理を最小化。必要な場合はオプトイン設定に分離する。
追加の安全確認：オフラインスキャンと二次意見
心理的な不安を払拭したい場合、以下を実施すると安心感が高まります。
- Defender オフラインスキャン：OS 起動前に検査・駆除を行います。Windows セキュリティ > ウイルスと脅威の防止 > スキャンのオプション から実行。
- 他社製ツールでの二次スキャン：独立エンジン（例：侵入防止特化ツール等）のフルスキャンを 1 回。検出が再現しなければ実害の可能性はさらに低下。
- 再起動後の監視：通知が収まるか、イベントログに新しい検出が現れないか確認。
実務で役立つ確認ステップ（チェックリスト）
1) 定義とプラットフォームの更新
PowerShell（管理者）:
Update-MpSignature
Get-MpComputerStatus | Select-Object AMProductVersion, AMEngineVersion, AntivirusSignatureVersion
更新後、同じファイルで再検証すると判定が収束することが多いです。
2) 設定の過剰除外が無いか点検
- 「ウイルスと脅威の防止の設定」>「除外の追加または削除」
- ビルドフォルダを除外する場合は最小範囲に限定（例：bin\Debug のみ）。
3) 保護の履歴で「許可」を整理
誤って許可した項目があれば解除します。安全側に倒したいなら「許可」ではなくサンプル提出→定義解消が王道です。
4) 監査ログの確認（再発監視）
PowerShell（管理者）:
Get-WinEvent -LogName "Microsoft-Windows-Windows Defender/Operational" -MaxEvents 100 |
Select-Object TimeCreated, Id, Message
| 代表イベント ID | 意味 |
|---|---|
| 1116 | マルウェア検出 |
| 1117 / 1118 | 処理成功 / 失敗（隔離・削除など） |
| 5007 など | 設定変更（除外追加等） |
5) 単一ファイルの精密スキャン
コマンドプロンプト（管理者）:
"%ProgramFiles%\Windows Defender\MpCmdRun.exe" -Scan -ScanType 3 -File "C:\Path\To\YourApp.exe"
特定ファイルのみを対象に、現在の定義での結果を可視化できます。
6) Safety Scanner のログを読む
- ログ場所：
C:\Windows\debug\msert.log - スキャン結果の要約、処理結果、検出候補の推移が出力されます。
PowerShell（管理者）:
Get-Content "C:\Windows\debug\msert.log" -Tail 200
よくある誤解と落とし穴
- 「途中経過の感染数＝確定感染数」ではない：これはあくまで暫定候補。最終レポートが正です。
- 「許可＝恒久解決」ではない：PC を変えれば再発、ユーザーが変わっても再発。定義側の解消を目指すべき。
- 「コード署名で絶対に検出されない」ではない：署名は強いシグナルだが、挙動が怪しければ検出され得ます。
- 広すぎる除外設定：Downloads やユーザープロファイル丸ごとの除外は厳禁。攻撃面が開きます。
開発・運用現場向け：誤検知を減らすビルド運用のベストプラクティス
- 再現性の高いビルド：ビルドサーバーで決まったツールチェーン・オプションを使用。乱数シードや埋め込みタイムスタンプの不定性を抑え、ハッシュの揺らぎを減らす。
- 不要なパッキング・難読化を避ける：本当に必要なときだけ使う。自己展開や自己解凍は検出を招きやすい。
- コード署名とタイムスタンプ：CI で自動署名。テスト署名と本番署名を分離。
- 配布前の多エンジン事前検証：公開前に複数エンジンでスキャン。誤検知があればサンプル提出してから配布。
- ユーザー教育：許可を促さず、「許可は最後の手段」と伝える。まずは提出・定義解消へ。
疑わしい兆候が続く場合の追加トリアージ
最終レポートがクリーンでも、以下の兆候が残る場合は深掘りを検討します。
- 再起動後も Defender の新規検出通知が継続
- 未知の常駐サービス/タスク/ドライバが増殖
- プロキシ設定・Hosts・証明書ストアに身に覚えのない変更
- 不審な外向き通信が持続（CPU/ネットワーク使用率の異常）
その場合は以下を実施します。
Autoruns（Sysinternals）でスタートアップの棚卸し
Task Scheduler / Services / Drivers の差分確認
PowerShell: Get-ScheduledTask / Get-Service / Get-NetTCPConnection
ブラウザ拡張の棚卸しとキャッシュクリア
それでも疑いが晴れなければ、オフラインスキャン＋隔離環境でのフォレンジックへ段階を上げます。
開発者・情シスのための実用スニペット集
Defender 設定の最小限見直し
PowerShell（管理者）:
# クラウド保護とサンプル提出を有効化（ポリシー許す範囲で）
Set-MpPreference -MAPSReporting Advanced
Set-MpPreference -SubmitSamplesConsent SendSafeSamples
除外はピンポイントで
# ビルドの生成物フォルダだけを限定除外（例）
Add-MpPreference -ExclusionPath "C:\Repos\MyApp\bin\Debug"
ファイル単位の再評価
"%ProgramFiles%\Windows Defender\MpCmdRun.exe" -Scan -ScanType 3 -File "C:\Path\To\YourApp.exe"
ケース別・意思決定フローチャート（文章版）
A. Defender 通知が 1 回だけ、Safety Scanner 最終「脅威なし」
→ 定義更新後に単一ファイル再スキャン。再現しなければ経過観察で可。
B. Defender 通知が断続的に再発する
→ オフラインスキャン、イベント 1116/1117 系の連続性を確認。持続性があれば深掘り。
C. 自作ツールのみが検出される
→ 一時許可ではなく、サンプル提出＋署名付与。挙動の見直し。
D. 複数エンジンで同一検出が再現
→ まず隔離。ネットワーク分離。証拠保全のうえクリーンインストール含めた復旧計画を検討。
FAQ（現場でよく出る質問）
途中で「感染ファイル数」が増え続けて不安です。
それは候補数であり、最終判定で整理されます。アーカイブやキャッシュを多く含む環境では数が伸びがちです。
「許可済み」と出た項目を元に戻せますか？
はい。「保護の履歴」から該当イベントを開き、「許可解除/削除」を選びます。表示語は OS/Defender のバージョンで多少異なります。
Safety Scanner のログはどこですか？
C:\Windows\debug\msert.log に出力されます。最後の要約行で最終判定を確認してください。
誤検知を根本的に消すには？
Microsoft のサンプル提出ページから対象ファイルを誤検知として提出します。合わせてコード署名や挙動の見直しを行うと再発率が下がります。
開発フォルダを丸ごと除外しても良いですか？
推奨しません。最小限のサブフォルダに限定してください。広い除外は攻撃リスクを高めます。
まとめ：落ち着いて「最終判定」を見る。恒久解決は提出と署名
Safety Scanner で途中表示される「感染数」は、確定する前の仮検出です。最終レポートが「脅威なし」であれば、そのスキャンにおいては実害は未確認。とはいえ、Defender 側で断続的に通知が続く・イベントが積み上がる・他エンジンでも再現する——といった状況では、オフラインスキャンや詳細トリアージを行いましょう。
自作・社内配布の実行ファイルが検出される場合は、一時的な許可ではなく、サンプル提出による定義調整＋コード署名＋挙動の整理が最短距離です。運用では除外の範囲を絞り、ログとイベントで再発監視。これらをルーチン化すれば、Wacatac.B!ml をはじめとする ML 検出に対して、過度に怯えることなく理性的に対処できます。
付録：確認手順のテンプレ（コピペ可）
更新＆再チェック
# 定義更新
Update-MpSignature
# バージョン確認
Get-MpComputerStatus | Select AMProductVersion, AMEngineVersion, AntivirusSignatureVersion
# ファイル単体スキャン
"%ProgramFiles%\Windows Defender\MpCmdRun.exe" -Scan -ScanType 3 -File "C:\Sample\app.exe"
# オフラインスキャン（再起動）
Start-MpWDOScan イベント監査
Get-WinEvent -LogName "Microsoft-Windows-Windows Defender/Operational" -MaxEvents 200 |
Where-Object { $_.Id -in 1116,1117,1118,5007 } |
Select-Object TimeCreated, Id, Message
Safety Scanner ログ
Get-Content "C:\Windows\debug\msert.log" -Tail 200
除外を最小化
# 例：ビルド生成物フォルダのみ
Add-MpPreference -ExclusionPath "C:\Repos\MyApp\bin\Release"
付録：誤検知が起きやすいパターン一覧
| パターン | なぜ誤検知しやすいか | 緩和策 |
|---|---|---|
| 未署名の EXE/DLL | 未知ファイルとして ML スコアが上がる | 信頼済み CA のコード署名＋タイムスタンプ |
| 自己更新・自己展開 | マルウェア挙動に類似 | 外部アップデータに分離、ユーザー同意を明示 |
| 難読化・パッキング | 解析回避のシグナルとして判定 | 必要最小限、署名前に解除 |
| 多数の一時ファイル生成 | キャッシュやビルド中間物で候補が急増 | 一時領域の整理、除外は最小化 |
| ブラウザ拡張のバンドル | PUA のしきい値に抵触 | 同梱しない、明示的な同意フローに |
付録：エンドユーザー向けの安全運用メモ
- 通知を見たらまず更新（Windows Update と Defender の定義）
- 最終レポートを基準に判断。疑念が残るときはオフラインスキャン。
- 許可は例外的措置。可能な限り提出・署名で根治。
- ダウンロード元・配布元の信頼性を確認。ハッシュの提示があれば突合。
コメント