事例を紹介しよう。ReliaQuestが発表した「ClickFix Evolves with PySoxy Proxying」では、初期アクセスや攻撃の基盤構築の入り口としてクリックフィックスが使われていると報告されている。これまで同様、ユーザーの操作を起点にPowerShellを実行させるが、ディスクにマルウェアやDLLを書き込むのではなく、メモリでのみ実行する攻撃のインフラを構築、永続化のためスクリプトを40分ごとに実行するようタスクスケジューラーに登録する。
その後、C2サーバに接続する小さなエージェントを動かし、3秒ごとにサーバへアクセスさせ、実行させたい命令が書かれたJSON形式のファイルの存在をチェックする。
加えて、curlによる疎通の確認が取れれば、「PySoxy」というPythonで書かれたオープンソースのSOCKSプロキシツールを端末に配置する。これを用いることで掌握した端末を中継点にして、さらに内部へと攻撃を拡大していくのである。
レポートではこの後、実際に攻撃者がどのような悪意ある行動を行ったかまでは触れていない。レポートを公開したReliaQuestが検知し止めた可能性もあるが、侵入した攻撃者がこの侵入口を売る「イニシャル・アクセス・ブローカー」の可能性もあるだろう。本件に関しては、筆者が主宰するポッドキャスト「セキュリティのアレ」でも紹介しているので、ぜひ聞いてみてほしい。
ClickFix Evolves with PySoxy Proxying | ReliaQuest Threat Research
https://reliaquest.com/blog/threat-spotlight-clickfix-evolves-with-pysoxy-proxying/
第305回 間がワルいとね!スペシャル! - podcast - #セキュリティのアレ
https://www.tsujileaks.com/?p=2299
また、フォーティネットが発表した、ランサムウェアギャングの「Interlock」による事例は、初期アクセスの手口としてクリックフィックスが使用された可能性を示唆している。クリックフィックスにより、まずユーザーの端末でPowerShellコマンドが実行され、外部からZIPファイルがダウンロードされ、バックドアに使われた。
Interlock Ransomware: New Techniques, Same Old Tricks | FortiGuard Labs
https://www.fortinet.com/blog/threat-research/interlock-ransomware-new-techniques-same-old-tricks
第291回 皆さんのお気に入りのふりかけ教えてちょ!スペシャル! - podcast - #セキュリティのアレ
https://www.tsujileaks.com/?p=2194
ランサムウェアグループLeakNetによる事例も紹介しよう。同グループは他のイニシャル・アクセス・ブローカーから初期アクセスを購入していたようだが、コスト削減や攻撃の案件待ちをなくすために、自分たちでクリックフィックスのキャンペーンを行う方向に転換したと考えられている。古典的なクリックフィックスの手口を利用し、VBScriptなどを用いて「Deno」という正規のJavaScript/TypeScriptランタイムを端末に持ち込む手口を取っていた。
これらの事例の詳細については各レポートを参照するか、私たちのポッドキャストを参照してほしい。
Casting a Wider Net: ClickFix, Deno, and LeakNet’s Scaling Threat
https://reliaquest.com/blog/threat-spotlight-casting-a-wider-net-clickfix-deno-and-leaknets-scaling-threat
第296回 真相 in the Dark!スペシャル! - podcast - #セキュリティのアレ
https://www.tsujileaks.com/?p=2230
いかがだろうか。これらはクリックフィックスが単なるマルウェア感染のためだけのの手法ではなく、既に「侵入口をこじ開ける」という手法になっているという事例だ。だからこそ、クリックフィックスのことをなめてはならないのだ。
このように、クリックフィックスは「ユーザーに届く」「見分けが付かない」「応用が利く」という大きな特徴がある。対策を行う上で「銀の弾丸」となるような完ぺきな方法はない。そのため、複数の対策を組み合わせることが重要だ。
まずは「教育と周知徹底」を挙げたい。本来であればシステムのみで処理できればいいのだが、防御は多くの場合において後追いとなり、検知・遮断が追いつかないという現実がついて回る。どうしても人に届いてしまうことは避けられないことを考慮すると、ユーザーのリテラシーの底上げが必要不可欠となるだろう。
重要なのは、「CAPTCHA画面に気をつけろ」とだけ教えるのではなく、偽のエラー画面やブルースクリーン、更新要求など、「指示に従ってアクションを起こさせる画面は全て怪しい」と、応用が利くようにさまざまなパターンを丁寧に教えることだ。そして、少しでも怪しいと思ったら「すぐに相談・報告する」というルールを周知徹底することで、もし誰かが遭遇しても、社内へ迅速に注意喚起を行い、被害を防ぐことができる。攻撃メールの訓練が多くの企業で行われたように、今後は最新の手法を常にアップデートする「クリックフィックス訓練」も必要かもしれない。
また、Windows Defender Application Control(WDAC)やAppLockerを利用して、powershell.exe、mshta.exe、wscript.exe、cscript.exeといった正規ツールの起動を制御することも、非常に強力な対策となる。これは、ユーザーに「Windows キー + R」を使わせないようにする対策ではなく、攻撃者に悪用されやすいツールの実行自体を制御するという考え方である。
ただし、全社一律で禁止するのではなく、開発部門ではPowerShellの利用を許可し、営業部門や人事部門では不要な実行を制限するなど、部署や業務ごとに「不要なものを止める」運用を検討すべきだろう。全てのツールを止めることが難しい場合でも、攻撃チェーンの一部を遮断し、攻撃者の手間を増やす効果が期待できる。自社の通常運用を把握しておくことは、このような対策をどこまで適用できるかを判断するための重要なポイントである。
Microsoft Defender for Endpoint などで利用できる攻撃面の縮小(ASR)ルールを活用し、被害軽減に加え、通信制御を組み合わせることで、マルウェアの実行や一部の認証情報窃取など、ASRルールが対象とする攻撃手法を阻止できるようにすることも重要だ。
攻撃者は、PowerShellへの検知や実行制御を回避するため、mshta.exeやrundll32.exeなど別の正規ツールへ処理を移すことがある。そのため、curl.exeやcertutil.exeなどの通信・取得に利用されやすいツールも含め、これらのプロセスがどのような親プロセスから起動され、どのような引数で実行され、どこへ通信しているのかを監視する必要がある。
その観点から、少なくとも以下のプロセスは監視対象としておきたい。
また、イベントログを確認する場合は、4688(プロセス作成)で実行ファイル名、コマンドライン、親プロセスを確認したい。サービスを作成する攻撃であれば4697やSystemログの7045も確認対象となる。さらに、侵入後の横展開を把握するには5140(共有アクセス)や5145(詳細なファイル共有アクセス)が参考になる。
今回投げた石とは、守る側に「脅威の見積もりの甘さはないか」というものだ。クリックフィックスは人を騙す手法と過小評価されがちだが、実際には「たった1人のユーザーのアクションが、ネットワーク全体の致命的な侵害を許す侵入口になってしまう」というほど危険なものなのだ。
そして、対策の難しさを通じ「自分たちの運用を知り、何が止められるか、何を許可するかを考える視点」を持つべきであると考える。クリックフィックスはシンプルな手口だが、防ぐ側が考えるべきことや非常に多いし、コストもかかる。運用を知るという観点では、外部のSOC(Security Operation Centrer)やMSSP(Managed Security Service Provider)に監視を任せている場合、「システムを運用している組織」と「監視している組織」が別になることもあるだろう。そこには「溝」がある。昨今の攻撃は正規のPowerShellが悪用されるため、監視側が異常を検知して運用側に確認しても「検証で使っている」と回答されると、後日本当の攻撃が発生した際に「以前も運用で使っていると言っていたから」と、重大な侵害を見逃しかねない。運用を知るということの重要性も、併せて考えていただきたい。
クリックフィックスとは、「単なるマルウェア感染の手口ではなく、ユーザーを巧みに操り、気付かれないようにネットワーク深部へ侵入するための極めて狡猾で危険な『経路』だ」と考える。
私が投じた一石の波紋が多くの組織に届き、真剣に議論されることを願っている。
Copyright © ITmedia, Inc. All Rights Reserved.
編集部からのお知らせ