XDR系製品には、何かしら異常が確認された端末に対してリモートで任意のコマンドが実行できるようなライブレスポンスと言われる類の機能がある。
CrowdStrike FalconのReal Time Response、SentinelOneのFull Remote Shell、 Microsoft Defender for Endpoint - Live Responseなどなど。
PaloAlto CortexならLive Terminal。
docs-cortex.paloaltonetworks.com
今回は、Cortex Live Terminalを悪用できる手法が見つかった。
いやでも待て待て、そりゃあCortex XDRの管理画面にログインしたら悪用できるっしょ？っと思うだろうが。今回はそういうことではない。
Cortex XDRインストールされた端末側で管理者権限が取れたら、Cortex XDR Live Terminalのシェルを任意のサーバに送信できるという話。
「Cortex XDRリバースシェル」とでも呼ぼうか。
labs.infoguard.ch
Live Terminalの接続先を変える
そもそも、Live Terminalってどうやって使うのか。
正規のLive Terminalセッションは、おそらく以下のように確立される。
[SOCアナリストや管理者] → Cortex XDRクラウドコンソール → WebSocket指示
↓
ターゲット端末上の cyserver.exe（Cortexエージェント）
↓ 起動
cortex-xdr-payload.exe
↓ WebSocket接続（TLS 443）
lrc-ch.paloaltonetworks.com（リージョナルエンドポイント）
↓
SOCアナリストがGUI上でコマンド実行
ここで注目したいのは、cortex-xdr-payload.exe。
こいつが、以下のように実行されて管理サーバに接続しにいくことで、管理画面でコマンド実行指示が可能となる。
cortex-xdr-payload.exe -port 443 -server <管理サーバ> -token <任意>
じゃあ、cortex-xdr-payload.exeが接続する先(<管理サーバ>)を付け替えたらどうなる？
デコンパイルできた
Info Guardの研究者は、調査中にcortex-xdr-payload.exeがPyInstallerで作成されていることに気が付いた。
そのため、pyinstxtractor-ng、PyLingualと段階的に使用することでデコンパイルに成功したようだ。
コマンド署名無
Burp Suiteで取得したコマンド実行時の記録をみると、普通にコマンドが流れていたらしい。
あれ？ 署名とか特に無いんだなぁ。
C2サーバとして、好きなところに使えられる可能性。
この時点で、攻撃者がPaloAlto Cortexの任意の別のテナントを持っていたら、接続先を好きな他の会社のCortex Web管理画面に付け替えられることになる。
ドメインチェックの不備
cortex-xdr-payload.exeからデコンパイルされたスクリプトには、接続先のサーバホストのチェック機構がある。
def run_lrc_payload(lrc_payload_config, logger): lrc_exit_code = (-1) if not lrc_payload_config.server.endswith('.paloaltonetworks.com'): logger.error(f'Server address {lrc_payload_config.server} is invalid') return lrc_exit_code
そりゃ、そうだよね。.paloaltonetworks.comで終わるサーバにアクセスするってくらいチェック機能ないと他のサーバに付け替えられたらヤバイよね。
あらら？ でも、何かおかしくないか。
この検証はホスト名ではなく、指定されたURL文字列全体に対してendswith() を実行している。ならば、attacker.com/test.paloaltonetworks.comのようなパスを含むURLが検証を通過してしまうのではないか。
つまり、これが受け入れられました。
一応防御機構？
Cortex XDRには想定されていないプロセスから、cortex-xdr-payload.exeが起動された場合にブロックするルールがあるらしい。
つまり、cmd.exeとかからcortex-xdr-payload.exeを実行しても実行がブロックされるということ。
しかし、研究者は回避方法があったと主張している。詳細は公開されていない。
うーん。普通にプロセスインジェクション系かなぁ。
cyserver.exeのハンドルがあれば、cyserver.exeを親プロセスとしてcortex-xdr-payload.exeを実行できるだろうし。そんなところでしょう。
ステルス性がお高め
この攻撃のメリットはステルス性。
cortex-xdr-payload.exeはCortex XDRベンダー署名済みバイナリ。cortex-xdr-payload.exeがある程度変なコマンド実行しても検知されないだろう。もしかして、Cobalt StrikeのBeaconやSliverのImplantを落としても、それ自体がEDRの検知されにくかったりする？
通信先がPalo Altoのクラウドインフラ（もしくはそう見える宛先）へのTLS 443なのも強いかもしれない。EDRベンダーの通信はTLSインスペクションから除外されているだろうし。ネットワーク監視で見ても、他の正規テナントを使っていれば「Cortex XDRの正規通信」に見えない。攻撃者自前サーバなら、話は別かもしれないが。
cortex-xdr-payload.exeがコマンド実行、PowerShell、Python、ファイルエクスプローラ、プロセスエクスプローラを全部内蔵している。既製品をそのまま使うだけとも言える。
ということで、EDRの正規バイナリをその正規機能のまま接続先だけ変えて攻撃者のC2として転用できると。
他のEDRとかどうだ
先に挙げた通り、他のXDR製品にもCortex Live Terminalに似たような機能がある。
これらも似たような状況になっていたらヤバいね。でも、簡単に調べた限りではそういった事例は無さそうだ。
ただし、これらの機能は管理画面を一度侵害してしまえば、とんでもないことになるのは誰でも分かる。レッドチーム演習で楽しく使ったと主張している人が居るようであるし。
資産管理ソフトも似たようなのありそうな気が
こういったリモートアクセス機能って、世にいう資産管理ソフトにもありそうだと思った。
これらもクライアント側でC2として利用されたりするような事例があったりするんだろうか。
管理サーバ側が乗っ取られる脆弱性(CVE-2016-7836),CVE-2025-61932)はあったが、クライアントのリモートアクセスに特化したものは無いかぁ？
まぁ、管理サーバが乗っ取られる脆弱性がある方がヤバいが。
変な話だが、EDR製品はセキュリティベンダーが開発していてセキュリティに対する意識や投資が相対的に高い。
一方、資産管理ソフトはIT運用管理を目的として設計されていて、エージェント・管理機間の通信プロトコルの堅牢性がセキュリティ製品ほど重視されていないってこともあったりしないだろうか。
そういう観点だと、資産管理ソフトって大丈夫かなってちょっと心配になる。
EDRとしてだけじゃなくて、他にも機能を統合して欲しいと言われたときの反応
EDR初導入を推奨して製品を紹介していたときの話。
私 「異常があったときには、対象端末でコマンド実行もできます。」
お客様 「じゃあ、EDRってリモート操作でPC管理ができるってことですね。」
私 「そういう側面もあります。(うーーん。まぁ、そうじゃない感だけど、とりあえず良いか。)」
お客様 「でも、GUIとかでも管理できた方が良いから、コマンドだけだと導入しなくていいかなぁ。」
私 「(・o・) (・o・) (・o・) (・o・) (・o・)」
