Segmentation Testing

Wireless vulnerabilities can manifest through misconfiguration of networks of lower trust (BYOD, IOT, Guest, etc). In an ideal situation, the organization would have a separate service provider connection set up for each of the lower trust networks. However, this is not always the case. In some instances, the customer will host lower trust networks on corporate infrastructure, relying on VLAN configuration, Access Control Lists (ACLs), firewalls, or other controls to prevent users on lower trust networks from accessing the corporate network. As a result, it is important to ensure that connections from all in-scope lower trust networks be tested for access to corporate resources. In some cases, these tests have demonstrated bypass of perimeter controls, allowing attacks that would normally be detected on the corporate network to go completely undetected.

Procedure

• During passive analysis and active testing of in-scope networks, collect configuration details to support segmentation testing. Often, this involves collection of IP address information from VoIP handsets and printer configuration pages. If IP address information cannot be easily collected (no VoIP, printers hardened, etc), then ask the POC for IP addresses belonging to the following resources:

  • Domain controllers
  • DNS servers
  • DHCP server
  • Sample corporate file server
  • Sample corporate application server Note: Usually, domain controller and DNS server IP addresses will suffice for the planned activity, so not all of the resources above need to be collected. Having a diverse set of IP addresses may increase the accuracy of your results.

• Connect to the lower-trust network and record your network configuration in the report.

• Inspect the DNS servers associated with the target network, are they:

  • Public DNS servers
  • Different local DNS servers
  • Corporate DNS servers

• If the DNS servers are non-corporate, then attempt manual resolution with the corporate DNS server. Skip the next two steps if no results are returned. A sample set of queries is shown below. nslookup server [corporate DNS IP] [domain controller hostname] [domain controller IP addres] set type=SRV _ldap._tcp.[fully qualified corporate Active Directory domain]

• Perform forward DNS enumeration if the hostname query returns an IP address. gobuster dns -d [domain suffix] -r [corporate DNS IP] -w [DNS hostname dictionary]

• Perform reverse DNS enumeration if IP address query returns a hostname.

  prips [Internal IP address range] > inscope_ip_list.txt
  inscope_ip_list.txt | hakrevdns > dns_results.txt
  

  Note: You may not have full awareness of the internal IP address scope. It may be worthwhile to use the entire RFC 1918 scope or ask the customer for broad ranges to generate IP lists with prips.

• Perform targeted scanning of corporate IP addresses collected in the first step in this procedure. It is typically useful to expand scanning to a 24-bit mask to target the network where the target resource is deployed. It may not be practical to scan the entire RFC 1918 IP address space from this context.

  masscan -p 21,22,23,80,443,445,1433,8080 [target resource network] -oL masscan_results.txt
  

• Repeat this process for each of the in-scope lower-trust SSIDs where access has been obtained/granted.