While hunting suspicious infrastructure on
@Huntio, I came across 176.65.139[.]158 exposing a /bins/ directory with Linux payloads for ARM, MIPS, x86, PPC, SH4 and several other architectures.
I collected the exposed binaries and started reversing the x86_64 and MIPS builds. The samples are consistent with a Mirai-derived codebase and contain an embedded RedKill identifier.
The x86_64 bot creates an AF_INET/SOCK_DGRAM socket, connects it to 8.8.8.8:53/UDP, and then uses getsockname() to determine the host's local IPv4 address.
It subsequently establishes a TCP connection to the hard-coded C2:
176.65.139[.]158:6722/TCP
The initial 12-byte client message sent after the connection is established is:
00 00 00 01 07 52 65 64 4b 69 6c 6c
The final seven bytes decode to RedKill.
The C2 parser accepts attack commands and forks separate worker processes. Reversing the attack dispatcher exposed several DDoS capabilities, including UDP flooding with randomized payload data, raw TCP flooding, GRE flooding with a TEB (0x6558) mode, and a TCP socket-hold/connection-flood routine.
The exposed dbg binary provided additional context. It is a ~1 MB statically linked x86_64 build containing verbose strings such as socket_hold_attack, a default 1000 connection limit, mirai, RedKill, the same C2 address and 8.8.8.8.
The currently hosted MIPS payload also has a different SHA256 from an earlier public Mirai sample I compared against. I treat it as a separate build; the hash difference alone is not enough to establish a payload-rotation cadence.