Post cover image
Phone Numbers and Emails to Hidden Subdomains

June 16, 2026

Phone Numbers and Emails to Hidden Subdomains: The OSINT Acquisition Pipeline That Uncovered a…

A deep technical blog on using phone numbers and email addresses to discover hidden domains, subdomains, and attack surface — with…

MD Mehedi Hasan

18 min read

A deep technical blog on using phone numbers and email addresses to discover hidden domains, subdomains, and attack surface — with real-world techniques you can use today.

Foreword: Why I Wrote This

In bug bounty and security research, one of the biggest challenges is not finding vulnerabilities — it's finding the right attack surface.

Many researchers start with traditional reconnaissance: collecting subdomains, checking DNS records, and running automated tools. While these methods are valuable, they often miss assets that are not directly connected to the primary domain.

This is where OSINT becomes powerful.

A simple phone number or email address can become a starting point for discovering hidden digital assets:

  • A company email can reveal related domains and third-party services
  • Public profiles can expose forgotten infrastructure
  • Developer footprints can reveal technology stacks and assets
  • Business records can connect organizations to previously unknown domains

The idea behind this research is simple:

Public information creates relationships, and relationships create attack surface.

This blog explores an OSINT-driven acquisition workflow for connecting phone numbers and email addresses with domains, subdomains, and external assets. These techniques are useful for authorized security testing, bug bounty research, and improving reconnaissance skills.

The goal is not just to collect more assets — it is to understand how different pieces of public information connect together to reveal a larger security picture.

Part I: The Conceptual Framework — Why This Works

The Problem with Traditional Subdomain Discovery

Traditional subdomain discovery relies on one thing: the DNS namespace is enumerable. You either brute-force it (guess names) or query passive sources (CT logs, passive DNS).

Both approaches share a fundamental limitation: they only find subdomains that are publicly resolvable or historically logged.

Here's what they miss:

  • Private/internal domains (e.g., internal.company.com that only resolves on the corporate VPN)
  • Pre-production domains that were registered but never deployed to DNS
  • Acquired company domains that aren't linked from the parent
  • Domains used for third-party services (e.g., company.slack.com, company.atlassian.net)
  • Personal domains used by employees for work purposes

The Email-to-Domain Bridge

Every email address user@domain.com tells you:

  1. The domain exists (obvious, but foundational)
  2. The domain is actively used (someone sent mail from it)
  3. The domain has a user (potential credential, potential account)
  4. The domain is connected to services (GitHub, Slack, Jira, AWS, etc.)

When you collect thousands of email addresses associated with a company, and you extract every domain from those emails, you build a corporate domain graph that DNS brute-force can never replicate.

The Phone-to-Domain Bridge

Every phone number +1 (415) 555-0199 tells you:

  1. The company exists at a physical location (office, data center)
  2. The company uses a specific VOIP provider (Twilio, RingCentral, Vonage)
  3. The company has registered infrastructure (WHOIS records, business registries)
  4. The company has extensions (which map to departments, which map to services)

When you collect phone numbers and reverse-search them, you find domains that were registered with those same phone numbers — often from before the company had a proper security team.

Part II: Phone Number → Domain Discovery

Phone numbers are a persistent identifier. Companies change domains more often than they change phone numbers. A domain registered in 2005 with a phone number is still associated with that company today — even if the domain is forgotten.

Every domain registration includes a phone number. SecurityTrails, WhoisXMLAPI, and DomainTools allow you to search by phone number to find all domains registered with it.

#!/bin/bash
# phone-to-domain.sh - Find domains registered with a specific phone number
PHONE="$1"

# Using WhoisXMLAPI (paid, but worth it)
curl -s "https://www.whoisxmlapi.com/whoisserver/WhoisService?apiKey=$API_KEY&domainName=$PHONE&outputFormat=JSON" | \
    jq -r '.WhoisRecord.registryData.registrarName // empty'

# Using DomainTools (requires API key)
curl -s "https://api.domaintools.com/v1/$PHONE/domains/" \
    -u "$DOMAINTOOLS_USER:$DOMAINTOOLS_KEY" | \
    jq -r '.response.domains[]'

# Manual: Reverse WHOIS lookup on SecurityTrails
# https://securitytrails.com/list/phone/$PHONE

What this finds: Every domain that was ever registered with that phone number — including domains for subsidiaries, defunct products, and personal projects.

Every corporation in the US registers with a state business registry. These registries include phone numbers. You can search by phone number to find all corporations registered under that number.

