contact us

What You Don’t Know, Your RiskSense Penetration Tester Does

by May 4, 2020

What You Don’t Know, Your RiskSense Penetration Tester Does

Knowing the Lay of Your Network Land

As a Security Analyst, my job is to identify all possible hosts within a predefined scope of network ranges and assess them for vulnerabilities. I exploit my way through the network to acquire all appropriate access and compromise specific targets defined in the rules of engagement. As I find and report interesting vulnerabilities to my clients, I am often met with surprise when disclosing the manner or device that was compromised.

One such client had dismissed a host with vulnerabilities because their documentation stated the device was decommissioned. It was not until that device was used as an attack path’s initial point to domain compromise that it was finally physically decommissioned. Another client had a handful of Windows servers sitting on an assumed retired subnet. Despite not being joined to the domain, the local administrator passwords were still reused on the production network, which led to domain compromise.

As you read this post, your public IP space is being scanned by both legitimate tools, like Googlebot or Shodan crawler, and nefarious scanners probing for known vulnerabilities in your perimeter. Attackers are looking for anything that can be leveraged, such as:

  • Newly installed servers without hardening.
  • Servers or services with default passwords.
  • Legacy servers containing outdated software.

It is not just external machines that require accounting for. Attackers compromise devices brought into company networks containing malware[1] capable of scanning these networks and compromising vulnerable machines. You do not want to find out about a vulnerable host from exposure when the process to find it is very simple.

My past experiences and adversarial tactics should drill home the importance of knowing what is on your network. This is so important, in fact, that the very first Center for Information Security (CIS) Control is Inventory and Control of Hardware Assets[2].

“Actively manage (inventory, track, and correct) all hardware devices on the network so that only authorized devices are given access, and unauthorized and unmanaged devices are found and prevented from gaining access.”

Before starting to track IPs, you must know your total available public and private IP space. What publicly routable IP space does your company own? What are your cloud-hosted asset’s IP addresses? What private IP ranges (RFC1918[3]) are in use? Are publicly routable IPs in use for internal-only access? Within these IP ranges are varying asset densities and IP address use. It is difficult to know what IPs are in use and how many IP addresses are in use at one time. As soon as you have swept your network, any number of devices could come online. It is up to us as IT professionals to diligently maintain an accurate host count.

There are many commercial or freely available open-source tools that can identify hosts on a network. Here is one of the first scans I perform on a range of networks to rapidly identify available hosts. There are many subsequent scans that are run, but after years in the field, this is a straightforward method to quickly identify live hosts on a network range.

nmap -sn -n -PE -PS

This scan identifies all of the live hosts it can out of the 254 possible IP addresses in the network range. The flags used for this scan are, in order:

-sn This flag tells nmap not to perform a full port scan. As this scan is aimed at identifying live hosts, we are not initially concerned about the services running on the host.

-n This flag turns off DNS resolution. This scan focuses on speed. Name lookups can add a significant amount of scan time. We can always perform DNS lookups on hosts at a later time.

-PE Perform an ICMP ECHO only scan. This is more commonly known as a ping scan.

-PS In cases where hosts do not respond to ping, we perform a half-open scan or TCP SYN scan against port 80. This port can be changed, and additional ports can be added to increase identification of hosts where ping is disabled. Please note that TCP-SYN scans against SCADA may have unintended consequences. Take precautions when enumerating these devices.

To perform this scan on your IP space, create a text file of newline-separated network CIDR ranges (e.g., networks.txt). Ideally from a Linux device on the management network, run the following command as root (prepend 'sudo ' if you are not root but have the appropriate privilege):

nmap -sn -n -PE -PS -iL networks.txt -oG live.gnmap

This provides a list of live hosts in a grepable format. To extract IP addresses for analysis, the following command saves them into a newline-separated file named targets.txt

cat live.gnmap | awk {'print $2'} | sort | uniq | head -n -1 > targets.txt

This command performs the following steps in order:

  • cat: outputs the contents of live.gnmap to the screen
  • awk {'print $2'}: Using the default separator of white space, print only the second word for each line. In a .gnmap file this will be an IP address or the word ‘nmap’.
  • sort: orders output and puts duplicate entries together
  • Uniq: condenses all adjacent duplicate values into one
  • head -n -1: will cut the last line from the list which will be the dangling ‘nmap’
  • > targets.txt: save the unique, sorted list of IPs to targets.txt.

These two sets of instructions (nmap & cat) create an efficient way to kickstart asset enumeration on your network and a cost-effective way to meet CIS Control #1. From here, feed this list of IPs into your vulnerability scanning tool (e.g., Nessus, Qualys, Nexpose, etc.). You can now track down newly identified assets and ensure they have an “owner” and regularly receive the appropriate security patches.



RiskSense Careers

Looking for a new opportunity in the growing field of Cyber Risk Management?

View Now >