RESEARCHERS analysing a RedTail Linux payload observed the attacker uploading a package containing architecture-specific executables for ARM, ARM64, i686, RISC-V and x86-64, delivered with shell scripts to deploy and clean up. The x86-64 sample analysed (SHA-256: 63be5f38b520b3143732962a5f8fec1f9abd1f483dbc741ed324e58f955dd35e) was statically linked and appears to have been packed with UPX.
In a controlled environment on Ubuntu 24.04, the malware was run inside an isolated Proxmox VM with no Internet access, while a simulated network service (INetSim) and various monitoring tools captured its behaviour. The deployment relied on architecture detection to select the appropriate RedTail binary, and a hidden staging location, with a focus on persistence and evasion rather than immediate external reach.
Dynamic analysis revealed a consistent sequence across runs: host profiling and resource discovery via /proc and /sys, followed by process masquerading, persistence via an @reboot cron entry (root-level in Run 002; victor58 user in Run 001), and the creation of a high-numbered TCP listener on an unpredictable port (examples observed: 39539, 40219, 39983). RedTail attempted to modify the firewall with iptables to permit traffic to its listener, though full rule application could not always be verified.
A surviving process appeared as php-fpm: pool www while its executable remained redtail.x86_64, demonstrating deliberate process-name masquerading. Network activity included outbound attempts to TLS-over-DNS destinations on TCP port 853, though the isolated environment prevented successful exchanges; some destinations correlated to public DNS infrastructure, while a couple appeared anomalous.
RedTail also interfered with analysis by terminating inotifywait, strace, and other monitoring processes, with root privileges enabling more effective disruption. Overall, RedTail combines host profiling, persistence, masquerading, network initialisation, and defensive evasion across both non‑root and root contexts.