ClickFixで実行されるコマンドで、以下のようなものを観測した。
powershell -c "Invoke-Expression(([System.Text.StringBuilder]::new((Get-Clipboard -Raw))).Remove(0, 256).ToString());"
私がこのコマンドを見つけたのは1週間ほど前のことである。このようなコマンドを用いる事例について書かれた情報が見つからなかったのでここに記す。先行文献があったら教えてほしい。
概要
観測した手法は、「ファイル名を指定して実行」ダイアログへのペーストが改行で打ち切られることを利用して、後続のスクリプトをクリップボードのデータ内に埋め込んで実行するものである。
これはClickFixの新しい手法と考えられる。ただしこの手法を用いることによる被害者誘導の面での利点はなく、検知回避や解析妨害の目的が強いと推測される。
新しい手法ではあれど新しい脅威というわけではないので、従来通りの対策をすることが肝要である。
How it works
実行されるコマンドと、その時クリップボードにあったデータは以下の通り。
powershell -c "Invoke-Expression(([System.Text.StringBuilder]::new((Get-Clipboard -Raw))).Remove(0, 256).ToString());"
クリップボードデータの1行目に、実行されるコマンドと、その後ろに多くのホワイトスペース（赤枠部分）がある。合わせて260文字分であった。その後改行がありPowerShellスクリプトが続く。
「ファイル名を指定して実行」ダイアログにペーストすると、データは改行で打ち切られ1行目のみがペーストされる。1行目の末尾にはホワイトスペースがあるため、以下のような見た目になる。
OKを押すと1行目のコマンドが実行される。このコマンドではクリップボードのデータを取得し、先頭256バイトを削除し、残りをPowerShellスクリプトとして実行している。先頭256バイトを削除した残りのデータは以下のようになり、これがPowerShellスクリプトとして実行される。
このように、今回観測した手法は、クリップボードにユーザーに実行させたいコマンドだけでなく、後続のスクリプトをも埋め込むという手法である。
従来のClickFixに対する優位点
従来ClickFixでは「ファイル名を指定して実行」ダイアログでのコマンド実行の後にインターネットに後続のスクリプトを取得しに行っていた。一方この手法ではクリップボードにコマンドと後続のスクリプトをまとめて格納している。
これにより以下の利点がある。
- URL情報がコマンド内に現れないので検知、ブロックされにくい。ただし、
Get-Clipboardが特徴的なのでここで検知、ブロックは可能。 - 後続のスクリプトをホストする必要がないのでテイクダウンされてスクリプトを取得できなくなる事態が発生しない。
- プロセス情報に具体的なコマンドが含まれないので解析が困難になる。従来だとコマンド内のURLから後続のスクリプトを取得すれば解析は容易であった。
これらの優位点は検知回避や解析妨害に利するもので、ユーザーの騙し方などが新しくなったわけではない。このため、脅威としては従来のClickFixを超えるものではない。
対策
従来とコマンドが異なるため検知やブロックの方法が変わるものの、それ以外では従来のClickFixと同様の対策を取ればよい。
予防
- ユーザーの教育を行う。「Webサイトにコンピュータの操作を指示されても従わない」「Win+Rが出てきたらそれは詐欺」など。
- 「ファイル名を指定して実行」を無効化する。
- AppLockerやWDACでユーザーレベルでのPowerShellの実行を制限する。
- PowerShellのConstrained Language（制約付き言語）モードを利用する。
技術的な対策についてはNasotasy氏のエントリに書かれている。
検知
- 「ファイル名を指定して実行」で実行されたコマンドはレジストリに記録される。そこに
powershell,invoke-expression,get-clipboardなどが含まれているものがないかチェックする。
Sysmonでレジストリ書き込みのイベントを捕まえるか、EDR製品を使うのが現実的。
参考リンク
- ClickFixから守る、攻撃を防ぐ対策と設定例｜Nasotasy
基本的なことはここを見ておけばOK - 同様の手口の解析事例
プロセス情報を見ても詳細な挙動を追いかけられないことがわかる