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:
Of 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 :
arpAnother bulit-in command that can help us to get even more information isarp, which displays the host ARP cache.As 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.
netstatAlthougharpmay 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:
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:
Let us run the command on the entire target subnet (
10.10.10.10/24) and see what we obtain.Although 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:
With 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:
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.As we can see, we have discovered another host.
The final configuration of the networks and hosts discovered can be summarized as follows:
netenumThe 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:
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):
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:Note: 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.
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:
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
Let's run it and see if the target has some open ports: ``` msf auxiliary(tcp) > run
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
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.
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
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?