I recently found myself in a situation where I had access to an internal network (10.0.0.0/8), but had no additional information about the network’s topology, defenses, firewalls, or hardware. Scratching my head, I started putting together tactics to enumerate the network given the following constraints:

  • Short amount of time available for discovery
  • Cannot be caught by organization IT or security teams
  • Not joined to any Windows domains

With the above constraints, a number of the typical approaches were disqualified from the get-go. There was no way I could run an nmap scan across all of the 10.0.0.0/8 network in the given time frame, and if I could even the worst IDS/IPS controls could easily pick up on my activities. All of the Windows out-of-the-box tools were out as well, so no net, dsquery, netdom, or wmic.

Whatever could I do then? Well, I’ll tell you, but note that I’m only going to be discussing host discovery in this series. As far as further exploitation and escalation goes, I’ll save that for some other time. Also, I’d rather go into a lot of detail than skimp on anything for the sake of keeping this post to a digestible length. As such I’m going to spread this information across a couple of posts.

Gathering Seeds

First thing’s first – I wanted to identify as many in-use internal IP addresses as I possibly could in the shortest amount of time while making very little noise. Once I had these IP addresses, I could guess at the size of the subnets they were in and only scan those subnets (I typically see internal networks divided into class C networks, so guessing that all IP addresses resided in /24s was a good bet). In doing this I would hopefully reduce my scanning targets from 10.0.0.0/8 (2^24 == 16,777,216 hosts to scan) to a handful of /24 networks (10-20 * 2^8 == 2,560-5,120 hosts to scan).

From there, I asked myself: what hosts can we typically find when we have very basic network access? Consider the following:

  • If you have internal network access, then you’ve been assigned an internal IP address. Chances are that you are not in a subnet all by yourself.
  • For an organization with a real internal network, internal domain names will be resolved by an internal DNS server. This internal DNS resolution needs to be provided for all boxes with internal network access, regardless of whether the box is joined to a domain.
  • Unless your default gateway is the internal network’s egress point any traffic that you send to the Internet will make a few hops around the internal network before reaching the glorious Interwebz.
  • Larger organizations typically have scanning devices employed that will poke and prod at the various boxes on the internal network for security and inventory purposes. They commonly inspect machines’ SMB, HTTP, and HTTPS services.
  • If you’ve joined the internal network via VPN, then your local routing tables have been altered to route traffic to the internal network. This could mean that all of your traffic is being routed through the VPN concentrator (0.0.0.0/0) or that all traffic destined to the internal IP space is being routed through the VPN concentrator (10.0.0.0/8, 192.168.0.0/16, and 172.16.0.0/20). With any luck though, your local routing tables will contain more specific rules, potentially all the way down to routing to specific /24 subnets.

Let’s walk through each of the points above. Note that all of the commands shown are run from OSX, so translate the commands to your respective OS as necessary. Also, I’m running these commands from a hotel wireless connection and not a real internal network, so what you see when on a real internal network may differ some. I’m happy to run these from a real internal network if someone would be gracious enough to provide me with VPN credentials…

Local Subnet

Take a look at your IP address with the following command:

My local output from this command is shown below:

Ifconfig output
Ifconfig output

As shown above, I’ve got an IP address of 192.168.100.167 with a netmask of 0xffffff00, meaning that my local network is 192.168.100.0/24. Chances are I’m not the only one in 192.168.100.0/24, so let’s throw that network into the metaphorical target networks bucket for safe keeping.

DNS Server

Use the following command to hit up your friendly local DNS server for Google’s IP address:

My local output from this command is shown below:

Nslookup output
Nslookup output

The arrow above points to the DNS server that responded to my DNS query. In a Windows environment, the role of DNS server is typically fulfilled by a domain controller. When it isn’t fulfilled by a domain controller, it’s most likely fulfilled by an appliance. In either case, the server that responds is probably in a server subnet, so slap a /24 on that baby and into the bucket it goes (ie: 192.168.100.1 means add 192.168.100.0/24 to your list of target subnets).

Traceroute

Use the following command to trace the hops between your position in the network and 8.8.8.8:

My local output from this command is shown below:

Traceroute output
Traceroute output

Unfortunately my default gateway is in fact the network egress point, but if I had run this from an internal network then I may see that the first few hops were in the 10.0.0.0/8 range. For each of these hops, I would take the IP address, slap a /24 on it, and throw that bad boy into the bucket with its friends. In this case, I throw a third copy of 192.168.100.0/24 into the bucket…

Scanning Devices

Assuming that you don’t already have anything running on these ports, run the following commands in separate terminal sessions before you even join the network:

These commands will set up ncat listeners on the specified ports (SSH, HTTP, NetBios, HTTPS, SMB respectively), which will then report any connections that are made to them. For instance, I connected to an ncat listener on port 445 running on my local machine from my local machine, the results of which are shown below:

Ncat output
Ncat output

As shown above, ncat displays the IP address of where the connection came from. The /24 networks for all of the IP addresses that connect to your ncat listeners should be thrown into your bucket, which is hopefully starting to fill up a bit by now. In my case, I would throw 127.0.0.0/24 into the bucket… which would make me an idiot.

Note that every time a connection is established and then closed to any of your ncat listeners, you will have to restart the ncat listener. There could very well be a way to prevent ncat from closing on disconnect, so please shoot me a message at @_lavalamp showing me how and telling me to RTFM.

Routing Tables

Routing tables contain the rules used by your operating system to determine where to route network traffic once user space applications hand packets to the kernel. Use the following command to print your routing tables:

Running this command on my local machine returns the following:

Netstat routing tables output
Netstat routing tables output

As shown above, the left-most column contains all of the networks that my machine knows about. If I was connected to a VPN that made use of the 10.0.0.0/8 network, the left-most column would also contain rules for networks in the 10.0.0.0/8 space. With any luck, the rules will specify /16 or smaller subnets within the 10.0.0.0/8 space. It puts the networks in the bucket or else it gets the hose again.

Checking the Bucket

Take a look at your bucket. Peer down into it. There should be a bunch of networks in there – some bigger than others, but all of them trembling at the sight of you. Smell their fear. Laugh maniacally. Either that or enjoy yourself in quiet contemplation like this guy:

Only the best nod
Only the best nod

Regardless of the method of celebration you prefer, these networks want you to scan them. It makes them feel dirty, but in a good way. The only thing you can do at this point is oblige.

Conclusion

Hopefully this post introduced you to some new techniques for fast and quiet host discovery that you can add to your toolset. For the next post I’m going to cover scanning the networks discovered through the methods above, and how to use the services found through those scans to get an even better network footprint.

Do you have any cool ways that you do unobtrusive host discovery? If so, please tell me about them via Twitter at @_lavalamp! I’d be happy to throw a section below this with additional tips and techniques from the community, and will of course give credit.

Thanks for your time folks. As my man bosnianbill says – stay safe and stay legal.