.NETの「From poisoned search results to GPU mining」は、.NETの新機能追加や通常のバージョンアップではなく、Microsoftが公表したクリプトジャッキング攻撃キャンペーンの調査情報です。まず押さえるべき結論は、.NETアプリを直ちに移行すれば解決する問題ではなく、偽の検索結果、AIチャットボット経由の不審リンク、ScreenConnectの悪用、Microsoft署名の.NET Framework系ユーティリティを使った防御回避をまとめて確認する必要がある、という点です。Microsoft Security Blogでは米国時間2026年5月26日公開として掲載されています。(Microsoft)
管理者や開発者がすぐに見るべきなのは、最近ダウンロードしたシステムユーティリティ、未承認のScreenConnectクライアント、RuntimeHost.exeやD3F4E2A1を含む不審な永続化設定、そしてInstallUtil.exeやMSBuild.exeなど正規の.NET関連ユーティリティの不自然な実行です。特にGPUを搭載した開発用PC、AI検証端末、映像編集端末、ゲーミング用途に近い高性能端末は優先して確認してください。
.NETの更新ではなく「.NETユーティリティの悪用」に注意する
今回の公式情報で重要なのは、.NETそのものの脆弱性が新たに公表されたわけではない点です。Microsoftが説明しているのは、攻撃者が正規ソフトに見せかけたダウンロードサイトからマルウェアを配布し、その後の防御回避にMicrosoft署名の.NET Framework付属ユーティリティを悪用する攻撃の流れです。
攻撃で名前が挙がっている正規ユーティリティには、次のようなものがあります。
| 悪用対象として挙げられたユーティリティ | 管理者が見るべきポイント |
|---|---|
InstallUtil.exe | 通常のインストール作業以外で起動していないか |
RegAsm.exe | ユーザーフォルダーや一時フォルダー配下の不審プロセスから呼ばれていないか |
RegSvcs.exe | 開発端末以外で突然実行されていないか |
MSBuild.exe | ビルド作業と関係ない時間帯・親プロセスから起動していないか |
AppLaunch.exe | 通常の業務端末で長時間動作していないか |
AddInProcess.exe | ネットワーク通信や高いCPU/GPU使用率を伴っていないか |
aspnet_compiler.exe | Webアプリのビルド・配置作業と無関係に動作していないか |
Microsoftの分析では、攻撃者はこれらの正規バイナリを一時停止状態で起動し、プロセスホロウイングによって悪意あるマイニングコードを実行していました。つまり、プロセス名だけを見るとMicrosoftの正規ツールに見えるため、「Microsoft署名だから安全」と判断する運用は危険です。(Microsoft)
今回の攻撃キャンペーンで何が変わったのか
今回の.NET関連クリプトジャッキングで注目すべき変更点は、攻撃者が単にマルウェアをばらまくのではなく、高性能GPUを持つ利用者に届きやすい経路を選んでいることです。
Microsoftは、攻撃者がCrystalDiskInfo、HWMonitor、Display Driver Uninstaller、FurMark、K-Lite Codec Pack、PDFgearなど、PC管理やGPU負荷テスト、メディア関連でよく検索されるツールになりすましたと説明しています。これらはPCに詳しい利用者や高性能GPUを持つ利用者が検索しやすいソフトであり、GPUマイニングの収益性を高める狙いがあると見られます。(Microsoft)
さらに、悪性サイトは従来の検索エンジン汚染だけでなく、LLMベースのAIチャットボットとのやり取りを通じて提示された可能性も報告されています。ただし、Microsoftはこれを特定のAIサービス全体の構造的問題とは断定しておらず、観測パターンと関連データに基づくものとして説明しています。(Microsoft)
実務上の変化は明確です。これまでは「検索広告や検索結果の偽サイトに注意」と教育していれば一定の効果がありましたが、今後は「AIにおすすめされたダウンロードリンクでも、公式サイトかどうかを確認する」運用が必要になります。
攻撃の流れを管理者目線で整理する
今回の攻撃は、利用者が偽サイトからZIPファイルをダウンロードするところから始まります。ZIPには正規ソフトの実行ファイルと、autorun.dllという悪意あるDLLが含まれます。利用者が正規に見える実行ファイルを起動すると、同じフォルダー内のDLLが読み込まれ、ScreenConnectの不正インストールにつながります。(Microsoft)
| 段階 | 攻撃内容 | 確認すべきログ・設定 |
|---|---|---|
| 初期接触 | 検索結果やAIチャットボット経由で偽ダウンロードサイトに誘導 | プロキシ、DNS、Web保護、ブラウザ履歴 |
| ダウンロード | 偽装ツールのZIPを取得 | ダウンロードフォルダー、Temp、EDRのファイル作成イベント |
| DLLサイドローディング | 正規EXEがautorun.dllを読み込む | DeviceImageLoadEvents、DLL読み込み元 |
| ScreenConnect設置 | msiexec.exeでリモート管理ツールをサイレント導入 | サービス作成、msiexec /quiet、RMM接続先 |
| 追加ペイロード | ScreenConnect経由でSimpleRunPE.exeなどを投入 | ファイル転送、PowerShell、スケジュールタスク |
| 永続化 | タスク、Runキー、スタートアップに登録 | Windows System Health系タスク、WinSysCache、RuntimeHost.lnk |
| 防御回避 | Defender除外と.NET系正規プロセスへのホロウイング | Add-MpPreference、除外設定、正規バイナリの異常挙動 |
| GPUマイニング | gminer、lolMiner、SRBMiner-MULTIなどを実行 | GPU使用率、外部通信、マイニングプロセス |
ScreenConnectは正規のリモート管理ツールであり、ツール自体が悪いわけではありません。問題は、攻撃者がその正規機能を悪用して永続的なリモートアクセスを確立している点です。Microsoftは、暗号資産マイニングだけでなく、後続の情報窃取、横展開、ランサムウェアにつながる可能性にも触れています。(Microsoft)
影響を受けやすい端末と優先確認の基準
すべての.NET利用環境が同じ優先度で危険というわけではありません。まずは「攻撃者にとって価値が高い端末」から確認するのが現実的です。
| 優先度 | 対象端末 | 理由 |
|---|---|---|
| 高 | 高性能GPU搭載のWindows PC | GPUマイニングの収益性が高い |
| 高 | 開発者PC、AI検証端末、3D/CAD端末、映像編集端末 | .NET系ツールやビルドツールが存在し、不審実行が埋もれやすい |
| 高 | ScreenConnectなどRMMを利用している端末 | 正規RMMとの見分けが難しく、永続アクセスに悪用されやすい |
| 中 | 管理者権限を持つ一般業務端末 | サイレントインストールやDefender除外変更の影響が大きい |
| 中 | 最近システムユーティリティを検索・導入した端末 | 偽サイトからの感染経路に一致する |
| 低〜中 | GPUを持たない一般端末 | 収益性は低いが、リモートアクセスの踏み台になる可能性はある |
開発者PCではMSBuild.exeやInstallUtil.exeが正規作業で使われることがあります。そのため、単純にプロセス名だけでブロックすると業務影響が出ます。判断基準は「誰が、どこから、何の親プロセスで、どの時間帯に、どの通信先へ接続しているか」です。
例えば、Visual StudioやCI/CDエージェント配下で動くMSBuild.exeは通常業務の可能性があります。一方、DownloadsやAppData\Local\Tempから展開されたファイル、RuntimeHost.exe、不明なScreenConnectセッション、GPU使用率の急上昇を伴う場合は調査対象にするべきです。
管理者がすぐ確認すべきMicrosoft Defender設定
今回の攻撃では、未知または変化の速いペイロード、偽サイト、DLLサイドローディング、Defender除外の悪用、RMM経由の操作が組み合わさっています。単一の対策ではなく、複数の保護機能を重ねる必要があります。
クラウド提供の保護を有効化する
Microsoft Defender Antivirusのクラウド保護は、リアルタイムで変化する攻撃ツールへの対策として重要です。Microsoft Learnでは、クラウド保護は既定で有効であるべき機能として説明されており、Block at First Sight、緊急署名更新、EDR in block mode、ASRルールなど複数の機能がクラウド保護に依存するとされています。(Microsoft Learn)
確認する項目は次の通りです。
| 確認項目 | 推奨対応 |
|---|---|
| Cloud-delivered protection | 有効化されているか確認 |
| Automatic sample submission | 原則として安全なサンプル送信を許可 |
| Tamper Protection | 管理対象端末で有効化 |
| Defender定義・プラットフォーム更新 | 更新停止や古い端末がないか確認 |
| ローカル除外設定 | ユーザーや攻撃者が勝手に追加できない運用にする |
今回の攻撃ではAdd-MpPreferenceによるDefender除外登録が使われています。除外設定は便利ですが、広すぎる除外は攻撃者にとって隠れ場所になります。特にC:\Users\配下、ダウンロードフォルダー、開発用ワークスペース全体を丸ごと除外している環境は見直してください。
EDR in block modeを確認する
Microsoft Defender for Endpoint Plan 2を利用しており、他社製アンチウイルスを主製品として使っている端末では、EDR in block modeの有効化を検討する価値があります。Microsoft Learnでは、Defender Antivirusがパッシブモードの場合でも、EDRが検出した悪意あるアーティファクトを修復する追加保護として説明されています。(Microsoft Learn)
ただし、EDR in block modeだけで万能ではありません。Defender Antivirusがパッシブモードの場合、リアルタイム保護、ネットワーク保護、ASRルールなど一部機能が使えないことがあります。既存の他社製セキュリティ製品に同等の機能があるか、Microsoft Defenderをアクティブ運用にするかを端末グループごとに判断してください。(Microsoft Learn)
ASRルールは監査から段階展開する
攻撃面の縮小、つまりASRルールは、スクリプトによるファイル取得、難読化スクリプト、プロセスインジェクションなど、マルウェアがよく使う挙動を抑えるための機能です。Microsoftは、今回の脅威に対して「実行ファイルが普及度、経過日数、信頼リストの条件を満たさない限り実行をブロックする」ASRルールを有効化することを推奨しています。(Microsoft)
展開時は、いきなり全社ブロックにしないことが重要です。Microsoft Learnでも、標準保護ルール以外はAuditモードでテストしてからBlockまたはWarnへ切り替える考え方が示されています。また、IntuneやConfiguration Managerなどの管理ソリューションを使うと、グループポリシーやPowerShellと競合した場合に管理側の設定を優先できます。(Microsoft Learn)
| 展開フェーズ | 対応 |
|---|---|
| 監査 | 開発端末、GPU端末、一般端末で検出状況を確認 |
| 例外整理 | 正規ビルドツールや社内配布ソフトを洗い出す |
| Warn | 影響が少ない端末群から警告モードへ |
| Block | 高リスク端末、管理者端末、RMM利用端末から順に適用 |
| 定期見直し | 例外が増えすぎていないか月次で確認 |
開発環境では、ASRや実行制御がビルド、テスト、自動生成ツールに影響することがあります。例外を作る場合は、フォルダー全体ではなく、署名済みの実行ファイル、固定されたパス、CI/CD専用端末など、範囲を絞るのが安全です。
ネットワーク保護とWeb保護を有効化する
今回のように偽サイトや外部C2への通信が絡む攻撃では、端末上の検知だけでなく、通信先の制御も重要です。Microsoft Learnでは、ネットワーク保護はフィッシング、エクスプロイト、マルウェアなどをホストする危険なドメインへのアクセスを防ぐ機能として説明されています。事前にAuditモードで、どのアプリがブロック対象になるか確認することも可能です。(Microsoft Learn)
Windows Serverではネットワーク保護が明示的な有効化を必要とする場合があります。サーバーにポリシーを配布しただけで効いていると思い込まず、OS側の前提設定と適用状況を確認してください。特にDNS、ファイルサーバー、SQL Server、Exchangeなど高トラフィックのサーバーでは、パフォーマンス影響も含めて検証が必要です。(Microsoft Learn)
Web保護では、Microsoft Edge以外のブラウザやプロセスに対してNetwork Protectionが検査・制御を担います。Microsoft Learnでは、非MicrosoftブラウザでHTTPSのFQDNブロックを機能させるには、QUICやEncrypted Client Helloの扱いに注意が必要とされています。また、カスタムインジケーターの適用には最大2時間程度の遅延が出る可能性があります。(Microsoft Learn)
ScreenConnectとRMMの棚卸しが必要な理由
ScreenConnectは、IT管理者にとって便利な正規のリモート管理ツールです。しかし、正規ツールだからこそ、攻撃者が設置しても見逃されやすいという問題があります。
管理者は、次の観点でRMMを棚卸ししてください。
| 確認項目 | 見るべき内容 |
|---|---|
| 正規利用の有無 | 会社としてScreenConnectを利用しているか |
| 接続先 | 承認済みの管理サーバー以外へ接続していないか |
| インストール日時 | 利用者が偽ソフトを導入した時期と近くないか |
| サービス名・コマンドライン | 不自然なホスト名やポートが含まれていないか |
| ファイル転送履歴 | SimpleRunPE.exe、vlc.exeなどの不審ファイルがないか |
| 管理者権限 | 一般ユーザーがRMMを導入できる状態になっていないか |
特に、社内でScreenConnectを正式採用していないのにクライアントが存在する場合は、優先度の高い調査対象です。正式採用している場合でも、承認済みサーバーのホスト名、ポート、証明書、管理者アカウントを明文化し、それ以外を検知できるようにしてください。
開発者が注意すべき.NET環境の落とし穴
開発者にとって厄介なのは、今回悪用された.NET Framework系ユーティリティやMSBuild.exeが、日常の開発作業でも使われることです。だからこそ、セキュリティ部門が単純に「MSBuildを禁止」と決めると、ビルドやCI/CDが止まります。
現実的な判断基準は次の通りです。
| 正常に近い例 | 調査すべき例 |
|---|---|
| Visual Studio、Build Tools、CIエージェント配下で起動 | DownloadsやTempから展開された実行ファイルを親に持つ |
| リポジトリやビルド定義と一致する時間帯に実行 | 深夜やアイドル時に長時間動作 |
| 社内ネットワークやパッケージリポジトリへ通信 | 不明なDynamic DNS、マイニングプール、外部WebSocketへ通信 |
| CPU使用率がビルド時間に集中 | アイドル時にGPU使用率が上がる |
| 署名済みの社内ツールから呼ばれる | RuntimeHost.exe、不明なPowerShell、ScreenConnect経由で起動 |
また、開発端末では「ビルドが遅くなるから」という理由でDefender除外が広く設定されがちです。リポジトリ全体、ユーザープロファイル全体、AppData全体を除外すると、今回のような攻撃の隠れ場所になります。除外が必要な場合は、対象プロセス、対象フォルダー、対象端末を最小限にしてください。
移行・展開上の注意点
今回の情報を受けて、.NET Frameworkから新しい.NETへ緊急移行する、という判断は適切ではありません。公式情報の焦点はランタイムの脆弱性ではなく、正規ユーティリティを悪用した実行隠蔽と防御回避です。したがって、移行計画より先に、端末防御、RMM管理、実行制御、ダウンロード経路の見直しを進めるべきです。
一方で、長期的な観点では、古い開発環境や不要なSDK、使っていないビルドツールを放置しないことが重要です。使われていないツールが多いほど、攻撃者が正規プロセスに紛れ込む余地が増えます。
展開時の実務ポイントは次の通りです。
| 項目 | 注意点 |
|---|---|
| .NETランタイム | 今回だけを理由に緊急移行しない。既存のサポート期限・互換性計画に沿って更新する |
| 開発端末 | MSBuild.exeなどの正規利用パターンを先に把握してから検知ルールを作る |
| CI/CD | ビルドエージェントに不要なRMM、ブラウザ、個人利用ツールを入れない |
| Defender除外 | ビルド高速化目的の広すぎる除外を避ける |
| ASRルール | Auditから始め、開発部門と誤検知を確認してBlockへ進める |
| RMM | 承認済みツール、接続先、管理者、ログ保存期間を台帳化する |
| ソフト配布 | 検索やAI回答からの直接ダウンロードではなく、社内ポータルや公式URL一覧を使う |
特にAIチャットボットの利用ルールは見直しが必要です。「おすすめのダウンロード先をAIに聞く」こと自体を禁止するよりも、「AIが提示したリンクをそのまま開かず、公式サイト、署名、ハッシュ、社内配布ポータルで確認する」という実用的なルールにした方が定着します。
感染が疑われる場合の確認チェックリスト
感染調査では、GPU使用率だけを見ると見逃す可能性があります。今回のマルウェアは、ユーザーがGPUを使っているときや端末がアイドルでないときにマイニングを止める挙動が説明されています。つまり、「使っている最中は重くないから安全」とは言えません。(Microsoft)
| チェック項目 | 確認内容 |
|---|---|
| 最近のダウンロード | CrystalDiskInfo、HWMonitor、DDU、FurMarkなどを検索経由で入れていないか |
| 不審なZIP | 正規サイト以外から取得したZIPがないか |
| DLL | autorun.dllがダウンロード、Temp、Desktop、ProgramData周辺にないか |
| ScreenConnect | 未承認クライアント、未知の接続先、directdownload[.]icuなどがないか |
| 永続化 | Windows System Health、Windows System Health Monitor、Windows System Health Checkのタスクがないか |
| レジストリ | WinSysCacheというRunキーがないか |
| ファイル | %LocalAppData%\Microsoft\Windows\Caches\D3F4E2A1\やRuntimeHost.exeがないか |
| Defender除外 | Add-MpPreferenceで不審なプロセス・パス除外が追加されていないか |
| .NET系プロセス | InstallUtil.exe、RegAsm.exe、MSBuild.exeなどが不自然に長時間動いていないか |
| GPUマイナー | gminer、lolMiner、SRBMiner-MULTIなどがないか |
Microsoftの公式記事には、RuntimeHost.exe、不審なスケジュールタスク、autorun.dllからmsiexec.exeへつながる挙動を探すAdvanced Huntingの例も掲載されています。Microsoft Defender XDRを利用している組織は、公式の検出名やIOCとあわせてSOCの調査手順に組み込むとよいでしょう。(Microsoft)
よくある誤解と正しい判断
.NETの脆弱性対応としてパッチを当てれば終わりなのか
終わりではありません。今回の主題は、.NET Framework系の正規ユーティリティが攻撃の隠れみのとして使われた点です。.NET SDKやランタイムを更新することは通常のセキュリティ衛生として重要ですが、今回の攻撃に対しては、偽サイト、RMM、Defender設定、プロセス監視を確認しなければ不十分です。
ScreenConnectを使っている会社は危険なのか
ScreenConnect自体が悪意あるツールという意味ではありません。問題は、攻撃者が正規のリモート管理機能を悪用していることです。正式に使っている組織ほど、承認済み接続先と未承認接続先を区別できるログ設計が必要です。
AIチャットボットが出したリンクなら安全なのか
安全とは限りません。AIの回答は、検索結果やWeb上の情報をもとにリンクを提示することがあります。ソフトウェアのダウンロードでは、AIの回答よりも公式サイト、ベンダーの署名、社内配布ポータルを優先してください。
マイニング目的なら情報漏えいの心配は小さいのか
小さいとは言えません。今回の攻撃ではScreenConnectによる永続的なリモートアクセスが使われており、Microsoftも後続の情報窃取、横展開、ランサムウェアにつながる可能性に触れています。GPU使用率や電気代の問題だけでなく、侵入経路として扱うべきです。(Microsoft)
まず取るべき行動
最初に行うべきことは、GPU搭載端末、開発端末、RMM利用端末を抽出し、最近のダウンロード履歴とScreenConnectの有無を確認することです。次に、Microsoft Defenderのクラウド保護、改ざん防止、EDR in block mode、ASRルール、ネットワーク保護、Web保護の適用状況を棚卸しします。
同時に、開発部門とは「正規の.NETユーティリティ利用パターン」を確認してください。MSBuild.exeやInstallUtil.exeを一律に危険視するのではなく、親プロセス、実行元フォルダー、通信先、実行時間、GPU使用率を組み合わせて判断することが重要です。
今回の.NET関連クリプトジャッキング対策は、単なるマルウェア駆除ではなく、ソフトウェア入手経路、RMM管理、端末防御、開発環境の例外運用を見直すきっかけになります。まずは高性能GPU端末から調査し、検知ルールと保護設定を段階的に展開していきましょう。
コメント