BYOVD 攻撃と EDR 無効化｜Huawei ドライバ悪用への多層防御

はじめに

2026 年 1 月以降、税務関連の文書を検索するユーザーを標的とした大規模な不正広告（マルバタイジング）キャンペーンが確認されています。

この攻撃は、Google 広告を悪用して正規の遠隔操作ツールである ScreenConnect の不正なインストーラーを配信し、最終的に BYOVD（Bring Your Own Vulnerable Driver）手法を用いてエンドポイントでの検知と対応（EDR）を無効化するツール「HwAudKiller」を展開します。Huntress の調査では、本キャンペーンに関連する 60 件以上の不正な ScreenConnect セッションが確認されました。

参考: How a Tax Search Leads to Kernel-Mode AV/EDR Kill（Huntress）
“While hunting for additional instances of the Havoc driver, we uncovered a separate intrusion…”
（Havoc ドライバの追加インスタンスを調査する中で、別の侵害事例も発見しました。）
https://www.huntress.com/blog/w2-malvertising-to-kernel-mode-edr-kill

現在はアメリカで確認されている攻撃ですが、攻撃手法そのものに地域依存性はなく、日本の確定申告シーズンや一般的なビジネス業務へのルアー（おとり）として標的が切り替わる可能性も否定できません。日本のインフラエンジニアにとっても、防御アーキテクチャの観点で参考にできる事例といえます。

本記事では、商用のクローキングサービスや署名済みの Huawei ドライバを悪用する攻撃の概要を整理し、FortiGate や MDE（Microsoft Defender for Endpoint）などのセキュリティ製品を組み合わせた多層防御アーキテクチャについて、具体的な設定例とともに考察します。

検索広告から始まる BYOVD 攻撃の概要と日本への影響可能性

今回の攻撃キャンペーンの初期侵入は、検索エンジン上で「W2 tax form」や「W-9 Tax Forms 2026」などの税務関連用語を検索したユーザーを、スポンサー付きの不正な検索結果へ誘導することから始まります。

税務書類を偽装した ScreenConnect の配信とクローキング技術

攻撃者は、ユーザーを「bringetax[.]com/humu/」や「anukitax[.]com」などの偽サイトへ誘導し、4sync 上でホストされた ScreenConnect の MSI インストーラーをダウンロードさせます。この際、セキュリティベンダーのクローラーや広告審査システムによる検知を回避するため、Adspect と JustCloakIt（JCI） という商用のクローキングサービスが多層的に悪用されています。具体的には、同一の index.php 内で JCI のサーバーサイドフィルタリングが最初に実行され、その後 Adspect のクライアントサイド JavaScript フィンガープリンティングが第 2 層として動作する構成です。

参考: Tax Search Ads Deliver ScreenConnect Malware Using Huawei Driver to Disable EDR（The Hacker News）
“The two cloaking services are stacked in the same index.php—JCI’s server-side filtering runs first, while Adspect provides client-side JavaScript fingerprinting as a second layer.”
（2 つのクローキングサービスは同じ index.php に積み重ねられています。JCI のサーバーサイドフィルタリングが最初に実行され、Adspect が第 2 層としてクライアントサイドの JavaScript フィンガープリンティングを提供します。）
https://thehackernews.com/2026/03/tax-search-ads-deliver-screenconnect.html

このように、セキュリティ製品には無害なページを提示し、実際の標的にのみ悪意のあるペイロードを配信する高度なトラフィック制御（TDS: Traffic Distribution System）が実装されています。

手法の汎用性: 日本のエンタープライズ環境も標的になり得る理由

このキャンペーンが日本のインフラエンジニアにとっても無視できない理由は、攻撃手法の汎用性の高さにあります。

攻撃に悪用されているのは、被害者の PC に元々インストールされている特定の Huawei 製ハードウェアの脆弱性ではありません。攻撃者自身が、正規のデジタル署名が付与された脆弱なカーネルドライバを外部から持ち込んでロードさせる BYOVD（Bring Your Own Vulnerable Driver） という手法です。

つまり、一般的な Windows 10 や Windows 11 が稼働している日本のエンタープライズ環境であれば、PC のメーカーを問わず標的となり得ます。

さらに、このマルウェアが停止対象とする Microsoft Defender、Kaspersky、SentinelOne といった EDR 製品は、日本国内でも高いシェアを持っています。攻撃者が検索広告のキーワードを日本の確定申告や一般的な業務ツールに切り替えるだけで、同様の手法が転用されるリスクがあります。

Huawei ドライバ（HWAuidoOs2Ec.sys）を悪用した EDR 無効化の仕組み

攻撃者がエンドポイントのセキュリティを無効化するために用いるのが、BYOVD（Bring Your Own Vulnerable Driver）と呼ばれる手法です。

BYOVD 手法の脅威: なぜ正規の署名済みドライバがロードされるのか

BYOVD 攻撃の特徴は、OS が持つ正規のセキュリティ機構を技術的に活用する点にあります。Windows には、未署名のドライバがカーネル空間に読み込まれるのを防ぐ DSE（Driver Signature Enforcement） という保護機能が存在します。

しかし攻撃者は、すでに正規のベンダー（今回は Huawei）によって署名されているものの、悪用可能な脆弱性を内包した古いオーディオドライバ（HWAuidoOs2Ec.sys）を標的のシステムに持ち込みます。このドライバは有効なデジタル署名を持っているため、Windows は DSE のチェックを通過し、カーネルモードでの実行が許可されます。

参考: How a Tax Search Leads to Kernel-Mode AV/EDR Kill（Huntress）
“The driver terminates the target process from kernel mode, bypassing any usermode protections that security products rely on. Because the driver is legitimately signed by Huawei, Windows loads it without complaint despite Driver Signature Enforcement (DSE).”
（ドライバはカーネルモードからターゲットプロセスを終了させ、セキュリティ製品が依存するユーザーモードの保護をバイパスします。ドライバは Huawei によって正当に署名されているため、Windows は Driver Signature Enforcement（DSE）にもかかわらず文句なしにロードします。）
https://www.huntress.com/blog/w2-malvertising-to-kernel-mode-edr-kill

カーネルレベルからのプロセス終了によるアンチウイルスの回避

カーネル空間は、OS の中核であり最高権限を持つ領域です。ここにロードされた脆弱なドライバを利用することで、攻撃者はユーザーモードで動作しているセキュリティ製品の保護プロセスをバイパスし、システム権限でプロセスを終了させることが可能になります。

HwAudKiller の動作詳細（Huntress による解析結果）

Huntress の解析によると、HwAudKiller は以下の手順で EDR を無効化します。

特に注目すべきは、Huntress が本攻撃を「HWAuidoOs2Ec.sys が BYOVD 兵器として悪用された最初の公開事例」と評価している点です。このドライバは執筆時点で LOLDrivers（Living Off The Land Drivers）プロジェクトのデータベースにも Microsoft Vulnerable Driver Blocklist にも未登録であり、既存の防御層をすり抜ける可能性があります。

MDE 等のクラウド EDR による検知と対策

このような高度な BYOVD 攻撃からシステムを守るためには、OS レベルの防御強化と、MDE（Microsoft Defender for Endpoint）などのクラウド EDR を連携させた対策が重要となります。

脆弱なドライバのロードと異常なプロセス終了の監視ロジック

最新の EDR は、マルウェアのシグネチャマッチングだけでなく、システムの振る舞い（ビヘイビア）を監視しています。

正規の署名を持つファイルであっても、通常業務では使用されない特定の Huawei ドライバ（HWAuidoOs2Ec.sys または Havoc.sys）が突然 %TEMP% などにドロップされ、ロードされる挙動自体を「疑わしいアクティビティ」として検知するよう、カスタム検出ルール（Custom Detection Rules） を構成することを推奨します。

