Redtail Payload Analysis [Guest Diary], (Wed, Sep 9th)
SANS guest analyst detonated a RedTail Linux sample from a DShield honeypot, finding process masquerading as php-fpm, monitoring-kill behavior, and a TCP listener.
A DShield honeypot captured multi-architecture RedTail Linux executables (ARM, ARM64, i686, RISC-V, x86-64) deployed via shell scripts. Dynamic analysis of the UPX-packed, statically linked x86-64 sample (SHA-256 63be5f38...d35e) in an isolated Ubuntu 24.04 VM on Proxmox showed it renamed its process via prctl(PR_SET_NAME), killed a filesystem-monitoring process, and opened a TCP listening socket while surviving processes posed as php-fpm or PostgreSQL-like workers. Differential memory images pre- and post-execution were captured from the hypervisor for forensics.
- RedTail ships multi-architecture ELF payloads selected by a deployment script
- Malware masquerades as php-fpm workers using prctl(PR_SET_NAME)
- Forensic check of /proc/PID/exe distinguishes impostor processes
- Sample killed filesystem-monitoring processes and opened TCP sockets
- Analysis combined INetSim, auditd, strace, tcpdump, and hypervisor memory dumps
- Vendors
- SANS
- Malware
- RedTail
- Organizations
- SANS Internet Storm Center
Indicators of compromise
auto-extracted · verify before use · export allAll| Type | Indicator | Context |
|---|---|---|
| domain | ip-109-091-184-021.um37.pools.vodafone-ip.de | utsche Telekom AG (AS3320), while 109.91.184.21 resolved to ip-109-091-184-021.um37.pools.vodafone-ip.de and belonged to a Vodafone GmbH static B2B customer pool (A |
| domain | mail3.kekew.info | erse-DNS information showed that 80.152.203.134 resolved to mail3.kekew.info and was allocated to Deutsche Telekom AG (AS3320), while 10 |
| ipv4 | 1.0.0.1 | ct() calls on TCP port 853 . Destinations included 1.1.1.1, 1.0.0.1, 8.8.8.8, 8.8.4.4, 9.9.9.9, 9.9.9.10, and several additiona |
| ipv4 | 109.91.184.21 | resolver infrastructure. Two addresses, 80.152.203.134 and 109.91.184.21 , did not clearly correspond to known public resolver servi |
| ipv4 | 1.1.1.1 | nal connect() calls on TCP port 853 . Destinations included 1.1.1.1, 1.0.0.1, 8.8.8.8, 8.8.4.4, 9.9.9.9, 9.9.9.10, and several |
| ipv4 | 80.152.203.134 | ons were public DNS resolver infrastructure. Two addresses, 80.152.203.134 and 109.91.184.21 , did not clearly correspond to known pub |
| ipv4 | 8.8.4.4 | port 853 . Destinations included 1.1.1.1, 1.0.0.1, 8.8.8.8, 8.8.4.4, 9.9.9.9, 9.9.9.10, and several additional addresses. TCP/8 |
| ipv4 | 8.8.8.8 | erified while attempts to reach an external address such as 8.8.8.8 returned Network is unreachable. This design allowed the ma |
| ipv4 | 9.9.9.10 | tions included 1.1.1.1, 1.0.0.1, 8.8.8.8, 8.8.4.4, 9.9.9.9, 9.9.9.10, and several additional addresses. TCP/853 is commonly asso |
| ipv4 | 9.9.9.9 | . Destinations included 1.1.1.1, 1.0.0.1, 8.8.8.8, 8.8.4.4, 9.9.9.9, 9.9.9.10, and several additional addresses. TCP/853 is com |
| sha256 | 63be5f38b520b3143732962a5f8fec1f9abd1f483dbc741ed324e58f955dd35e | le analyzed in this article has the following SHA-256 hash: 63be5f38b520b3143732962a5f8fec1f9abd1f483dbc741ed324e58f955dd35e Dynamic analysis showed that the payload did considerably m |
From the original article
12 min read at isc.sans.edu
[This is a Guest Diary by Aaron Ng, an ISC intern as part of the SANS. edu BACS program]
isc.sans.edu
A short excerpt; the article and its images belong to the publisher. Summary, key facts and assessment above are AI-written from the article and can be wrong.