Recon Methods Part 5 – Traffic on the Target

In the previous parts of this series, we looked at different ways to gather intelligence on a target without generating traffic on their hosts through manual processes and automated tools. Today, we will start to ramp up interactions with the target hosts while remaining largely under the radar. We will use EyeWitness to record interactions with target web hosts, determine internal username formats through hosted file metadata, search for internal domain names through ADFS and Outlook Web Access sites, and perform port scans of external hosts through third party sites.

Links to posts in this series: 

Recon Methods Part 1 – OSINT Host Discovery

Recon Methods Part 2 – OSINT Host Discovery Continued

Recon Methods Part 3 – OSINT Employee Discovery

Recon Methods Part 4 – Automated OSINT

EyeWitness

The first tool we’ll talk about is EyeWitness. This tool is great for quickly enumerating attack surface with minimal interaction on the target hosts. EyeWitness records interactions with HTTP(S), VNC, and RDP hosts including a screenshot of the service and HTTP headers. You can provide EyeWitness with a list of IP addresses, hostnames, and even xml output from Nmap. Once the scan is complete, EyeWitness creates a report categorized by the response with a screenshot of the service and the HTTP headers. An example command can be seen below.

#Runs EyeWitness for web hosts using the 'urls' file and outputting the report to the <target> directory
python EyeWitness.py --web -f <absolute_path>/urls --prepend-https --threads 10 --max-retries 2 -d <target>

File Metadata

Another great source of data is hosted file metadata. When a company hosts files such as PDF, DOC, XLS, and PPT, the files often have metadata embedded that includes the author, the file path it was originally saved to, and the software that created it. As an attacker, we can glean employee names, usernames from the file path, and operating systems/document creation suite versions from this information.

To find and download documents, we use the Google Chrome add-on LinkKlipper. Link Klipper will grab all of the URLs from a page and save them to a CSV file. Once this is installed, we search Google and Bing with the following search. On each result page, click the Link Klipper icon and save to CSV.

site:example.com (filetype:pdf OR filetype:doc OR filetype:xml OR filetype:txt OR  filetype:xls OR filetype:ppt OR filetype:pps OR filetype:docx OR filetype:wps OR filetype:rtf OR filetype:csv OR filetype:pptx OR filetype:xlsx OR filetype:xlr)

The CSV files that are created will have a lot of extra lines and fields included. We combine all of the CSV files into one file and then use the following one-liner to grep out a list of URLs. Once a list of URLs is created, downloading the files is as simple as using a bash for loop to download with wget. An example of the for loop can also be seen below.

grep example.com links.csv | grep -v google | grep -v bing | grep '"' | cut -d '"' -f 2 | sort -u >> links.txt
for i in $(cat links.txt); do wget -u "<user-agent string>" $i; done

Now that we have the files downloaded, it’s time to extract the metadata. We use PowerMeta to extract the metadata into a CSV file that can be imported into Excel. PowerMeta has the ability to automate the process of finding and downloading documents from a target as well. However, in our experience, we’ve found that Bing and Google will start blocking the requests due to automated search detection and will not return the same amount of results when using PowerMeta (YMMV). Clone the repo and run the following command from a Powershell prompt to extract all metadata from the downloaded documents.

Import-Module .\\PowerMeta.ps1; ExtractMetaData -OutputDir <path_to_downloaded_docs>\\downloads_folder -ExtractAllToCsv metadata.csv

Internal Domain Name Disclosure

A good target for password spraying attacks are Microsoft services tied to Active Directory such as Active Directory Federated Services (ADFS) and Outlook Web Access (OWA). An attacker will need to find the internal domain name for password attempts. On-premises ADFS portals will often display
an error message stating the internal domain name. An attacker can enter garbage in both fields and then find the expected internal domain name from the error message or through an autocorrection in the username field.

While OWA services are becoming less common, they are still available so make sure to check for it. Very often we will see the autodiscover service and Exchange Web Services (EWS) exposed as they are turned on by default. Both of these services support NTLM authentication when you visit the following URLs.

During the NTLM authentication process, the response will contain the internal hostname as well as the internal domain name. There are two ways to extract the internal domain from a request. The first is the Metasploit Framework module owa_login. You’ll need to supply a throwaway username and password as well as the OWA URL. The module will extract the domain name and display it to the screen. An alternate way of pulling the domain name and internal hostname of the OWA server is through the following Curl command (Thanks @Wh1t3Rh1n0). Note: the Curl command will also work with the EWS URL.

curl -u guest:password --ntlm -vs 'https://<owa_url>/autodiscover/autodiscover.xml' 2>&1 | grep -E '> Authorization: NTLM.{50,}' | cut -d ' ' -f 4 | base64 -d | hexdump -C

Be aware that NTLM authentication includes your host’s name in the request. Make sure to change your host name to something nondescript before making the requests.

Third-Party Port Scanning

While Nmap works just fine in most cases, modern firewalls can start rate-limiting requests or dropping them altogether when the IP address of our VPS is blacklisted for scanning too quickly. One way around this is to use a third-party resource. While this isn’t always the case, we have had cases where going through an online scanning service gave better results than our Nmap/Masscan scans. These third-party sources also have the added benefit of masking the identity of who requested the scan. A list of easy to use scanning sources can be seen below.

• Geekflare has a whole suite of tools that are free to use including a port scanner.
  Results seem to be limited to common ports.
• T1 Shopper is a great resource. It allows a full 65k port scan and returns the results pretty
  quickly. The output is very verbose so you will need to copy the results offline and grep out the open ports.
• IPv6 Scanner is another site that scans for a set of common ports. This site allows IPv4 or IPv6
  addresses to be scanned.
• HackerTarget has a large suite of scanning tools including a port scanner. This
  site requires a subscription to use the full range of tools.

Conclusion

In this series, we’ve shown how to start with a company name or domain and build a list of subdomains, map out the attack surfaces of their internet-facing hosts, build a list of employees and email addresses, and start building a list of internal domain names and users all while generating little to no conspicuous traffic on that target’s hosts (with the exception of the third-party port scanning). While this series did not cover every possible method of recon, this methodology gives a very strong foundation for finding avenues into a target network through their external hosts and employees.