Apache default site image

You are on a Red Team internal engagement and find an IP with a webserver running. However, you’re unsure of the Fully Qualified Domain Name(FQDN) it’s hosting. Without knowing the FQDN we cannot access any sites hosted on the webserver, besides the default site. Now you are stuck staring at the default IIS or Apache landing page. How can we access the websites when we don’t have the FQDNs?

The Challenge

Whenever you make a web request, part of the web request contains the “HOST:” option in the HTTP Header. The “HOST:” option is the FQDN; for example, “HOST: yahoo.com.” The Header option tells the web service to use the “VHost” settings matching the FQDN. The default page is displayed if you do not provide an FQDN(using just the IP), or a non-existent FQDN.

Let’s look at the response difference we get when using the FQDN vs the IP when making a request to Yahoo’s webserver.

curl command of yahoo.com
curl command of Yahoo webserver IP

You can see in the above images that the responses are different based on the host options used. So we need to know the FQDN of a website hosted on a webserver before we can access that site.

To find the FQDNs we will brute-force the “HOST:” header options to find the VHosts configured on a webserver.

Why not just brute-force the DNS?

You may be thinking, “Why not just brute-force the DNS records instead?” Glad you asked! The short answer is you may miss websites hosted on the webserver. Here are some reasons why sites will be missed.

  • No access to the targets network DNS server.
  • Split-brain DNS, and you are on a external network. A target may have a website hosted on a server that is Internet-facing, but DNS records are on the internal DNS server only. So only internal company employees can resolve the FQDN to the website.
  • Find old and Dev websites. It is not uncommon to find temporary websites that a Dev Team or System Admin put up to test and then forgot about. They likely only configured their local systems “hosts” file for their test, so no DNS records.

GoBuster does not cover this,

Show More...

Brute-forcing the VHost can be done with a tool called GoBuster. However, GoBuster’s VHost brute-forcing has a flaw; you cannot dictate an IP of where to send the requests. So if I want to brute-force the subdomains hosted on the server, a DNS record for the subdomain must exist.

You can get around this shortcoming by installing a local DNS server and configure all subdomains to resolve to the same target IP. However, this process is more time-consuming than the method I propose.

VHost Brute-Force Tactic

To brute-force a webservers VHosts, we can use the curl command. The curl command allows us to dictate a host option and the IP address to resolve the FQDN. Here is an example below.

# curl http://fqdn --resolve "fqdn:port:IP" -H "HOST: fqdn"
curl "http://test.example.com" --resolve "test.example.com:80:10.1.1.30" -H "HOST: test.example.com"

Now that we have the tactic of enumerating the webserver’s VHosts, we can script the testing procedure.

The brute-force procedure goes like this.

  1. Curl the IP without an FQDN, take note of the Content-Length in the returned message response.
  2. Curl the IP with the FQDN, and compare the returned Content-Length to the first request.
  3. If the returned Content-Lengths do not match, then you discovered a website.

I have written up a quick script to weaponize this procedure. The script is available on my GitHub.

wget https://raw.githubusercontent.com/Brets0150/CG_RedTeamTools/main/cg_web_sub_enum.sh
My script running example.

Happy Hunting!

Related posts:

Linux BackdoorRedTeam Tip: Hiding Cronjobs Getting My Certified Ethical Hacker v10 Cert Lab: Breaking Guest WiFi CVE-2021-29255 Vulnerability Disclosure Lab: Exploiting CVE-2021-29255 Red Team Tools: Reverse Shell Generator Evil-winrmBypass 2FA on Windows Servers via WinRM HTB Walkthrough: Support How to Stay on Top of Cybersecurity News Bash LogoTips for Writing Secure Bash Scripts