Sunday, October 17, 2021

Pivoting / Relaying SSH communication through ncat, iptables, netsh, SSH and getting internet access via SSH "dynamic" application port forwarding

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: