JPCERT/CC Eyes

はじめに

2024年6月25日、JPCERT/CCからVolt Typhoonの攻撃活動に関する注意喚起を発行しました。
重要インフラを狙う長期的な攻撃キャンペーンのインパクトやその戦術に注目が集まるところ、こうした脅威にどのようなアプローチで対応していけばよいのか考えてみたいと思います。

JPCERT/CC Operation Blotless攻撃キャンペーンに関する注意喚起
https://www.jpcert.or.jp/at/2024/at240013.html

インディケータ情報依存からの脱却の必要性

今年の5月に開催されたRSAカンファレンスにて、FBI、NSA、CISA、Microsoftの各担当者がVolt Typhoonに関する共同セッションを行いました。
この発表において、NSAの担当者であるAdamski氏は、Volt Typhoonに関するNSAやCISAのアドバイザリを見た人々から「インディケータ情報を送ってくれればログを見ます」とよく言われたことに触れ、「そういうこと（IoCによる侵害有無の調査）ではなく、これはLoTL（Living off the Land）の話であり、アイデンティティとアクセス管理の話をしている」とコメント[1]しています。これはどういう意味なのでしょうか。

APT事案のインシデント対応の多くでは、情報共有活動等から不正通信先やマルウェアに関する情報である「IoC（Indicator of Compromise）」情報を入手し、初期侵入経路での不正アクセス有無、マルウェア感染有無を調査することから始まることがあります。こうした想定の下で、多くの情報共有活動では、広く知られていないAPTの攻撃キャンペーンに関するIoC情報をいかに速やかに見つけ、共有するかということに取り組んでいます。

しかし、Volt Typhoonの攻撃キャンペーンに対しては、こうした従前のアプローチは効果的ではないと考えられます。
一般的なAPTでは攻撃キャンペーン期間内においてC2サーバーやマルウェアを使いまわすため、これらの情報を共有することで、未認知の被害をあぶり出すことや被害拡大防止を行うことができます。このような対抗策は「IoC情報ベースのアプローチ」と言えるかと思います。
Volt Typhoonは、グループ固有のマルウェアをほとんど使わないなどのLoTL戦術の徹底により、被害現場にはIoCとなる情報をほとんど残しません。そして、Volt Typhoonが単なるLoTL戦術を取る他のアクターと違う点として、1回あたりの侵害期間が短く[2]、侵害範囲が限定的であることから、被害現場に残るアーティファクトの量がそもそも圧倒的に少ないことが挙げられます。アーティファクトが少なければ、IoC情報を作出できる機会／量も大きく減ります。

一般的なAPTキャンペーンの対応として、Initial Accessに関するIoC情報の共有も有効です。ここ数年で増えているSSL-VPNへの不正アクセス元情報や、スピアフィッシングメールのメールアドレス、件名、添付ファイル名などもIoC情報として共有されることがあります。これも攻撃者がInitial Access方法を「使いまわし」することを逆手にとったアプローチです。
他方でVolt Typhoonは少なくとも2023年12月までの攻撃活動においては、KVボットネットを攻撃インフラとして多用していたと報告[3]されています。

多くのAPTアクターは攻撃インフラを自前で調達・運用していると考えられるため、限られたリソースの中で効率的にオペレーションを行うためにC2サーバーやマルウェアの使いまわしを合理的に選択しているのではないかと考えられます。
他方で大規模なボットネットを使う場合、ボットネットの構築、運用・維持に膨大なリソースが必要であるため、基本的に単独の攻撃グループが攻撃自体の実施とボットネットの運用と並行して行うことは困難と思われます。いわゆるサイバークライム系の攻撃活動ではボットネットの構築・運用グループと、これを利用した複数のクライム系グループとの分担・連携が度々観測されています。
KVボットネットを追跡してきたLumen社によると、KVボットネットはVolt Typhoon以外のアクターの攻撃活動にも使われている可能性が指摘[4]されています。KVボットネットもボットネット自体の構築・運用を行うグループとこれを使って攻撃活動を行う複数グループ間の連携が存在するのかもしれません。

