What is Web Reconnaissance?
Web reconnaissance is the process of gathering information about a target web application and its infrastructure before attempting any exploitation. Effective web recon uncovers:
- Hidden directories and files
- Exposed configuration files
- Backup files containing source code
- Administrative interfaces
- Sensitive documents indexed by search engines
Two of the most useful techniques for web reconnaissance are directory brute-forcing with DIRB and Google dorking with advanced search operators.
DIRB — Directory Brute-Forcing
DIRB (Directory Buster) is a web content scanner included in Kali Linux. It discovers existing and hidden web objects by launching a dictionary-based attack against a web server and analyzing the HTTP responses.
DIRB works by taking a wordlist of common directory and file names, appending each one to the target URL, sending HTTP requests, and recording which paths return valid responses.
# Basic scan against a target domain
dirb http://domain.com
# Scan with a custom wordlist
dirb http://domain.com /usr/share/wordlists/dirb/big.txt
# Scan with a specific file extension
dirb http://domain.com -X .php,.txt,.bak
# Scan against HTTPS
dirb https://domain.com
# Save results to a file
dirb http://domain.com -o results.txt
What DIRB typically finds:
Example DIRB Results:
http://domain.com/admin/ → Administrative panel
http://domain.com/backup/ → Backup files directory
http://domain.com/config.php.bak → Exposed backup config file
http://domain.com/.git/ → Exposed Git repository
http://domain.com/upload/ → File upload directory
http://domain.com/phpinfo.php → PHP configuration details
How DIRB Works Internally
Wordlist Entry: "admin"
|
DIRB sends: GET http://domain.com/admin/ HTTP/1.1
|
Server responds: 200 OK → directory exists, record it
301 Redirect → follow and record
403 Forbidden → exists but access denied, record it
404 Not Found → skip
Even a 403 response is valuable — it confirms the path exists even if access is currently denied, which may indicate a misconfigured access control.
Google Dorking — Advanced Search Operators
Google dorking uses Google's advanced search operators to find information about a target that is publicly indexed but not prominently visible. This is a form of passive reconnaissance — no direct interaction with the target server occurs.
A comprehensive reference for all Google dork operators: https://github.com/cipher387/Advanced-search-operators-list
Finding File Types
The filetype: operator restricts results to a specific file extension:
# Find PDF documents mentioning "hacking"
filetype:pdf learn hacking
# Find PowerPoint presentations
filetype:ppt security architecture
# Find Excel files (potentially containing data)
filetype:xls password
# Find backup files
filetype:bak site:target.com
High-value file types to search for:
| File Type | Potential Value |
|---|---|
.pdf | Policies, architecture docs, contracts |
.xls / .xlsx | Employee data, financial records |
.sql | Database dumps |
.bak | Backup files containing source code or configs |
.log | Application and server logs |
.env | Environment files containing API keys or credentials |
.config | Configuration files with connection strings |
Restricting to a Specific Domain
The site: operator limits results to a specific domain:
# Find everything Google has indexed for a domain
site:target.com
# Find specific content within a domain
site:target.com admin
# Find subdomains
site:*.target.com
# Combine with filetype
site:target.com filetype:pdf
Combining Operators for Targeted Searches
Google dork operators can be combined for precise targeting:
# Find login pages on a target
site:target.com inurl:login
# Find PHP pages with admin in the URL
site:target.com inurl:admin filetype:php
# Find configuration files
site:target.com ext:xml OR ext:conf OR ext:cnf
# Find pages with specific sensitive text
site:target.com intext:"index of" password
# Find exposed directory listings
intitle:"index of" site:target.com
# Find SQL files on a site
site:target.com filetype:sql
Common High-Value Google Dorks
| Dork | What it Finds |
|---|---|
intitle:"index of" | Open directory listings exposing file trees |
inurl:"/phpmyadmin/" | Exposed database administration panels |
inurl:wp-config.php.bak | WordPress configuration backups |
filetype:env DB_PASSWORD | Environment files with database passwords |
intext:"SQL syntax" site:target.com | SQL errors leaking database structure |
intitle:"dashboard" inurl:jenkins | Exposed Jenkins CI/CD dashboards |
Passive vs. Active Reconnaissance
It is important to understand the distinction between passive and active web reconnaissance:
Passive Reconnaissance (no target interaction):
├── Google dorking
├── Shodan searches
├── WHOIS lookups
├── DNS enumeration from public records
└── Certificate transparency log searches
Active Reconnaissance (direct target interaction):
├── DIRB directory scanning
├── nmap port scanning
├── nikto web server scanning
└── spider/crawling the target application
Passive reconnaissance leaves no trace on the target's servers and is generally safe to perform without authorization. Active reconnaissance sends requests directly to the target and may be logged, detected, or in some jurisdictions require authorization.
Building a Complete Web Recon Workflow
1. Passive Recon
├── Google dorking for files, directories, subdomains
├── Shodan for exposed services and open ports
└── Certificate transparency for subdomain enumeration
2. DNS Enumeration
├── dnsenum / dnsrecon for zone transfers and record mapping
└── Subfinder / Amass for subdomain discovery
3. Active Directory and File Discovery
├── DIRB for hidden paths and files
├── Gobuster / ffuf for faster brute-forcing
└── Nikto for web server misconfiguration detection
4. Application Mapping
└── Burp Suite spider and manual browsing for full endpoint mapping
Thorough reconnaissance before exploitation ensures you have a complete picture of the attack surface and reduces the risk of missing critical vulnerabilities.