# OpenCorporates API
curl -s "https://api.opencorporates.com/v0.4/companies/search?q=$PHONE&api_token=$TOKEN" | \
    jq -r '.results[].company.name'

# State-specific registries (examples)
# California: https://businesssearch.sos.ca.gov/
# Delaware: https://icis.corp.delaware.gov/
# Texas: https://mycpa.cpa.state.tx.us/coa/

What this finds: Legal entities, DBAs, and subsidiaries that aren't publicly linked to the parent company.

Technique 3: Phone Number Reverse Lookup Services

# Twilio Lookup API
curl -s "https://lookups.twilio.com/v1/PhoneNumbers/$PHONE?Type=carrier&Type=caller-name" \
    -u "$TWILIO_SID:$TWILIO_TOKEN" | \
    jq '.carrier.name, .caller_name.caller_name'

# Numverify
curl -s "https://apilayer.net/api/validate?access_key=$KEY&number=$PHONE" | \
    jq '.carrier, .location, .line_type'

# Manual: Whitepages reverse lookup

What this finds: The carrier name (VOIP provider), which tells you what infrastructure to attack, and sometimes the registered business name.

Technique 4: Breach Data Phone Search (Authorized Only)

If you have authorized access to breach databases:

# Dehashed search by phone
curl -s "https://api.dehashed.com/v1/search?query=phone:$PHONE&size=1000" \
    -u "$EMAIL:$API_KEY" | \
    jq -r '.entries[].domain' | sort -u

What this finds: Every domain where an account was registered with that phone number — including internal systems, VPN portals, and employee benefits portals.

Real-World Example: Phone-to-Domain Discovery

Target: Large healthcare tech company. Scope: *.healthtech.com.

I found the company's main phone number from their contact page: +1 (617) 555-0100.

I ran a WHOIS phone number search:

# SecurityTrails reverse WHOIS by phone
# Result: 47 domains registered with +1.617.555.0100

Among those 47 domains:

None

Critical find: internal-healthtech.com was registered with the same phone number but was not on any subdomain list. It resolved to a private IP range (10.x.x.x) from the outside, but it hosted an internal tool portal accessible via VPN. The VPN wasn't in scope either — until I found it through the phone number.

Part III: Email Address → Domain Discovery

Every email address user@domain.com is a direct pointer to a domain. When you collect thousands of emails associated with a target company, you build a comprehensive domain inventory.

Technique 1: Cross-Company Email Analysis

When employees from Company A and Company B communicate, email headers reveal both domains. If you find john@company-a.com and jane@company-b.com in the same email chain, they're connected.

# From breach data (authorized): find which domains appear alongside the target domain
# From leaked email threads: extract all sender/receiver domains
# From public mailing lists: find cross-company email patterns

What this finds: Business relationships — partners, vendors, clients, and acquired companies.

Hunter.io allows you to search by domain AND by company name. The company name search returns emails from multiple domains:

# Search by company name
curl -s "https://api.hunter.io/v2/company/domain?company=healthtech&api_key=$KEY" | \
    jq -r '.data.domains[]'

# Result:
# healthtech.com
# healthtech.io
# healthtech.dev
# healthtech-careers.com
# healthtech-benefits.com

What this finds: All domains associated with a company name, including HR, benefits, and internal tool domains.

Technique 3: Email-to-GitHub-to-Domain Chain

This is one of the most powerful discovery chains in bug hunting:

  1. Collect employee email: alice@healthtech.com
  2. Search GitHub for that email: finds Alice's GitHub account
  3. Look at Alice's GitHub repos, commits, and organizations
  4. Find references to other domains in code, configs, and commit messages
#!/bin/bash
# email-to-github-to-domains.sh
EMAIL="$1"

# Step 1: Find GitHub account
echo "[*] Searching GitHub for $EMAIL..."
curl -s "https://api.github.com/search/users?q=$EMAIL+in:email" | \
    jq -r '.items[].login' > github_users.txt

# Step 2: For each GitHub user, find their repos and orgs
while read USER; do
    echo "[*] Checking user: $USER"

    # Get user's repos
    curl -s "https://api.github.com/users/$USER/repos?per_page=100" | \
        jq -r '.[].full_name' >> repos.txt

    # Get organizations
    curl -s "https://api.github.com/users/$USER/orgs" | \
        jq -r '.[].login' >> orgs.txt

    sleep 2  # Rate limiting
done < github_users.txt