前置きが長くなりましたが、大規模なボットネットを使うことで、標的組織が所在する地域内に所在するボットから侵入することができ、被害組織から見たときに国内からのアクセスとして見えることで検知回避／遅延を狙ったり、あるいは、攻撃インフラの使いまわしをせず、標的組織ごとに異なるアクセス元からの不正アクセスを行ったりすることも可能です。Volt Typhoonの攻撃インフラをすべて把握できているわけではありませんが、ボットネットを攻撃インフラに使っていたことから、基本的にInitial Access等の通信元を地域／標的間で広く使いまわしていた可能性は小さいと推測できます。

以上のことから、Volt Typhoonの攻撃活動に対して、従前の「攻撃者によるマルウェアや攻撃インフラの使いまわしを前提としたIoC情報をベースとした対処アプローチ」は有効性が低いと考えることができます。

なぜThreat Huntingを考える必要があるのか

注意喚起でも触れたとおり、Volt Typhoonの攻撃キャンペーン（広義の攻撃キャンペーン）は非常に長期間のものであり、合同で注意喚起を発表したアメリカ・イギリス・カナダ・オーストラリア・ニュージーランドの見解によれば、この攻撃キャンペーンは標的組織に将来「再侵入」するためのものであるとされ、これまでに我々が見てきたVolt Typhoonの過去の攻撃キャンペーン（狭義の攻撃キャンペーン）は、より長期的な攻撃活動の「準備段階」と考えることができます。

NTDSファイルの窃取による認証情報収集を目的とするVolt Typhoonによる狭義の攻撃キャンペーンでは、基本的にドメインコントローラーが狙われ、侵害範囲は極めて限定的です。
先述のとおり、従前のIoC情報／シグニチャベースの調査アプローチが有効でない中、ドメインコントローラー自体が不正に操作されたことをどのように検知すればいいのかが問題となります。そこで注目されているのがThreat Huntingであり、米当局のアドバイザリでも「proactive hunting」として同様のアプローチが推奨されています。

Threat Huntingの定義もさまざまで、この用語は理論の紹介から特定製品のPRまで、幅広い文脈で使われています。基本的にはアノマリ（Anomalies）を探しだすことだと考えられ、不審なプロセスの存在といった技術的アノマリや、不審な時間帯でのアカウントの挙動といった文脈的アノマリがあります。こうした、ベースラインから逸脱したアノマリを探しだすことがThreat Huntingの基本的な考え方です。
そのためには、自組織のシステム／ネットワーク運用における「ベースライン」の把握が必要になります。JPCERT/CCでも過去にActiveDirectoryのログ分析を紹介するコンテンツを公開[5]してきましたが、Active Directoryのログが一定期間保存されていなかったり、正規のアカウントが整理されていなかったりすれば、ベースラインを把握できず、アノマリを検出しようがありません。

「Threat Huntingを導入しよう！」と言いだしたところですぐに導入できるようなものではありません。何かツールやサービスを導入すれば実現できるものではなく、Active Directory の各種ログに加え、FWや侵入経路となりそうなネットワークアプライアンスなど各種機器のログの設定・保存・定期的なチェックが必要になります。Active Directoryのログだけでも膨大であり、これをどれだけの期間残すのか、どのタイミングで誰がログをチェックするのかなど、運用コストを上げる難しい判断が必要になります。また、アカウントの整理／棚卸しといってもすぐに行えるものではなく、社内／グループ内のさまざまな運用・管理部門、担当者との調整が必要です。
そうなると、「Volt Typhoonへの対策としてThreat Huntingを導入する」という単純な考え方に基づく導入は現実的ではありません。

