Say you popped into a network after exploiting something, and you are looking to further infiltrate the network. When theorizing in my head I realized the local ip's can change themselves. So doing a ping sweep of the subnet of your ip could potentially miss targets if they were using different ip's?

After this realization, how do you discover these hosts? All I can think of is sniffing to find hosts, besides that what else can you do?

  • IPs don't change that often, and usually servers have static ips. Beyond that arp, netstat, your local DC, fileshares, netbios, local reverse dns lookups are pretty good methods
    – KDEx
    Dec 10 '15 at 20:13
  • Your question seems confused. You can find targets just fine with IPs, but your "theorizing" is about maintaining a correlation between IPs and the actual machines. That's a totally different problem. Which are you wanting to know?
    – schroeder
    Dec 10 '15 at 20:36

This is a huge question but I'll put out a few things in the way I would approach finding other targets to pivot to.

1.) look at layer 2 arp -a sends no packets to the wire and helps you spot other hosts the system you have access to is talking too.

2.) look at layer 3/4 lsof -i (or it's equivalent) will show you established connections that allow you to see the IP's and some protocols that this computer is communicating with others on. Again this sends no packets on the network.

3.) Check for mounted storage, local scripts, backup configurations, DLP software, or passwords which may be configured to give you information, or possibly access too, other servers. Again this sends no packets onto the network and the storage devices may have shared networks to other hosts (possibly beyond the scope of your question).

4.) At this point verify you are not on a HoneyPot before proceeding.

5.) Optionally at this point you could look at packet capture, this can be detected but 99.9% of organizations aren't looking for this so it's generally safe to do. This will help you find other hosts on the network that are broadcasting their information and depending on the type network may give you access to lots of other traffic nearby.

6.) Determine internal DNS and if possible scan the internal DNS for other hosts. DNS traffic is considered pretty normal. Do it slowly if you are in a high-security environment.

7.) At this point I would suggest exploiting the connected systems using the connecting protocols. You want to go out on protocols the system you are on normally talks out on (DLP, NMS, Backup are most common but frequently databases are also available). These are outbound connections which might not look weird to from the standpoint of netflow communications. If you can pivot in-band it is much stealthier than scanning.

8.) Next step connecting to hosts which connect to the one you are on. This is similar to the step above but from a netflow perspective some systems always initiate connections to the end points in this case you are likely an endpoint connecting back which may or may not get caught.

9.) If that hasn't worked you start scanning. Slow your scans below the most common IDS timing threshold for scans or do this manually at first. Aim for protocols you can exploit and prioritize most common protocols that a given client would have. Go slow stay under the radar. The scanning tool nmap from nmap.org has a --top-ports option if you don't know where to start. I'd say start with the top 10-20 ports at first unless you are in a rush.

10.) If you are still having no luck now you start deeper scans and map the entire environment out.

11.) Still having issues try jumping VLANS's


Good video of it in use on a Cisco switch.




12.) Check for wireless, if the device you have has wireless access (try turning it on at some point if it's not on) scan the wireless network for other targets. Don't forget Bluetooth or any other protocol likely to be on the type host you have access too.

13.) Still no luck. Check to see if you are on a Virtual Machine, identify which one and look for ways to jailbreak the VM into the Hypervisor and attack from there.

NOTE: Always check for IPv6 connections and explore for storage connections in depth. There is also more work to be done on the local host like grabbing keys and passwords if you can but your question was more focused on finding targets so I'm leaving that out of scope.

This is a BIG subject with lots of additional things you could do but what is a listed above is a very effective strategy for mapping out nearby hosts in the situation you asked about.

  • How would packet captures be noticed?
    – schroeder
    Dec 11 '15 at 0:56
  • Short answer: Interfaces in promiscuous mode (for capturing) keep track of MAC addresses not talking directly to them, this is something they don't ordinarily do (other than broadcast traffic). You can test if one is listening by sending traffic to a fake MAC/IP address near that host then check that host twice in a row if it knows of the fake MAC address. If the first response is slower than the second the system was not listening in promiscuous mode and had to build its arp table the first time. If the times are identical it was listening. Dec 11 '15 at 7:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.