# Step 3: Search repo contents for domain references
while read REPO; do
    echo "[*] Searching repo: $REPO"

    # Search code for domain patterns
    curl -s "https://api.github.com/search/code?q=repo:$REPO+healthtech" | \
        jq -r '.items[].html_url' >> code_refs.txt

    # Search commit messages for domain references
    curl -s "https://api.github.com/search/commits?q=repo:$REPO+healthtech" | \
        jq -r '.items[].html_url' >> commit_refs.txt

    sleep 2
done < repos.txt

What this finds: Internal domains referenced in code comments, config files, READMEs, and commit messages.

Technique 4: Email-to-Breach-to-Domain Correlation

When an employee's email appears in a breach, you can see what service they were using and what domain was involved:

# Dehashed query (authorized)
curl -s "@healthtech.com&size=10000">https://api.dehashed.com/v1/search?query=email:@healthtech.com&size=10000" \
    -u "$EMAIL:$API_KEY" | \
    jq -r '.entries[] | "\(.domain) \(.email) \(.password)"' | sort -u

# Extract unique domains
curl -s "@healthtech.com&size=10000">https://api.dehashed.com/v1/search?query=email:@healthtech.com&size=10000" \
    -u "$EMAIL:$API_KEY" | \
    jq -r '.entries[].domain' | sort -u > breached-domains.txt

What this finds: Domains where employees had accounts — including personal projects, side businesses, and services they used for work purposes (sometimes on unmanaged infrastructure).

Technique 5: Email-Specific Subdomain Discovery

Services like Have I Been Pwned, Firefox Monitor, and custom tools can tell you which subdomains of a company have accounts registered:

# Check if a subdomain has active accounts
# For Office 365: login.microsoftonline.com will reveal tenant info
# For Atlassian: company-name.atlassian.net
# For Slack: company-name.slack.com
# For GitHub: github.com/orgs/CompanyName

# Using emails to discover the company's Atlassian instance:
for email in $(cat emails.txt); do
    # Check for Atlassian account
    response=$(curl -s -o /dev/null -w "%{http_code}" \
        "https://healthtech.atlassian.net/rest/analytics/1.0/user/is-licensed?username=$email")

    if [ "$response" == "200" ] || [ "$response" == "401" ]; then
        echo "Atlassian domain found: healthtech.atlassian.net"
        break
    fi
done

Real-World Example: Email-to-Domain Discovery Chain

Target: Financial services company finsecure.com.

I collected 2,400 emails using Hunter.io, theHarvester, and LinkedIn scraping. Among them was devops@finsecure.com.

GitHub search on devops@finsecure.com: Found a GitHub account finsecure-devops with a private repo (misconfigured visibility).

Repo contents revealed:

  • deploy.config with DB_HOST=mariadb.internal.finsecure.com
  • terraform.tf with bucket = "finsecure-terraform-state"
  • README.md with See internal docs at docs.internal.finsecure.com

New domains discovered:

  • internal.finsecure.com — Not in any CT log or DNS record
  • docs.internal.finsecure.com — Subdomain of the above
  • mariadb.internal.finsecure.com — Internal database hostname
  • finsecure-terraform-state.s3.amazonaws.com — S3 bucket with terraform state

The S3 bucket was publicly listable. It contained AWS access keys. The AWS keys gave access to the production environment.

Chain: 1 email → 1 GitHub account → 1 repo → 4 new domains → 1 S3 bucket → AWS root access.

Part IV: Phone Number + Email → Subdomain Discovery (The Real Gold)

When you combine phone numbers and emails, you unlock subdomain discovery that no DNS tool can match.

Technique 1: WHOIS Contact Cross-Reference

Company domains are often registered by the same person. If you find the registrant's name and email from one domain, you can find all other domains they've registered:

# Step 1: Get WHOIS info for the main domain
whois healthtech.com | grep -E "Registrant|Admin|Tech|Email" > whois-info.txt

# Step 2: Extract registrant name and email
NAME=$(grep "Registrant Name" whois-info.txt | awk -F: '{print $2}' | xargs)
EMAIL=$(grep "Registrant Email" whois-info.txt | awk -F: '{print $2}' | xargs)

# Step 3: Search for other domains with same registrant
# Using WhoisXMLAPI
curl -s "https://www.whoisxmlapi.com/whoisserver/WhoisService?apiKey=$API_KEY&domainName=$NAME&outputFormat=JSON" | \
    jq -r '.WhoisRecord.registryData.registrantDomains[]'

# Using DomainTools Reverse WHOIS
curl -s "https://api.domaintools.com/v1/$NAME/domains/" \
    -u "$DOMAINTOOLS_USER:$DOMAINTOOLS_KEY" | \
    jq -r '.response.domains[]'

