amass enum -passive -d target.com -config config.ini -o passive_subs.txt
When targeting a hardened enterprise environment, the front door is almost always locked. The primary production WordPress site is sitting behind a Web Application Firewall (WAF), guarded by strict rate limits, and monitored by a 24/7 Security Operations Center. Pointing an automated scanner at it will get your IP burned in seconds.
But organizations have a bad habit of forgetting their digital past.
They leave `staging-wp.company.com` exposed after a redesign. They forget to decommission `dev-blog-2023.company.com`. These forgotten instances lack WAFs, run outdated plugins, and often share the same underlying database credentials as the production site.
To find these hidden targets, we must become cartographers of the target's attack surface. We need a tool that can scrape, brute-force, and map every subdomain connected to an organization. For this, we turn to the heavy lifter of modern reconnaissance: OWASP Amass.
Disclaimer: The methodologies outlined in this tactical auditing playbook are for offensive security professionals and ethical hackers. Always secure explicit, documented permission before mapping or auditing external infrastructure.
Why OWASP Amass Dominates Subdomain Enumeration
While basic tools like Sublist3r scrape search engines, they barely scratch the surface of a target's infrastructure. OWASP Amass is an in-depth attack surface mapping framework. It doesn't just ask Google; it queries DNS records, scrapes internet archives, interrogates SSL certificates, and queries dozens of threat intelligence APIs simultaneously.
When you are scaling your auditing operations—moving from performing 20 manual checks to running thousands of weekly automated assessments—Amass is the engine that feeds your exploitation pipeline.
Amass utilizes three primary techniques to discover subdomains:
- Passive Discovery: Querying third-party APIs (like VirusTotal, SecurityTrails, and Censys) without directly interacting with the target's DNS servers.
- Active Discovery: Interacting directly with the target infrastructure, requesting zone transfers, and querying their specific name servers.
- Brute Forcing: Using massive wordlists to guess subdomains and resolving them against trusted public DNS resolvers.
Setting Up the Amass Intelligence Engine
Out of the box, Amass is powerful, but to truly unlock its potential for WordPress auditing, you need to configure its data sources. Amass queries dozens of external APIs, but many of the best ones require free registration to access.
Step 1: The `config.ini` Master File
To get the most accurate map of hidden WordPress installations, you must configure your API keys. Create a `config.ini` file in your working directory.
You’ll want to register for free API tiers at the following services and plug them into your configuration:
- SecurityTrails: Excellent for historical DNS data.
- Censys: As we discussed in our Shodan & Censys Playbook, crucial for finding subdomains hidden in SSL certificates.
- AlienVault OTX: Great for finding hostnames associated with threat intelligence feeds.
# Example Amass config.ini snippet
[data_sources]
[data_sources.SecurityTrails]
apikey = "YOUR_API_KEY_HERE"
[data_sources.Censys]
apikey = "YOUR_API_KEY_HERE"
secret = "YOUR_SECRET_HERE"
Step 2: Evading API Throttling with ISP Proxies
Amass is aggressive. When running deep enumerations across multiple data sources, you will quickly hit API rate limits or get IP-banned by search engines and data brokers.
To keep your reconnaissance operations running smoothly without interruption, you must route your Amass traffic through dedicated ISP proxies. Using high-quality, residential or dedicated ISP proxies ensures your queries look like legitimate, distributed traffic rather than a single server aggressively scraping data.
You can configure proxy support directly in the Amass configuration or route the entire terminal session through proxy chains.
Executing the Tactical Audit
With our APIs configured and our proxies routing traffic, it’s time to map the target. We will start with a passive scan to stay completely invisible to the target’s logging mechanisms.
Phase 1: The Passive Baseline
The `enum` subcommand is the core of Amass' discovery capabilities. We use the `-passive` flag to tell Amass not to interact directly with the target.
amass enum -passive -d target.com -config config.ini -o passive_subs.txtThis command cross-references your configured APIs, scrapes search engines, and pulls historical data. The output is a raw list of potential subdomains. Search this list for keywords like `wp`, `blog`, `staging`, `dev`, `new`, and `test`.
Phase 2: Active Brute-Forcing and Alterations
Once the passive scan is complete, we move to active enumeration. This phase interacts with public DNS resolvers to confirm if the subdomains we found are actually alive, and it uses alterations (guessing variations of known subdomains, like `dev1`, `dev2`) to find more.
amass enum -active -d target.com -brute -w /usr/share/wordlists/SecLists/Discovery/DNS/subdomains-top1million-110000.txt -dir amass_output/Visualizing the Attack Surface
Looking at a text file with 5,000 subdomains is overwhelming. To make tactical decisions about which WordPress instances to attack, we need to visualize the relationships between these domains, their IP addresses, and their hosting providers.
Amass stores all of its findings in a local graph database. You can export this data into a format readable by Maltego, a premier open-source intelligence and graphical link analysis tool.
amass db -viz -d3 -dir amass_output/By importing the results into a visualization tool, patterns emerge instantly. You might notice that while the main `target.com` resolves to a highly secure Cloudflare IP range, `wp-staging.target.com` resolves directly to a vulnerable hosting provider.
Handoff: From Cartography to Exploitation
Amass has drawn the map. You now have a curated list of live, active subdomains associated with the target organization, specifically filtering for hidden development and staging environments.
The reconnaissance phase is closing. We have bypassed the heavily armored front door and found an unlocked window in the back alley.
The next step in the methodology is to feed these live, vulnerable subdomains directly into our active scanning tools. Take your compiled list of targets from Amass and move immediately to the WPScan Masterclass Series, where we will initiate advanced user enumeration, plugin vulnerability scanning, and payload deployment.