偽BSODで実行を誘導するClickFix攻撃、手口の仕組みと防御論点

本記事が扱う事象は、Web上に偽のWindowsクラッシュ画面（BSOD：ブルースクリーン・オブ・デス）を表示し、利用者に自分でコマンドを実行させる「ClickFix（クリックフィックス）」型の攻撃です。ホテルなどホスピタリティ分野を主な標的として、フィッシングから誘導された偽サイト上で「修復」を装い、PowerShell（パワーシェル）や正規ツールを悪用してRAT（リモートアクセス型トロイの木馬）を導入する流れが報告されています。 (Securonix)

• 報告された攻撃キャンペーンの輪郭と、狙われた業務領域
• ClickFixという誘導構造と、偽BSODが担う役割
• 今回報告の攻撃チェーンを、段階ごとに分解する
• DCRat導入が意味する影響と、見落としやすい論点
• 防御側で整理されている対策論点と、運用上の設計課題

報告された攻撃キャンペーンの輪郭と、狙われた業務領域

本件は、偽の予約関連連絡から偽サイトに誘導し、偽BSODで操作を固定した上で「利用者自身の手作業」を攻撃チェーンに組み込む点が中核です。 (Securonix)

報告では、Booking.com（ブッキングドットコム）を装う「予約キャンセル」などの連絡を起点に、宿泊施設側の担当者をクリック誘導する流れが整理されています。誘導先は正規サイトを模したページで、表示上は読み込み不良や認証確認を示し、業務中の確認作業に見える体裁を取ります。こうした入口設計により、メール対策やWebフィルタだけでは判断が割れる場面が残り得ます。 (SecurityWeek)

一方で、今回の報告は「ホスピタリティ分野を中心」とされていますが、ClickFix自体は特定業界に限定された技術ではありません。過去の公的アラートやベンダー解説では、偽CAPTCHA（キャプチャ）や偽エラーを使い、端末側でコマンド実行を誘導するモデルが複数の業種で観測されてきた経緯があります。つまり、業界名は入口の偽装素材であり、手口の再利用可能性が論点になります。 (Microsoft)

ClickFixという誘導構造と、偽BSODが担う役割

ClickFixは、検知回避のために「攻撃者が実行する」のではなく「利用者が実行する」形へ寄せる社会工学の型として説明されています。 (Microsoft)

Microsoftの解説では、フィッシングや改ざんサイトなどから視覚的な「おとりページ」へ導き、利用者にコマンドを入力・実行させることで、通常の自動防御や自動解析をすり抜ける余地が生まれる点が整理されています。ここで重要なのは、端末上の実行が「ユーザー操作」として記録されやすいことです。そのため、許可済みのスクリプト実行や正規ツール起動に紛れやすい構造になります。 (Microsoft)

他方、偽BSODは「画面が停止した」状況を演出し、作業継続のための手順提示へ自然に接続させる役割を持ちます。報告では、偽CAPTCHA風のエラー表示や「ページ読み込み」エラーの後に、BSODアニメーションが出る流れが記載されています。そうすることによって、ブラウザ上の出来事をOS側の障害に見せ替え、Win+R（ファイル名を指定して実行）などの操作へ誘導する説明が成立します。 (Securonix)

今回報告の攻撃チェーンを、段階ごとに分解する

入口からRAT導入までを分解すると「偽メール→偽サイト→偽エラー/偽BSOD→手動コマンド→追加取得→常駐/遠隔操作」の順で組まれています。 (Securonix)

報告されたキャンペーン（PHALT#BLYXと呼称）では、まず偽の予約関連メールでリンクを踏ませ、模倣サイトへ到達させます。サイト上では偽の認証やエラーが表示され、クリック動作を契機に偽BSODが表示される構成です。ここで「修復手順」として提示されるのが、PowerShell（パワーシェル）の実行や、クリップボードへ自動コピーされた文字列の貼り付けです。利用者が自分で貼り付けるため、技術的には単純でも、監視側の切り分けは難度が上がりまうす。 (Securonix)

なお、Securonixの分析や複数メディアの要約では、後段でMSBuild.exe（MSBuild：エムエスビルド）など正規のビルド機能を悪用し、DCRatの導入へつなぐ点が示されています。正規コンポーネントの利用は「不正ツールの新規設置」を伴わない場合があり、ログの読み方と相関分析が実務上の確認点となります。 (Securonix)

そのため、段階の整理は検知設計にも直結します。要点を整理すると、監視すべき点は「メール本文」だけでなく「ブラウザ表示の不自然さ」と「端末上の実行履歴」に分かれます。

ただし、組織ごとに正規ツールの利用実態は異なります。以上を踏まえると、単純な「MSBuild起動＝不正」とは断定できず、平常時の利用ベースラインを持つことが判断材料として重要です。 (BleepingComputer)

DCRat導入が意味する影響と、見落としやすい論点

最終段で導入されるDCRatは、遠隔操作の足場となり、追加の情報窃取や二次ペイロード展開へ接続し得る点が要点です。 (Dark Reading)

複数の報道・解説では、この種のキャンペーンの狙いが「端末への遠隔アクセス確立」に置かれ、その後の横展開や追加のマルウェア配布へつながり得ると整理されています。ここでの論点は、初期侵入がゼロデイ（未知脆弱性）ではなく、利用者の手動実行で成立している点です。この点から、脆弱性管理だけに依存した防御設計では説明が不足しやすく、操作誘導と実行制御の両面が必要になります。 (Microsoft)

また、正規機能の悪用は、セキュリティ製品のアラート粒度を粗くする方向に働きます。PowerShellやMSBuildは業務で使われることがあり、完全遮断が困難な環境もあります。言い換えると、今回の手口は「許可されがちな機能」を前提にし、悪性判定を行為の連鎖で捉えさせる設計です。そうすることによって、単発イベントの遮断よりも、複数イベントの相関が重要になります。 (Securonix)

防御側で整理されている対策論点と、運用上の設計課題

公表情報が共通して示す方向性は、手動実行の誘導点を減らし、スクリプト実行と正規ツール悪用を「許可条件付き」で扱う運用に寄せることです。 (Microsoft)

Microsoftの解説では、ClickFixが「利用者に実行させる」点を前提に、フィッシング対策だけでなく、PowerShellの監視・制御、実行ポリシー、攻撃面削減（ASR：Attack Surface Reduction、攻撃面削減ルール）など複合対策の考え方が示されています。公的アラートでも同様に、偽CAPTCHAや偽修復手順でコマンド実行へ誘導されるパターンが共有されており、教育だけでなく技術制御の位置づけが明確です。 (Microsoft)

ただし、現場運用には条件差が生じます。例えば、フロント業務端末では開発系ツールが不要でも、バックオフィス端末では自動化のためにPowerShellが使われる場合があります。以上を踏まえると、端末区分ごとに「許可する実行の範囲」を変え、例外管理を記録する設計が判断材料として重要である、という整理になります。 (BleepingComputer)

なお、今回の入口は「予約・顧客対応」という業務文脈に寄せられましたが、同種のClickFixは偽Windows Update（ウィンドウズ・アップデート）画面など別の表示でも成立します。つまり、画面の種類が変わっても「手動で貼り付けて実行」が共通項になります。この点から、運用上は「正規の更新や認証が手動コード入力を要求しない」というルール化、ならびに手動実行が発生した際の即時切り分け手順の整備が、継続的な課題として残ります。 (CSO Online)

• TechRadar
• Tom's Guide
• PC Gamer
• TechRadar
• TechRadar