一方で、こうした対策項目は、いわゆる「ラテラルムーブメント対策」で言われていることとほとんど同じです。ここ数年で被害が増加してきたランサムウェア攻撃においては、横展開等のために正規ツールの利用、管理不備のあるアカウントの悪用など、要するにLoTL戦術が使われています。特にアフィリエイトスキームで攻撃活動を行っているアフィリエイトは自前でカスタマイズマルウェアを調達する能力／リソースがないため、正規ツールや商用ツールの利用に依存しています。
ランサムウェア攻撃については侵害原因の特定が不徹底に終わっているケース[6]もあり、また、侵入経路に関するログの不足から、不正アクセス元に関する情報が現場から提供されにくい状況にあります。そのため、被害現場から得たIoC情報を情報共有活動で展開できるケースがほとんどありません。ランサムウェア攻撃への対処においてもIoC情報依存からの脱却が求められています。
さらに、アカウントの棚卸しやアノマリ検出の仕組みというのは内部不正対策で求められる対策とも共通しています。

Volt Typhoon対策のためにThreat Huntingの仕組みを導入する、というのではなく、ランサムウェア対策、内部不正対策など、あらゆる脅威に共通で対応できる、基盤的な対策として導入を検討する方が組織内での納得感があるのではないでしょうか。

さいごに：攻撃「キャンペーン」単位の視点と対応コストの再分配について

個別の事案単位で見ると「被害」がすでに出ているわけですが、長期的な攻撃キャンペーン全体の視点から見ると、攻撃者側はまだ最終目的は達成していないわけで、何を「被害」と考えるか／定義するかによって、この脅威の捉え方はかなり変わるのではないでしょうか。

従前のAPTキャンペーンへの対応においては、過去の攻撃被害を掘り返して「こんな被害があった」という情報／報道が飛び交います。法令上の届出制度等も「（過去に）どのような被害があったのか」という点にフォーカスされ、行政への報告、被害の公表など、事後対応としてのインシデント対応に被害組織は追われることとなります。基本的には個別の事案単位でインシデント対応、行政側の対応が行われます。攻撃キャンペーン全体や今この瞬間のアクターの動静を踏まえて、「今攻撃を受けている」「これから攻撃を受けるかもしれない」組織への保護という観点はありません。
現状のインシデント対応や制度は過去の事象に関わるコスト負担が高く、将来の被害予防のための対策コストを支払うかどうかは各組織での判断に任されています。近い将来において最終的な被害にあう恐れのある潜在的な被害組織をどう保護するのか考えたとき、既存の制度・体制における「事後の被害／原因追及を行う」仕組みでは対応しきれず、基本的に「（将来の脅威に対しては）各自で自分を守れ」ということにしかなりません。

昨年5月以降の米当局をはじめとした一連の情報発信は、公的機関等の被害に関する情報や、「将来、大規模な攻撃を行う可能性のあるアクターの動静に関する情報」の発信であり、場合によってはインテリジェンス情報といった機微な情報として扱われるような情報の発信と捉えることもできます。
こうした機微な情報はややもすると長期間非開示になることも多く、開示されたとしても、極めて限定的な範囲・用途に絞られて、対処の現場で活用されないこともあります。
長期的かつ継続中の攻撃キャンペーンに対して、情報開示（2023年5月、2024年2月の米当局の情報開示）や攻撃インフラへの対処（2023年12月のKVボットネットのテイクダウン）が米側では取り組まれており、民間のセキュリティベンダーからの情報提供に基づくアドバイザリも提供されています。「いつ来るかわからない攻撃に各自で備えよ」というだけでなく、「いつその攻撃が本格化するのか」「何をすればいいのか」が積極的に国側から開示されたケースと捉えることができます。

従前のAPTキャンペーンに対する対処の多くは、攻撃キャンペーン後にパブリックアトリビューションや刑事訴追を行うことが多く、一部のアクターには効果を発揮したと考えられますが、基本的に対処は「後追い」です。やや楽観的な見方かもしれませんが、今回は現在進行形で攻撃キャンペーンが追跡されており、将来の被害防止等の対処を行うことができるかもしれません。
「後追い」でない、「今／これからどう備えるか」という今回の攻撃活動への対処において、今後も積極的な情報発信と具体的な対策方法の検討に取り組んでいきます。

＜補足＞ボットネットインフラをどうするのか

