Skip to main content
Beta: Credential Monitoring is currently in beta. We’re continuously expanding monitoring methods and adding new features to enhance your security posture.

​
What is Credential Monitoring?

Compromised credentials are one of the weakest security points and the easiest attack vector for cybercriminals. ProjectDiscovery’s Credential Monitoring is a continuous threat intelligence system that detects compromised credentials from malware stealer logs, enabling security teams to prevent account takeovers. By continuously scanning millions of exposed credentials, the platform identifies actual credential exposures that pose immediate risk to your organization, employees, and customers. We specifically focus on malware stealer logs as these have proven to be the most impactful security vulnerabilities. As we evolve this beta product, we’ll be expanding monitoring across GitHub repositories, crawled web pages, and other sources to detect exposed tokens, API keys, and environment secrets.
ProjectDiscovery Credential Monitoring Dashboard

Try Credential Monitoring Now

Start monitoring your credentials for free and see exposed credentials in real time.

​
Feature access by plan

​
Domain Verification

Required for Organization-Wide Leaks: To access Employee Leaks and Customer/User Leaks for your organization, you must first verify ownership of your domain.

​
How to Verify in the App

1

Navigate to Credential Monitoring

Go to cloud.projectdiscovery.io → Credential Monitoring → Domains → Add Domain
2

Enter your domain

Type your domain name and click Continue
3

Choose verification method

Select your preferred method tab (DNS record / HTML meta tag / Upload TXT file) and follow the instructions. Use the built-in copy and download helpers.
4

Complete verification

After adding the record, meta tag, or file, click Verify. A successful verification marks the domain as Verified ✓

​
Verification Methods

Choose from three verification methods based on your access level:

DNS TXT Record

Best when you have DNS access

HTML Meta Tag

Best when you can edit your website

Upload TXT File

Best when you can upload files to your site
The verification modal in the app provides copy/download helpers for each method to make setup quick and easy.

​
Method 1: DNS TXT Record

Recommended — Standard method when you have access to edit DNS records for the domain.
1

Create a TXT record

Add a TXT record on the root of your domain with the following value:
2

Configure DNS settings

3

Verify in the app

Click Verify in Credential Monitoring. Once successful, your domain will show as Verified.
  • DNS propagation can take up to 48 hours, though most verifications succeed within minutes
  • Verify your record is live using terminal:
Or for specific record names:

​
Method 2: HTML Meta Tag

Best when you can edit and deploy your site’s HTML but cannot change DNS settings.
1

Add the meta tag

