Executive Summary

The September 2026 exploitation of Citrix NetScaler appliances drew attention to attackers deploying Platypus, an open-source remote-management framework, as a post-compromise agent. Citrix disclosed CVE-2026-88771, an unauthenticated command-execution vulnerability, and subsequent investigations documented the use of architecture-specific Platypus agents, enrollment tokens, certificates, and distribution infrastructure.

Building on these findings, Rubrik Zero Labs identified a separate collection of operator-oriented scripts referencing the same Platypus distribution infrastructure. Unlike conventional payload-delivery methods, these scripts attempt to exploit legitimate database and application-management capabilities to stage and execute Platypus across Windows and Linux environments.

The scripts contain hardcoded credentials, internal network addresses, and references to specific administrative services, suggesting that the threat actor had prior knowledge of the targeted environment. This activity is consistent with a post-compromise operation in which an attacker may have conducted reconnaissance and identified available services before attempting further payload deployment.

Our investigation identified two distinct attack workflows:

Oracle and Windows/Active Directory: A Bash controller uses SQL*Plus and Oracle UTL_FILE to stage a PowerShell bootstrap and Windows batch scripts. These scripts attempt to create a SYSTEM scheduled task on a Windows host, use SMB and WinRM to reach a domain controller, and download a Windows Platypus agent from entretiensol[.]com.

Redis and Asterisk-based Linux VoIP gateway: A collection of Python scripts attempts to abuse Redis configuration and replication functionality to stage shell scripts and a Linux ARM Platypus agent on an Asterisk-based gateway. The scripts then attempt to modify the Asterisk dialplan through its Asterisk Manager Interface (AMI) and trigger operating-system commands through SIP calls.

Although the initial compromise method remains unknown, the analyzed scripts reveal detailed attempts to stage and execute Platypus across Windows and Linux environments. Rubrik Zero Labs could not independently confirm successful payload deployment or execution. Nevertheless, these findings provide insight into how threat actors may abuse legitimate enterprise services for post-compromise activities.

Shared Platypus Infrastructure

The domain entretiensol[.]com, previously used to deliver Platypus payloads in attacks exploiting Citrix NetScaler vulnerability CVE-2026-88771, also appears in the scripts analyzed by Rubrik Zero Labs. These scripts reference the same domain to download Platypus agents for Windows and Linux systems.

Unlike the previously reported NetScaler attacks, the newly identified scripts attempt to deploy Platypus through database file-writing capabilities, remote Windows execution, and Redis and Asterisk services. While the shared infrastructure suggests a connection to previously reported activity, there is no evidence that these attacks exploited the same Citrix NetScaler vulnerability. 

Payload Staging Through Oracle UTL_FILE

Rubrik Zero Labs identified a Bash script named ora23.sh, hosted at hxxp://173.255.247[.]97:8001/ora23.sh. Designed to run on a Linux system, the script uses Oracle Instant Client's SQL*Plus utility and hardcoded credentials to attempt authentication to an Oracle database server over TCP port 31522.

The script then attempts to stage malicious PowerShell and batch-script payloads on the database server's filesystem using Oracle's UTL_FILE package and the RTWIN directory object. A reusable function converts each payload into a PL/SQL block containing UTL_FILE.PUT_LINE statements, which are submitted through SQL*Plus to write the files line by line.

By using this technique, the attacker attempts to place PowerShell and batch scripts on the target system through the database's legitimate file-writing functionality, without directly transferring the files over conventional file-sharing protocols. The script prepares four payloads, each serving a specific purpose in the subsequent Windows execution and lateral-movement workflow:

• rt23o.ps1 – PowerShell bootstrap that downloads and launches the Platypus agent on the targeted Windows host.
• rt17w.bat – Creates and triggers a Windows scheduled task named RTA23W to execute rt23s.bat with SYSTEM privileges.
• rt23s.bat – Uses SMB and WinRM to authenticate to the remote Windows host, copy rt23o.ps1, and execute it remotely using PowerShell.
• rt17r.bat – Retrieves execution logs generated by rt23s.bat to collect the results of the remote deployment attempts.

The targeting details are also noteworthy. The targeted Oracle database server is associated with a Ukrainian network, while additional artifacts suggest that the environment may be linked to a Ukrainian pharmaceutical company.

