Skip to content
  • to manage a network, you should have an inventory of your network (servers, workstations, network appliances, devices, etc), installed software, applications.
  • we should know if an application is installed locally or hosted by a third-party.
    • their patch levels, e-o-l
    • default passwords
  • Certain applications have administrative portals that can be restricted to only being accessible from specific IP addresses or the host itself (localhost).
  • The enumeration that we perform can be highly beneficial to our clients to help them enhance or start building an asset inventory.
  • we could ID apps that:
    • have been forgotten,
    • demo versions of software that have had their trial license expired and converted to a version that does not require authentication (in the case of Splunk),
    • applications with default/weak credentials,
    • unauthorized/misconfigured applications, and
    • applications that suffer from public vulnerabilities.
  • We can provide this data to our clients as a combination of the findings in our reports (i.e., an application with default credentials admin:admin, as appendices such as a list of identified services mapped to hosts, or supplemental scan data).
  • When we connect to a network,
    • we begin with a "ping sweep" to find the live hosts
    • then, targeted port scanning
    • eventually, deeper port scanning to id running services.
  • Sifting through every IP:PORT would be time consuming.
  • We can use EyeWitness and Aquatone.
    • Both of these tools can be fed raw Nmap XML scan output (Aquatone can also take Masscan XML; EyeWitness can take Nessus XML output) and be used to quickly inspect all hosts running web applications and take screenshots of each
  • The screenshots are then assembled into a report that we can work through in the web browser to assess the web attack surface.
  • This narrows down 100s of host and builds a more targeted list.

Note taking Structure:

External Penetration Test - <Client Name> - Scope (including in-scope IP addresses/ranges, URLs, any fragile hosts, testing timeframes, and any limitations or other relative information we need handy) - Client Points of Contact - Credentials - Discovery/Enumeration - Scans - Live hosts - Application Discovery - Scans - Interesting/Notable Hosts - Exploitation - <Hostname or IP> - <Hostname or IP> - Post-Exploitation - <Hostname or IP> - <Hostname or IP>

Enum Steps

Initial Enum

  • Start with an Nmap scan of common web ports - 80,443,8000,8080,8180,8888,10000
  • then run either EyeWitness or Aquatone or both against the initial scan
  • While reviewing the screenshot report from above of the most common ports, I may run a more thorough Nmap scan against the top 10,000 ports or all TCP ports, depending on the size of the scope.
  • Since enumeration is an iterative process, we will run a web screenshotting tool against any subsequent Nmap scans we perform to ensure maximum coverage.
  • create one methodology that can be applied to all environments we cover
  • we should strive to  provide our clients maximum value
  • Pay attention to the subdomains/vhosts.
  • dev is interesting as it could have debug mode enabled
  • eg: It is not uncommon to find Gitlab instances that allow us to register a user without requiring admin approval to activate the account. We may find additional repos after logging in. It would also be worth checking previous commits for data such as credentials which we will cover more in detail later in this module when we dig deeper into Gitlab.

EyeWitness

  • eyewitness --web -x nmap.xml -d <name>_directory
    • will write to -d directory

Aquatone

  • cat nmap.xml | aquatone -nmap 
    During an assessment, I would continue reviewing the report, noting down interesting hosts, including the URL and application name/version for later. It is important at this point to remember that we are still in the information gathering phase, and every little detail could make or break our assessment. We should not get careless and begin attacking hosts right away, as we may end up down a rabbit hole and miss something crucial later in the report. During an External Penetration Test, I would expect to see a mix of custom applications, some CMS, perhaps applications such as Tomcat, Jenkins, and Splunk, remote access portals such as Remote Desktop Services (RDS), SSL VPN endpoints, Outlook Web Access (OWA), O365, perhaps some sort of edge network device login page, etc.

Your mileage may vary, and sometimes we will come across applications that absolutely should not be exposed, such as a single page with a file upload button I encountered once with a message that stated, "Please only upload .zip and .tar.gz files". I, of course, did not heed this warning (as this was in-scope during a client-sanctioned penetration test) and proceeded to upload a test `.aspx` file. To my surprise, there was no sort of client-side or back-end validation, and the file appeared to upload. Doing some quick directory brute-forcing, I was able to locate a `/files` directory that had directory listing enabled, and my `test.aspx` file was there. From here, I proceeded to upload a `.aspx` web shell and gained a foothold into the internal environment. This example shows that we should leave no stone unturned and that there can be an absolute treasure trove of data for us in our application discovery data.

During an Internal Penetration Test, we will see much of the same but often also see many printer login pages (which we can sometimes leverage to obtain cleartext LDAP credentials), ESXi and vCenter login portals, iLO and iDRAC login pages, a plethora of network devices, IoT devices, IP phones, internal code repositories, SharePoint and custom intranet portals, security appliances, and much more.