Technique 2: Social Media Profile Mining

Employee LinkedIn profiles often list multiple domains:

Current: Senior Engineer at HealthTech (healthtech.com)
Past: Lead Developer at MedData (meddata.io)
Education: MIT (mit.edu)

Each of these is a domain that may or may not be in scope. If meddata.io was acquired by healthtech.com, then meddata.io infrastructure is likely part of the target's attack surface.

# LinkedIn scraper (requires authentication)
# Extract: current company, past companies, education
# Cross-reference with known acquisitions

# For each past company found on LinkedIn profiles:
# Check if it was acquired by the target
# If yes: run full acquisition pipeline on that domain

Technique 3: Support Portal and Help Desk Domains

Phone numbers often lead to support portals, which lead to subdomains:

# Call the company's support number
# Listen for automated messages:
# "Press 1 for billing" → billing.helpdesk.com
# "Press 2 for technical support" → support.helpdesk.com
# "Press 3 for sales" → sales.helpdesk.com

# These are subdomains of the support portal domain
# Check if they resolve, check for takeovers

# Also check: support@company.com → Zendesk, Freshdesk, Helpscout
# Zendesk: company.zendesk.com
# Freshdesk: company.freshdesk.com
# Helpscout: company.helpscout.net

Technique 4: Email Header Subdomain Discovery

If you can obtain a legitimate email from the company (e.g., by signing up for their newsletter), the email headers reveal internal infrastructure:

Received: from mail.healthtech.com (192.168.1.10)
Received: from mx1.healthtech.com (203.0.113.5)
Received: from smtp-in.healthtech.com (198.51.100.20)
DKIM-Signature: d=healthtech.com; s=selector1
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of newsletter@healthtech.com designates 203.0.113.5 as permitted sender)

Each of these IPs and hostnames is a potential subdomain:

  • mail.healthtech.com
  • mx1.healthtech.com
  • smtp-in.healthtech.com

Real-World Example: Phone + Email → Subdomain Discovery

Target: SaaS company cloudserve.com.

Phone number from WHOIS: +1 (425) 555-0100 (Seattle area)

Email from WHOIS: admin@cloudserve.com

Step 1: WHOIS reverse search on phone number Found 12 domains, including:

  • cloudserve.io (known)
  • cloudserve-backup.com (unknown — registered 2008)
  • cs-legacy.com (unknown — registered 2005)

Step 2: WHOIS reverse search on email Found 8 more domains:

  • cloudserve-status.com (status page — known but useful)
  • cloudserve-dev.com (development — not in scope docs)

Step 3: Emails collected from Hunter.io 1,800 emails. Found devops@cloudserve.com in a GitHub commit.

Step 4: DevOps email → GitHub repos Found a repo with monitoring.cloudserve.com hardcoded in a config file.

Step 5: Subdomain enumeration on new domains

subfinder -d cloudserve-backup.com -silent
# Found: admin.cloudserve-backup.com
# Found: db.cloudserve-backup.com

Result: 14 new domains and 47 new subdomains discovered through phone and email OSINT alone. DNS brute-force against the main domain found none of these.

Part V: Building the Phone-to-Email-to-Domain Pipeline

Here's a practical automated pipeline that can be used for this workflow.

Phase 1: Phone Number Collection & Analysis

#!/bin/bash
# phase1-phone-collect.sh
TARGET="$1"
DOMAIN="$2"

echo "[*] Phase 1: Phone Number Collection"

# 1a. WHOIS extraction
whois "$DOMAIN" 2>/dev/null | grep -oP '(\+?\d{1,3}[-.\s]?)?\(?\d{3}\)?[-.\s]?\d{3}[-.\s]?\d{4}' > phones.txt

# 1b. Web scraping for phone numbers
katana -u "https://$DOMAIN" -d 2 -silent | \
    grep -oP '(\+?\d{1,3}[-.\s]?)?\(?\d{3}\)?[-.\s]?\d{3}[-.\s]?\d{4}' >> phones.txt

# 1c. Business directories
curl -s "https://api.opencorporates.com/v0.4/companies/search?q=$DOMAIN" | \
    jq -r '.results[].company.phone_number' 2>/dev/null | grep -v null >> phones.txt

# Deduplicate
sort -u phones.txt -o phones.txt
echo "[*] Found $(wc -l < phones.txt) unique phone numbers"

Phase 2: Phone → Domain Mapping

#!/bin/bash
# phase2-phone-to-domain.sh
TARGET="$1"