先述のとおり、Volt Typhoonは攻撃インフラとして大規模なボットネットを使っていました。このKVボットネットは正規利用されているSOHOルーターを侵害することで構築されていました。一般的な、VPS等を使ったC2サーバーに比べて、こうした大規模なボットネットインフラが攻撃検知回避に有利になってしまっている点は先に解説したとおりです。
一般的なC2サーバーは攻撃キャンペーン期間中に使いまわされますが、攻撃キャンペーンが終われば短期的に「使い捨て」されます。他方で大規模なボットネットは複数の攻撃キャンペーン、あるいは複数のアクターにおいて長期間使われます。したがって、海外当局は長期間追跡し構造を解明し、大規模なテイクダウンオペレーションを実施して解体に持ち込もうとします。ただ、この解明・特定には長い時間を必要とするため、テイクダウンまで数年単位で悪用が続いてしまいます。2020年のTrickbotへの対抗オペレーションのように、一時的な麻痺を狙う対処もあり得ますが、冗長性の強いボットインフラの場合、しばらくして復活することも考えられます。

基本的には、ボットインフラを作らせないことにも注力する必要があります。
JPCERT/CCからも日々注意喚起を発出したり、侵害されたホストへの通知オペレーションを実施したりしていますが、特に通知オペレーションはこうしたボットネットなどの大規模インフラに悪用されないような予防措置的意味もあります。
他方で、JPCERT/CCからの注意喚起や個別通知が「届かない」層もあり、特に、中小規模の事業者や個人で利用する機器にはなかなか情報が伝わりません。脆弱な機器や侵害されている可能性のある機器の利用者への通知オペレーションにおける「誰が伝えるのか」という問題は過去のブログ[7]でもご紹介した次第です。 

他方で、2024年3月、総務省が進めるNOTICEにおいて、「ファームウェアに脆弱性があるIoT機器」の調査も新たに活動範囲に加えるとの発表[8]がなされました。調査した結果、実際にユーザーに通知がISP から実施されるに至るかどうかはケースバイケースと考えられますが、拡散気味になり、到達性の低い「注意喚起」だけでなく、こうした個別の通知といった対応オプションもこうしたボットネットを作らせないために必要です。

参考資料

[1] RSA Conference, "Hiding in Plain Sight: Hunting Volt Typhoon Cyber Actors"
  https://www.rsaconference.com/Library/presentation/usa/2024/hiding%20in%20plain%20sight%20hunting%20volt%20typhoon%20cyber%20actors

[2] Secureworks,"Chinese Cyberespionage Group BRONZE SILHOUETTE Targets U.S. Government and Defense Organizations"
  https://www.secureworks.com/blog/chinese-cyberespionage-group-bronze-silhouette-targets-us-government-and-defense-organizations

[3] 米司法省, "U.S. Government Disrupts Botnet People’s Republic of China Used to Conceal Hacking of Critical Infrastructure"
  https://www.justice.gov/opa/pr/us-government-disrupts-botnet-peoples-republic-china-used-conceal-hacking-critical

[4] Lumen, "Routers Roasting on an Open Firewall: the KV-botnet Investigation"
  https://blog.lumen.com/routers-roasting-on-an-open-firewall-the-kv-botnet-investigation/

[5] JPCERT/CC「高度サイバー攻撃への対処におけるログの活用と分析方法」
  https://www.jpcert.or.jp/research/apt-loganalysis.html

[6] JSAC2024 JPCERT/CC 佐々木勇人「ランサムウェア攻撃のアクター特定をすべきこれだけの理由」
  https://jsac.jpcert.or.jp/archive/2024/pdf/JSAC2024_2_6_hayato_sasaki_jp.pdf

[7] JPCERT/CC Eyes「なぜ、SSL-VPN製品の脆弱性は放置されるのか ～“サプライチェーン”攻撃という言葉の陰で見過ごされている攻撃原因について～」
  https://blogs.jpcert.or.jp/ja/2022/07/ssl-vpn.html

[8] 総務省「IoT機器のセキュリティ向上を推進する新しい「NOTICE」を開始」
  https://www.soumu.go.jp/menu_news/s-news/01cyber01_02000001_00200.html