Base64-Encoded PowerShell Payload

As part of the payload-staging process, the Bash script contains a Base64-encoded PowerShell payload stored in the RT23OB64 variable. The script decodes this content into rt23o.ps1 and attempts to write it to the target filesystem using Oracle's UTL_FILE functionality.

Analysis of the decoded PowerShell script reveals that its purpose is to download and execute a Windows Platypus agent from entretiensol[.]com. To do this, the script first identifies the target system's architecture (AMD64, ARM64, or x86) and selects the corresponding agent from the /v1/artifacts/windows/<architecture>/latest endpoint. It then identifies a writable directory and saves the downloaded executable under a system-health-related filename, such as system-health.exe, health-monitor.exe etc., to resemble a legitimate system utility.

For the download, the script uses curl.exe, with Invoke-WebRequest as a fallback, and disables TLS certificate verification. Once downloaded, it attempts to launch the agent using the embedded Platypus enrollment token, configured management server, and data directory. If successful, this would establish a remote-management agent on the targeted Windows system, potentially allowing the attacker to execute commands and perform further post-compromise activities.

The ingress CA certificate used in this attack shares the same serial number (E401CB3138B193E7C236EC7DD8B239BA) as the certificate documented by Binary Defense in previously reported NetScaler-related Platypus activity. However, the project CA serial number and project identifier differ.

Scheduled Task Execution

The batch script rt17w.bat is designed to execute the staged rt23s.bat payload with SYSTEM privileges. It uses the Windows schtasks utility to create a scheduled task named RTA23W, configures it to run under the local SYSTEM account, and immediately triggers its execution.

Windows Lateral Movement and Remote Execution

Once launched, rt23s.bat attempts to establish remote access to the targeted domain controller using SMB and Windows Remote Management (WinRM). It modifies the local WinRM TrustedHosts configuration and uses hardcoded domain credentials to authenticate to the target's administrative shares.

The script then attempts to copy the previously staged PowerShell installer (rt23o.ps1) to the domain controller's C:\Windows\Temp directory. It uses winrs to test remote command execution by running system-identification commands before attempting to execute the installer with PowerShell's execution policy bypassed.

Upon execution, the PowerShell installer is designed to download and launch the Platypus agent on the domain controller.

Payload Staging and Execution Monitoring

The Bash script also contains a fourth Windows batch payload, rt17r.bat, designed to retrieve execution logs generated during the lateral-movement workflow.

The script's final section provides four operational options: files, fire, read, and spool. The files option stages all four Windows payloads through Oracle's UTL_FILE functionality, while fire and read query Oracle database objects named RT17T and RT17R, respectively. The spool option monitors a local output-collection process and checks for a Base64 completion marker.

Redis Payload Staging and Asterisk-Based Execution

Further investigation into 173.255.247[.]97, the IP address hosting the previously identified ora23.sh script, led to the discovery of several Python scripts targeting a Linux-based VoIP gateway.

The scripts reveal attempts to combine Redis database functionality, Asterisk's management interface, and SIP call processing to stage and execute malicious payloads, including the Platypus agent. The same IP address also appears as a rogue Redis replication endpoint, establishing an infrastructure connection between the Oracle and Redis attack workflows.

The scripts contain diagnostic markers, execution checks, repeated payload-staging attempts, and alternative dialplan configurations, suggesting that the threat actor was testing and refining different techniques to achieve payload execution on the targeted VoIP gateway.

Understanding Asterisk AMI and SIP

Asterisk is an open-source communications platform commonly used in VoIP gateways and telephone systems. It provides the Asterisk Manager Interface (AMI), which allows administrators and applications to remotely manage and monitor the system. Asterisk also supports the Session Initiation Protocol (SIP), which is used to establish and manage voice calls.

Asterisk uses a dialplan, a set of rules that determines how incoming calls are handled, including which actions to perform when a specific phone number or extension is dialed.

In this attack, the threat actor attempts to abuse these capabilities alongside Redis. The Python scripts use Redis configuration and replication commands to stage malicious payloads on the VoIP gateway. They then attempt to access Asterisk through AMI and modify its dialplan to include commands that execute malicious payloads.

By sending a crafted SIP INVITE request to a specific extension, the attacker attempts to trigger the modified dialplan and execute operating-system commands through Asterisk's System() functionality, ultimately launching the Platypus agent.