具体的な検知ポイントとしては、以下のような観点が挙げられます。

• %TEMP% 配下から .sys ファイルが書き込まれた直後の sc create コマンド実行
• カーネルサービス「Havoc」の作成イベント（Sysmon Event ID 6: Driver loaded、Event ID 7045: Service installation）
• EDR 自身のサービスプロセス（MsMpEng.exe 等）が予期せず終了したログ
• winmm.dll 由来の不審なシェルコード実行（マルチメディアタイマー API の悪用）

また、EDR 自身のサービスプロセスが終了（クラッシュ）したログをトリガーとし、管理者にアラートを発報する仕組みも有効です。Microsoft Defender Antivirus 自体が停止された場合は、MDE の Tamper Protection（改ざん防止） が有効化されていれば、無効化の試行自体が記録されます。

参考: Strategies to monitor and prevent vulnerable driver attacks（Microsoft Tech Community）
“Vulnerable and exploited drivers are routinely identified and automatically added to the vulnerable driver ASR rule to protect Microsoft Defender for Endpoint users against driver malware campaigns.”
（脆弱な悪用ドライバは継続的に特定され、Microsoft Defender for Endpoint ユーザーをドライバマルウェアキャンペーンから保護するために、脆弱ドライバ用の ASR ルールへ自動的に追加されます。）
https://techcommunity.microsoft.com/blog/microsoftsecurityexperts/strategies-to-monitor-and-prevent-vulnerable-driver-attacks/4103985

ブロックリストの活用と OS レベルでのパッチ管理・設定強化

BYOVD に対する根本的な防御策の 1 つが、脆弱なドライバのロードを OS レベルでブロックすることです。

Microsoft Vulnerable Driver Blocklist の活用

Microsoft が提供する 「脆弱性のあるドライバのブロックリスト（Microsoft Vulnerable Driver Blocklist）」 は、Windows Defender Application Control（WDAC）フレームワークの一部として動作し、Hypervisor-Protected Code Integrity（HVCI、メモリ整合性）または Smart App Control が有効な環境で機能します。

注意点として、以下の前提条件があります。

• Windows 11 22H2 以降: ブロックリストはデフォルト有効。
• Windows 10 / Windows Server: 明示的な有効化が必要（HVCI または Smart App Control が前提）。
• 更新頻度: Windows メジャーアップデートのタイミングで年 1〜2 回更新されるため、新規発見の脆弱ドライバが反映されるまでタイムラグがある。

ブロックされたドライバのロード試行は、Windows イベントビューアの Event ID 3023 および 3033（システムログ）に記録されます。

ASR ルール「Block abuse of exploited vulnerable signed drivers」の併用

Microsoft Defender for Endpoint の Attack Surface Reduction（ASR）ルールにも、脆弱な署名済みドライバの悪用を防ぐルールが用意されています。

PowerShell での有効化コマンドは以下の通りです。

