4.3 Search Engine Reconnaissance, Google Dorking & Information Leakage

4.3 Search Engine Reconnaissance, Google Dorking & Information Leakage

Search engines continuously index the World Wide Web using automated web spiders. In the process, they index not only public marketing pages but also misconfigured staging environments, exposed administrative interfaces, sensitive documents, and leaked credentials. For the CREST Practitioner Security Analyst (CPSA), search engine reconnaissance—often referred to as Google Dorking—along with code repository mining, metadata extraction, and email header analysis, represents a core capability for passive information gathering.

---

1. Search Engine Operators & The Google Hacking Database (GHDB)

Search engines parse web pages and store indexed terms across specific document fields: URL strings, page titles, text bodies, file extensions, and HTTP headers. Standard queries search broad keyword indices; advanced search operators force the search engine to query specific field indices with Boolean precision.

Advanced Search Operators

Advanced Operator Anatomy:
site:target.com  AND  filetype:env  AND  intext:"DB_PASSWORD"
      │                     │                     │
Restricts to Target     Filters to DotEnv       Ensures High-Value Credential
Domain Scope            Configuration Files     String Exists in Plaintext

The Google Hacking Database (GHDB)

Maintained by Offensive Security on Exploit-DB, the Google Hacking Database (GHDB) is an categorized repository of search queries designed to uncover security vulnerabilities, information disclosures, and exposed infrastructure:

1. Directory Traversal & Open Directory Listings:
   • site:target.com intitle:"index of /" "parent directory"
   • Impact: Web servers configured without default index documents (index.html or index.php) often display raw directory trees, allowing testers to browse and download internal files.
2. Exposed Configuration Files & Environment Secrets:
   • site:target.com filetype:env "DB_PASSWORD"
   • site:target.com ext:xml inurl:web.config
   • site:target.com filetype:ini inurl:php.ini
   • Impact: Exposes database credentials, mail server tokens, application secrets, and internal server paths.
3. Public Database Dumps & Log Files:
   • site:target.com filetype:sql ("dump" OR "INSERT INTO")
   • site:target.com filetype:log inurl:error.log
   • Impact: Exposes raw database schemas, customer data, and stack traces revealing software versions and filesystem architectures.
4. Backup Files & Editor Swap Files:
   • site:target.com (ext:bak OR ext:old OR ext:swp OR ext:backup OR ext:zip)
   • Impact: Developers frequently edit production scripts in text editors (like Vim or nano) or create ad-hoc backups (config.php.bak). Web servers do not execute .bak or .swp extensions as PHP; instead, they serve them as plaintext, completely leaking underlying source code and database connection strings.
5. Authentication Portals & Management Consoles:
   • site:target.com (inurl:login OR inurl:admin OR inurl:portal)
   • site:target.com intitle:"Dashboard [Jenkins]"
   • site:target.com inurl:phpmyadmin/index.php
   • Impact: Locates attack targets for password spraying, credential stuffing, or default credential exploitation.

---

2. Code Repository & Paste Site Leakage

Modern software development relies heavily on version control platforms (GitHub, GitLab, Bitbucket). Developers under commercial pressure frequently commit sensitive infrastructure secrets to public repositories.

Types of Leaked Credentials

• Cloud Provider API Keys: AWS Access Key IDs (AKIA[0-9A-Z]{16}), Google Cloud Platform API keys (AIza[0-9A-Za-z\-_]{35}), Azure Storage connection strings.
• Payment & SaaS Tokens: Stripe secret keys (sk_live_[0-9a-zA-Z]{24}), Slack webhooks (hooks.slack.com/services/...), SendGrid API keys.
• Cryptographic Keys: Private SSH keys (-----BEGIN RSA PRIVATE KEY-----), TLS certificates, JSON Web Token (JWT) HMAC signing secrets.
• Database Connection Strings: URIs containing cleartext credentials: postgres://dbadmin:P@ssw0rd123!@db.target.corp:5432/prod_db.

The Danger of Git Commit History

A common misconception among junior developers is that removing a secret in a subsequent commit neutralizes the exposure. In Git, every commit is cryptographically preserved in the repository's .git history:

# A secret committed in revision A remains accessible even after deletion in revision B
git log -p -- path/to/config.json
# An attacker simply checks out the historical commit to recover the active key
git checkout HEAD~1

Automated Secret Detection Tools

• TruffleHog: Scans entire Git commit histories, filesystems, and S3 buckets. Utilizes regular expressions combined with Shannon Entropy analysis to detect high-entropy strings characteristic of encrypted or base64-encoded secrets. Crucially, TruffleHog includes automated live validation modules that query provider APIs (e.g., verifying whether an AWS key is active and determining its IAM permissions).
• Gitleaks: A fast, lightweight, Go-based regex scanner designed for continuous integration (CI/CD) pipelines to intercept secrets before they are pushed to remote repositories.

Paste Sites & Scraping Portals

Sites like Pastebin, Ghostbin, and JustPaste.it serve as temporary staging grounds for code snippets, debug outputs, and malicious threat actor dumps. Analysts monitor paste feeds using automated scraping tools (e.g., pastehunter) to alert whenever target corporate email domains or internal IP ranges are posted.

---

3. Document Metadata Extraction & EXIF Analysis

Every time an employee creates an electronic document or takes a photograph, the originating software embeds metadata into the file structure. Organizations publish thousands of PDF whitepapers, Word manuals, and Excel financial reports to their public websites. Inadvertently, these files contain rich intelligence regarding internal operations.

Public PDF Download ──► [ ExifTool / FOCA Metadata Analysis ]
                                     │
       ┌─────────────────────────────┼─────────────────────────────┐
       ▼                             ▼                             ▼
