Welcome to Part 2 of Subdomain Attack Surface Discovery! If you haven’t read Part 1, I would do that first… Otherwise confusion may follow. Assuming you are continuing after Part 1, let’s get back to our list of subdomains.

But first, a much-needed disclaimer.

DISCLAIMER: The tools and techniques in this post should only be run against hosts that you have permission to scan!

Ok, back to business.

In order to start taking a deeper look at the Internet attack surface to see what’s out there, we need to perform some light enumeration of the targets. My chosen tool for this is Nmap. Some have suggested the use of masscan for this instead of Nmap. I like masscan for extremely large quantities of hosts, but Nmap tends to work for me just fine for a “normal” number of hosts.

Generally, I only scan for the top 20 ports (nmap Top 20) to keep the scan quick and not to attract unwanted attention, but you can tailor this to fit your recon style.

Command: “nmap -vvv -sS –open –top-ports 20 –max-retries 2 -iL import_filename.txt -oA export_filename”

Let’s quickly dissect this nmap command. The “-vvv” puts Nmap in “very verbose” mode, meaning that there will be a lot of output and feedback. The “-sS” tells Nmap to run a more stealthy SYN scan. “–open” tells Nmap to only show open ports. “–top-ports 20” tells Nmap to only scan for the most common 20 ports – these are generally all we need for this initial reconnaissance. The “–max-retries 2” tells Nmap to stop probing a target port if a certain number of “retries” occurs. In a nutshell, this will speed up the scan. “-iL import_filename.tx” is the list of IP addresses and hostnames that you want to scan. From Part 1, this is the list of subdomains we discovered. Finally, “-oA export_filename” is the export file name. This will send the output of Nmap to 3 different file formats that can later be used.

Here is some of the information returned from the Nmap scan:

Here we see some standard web ports such as 80 and 443. These ports are hosting web services. Sometimes you will find more peculiar ports open, such as the below output:

Hosts such as this should be looked at more closely to ensure the open ports have a good reason for being open (e.g., providing services to the end-user).

Next, I run my favorite recon tool – Eyewitness. Eyewitness was written in Python and it simply takes screenshots of websites, and RDP and VNC login screens, and is a GREAT tool for quickly figuring out which hosts and subdomains look interesting and warrant further “review”. Let’s run an Eyewitness “scan”.

Since Eyewitness will navigate to all the subdomains and attempt to screenshot them, this tool can take quite a while to complete. Usually I will start an Eyewitness enumeration and go do something else for a few hours (or the day).

Command: “python EyeWitness.py –all-protocols -x nmap_file –timeout 15 -d output_file”

The Nmap input file should be the output of our Nmap scan from above. The output file name can be named anything.

Eyewitness reports output in HTML format, so you can open the result files in a web browser. After open the results in Firefox, I can see that various types of web pages were discovered. What we want to look for here are login portals, misconfigured web pages or applications, weird errors, or obvious potential issues such directory indexing and SQL errors.

Let’s take a look at our results. This is the type of stuff to look for:

Login portals, such as these:

Error Messages / Strange Output, such as these:

Misconfigured Web Pages, such as the below:

Or, Information about the backend infrastructure, such as the below:

These are only examples – Anything that looks out of the ordinary or peculiar should be inspected further. Usually this combination of tools and techniques can help you get a quick overview of the Internet attack surface of your organization, and can also be used in bughunting.

Please leave comments if anything is incorrect or if you have a better idea for the execution of these techniques!

I am currently working on a Python script that automates this tool chain and will write about it in the another post.. I know there are many tools and scripts out there that do similar recon, but I always find it safer to rely on a tool chain instead of a single tool that does it all – you never know when the developer stops supporting the “do-it-all” tool. With a tool chain, you can also include new tools and scripts (or take them out) in the chain any time you need!