Set-MpPreference -AttackSurfaceReductionRules_Ids 56a863a9-875e-4185-98a7-b882c64b5ce5 `
                 -AttackSurfaceReductionRules_Actions Enabled

設定状況の確認は以下のコマンドで行えます。

Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids

ブロック発生時のイベントログは 「Microsoft-Windows-Windows Defender/Operational」の Event ID 1121 に記録されます。

参考: Block abuse of exploited vulnerable signed drivers（Microsoft Learn）
“The block abuse of exploited vulnerable signed drivers ASR rule monitors and prevents an application from writing a signed vulnerable driver to the system.”
（「脆弱な署名済みドライバの悪用ブロック」ASR ルールは、アプリケーションが脆弱な署名済みドライバをシステムへ書き込むことを監視・防止します。）
https://learn.microsoft.com/en-us/defender-endpoint/attack-surface-reduction-rules-reference

これにより、攻撃者が HWAuidoOs2Ec.sys などの悪用可能なドライバを %TEMP% に書き込もうとする時点でブロックできる可能性が高まります。

FortiGate を活用した C2 通信の遮断と多層防御アーキテクチャ

EDR 製品が BYOVD 攻撃によって無効化されるリスクを考慮すると、エンドポイント単体の防御に依存しないネットワーク境界での多層防御が重要となります。

Web フィルタリングと IPS を用いた RMM ツールの不正通信ブロック

今回のキャンペーンの特徴は、初期侵入後に複数のリモートアクセスツールが迅速にエンドポイントへ展開される点にあります。

参考: Tax Search Ads Deliver ScreenConnect Malware Using Huawei Driver to Disable EDR（The Hacker News）
“A consistent pattern across compromised hosts was the rapid stacking of multiple remote access tools. After the initial rogue ScreenConnect relay was established, the threat actor deployed additional trial ScreenConnect instances on the same endpoint, sometimes two or three within hours, and backup RMM tools like FleetDeck.”
（侵害されたホスト全体で一貫したパターンは、複数のリモートアクセスツールが急速に積み重ねられていることでした。最初の不正な ScreenConnect リレーが確立された後、脅威アクターは同じエンドポイントに追加のトライアル ScreenConnect インスタンスを数時間以内に 2、3 個展開し、FleetDeck などのバックアップ RMM ツールを展開しました。）
https://thehackernews.com/2026/03/tax-search-ads-deliver-screenconnect.html

FortiGate Application Control での RMM ツール制御

FortiGate の Application Control 機能を活用し、組織内で公式に許可されていない ScreenConnect や FleetDeck などの RMM（Remote Monitoring and Management）ツールの通信をネットワークレベルで事前にブロックする運用を推奨します。

FortiGuard が提供する ScreenConnect 向けの Application Control シグネチャは以下の通りです。

参考: FortiGuard Labs Application Control（ScreenConnect.Software）
“This indicates an attempt to access ScreenConnect (known as ConnectWise Control). ScreenConnect (also known as ConnectWise Control now) is a remote desktop application by ConnectWise.”
（これは ScreenConnect（ConnectWise Control として知られる）へのアクセス試行を示します。ScreenConnect（現在は ConnectWise Control とも呼ばれる）は ConnectWise によるリモートデスクトップアプリケーションです。）
https://www.fortiguard.com/appcontrol/38570

ScreenConnect は HTTPS を経由するため、シグネチャを有効に機能させるためには SSL Deep Inspection（SSL 深層検査）プロファイル の適用も推奨されます。SSL Deep Inspection の設定手順については、関連記事「FortiGate の SSL Deep Inspection の手順」も参照してください。

また、Web フィルタリングや IPS（侵入防御システム）のシグネチャを最新に保ち、初期侵入時のインストーラーのダウンロードや、Adspect 等のクローキングインフラへの通信を検知・ブロックする設定を推奨します。

ゼロトラストを前提としたネットワークセグメンテーションの重要性

万が一 EDR が無効化され、LSASS（Local Security Authority Subsystem Service）から認証情報がダンプされた場合、攻撃者は NetExec（旧 CrackMapExec）などのツールを用いて内部ネットワークでの横展開（ラテラルムーブメント）を試みます。

これを防ぐためには、内部からの侵害を前提としたゼロトラストアーキテクチャの採用が重要な対策となります。FortiGate を ISFW（Internal Segmentation Firewall: 内部セグメンテーションファイアウォール） として配置し、クライアント PC 間の不要な SMB（TCP 445）や RPC（TCP 135）通信をデフォルトで拒否（Deny All）するマイクロセグメンテーションの実装を推奨します。FortiGate での内部セグメンテーション設計の詳細は、関連記事「FortiGate VDOM 機能の活用ポイント」も参考になります。

BYOVD 対策の限界と運用上の注意点

ここまで紹介した OS／EDR／ネットワーク各層の対策は、それぞれ単独では BYOVD 攻撃を防ぎきれない制約があります。各防御層の限界を理解し、複数の対策を組み合わせる多層防御の前提として整理します。

Microsoft Vulnerable Driver Blocklist の制約

Microsoft Vulnerable Driver Blocklist は強力な防御層ですが、以下の制約があります。

HVCI または Smart App Control が前提

ブロックリストは WDAC フレームワーク上で動作するため、Hypervisor-Protected Code Integrity（メモリ整合性）または Smart App Control が有効でないと十分に機能しません。仮想化ベースのセキュリティ（VBS）に対応していない古いハードウェアでは利用できない場合があります。

更新頻度のタイムラグ

ブロックリストは Windows メジャーアップデートのタイミングで年 1〜2 回更新されるため、新規に発見された脆弱ドライバが反映されるまで数か月のタイムラグが生じます。HwAudKiller が悪用する HWAuidoOs2Ec.sys も執筆時点では未登録であり、ブロックリスト単独では防げない可能性があります。

既存ドライバには無効

すでにシステムにロードされている脆弱ドライバは、ブロックリストの対象外です。

参考: Do we need to use Microsoft recommended driver block rules（MicrosoftDocs/WDAC-Toolkit GitHub Discussion）
“With Windows 11 2022 update, the vulnerable driver blocklist is enabled by default for all devices.”
（Windows 11 2022 アップデート以降、脆弱ドライバブロックリストはすべてのデバイスでデフォルト有効になりました。）
https://github.com/MicrosoftDocs/WDAC-Toolkit/discussions/217

ASR ルールの制約

ASR ルール（GUID: 56a863a9-875e-4185-98a7-b882c64b5ce5）にも以下の運用上の注意点があります。

既にロード済みのドライバは対象外

このルールはディスクへの新規書き込みを監視するため、すでにロードされている脆弱ドライバには効果がありません。

Intune 標準 UI での設定制限

執筆時点では Intune の標準ポリシー UI から直接設定できないケースがあり、PowerShell または OMA-URI での設定が必要となる場合があります。

誤検知のリスク

正規のドライバインストールがブロックされる可能性があるため、Audit モードで影響を確認してから Block モードへ移行する運用が推奨されます。

FortiGate Application Control の制約

ネットワーク境界での RMM ツール制御にも、運用上の前提があります。

SSL Deep Inspection が事実上必須

ScreenConnect や FleetDeck などの RMM ツールは HTTPS を経由するため、SSL Deep Inspection を有効化しないとシグネチャによる識別が困難です。プライバシーや業務影響を考慮した上で、対象範囲を明確化する必要があります。

セルフホスト・カスタムサブドメインへの対応

攻撃者が独自ドメインで ScreenConnect リレーをホストする場合、シグネチャでの識別が難しくなる場合があります。FortiGuard の継続的な更新と、Web フィルタリング・脅威インテリジェンスフィードとの組み合わせが推奨されます。

トライアルインスタンスの識別

今回のキャンペーンでは instance-* 形式のリレーパターンが使われているため、これらの URL パターンを Web フィルタリングで併用して検知することが有効な対策となります。

EDR（MDE 等）の制約

EDR 自体が BYOVD 攻撃のターゲットであるという根本的な前提があります。

無効化されればログも止まる

EDR プロセスが終了させられた場合、それ以降のテレメトリは収集できません。Tamper Protection（改ざん防止） の有効化と、終了イベント自体をトリガーとしたアラート設計が重要です。

クラウド側ログとの突合せ

エンドポイント側のログだけでなく、MDE のクラウド側ログ（Advanced Hunting）や Microsoft Sentinel との連携によって、ローカルログ消失後の挙動も追跡できる体制を整えておくことを推奨します。

すぐに実行できる対策コマンド集

ここでは、各防御層を実装する際の具体的なコマンドと設定例を整理します。検証環境での動作確認を経た上で、本番環境へ展開することを推奨します。

Windows 側の設定確認・有効化（PowerShell）

Vulnerable Driver Blocklist と HVCI の有効化状況確認

Vulnerable Driver Blocklist が機能する前提となる HVCI（メモリ整合性）の有効化状況を確認します。

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | `
    Select-Object SecurityServicesRunning, VirtualizationBasedSecurityStatus

