エグゼクティブサマリー
2026年9月に発生したCitrix NetScaler製品への攻撃では、攻撃者がオープンソースのリモート管理フレームワーク「Platypus」を、侵害後のエージェントとして展開していたことが注目を集めました。Citrixは、認証不要でコマンドを実行できる脆弱性CVE-2026-88771を公表しています。その後の調査では、アーキテクチャ別のPlatypusエージェント、登録トークン、証明書、配布インフラの使用が報告されました。
これらの知見を踏まえ、Rubrik Zero Labsは、同じPlatypus配布インフラを参照する、オペレーター向けスクリプト群を別途確認しました。従来のペイロード配布手法とは異なり、これらのスクリプトは、正規のデータベース機能やアプリケーション管理機能を悪用して、WindowsとLinuxの環境にPlatypusを配置・実行しようとします。
スクリプトには、ハードコードされた認証情報、内部ネットワークのアドレス、特定の管理サービスへの参照が含まれています。このことから、攻撃者は標的環境について事前に把握していた可能性があります。今回の活動は、攻撃者が偵察を行って利用可能なサービスを特定したうえで、さらなるペイロードの展開を試みた、侵害後の作戦と整合します。
調査の結果、2つの異なる攻撃ワークフローが判明しました。
OracleとWindows/Active Directory: Bashのコントローラーが、SQL*PlusとOracleのUTL_FILEを使ってPowerShellのブートストラップとWindowsのバッチスクリプトを配置します。これらのスクリプトは、Windowsホスト上でSYSTEM権限のスケジュールタスクを作成し、SMBとWinRMでドメインコントローラーに到達したうえで、entretiensol[.]comからWindows版Platypusエージェントをダウンロードしようとします。
RedisとAsteriskベースのLinux VoIPゲートウェイ:複数のPythonスクリプトが、Redisの設定機能とレプリケーション機能を悪用し、Asteriskベースのゲートウェイ上にシェルスクリプトとLinux ARM版Platypusエージェントを配置しようとします。続いて、Asterisk Manager Interface（AMI）経由でAsteriskのダイヤルプランを書き換え、SIPコールを通じてOSコマンドを実行させようとします。
最初の侵害手法は不明ですが、分析したスクリプトからは、WindowsとLinuxの環境にPlatypusを配置・実行しようとする詳細な試みが読み取れます。Rubrik Zero Labsは、ペイロードの展開や実行が成功したかどうかを独自に確認することはできませんでした。それでも今回の発見は、攻撃者が侵害後の活動で正規のエンタープライズサービスをどのように悪用しうるかを示しています。
ドメインentretiensol[.]comは、Citrix NetScalerの脆弱性CVE-2026-88771を突いた攻撃でPlatypusのペイロード配布に使われていたものです。Rubrik Zero Labsが分析したスクリプトにも、このドメインが登場します。これらのスクリプトは、WindowsおよびLinuxシステム向けのPlatypusエージェントをダウンロードするために、同じドメインを参照しています。
先に報告されたNetScalerへの攻撃とは異なり、今回新たに確認されたスクリプトは、データベースのファイル書き込み機能、リモートからのWindows実行、そしてRedisとAsteriskのサービスを使ってPlatypusを展開しようとします。インフラが共通していることから、以前報告された活動との関連がうかがえますが、今回の攻撃が同じCitrix NetScalerの脆弱性を悪用したことを示す証拠はありません。
Oracle UTL_FILEによるペイロードの配置
Rubrik Zero Labsは、hxxp://173.255.247[.]97:8001/ora23.shでホストされていたora23.shという名前のBashスクリプトを確認しました。このスクリプトはLinuxシステム上で動作するよう設計されており、Oracle Instant ClientのSQL*Plusユーティリティとハードコードされた認証情報を使って、TCPポート31522経由でOracleデータベースサーバーへの認証を試みます。
続いてスクリプトは、OracleのUTL_FILEパッケージとRTWINディレクトリオブジェクトを使って、悪意あるPowerShellスクリプトとバッチスクリプトのペイロードをデータベースサーバーのファイルシステム上に配置しようとします。再利用可能な関数が各ペイロードをUTL_FILE.PUT_LINE文を含むPL/SQLブロックに変換し、SQL*Plus経由で送信することで、ファイルを1行ずつ書き込みます。
この手法により、攻撃者は従来のファイル共有プロトコルでファイルを直接転送することなく、データベースの正規のファイル書き込み機能を通じて、PowerShellスクリプトとバッチスクリプトを標的システムに置こうとします。スクリプトは4つのペイロードを用意しており、それぞれがその後のWindows上での実行とラテラルムーブメントのワークフローで固有の役割を担います。
- rt23o.ps1 – 標的のWindowsホスト上でPlatypusエージェントをダウンロードして起動する、PowerShellのブートストラップ
- rt17w.bat – RTA23Wという名前のWindowsスケジュールタスクを作成・起動し、SYSTEM権限でrt23s.batを実行
- rt23s.bat – SMBとWinRMでリモートのWindowsホストに認証し、rt23o.ps1をコピーしてPowerShellでリモート実行
- rt17r.bat – rt23s.batが生成した実行ログを取得し、リモート展開の試行結果を収集
標的に関する詳細も注目に値します。標的となったOracleデータベースサーバーはウクライナのネットワークに関連しており、ほかの痕跡からは、この環境がウクライナの製薬会社と関係している可能性が示唆されます。
Base64エンコードされたPowerShellペイロード
ペイロード配置の一環として、BashスクリプトにはRT23OB64変数に格納されたBase64エンコード済みのPowerShellペイロードが含まれています。スクリプトはこの内容をrt23o.ps1にデコードし、OracleのUTL_FILE機能を使って標的のファイルシステムへの書き込みを試みます。
デコードしたPowerShellスクリプトを分析したところ、その目的は、entretiensol[.]comからWindows版Platypusエージェントをダウンロードして実行することだと判明しました。スクリプトはまず、標的システムのアーキテクチャ（AMD64、ARM64、x86）を判別し、/v1/artifacts/windows/<architecture>/latestエンドポイントから対応するエージェントを選択します。次に書き込み可能なディレクトリを特定し、ダウンロードした実行ファイルを、system-health.exeやhealth-monitor.exeなど、システムの健全性に関連するファイル名で保存します。正規のシステムユーティリティに見せかけるためです。
ダウンロードにはcurl.exeを使用し、失敗した場合はInvoke-WebRequestにフォールバックします。その際、TLS証明書の検証は無効化されます。ダウンロード後は、埋め込まれたPlatypusの登録トークン、設定済みの管理サーバー、データディレクトリを指定してエージェントの起動を試みます。成功すれば、標的のWindowsシステム上にリモート管理エージェントが確立され、攻撃者がコマンドを実行したり、侵害後のさらなる活動を行ったりできる可能性があります。
この攻撃で使われたインバウンド用CA証明書は、NetScalerに関連する過去のPlatypus活動でBinary Defenseが報告した証明書と、シリアル番号（E401CB3138B193E7C236EC7DD8B239BA）が一致します。ただし、プロジェクトCAのシリアル番号とプロジェクト識別子は異なります。
スケジュールタスクによる実行
バッチスクリプトrt17w.batは、配置済みのrt23s.batペイロードをSYSTEM権限で実行するよう設計されています。Windowsのschtasksユーティリティを使ってRTA23Wというスケジュールタスクを作成し、ローカルのSYSTEMアカウントで実行するよう設定したうえで、即座に起動します。
Windowsでのラテラルムーブメントとリモート実行
rt23s.batは起動されると、SMBとWindowsリモート管理（WinRM）を使って、標的のドメインコントローラーへのリモートアクセスを確立しようとします。ローカルのWinRM TrustedHosts設定を書き換え、ハードコードされたドメイン認証情報で標的の管理共有に認証します。
続いてスクリプトは、先に配置したPowerShellインストーラー（rt23o.ps1）をドメインコントローラーのC:\Windows\Tempディレクトリにコピーしようとします。winrsを使ってシステム識別コマンドを実行し、リモートでのコマンド実行をテストしたうえで、PowerShellの実行ポリシーをバイパスしてインストーラーの実行を試みます。
実行されると、PowerShellインストーラーはドメインコントローラー上でPlatypusエージェントをダウンロードして起動するよう設計されています。
ペイロードの配置と実行の監視
Bashスクリプトには、4つ目のWindowsバッチペイロードであるrt17r.batも含まれています。ラテラルムーブメントの過程で生成された実行ログを取得するためのものです。
スクリプト末尾のセクションには、files、fire、read、spoolの4つの操作オプションがあります。filesはOracleのUTL_FILE機能を通じて4つのWindowsペイロードをすべて配置します。fireとreadは、それぞれRT17TとRT17Rという名前のOracleデータベースオブジェクトを照会します。spoolはローカルの出力収集プロセスを監視し、Base64形式の完了マーカーを確認します。
Redisによるペイロード配置とAsteriskを使った実行
先に確認したora23.shスクリプトをホストしていたIPアドレス173.255.247[.]97をさらに調査したところ、Linuxベースを標的とするVoIPゲートウェイ向けの複数のPythonスクリプトが見つかりました。
これらのスクリプトからは、Redisのデータベース機能、Asteriskの管理インターフェース、SIPコール処理を組み合わせて、Platypusエージェントを含む悪意あるペイロードを配置・実行しようとする試みがうかがえます。同じIPアドレスは、不正なRedisレプリケーションのエンドポイントとしても登場しており、OracleとRedisの攻撃ワークフローがインフラ面でつながっていることを示しています。
スクリプトには、診断用のマーカー、実行チェック、繰り返されるペイロード配置の試行、代替のダイヤルプラン設定が含まれています。攻撃者が標的のVoIPゲートウェイでペイロードを実行するため、さまざまな手法を試し、改良していたことがうかがえます。
Asterisk AMIとSIPの概要
Asteriskは、VoIPゲートウェイや電話システムで広く使われているオープンソースの通信プラットフォームです。管理者やアプリケーションがシステムをリモートで管理・監視できるAsterisk Manager Interface（AMI）を備えています。また、音声通話の確立と管理に使われるSession Initiation Protocol（SIP）にも対応しています。
Asteriskはダイヤルプランを使います。これは、着信をどう処理するかを決めるルールの集合で、特定の電話番号や内線番号にダイヤルされたときに実行する動作も定義します。
この攻撃で、攻撃者はRedisとともにこれらの機能を悪用しようとします。Pythonスクリプトは、Redisの設定コマンドとレプリケーションコマンドを使って、VoIPゲートウェイに悪意あるペイロードを配置します。その後、AMI経由でAsteriskにアクセスし、悪意あるペイロードを実行するコマンドを含むようダイヤルプランを書き換えようとします。
攻撃者は、特定の内線番号に細工したSIP INVITEリクエストを送信することで、書き換えたダイヤルプランを起動させ、AsteriskのSystem()機能を通じてOSコマンドを実行し、最終的にPlatypusエージェントを起動しようとします。
不正なRedisレプリケーションによる初期ペイロードの配置
確認されたPythonスクリプトの1つは、オペレーター側のペイロード配置ツールとして機能し、LinuxベースのVoIPゲートウェイ上でTCPポート6379で動作するRedisサービスを標的にします。Redisのレプリケーション機能を悪用して、悪意あるファイルをゲートウェイのファイルシステムに転送しようとします。
スクリプトはポート16380でTCPリスナーを作成し、正規のRedisレプリケーションサーバーになりすまします。次に、CONFIG SETコマンドで被害者のRedisの永続化ディレクトリとファイル名を変更したうえで、別のサーバーからデータを複製するようRedisサーバーに指示するSLAVEOFコマンドを発行します。ここでは、被害者のRedisサーバーを、攻撃者が管理するレプリケーションのエンドポイントである173.255.247[.]97:16380に向けます。
被害者のRedisサーバーは、この不正なサーバーに接続して同期（SYNC）を要求します。不正なサーバーは攻撃者が制御するペイロードデータを返します。攻撃者は、変更したRedisの設定を利用して、このデータを被害者のファイルシステムに書き込ませる狙いです。
オペレーターは、次の3つのファイルの配置を試みます。
- rtorder.sh – /root/ovx_order.shから読み込まれる、オペレーター提供のシェルスクリプト。内容は回収できず
- rte_go.sh – Platypusエージェントの実行手順、サーバーへの接続情報、機微なシステム情報の収集コマンドを含む組み込み型のシェルペイロード。後続の実行に備えて配置
- System-health – Platypusエージェントとして動作させる意図のLinux ARM実行ファイル。/root/ovx_agent_armから取得
このPythonスクリプトにはrte_go.shというシェルランチャーが埋め込まれており、インストールトークンを使ってPlatypusエージェントを実行し、entretiensol[.]com:443に接続する命令が含まれています。スクリプトはまた、hxxps://entretiensol[.]com/v1/artifacts/linux/arm/latestからLinux ARM版Platypusエージェントをダウンロードし、/root/ovx_agent_armとしてローカルに保存します。そのうえで、不正なRedisレプリケーションを通じて、エージェントを/tmp/system-healthとして、埋め込まれたランチャーを/tmp/rte_go.shとして、被害者のVoIPゲートウェイに配置しようとします。配置されたrte_go.shランチャーが後に実行されると、Platypusエージェント（/tmp/system-health）をバックグラウンドで起動し、entretiensol[.]com:443への接続を確立しようとします。
埋め込まれたrte_go.shランチャーには、Linuxのアカウント情報、パスワードハッシュ、Asteriskの管理設定、ネットワーク近隣情報、プロセス一覧、システムの詳細を収集するコマンドも含まれています。収集した情報はBase64エンコードして/etc/asterisk/gw/配下に保存する想定で、実行マーカーはrte_proof2に書き込まれます。
この段階でPythonスクリプトは、Redisレプリケーションを通じたペイロードの配置を試みます。Asterisk AMIとSIPを使った後続の実行メカニズムについては、次のセクションで説明します。
Asterisk AMIとSIPによるペイロード実行の試み
Redisを使ったペイロード配置の試みに続き、別のPythonスクリプトが、攻撃者がAsterisk Manager Interface（AMI）を利用してrte_go.shの実行を試みた手口を明らかにしています。AMIは、先に標的となったRedisサービスをホストしているのと同じLinuxベースのVoIPゲートウェイで動作しています。
スクリプトは、管理者がAsteriskをリモートで管理・設定するためのインターフェースであるTCPポート5038経由で、AMIへの認証を試みます。続いて攻撃者は、着信の処理方法を制御するAsteriskのダイヤルプランを書き換え、配置済みのペイロードを実行させようとします。
具体的には、スクリプトはnothingtodoダイヤルプランコンテキストにある内線889の既存エントリを削除し、OSコマンドを実行できるAsteriskのSystem()アプリケーションを使った6つのステップに置き換えようとします。これらのステップには、診断コマンド、chmod 755で/tmp/rte_go.shに実行権限を付与する試み、そしてランチャーを実行するコマンドが含まれます。
ダイヤルプランを書き換えた後、スクリプトはUDPポート5060経由で内線889に細工したSIP INVITEリクエストを送信します。書き換えた内線に通話を向けることで、攻撃者はSystem()コマンドを起動し、基盤となるLinuxシステム上で/tmp/rte_go.shを実行して、続いてPlatypusエージェント（/tmp/system-health）をバックグラウンドで起動しようとします。
まとめ
分析したスクリプトは、攻撃者がOracle、Redis、Asteriskといった正規の技術を悪用して、WindowsとLinuxの環境にマルウェアを配置・実行しうることを示しています。こうした手法は、データベース機能や管理サービスが、Platypusエージェントの展開に悪用されうることを物語っています。
攻撃者は、信頼されたシステム機能を利用することで、悪意ある活動を正規の運用に紛れ込ませ、従来のセキュリティ検知を回避しようとした可能性があります。今回の発見は、悪意ある実行ファイルだけでなく、信頼されたサービス内の不審な活動も監視することの重要性を浮き彫りにしています。
侵害指標（IOC）
特定された侵害指標（IOC）はすべて、Rubrik製品全体での検知を支援するため、Rubrik Zero Labs（RZL）の脅威インテリジェンスフィードで提供されています。
ファイルの指標
Yaraルール
rule RBRK_Platypus_Redis_Asterisk_Operator_Scripts
{
meta:
description = "Detects Platypus-associated Redis/Asterisk operator and reconnaissance scripts"
author = "Rubrik Zero Labs"
category = "Operator scripts"
date = "2026-10-15"
strings:
// Redis replication behavior
$redis_repl = "SLAVEOF" ascii
$redis_file = "dbfilename" ascii
$redis_sync = "SYNC" ascii
$redis_socket = "socket.socket" ascii
$redis_port = "16380" ascii
// More distinctive staging/target artifacts
$redis_art1 = "rogue_sync_to(" ascii
$redis_art2 = "rte_go.sh" ascii
$redis_art3 = "ovx_agent_arm" ascii
$redis_art4 = "/etc/asterisk" ascii
$redis_art5 = "rte_proof" ascii
// Asterisk AMI and SIP execution attempts
$ami_action = "Action: Command" ascii
$ami_dialplan = "dialplan" ascii
$sip_invite = "INVITE sip:" ascii
$sip_context = "nothingtodo" ascii
// Related Linux reconnaissance
$probe_endpoint = "bpr26_probe" ascii
$probe_result = "bpr26_out" ascii
$probe_key = "/tmp/rtkey" ascii
condition:
filesize < 128KB and
(
(
$redis_repl and $redis_file and $redis_sync and
$redis_socket and $redis_port and
1 of ($redis_art*)
)
or
(
$ami_action and $ami_dialplan and
$sip_invite and $sip_context
)
or
(
$probe_endpoint and $probe_result and $probe_key
)
)
}
MITRE ATT&CK マッピング
翻訳元: https://zerolabs.rubrik.com/blog/databases-dialplans-uncovering-platypus-deployment-attempts