echo "[*] Phase 2: Phone to Domain Mapping"

while read PHONE; do
    echo "[*] Processing phone: $PHONE"

    # 2a. Reverse WHOIS by phone (if you have access)
    # DomainTools API
    # curl -s "https://api.domaintools.com/v1/$PHONE/domains/" -u "$USER:$KEY" | \
    #     jq -r '.response.domains[]' >> phone-domains.txt

    # 2b. SecurityTrails (manual or API)
    # curl -s "https://api.securitytrails.com/v1/search?query=whois.phone:$PHONE" \
    #     -H "APIKEY: $ST_KEY" | jq -r '.records[].hostname' >> phone-domains.txt

    # 2c. Breach data (authorized)
    # dehashed API
    # curl -s "https://api.dehashed.com/v1/search?query=phone:$PHONE" \
    #     -u "$EMAIL:$DEHASHED_KEY" | jq -r '.entries[].domain' >> phone-domains.txt

    sleep 1
done < phones.txt

sort -u phone-domains.txt -o phone-domains.txt
echo "[*] Found $(wc -l < phone-domains.txt) domains from phone numbers"

Phase 3: Email Collection

#!/bin/bash
# phase3-email-collect.sh
DOMAIN="$1"

echo "[*] Phase 3: Email Collection"

# 3a. Hunter.io
curl -s "https://api.hunter.io/v2/domain-search?domain=$DOMAIN&api_key=$HUNTER_KEY" | \
    jq -r '.data.emails[].value' > emails-hunter.txt

# 3b. theHarvester
theHarvester -d "$DOMAIN" -b google,linkedin,github -f /dev/null 2>/dev/null | \
    grep -oP '[a-zA-Z0-9._%+-]+@'"$DOMAIN" > emails-harvester.txt

# 3c. Skymem
curl -s "https://www.skymem.info/srch?q=$DOMAIN" | \
    grep -oP '[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]*\.?'"$DOMAIN" > emails-skymem.txt

# 3d. Web page extraction
katana -u "https://$DOMAIN" -d 2 -silent | \
    grep -oP '[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]*\.?'"$DOMAIN" > emails-web.txt

# 3e. JS file extraction
katana -u "https://$DOMAIN" -jc -silent | xargs -I{} curl -s {} 2>/dev/null | \
    grep -oP '[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]*\.?'"$DOMAIN" > emails-js.txt

# Combine
cat emails-hunter.txt emails-harvester.txt emails-skymem.txt emails-web.txt emails-js.txt | \
    sort -u > emails.txt

echo "[*] Found $(wc -l < emails.txt) unique email addresses"

Phase 4: Email → Domain Extraction

#!/bin/bash
# phase4-email-to-domain.sh
DOMAIN="$1"

echo "[*] Phase 4: Email to Domain Extraction"

# 4a. Extract all domains from email addresses
grep -oP '@[a-zA-Z0-9.-]+' emails.txt | sed 's/@//' | sort -u > email-domains.txt

# 4b. Remove the main domain (keep only non-obvious domains)
grep -v "$DOMAIN" email-domains.txt > other-domains.txt

echo "[*] Found $(wc -l < email-domains.txt) total domains from emails"
echo "[*] Found $(wc -l < other-domains.txt) domains OUTSIDE the main domain"

Phase 5: LinkedIn → Name → Email → Domain

#!/bin/bash
# phase5-linkedin-to-domains.sh
TARGET="$1"
DOMAIN="$2"

echo "[*] Phase 5: LinkedIn Name to Email to Domain"

# 5a. Scrape LinkedIn for employees (manual or with tool)
# linkedin_scraper -c "$TARGET" -o linkedin-employees.csv

# 5b. Extract past companies from LinkedIn profiles
# awk -F, '{print $3}' linkedin-employees.csv | sort -u > past-companies.txt

# 5c. For each past company, check if it's in scope
while read COMPANY; do
    echo "[*] Checking past company: $COMPANY"

    # Search for the company's domain
    domain_from_name=$(echo "$COMPANY" | tr '[:upper:]' '[:lower:]' | sed 's/ //g').com
    nslookup "$domain_from_name" > /dev/null 2>&1 && echo "$domain_from_name" >> past-company-domains.txt

done < past-companies.txt

# 5d. For each past company domain, check if acquired by target
# Manual step: verify acquisition history

Phase 6: Cross-Reference and Subdomain Enumeration on New Domains

#!/bin/bash
# phase6-subdomain-enum.sh
DOMAIN="$1"

