Microsoftの「Kazuar: Anatomy of a nation-state botnet」で最初に押さえるべき結論は、Microsoft製品の仕様変更や緊急パッチではなく、Kazuarという高度なマルウェアの構造変化を踏まえた防御設定の見直しが必要になったという点です。特にMicrosoft Defender for Endpoint、Microsoft Defender Antivirus、PowerShellログ、ネットワーク保護、EDR運用を担当する管理者は、単なるIOC照合だけでなく、P2P型ボットネットとしての振る舞いを検知できる状態になっているかを確認する必要があります。
Microsoft公式情報では、Kazuarはロシア系国家支援型アクターSecret Blizzardに関連付けられるマルウェアファミリーで、従来のバックドアから、Kernel・Bridge・Workerの3種類のモジュールで構成されるP2Pボットネット型のエコシステムへ進化したと説明されています。つまり、今回のポイントは「新しい更新プログラムを入れれば終わり」ではなく、長期侵入・情報窃取・目立たないC2通信を前提に、防御と監視を再点検することです。(Microsoft)
今回の公式情報で何が変わったのか
2026年5月15日時点で確認できるMicrosoft公式情報では、Microsoft Security Blog上の表示はMay 14となっています。本稿では、この公式情報をもとに、Microsoft環境の管理者や開発者が確認すべきポイントを整理します。(Microsoft)
重要なのは、Kazuarが単体のマルウェアとしてではなく、モジュール化されたP2Pボットネットとして説明されていることです。Microsoftは、KazuarがKernel、Bridge、Workerの役割を分け、外部通信を選出された単一のKernelリーダーに集約することで、観測される通信量を減らす設計になっていると分析しています。(Microsoft)
| 観点 | 従来の見方 | 今回重視すべき見方 |
|---|---|---|
| マルウェアの性質 | バックドア型マルウェア | Kernel・Bridge・Workerで構成されるモジュール型P2Pボットネット |
| C2通信 | 感染端末が個別に外部通信する | 選出されたリーダーがBridge経由で外部通信し、可視性を下げる |
| 検知の考え方 | ハッシュや通信先のIOC照合 | IPC、名前付きパイプ、Mailslot、作業ディレクトリ、EWS/HTTP/WSS通信の組み合わせを見る |
| 管理者の対応 | AV定義更新や単発スキャン | Defender設定、ASRルール、ネットワーク保護、EDR、ログ監視の総点検 |
| 移行対応 | 製品アップデートの適用 | 強制的な移行ではなく、防御設定の段階的な展開と検証 |
このため、管理者は「Kazuarのハッシュが見つからないから安全」と判断しない方がよいです。Microsoft自身も、Kazuarの理解では単一サンプルの分析だけでなく、リーダー選出、IPCメッセージルーティング、作業ディレクトリへのステージング、定期的な持ち出しといった運用上の振る舞いを見る必要があると説明しています。(Microsoft)
影響範囲：Microsoft製品の脆弱性ではなく、Microsoft環境の防御体制が問われる
今回の情報は、WindowsやMicrosoft 365に対する特定の脆弱性修正ではありません。Kazuarはマルウェアであり、Microsoft DefenderやWindows環境の設定不備、監視不足、過度な除外設定、スクリプト実行の緩さを悪用されると、侵入後の長期潜伏や情報収集を検知しにくくなります。
Microsoftは、Secret Blizzardが政府・外交関連組織、欧州や中央アジアの組織、ウクライナの侵害済みシステムなどを標的にしてきたと説明しています。ただし、日本企業であっても、官公庁、研究機関、防衛・インフラ関連、海外拠点、国際取引先を持つ組織は「自社は対象外」と決めつけるべきではありません。(Microsoft)
特に注意すべき環境は次の通りです。
- Microsoft Defender for Endpointを導入しているが、ASRルールやネットワーク保護が監査モードのままになっている
- 非Microsoft製アンチウイルスを主製品にしており、Microsoft Defender Antivirusがパッシブ運用になっている
- 開発端末、CI/CDサーバー、管理端末に広い除外設定を入れている
- PowerShell、WMI、PSExec、スクリプト実行のログを十分に取得していない
- Exchange Web Services、HTTP、WebSocket通信の正規利用と異常利用を切り分けられていない
- サーバーや古いWindows ServerがDefender for Endpointに完全にオンボードされていない
管理者がまず確認すべきMicrosoft Defender設定
Kazuar対策で優先すべきなのは、単体のブロックリスト登録よりも、侵入後の活動を止めるためのDefender設定です。Microsoftは公式ブログで、Attack Surface Reductionルール、ネットワーク保護、改ざん防止、EDRのブロックモード、自動調査と修復、PUA保護、クラウド提供の保護、リアルタイム保護、PowerShellログなどの確認を挙げています。(Microsoft)
| 確認項目 | 推奨される確認内容 | 失敗しやすいポイント |
|---|---|---|
| ASRルール | 難読化スクリプト、PSExec/WMI起点のプロセス作成、信頼性の低い実行ファイル、脆弱な署名付きドライバー悪用のブロックを確認 | いきなり全社Blockにして業務アプリを止める |
| ネットワーク保護 | まずAuditで影響を見て、段階的にBlockへ移行 | サーバーの高負荷通信やUDP処理を検証せず有効化する |
| 改ざん防止 | Defender設定が無効化・変更されないよう有効化を確認 | グループポリシー変更が成功したように見えて実際はブロックされる |
| EDR in block mode | 非Microsoft製AV併用環境で、EDR検知後のブロックを有効化 | Defender Antivirusがパッシブでも全機能が使えると誤解する |
| 自動調査と修復 | フル自動化または承認フローを整備 | Action centerの確認担当が決まっていない |
| PUA保護 | AuditまたはBlockの状態を確認 | PUAを軽視して侵入前段のリスクを放置する |
| クラウド保護 | 無効化されていないか確認 | オフライン端末や閉域端末の例外を放置する |
| PowerShellログ | モジュールログ、スクリプトブロックログを有効化 | 実行ポリシーだけで十分と誤解する |
ASRルールは、Microsoft LearnでもAuditからBlockへ段階的に移行する考え方が示されています。問題のあるルールをすぐ無効化するのではなく、除外の範囲を見直しながら展開リングを広げる運用が重要です。(Microsoft Learn)
ネットワーク保護は、危険なドメインや悪意あるコンテンツへのアクセスを防ぐ機能です。Microsoft Defenderポータル、Intune、グループポリシー、PowerShellなどで構成できますが、Windows Serverの高UDPトラフィック環境では性能や安定性に注意が必要です。Microsoftはドメインコントローラー、DNSサーバー、ファイルサーバー、SQL Server、Exchange ServerなどでDatagram Processingを有効にする場合の影響に注意を促しています。(Microsoft Learn)
改ざん防止は、リアルタイム保護、クラウド保護、セキュリティインテリジェンス更新、自動アクションなどの重要設定を攻撃者に無効化されにくくする機能です。PowerShellではGet-MpComputerStatusを使い、IsTamperProtectedやRealTimeProtectionEnabledを確認できます。(Microsoft Learn)
非Microsoft製AVを使っている組織はEDR in block modeを確認する
非Microsoft製アンチウイルスを主製品にしている組織では、Microsoft Defender Antivirusがパッシブモードで動いているケースがあります。この場合、EDR in block modeは、EDRで検知された悪性アーティファクトをMicrosoft Defender Antivirusが修復できるようにする追加保護として重要です。(Microsoft Learn)
ただし、注意点があります。Microsoft Learnでは、Defender Antivirusがパッシブモードの場合、リアルタイム保護、ネットワーク保護、ASRルール、ファイルハッシュ・IP・URLなどのインジケーター機能の一部は、アクティブモード時と同じようには動作しないと説明されています。つまり、EDR in block modeを有効にしても「Defenderの全機能が有効になった」とは考えないでください。(Microsoft Learn)
確認の優先順位は次の通りです。
| 環境 | 確認すべきこと |
|---|---|
| Microsoft Defender Antivirusがアクティブ | ASR、ネットワーク保護、クラウド保護、リアルタイム保護、改ざん防止が期待通り有効か確認 |
| Microsoft Defender Antivirusがパッシブ | EDR in block modeの有効化、非Microsoft製AV側の同等機能、Defender機能の制約を確認 |
| 混在環境 | 端末グループごとに、どの製品がどの防御レイヤーを担っているか一覧化 |
| サーバー環境 | Defender for Endpointへのオンボード、OS要件、Server 2012 R2/2016の統合エージェント要否を確認 |
検知はIOCだけでなく振る舞いで見る
MicrosoftはKazuarに関するMicrosoft Defenderの検知名として、Microsoft Defender Antivirus側でKazuar、KazuarModule、KazuarLoader、ShadowLoader、ToxicDustなどを挙げ、Microsoft Defender for Endpoint側ではSecret Blizzard actor activity detectedを示しています。(Microsoft)
公式ブログで示されたSHA-256のIOCを使う場合、Microsoft Defender XDRのAdvanced Huntingでは、まずファイルイベントを確認します。環境によってテーブルや取得項目は異なるため、実行前に自社テナントのスキーマを確認してください。
let kazuar_iocs = datatable(SHA256:string)
[
"69908f05b436bd97baae56296bf9b9e734486516f9bb9938c2b8752e152315d4",
"c1f278f88275e07cc03bd390fe1cbeedd55933110c6fd16de4187f4c4aaf42b9",
"6eb31006ca318a21eb619d008226f08e287f753aec9042269203290462eaa00d",
"436cfce71290c2fc2f2c362541db68ced6847c66a73b55487e5e5c73b0636c85"
];
DeviceFileEvents
| where SHA256 in (kazuar_iocs)
| project Timestamp, DeviceName, FileName, FolderPath, SHA256,
InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc検知名で確認する場合は、次のような観点で調べます。
DeviceEvents
| where ActionType has_any ("Antivirus", "Detection", "Alert")
| where AdditionalFields has_any (
"Kazuar",
"KazuarModule",
"KazuarLoader",
"ShadowLoader",
"ToxicDust",
"Secret Blizzard"
)
| project Timestamp, DeviceName, ActionType, AdditionalFields
| order by Timestamp descただし、Kazuarのような高度なマルウェアでは、ハッシュが一致しない亜種や、通信先が変わるケースを想定すべきです。MicrosoftはKazuarがC2から構成を更新でき、HTTP、WebSocket、Exchange Web Servicesを含む複数の外部通信方式を持つと説明しています。(Microsoft)
そのため、追加で次の振る舞いも確認対象にします。
- Outlookや業務アプリ以外のプロセスがEWS風の通信を行っていないか
- 通常業務に関係のないプロセスがWebSocket通信を継続していないか
- 端末内に暗号化された収集データ、ログ、タスクファイルが継続的に作成されていないか
- 名前付きパイプ、Mailslot、隠しウィンドウを使ったプロセス間通信が不自然に多くないか
- PowerShell、WMI、PSExec経由のプロセス作成が管理作業の時間帯・管理者端末と一致しているか
- スクリーンショット、最近使ったファイル、Outlook関連情報、ユーザー情報の収集に見える挙動がないか
MicrosoftはKazuarのWorkerモジュールが、システム情報、ファイル一覧、ウィンドウ情報、MAPI情報、キーログ、スクリーンショットなどの収集に関わる機能を持つと説明しています。ログ監視では、これらの「情報窃取につながる前段の動き」を拾えるかが重要です。(Microsoft)
PowerShellとスクリプト実行の監視を軽視しない
Kazuar対策では、PowerShellの実行ポリシーだけに頼らないことが重要です。PowerShellの実行ポリシーは、構成ファイルやスクリプトの実行条件を制御する安全機能ですが、これだけで攻撃を完全に防げるわけではありません。Microsoft Learnでは、モジュールログとスクリプトブロックログにより、コマンド、スクリプトブロック、関数、スクリプトの処理をイベントログに記録できると説明されています。(Microsoft Learn)
管理者が確認すべき設定は次の通りです。
| 項目 | 実務上の確認ポイント |
|---|---|
| PowerShell実行ポリシー | AllSignedやRemoteSignedなど、自社ルールに沿った設定か |
| Script Block Logging | 攻撃調査に必要なコマンド内容が記録されるか |
| Module Logging | 管理モジュールや重要モジュールの実行履歴が残るか |
| AMSI連携 | セキュリティ製品がスクリプト内容を検査できる状態か |
| 管理者端末の分離 | 日常利用端末と特権操作端末を分けているか |
| ログ保管期間 | 侵害調査に必要な期間、イベントログやDefenderログを保管しているか |
特に、国家支援型の侵入では初期侵入から発覚まで時間がかかる可能性があります。ログ保管期間が短いと、発見時に「いつ入られたか」「どの端末が最初だったか」を追えません。端末ログ、認証ログ、メール関連ログ、プロキシログ、DNSログは、インシデント対応チームが横断的に検索できる状態にしておくべきです。
開発者・DevOpsが確認すべき点
開発者やDevOps担当者は、Kazuarのような脅威を「情シスだけの問題」と見ない方がよいです。開発端末、ビルドサーバー、CI/CDランナー、署名用端末、デプロイ用サービスアカウントは、攻撃者にとって価値が高い資産です。
特に注意すべきなのは、Defenderの除外設定です。ビルド高速化や誤検知回避のために、ソースコード全体、作業ディレクトリ全体、Downloads、Temp、CIエージェントのルートフォルダを丸ごと除外していると、マルウェアの実行やステージングを見逃すリスクが高まります。ASRルールのドキュメントでも、除外や許可設定は保護効果を下げる可能性があるため、慎重に扱う必要があると説明されています。(Microsoft Learn)
開発チームでは、次のように運用を見直します。
| 対象 | 確認ポイント |
|---|---|
| 自社開発ツール | 署名、配布元、ハッシュ、実行パスを明確にする |
| CI/CDサーバー | Defender for Endpointにオンボードし、ログを収集する |
| ビルド出力 | 誤検知が出る場合は全体除外ではなく、最小範囲の除外にする |
| スクリプト | 署名、レビュー、実行権限、ログ取得を整備する |
| EWS/HTTP/WebSocket利用アプリ | 正規通信のプロセス名、宛先、サービスアカウントを棚卸しする |
| 管理者権限 | 開発作業用アカウントと本番操作アカウントを分ける |
EWSやWebSocket通信を一律でブロックするのは現実的ではありません。業務アプリや監視ツールが正当に使っている場合もあるため、「どのプロセスが、どのアカウントで、どの宛先に、どの頻度で通信するのが正常か」を先に把握することが大切です。
展開・移行上の注意点：いきなりBlockではなく段階的に進める
今回のKazuar情報を受けて、すぐに全端末へ強い制御を入れたくなるかもしれません。しかし、ASRルール、ネットワーク保護、PUA保護、EDR自動修復を一度にBlockへ変更すると、業務アプリ、社内スクリプト、管理ツール、開発環境に影響が出る可能性があります。
おすすめの展開順序は次の通りです。
| フェーズ | 実施内容 | 判断基準 |
|---|---|---|
| 現状把握 | Defenderオンボード率、保護機能、除外設定、ログ取得状況を確認 | 端末・サーバー・開発環境が一覧化されている |
| Audit展開 | ASR、ネットワーク保護、PUA保護を監査モードで展開 | 業務影響と検知ノイズが見えている |
| 小規模Block | 情シス端末、テスト端末、限定部署でBlock化 | 誤検知時の復旧手順がある |
| 段階展開 | 部署・端末グループごとに展開リングを拡大 | 例外設定が最小化されている |
| 運用定着 | Advanced Hunting、Action center、インシデント対応手順に組み込む | 検知後の担当者と対応期限が決まっている |
自動調査と修復を使う場合、Microsoft Defender for EndpointのAIRはアラートを起点に調査を開始し、悪性・疑わしい・脅威なしといった判定に応じて、隔離、サービス停止、スケジュールタスク削除などの修復アクションにつながることがあります。修復アクションはAction centerで追跡され、必要に応じて承認や取り消しも行えます。(Microsoft Learn)
すぐに実施したいチェックリスト
最後に、MicrosoftのKazuar公式情報を受けて、管理者が今日から確認すべき項目を整理します。
| 優先度 | チェック項目 | 完了の目安 |
|---|---|---|
| 高 | Microsoft Defender for Endpointの対象端末と未オンボード端末を確認 | 管理端末、サーバー、開発端末まで把握できている |
| 高 | Kazuar関連IOCと検知名でAdvanced Huntingを実行 | 該当有無、対象端末、時刻、プロセスが確認済み |
| 高 | ASRルールのAudit/Block状態を確認 | 重要ルールの展開計画がある |
| 高 | ネットワーク保護の状態を確認 | AuditまたはBlockで展開され、サーバー影響を検証済み |
| 高 | 改ざん防止、クラウド保護、リアルタイム保護を確認 | 無効化端末が例外管理されている |
| 中 | EDR in block modeを確認 | 非Microsoft製AV環境での役割分担が明確 |
| 中 | PowerShellログとスクリプト実行ルールを確認 | Script Block LoggingとModule Loggingの取得方針がある |
| 中 | Defender除外設定を棚卸し | 広すぎる除外が削除または縮小されている |
| 中 | EWS/HTTP/WebSocketの正規通信を棚卸し | 不審通信を切り分けられる基準がある |
| 中 | インシデント対応手順を更新 | Kazuar検知時の隔離、調査、報告フローが決まっている |
Kazuarの対策で最も避けたいのは、公式ブログのIOCだけを登録して対応完了にしてしまうことです。今回のMicrosoft公式情報が示している本質は、Kazuarが長期潜伏、P2P的な内部連携、限定された外部通信、複数のC2手段、情報収集のステージングを組み合わせる脅威であるという点です。(Microsoft)
まずはDefender設定、ログ取得、除外設定、Advanced Huntingの4点を確認してください。そのうえで、ASRルールやネットワーク保護をAuditからBlockへ段階的に移行し、開発端末やサーバーを含めた全体の可視性を高めることが、Kazuar対策として現実的で効果的な第一歩です。
コメント