Let's say, there is a situation in which firewall rules, such as below, only allows SSH communication from machine 10.0.0.101 and drops all other requests. Specifically, it allows 1 connection at a time from this device. Therefore multiple users should not be able to access the SSH service at one time from 10.0.0.101.
securitynik@ssh-server~$ sudo iptables --table filter --append INPUT --ipv4 --source 10.0.0.101/32 --protocol tcp --dport 22 --match comment --comment "Allow SSH only from 10.0.0.101" --match connlimit --connlimit-upto 1 --jump LOG --log-level info --log-prefix "** EXPECTED SSH REQUEST **" --log-tcp-sequence --log-tcp-options --log-uid securitynik@ssh-server~$ sudo iptables --table filter --append INPUT --ipv4 --source 10.0.0.101/32 --protocol tcp --dport 22 --match comment --comment "Allow SSH only from 10.0.0.101" --match connlimit --connlimit-upto 1 --jump ACCEPT securitynik@ssh-server~$ sudo iptables --table filter --append INPUT --ipv4 --protocol tcp --dport 22 --match comment --comment "DROP ALL SSH SESSIONS NOT COMING FROM 10.0.0.101" --jump LOG --log-level info --log-prefix "** SUSPICIOUS SSH REQUEST**" --log-tcp-sequence --log-tcp-options --log-uid securitynik@ssh-server~$ sudo iptables --table filter --append INPUT --ipv4 --protocol tcp --dport 22 --match comment --comment "DROP ALL SSH SESSIONS NOT COMING FROM 10.0.0.101" --jump DROP
The reason there may be rules like these, is because many organization leverages what is called a "jump box", making it the only device authorized to access the SSH (or some other) service.
Looking at the IPTables INPUT Chain to verify the configuration.
securitynik@ssh-server~$ sudo iptables --list INPUT --verbose --numeric --table filter Chain INPUT (policy ACCEPT 6 packets, 1032 bytes) pkts bytes target prot opt in out source destination 0 0 LOG tcp -- * * 10.0.0.101 0.0.0.0/0 tcp dpt:22 /* Allow SSH only from 10.0.0.101 */ #conn src/32 <= 1 LOG flags 11 level 6 prefix "** EXPECTED SSH REQUEST **" 0 0 ACCEPT tcp -- * * 10.0.0.101 0.0.0.0/0 tcp dpt:22 /* Allow SSH only from 10.0.0.101 */ #conn src/32 <= 1 0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 /* DROP ALL SSH SESSIONS NOT COMING FROM 10.0.0.101 */ LOG flags 11 level 6 prefix "** SUSPICIOUS SSH REQUEST**" 0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 /* DROP ALL SSH SESSIONS NOT COMING FROM 10.0.0.101 */
Running tcpdump on the SSH server machine.
securitynik@ssh-server~$ sudo tcpdump -nnt --interface eth0 port 22
Trying to connect from a device at 10.0.0.108. This should fail, as the only IP address authorize to access this service is at 10.0.0.101.
C:\Users\SecurityNik>ipconfig Windows IP Configuration Ethernet adapter Ethernet: Connection-specific DNS Suffix . : Link-local IPv6 Address . . . . . : fe80::a049:348c:1e6b:6497%9 IPv4 Address. . . . . . . . . . . : 10.0.0.108 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : C:\Users\SecurityNik>ssh sec560@10.0.0.107 ssh: connect to host 10.0.0.107 port 22: Connection timed out
After waiting a few minutes, this request timed out and no SSH access was gained. Looking at the tcpdump output, we see the client sends a SYN but no SYN/ACK was received (sent by the server) by the client. No SYN/ACK implies the service did not answer. This could be the as a result of multiple reasons. However, we know the firewall is configured to drop this traffic.
securitynik@ssh-server~$ sudo tcpdump -nnt --interface eth0 port 22 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes IP 10.0.0.108.2250 > 10.0.0.107.22: Flags [S], seq 2959767667, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 IP 10.0.0.108.2250 > 10.0.0.107.22: Flags [S], seq 2959767667, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 IP 10.0.0.108.2250 > 10.0.0.107.22: Flags [S], seq 2959767667, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 IP 10.0.0.108.2250 > 10.0.0.107.22: Flags [S], seq 2959767667, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 IP 10.0.0.108.2250 > 10.0.0.107.22: Flags [S], seq 2959767667, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
Looking at the IPTables we see 5 packets were dropped and logged.
securitynik@ssh-server~$ sudo iptables --list INPUT --verbose --numeric --table filter Chain INPUT (policy ACCEPT 48 packets, 8025 bytes) pkts bytes target prot opt in out source destination 0 0 LOG tcp -- * * 10.0.0.101 0.0.0.0/0 tcp dpt:22 /* Allow SSH only from 10.0.0.101 */ #conn src/32 <= 1 LOG flags 11 level 6 prefix "** EXPECTED SSH REQUEST **" 0 0 ACCEPT tcp -- * * 10.0.0.101 0.0.0.0/0 tcp dpt:22 /* Allow SSH only from 10.0.0.101 */ #conn src/32 <= 1 5 260 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 /* DROP ALL SSH SESSIONS NOT COMING FROM 10.0.0.101 */ LOG flags 11 level 6 prefix "** SUSPICIOUS SSH REQUEST**" 5 260 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 /* DROP ALL SSH SESSIONS NOT COMING FROM 10.0.0.101 */
This can be further confirmed by looking at the kern.log file.
securitynik@ssh-server~$ sudo tail --follow /var/log/kern.log --lines 0 Sep 19 16:13:32 ssh-server kernel: [14203.074341] ** SUSPICIOUS SSH REQUEST**IN=eth0 OUT= MAC=00:0c:29:cb:60:fd:08:00:27:ec:69:d7:08:00 SRC=10.0.0.108 DST=10.0.0.107 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=1104 DF PROTO=TCP SPT=2250 DPT=22 SEQ=2959767667 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B40103030801010402) Sep 19 16:13:33 ssh-server kernel: [14204.076874] ** SUSPICIOUS SSH REQUEST**IN=eth0 OUT= MAC=00:0c:29:cb:60:fd:08:00:27:ec:69:d7:08:00 SRC=10.0.0.108 DST=10.0.0.107 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=1105 DF PROTO=TCP SPT=2250 DPT=22 SEQ=2959767667 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B40103030801010402) Sep 19 16:13:35 ssh-server kernel: [14206.077432] ** SUSPICIOUS SSH REQUEST**IN=eth0 OUT= MAC=00:0c:29:cb:60:fd:08:00:27:ec:69:d7:08:00 SRC=10.0.0.108 DST=10.0.0.107 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=1106 DF PROTO=TCP SPT=2250 DPT=22 SEQ=2959767667 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B40103030801010402) Sep 19 16:13:39 ssh-server kernel: [14210.093057] ** SUSPICIOUS SSH REQUEST**IN=eth0 OUT= MAC=00:0c:29:cb:60:fd:08:00:27:ec:69:d7:08:00 SRC=10.0.0.108 DST=10.0.0.107 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=1107 DF PROTO=TCP SPT=2250 DPT=22 SEQ=2959767667 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B40103030801010402) Sep 19 16:13:47 ssh-server kernel: [14218.108854] ** SUSPICIOUS SSH REQUEST**IN=eth0 OUT= MAC=00:0c:29:cb:60:fd:08:00:27:ec:69:d7:08:00 SRC=10.0.0.108 DST=10.0.0.107 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=1108 DF PROTO=TCP SPT=2250 DPT=22 SEQ=2959767667 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B40103030801010402)
We have now confirmed, the host at 10.0.0.108 is unable to connect to the SSH service on 10.0.0.107. Remember, the only device having access to 10.0.0.107 is 10.0.0.101 (the jumpbox). Since this is known, leveraging ncat on 10.0.0.101 to then proxy the traffic from 10.0.0.108 to 10.0.0.101 then forward to 10.0.0.107.
10.0.0.108:any -> 10.0.0.101:9999 -> 10.0.0.101:any -> 10.0.0.107:22
To achieve this relay, we leverage a named pipe (a FIFO file)
┌──(rootđź’€securitynik)-[/tmp] └─# mkfifo ssh.relay ┌──(rootđź’€securitynik)-[/tmp] └─# file ssh.relay ssh.relay: fifo (named pipe)
This file will now be used as part of our relay mechanism
┌──(rootđź’€securitynik)-[/tmp] └─# ncat --listen 10.0.0.101 9999 --verbose 0<ssh.relay | ncat --verbose 10.0.0.107 22 1>ssh.relay Ncat: Version 7.91 ( https://nmap.org/ncat ) Ncat: Version 7.91 ( https://nmap.org/ncat ) Ncat: Listening on 10.0.0.101:9999 Ncat: Connected to 10.0.0.107:22.
We can see above a successful connection to 10.0.0.107:22 while 10.0.0.101:9999 is listening for incoming connections. Confirming on 10.0.0.107, that there was indeed an expected SSH connection coming from 10.0.0.101.
securitynik@ssh-server~$ sudo tail --follow /var/log/kern.log --lines 0 Sep 19 16:39:24 ssh-server kernel: [15755.345756] ** EXPECTED SSH REQUEST **IN=eth0 OUT= MAC=00:0c:29:cb:60:fd:08:00:27:0e:34:8d:08:00 SRC=10.0.0.101 DST=10.0.0.107 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=56787 DF PROTO=TCP SPT=57934 DPT=22 SEQ=1204929296 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B40402080AC65B221C0000000001030307) Sep 19 16:39:24 ssh-server kernel: [15755.346076] ** EXPECTED SSH REQUEST **IN=eth0 OUT= MAC=00:0c:29:cb:60:fd:08:00:27:0e:34:8d:08:00 SRC=10.0.0.101 DST=10.0.0.107 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=56788 DF PROTO=TCP SPT=57934 DPT=22 SEQ=1204929297 ACK=970219203 WINDOW=502 RES=0x00 ACK URGP=0 OPT (0101080AC65B221D9D2FFA76) Sep 19 16:39:24 ssh-server kernel: [15755.354408] ** EXPECTED SSH REQUEST **IN=eth0 OUT= MAC=00:0c:29:cb:60:fd:08:00:27:0e:34:8d:08:00 SRC=10.0.0.101 DST=10.0.0.107 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=56789 DF PROTO=TCP SPT=57934 DPT=22 SEQ=1204929297 ACK=970219244 WINDOW=502 RES=0x00 ACK URGP=0 OPT (0101080AC65B22259D2FFA7E) UID=0 GID=0
Time now to go back to 10.0.0.108 and attempt the SSH connection. This time, using the same username, we now point to 10.0.0.101 and rather than the default port 22, we now use port 9999 by specifying the "-p 9999"
C:\Users\SecurityNik>ssh sec560@10.0.0.101 -p 9999 sec560@10.0.0.101's password: System information as of Sun Sep 19 16:40:18 UTC 2021 System load: 0.0 Usage of /: 32.6% of 61.80GB Memory usage: 36% Swap usage: 0% Processes: 152 Users logged in: 1 IP address for eth0: 10.0.0.107 IP address for eth1: 192.168.253.155 0 updates can be applied immediately. Last login: Sat Sep 18 18:48:42 2021 from 10.0.0.101 securitynik@ssh-server~$
Good stuff! Now we have access to the device at 10.0.0.107 via 10.0.0.101. This can be further confirmed by looking at ncat again.
┌──(rootđź’€securitynik)-[/tmp] └─# ncat --listen 10.0.0.101 9999 --verbose 0<ssh.relay | ncat --verbose 10.0.0.107 22 1>ssh.relay Ncat: Ncat: Version 7.91 ( https://nmap.org/ncat ) Ncat: Listening on 10.0.0.101:9999 Version 7.91 ( https://nmap.org/ncat ) Ncat: Connected to 10.0.0.107:22. Ncat: Connection from 10.0.0.108. Ncat: Connection from 10.0.0.108:2333.
Above, there is now a connection from 10.0.0.108 on port 2333. This is the connection which is then proxied to the SSH server.
Further confirming the above by looking at the iptables log, everything is being reported as "EXPECTED SSH REQUEST"
Sep 19 16:40:08 ssh-server kernel: [15798.927298] ** EXPECTED SSH REQUEST **IN=eth0 OUT= MAC=00:0c:29:cb:60:fd:08:00:27:0e:34:8d:08:00 SRC=10.0.0.101 DST=10.0.0.107 LEN=85 TOS=0x00 PREC=0x00 TTL=64 ID=56790 DF PROTO=TCP SPT=57934 DPT=22 SEQ=1204929297 ACK=970219244 WINDOW=502 RES=0x00 ACK PSH URGP=0 OPT (0101080AC65BCC449D2FFA7E) UID=0 GID=0 Sep 19 16:40:08 ssh-server kernel: [15798.928757] ** EXPECTED SSH REQUEST **IN=eth0 OUT= MAC=00:0c:29:cb:60:fd:08:00:27:0e:34:8d:08:00 SRC=10.0.0.101 DST=10.0.0.107 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=56791 DF PROTO=TCP SPT=57934 DPT=22 SEQ=1204929330 ACK=970220324 WINDOW=501 RES=0x00 ACK URGP=0 OPT (0101080AC65BCC469D30A4B5) UID=0 GID=0 Sep 19 16:40:08 ssh-server kernel: [15798.931232] ** EXPECTED SSH REQUEST **IN=eth0 OUT= MAC=00:0c:29:cb:60:fd:08:00:27:0e:34:8d:08:00 SRC=10.0.0.101 DST=10.0.0.107 LEN=1372 TOS=0x00 PREC=0x00 TTL=64 ID=56792 DF PROTO=TCP SPT=57934 DPT=22 SEQ=1204929330 ACK=970220324 WINDOW=501 RES=0x00 ACK PSH URGP=0 OPT (0101080AC65BCC489D30A4B5) UID=0 GID=0 Sep 19 16:40:08 ssh-serve kernel: [15798.973768] ** EXPECTED SSH REQUEST **IN=eth0 OUT= MAC=00:0c:29:cb:60:fd:08:00:27:0e:34:8d:08:00 SRC=10.0.0.101 DST=10.0.0.107 LEN=100 TOS=0x00 PREC=0x00 TTL=64 ID=56793 DF PROTO=TCP SPT=57934 DPT=22 SEQ=1204930650 ACK=970220324 WINDOW=501 RES=0x00 ACK PSH URGP=0 OPT (0101080AC65BCC739D30A4E2) UID=0 GID=0
When we close down the SSH connection on 10.0.0.108, it also tears down the relay in this instance.
┌──(rootđź’€securitynik)-[/tmp] └─# ncat --listen 10.0.0.101 9999 --verbose 0<ssh.relay | ncat --verbose 10.0.0.107 22 1>ssh.relay Ncat: Ncat: Version 7.91 ( https://nmap.org/ncat ) Ncat: Listening on 10.0.0.101:9999 Version 7.91 ( https://nmap.org/ncat ) Ncat: Connected to 10.0.0.107:22. Ncat: Connection from 10.0.0.108. Ncat: Connection from 10.0.0.108:2333. Ncat: 2305 bytes sent, 3869 bytes received in 391.40 seconds.
From the involved hosts perspective we see the following on the device at 10.0.0.108 ...
C:\Users\SecurityNik>netstat -anop tcp | findstr /R ":9999 :22" TCP 10.0.0.108:2333 10.0.0.101:9999 ESTABLISHED 32
The following from the relay / proxy device at 10.0.0.101 ...
┌──(rootđź’€securitynik)-[/tmp] └─# ss --numeric --tcp --processes --oneline | grep --perl-regexp ':22|:9999' ESTAB 0 0 10.0.0.101:57934 10.0.0.107:22 users:(("ncat",pid=23375,fd=3)) ESTAB 0 0 10.0.0.101:9999 10.0.0.108:2333 users:(("ncat",pid=23374,fd=4))
... and the following from the SSH server at 10.0.0.107.
securitynik@ssh-server~$ ss --numeric --tcp --processes | grep --perl-regexp ':22|:9999' ESTAB 0 0 10.0.0.107:22 10.0.0.101:57934
With all of the above, if we looked at the full packet capture, what can we learn.
On the relay, the following was used to capture the traffic
┌──(rootđź’€securitynik)-[/tmp] └─# tcpdump -nv --interface any 'tcp port (9999 or 22)' -w ssh-relay.pcap --print ┌──(rootđź’€securitynik)-[/tmp] └─# tshark -n -r ssh-relay.pcap | more 1 0.000000 10.0.0.101 → 10.0.0.107 TCP 80 57934 → 22 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3327861276 TSecr=0 WS=128 2 0.000759 10.0.0.107 → 10.0.0.101 TCP 80 22 → 57934 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM=1 TSval= 2637167222 TSecr=3327861276 WS=128 3 0.000778 10.0.0.101 → 10.0.0.107 TCP 72 57934 → 22 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=3327861277 TSecr=263716722 2 4 0.008706 10.0.0.107 → 10.0.0.101 SSH 113 Server: Protocol (SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3) 5 0.008728 10.0.0.101 → 10.0.0.107 TCP 72 57934 → 22 [ACK] Seq=1 Ack=42 Win=64256 Len=0 TSval=3327861285 TSecr=26371672 30
Packets 1 to 3 shows the allowed host at 10.0.0.101 sets up a successful connection to port 22 on host 10.0.0.107. In packet 4, the SSH server sends its protocol information. At this point and during a normal connection, the SSH client would send its protocol information. This is not the case. Instead in packet 5, there is simply an acknowledgement from 10.0.0.101 to 10.0.0.107 acknowledging the packet.
If you notice above, the source port 57934, is the same source port being reported in the IPtables log on the 10.0.0.107.
Looking at the next 6 packets, we now see connection from 10.0.0.108 on source port 2333 to 10.0.0.101 port 9999. This is once again, reflective of what was seen via ncat output.
6 43.557506 10.0.0.108 → 10.0.0.101 TCP 72 2333 → 9999 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1 7 43.557539 10.0.0.101 → 10.0.0.108 TCP 72 9999 → 2333 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460 SACK_PERM=1 WS=12 8 8 43.557997 10.0.0.108 → 10.0.0.101 TCP 66 2333 → 9999 [ACK] Seq=1 Ack=1 Win=2102272 Len=0 9 43.558174 10.0.0.101 → 10.0.0.108 TCP 101 9999 → 2333 [PSH, ACK] Seq=1 Ack=1 Win=64256 Len=41 10 43.559876 10.0.0.108 → 10.0.0.101 TCP 93 2333 → 9999 [PSH, ACK] Seq=1 Ack=42 Win=2102272 Len=33 11 43.559887 10.0.0.101 → 10.0.0.108 TCP 60 9999 → 2333 [ACK] Seq=42 Ack=34 Win=64256 Len=0
Packets 12-15, shows the SSH client protocol is now being sent (packet 12) between 10.0.0.101 and 10.0.0.107. The SSH server then responds in packet 14, with its Key Exchange Init message.
12 43.560036 10.0.0.101 → 10.0.0.107 SSH 105 Client: Protocol (SSH-2.0-OpenSSH_for_Windows_7.7) 13 43.560486 10.0.0.107 → 10.0.0.101 TCP 72 22 → 57934 [ACK] Seq=42 Ack=34 Win=65280 Len=0 TSval=2637210804 TSecr=3327904 836 14 43.561582 10.0.0.107 → 10.0.0.101 SSHv2 1152 Server: Key Exchange Init 15 43.561600 10.0.0.101 → 10.0.0.107 TCP 72 57934 → 22 [ACK] Seq=34 Ack=1122 Win=64128 Len=0 TSval=3327904838 TSecr=26372 10805
Packets 16-18 shows the the "SSHv2 1152 Server: Key Exchange Init"-, being relayed back to 10.0.0.108 and .108 responding with 1320 bytes.
16 43.561789 10.0.0.101 → 10.0.0.108 TCP 1140 9999 → 2333 [PSH, ACK] Seq=42 Ack=34 Win=64256 Len=1080 17 43.563811 10.0.0.108 → 10.0.0.101 TCP 1380 2333 → 9999 [PSH, ACK] Seq=34 Ack=1122 Win=2101248 Len=1320 18 43.563837 10.0.0.101 → 10.0.0.108 TCP 60 9999 → 2333 [ACK] Seq=1122 Ack=1354 Win=64128 Len=0
Those bytes more than likely contains the "Client: Key Exchange Init" which is being relayed back to the SSH server.
19 43.563947 10.0.0.101 → 10.0.0.107 SSHv2 1392 Client: Key Exchange Init
Considering above, we see some additional setup steps showing the back and forth between 10.0.0.108 and 10.0.0.101 & 10.0.0101 and 10.0.0.107
20 43.565523 10.0.0.108 → 10.0.0.101 TCP 108 2333 → 9999 [PSH, ACK] Seq=1354 Ack=1122 Win=2101248 Len=48 21 43.565531 10.0.0.101 → 10.0.0.108 TCP 60 9999 → 2333 [ACK] Seq=1122 Ack=1402 Win=64128 Len=0 22 43.606554 10.0.0.107 → 10.0.0.101 TCP 72 22 → 57934 [ACK] Seq=1122 Ack=1354 Win=64128 Len=0 TSval=2637210850 TSecr=332 7904840 23 43.606582 10.0.0.101 → 10.0.0.107 SSHv2 120 Client: Elliptic Curve Diffie-Hellman Key Exchange Init 24 43.606932 10.0.0.107 → 10.0.0.101 TCP 72 22 → 57934 [ACK] Seq=1122 Ack=1402 Win=64128 Len=0 TSval=2637210850 TSecr=332 7904883 25 43.610970 10.0.0.107 → 10.0.0.101 SSHv2 524 Server: Elliptic Curve Diffie-Hellman Key Exchange Reply, New Keys, Encryp ted packet (len=172) 26 43.610990 10.0.0.101 → 10.0.0.107 TCP 72 57934 → 22 [ACK] Seq=1402 Ack=1574 Win=64128 Len=0 TSval=3327904887 TSecr=263 7210854 27 43.611101 10.0.0.101 → 10.0.0.108 TCP 512 9999 → 2333 [PSH, ACK] Seq=1122 Ack=1402 Win=64128 Len=452 28 43.616465 10.0.0.108 → 10.0.0.101 TCP 76 2333 → 9999 [PSH, ACK] Seq=1402 Ack=1574 Win=2102272 Len=16 29 43.616495 10.0.0.101 → 10.0.0.108 TCP 60 9999 → 2333 [ACK] Seq=1574 Ack=1418 Win=64128 Len=0 30 43.616620 10.0.0.101 → 10.0.0.107 SSHv2 88 Client: New Keys 31 43.616674 10.0.0.108 → 10.0.0.101 TCP 104 2333 → 9999 [PSH, ACK] Seq=1418 Ack=1574 Win=2102272 Len=44 32 43.616678 10.0.0.101 → 10.0.0.108 TCP 60 9999 → 2333 [ACK] Seq=1574 Ack=1462 Win=64128 Len=0 33 43.658992 10.0.0.107 → 10.0.0.101 TCP 72 22 → 57934 [ACK] Seq=1574 Ack=1418 Win=64128 Len=0 TSval=2637210902 TSecr=332 7904893
Looking at the communication from the encrypted packets perspective, we see the proxy / relay device at 10.0.0.101 relaying communication to 10.0.0.107 in SSH.
34 43.659047 10.0.0.101 → 10.0.0.107 SSHv2 116 Client: Encrypted packet (len=44) 35 43.659911 10.0.0.107 → 10.0.0.101 TCP 72 22 → 57934 [ACK] Seq=1574 Ack=1462 Win=64128 Len=0 TSval=2637210903 TSecr=332 7904935 36 43.660391 10.0.0.107 → 10.0.0.101 SSHv2 116 Server: Encrypted packet (len=44) 37 43.660430 10.0.0.101 → 10.0.0.107 TCP 72 57934 → 22 [ACK] Seq=1462 Ack=1618 Win=64128 Len=0 TSval=3327904937 TSecr=263 7210903
Then the communication between 10.0.0.101 and 10.0.0.108 does not contain the SSH application layer data.
38 43.660734 10.0.0.101 → 10.0.0.108 TCP 104 9999 → 2333 [PSH, ACK] Seq=1574 Ack=1462 Win=64128 Len=44 39 43.661632 10.0.0.108 → 10.0.0.101 TCP 128 2333 → 9999 [PSH, ACK] Seq=1462 Ack=1618 Win=2102272 Len=68 40 43.661670 10.0.0.101 → 10.0.0.108 TCP 60 9999 → 2333 [ACK] Seq=1618 Ack=1530 Win=64128 Len=0
Following the above pattern, we see in packet 123, the relay (10.0.0.101) sends a packet to 10.0.0.108 but a RST ACK was sent instead in packet 124 from the device at 10.0.0.108 . Seems like 10.0.0.108 is no longer interested in using the relay. If we look deeper, below the connection is being torn down with the FIN flag.
122 391.383881 10.0.0.108 → 10.0.0.101 TCP 120 2333 → 9999 [PSH, ACK] Seq=2246 Ack=3870 Win=2101760 Len=60 123 391.383902 10.0.0.101 → 10.0.0.108 TCP 60 9999 → 2333 [ACK] Seq=3870 Ack=2306 Win=64128 Len=0 124 391.385121 10.0.0.108 → 10.0.0.101 TCP 66 2333 → 9999 [RST, ACK] Seq=2306 Ack=3870 Win=0 Len=0 125 391.385580 10.0.0.101 → 10.0.0.107 SSHv2 132 Client: Encrypted packet (len=60) 126 391.386072 10.0.0.107 → 10.0.0.101 TCP 72 22 → 57934 [ACK] Seq=3870 Ack=2307 Win=64128 Len=0 TSval=2637558803 TSecr=332 8252660 127 391.391308 10.0.0.107 → 10.0.0.101 TCP 72 22 → 57934 [FIN, ACK] Seq=3870 Ack=2307 Win=64128 Len=0 TSval=2637558808 TSec r=3328252660 128 391.391339 10.0.0.101 → 10.0.0.107 TCP 72 57934 → 22 [ACK] Seq=2307 Ack=3871 Win=64128 Len=0 TSval=3328252668 TSecr=263 7558808
If we pay close attention above, we would see most of the communication between 10.0.0.108 and 10.0.0.101 is using raw TCP. You can see this below after the TCP 3-way handshake has been completed.
┌──(rootđź’€securitynik)-[/tmp] └─# tshark -n -r ssh-relay.pcap -Y '(tcp.port == 9999) and (tcp.port == 2333)' | more 6 43.557506 10.0.0.108 → 10.0.0.101 TCP 72 2333 → 9999 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1 7 43.557539 10.0.0.101 → 10.0.0.108 TCP 72 9999 → 2333 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460 SACK_PERM=1 WS=128 8 8 43.557997 10.0.0.108 → 10.0.0.101 TCP 66 2333 → 9999 [ACK] Seq=1 Ack=1 Win=2102272 Len=0 9 43.558174 10.0.0.101 → 10.0.0.108 TCP 101 9999 → 2333 [PSH, ACK] Seq=1 Ack=1 Win=64256 Len=41 10 43.559876 10.0.0.108 → 10.0.0.101 TCP 93 2333 → 9999 [PSH, ACK] Seq=1 Ack=42 Win=2102272 Len=33
When the above is compared with the SSH communication between 10.0.0.101 and 10.0.0.107 we see the actual SSH communication.
┌──(rootđź’€securitynik)-[/tmp] └─# tshark -n -r ssh-relay.pcap -Y '(tcp.port == 57934) and (tcp.port == 22)' | more 1 0.000000 10.0.0.101 → 10.0.0.107 TCP 80 57934 → 22 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3327861276 TSecr=0 WS=128 2 0.000759 10.0.0.107 → 10.0.0.101 TCP 80 22 → 57934 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM=1 TSval= 2637167222 TSecr=3327861276 WS=128 3 0.000778 10.0.0.101 → 10.0.0.107 TCP 72 57934 → 22 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=3327861277 TSecr=263716722 2 4 0.008706 10.0.0.107 → 10.0.0.101 SSH 113 Server: Protocol (SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3) 5 0.008728 10.0.0.101 → 10.0.0.107 TCP 72 57934 → 22 [ACK] Seq=1 Ack=42 Win=64256 Len=0 TSval=3327861285 TSecr=26371672 30 12 43.560036 10.0.0.101 → 10.0.0.107 SSH 105 Client: Protocol (SSH-2.0-OpenSSH_for_Windows_7.7) 13 43.560486 10.0.0.107 → 10.0.0.101 TCP 72 22 → 57934 [ACK] Seq=42 Ack=34 Win=65280 Len=0 TSval=2637210804 TSecr=3327904 836
Looking at the protocol hierarchy, we see
┌──(rootđź’€securitynik)-[/tmp] └─# tshark -n -r ssh-relay.pcap -q -z io,phs ================================================================== Protocol Hierarchy Statistics Filter: sll frames:128 bytes:20944 ip frames:128 bytes:20944 tcp frames:128 bytes:20944 ssh frames:36 bytes:8766 vssmonitoring frames:12 bytes:792 data frames:36 bytes:8334 ===================================================================
Above confirms there is TCP data as well as TCP SSH traffic in this pcap file.
Looking at the TCP conversations, we see the traffic in terms of bytes, etc., are not that far off. More importantly, we see that the connection between 10.0.0.101 and 10.0.0.108 started about 43 second after the first. Looking at the duration of this activity, we can also see that the activity has basically the same duration, minus the 43+ seconds.
┌──(rootđź’€securitynik)-[/tmp] └─# tshark -n -r ssh-relay.pcap -q -z conv,tcp ================================================================================ TCP Conversations Filter:<No Filter> | <- | | -> | | Total | Relative | Duration | | Frames Bytes | | Frames Bytes | | Frames Bytes | Start | | 10.0.0.101:57934 <-> 10.0.0.107:22 28 5,893bytes 39 5,121bytes 67 11kB 0.000000000 391.3913 10.0.0.101:9999 <-> 10.0.0.108:2333 31 4,249bytes 30 5,681bytes 61 9,930bytes 43.557506000 347.8276 ================================================================================
Let's now further confirm the the communication occurring on between ports 9999 and 2333 by looking directly into the packets.
┌──(rootđź’€securitynik)-[/tmp] └─# tshark -n -r ssh-relay.pcap -q -z follow,tcp,ascii,10.0.0.101:9999,10.0.0.108:2333 | more =================================================================== Follow: tcp,ascii Filter: ((ip.src eq 10.0.0.101 and tcp.srcport eq 9999) and (ip.dst eq 10.0.0.108 and tcp.dstport eq 2333)) or ((ip.src eq 10.0.0.108 and tcp.srcport eq 2333) and (ip.dst eq 10.0.0.101 and tcp.dstport eq 9999)) Node 0: 10.0.0.108:2333 Node 1: 10.0.0.101:9999 41 SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 33 SSH-2.0-OpenSSH_for_Windows_7.7
Above shows SSH is the protocol being used within this communication.
As I'm on this topic, time to kill a few birds with one stone. Note, no birds were harmed during the making of that statement ;-)
Living off the land instead of using ncat.
Whereas in the above example my device had one interface, I've now added a second interface and am attempting to use the built in IPTables firewall to forward traffic to a third host. Basically making this host act like a router.
┌──(rootđź’€securitynik)-[~] └─# ip address show eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 08:00:27:0e:34:8d brd ff:ff:ff:ff:ff:ff inet 10.0.0.108/24 brd 10.0.0.255 scope global dynamic eth0 valid_lft 367sec preferred_lft 367sec inet6 fe80::a00:27ff:fe0e:348d/64 scope link valid_lft forever preferred_lft forever ┌──(rootđź’€securitynik)-[~] └─# ip address show eth1 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 08:00:27:d0:8c:32 brd ff:ff:ff:ff:ff:ff inet 192.168.0.111/24 brd 192.168.0.255 scope global dynamic noprefixroute eth1 valid_lft 86164sec preferred_lft 86164sec inet6 fe80::a00:27ff:fed0:8c32/64 scope link noprefixroute valid_lft forever preferred_lft forever
Next up, verify IP forwarding is disable and then enable it by echoing 1 into the ip_forward file.
┌──(rootđź’€securitynik)-[~] └─# cat /proc/sys/net/ipv4/ip_forward 0 └─# echo 1 > /proc/sys/net/ipv4/ip_forward └─# cat /proc/sys/net/ipv4/ip_forward 1
Flush the nat and filter tables within IPTables, removing any remnants of previous configurations.
┌──(rootđź’€securitynik)-[~] └─# iptables --flush --table nat ┌──(rootđź’€securitynik)-[~] └─# iptables --flush --table filter
Configure IPTables for PREROUTING, changing the destination IP address of the packet once it comes in on IP address 192.168.0.111, destination port 22 and forwarding it to the host at 10.0.0.101 on port 22.
Do note, whereas in the above example with port 9999, I had setup a Ncat listener, in this example, there is nothing listening on port 22 on the relay device as shown below.
┌──(rootđź’€securitynik)-[~] └─# ss --numeric --listening --tcp --processes State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
Configuring the IPTables to first log the packets and route.
┌──(rootđź’€securitynik)-[~] └─# iptables --table nat --append PREROUTING --protocol TCP --in-interface eth1 --destination 192.168.0.111 --destination-port 22 --jump LOG ┌──(rootđź’€securitynik)-[~] └─# iptables --table nat --append PREROUTING --protocol TCP --in-interface eth1 --destination 192.168.0.111 --destination-port 22 --jump DNAT --to-destination 10.0.0.101:22
Reviewing the NAT table and the PREROUTING chain.
┌──(rootđź’€securitynik)-[~] └─# iptables --list --numeric --verbose --table nat Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 LOG tcp -- eth1 * 0.0.0.0/0 192.168.0.111 tcp dpt:22 LOG flags 0 level 4 0 0 DNAT tcp -- eth1 * 0.0.0.0/0 192.168.0.111 tcp dpt:22 to:10.0.0.101:22
With the configuration in place, time to now connect from a device on the 192.168.0.0/24 network and have the proxy forward this traffic to the SSH Server at 10.0.0.101.
192.168.0.0/24:any -> 192.168.0.111:22 -> 10.0.0.108 -> 10.0.0.101:22
I changed the IP address of the windows virtual machine to be on the same network as the proxy / pivot device's eth1.
C:\Users\SecurityNik>ipconfig Windows IP Configuration Ethernet adapter Ethernet: Connection-specific DNS Suffix . : securitynik.local Link-local IPv6 Address . . . . . : fe80::a049:348c:1e6b:6497%9 IPv4 Address. . . . . . . . . . . : 192.168.0.108 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . :
When I attempt to connect to SSH, here is what I see.
C:\Users\SecurityNik>ssh sans@192.168.0.111 ssh: connect to host 192.168.0.111 port 22: Connection timed out
The connection timing out does not make sense. As I look at the proxy's tcpdump ...
┌──(rootđź’€securitynik)-[~] └─# tcpdump -n --interface any tcp port 22 -c 4 listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes 15:04:48.456962 eth1 In IP 192.168.0.108.1871 > 192.168.0.111.22: Flags [S], seq 719757654, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 15:04:48.457036 eth0 Out IP 192.168.0.108.1871 > 10.0.0.101.22: Flags [S], seq 719757654, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 15:04:49.466180 eth1 In IP 192.168.0.108.1871 > 192.168.0.111.22: Flags [S], seq 719757654, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 15:04:49.466216 eth0 Out IP 192.168.0.108.1871 > 10.0.0.101.22: Flags [S], seq 719757654, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
... and the IPTables log
┌──(rootđź’€securitynik)-[~] └─# tail --follow /var/log/kern.log --lines 0 Oct 1 15:04:48 securitynik kernel: [ 6284.654528] IN=eth1 OUT= MAC=08:00:27:d0:8c:32:08:00:27:ec:69:d7:08:00 SRC=192.168.0.108 DST=192.168.0.111 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=53607 DF PROTO=TCP SPT=1871 DPT=22 WINDOW=64240 RES=0x00 SYN URGP=0
The above tells me the connection attempt was received. However, I do not get a SYN/ACK and my SSH connection timed out.
Looking at the remote hosts via tcpdump, I see ...
sans@sec503:~$ sudo tcpdump -nnt --interface any port 22 listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes IP 192.168.0.108.1871 > 10.0.0.101.22: Flags [S], seq 719757654, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 IP 192.168.0.108.1871 > 10.0.0.101.22: Flags [S], seq 719757654, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 IP 192.168.0.108.1871 > 10.0.0.101.22: Flags [S], seq 719757654, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 IP 192.168.0.108.1871 > 10.0.0.101.22: Flags [S], seq 719757654, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
Interesting, the SSH request is making it to the remote server but the server is not responding with a SYN/ACK. At the same time, it did not respond with a RST, which suggests to me the service is available but this server does not know how to get back to 192.168.0.108.
First verifying the service is actually available.
sans@sec503:~$ sudo ss --numeric --listening --tcp --processes State Recv-Q Send-Q Local Address:Port Peer Address:Port Process LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1074,fd=3)) LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=1074,fd=4))
Now that we confirm the service is listening, time to see if there is a route back to 192.168.0.108.
sans@sec503:~$ ip route 10.0.0.0/24 dev ens38 proto kernel scope link src 10.0.0.101 metric 101
No route currently to 192.168.0.108. Let's create a route so that this device at 10.0.0.101 gets to 192.168.0.108 via 10.0.0.108.
sans@sec503:~$ sudo ip route add 192.168.0.108/32 via 10.0.0.108 sans@sec503:~$ ip route 10.0.0.0/24 dev ens38 proto kernel scope link src 10.0.0.101 metric 101 192.168.0.108 via 10.0.0.108 dev ens38
Attempting the SSH again
C:\Users\SecurityNik>ssh sans@192.168.0.111 The authenticity of host '192.168.0.111 (192.168.0.111)' can't be established. ECDSA key fingerprint is SHA256:mZEyw9GoOoSoQyczxXzCFpCkLBj4WpsOEOlQg5ltdGY. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.0.111' (ECDSA) to the list of known hosts. sans@192.168.0.111's password: Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.4.0-88-generic x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/advantage 89 updates can be applied immediately. To see these additional updates run: apt list --upgradable Last login: Fri Oct 1 17:01:52 2021 from 10.0.0.108 sans@sec503:~$
Voila! That's it, we've route traffic through a middle box to the SSH server.
Using SSH port forwarding
For this example, I'm transitioning back to a device with one interface, with that interface being eth0. Primary reason being, I would like to operate similar to how a device would on the normal LAN. Even though many laptops may have both Wireless and Ethernet interfaces, it is quite possible, it is only connected to one of these at a time. So in this example, all the devices are on the same LAN.
┌──(rootđź’€securitynik)-[~] └─# ip address show eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 08:00:27:0e:34:8d brd ff:ff:ff:ff:ff:ff inet 10.0.0.109/24 brd 10.0.0.255 scope global dynamic eth0 valid_lft 532sec preferred_lft 532sec inet 10.0.0.108/24 brd 10.0.0.255 scope global secondary dynamic eth0 valid_lft 499sec preferred_lft 499sec inet6 fe80::a00:27ff:fe0e:348d/64 scope link valid_lft forever preferred_lft forever
On the compromised machine, first ensure that SSH service is listening ...
┌──(rootđź’€securitynik)-[~] └─# ss --numeric --listening --tcp State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
... it is not! Next check to see if the service is available.
└─# systemctl status ssh.service ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; disabled; vendor preset: disabled) Active: inactive (dead) Docs: man:sshd(8) man:sshd_config(5)
It is available but not running. Starting the SSH service and verifying that it is listening.
┌──(rootđź’€securitynik)-[~] └─# systemctl start ssh.service ┌──(rootđź’€securitynik)-[~] └─# systemctl status ssh.service ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; disabled; vendor preset: disabled) Active: active (running) since Sat 2021-10-02 07:08:33 EDT; 1s ago Docs: man:sshd(8) man:sshd_config(5) Process: 2212 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS) Main PID: 2213 (sshd) Tasks: 1 (limit: 2293) ... ┌──(rootđź’€securitynik)-[~] └─# ss --numeric --listening --tcp State Recv-Q Send-Q Local Address:Port Peer Address:Port Process LISTEN 0 128 0.0.0.0:22 0.0.0.0:* LISTEN 0 128 [::]:22 [::]:*
Now that the service is listening, time to setup the relay. The server we wish to relay to, can be found at IP address 10.0.0.101.. Our relay device as you may be aware is 10.0.0.109.
┌──(rootđź’€securitynik)-[~] └─# ssh -L 10.0.0.109:9999:10.0.0.101:22 kali@localhost -v -N -4 OpenSSH_8.4p1 Debian-5, OpenSSL 1.1.1l 24 Aug 2021 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files debug1: /etc/ssh/ssh_config line 21: Applying options for * debug1: Connecting to localhost [127.0.0.1] port 22. debug1: Connection established. debug1: identity file /root/.ssh/id_rsa type -1 debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: identity file /root/.ssh/id_ecdsa type -1 debug1: identity file /root/.ssh/id_ecdsa-cert type -1 debug1: identity file /root/.ssh/id_ecdsa_sk type -1 debug1: identity file /root/.ssh/id_ecdsa_sk-cert type -1 debug1: identity file /root/.ssh/id_ed25519 type -1 debug1: identity file /root/.ssh/id_ed25519-cert type -1 debug1: identity file /root/.ssh/id_ed25519_sk type -1 debug1: identity file /root/.ssh/id_ed25519_sk-cert type -1 debug1: identity file /root/.ssh/id_xmss type -1 debug1: identity file /root/.ssh/id_xmss-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_8.4p1 Debian-5 debug1: Remote protocol version 2.0, remote software version OpenSSH_8.4p1 Debian-5 debug1: match: OpenSSH_8.4p1 Debian-5 pat OpenSSH* compat 0x04000000 debug1: Authenticating to localhost:22 as 'kali' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: curve25519-sha256 debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ecdsa-sha2-nistp256 SHA256:Q/zS4nFDQMfW2awS/SB+X4hbLAqOadUzdNtnVDX71ZY debug1: Host 'localhost' is known and matches the ECDSA host key. debug1: Found key in /root/.ssh/known_hosts:4 debug1: rekey out after 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey in after 134217728 blocks debug1: Will attempt key: /root/.ssh/id_rsa debug1: Will attempt key: /root/.ssh/id_dsa debug1: Will attempt key: /root/.ssh/id_ecdsa debug1: Will attempt key: /root/.ssh/id_ecdsa_sk debug1: Will attempt key: /root/.ssh/id_ed25519 debug1: Will attempt key: /root/.ssh/id_ed25519_sk debug1: Will attempt key: /root/.ssh/id_xmss debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,webauthn-sk-ecdsa-sha2-nistp256@openssh.com> debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Trying private key: /root/.ssh/id_rsa debug1: Trying private key: /root/.ssh/id_dsa debug1: Trying private key: /root/.ssh/id_ecdsa debug1: Trying private key: /root/.ssh/id_ecdsa_sk debug1: Trying private key: /root/.ssh/id_ed25519 debug1: Trying private key: /root/.ssh/id_ed25519_sk debug1: Trying private key: /root/.ssh/id_xmss debug1: Next authentication method: password kali@localhost's password: debug1: Authentication succeeded (password). Authenticated to localhost ([127.0.0.1]:22). debug1: Local connections to 10.0.0.109:9999 forwarded to remote address 10.0.0.101:22 debug1: Local forwarding listening on 10.0.0.109 port 9999. debug1: channel 0: new [port listener] debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: pledge: network debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
Note that port 9999 was not listening initially above when I ran the ss command. However, now that I've setup the relay, port 9999 is also listening for incoming connections as seen below.
┌──(rootđź’€securitynik)-[~] └─# ss --numeric --tcp --listening --processes State Recv-Q Send-Q Local Address:Port Peer Address:Port Process LISTEN 0 128 10.0.0.109:9999 0.0.0.0:* users:(("ssh",pid=2381,fd=4)) LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=2213,fd=3)) LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=2213,fd=4))
Confirming the Windows client IP address
C:\Users\SecurityNik>ipconfig Windows IP Configuration Ethernet adapter Ethernet: Connection-specific DNS Suffix . : Link-local IPv6 Address . . . . . : fe80::a049:348c:1e6b:6497%9 IPv4 Address. . . . . . . . . . . : 10.0.0.110 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . :
Connecting via SSH from the host at 10.0.0.110 to the server at 10.0.0.101 via 10.0.0.109 port 9999. Note above that port 9999 was not listening initially.
C:\Users\SecurityNik>ssh sans@10.0.0.109 -p 9999 sans@10.0.0.109's password: Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.4.0-88-generic x86_64) ... Last login: Sat Oct 2 11:23:37 2021 from 10.0.0.109 sans@sec503:~$
Good stuff! We have pivoted through to the device at 10.0.0.101 via 10.0.0.109. Let's now some quick live forensics.
Looking at the auth.log file on the SSH Server, we see
sans@sec503:/tmp$ sudo tail --follow /var/log/auth.log --lines 0 Oct 2 11:28:21 sec503 sshd[22558]: Accepted password for sans from 10.0.0.109 port 39258 ssh2 Oct 2 11:28:21 sec503 sshd[22558]: pam_unix(sshd:session): session opened for user sans by (uid=0) Oct 2 11:28:21 sec503 systemd-logind[995]: New session 30 of user sans.
As can be seen above, the SSH server is seeing the connection coming from the relay.
If we look at the network statistics, on the SSH server, we also see the connection is between 10.0.0.109 and 10.0.0.101.
sans@sec503:/tmp$ sudo ss --numeric --tcp --processes State Recv-Q Send-Q Local Address:Port Peer Address:Port Process ESTAB 0 0 10.0.0.101:22 10.0.0.109:39258 users:(("sshd",pid=22625,fd=4),("sshd",pid=22558,fd=4))
Looking at things now from the perspective of the proxy/pivot device we see from the verbose output a snippet below which shows a connection came in on port 9999 but got forwarded to 10.0.0.101 on port 22.
... debug1: Connection to port 9999 forwarding to 10.0.0.101 port 22 requested. debug1: channel 1: new [direct-tcpip]
If we look at the network statistics, we see a connection between the relay at 10.0.0.109 and the Windows host at 10.0.0.110. Similarly, we see a connection between the relay and the SSH server. The final 2 entries represent the same connection from two half-duplex perspective, rather than a full duplex.
┌──(rootđź’€securitynik)-[~] └─# ss --numeric --tcp --processes State Recv-Q Send-Q Local Address:Port Peer Address:Port Process ESTAB 0 0 10.0.0.109:9999 10.0.0.110:1595 users:(("ssh",pid=2418,fd=5)) ESTAB 0 0 10.0.0.109:39258 10.0.0.101:22 users:(("sshd",pid=2451,fd=10)) ESTAB 0 0 127.0.0.1:44034 127.0.0.1:22 users:(("ssh",pid=2418,fd=3)) ESTAB 0 0 127.0.0.1:22 127.0.0.1:44034 users:(("sshd",pid=2451,fd=4),("sshd",pid=2419,fd=4))
Looking at the end-host to see information about the process
C:\Users\SecurityNik>wmic process where name="ssh.exe" list brief HandleCount Name Priority ProcessId ThreadCount WorkingSetSize 133 ssh.exe 8 1288 2 7561216
Looking at the network statistics land we see that the connection is to the relay device.
C:\Users\SecurityNik>netstat -anop tcp | find "1288" TCP 10.0.0.110:1595 10.0.0.109:9999 ESTABLISHED 1288
Taking advantage of Windows as the relay.
Above, most of the relaying was done via Linux. It is also possible to do same via Windows.
First up Windows does have SSH these days, so the above example using SSH can also be done on Windows. What we will do, is connect locally to the system via SSH, then relay through a remote device running SSH to ultimately get to the server.
C:\Users\SecurityNik>ssh -L 127.0.0.1:9999:10.0.0.101:22 kali@10.0.0.109 -v -4 OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5 debug1: Connecting to 10.0.0.109 [10.0.0.109] port 22. debug1: Connection established. debug1: key_load_public: No such file or directory debug1: identity file C:\\Users\\SecurityNik/.ssh/id_rsa type -1 debug1: key_load_public: No such file or directory debug1: identity file C:\\Users\\SecurityNik/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file C:\\Users\\SecurityNik/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file C:\\Users\\SecurityNik/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file C:\\Users\\SecurityNik/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file C:\\Users\\SecurityNik/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file C:\\Users\\SecurityNik/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file C:\\Users\\SecurityNik/.ssh/id_ed25519-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file C:\\Users\\SecurityNik/.ssh/id_xmss type -1 debug1: key_load_public: No such file or directory debug1: identity file C:\\Users\\SecurityNik/.ssh/id_xmss-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_for_Windows_7.7 debug1: Remote protocol version 2.0, remote software version OpenSSH_8.4p1 Debian-5 debug1: match: OpenSSH_8.4p1 Debian-5 pat OpenSSH* compat 0x04000000 debug1: Authenticating to 10.0.0.109:22 as 'kali' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: curve25519-sha256 debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ecdsa-sha2-nistp256 SHA256:Q/zS4nFDQMfW2awS/SB+X4hbLAqOadUzdNtnVDX71ZY debug1: Host '10.0.0.109' is known and matches the ECDSA host key. debug1: Found key in C:\\Users\\SecurityNik/.ssh/known_hosts:8 debug1: rekey after 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey after 134217728 blocks debug1: pubkey_prepare: ssh_get_authentication_socket: No such file or directory debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,webauthn-sk-ecdsa-sha2-nistp256@openssh.com> debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Trying private key: C:\\Users\\SecurityNik/.ssh/id_rsa debug1: Trying private key: C:\\Users\\SecurityNik/.ssh/id_dsa debug1: Trying private key: C:\\Users\\SecurityNik/.ssh/id_ecdsa debug1: Trying private key: C:\\Users\\SecurityNik/.ssh/id_ed25519 debug1: Trying private key: C:\\Users\\SecurityNik/.ssh/id_xmss debug1: Next authentication method: password debug1: read_passphrase: can't open /dev/tty: No such file or directory kali@10.0.0.109's password: debug1: Authentication succeeded (password). Authenticated to 10.0.0.109 ([10.0.0.109]:22). debug1: Local connections to 127.0.0.1:9999 forwarded to remote address 10.0.0.101:22 debug1: Local forwarding listening on 127.0.0.1 port 9999. debug1: channel 0: new [port listener] debug1: channel 1: new [client-session] debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: pledge: network debug1: console supports the ansi parsing debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0 Linux securitynik 5.10.0-kali9-amd64 #1 SMP Debian 5.10.46-4kali1 (2021-08-09) x86_64 The programs included with the Kali GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Kali GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Sat Oct 2 08:00:39 2021 from 10.0.0.110 ┏━(Message from Kali developers) ┃ ┃ We have kept /usr/bin/python pointing to Python 2 for backwards ┃ compatibility. Learn how to change this and avoid this message: ┃ ⇒ https://www.kali.org/docs/general-use/python3-transition/ ┃ ┗━(Run: “touch ~/.hushlogin” to hide this message) ┌──(kali㉿securitynik)-[~] └─$
With the connection setup to the remote server as seen from the terminal above. Note, I did not use the "-N", this is why the output in this case looks different from the one before. We can then confirm the SSH process is connected to the relay at 10.0.0.109 and is also listening for incoming connections on port 9999
C:\Users\SecurityNik>wmic process where name="ssh.exe" list brief HandleCount Name Priority ProcessId ThreadCount WorkingSetSize 140 ssh.exe 8 4548 4 7651328 C:\Users\SecurityNik>netstat -anop tcp | find "4548" TCP 10.0.0.110:1732 10.0.0.109:22 ESTABLISHED 4548 TCP 127.0.0.1:9999 0.0.0.0:0 LISTENING 4548
Using the SSH client on Windows
C:\Users\SecurityNik>ssh sans@127.0.0.1 -p 9999 sans@127.0.0.1's password: sans@127.0.0.1's password: Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.4.0-88-generic x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/advantage 89 updates can be applied immediately. To see these additional updates run: apt list --upgradable Last login: Sat Oct 2 12:10:15 2021 from 10.0.0.109 sans@sec503:~$
Looking below, we can see the SSH Server is still seeing the connection coming from the proxy/pivot device.
Oct 2 12:20:06 sec503 sshd[23430]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.0.109 user=sans Oct 2 12:20:08 sec503 sshd[23430]: Failed password for sans from 10.0.0.109 port 39286 ssh2 Oct 2 12:20:11 sec503 sshd[23430]: Accepted password for sans from 10.0.0.109 port 39286 ssh2 Oct 2 12:20:11 sec503 sshd[23430]: pam_unix(sshd:session): session opened for user sans by (uid=0) Oct 2 12:20:11 sec503 systemd-logind[995]: New session 37 of user sans.
On the proxy, we may also see messages such as the following showing up on the console.
debug1: Connection to port 9999 forwarding to 10.0.0.101 port 22 requested. debug1: channel 2: new [direct-tcpip] debug1: channel 2: free: direct-tcpip: listening port 9999 for 10.0.0.101 port 22, connect from 127.0.0.1 port 1766 to 127.0.0.1 port 9999, nchannels 3
Leveraging Windows netsh to setup the proxy
Note, below I use the service name rather than the port numbers. I just wanted to do things differently.
C:\WINDOWS\system32>netsh interface portproxy add v4tov4 listenport=ssdp connectaddress=10.0.0.101 connectport=ssh listenaddress=10.0.0.110 protocol=tcp
If you wanted to confirm the port numbers for these two services, you can type
C:\Users\SecurityNik>type c:\Windows\System32\drivers\etc\services | findstr /i /R "ssdp ssh" ssh 22/tcp #SSH Remote Login Protocol ssdp 1900/tcp ssdp 1900/udp
Showing the configuration.
C:\WINDOWS\system32>netsh interface portproxy show all Listen on ipv4: Connect to ipv4: Address Port Address Port --------------- ---------- --------------- ---------- 10.0.0.110 ssdp 10.0.0.101 ssh
Dumping the configuration
C:\WINDOWS\system32>netsh interface portproxy dump #======================== # Port Proxy configuration #======================== pushd interface portproxy reset add v4tov4 listenport=ssdp connectaddress=10.0.0.101 connectport=ssh
With the Port forwarding configured, we now see that there is a TCP connection listening for this incoming communication on port 1900.
C:\Users\SecurityNik>netstat -anop tcp | findstr /R "1900 22" TCP 10.0.0.110:1900 0.0.0.0:0 LISTENING 2416
Time to initiate a connection from IP 10.0.0.109 to the SSH Server at 10.0.0.101 via the Windows host at 10.0.0.110.
┌──(rootđź’€securitynik)-[~] └─# ssh sans@10.0.0.110 -p 1900 sans@10.0.0.110's password: Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.4.0-88-generic x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/advantage 89 updates can be applied immediately. To see these additional updates run: apt list --upgradable Last login: Sat Oct 2 12:46:38 2021 from 10.0.0.110 sans@sec503:~$
Boom! We were able to connect successfully via the Windows device.
Looking at the Windows pivot/relay again, we see a connection is established with the host at 10.0.0.109 on port 1900 which is our proxy port. Similarly, we see this Windows host which is the pivot/relay has a session established to 10.0.0.101 on port 22.
C:\Users\SecurityNik>netstat -anop tcp | findstr /R "1900 22" TCP 0.0.0.0:5040 0.0.0.0:0 LISTENING 2224 TCP 10.0.0.110:1849 10.0.0.101:22 ESTABLISHED 2416 TCP 10.0.0.110:1900 0.0.0.0:0 LISTENING 2416 TCP 10.0.0.110:1900 10.0.0.109:44136 ESTABLISHED 2416
Looking at the SSH server logs, we see it accepted the authentication from the host at 10.0.0.110, which is our relay/pivot device.
Oct 2 12:46:55 sec503 sshd[23850]: Accepted password for sans from 10.0.0.110 port 1849 ssh2 Oct 2 12:46:55 sec503 sshd[23850]: pam_unix(sshd:session): session opened for user sans by (uid=0) Oct 2 12:46:55 sec503 systemd-logind[995]: New session 40 of user sans.
That's good progress!!
Browser Based - gaining web access from a computer with no default gateway
Final one. Using a browser to gain internet access from a host which currently does not have a default gateway defined. Thus the host does not know how to come off the network to get to the internet. Below shows the host IP configuration with no "Default Gateway"
C:\Users\SecurityNik>ipconfig Windows IP Configuration Ethernet adapter Ethernet: Connection-specific DNS Suffix . : Link-local IPv6 Address . . . . . : fe80::a049:348c:1e6b:6497%9 IPv4 Address. . . . . . . . . . . : 10.0.0.110 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . :
When we try to ping www.securitynik.com, here is what we get.
C:\Users\SecurityNik>ping www.securitynik.com -n 1 Ping request could not find host www.securitynik.com. Please check the name and try again.
On the other hand, we need a device that has internet access. In this case , I've configured my Linux with two interfaces. One is on the internal network (10.0.0.109) and the other on the external network (10.0.3.15) as shown below.
┌──(rootđź’€securitynik)-[~] └─# ip address show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo ... 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 08:00:27:0e:34:8d brd ff:ff:ff:ff:ff:ff inet 10.0.0.109/24 brd 10.0.0.255 scope global dynamic eth0 ... 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 08:00:27:d0:8c:32 brd ff:ff:ff:ff:ff:ff inet 10.0.3.15/24 brd 10.0.3.255 scope global dynamic noprefixroute eth1 ...
Let's also confirm, this device can ping www.securitynik.com.
┌──(rootđź’€securitynik)-[~] └─# ping -c 1 www.securitynik.com PING ghs.googlehosted.com (142.251.33.179) 56(84) bytes of data. 64 bytes from yyz10s17-in-f19.1e100.net (142.251.33.179): icmp_seq=1 ttl=116 time=57.6 ms
With the successful ping, let's once again take advantage of SSH's "dynamic" application level port forwarding. Currently SSH can act as a SOCKS server, supporting both SOCKS4 and SOCKS5. You will need to ensure SSH is running on the device will be ultimately giving access to the internet.
C:\Users\SecurityNik>ssh -D 10.0.0.110:9999 kali@10.0.0.109 -N -v OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5 debug1: Connecting to 10.0.0.109 [10.0.0.109] port 22. debug1: Connection established. debug1: key_load_public: No such file or directory debug1: identity file C:\\Users\\SecurityNik/.ssh/id_rsa type -1 debug1: key_load_public: No such file or directory debug1: identity file C:\\Users\\SecurityNik/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file C:\\Users\\SecurityNik/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file C:\\Users\\SecurityNik/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file C:\\Users\\SecurityNik/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file C:\\Users\\SecurityNik/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file C:\\Users\\SecurityNik/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file C:\\Users\\SecurityNik/.ssh/id_ed25519-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file C:\\Users\\SecurityNik/.ssh/id_xmss type -1 debug1: key_load_public: No such file or directory debug1: identity file C:\\Users\\SecurityNik/.ssh/id_xmss-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_for_Windows_7.7 debug1: Remote protocol version 2.0, remote software version OpenSSH_8.4p1 Debian-5 debug1: match: OpenSSH_8.4p1 Debian-5 pat OpenSSH* compat 0x04000000 debug1: Authenticating to 10.0.0.109:22 as 'kali' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: curve25519-sha256 debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ecdsa-sha2-nistp256 SHA256:Q/zS4nFDQMfW2awS/SB+X4hbLAqOadUzdNtnVDX71ZY debug1: Host '10.0.0.109' is known and matches the ECDSA host key. debug1: Found key in C:\\Users\\SecurityNik/.ssh/known_hosts:8 debug1: rekey after 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey after 134217728 blocks debug1: pubkey_prepare: ssh_get_authentication_socket: No such file or directory debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,webauthn-sk-ecdsa-sha2-nistp256@openssh.com> debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Trying private key: C:\\Users\\SecurityNik/.ssh/id_rsa debug1: Trying private key: C:\\Users\\SecurityNik/.ssh/id_dsa debug1: Trying private key: C:\\Users\\SecurityNik/.ssh/id_ecdsa debug1: Trying private key: C:\\Users\\SecurityNik/.ssh/id_ed25519 debug1: Trying private key: C:\\Users\\SecurityNik/.ssh/id_xmss debug1: Next authentication method: password debug1: read_passphrase: can't open /dev/tty: No such file or directory kali@10.0.0.109's password: debug1: Authentication succeeded (password). Authenticated to 10.0.0.109 ([10.0.0.109]:22). debug1: Local connections to 10.0.0.110:9999 forwarded to remote address socks:0 debug1: Local forwarding listening on 10.0.0.110 port 9999. debug1: channel 0: new [port listener] debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: pledge: network debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
Looking at above, we see the successful authentication to the remote host through which internet will be gained. Looking now at the network statistics on the Windows host.
C:\Users\SecurityNik>wmic process where name="ssh.exe" list brief HandleCount Name Priority ProcessId ThreadCount WorkingSetSize 136 ssh.exe 8 4284 3 7589888 C:\Users\SecurityNik>netstat -anop tcp | findstr "4284" TCP 10.0.0.110:2726 10.0.0.109:22 ESTABLISHED 4284 TCP 10.0.0.110:9999 0.0.0.0:0 LISTENING 4284
Above shows our host at 10.0.0.110 has established a connection with 10.0.0.109 on port 22. We also see port 9999 is listening for incoming connection.
With this in place, we know from the client's perspective, the authentication was successful, looking at it from the relay device's perspective.
┌──(rootđź’€securitynik)-[~] └─# tail --follow /var/log/auth.log --lines 0 Oct 2 11:48:08 securitynik sshd[10053]: Accepted password for kali from 10.0.0.110 port 2726 ssh2 Oct 2 11:48:08 securitynik sshd[10053]: pam_unix(sshd:session): session opened for user kali(uid=1000) by (uid=0) Oct 2 11:48:08 securitynik systemd-logind[399]: New session 35 of user kali.
Confirming from the SSH activity from the first 5 packets.
┌──(rootđź’€securitynik)-[~] └─# tcpdump -nnt --interface any port "(443 or 22 or 53)" --number tcpdump: data link type LINUX_SLL2 listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes 1 eth0 In IP 10.0.0.110.2726 > 10.0.0.109.22: Flags [S], seq 2796182822, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 2 eth0 Out IP 10.0.0.109.22 > 10.0.0.110.2726: Flags [S.], seq 616489375, ack 2796182823, win 64240, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 3 eth0 In IP 10.0.0.110.2726 > 10.0.0.109.22: Flags [.], ack 1, win 8212, length 0 4 eth0 Out IP 10.0.0.109.22 > 10.0.0.110.2726: Flags [P.], seq 1:33, ack 1, win 502, length 32: SSH: SSH-2.0-OpenSSH_8.4p1 Debian-5 5 eth0 In IP 10.0.0.110.2726 > 10.0.0.109.22: Flags [P.], seq 1:34, ack 1, win 8212, length 33: SSH: SSH-2.0-OpenSSH_for_Windows_7.7 ...
Time to configure our browser to point to the local proxy, while going to www.securitynik.com.
C:\Users\SecurityNik>"c:\Program Files\Google\Chrome\Application\chrome.exe" --proxy-server="socks5://10.0.0.110:9999" "https://www.securitynik.com"
When the browser is opened we see the page loads successfully.
We can confirm the access was forwarded as seen below from the perspective of the Windows client.
debug1: channel 37: new [dynamic-tcpip] debug1: Connection to port 9999 forwarding to socks port 0 requested. debug1: channel 38: new [dynamic-tcpip] .... debug1: channel 2: free: direct-tcpip: listening port 9999 for www.securitynik.com port 443, connect from 10.0.0.110 port 2912 to 10.0.0.110 port 9999, nchannels 35 debug1: channel 3: free: direct-tcpip: listening port 9999 for www.blogger.com port 443, connect from 10.0.0.110 port 2913 to 10.0.0.110 port 9999, nchannels 34 debug1: channel 6: free: direct-tcpip: listening port 9999 for apis.google.com port 443, connect from 10.0.0.110 port 2916 to 10.0.0.110 port 9999, nchannels 33 ....
Looking at a few selected packets from the tcpdump output and we see
┌──(rootđź’€securitynik)-[~] └─# tcpdump -nnt --interface any port "(443 or 22 or 53)" --number tcpdump: data link type LINUX_SLL2 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes ... 1 eth0 In IP 10.0.0.110.2726 > 10.0.0.109.22: Flags [P.], seq 2796280292:2796280392, ack 617013412, win 8207, length 100 2 eth0 Out IP 10.0.0.109.22 > 10.0.0.110.2726: Flags [.], ack 100, win 1727, length 0 3 eth1 Out IP 10.0.3.15.36773 > 192.168.173.43.53: 37836+ A? www.securitynik.com. (37) ... 8 eth1 In IP 192.168.173.43.53 > 10.0.3.15.36773: 37836 3/0/0 CNAME www.securitynik.com.ghs.googlehosted.com., CNAME ghs.googlehosted.com., A 142.251.32.83 (118) ...
We see above a packet exchanged between 10.0.0.110 and 10.0.0.109. We also see that that the 10.0.3.15 (interface in the proxy device connected to the internet) made a DNS request for www.securitynik.com and we see it got an answer back stating www.securitynik.com is at 142.251.32.83.
Looking now for communications going to this IP and communications between the 10.0.0.110 and 10.0.0.109, we see.
3 eth1 Out IP 10.0.3.15.36773 > 192.168.173.43.53: 37836+ A? www.securitynik.com. (37) 8 eth1 In IP 192.168.173.43.53 > 10.0.3.15.36773: 37836 3/0/0 CNAME www.securitynik.com.ghs.googlehosted.com., CNAME ghs.googlehosted.com., A 142.251.32.83 (118) 9 eth1 Out IP 10.0.3.15.36773 > 192.168.173.43.53: 44081+ AAAA? www.securitynik.com. (37) 11 eth1 Out IP 10.0.3.15.48196 > 142.251.32.83.443: Flags [S], seq 961402155, win 64240, options [mss 1460,sackOK,TS val 2530004336 ecr 0,nop,wscale 7], length 0 13 eth1 In IP 142.251.32.83.443 > 10.0.3.15.48196: Flags [S.], seq 191104001, ack 961402156, win 65535, options [mss 1460], length 0 14 eth1 Out IP 10.0.3.15.48196 > 142.251.32.83.443: Flags [.], ack 1, win 64240, length 0 24 eth0 Out IP 10.0.0.109.22 > 10.0.0.110.2726: Flags [P.], seq 1:45, ack 316, win 1727, length 44 25 eth0 In IP 10.0.0.110.2726 > 10.0.0.109.22: Flags [P.], seq 316:872, ack 45, win 8207, length 556 26 eth0 Out IP 10.0.0.109.22 > 10.0.0.110.2726: Flags [.], ack 872, win 1742, length 0 27 eth1 Out IP 10.0.3.15.48196 > 142.251.32.83.443: Flags [P.], seq 1:518, ack 1, win 64240, length 517 28 eth1 In IP 142.251.32.83.443 > 10.0.3.15.48196: Flags [.], ack 518, win 65535, length 0 31 eth0 Out IP 10.0.0.109.22 > 10.0.0.110.2726: Flags [P.], seq 45:89, ack 872, win 1742, length 44 32 eth0 In IP 10.0.0.110.2726 > 10.0.0.109.22: Flags [P.], seq 872:1428, ack 89, win 8206, length 556 33 eth0 Out IP 10.0.0.109.22 > 10.0.0.110.2726: Flags [.], ack 1428, win 1751, length 0 34 eth1 Out IP 10.0.3.15.57382 > 172.217.165.3.443: Flags [P.], seq 1:518, ack 1, win 64240, length 517 36 eth1 In IP 142.251.32.83.443 > 10.0.3.15.48196: Flags [P.], seq 1:2781, ack 518, win 65535, length 2780 37 eth1 Out IP 10.0.3.15.48196 > 142.251.32.83.443: Flags [.], ack 2781, win 62780, length 0 38 eth0 Out IP 10.0.0.109.22 > 10.0.0.110.2726: Flags [P.], seq 89:2909, ack 1428, win 1751, length 2820 39 eth0 In IP 10.0.0.110.2726 > 10.0.0.109.22: Flags [.], ack 2909, win 8212, length 0 40 eth1 In IP 142.251.32.83.443 > 10.0.3.15.48196: Flags [P.], seq 2781:4171, ack 518, win 65535, length 1390 41 eth1 Out IP 10.0.3.15.48196 > 142.251.32.83.443: Flags [.], ack 4171, win 62780, length 0 42 eth1 In IP 142.251.32.83.443 > 10.0.3.15.48196: Flags [P.], seq 4171:4677, ack 518, win 65535, length 506 43 eth1 Out IP 10.0.3.15.48196 > 142.251.32.83.443: Flags [.], ack 4677, win 62780, length 0 44 eth0 Out IP 10.0.0.109.22 > 10.0.0.110.2726: Flags [P.], seq 2909:4841, ack 1428, win 1751, length 1932 45 eth0 In IP 10.0.0.110.2726 > 10.0.0.109.22: Flags [.], ack 4841, win 8212, length 0
Ok! That's it!!
References:
