Microsoftが警告「nslookup×DNSルックアップ」でClickFixマルウェアを配布――“ダウンロード不要”の新手口と今すぐできる対策

「ファイルを落としていないのに感染した」──そんな事態を現実にする手口が出てきました。近年猛威を振るうソーシャルエンジニアリング“ClickFix”が進化し、Windows標準ツールの nslookup と DNSルックアップ を悪用して、目立たずに次段階のペイロードを受け渡す方式が確認されています。ポイントは、攻撃の“受け渡し”がWebのダウンロードではなく、日常的なDNS通信に紛れること。この記事では、仕組み・攻撃の流れ・検知が難しい理由と、個人/組織で効く防御策を整理します。

Microsoftが警告「nslookup×DNSルックアップ」でClickFixマルウェアを配布――“ダウンロード不要”の新手口と今すぐできる対策

ClickFixとは何か――「ユーザー自身に実行させる」最強クラスのだまし

ClickFixは、脆弱性を突くのではなく 人の判断を乗っ取る タイプの攻撃です。攻撃者は、もっともらしい画面や案内で被害者を焦らせ、自分の手でコマンドを実行 させます。典型例は次のような誘導です。

偽CAPTCHA（「確認のために操作してください」など）
偽のエラー表示（「PCを修復する必要があります」）
「今すぐこの手順で直してください」という指示ページ
広告からの誘導（マルバタイジング）やフィッシングリンク

実行場所も“正規の操作”に見える点が厄介です。

Windowsの「ファイル名を指定して実行（Win+R）」
コマンドプロンプト
macOSのターミナル（派生型で使われることも）

ここで重要なのは、セキュリティ製品がブロックしづらい形で“本人の意思で実行”が成立し得ること。近年はClickFixの派生（例：FileFix/ConsentFix/CrashFix/GlitchFix/JackFix など）も見られ、名称よりも「誘導して実行させる構造」が広がっています。

新型のポイント：nslookupでDNS応答に“隠した”次段ペイロードを取り出す

今回の進化型では、従来の「怪しいサイトからダウンロード」ではなく、DNSルックアップ を“受け渡しの通路”として使います。被害者は、案内に従って Windowsの実行ダイアログなどでコマンドを走らせてしまい、そこに nslookup（正規のネットワーク診断ツール） が登場します。

攻撃の概念はこうです。

被害者が指示通りにコマンドを実行
nslookupが、攻撃者の用意した 外部DNSサーバー を参照して問い合わせ
返ってきたDNS応答の一部（例：「Name:」のようなフィールド）を抽出
抽出した内容が 次段の実行要素（第二段階ペイロード） として機能
以降、追加のマルウェア展開や遠隔操作へ発展

ここでの本質は、マルウェアの“搬送”がHTTPダウンロードではなくDNSに見えることです。DNSは多くの環境で常時発生し、監視の粒度が粗いと「いつもの通信」に埋もれます。攻撃者側にとっては、軽量で、目立ちにくく、環境によっては検知の盲点になりやすい“ステージング/合図のチャネル”になり得ます。

攻撃チェーンのイメージ：DNSルックアップからRATなどへ拡大

DNSで受け渡された第二段階が動くと、感染は一気に進みます。一般にこの手のローダー型は、状況に応じて追加モジュールを落とし、最終的に 遠隔操作型（RAT） や情報窃取、横展開の足場へつながります。

想定される展開例は次の通りです。

端末情報の収集（OS/権限/セキュリティ製品/ドメイン参加状況）
通信先の切替（環境に応じてC2を変える）
追加ペイロードの取得（後段は別経路を使うこともある）
資格情報の窃取、持続化（自動起動登録など）
社内ネットワーク内の探索と拡大

「DNSで渡すのは第二段階“まで”」という設計でも十分危険で、初期侵入の成功率を上げるのが狙いです。

なぜ見抜きにくいのか――3つの“紛れ”ポイント

1) 正規ツールの悪用（Living off the Land）

nslookup自体はWindows標準で、ネットワークの疎通確認に使われます。つまり、ツール名だけで異常と判断しづらい。

2) Webダウンロードが見えない

「怪しいexeをダウンロードした」という痕跡が薄く、プロキシやURLフィルタ中心の防御だと 初動が抜けやすい。

3) DNSは日常的に多発し、監視の前提が甘い

多くの組織はHTTP/HTTPSほどDNSを深掘りしていません。外部DNSの利用や不自然な問い合わせパターンが埋もれると、“普通の通信”に見えるまま進行します。

いま効く対策：個人と組織でやるべきこと

個人ユーザー：まず「指示されてもコマンドを打たない」

Web上のCAPTCHAやエラー画面が コマンド実行を要求した時点で中止
「Win+Rを押して…」「貼り付けてEnter」系の手順は、正規サポートでも例外的
不安なら、公式サイトや正規窓口から再確認（リンクは踏まずに自分で検索して到達）

組織：DNSと端末操作の両面で“実行を止める”

外部DNSサーバーへの直接問い合わせを制限（社内指定リゾルバ以外を遮断/監視）
DNSログの収集・可視化（問い合わせ先、頻度、長いサブドメイン、規則的な連番などを検知）
端末側の監視：
- Win+R（Explorer/Run）からの不審なコマンド実行
- nslookupの実行に 外部DNS指定 が付く挙動
- コマンドライン監査（EDR/監査ログ）で“誰が何を実行したか”を残す
ユーザー教育を“画面例ベース”で更新（偽CAPTCHA/偽修復指示を実例で学ばせる）
権限設計：一般ユーザーの権限を抑え、被害を局所化（管理者権限の乱用を防ぐ）

インシデント対応の即席チェック（疑いが出たら）

直近の端末で、nslookup実行履歴・コマンドラインログ・Run起点の実行を確認
外部DNSサーバーへの通信有無（特定IPへの53/UDP・DoH/DoTの利用も）
端末の不審プロセス、永続化（自動起動、タスク、レジストリ）を点検
同様の誘導ページ閲覧が他端末に広がっていないか、メール/広告経路を追跡

まとめ：技術より“手順”が狙われる時代、DNSは新しい盲点になり得る

ClickFixの怖さは、脆弱性よりも 人の操作を武器にする 点にあります。そこへDNSという“日常の通信”を組み合わせると、従来の「怪しいダウンロードを止める」発想だけでは守り切れません。
対策の核心はシンプルで、(1) コマンド実行を促す画面を疑う、(2) 外部DNSを許さない/見える化する、(3) 端末の実行ログを押さえる。この3点を固めるだけでも、同種攻撃の成功率を大きく下げられます。