$ cat writeup.md…
$ cat writeup.md…
alfactf
Task: SSH access lands on a jumphost where the only remaining production path is an active admin SSH session. Solution: race the short-lived forwarded SSH agent socket, proxy it into a new SSH connection to tracker-prod, and read the admin flag.
$ cat /etc/rate-limit
Rate limit reached (20 reads/hour per IP). Showing preview only — full content returns at the next hour roll-over.
Original organizer text was not preserved in the workspace; only the access details and story summary remained.
We received SSH access to quitting-rexo4dac.alfactf.ru as user quitting with the hint that only one production session was still alive and access had to be restored.
The critical idea was to reuse the forwarded SSH agent from that surviving admin session before cleanup removed the SSH_AUTH_SOCK path.
Logging into the provided host did not place us into a normal low-privileged shell. Instead, it dropped us into a jumphost shell as root, which immediately changed the problem from privilege escalation to session and process inspection.
Recon on the jumphost showed an already-running SSH chain for the admin user:
sshd: admin [priv] sshd: admin@pts/1 sh -c sleep 1 && rm -rf /tmp/ssh* & ssh -l admin tracker-prod bash ssh -l admin tracker-prod bash
This revealed three important facts:
admin -> tracker-prod SSH login.sleep 1 && rm -rf /tmp/ssh* & ....Reliable PTY hijacking was possible in theory, but in practice it was messy and timing-sensitive. The forwarded agent was a much cleaner target: if we could find the agent socket quickly enough and reuse it, we could authenticate to tracker-prod as admin without extracting any private key.
The transient socket appeared briefly in /proc/net/unix as /tmp/ssh-XXXX/agent.N. A probe script confirmed that it was a real SSH agent and that it exposed exactly one identity with comment admin@adminlaptop.
...
$ grep --similar