WinRARをwingetで更新した直後に、Microsoft Defenderが「C:\Program Files\WinRAR\Default.SFX」をTrojan:Win32/Egairtigado!rfnとして隔離するケースがあります。誤検知か感染かを最短で切り分ける手順と、追加の確認ポイントをまとめます。
現象の整理:何が検出され、何が不安ポイントなのか
まずは状況を「事実」と「推測」に分けて整理します。Defenderの検出は重大(Severe)と表示されることがあり、しかも更新直後・SYSTEM権限での検出だと「アップデート経由で混入?」と疑いやすい一方で、実際には誤検知やヒューリスティック(挙動・特徴量)判定の可能性も十分あります。
| 項目 | 内容(例) | 読み解きポイント |
|---|---|---|
| 検出名 | Trojan:Win32/Egairtigado!rfn | 特定ファミリ名ではなく、Defender側の検出名。脅威ページでも技術詳細が出ない場合があります。 |
| 対象ファイル | C:\Program Files\WinRAR\Default.SFX | WinRARのSFX(自己解凍)関連モジュール。正規コンポーネントでも検出対象になり得ます。 |
| 検出元 | System(SYSTEM権限) | Defenderなどのセキュリティ製品はSYSTEM権限で動作します。「SYSTEM=犯人」とは限りません。 |
| 発生タイミング | winget更新直後 | 更新でファイルが置き換わった直後にスキャン→検出、という流れが起きやすい |
| VirusTotal | 白黒つかない | エンジンごとに判定基準が違うため、最終的にはDefender側(Microsoft)に確認するのが確実 |
まず結論:最短で白黒つけるなら「Microsoftへファイル提出」
この手の「正規ソフトの正規ファイルがDefenderに隔離された」系は、現場で悩み続けるよりMicrosoft Security Intelligence(WDSI)のファイル提出に載せるのが最短ルートです。実際、WinRAR更新後にDefault.SFXがTrojan:Win32/Egairtigado!rfnとして隔離されたケースでも、Microsoft側から隔離ファイルをWDSIポータルへ提出して解析してもらう案内がされています。
| やること | 目的 | ゴール |
|---|---|---|
| WDSI「Submit a file」で提出 | Defenderの検出が誤検知か真陽性かを公式に判定 | Microsoft側の分析結果(誤検知なら修正、真陽性なら対処) |
| 提出時にログ・状況を添える | 解析のスピードと精度を上げる | 「どこから入手」「どう更新」「どの環境」で起きたかを伝える |
WDSI(Microsoft Security Intelligence)への提出手順
WDSIポータルには「Home customer / Enterprise customer / Software developer」など提出区分があり、一般のPC利用でも提出できます。ファイルサイズ上限や、ZIP/RARを暗号化する場合のパスワード指定も明記されています。
- 提出先:Microsoft Security Intelligence の「Submit a file for malware analysis」
- 最大ファイルサイズ:50MB
- ZIP/RARで暗号化する場合:パスワード infected
- 追加情報:英語で書くよう推奨(入手経路、影響、端末情報など)
提出前に揃えておく情報(そのままフォームに転記できる)
WDSIのフォームには「検出名」「定義(Definition)バージョン」などの項目があります。事前に以下を控えると、提出がスムーズです。
| 控える項目 | 例 | 確認方法 |
|---|---|---|
| 検出名 | Trojan:Win32/Egairtigado!rfn | Windows セキュリティの「保護の履歴(Protection history)」で確認 |
| 検出ファイルパス | C:\Program Files\WinRAR\Default.SFX | 同上 |
| 定義(Security intelligence / 定義)バージョン | 例:1.xx.xxxx.x | PowerShellで Get-MpComputerStatus の AntivirusSignatureVersion を確認(環境により項目名が表示されます) |
| Defenderエンジン/プラットフォーム | 例:4.18… | 同じく Get-MpComputerStatus で確認 |
| 更新方法 | winget upgrade / winget install | 実行したコマンドをそのまま記録 |
追加情報(英語)テンプレ
WDSIは追加情報を英語で書くよう促しているため、貼り付け用テンプレを用意します(そのまま編集して使えます)。
Summary:
Microsoft Defender quarantined "Default.SFX" right after updating WinRAR via winget.
Detection:
- Threat name: Trojan:Win32/Egairtigado!rfn
- File path: C:\Program Files\WinRAR\Default.SFX
- Severity: Severe
- Detection source: System (NT AUTHORITY\SYSTEM)
Environment:
- Windows edition/version: (e.g., Windows 11 23H2)
- Defender signature version: (AntivirusSignatureVersion)
- Defender engine/platform version: (AMEngineVersion / AMProductVersion)
Update method:
- Command used: winget upgrade --id RARLab.WinRAR (or exact command)
- winget version: (winget --version)
- winget sources: (winget source list)
Notes:
VirusTotal results were inconclusive. Please confirm whether this is a true positive or a false positive and advise on remediation.
Default.SFXとは:WinRARの「自己解凍(SFX)用モジュール」
Default.SFXは、WinRARでGUIの自己解凍(SFX)アーカイブを作るためのモジュールとして提供されています。RAR用がDefault.SFX、ZIP用がZip.SFXで、64bit版(Default64.SFXなど)も存在します。
ここが重要なのですが、SFXは「圧縮ファイル」ではなく実行形式(exe相当)として動作します。RARLAB側も「SFXは実行ファイルであり、信頼できる入手元のものだけ実行すべき」という趣旨を強調しています。さらに、SFXの実行部分はユーザーが真正性を簡単に検証できないため、悪意あるコードを混ぜたSFXが配布され得る点や、SFXには抽出後にプログラムを実行する機能がある点も説明されています。
つまり、Default.SFX自体が「怪しい」というより、SFXという仕組みがインストーラにも便利/攻撃者にも悪用されやすい領域であるため、Defender側が機械学習やヒューリスティックで「似た特徴」を拾ってしまうと、正規ファイルでも検出される余地が生まれます。
なぜ「winget経由の更新直後」に検出されやすいのか
更新直後は、ファイルが新規に配置・置換されたタイミングです。Defenderのリアルタイム保護は、新規作成や書き換えを契機にスキャンが走ることが多く、結果として「更新が原因で混入した」と見えやすい構図になります。
ここで押さえるべき切り分け軸は次のとおりです。
| 疑うポイント | 起き方 | 切り分けの決め手 |
|---|---|---|
| 誤検知(Defender側) | 特定の定義バージョンで突然検出→後日解消 | WDSI提出で「Incorrectly detected」と判定される |
| 公式配布物の問題(サプライチェーン含む) | どのPCでも同一ファイルが再現性高く検出 | 隔離ファイル提出+別環境(Sandbox等)で同じ挙動を確認 |
| ローカル環境の汚染/改ざん | 同じWinRAR版でも自分の端末だけ検出 | フルスキャン/オフラインスキャン、他の痕跡の有無 |
| wingetの取得元の問題 | 非公式ソース追加、プロキシ改ざん、署名不整合など | winget source / show / download と署名・ハッシュの確認 |
追加の切り分け:wingetの提供元・URL・ハッシュを確認する
wingetは、どのソースから取得しているかと、そのパッケージがどのインストーラURL・SHA256で定義されているかを確認できます。これにより「更新経路が正しいか」をかなりの精度で検証できます。
まず確認:wingetのソース一覧
winget source listで、現在有効なソースが表示されます。Microsoft Learnの例では、msstore / winget / winget-font が表示され、各ソースのURLと信頼レベル(Trustedなど)も確認できます。見覚えのないソースが追加されているなら、その時点で更新経路の安全性に赤信号です。
winget source list
次に確認:WinRARパッケージ情報(Installer URL / SHA256)
winget showは、指定アプリの詳細(ソースやメタデータ)に加えて、Installer UrlとInstaller SHA256を表示します。これが「どこからインストーラを取ってきたか」「改ざんが起きていないか」の重要証跡になります。
winget show -e --id RARLab.WinRAR
表示結果の見方(チェック観点)
- Source:想定どおり(通常はwinget)か
- Publisher / Publisher Url:不自然な値になっていないか
- Installer Url:公式ドメイン/正規配布元に見えるか
- Installer SHA256:少なくともwingetのマニフェストが想定するハッシュが提示されているか
可能なら有効:インストーラを「実行せず」取得して検証する
winget downloadを使うと、インストーラ等をダウンロードできます。デフォルトではユーザーのDownloadsに保存され、--download-directoryで保存先を変えられます。なお、--ignore-security-hashのようなハッシュチェック無視は「推奨しない」と明記されています(検証目的でも基本は避けるべきです)。
winget download --id RARLab.WinRAR --download-directory C:\Temp\winget-download
ダウンロード後にやると有効な確認(例)
- PowerShellでハッシュ取得:
Get-FileHash - デジタル署名の確認:
Get-AuthenticodeSignature(署名がある場合)
Defender側の追加チェック:他の感染痕跡がないかを確認
WDSI提出が本命とはいえ、「もし真陽性だったら?」に備えて、端末全体の衛生確認も同時に進めるのが安全です。ポイントは定義更新→フルスキャン→(必要なら)オフラインスキャンです。
定義(Security intelligence)を最新化
Defenderの定義更新はPowerShellからも可能です。Update-MpSignatureは最新の定義へ更新するコマンドとして案内されています。
Update-MpSignature
フルスキャンを実行(PowerShellでもGUIでもOK)
PowerShellのStart-MpScanでスキャンを開始できます。疑わしい状況では、まずフルスキャンを実施して他の痕跡がないかを確認します。
Start-MpScan -ScanType FullScan
より強い確認:Microsoft Defender Offline スキャン
オフラインスキャンは、通常のWindows環境(カーネル)の外側からスキャンすることで、ブート領域やルートキットなど「居座り型」を狙います。Microsoft Learnでも、通常のWindowsカーネル外でスキャンできる点や、Windows セキュリティアプリから実行できる手順が説明されています。
- Windows セキュリティを開く
- 「ウイルスと脅威の防止」→「スキャンのオプション」
- 「Microsoft Defender オフライン スキャン」を選び「今すぐスキャン」
補足:BitLockerを有効にしている環境では、再起動時に回復キーを求められる場合があるため、事前に回復キーや手順を把握してから実行してください。
隔離されたDefault.SFXを扱うときの注意点
隔離済みのファイルに対して、安易に「復元(Restore)」「許可(Allow)」を選ぶのは危険です。Windows セキュリティの「保護の履歴(Protection History)」には、隔離された脅威に対して「削除(Remove)」「復元(Restore)」などのアクションがあり、許可はリスクがある旨の注意も記載されています。
どうしても提出のためにファイルを取り出す必要がある場合は、次の優先順位で“安全側”に倒すのが現実的です。
| 優先度 | 方法 | メリット | 注意点 |
|---|---|---|---|
| 高 | 別環境(Windows Sandbox/検証VM)でWinRARを入れ直し、同じDefault.SFXが検出されるか再現して提出 | 本番端末を危険に晒しにくい | 再現できない場合は「本番端末固有」の可能性が残る |
| 中 | WDSIの「Search file hash」を先に試す(ハッシュが分かる場合) | ファイルを復元せずに情報が得られる可能性 | 隔離ファイルのハッシュが取得できないと使いにくい |
| 低 | 本番端末で隔離ファイルを復元してコピー→提出→再隔離/削除 | 「その端末で隔離された現物」を提出できる | 真陽性だった場合のリスクが上がる(実行しない・ネットワーク遮断など厳重に) |
判定が出た後の動き:誤検知だった場合/真陽性だった場合
誤検知(False Positive)だった場合にやること
- Defenderの定義更新を実施し、フルスキャンを回す(残骸がないか確認)
- WinRARをいったんアンインストール→公式入手元(またはwingetの情報を精査した上で)で再インストールし、同現象が再発するか確認
- 企業環境なら、Defender for Endpointのガイドラインに沿って「誤検知提出」「アラート分類」なども実施(WDSI提出が基本解)
真陽性(True Positive)だった場合にやること
- 端末をネットワークから切り離す(有線LAN抜線、Wi‑Fi切断)
- Defender Offlineスキャンを実行し、追加の潜伏がないか確認
- 他の端末にも同じ検出がないか横展開調査(企業ならEDRでハッシュ検索・インシデント対応)
- 重要アカウントのパスワード変更、セッション失効、二要素認証の見直し
- 状況によってはバックアップ→初期化/再展開を検討(侵害範囲が不明な場合)
再発防止:wingetとDefender運用で押さえるチェックポイント
今回のような「正規ソフト×検出」は、単発で終わらないこともあります。次の運用で“疑うべき場所”を最初から狭めておくと、次回の切り分けが速くなります。
| チェック | 狙い | 具体策 |
|---|---|---|
| wingetソースの棚卸し | 取得元の正当性を担保 | winget source listで見慣れないソースを排除/必要ならリセットを検討 |
| パッケージのURL/ハッシュ確認 | “どこから落としたか”を説明できる状態に | winget showでInstaller Url/SHA256を控える |
| ハッシュ無視オプションを使わない | 改ざん検知を弱めない | --ignore-security-hashは原則避ける(非推奨) |
| Defenderの定義更新・スキャンの習慣化 | “他の痕跡がない”を説明できる状態に | Update-MpSignature、必要に応じてフルスキャン/オフラインスキャン |
よくある質問
VirusTotalが曖昧でした。放置しても大丈夫?
放置はおすすめしません。VTは参考情報として有用ですが、判定が割れるケースは現実にあります。今回のようにDefenderが隔離したなら、DefenderのベンダーであるMicrosoftへ提出して判定してもらうのが最も確実です。
「SYSTEMが検出した」=すでに侵害されている?
必ずしもそうではありません。Defenderの保護機能自体がSYSTEM権限で動作するため、検出元にSystemと出ることは自然です。重要なのは、他の痕跡(別ファイルの検出、永続化、通信、資格情報の不正利用など)があるかどうかです。
Default.SFXは消してよい?
Default.SFXはSFX作成に使われるモジュールのため、削除するとWinRARの一部機能に影響する可能性があります。まずはWDSI提出で判定を取り、その結果に従って「再インストール」「定義更新待ち」「(企業なら)許可/除外の検討」を進めるのが安全です。
誤検知だった場合、どうすれば再発しにくい?
一番効くのは「更新経路の透明化」です。wingetのソース、Installer URL、SHA256、Defender定義バージョンを記録できる状態にしておくと、次に同じ事象が起きても“疑うべき場所”が一気に絞れます。

コメント