Full Report
Two security researchers bought cheap domains—including noreply.net and deleteduser.com—and set up email listening services. Hundreds of companies are sending them corporate secrets.
Analysis Summary
# Incident Report: Exposure of Corporate and PII via Misconfigured "No-Reply" Domains
## Executive Summary
Security researchers Cory Solovewicz and others inadvertently created a massive "accidental honeypot" by purchasing common placeholder domains like `noreply[.]net`, `noreply[.]us`, and `deleteduser[.]com`. Hundreds of companies worldwide are leaking sensitive corporate secrets, PII, and credentials because their automated systems are configured to send mail to these non-existent placeholder addresses. The ongoing incident highlights a systemic failure in how organizations handle "no-reply" configurations and user deletion workflows.
## Incident Details
- **Discovery Date:** Ongoing (Significant volume noted since December 2024)
- **Incident Date:** 2020 – Present
- **Affected Organization:** Hundreds of third-party organizations (including city governments, schools, and private enterprises)
- **Sector:** Cross-sector (Government, Education, Retail, Tech)
- **Geography:** Global
## Timeline of Events
### Initial Access
- **Date/Time:** 2020 (Purchase of `noreply[.]us`), 2024 (Purchase of `noreply[.]net`)
- **Vector:** Domain Squatting / Passive Collection
- **Details:** Researchers purchased expired or available domains commonly used as "placeholders" in software code and database entries.
### Lateral Movement
- **N/A:** No active movement was required; the data was pushed directly to the researchers' infrastructure by the victim organizations' own mail servers.
### Data Exfiltration/Impact
- **Details:** Since December 2024, one domain alone received over 401,796 messages. Data includes government injury reports, pizza orders, service repair orders, school platform credentials, and internal corporate communications.
### Detection & Response
- **Discovery:** Solovewicz noticed a deluge of traffic while setting up a catch-all email for personal privacy.
- **Response Actions:** Researchers have attempted to notify some affected parties; however, the scale of the leak makes individual notification difficult.
## Attack Methodology
- **Initial Access:** Passive collection via ownership of "placeholder" domains (e.g., `noreply[.]net`).
- **Persistence:** Maintaining domain registration and catch-all SMTP servers.
- **Privilege Escalation:** Not required; incoming emails contained plaintext credentials and sensitive internal links.
- **Defense Evasion:** Not applicable; the "attackers" (researchers) are the legitimate owners of the destination domains.
- **Credential Access:** Harvesting credentials sent in "account setup" or "password reset" emails directed to placeholder addresses.
- **Discovery:** Passive reconnaissance of incoming SMTP traffic.
- **Lateral Movement:** Potential for movement if researchers used the received credentials to log into victim platforms (not performed).
- **Collection:** Catch-all email server logs and storage.
- **Exfiltration:** Data is "self-exfiltrated" by the victims' automated systems.
- **Impact:** Massive exposure of PII and corporate intellectual property.
## Impact Assessment
- **Financial:** Potential for significant GDPR/CCPA fines for leaking organizations.
- **Data Breach:** High; includes PII, medical/injury reports, and authentication credentials.
- **Operational:** Low direct disruption, but high risk of account takeover.
- **Reputational:** High; demonstrates a lack of basic security hygiene regarding automated mail systems.
## Indicators of Compromise
- **Network Indicators:** Outbound SMTP traffic to:
- `noreply[.]net`
- `noreply[.]us`
- `deleteduser[.]com`
- **Behavioral Indicators:** Systems configured to use "placeholder" emails in "From" or "Reply-To" fields that point to external domains not owned by the organization.
## Response Actions
- **Containment:** Organizations must audit all "no-reply" settings and database "deleted user" scripts.
- **Eradication:** Update all hardcoded placeholder strings in codebases to use domains owned by the organization (e.g., `noreply@company[.]com`).
- **Recovery:** Rotate any credentials or sensitive links that were sent to these domains.
## Lessons Learned
- **The "Placeholder" Fallacy:** Developers often use "fake" domains for testing or for users who have deleted their accounts, assuming those domains are invalid.
- **Default Trust:** Systems are blindly trusting that "no-reply" addresses do not need to be valid or owned by the sender.
- **Data Hygiene:** PII is being sent to addresses without verifying if an active, authorized user is on the receiving end.
## Recommendations
- **Domain Ownership:** Only use domains owned and controlled by your organization for any automated email communications.
- **Null Routing:** If a "no-reply" address is needed, use a sub-domain (e.g., `noreply.yourcompany[.]com`) and ensure it has no MX records or points to a controlled internal sinkhole.
- **Code Audit:** Scan codebases and databases for hardcoded strings like `noreply[.]com`, `test[.]com`, or `deleted[.]com`.
- **Encryption:** Avoid sending sensitive data or credentials in automated emails; use secure, time-limited portal links instead.