echo "[*] Phase 6: Subdomain Enumeration on All Discovered Domains"

# Combine all domain lists
cat phone-domains.txt other-domains.txt past-company-domains.txt | sort -u > all-discovered-domains.txt

# Run subdomain enumeration on each
while read DISCOVERED_DOMAIN; do
    echo "[*] Enumerating: $DISCOVERED_DOMAIN"

    # CT logs
    curl -s "https://crt.sh/?q=%25.$DISCOVERED_DOMAIN&output=json" | \
        jq -r '.[].name_value' 2>/dev/null >> all-subs.txt

    # Subfinder
    subfinder -d "$DISCOVERED_DOMAIN" -silent >> all-subs.txt

    # DNS brute-force
    puredns bruteforce ~/wordlists/subdomains.txt "$DISCOVERED_DOMAIN" \
        -r ~/resolvers.txt -q >> all-subs.txt

done < all-discovered-domains.txt

sort -u all-subs.txt -o all-subs.txt
echo "[*] Total subdomains discovered: $(wc -l < all-subs.txt)"

Part VI: The Complete Real-World Workflow

To understand how this methodology works in practice, let's walk through an anonymized example of how phone numbers, emails, and public intelligence can reveal hidden assets. payflow.com

08:00 — Phone Collection

# WHOIS
whois payflow.com | grep -E "Phone|Tel"
# +1 (415) 555-0100

# Contact page
katana -u https://payflow.com/contact -d 1 | grep -oP '(\+?\d{1,3}[-.\s]?)?\(?\d{3}\)?[-.\s]?\d{3}[-.\s]?\d{4}'
# +1 (415) 555-0100 (same)
# +1 (512) 555-0200 (different — Austin)

# Business registry
curl -s "https://api.opencorporates.com/v0.4/companies/search?q=payflow" | \
    jq -r '.results[].company.phone_number'
# +1 (512) 555-0200
# +1 (512) 555-0300 (NEW — unknown)

Phone numbers collected:

  • +1 (415) 555-0100 (San Francisco — HQ)
  • +1 (512) 555-0200 (Austin — known office)
  • +1 (512) 555-0300 (Austin — UNKNOWN)

08:30 — Phone → Domain

# SecurityTrails reverse WHOIS by phone
# +1 (512) 555-0300 → registered to:
# payflow-holdings.com
# payflow-ventures.com
# pf-internal.com

New domains discovered:

  • payflow-holdings.com — Holding company
  • payflow-ventures.com — Venture arm
  • pf-internal.com — INTERNAL DOMAIN

09:00 — Email Collection

# Hunter.io: 847 emails
# theHarvester: 312 emails
# Skymem: 1,204 emails
# Web scraping: 89 emails
# JS files: 34 emails
# Total unique: 1,892 emails

09:30 — Email → Domain Extraction

grep -oP '@[a-zA-Z0-9.-]+' emails.txt | sed 's/@//' | sort -u

# Unique domains found in emails (excluding payflow.com):
# payflow.io (known)
# payflow.co (NEW)
# payflow-engineering.com (NEW — engineering team domain)
# pf-payments.com (NEW — payments processing domain)
# payflow-benefits.com (NEW — HR/benefits domain)

10:00 — GitHub Cross-Reference

# Searched for devops@payflow.com on GitHub
# Found GitHub user: payflow-devops
# Scanned repos for domain references

# Found in deploy configs:
# monitoring.internal.payflow.com
# logs.internal.payflow.com
# ci.internal.payflow.com

10:30 — Subdomain Enumeration on New Domains

# On pf-internal.com:
subfinder -d pf-internal.com -silent
# vpn.pf-internal.com (LIVE)
# jenkins.pf-internal.com (LIVE)
# git.pf-internal.com (LIVE)

# On payflow-engineering.com:
subfinder -d payflow-engineering.com -silent
# dev.payflow-engineering.com (LIVE)
# staging.payflow-engineering.com (LIVE)
# api.payflow-engineering.com (LIVE)

11:00 — Priority Assessment

P0:

  1. vpn.pf-internal.com — VPN portal (potential credential access)
  2. jenkins.pf-internal.com — Jenkins (potential RCE)
  3. pf-internal.com — Internal domain (potential for more discovery)

P1: 4. payflow-engineering.com — Engineering domain (dev/staging instances) 5. payflow-holdings.com — Holding company (potential subsidiary assets) 6. monitoring.internal.payflow.com — Monitoring (potential Grafana/Prometheus)

11:30 — Attack Phase