SecurityServicesRunning に 2（HVCI が実行中）が含まれていれば、HVCI が有効化されています。

参考: How to Enable or Disable Microsoft Vulnerable Driver Blocklist（NinjaOne）
“The blocklist integrates with Windows Defender Application Control and relies on Memory Integrity (HVCI) or Smart App Control to function.”
（ブロックリストは Windows Defender Application Control と統合され、その動作は Memory Integrity（HVCI）または Smart App Control に依存します。）
https://www.ninjaone.com/blog/enable-or-disable-microsoft-vulnerable-driver-blocklist/

ASR ルール「Block abuse of exploited vulnerable signed drivers」の有効化

Audit モードで影響を確認してから、Block モードに切り替える運用を推奨します。

# まず Audit モードで影響範囲を確認
Set-MpPreference -AttackSurfaceReductionRules_Ids 56a863a9-875e-4185-98a7-b882c64b5ce5 `
                 -AttackSurfaceReductionRules_Actions AuditMode

# 影響が問題ないことを確認した上で Block モードへ移行
Set-MpPreference -AttackSurfaceReductionRules_Ids 56a863a9-875e-4185-98a7-b882c64b5ce5 `
                 -AttackSurfaceReductionRules_Actions Enabled

現在の ASR ルール設定状況の確認

Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids
Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Actions

