Joff Thyer //
Picture a scenario whereby you are involved in an internal network penetration test. Perhaps you have succeeded with a spear-phishing campaign and landed on an internal system, or perhaps you have been placed there to begin with.
Being the l33t ninja penetration tester that you are, you lead with some low n’ slow outbound port scanning and quickly realize you have a handful of useful TCP ports available for Command and Control (C2) communications. Either using your pre-existing C2 channel or by establishing another one, you begin to look for privilege escalation. Naturally, you whip out good old “PowerUp” from the Empire project as well as your favorite method to examine group policy preferences. You are lucky today and find that there is a DLL hijack opportunity, as well as credentials within the Group Policy Preferences XML files. Taking the easy route, you use the Group Policy Preferences credentials and establish a privileged C2 channel using trusty PSEXEC, or WMI.
After that, you go ahead with your usual routine to learn more information. Windows commands like ‘net view /domain’, ‘net localgroup administrators’, ‘net group “Domain Admins” /domain’, and ‘net group “Domain Controllers” /domain’.
You also go ahead and check out “User-Hunter” from Empire in order to find where all the domain admins have logged in.
You proceed with some DNS lookups against the domain controller names and get a pretty good sense of where in the network these systems live. You quickly learn that the environment is pretty large with dedicated sub-networks for client systems, as well as dedicated sub-networks for server systems.
After that, you begin to wonder how the rest of the client-side network is put together. You know it has sub-networks, but like so many organizations, your customer uses a class B network (/16) on the inside and you really want to get a sense of where all the client-side subnets are!
One great start is your own network adapter. You type the ‘ipconfig’ command and learn that you are sitting in a class C network.
From here you can make some observations. Namely that you have an address in a class C (/24) address space with a router gateway address of the network address (10.99.1.0 in this case) plus one.
You are dying to crank loose some “smb_login” scans with Metasploit so you can login to other systems. You know you can target some individual systems found with user-hunter, but you don’t want to miss any really cool devices for expanded attack surface opportunities!
With some l33t consulting from some former enterprise network architect people, you have a pretty good idea that almost all of the router gateways in this environment will probably observe the same convention of being the network address plus one. You can also make the assumption that if you are sitting in a class C address space, then a pretty good part of the network is probably architected the same way. Since internal routers very rarely filter ICMP traffic, then you can go on an internal router gateway hunt using ICMP echo requests, and a DOS batch file loop command.
C:\> FOR /L %X IN (1,1,254) do @PING -i 3 -w 1 -n 1 10.99.%x.1 | FIND “bytes=”
Let’s break the PING command arguments down to understand this a little better:
-i 3 ⇒ set the IP TTL to 3 hops maximum (stay pretty local in other words)
-w 1 ⇒ wait only 1 second for a response
-n 1 ⇒ send only one packet
The result of doing this should reveal all the potential router gateways on the network, which in turn lets you know where other client/server sub-networks reside in the environment.
The results above also yield some other potential information. Where the TTL returned is 255, you are getting answers in your local subnet. Where the TTL returned is 254, you are probably getting answers in the same LAN / campus location as where your system is connected. Where the TTL is 253 or even less, you may well be pinging router gateways in a remote branch office or other campus location. You might have to experiment a little with the “-i 3” parameter if the network is larger, and involves perhaps MultiProtocol Label Switching (MPLS). In the case of MPLS, the TTL might or might not be decremented across the MPLS (cloud) router hops. This is a provider dependent decision. I would recommend starting with “-i 3” and going up as high as “-i 9” to capture most of the network scope. Anything that is not local would be routed to the gateway of last resort and will result in a “TTL expired in transit method” response, or in more sophisticated environments might be routed to a black hole/sink destination.
Happy pen testing all!