Jenkins on pf-internal.com:

  • No authentication required
  • Created a freestyle project with a reverse shell
  • Got shell access to the Jenkins server
  • Jenkins had AWS keys in environment variables
  • AWS keys had full admin access to production

Chain: 1 phone number → 3 unknown phone numbers → 1 unknown domain → 3 subdomains → 1 Jenkins server → AWS root access.

Part VII: Tool Reference Guide

Phone Number Tools

None

Email Collection Tools

None

Cross-Reference Tools

None

Part VIII: Common Mistakes (From Personal Experience)

Mistake 1: Not Checking All Phone Numbers from WHOIS

A common mistake is finding one phone number in WHOIS and stopping too early, ran my reverse search, and stopped. There were actually three different phone numbers across different domains — I missed two.

Fix: Extract EVERY phone number from EVERY WHOIS record for EVERY domain you find.

Mistake 2: Ignoring Email Domains That Don't Match the Target

What happened: I collected 2,000 emails for target.com. I filtered out everything that wasn't @target.com. I missed the 200 emails with @target-engineering.com, @target-holdings.com, and @target-benefits.com — all of which were owned by the same company.

Fix: Extract ALL unique domains from your email collection, not just the primary domain.

Mistake 3: Not Checking LinkedIn Past Companies

What happened: An employee's LinkedIn profile showed they previously worked at acme-solutions.com. I ignored it. Acme Solutions had been acquired by my target three years prior. Its infrastructure was in scope but I never checked it.

Fix: Scrape past companies from LinkedIn profiles and cross-reference with acquisition history.

Mistake 4: Not Running Subdomain Enumeration on Each New Domain

What happened: I found pf-internal.com and added it to my list. I didn't run subfinder or CT log queries against it. vpn.pf-internal.com was sitting there the whole time.

Fix: Run full subdomain enumeration on EVERY domain you discover, no exceptions.

Mistake 5: Stopping After One Round

What happened: I discovered new domains, ran subfinder once, and started attacking. I didn't recurse. Some of those new domains had their own subdomains, and those subdomains had their own CT logs.

Fix: Recursive enumeration. Every new domain → full acquisition pipeline → find more domains → repeat.

Bug Hunter Acquisition Checklist — Phone & Email Edition

☐ Phone Number Collection

  • ☐ WHOIS records extracted for all discovered domains
  • ☐ Contact/scraped pages (main site, subdomains, subsidiaries)
  • ☐ Business registries checked (OpenCorporates, state registries)
  • ☐ SEC filings reviewed (10-K, 10-Q, S-1)
  • ☐ Press releases and news articles mined
  • ☐ Social media profiles checked (LinkedIn, Twitter, Facebook)
  • ☐ Breach data queried (with authorization)

☐ Phone Number Analysis

  • ☐ VOIP provider identified for each number
  • ☐ Area codes mapped to physical office locations
  • ☐ Multi-number comparison for organizational structure
  • ☐ Extension patterns identified
  • ☐ Reverse WHOIS by phone number completed
  • ☐ Business registry search by phone completed
  • ☐ Phone number range scanning (if applicable)

☐ Phone → Domain Mapping

  • ☐ Reverse WHOIS for every unique phone number
  • ☐ Business registry domain mapping
  • ☐ Carrier/VOIP provider infrastructure checked
  • ☐ Support portal domains discovered (Zendesk, Freshdesk, etc.)
  • ☐ VOIP admin console exposure checked
  • ☐ Webhook endpoint testing (if Twilio/RingCentral identified)

☐ Email Collection

  • ☐ Hunter.io domain search completed
  • ☐ theHarvester multi-source harvest completed
  • ☐ Skymem cross-reference completed
  • ☐ Web page email extraction completed
  • ☐ JavaScript file email extraction completed
  • ☐ LinkedIn employee name scraping completed
  • ☐ GitHub commit email extraction completed
  • ☐ Mailing list/public forum extraction completed
  • ☐ Breach data email extraction (with authorization)

☐ Email → Domain Extraction

  • ☐ All unique domains extracted from email addresses
  • ☐ Primary domain filtered out to reveal hidden domains
  • ☐ Subsidiary/acquired company domains identified
  • ☐ Internal/private domains identified
  • ☐ Third-party service domains identified
  • ☐ Employee personal domains identified

☐ Email → GitHub → Domain Chain

  • ☐ GitHub accounts found for employee emails
  • ☐ Repos and commits scanned for domain references
  • ☐ Organization discovery completed
  • ☐ Config files and environment vars checked
  • ☐ Hardcoded endpoints extracted
  • ☐ S3 bucket names and cloud resources extracted