参考: Attack surface reduction rules reference（Microsoft Learn）
https://learn.microsoft.com/en-us/defender-endpoint/attack-surface-reduction-rules-reference

FortiGate での ScreenConnect ブロック設定（CLI）

FortiOS 7.6 系の CLI 構文に準拠した、Application Control プロファイルで ScreenConnect をブロックする例を示します。

config application list
    edit "block-rmm-tools"
        set comment "Block ScreenConnect and unauthorized RMM tools"
        config entries
            edit 1
                set application 38570
                set action block
                set log enable
            next
        end
    next
end

上記プロファイルをファイアウォールポリシーへ適用します。SSL Deep Inspection プロファイルとセットで適用することで HTTPS 通信に対しても識別が可能になります。

config firewall policy
    edit <policy_id>
        set application-list "block-rmm-tools"
        set ssl-ssh-profile "deep-inspection"
        set utm-status enable
    next
end

参考: config application list（FortiGate / FortiOS 7.6.0 CLI Reference）
https://docs.fortinet.com/document/fortigate/7.6.0/cli-reference/117262721/config-application-list

Microsoft Defender Advanced Hunting（KQL）

MDE の Advanced Hunting で HwAudKiller の挙動を検知するための KQL クエリ例です。Microsoft Defender XDR ポータルの「Advanced hunting」から実行できます。これらのクエリはカスタム検出ルールとして登録することで、定期実行・自動アラート化も可能です。

Havoc.sys または HWAuidoOs2Ec.sys のファイル作成検知

DeviceFileEvents
| where Timestamp > ago(30d)
| where FileName in~ ("Havoc.sys", "HWAuidoOs2Ec.sys")
   or FolderPath endswith @"\Havoc.sys"
| project Timestamp, DeviceName, FileName, FolderPath,
          InitiatingProcessFileName, InitiatingProcessCommandLine, ReportId
| order by Timestamp desc

sc create による Havoc サービスの登録検知

DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName =~ "sc.exe"
| where ProcessCommandLine has_all ("create", "Havoc", "type= kernel")
| project Timestamp, DeviceName, AccountName,
          ProcessCommandLine, InitiatingProcessFileName, ReportId
| order by Timestamp desc

Defender プロセスが予期せず終了したイベントの検知

