インターネット公開のWebサーバー（IIS・Linuxいずれも対象）を運用している方に向けた内容です。
Cisco Talosが2026年8月に公表した脅威アクター「UAT-10147」の攻撃活動は、既知の脆弱性を悪用した典型的な初期侵入から始まりますが、攻撃コードの修正やテストにAIツールを使って効率化している点が特徴です。約17万件のURLを標的リストとして管理し、政府機関・教育機関・技術系企業など幅広い対象に攻撃を仕掛けています。オンプレミスの公開サーバーを抱えている組織にとって、他人事ではない事例です。
何が起きるのか
攻撃の起点は、インターネットに公開されているWebサーバーの既知脆弱性です。
リモートコード実行（RCE、遠隔から任意のコマンドを実行できる状態）やWebシェル（Webサーバー上に設置される遠隔操作用のスクリプト）の設置から侵入が始まります。
Windows環境では、certutil（Windows標準のファイルダウンロード・証明書管理コマンド）やバッチファイルを使い、EfsPotato（権限昇格ツール）、QuasarRAT（遠隔操作型マルウェア）、BadIIS（IIS改ざん用マルウェア）などをダウンロードします。
SeImpersonatePrivilege（プロセスがユーザーになりすませる権限）が有効な場合は、これを悪用して管理者権限まで昇格を試みます。
さらにDefenderの除外リストにIISのディレクトリを追加し、検知を回避したうえで不正な管理者アカウントやRDPアカウントを作成します。
最終的にSPECTRE（クロスプラットフォーム対応のインプラント、HTTP経由でC2サーバーと通信する遠隔操作基盤）を設置し、長期的な制御下に置きます。
Linux環境でも同様にWebシェル経由で侵入したのち、既知の権限昇格手法を複数試行します。
特徴的なのは、Specterロットキット（ftrace hooksというカーネルのトレース機構を悪用してプロセス・ファイル・通信を隠すルートキット）を導入する点です。
これによりプロセス一覧やネットワーク通信の監視コマンドからも活動が見えなくなります。
なぜ起きるのか（原因の分解）
原因を段階的に見ていくと、単一の脆弱性の問題ではないことが分かります。
第一に、公開Webサーバーへのパッチ適用の遅れです。
既知の脆弱性を突かれているという点は、ゼロデイ（未公表の脆弱性）ではなく防御可能な攻撃であることを示しています。
第二に、Webサーバープロセスの権限設計の甘さです。
SeImpersonatePrivilegeのような強い権限がIISのワーカープロセスに残っていると、侵入後の権限昇格が容易になります。
第三に、送信方向（アウトバウンド）の通信制御の欠如です。
WebサーバーからC2サーバーへのHTTP通信やcertutil経由の外部ダウンロードが素通りする環境では、侵入後の道具立てが自由に進んでしまいます。
第四に、Linuxにおけるカーネルモジュールのロード制御の不備です。
Specterロットキットの導入には署名検証やモジュール制御の仕組みが機能していないことが前提になります。
そして今回の事例で特筆すべきは、攻撃側がAIツールを使ってエクスプロイトコードの修正・失敗原因の分析・再試行手順の生成を自動化している点です。
Pythonスクリプトでysoserial（Java環境のデシリアライズ攻撃ツール）を組み込み、書き込み可能なパスやViewState RCE（.NETのViewStateを悪用した遠隔コード実行）を自動探索する仕組みも確認されています。
攻撃の「試行回数」と「修正速度」が上がることで、従来なら気づけていたはずの防御の隙間を突破される可能性が高まります。
自分の環境が該当するか確認する
まず、インターネット公開しているWebサーバーの棚卸しから始めます。
- IISまたはApache/Nginx等のバージョンと公開パッチ適用状況を確認する（iisreset /status やパッケージマネージャーのバージョン照会コマンドで確認可能）
- Windowsサーバーで whoami /priv を実行し、IISワーカープロセスのアカウントにSeImpersonatePrivilegeが有効になっていないか確認する
- Windows Defenderの除外設定（フォルダ・プロセス除外）にIISディレクトリが不自然に追加されていないか確認する
- Linuxサーバーで lsmod を実行し、見覚えのないカーネルモジュールがロードされていないか確認する
- ファイアウォールやプロキシのアウトバウンドログを確認し、Webサーバープロセスからの不審な外部HTTP POST通信がないか調べる
これらは特別なツールがなくても、既存の運用コマンドで確認できる範囲です。
監視基盤（Zabbix、Datadog、CloudWatchなど）を使っている場合は、certutilの実行やIISサイト一覧取得コマンド（appcmd）の呼び出しをアラート条件に加えられるか、既存ルールを見直す価値があります。
対策の手順
侵入経路を塞ぐ観点と、侵入後の被害を抑える観点の両方が必要です。
1. 公開Webサーバーのパッチ適用サイクルを短縮する。既知脆弱性の悪用が起点なので、月次より短い間隔での適用を検討する
2. WAF（Web Application Firewall）またはIPS（侵入防止システム）で既知の攻撃パターンをブロックする設定を有効化する
3. IISのワーカープロセスからSeImpersonatePrivilegeなど不要な権限を剥奪し、最小権限で稼働させる
4. Webサーバープロセスからのアウトバウンド通信を必要な宛先のみに制限する。特にcertutil経由の外部ダウンロードは業務上不要であれば遮断する
5. Linuxでは署名済みモジュールのみロードを許可する設定（module.sig_enforce=1 など、カーネルの起動パラメータで制御）を検討する
6. 監視基盤にIISサイト一覧の取得コマンド実行、RDPアカウントの新規作成、Defender除外設定の変更をアラート条件として組み込む
クラウド移行を検討している組織であれば、この機会にWAFやIPSをマネージドサービス（AWS WAF、Azure Front Doorのマネージドルールなど）に切り替える選択肢も検討に値します。
オンプレミスで個別にパッチ管理していたWebサーバー群を、クラウド上のマネージドロードバランサー配下に集約すれば、脆弱性パッチの適用漏れを一元管理しやすくなります。
一方で、移行コストと運用体制の変更が伴うため、既存のオンプレ環境で上記のような設定点検を先に済ませておくほうが現実的な組織も多いはずです。
まとめ
今回の攻撃事例が示しているのは、既知脆弱性への対応が遅れると、AIによる攻撃効率化の影響を強く受けるという構図です。
- 公開Webサーバーのパッチ適用状況とバージョンをまず棚卸しする
- Windowsは whoami /priv、Linuxは lsmod でそれぞれ不審な権限・モジュールを点検する
- アウトバウンド通信の制御とDefender除外設定の監視ルールを見直す
- クラウド移行の予定があるなら、WAF・IPSのマネージド化も選択肢に入れる
まずは自組織の公開サーバー一覧とパッチ適用状況の確認から着手してみてください。