☐ Email → Service → Domain Chain

  • ☐ Atlassian (Jira/Confluence) instance discovered
  • ☐ Slack workspace discovered
  • ☐ Microsoft 365 tenant discovered
  • ☐ Google Workspace tenant discovered
  • ☐ Zendesk/Freshdesk/Helpscout portal discovered
  • ☐ Status page hosted domain discovered
  • ☐ Documentation/wiki hosted domain discovered

☐ Full Subdomain Enumeration on New Domains

  • ☐ CT log queries (crt.sh, certspotter) for each new domain
  • ☐ Passive DNS queries (SecurityTrails, VirusTotal)
  • ☐ Subdomain brute-force (subfinder, puredns, massdns)
  • ☐ Permutation-based discovery (alterx, gotator, dmut)
  • ☐ Recursive enumeration (each subdomain → parent as new target)
  • ☐ Wayback Machine historical subdomain discovery
  • ☐ Technology fingerprinting (httpx, whatweb)
  • ☐ HTTP response analysis (live vs. dead, redirects, error pages)

☐ Cross-Reference Validation

  • ☐ Phone numbers matched to discovered domains
  • ☐ Emails matched to discovered domains
  • ☐ LinkedIn past companies cross-referenced with acquisitions
  • ☐ GitHub profiles cross-referenced with company email domains
  • ☐ Breach data cross-referenced (correlates emails, phones, domains)
  • ☐ Scope validation for every newly discovered asset

☐ Continuous Monitoring

  • ☐ Daily CT log monitoring for new subdomains on discovered domains
  • ☐ Weekly phone number re-check (new WHOIS entries)
  • ☐ Weekly email re-harvesting (new employees, new domains)
  • ☐ GitHub monitoring for new employee commits
  • ☐ Acquisition news monitoring (Google Alerts, Crunchbase)
  • ☐ LinkedIn employee movement tracking
  • ☐ Quarterly full pipeline re-run

Final Technical Notes

Why This Works at Scale

The average Fortune 500 company has:

  • 50–200 registered domains
  • 10–50 subsidiaries/acquired entities
  • 2,000–20,000 employees
  • 5–20 different phone numbers

DNS brute-force will find maybe 30–50% of the subdomains on the main domain. It will find almost none of the subdomains on other domains.

Phone and email OSINT finds the other domains. Then you run DNS brute-force on those. The result is a 3–5x increase in discovered attack surface.

The Data Flow

Phone Number → Reverse WHOIS → New Domains
Phone Number → Business Registry → Legal Entities → New Domains
Phone Number → VOIP Provider → Admin Console → Subdomains

Email Address → Hunter.io → Cross-Company Domains
Email Address → GitHub → Repos → Configs → Domains
Email Address → Breach Data → Service Registrations → Domains
Email Address → LinkedIn → Past Companies → Acquired Domains

New Domains → Subdomain Enumeration → Attack Surface

A Final Word on Authorization

Everything in this blog assumes you have explicit written authorization to test the target's assets. I do not share the names of actual targets. All examples are anonymized composites of real engagements.

If you're new to bug bounty:

  1. Start with public programs on HackerOne/Bugcrowd that explicitly allow OSINT
  2. Never use breach data unless the program explicitly permits it
  3. Never use social engineering unless the program explicitly permits it
  4. When in doubt, ask the program's security team

Disclaimer: Only for authorized bug bounty / pentesting environments.

None

GitHub: SecurityTalent | Medium: Security Talent | Twitter: Securi3yTalent | Facebook: Securi3ytalent | Telegram: Securi3yTalent

#BugBounty #OSINT #CyberSecurity #EthicalHacking #Infosec #PenetrationTesting #AttackSurface #SubdomainEnumeration #ThreatHunting #SecurityResearch #RedTeam #DigitalFootprint #CyberSecurity #BugBounty #BugBountyHunter #EthicalHacking #InfoSec #WebSecurity #ApplicationSecurity #AppSec #CloudSecurity #FrontendSecurity #WebDevelopment #JavaScript #ReactJS #Laravel #NodeJS #DevSecOps #OWASP #SecretsManagement #GitHub #GitHubDorks #SourceMaps #EnvFiles #SecurityResearch #PenetrationTesting #RedTeam #BlueTeam #CloudComputing #AWS #Azure #GoogleCloud #VibeCoding #AI #SecureCoding #DeveloperSecurity #TechBlog #Programming