Initial Payload Staging Through Rogue Redis Replication

One of the identified Python scripts acts as an operator-side payload-staging tool, targeting a Redis service running on a Linux-based VoIP gateway over TCP port 6379. It attempts to abuse Redis's replication functionality to transfer malicious files onto the gateway's filesystem.

The script creates a TCP listener on port 16380 to impersonate a legitimate Redis replication server. It then modifies the victim's Redis persistence directory and filename using CONFIG SET commands before issuing a SLAVEOF command, which instructs a Redis server to replicate data from another server. In this case, it directs the victim's Redis server to 173.255.247[.]97:16380, the attacker-controlled replication endpoint.

The victim's Redis server then attempts to connect to the rogue server and request synchronization (SYNC). The rogue server responds with attacker-controlled payload data, which the attacker intends to write to the victim's filesystem using the modified Redis configuration.

The operator attempts to stage three files:

• rtorder.sh - Operator-supplied shell script loaded from /root/ovx_order.sh; its contents were not recovered
• rte_go.sh - Embedded shell payload containing Platypus agent execution instructions, server connection details, and sensitive system-information collection commands; staged for subsequent execution.
• System-health - Linux ARM executable intended to run as the Platypus agent, sourced from /root/ovx_agent_arm

The Python script embeds a shell launcher named rte_go.sh, which contains instructions to execute the Platypus agent using an installation token and connect to entretiensol[.]com:443. The script also downloads the Linux ARM Platypus agent from hxxps://entretiensol[.]com/v1/artifacts/linux/arm/latest and saves it locally as /root/ovx_agent_arm. It then attempts to stage the agent as /tmp/system-health, along with the embedded launcher as /tmp/rte_go.sh, on the victim's VoIP gateway through rogue Redis replication. When the staged rte_go.sh launcher is subsequently executed, it attempts to start the Platypus agent (/tmp/system-health) in the background and establish a connection to entretiensol[.]com:443.

The embedded rte_go.sh launcher also contains commands to collect Linux account information, password hashes, Asterisk management configuration, network-neighbor information, process listings, and system details. The collected information is intended to be Base64-encoded and stored under /etc/asterisk/gw/, while execution markers are written to rte_proof2.

At this stage, the Python script attempts to stage the payloads through Redis replication. The subsequent execution mechanism involving Asterisk AMI and SIP is discussed in the following section.

Attempted Payload Execution Through Asterisk AMI and SIP

Following the Redis-based payload staging attempts, another Python script reveals how the threat actor attempted to execute rte_go.sh by leveraging the Asterisk Manager Interface (AMI), running on the same Linux-based VoIP gateway that hosts the previously targeted Redis service.

The script attempts to authenticate to AMI over TCP port 5038, an interface that allows administrators to remotely manage and configure Asterisk. The attacker then attempts to modify the Asterisk dialplan, which controls how incoming calls are processed, to trigger execution of the staged payload.

Specifically, the script attempts to remove the existing entry for extension 889 in the nothingtodo dialplan context and replace it with six steps using Asterisk's System() application, which can execute operating-system commands. These steps include diagnostic commands, attempts to assign executable permissions to /tmp/rte_go.sh using chmod 755, and commands to execute the launcher. 

After modifying the dialplan, the script sends a crafted SIP INVITE request to extension 889 over UDP port 5060. By directing the call to the modified extension, the attacker attempts to trigger the System() commands and execute /tmp/rte_go.sh on the underlying Linux system, subsequently launching the Platypus agent (/tmp/system-health) in the background.

Conclusion

The analyzed scripts highlight how threat actors may abuse legitimate technologies, including Oracle, Redis, and Asterisk, to stage and execute malware across Windows and Linux environments. These techniques demonstrate how database functionality and administrative services can be misused to deploy the Platypus agent.

By leveraging trusted system capabilities, the threat actor may have attempted to blend malicious activity with legitimate operations and evade conventional security detections. These findings highlight the importance of monitoring suspicious activity within trusted services, not just malicious executables.

Indicators of Compromise (IOCs)

All identified indicators of compromise (IOCs) are available in the Rubrik Zero Labs (RZL) threat intelligence feed to support detection across Rubrik products.

File indicators 

Network indicators 

Yara Rule

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 Mapping