Place this meta tag inside the <head> section of your root HTML page (https://yourdomain/):
2

Deploy the change

Push the updated HTML to your live site.
3

Verify in the app

Click Verify in Credential Monitoring.
Confirm the tag is present in the deployed page:
If verification fails:
  • Ensure the change is on the live site (not staging)
  • Clear any CDN/cache that might be serving an old version

​
Method 3: Upload TXT File

Best when you can upload static files to your site root but don’t want to modify DNS or HTML.
1

Create the verification file

Create a file named pd-verification.txt containing only your verification string:
2

Upload to your site root

Upload the file so it’s accessible at https://yourdomain/pd-verification.txt
3

Verify in the app

Click Verify in Credential Monitoring.
Confirm the file is reachable and contains the expected string:
If verification fails:
  • Ensure the file is served over HTTPS
  • Verify it’s accessible at the exact root path

​
Quick Troubleshooting Reference

​
FAQs About Verification

No — personal leaks are automatically visible for the email you used to sign up. Verification is only required for organization-wide views.
Only Enterprise customers can have multiple domains verified. You can self-verify each domain individually or reach out to support for bulk verification.
Usually 5–10 minutes, depending on DNS propagation time.
No, once a domain is verified it remains linked unless the verification record is removed.

​
How It Works

Our credential monitoring system:
  1. Collects malware-stolen credential data from publicly accessible sources including:
    • Telegram channels and groups where malware logs are shared
    • Leaks forums and websites
    • Public repositories where malware logs are posted
  2. Processes and filters the data to:
    • Parse credential pairs (email:password combinations) from malware logs
    • Extract domain and email information
    • Filter for credentials matching your monitored domains
    • Remove invalid formatted data
  3. Alerts your team when credentials matching your monitored domains are found
All credential data comes from publicly accessible sources on the internet where malware logs are shared. We do not perform any unauthorized access or hacking to obtain this information.
Important: ProjectDiscovery does not validate, test, or attempt to login with any collected credential information. We only collect and filter the data for formatting validity - we do not verify if credentials are active or functional.

​
Leak Classification and Mapping

ProjectDiscovery’s Credential Monitoring categorizes discovered credentials into three distinct types based on their relationship to your organization. Understanding these categories helps prioritize remediation efforts and assess security impact across different stakeholder groups.
Credential Monitoring Data Classification

​
Visual Data Flow

The following diagram illustrates how credential data flows through our classification system:

​
Leak Categories Explained

​
👤 My Leaks

Personal Account Exposures
  • Definition: All credential exposures directly associated with your logged-in email address in the ProjectDiscovery platform
  • Scope: Personal accounts and services where you used your email for registration
  • Impact: Direct personal security risk requiring immediate attention
  • Example: If you’re logged in as admin@hooli.com, this shows all malware logs containing admin@hooli.com credentials
  • Access: Available to all user tiers without additional verification

​
👥 Employee Leaks

Organizational Workforce Exposures
  • Definition: All credential exposures where the login email contains your organization’s domain, regardless of the service/platform where it was used
  • Scope: Current and former employees using company email addresses on ANY platform or service
  • Impact: Internal security risk affecting both organizational assets and external vendor access
  • Examples:
    • Internal Company Services:
      • john.doe@hooli.com → mail.hooli.com (company email)
      • sarah.smith@hooli.com → intranet.hooli.com (internal systems)
    • External/3rd Party Services:
      • john.doe@hooli.com → github.com (code repositories)
      • sarah.smith@hooli.com → aws.amazon.com (cloud services)
      • support@hooli.com → slack.com (communication tools)
      • admin@hooli.com → dropbox.com (file sharing)
  • Access: Requires domain verification for Business Domain Users; automatically available for Enterprise users
  • Privacy: Only visible to Owner and Admin account types

​
🏢 Customer/User Leaks

External Customer Exposures
  • Definition: All credential exposures where the login URL/domain contains your company domain, but the email address does NOT belong to employees
  • Scope: Your customers and users who have accounts on your services or platforms
  • Impact: External customer security risk affecting user trust and platform security
  • Examples:
    • user123@gmail.com with login URL containing hooli.com
    • customer@yahoo.com accessing services at app.hooli.com
    • buyer@outlook.com with stored passwords for shop.hooli.com
  • Exclusions: Does not include employee emails (those are classified as Employee Leaks)
  • Access: Available to verified Business Domain Users and Enterprise customers

​
Key Classification Distinction

Critical Understanding: The fundamental difference between Employee and Customer leaks:
  • 👥 Employee Leaks: Determined by the EMAIL ADDRESS - any leak where the email contains your company domain, regardless of what service it was used on
    • john@hooli.com used on GitHub ✓ Employee Leak
    • sarah@hooli.com used on AWS ✓ Employee Leak
    • admin@hooli.com used on Dropbox ✓ Employee Leak
  • 🏢 Customer Leaks: Determined by the SERVICE/LOGIN URL - any leak where external emails were used on your company’s services
    • user@gmail.com used on app.hooli.com ✓ Customer Leak
    • customer@yahoo.com used on shop.hooli.com ✓ Customer Leak

​
Priority Matrix for Remediation

Pro Tip: Use the leak classification to implement different response workflows. Personal and employee leaks require immediate internal action (including auditing 3rd party service access), while customer leaks may need customer communication and platform-level security enhancements.

​
Data Accuracy and Classification Logic

Our classification system uses advanced pattern matching and domain analysis to ensure accurate categorization:
  • Email Domain Matching: Sophisticated regex patterns identify company domains in email addresses
  • URL Domain Extraction: Advanced parsing extracts target domains from login URLs and service endpoints
  • Duplicate Prevention: Cross-category filtering ensures employee emails don’t appear in customer leak categories
  • False Positive Reduction: Multiple validation layers minimize misclassification

​
Understanding Malware-Based Credential Theft

​
How Malware Steals Credentials

Malware (information stealers) typically harvest credentials from:
  • Browser saved passwords - Chrome, Firefox, Edge, Safari stored passwords
  • Application credentials - Email clients, FTP clients, messaging apps
  • System credential stores - Windows Credential Manager, macOS Keychain
  • Browser cookies and sessions - Active login sessions
  • Cryptocurrency wallets - Wallet files and recovery phrases
  • SSH/RDP credentials - Stored connection credentials

​
Malware Log Structure

When malware infects a system, it creates “logs” containing stolen data that may include:
  • Victim’s system information (OS, location, etc.)
  • Stolen passwords organized by application/browser
  • Cookies and session tokens
  • Cryptocurrency wallet data
  • Screenshots and system files
These logs are then shared or sold on underground platforms, which is where we collect them from publicly accessible sources.

​
Why Some Findings Lack Detailed Metadata

Important: Not all credential exposures include complete metadata such as specific malware names, infection dates, or victim details. This happens because:
  • Data Processing: Threat actors often strip identifying information before sharing logs
  • Source Aggregation: Logs may pass through multiple hands before becoming publicly available
  • Privacy Protection: Some sources anonymize victim information
  • Technical Limitations: Malware logs don’t always contain complete metadata

​
Common Metadata Available

When present, malware logs may include:
  • Collection date - When the malware harvested the credentials
  • Geographic location - Country/region of infected system
  • System information - OS version, browser versions
  • Malware family - Type of stealer malware used (when identifiable)

​
When Metadata is Missing or “Blank”

If findings show blank or missing source information:
  • The credentials are still valid threats - treat them seriously
  • Source anonymization - Information may have been stripped for privacy
  • Multiple aggregation - Logs may have passed through several sources
  • Technical parsing issues - Some log formats don’t parse completely

​
What Actions Should You Take?

When malware-exposed credentials are identified for your domain:
  1. Force password resets for all affected email addresses
  2. Enable multi-factor authentication (MFA) on all affected accounts
  3. Disable compromised accounts temporarily and review recent activity
  4. Rotate associated API keys and service account passwords
  5. Scan endpoints for malware infections
  6. Deploy endpoint protection and implement password managers
  7. Conduct security training to prevent future credential theft

​
Handling Cases with Missing Source Details

When leak sources are blank or incomplete:
  • Prioritize these equally - assume they represent active threats
  • Focus on remediation rather than source investigation
  • Monitor affected accounts closely for suspicious activity
  • Treat as confirmed malware exposure and follow full remediation steps

​
API Integration

Access credential monitoring data programmatically:
  • Export Leaks: POST /v1/leaks/export - Export all leaked credentials (personal, employee, customer) with filtering options
  • Leak Details: POST /v1/leaks/info - Get detailed information for a specific leak
  • Update Status: POST /v1/leaks/status - Mark leaks as fixed or reopen them
  • Domain Stats: GET /v1/leaks/stats/domain - Get leak statistics for any domain (public endpoint, no auth required)
  • Email Stats: GET /v1/leaks/stats/email - Get leak statistics for any email (public endpoint, no auth required)
For detailed API documentation and usage examples, see the API Reference.
Integrate these API endpoints with your security tools to automatically trigger password resets and security reviews when new malware-based exposures are detected.

​
Common User Questions

Q: Can all team members see our organization’s exposed credentials? A: No, credential visibility is restricted to Owner and Admin accounts only. This ensures sensitive breach data is only accessible to authorized personnel responsible for security. Q: Why can’t I see employee passwords? A: Business Domain Users can view employee passwords data after DNS verification. Only Enterprise customers can monitor multiple domains. Q: How do I view my personal leaked credentials? A: You can automatically view all leaked credentials associated with the email address you used to sign up. Simply navigate to “My Leaks” to see any exposures linked to your personal email account - no additional verification required. Q: What breach notifications will I receive? A: All users receive email notifications when new breaches affecting their personal email are discovered. Business Domain Users (after DNS verification) and Enterprise customers also receive notifications for employee credential exposures across their organization. Q: How do I monitor my company’s domain? A: Business domain users must verify their domain via DNS TXT record to access organization-wide breach data. Without verification, you’ll only see personal email exposures. Enterprise users can verify and monitor multiple domains. Q: Are you monitoring our employees? A: No, we monitor internet-wide credential leaks and aggregate them into a comprehensive database. When you verify your domain, we filter this existing database to show only exposures related to your organization. We’re not actively monitoring your employees - we’re helping you discover credentials that are already publicly exposed across the internet. Q: How accurate is the breach data? A: We aggregate data from multiple verified sources. While false positives are possible, always verify before taking action. Q: How current is the data? A: We continuously monitor sources 24/7. New breaches typically appear within hours to days of being discovered. Q: How did these credentials get stolen? A: The credentials were harvested by malware (information stealers) that infected user devices. These malware strains steal saved passwords from browsers and applications, then upload the data to command-and-control servers where it eventually gets shared publicly. Q: Are these from phishing attacks or data breaches? A: No. Our credential monitoring specifically focuses on malware-based credential theft only. We do not track credentials from phishing campaigns or corporate data breaches. Q: Why don’t all findings show malware names? A: Malware logs don’t always contain identifying information about the specific malware strain. Additionally, logs are often processed and anonymized before being shared publicly, which strips technical details. Q: Why are some metadata fields showing as blank? A: This indicates that metadata fields (such as malware family name, collection date, geographic location, or system information) were not available in the original malware log or were stripped during processing. The credentials are still legitimate exposures that require immediate action. Q: Do you test if these credentials actually work? A: No. ProjectDiscovery does not validate, test, or attempt to login with any collected credential information. We only collect and present the data as found in publicly accessible malware logs.