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.