Holehe Detection Strategies: How Email Verification Modules Work in megadose/holehe

Holehe uses four distinct detection strategies—register, login, password recovery, and other—to verify whether an email address is linked to online service accounts.

Holehe is an open-source OSINT tool that checks if an email address exists across hundreds of services. Each service check is implemented as a module in holehe/modules/, and every module declares a method variable that specifies which of the four detection strategies it employs. Understanding these strategies helps security researchers interpret results and develop new modules.

The Four Holehe Detection Strategies

Holehe modules use four string values for the method variable. These values describe the technical approach each module uses to probe a service.

1. Register Method — Email Availability Checks

The register method queries registration or email-availability endpoints to determine if an address is already taken.

• Mechanism: Services often expose public APIs that return whether an email is available for new account creation. If unavailable, the address likely has an existing account.
• Example: In holehe/modules/social_media/twitter.py, the module calls Twitter's email_available.json endpoint:

# From holehe/modules/social_media/twitter.py

async def twitter(email, client, out):
    name = "twitter"
    domain = "twitter.com"
    method = "register"           # ← detection strategy

    
    headers = {
        "Authorization": "Bearer AAAAAAAAAAAAAAAAAAAAANRILgAAAAAAnNwIzUejRCOuH5E6I8xnZz4puTs%3D1Zv7ttfk8LF81IUq16cHjhLTvJu4FA33AGWWjCpTnA",
        "Content-type": "application/x-www-form-urlencoded",
    }
    
    data = {
        'email': email,
    }
    r = await client.post(
        "https://api.twitter.com/i/users/email_available.json",
        headers=headers,
        data=data
    )
    # Response indicates if email is taken (account exists)

2. Login Method — Authentication Flow Probing

The login method initiates or simulates part of a login flow to detect account existence.

• Mechanism: Many services reveal whether an email has an associated account through login form responses, even without correct credentials.
• Example: holehe/modules/social_media/snapchat.py uses this approach:

# From holehe/modules/social_media/snapchat.py

async def snapchat(email, client, out):
    name = "snapchat"
    domain = "snapchat.com"
    method = "login"              # ← detection strategy

    
    # Snapchat login flow probe

    # Response differentiation reveals account existence

Login-based detection requires careful handling of rate limits and anti-bot measures but provides reliable results for services without public availability endpoints.

3. Password Recovery Method — Reset Flow Analysis

The password recovery method leverages password reset or account recovery functionality.

• Mechanism: Password reset forms typically validate whether an email exists in the system before sending reset instructions. This validation response becomes the detection signal.
• Example: holehe/modules/social_media/odnoklassniki.py demonstrates this technique:

# From holehe/modules/social_media/odnoklassniki.py

async def odnoklassniki(email, client, out):
    name = "odnoklassniki"
    domain = "odnoklassniki.ru"
    method = "password recovery"  # ← detection strategy

    
    # Triggers password recovery flow

    # Server response indicates account existence

This method is particularly effective for services with comprehensive account recovery systems that distinguish between registered and unregistered emails.

4. Other Method — Custom Detection Approaches

The other method categorizes detection strategies that don't fit the three standardized approaches.

• Mechanism: Unique service-specific techniques, proprietary APIs, or complex multi-step verification flows.
• Example: Currently only holehe/modules/software/office365.py uses this label:

# From holehe/modules/software/office365.py

async def office365(email, client, out):
    name = "office365"
    domain = "office365.com"
    method = "other"              # ← detection strategy

    
    # Custom Office 365 tenant and account discovery

    # Uses Microsoft-specific authentication endpoints

How Detection Strategies Flow Through the System

Each module's method value propagates through Holehe's core engine and appears in final results. The execution flow works as follows:

1. Module declaration: Each .py file in holehe/modules/ sets method = "register|login|password recovery|other"
2. Result construction: Modules append dictionaries to the out list with standardized fields including method
3. Aggregation: holehe/core.py collects all module outputs
4. Reporting: Results include the detection strategy for transparency

# Typical module result structure (appended to out list)

{
    "name": "twitter",
    "domain": "twitter.com",
    "method": "register",         # ← the detection strategy

    "email": "user@example.com",
    "exists": True,
    "rateLimit": False,
    "source": "Holehe"
}

Practical Usage and Output Interpretation

Running Holehe from command line or Python API returns detection strategy metadata:

# Command-line usage

$ python -m holehe -e target@example.com

# Sample output format

twitter: exists=True  method=register
snapchat: exists=False  method=login
odnoklassniki: exists=True  method=password recovery
office365: exists=False  method=other

# Python API usage

import asyncio
from holehe.core import core

async def analyze_detection_strategies(email):
    results = await core(email)
    strategies = {}
    for r in results:
        method = r['method']
        if method not in strategies:
            strategies[method] = []
        strategies[method].append({
            'service': r['name'],
            'exists': r['exists']
        })
    return strategies

# Categorize results by detection strategy

strategies = asyncio.run(analyze_detection_strategies("target@example.com"))
print(strategies['register'])  # All services using register method

Key Source Files for Detection Strategy Implementation

File Path	Purpose	Detection Strategy Used
holehe/modules/social_media/twitter.py	Twitter email availability	register
holehe/modules/social_media/snapchat.py	Snapchat login flow	login
holehe/modules/social_media/odnoklassniki.py	Odnoklassniki password reset	password recovery
holehe/modules/software/office365.py	Office 365 tenant discovery	other
holehe/core.py	Module orchestration and result aggregation	All strategies

Summary

• Register method: Checks email availability through registration APIs—fast and non-intrusive
• Login method: Probes authentication flows—effective when availability endpoints don't exist
• Password recovery method: Analyzes reset responses—reliable for services with recovery systems
• Other method: Captures custom approaches for complex services like Office 365

The method variable in each Holehe module provides crucial context for interpreting verification results and selecting appropriate techniques when extending the tool.

Frequently Asked Questions

How does Holehe choose which detection strategy to use for a service?

Each module developer selects the strategy based on the target service's available endpoints. The choice depends on which technique produces reliable account-existence signals without triggering aggressive rate limiting. If a service exposes a public email-availability check, register is preferred; otherwise, login or password recovery flows are probed.

Can a single module use multiple detection strategies?

No. According to the megadose/holehe source code, each module assigns exactly one method string value. Modules implement one primary detection technique. If that technique fails or returns ambiguous results, the module reports failure rather than switching strategies.

Why does Office 365 use the "other" detection method?

Office 365 detection requires Microsoft-specific tenant discovery and authentication endpoint analysis that doesn't match the standard three patterns. The other label in holehe/modules/software/office365.py acknowledges this unique approach while maintaining result structure consistency across all modules.

Where is the detection strategy information stored in Holehe results?

The method field appears in every result dictionary that modules append to the out list. In holehe/core.py, these dictionaries are collected and returned to the caller. Both command-line and programmatic usage expose this field for downstream analysis and reporting.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}