DeviceProcessEvents
| where Timestamp > ago(7d)
| where ActionType == "ProcessTerminated"
| where FileName in~ ("MsMpEng.exe", "MsSense.exe", "SenseIR.exe")
| project Timestamp, DeviceName, FileName,
          InitiatingProcessFileName, InitiatingProcessCommandLine, ReportId
| order by Timestamp desc

参考: DeviceFileEvents table（Microsoft Defender XDR / Microsoft Learn）
https://learn.microsoft.com/en-us/defender-xdr/advanced-hunting-devicefileevents-table

多層防御の比較表: どの層で何を防ぐのか

BYOVD 攻撃に対する多層防御は、それぞれの層が異なる攻撃フェーズをカバーします。各層の役割と特性を整理することで、自組織の優先実装順を判断する材料になります。

各防御層の対応フェーズと特性

実装優先度の考え方

組織の現状に応じて、以下の順序で実装を進めることが推奨されます。

1. 最優先: Windows 11 22H2 以降への移行と HVCI 有効化により、Vulnerable Driver Blocklist のデフォルト保護を受けられる状態にする。
2. 次に優先: MDE の Tamper Protection の有効化と、ASR ルール（GUID: 56a863a9-875e-4185-98a7-b882c64b5ce5）の Audit モード → Block モード適用。
3. 並行実施: FortiGate Application Control で未承認 RMM ツール（ScreenConnect、FleetDeck 等）の通信をブロック。SSL Deep Inspection との併用を前提とする。
4. 中長期で実装: 内部セグメンテーション（ISFW）による横展開対策。SMB／RPC のデフォルト Deny ポリシー化。

EDR は強力な検知層ですが、BYOVD 攻撃そのものの標的になるため、「EDR が無効化されても被害が局所化できる設計」 を前提とした多層防御が望ましいアプローチとなります。

HwAudKiller の主要 IoC（侵害指標）

Huntress が公開した解析レポートをもとに、検知ルール・SIEM ルール・スレットハンティングに活用できる主要 IoC を整理します。実環境のログ調査やルールチューニングの参考としてご活用ください。

ファイル系 IoC

動作系 IoC

ネットワーク系 IoC

イベントログ系 IoC

参考: How a Tax Search Leads to Kernel-Mode AV/EDR Kill（Huntress 公式解析レポート）
“On execution, HwAudKiller prints ‘[+] Havoc Process Terminator’ and attempts to open a handle to the device \.\HWAudioX64.”
（実行時、HwAudKiller は「[+] Havoc Process Terminator」と表示し、デバイス \.\HWAudioX64 へのハンドル取得を試みます。）
https://www.huntress.com/blog/w2-malvertising-to-kernel-mode-edr-kill

※本 IoC リストは Huntress の解析結果（2026 年 3 月時点）に基づきます。攻撃キャンペーンの進化により IoC が変化する可能性があるため、最新情報は Huntress 公式ブログを定期的に確認することを推奨します。

まとめ

本記事では、検索広告から始まり Huawei ドライバを悪用して EDR を無効化するマルウェアキャンペーンについて解説しました。

• 検索広告とクローキング技術（Adspect / JCI）を悪用し、不正な ScreenConnect などの RMM ツールを展開する。
• 正規署名を持つ脆弱なドライバ（HWAuidoOs2Ec.sys）を持ち込む BYOVD 手法で、カーネルモードから 23 種類のセキュリティプロセスを無効化する。
• OS のドライバブロックリストと ASR ルール（GUID: 56a863a9-875e-4185-98a7-b882c64b5ce5）を有効化し、新規の脆弱ドライバ書き込みをブロックする。
• クラウド EDR で Havoc サービスの登録や Defender プロセスの予期せぬ終了を KQL で監視する。
• FortiGate の Application Control（シグネチャ ID 38570）で未承認の RMM ツールを遮断し、内部セグメンテーションで横展開を防ぐ。
• 各防御層には固有の限界があるため、OS・EDR・ネットワーク境界を組み合わせた多層防御が有効なアプローチとなる。

以上、最後までお読みいただきありがとうございました。