[ Usernames & Accounts ]    [ Software Versions ]       [ Network Paths & Shares ]
• jsmith                    • Microsoft Word 2016 (v16.0) • \\srv-fs01\finance\2026\
• bwilson                   • Acrobat Distiller 11.0     • \\dc01\sysvol\corp\scripts
• admin_svc                 • LibreOffice 7.2            • PRN-LON-CORP-HP608 (Printer)

Intelligence Disclosed in Office & PDF Metadata

1. Usernames & Email Formats: The Author, Creator, and Last Modified By properties frequently record network login names (jsmith, svc_finance). This eliminates guesswork when building username lists for subsequent password spraying attacks.
2. Software & OS Versions: The Producer and Application tags record exact software versions (e.g., Microsoft Office 2013 on Windows 7), allowing testers to identify vulnerable, unpatched client-side applications for client-side exploitation.
3. Network Paths & File Shares: Universal Naming Convention (UNC) paths embedded in document templates or linked objects reveal internal file server names and directory structures (e.g., \\fs01.corp.local\Shared\HR).
4. Printer Models: Embedded print job properties disclose internal printer models and network printer share names (HP LaserJet Enterprise M608 on prnt-srv-02).

Image EXIF (Exchangeable Image File Format) Analysis

Photographs taken with digital cameras or smartphones embed EXIF metadata:

• Camera Hardware: Make, model, and lens specifications.
• Timestamps: Exact date, time, and time zone of photo creation.
• GPS Geolocation: Precise latitude, longitude, and altitude coordinates.
• Testing Implication: Photographs of corporate data centers, office security badges, or server racks posted to corporate social media or corporate blogs can be analyzed to reveal exact physical coordinates and internal equipment models.

Metadata Extraction Tools

• exiftool: The gold standard command-line utility for reading, writing, and manipulating metadata across hundreds of file types:

# Extract all metadata from a target PDF document
exiftool -a -u -g1 document.pdf

# Extract GPS coordinates from an image
exiftool -GPSLatitude -GPSLongitude server_room.jpg

# Secure sanitization: strip all metadata from a file before publication
exiftool -all= clean_document.pdf

• FOCA (Fingerprinting Organizations with Collected Archives): An automated reconnaissance tool that searches Google, Bing, and DuckDuckGo for files matching specific extensions (.pdf, .doc, .xls, .ppt) belonging to a target domain, downloads them, extracts all metadata, and automatically correlates the findings into an interactive organizational map showing users, servers, printer shares, and software versions.

---

4. Email Header Analysis & Information Disclosure

Email transmission is governed by RFC 5322. As an email message travels from the sender's client across the Internet to the recipient's mailbox, each intermediate Mail Transfer Agent (MTA) inspects the message and prepends routing metadata to the header block.

+-------------------------------------------------------------------------+
|                         RFC 5322 EMAIL HEADER STACK                     |
+-------------------------------------------------------------------------+
[ Received: from mail-in.recipient.com by imap.recipient.com ] ◄── (Top / Most Recent)
[ Received: from relay02.corp.target.com (198.51.100.5) ... ]
[ Received: from internal-ex01.corp.target.com (10.10.20.15) ]
[ Received: from [10.10.50.104] (client-pc.corp.target.com) ]  ◄── (Bottom / Origin)
---------------------------------------------------------------------------
From: CEO <ceo@target.com>
To: Vendor <sales@vendor.com>
Subject: Project Alpha Financials
X-Mailer: Microsoft Outlook 16.0 (Build 14326.20404)
Authentication-Results: spf=pass smtp.mailfrom=target.com; dkim=pass

Reading the Received: Header Chain

• The Golden Rule of Email Analysis: Received: headers are prepended at the top of the header stack by each receiving MTA. Therefore, to trace the chronological path of an email, analysts must read the Received: chain from bottom to top:
  1. The bottom-most Received: header represents the original sending client (MUA) transmitting the message to the first outbound mail server.
  2. Intermediate headers record transmission across edge gateways, spam filters, and cloud relays.
  3. The top-most Received: header represents the final delivery into the recipient's mailbox server.

Information Leaked in Email Headers

1. Internal RFC 1918 IP Addresses: Misconfigured Microsoft Exchange or Postfix servers frequently record the originating workstation's internal private IP address (e.g., Received: from [10.10.50.104]) in the first hop, exposing internal subnet schemes.
2. Internal Hostnames & Server FQDNs: Headers disclose internal mail server names (internal-ex01.corp.target.com) and routing hops that are never published in public DNS.
3. Mail User Agent (MUA) Fingerprinting: Headers such as User-Agent: or X-Mailer: explicitly reveal the client's email application and operating system version (e.g., X-Mailer: iPhone Mail (20G75) or X-Mailer: Microsoft Outlook 16.0).

Email Authentication & Spoofability Assessment

During OSINT and social engineering assessments, penetration testers inspect the target's email security posture to evaluate whether the organization's domain can be spoofed:

• SPF Verification: Inspected in Received-SPF:. If the sending IP is not authorized in the sender's DNS SPF record, the result is Fail or SoftFail.
• DKIM Alignment: The DKIM-Signature: header contains the cryptographic hash and digital signature. The recipient's server queries the public key published under selector._domainkey.domain.com to verify message integrity.
• DMARC Enforcement Analysis: The Authentication-Results: header indicates how the receiving MTA evaluated DMARC policy. If the domain publishes p=none, email servers will not reject or quarantine spoofed messages, allowing penetration testers to demonstrate email impersonation vulnerabilities during authorized social engineering simulations.