Screenshotting¶

Screenshotting means automatically taking screenshots of tons of web pages to quickly spot interesting targets. When you've got hundreds or thousands of subdomains, you can't check each one manually. Screenshots give you a visual summary of the attack surface - you can scan through images way faster than visiting each URL.

1. Introduction to Screenshotting¶

The goal? Triage a massive URL list efficiently. Convert pages into images and you can quickly scan for:

• Login Portals: Identifying authentication interfaces is a top priority.
• Default Application Pages: Spotting default installations of Jenkins, Tomcat, Grafana, etc., which may have default credentials or known vulnerabilities.
• Directory Listings: An Index Of page indicates a misconfiguration.
• Error Pages: Errors can leak framework versions, file paths, and other sensitive information.
• Old or Forgotten Applications: Visual inspection can uncover legacy applications that are often less secure.
• 404 Pages vs. Live Apps: Quickly separate dead pages from live ones.

2. Core Methodology¶

The screenshotting workflow is straightforward and designed for automation.

1. Prepare Input: Start with a clean, sorted list of URLs. This list is typically the output of subdomain enumeration and web server discovery tools.
2. Run a Screenshotting Tool: Use a command line tool to iterate through the list. The tool uses a headless browser (like Chrome/Chromium) to visit each URL, render the page, and save a screenshot.
3. Review the Output: The tool will generate a directory of images, usually accompanied by an HTML report for easy viewing.
4. Prioritize Targets: Based on the visual evidence, identify the most interesting applications and prioritize them for in-depth manual testing.

Preparing the Input List¶

A good input list is key. It should contain full, valid URLs. Tools like httpx are perfect for this.

# Take a list of subdomains and probe for live web servers
cat subdomains.txt | httpx -silent > urls.txt

# The output urls.txt will look like:
# http://www.example.com
# https://www.example.com
# http://app.example.com:8080
# https://api.example.com

3. Key Screenshotting Tools¶

Several excellent open-source tools automate this process.

gowitness¶

A fast and flexible screenshotting tool written in Go. It's highly configurable and can generate a convenient report.

Installation:

go install github.com/sensepost/gowitness@latest

Usage:

# Take screenshots from a file containing URLs
gowitness file -f urls.txt

# Specify a different output directory
gowitness file -f urls.txt --destination /path/to/output

# Control the number of concurrent threads
gowitness file -f urls.txt -t 50

# Add extra delay for single-page applications (SPAs) that need time to render
gowitness file -f urls.txt --delay 5

After running, gowitness creates a screenshots directory with all the images and an gowitness.html report file.

aquatone¶

The classic screenshotting tool. While gowitness is often faster, aquatone is still widely used and produces excellent reports.

Installation: Download the binary from the releases page on GitHub.

Usage: aquatone takes input from stdin, making it easy to pipe into.

# Pipe the output of httpx directly into aquatone
cat subdomains.txt | httpx -silent | aquatone

# Set the output directory
cat urls.txt | aquatone -out /path/to/output

# Set the number of threads
cat urls.txt | aquatone -threads 20

webscreenshot¶

Another powerful tool that can use different browser engines and supports more advanced configurations.

# Basic usage with a list of URLs
webscreenshot -i urls.txt

# Use a proxy for requests
webscreenshot -i urls.txt --proxy http://127.0.0.1:8080

4. Analyzing the Results¶

Once the screenshots are generated, the manual review process begins.

• Open the HTML Report: All major tools generate a report that displays all the screenshots on a single page. This is the most efficient way to review.
• Look for Anomalies: Your eyes will quickly learn to pick out interesting patterns. A default Tomcat page, a PHP info page, or a login form will stand out from standard corporate landing pages.
• Group Similar Pages: The reports often group visually similar pages, which helps you ignore duplicates (e.g., hundreds of identical 404 pages).
• Check HTTP Status and Titles: The reports also include metadata like the HTTP status code, page title, and content length, which provide additional context. A 403 Forbidden page with a non-standard title is worth investigating.

5. Advanced Tips¶

• Customize User-Agent: Some websites serve different content based on the User-Agent. You can configure your screenshotting tool to mimic a common browser or a mobile device.

  # gowitness example
  gowitness file -f urls.txt --user-agent "Mozilla/5.0 (iPhone; CPU iPhone OS 13_5 like Mac OS X) ..."
  

• Adjust Viewport Size: Change the resolution of the headless browser to simulate different screen sizes (e.g., desktop vs. mobile). This can sometimes reveal different application layouts or functionality.
• Handle Authentication: Screenshotting tools generally don't handle authentication well. If many pages redirect to a single sign-on (SSO) login, you may need to manually investigate those applications.
• Integrate into a Workflow: Screenshotting should be an automated step in your recon pipeline.

  # Example Workflow
  subfinder -d example.com -silent | httpx -silent | gowitness file -f -
  

6. Notes and Pitfalls¶

• Headless Browser Detection: Some advanced web applications or WAFs can detect and block headless browsers. This may result in blank or error-page screenshots.
• Rendering Time: Modern JavaScript-heavy applications (SPAs) can take several seconds to fully render. If you get blank screenshots, increase the delay/timeout value in your tool.
• Resource Intensive: Running a headless browser for every URL is CPU and memory intensive. Don't use an excessive number of threads on a low-resource machine.
• False Negatives: A tool might fail to take a screenshot for various reasons (network error, SSL error, timeout). Don't assume a failed screenshot means the site is down; it may warrant a manual check.

7. Quick Reference Table¶