In recent years, a new category of abuse has emerged in the cybersecurity landscape: the impersonation of law enforcement officers and government agencies by organized criminal groups, carried out through the use of compromised or look-alike government email domains. The objective of these attacks is to obtain user data from online service providers through what appear to be legitimate Emergency Data Requests (EDRs) or legal process, when in reality the requests originate from threat actors operating under stolen institutional credentials.
This is not a marginal phenomenon. On 4 November 2024, the FBI’s Internet Crime Complaint Center released Private Industry Notification 20241104-001, explicitly warning US-based companies about the increase in fraudulent Emergency Data Requests submitted using compromised US and foreign government email accounts. The notification documents that compromised credentials are openly traded on criminal forums, that the practice was originally associated with groups such as Lapsus$, and that the volume and accessibility of such credentials has grown substantially.
Independent investigative reporting by Brian Krebs at KrebsOnSecurity, research published by Mandiant, and public disclosures by major platforms have confirmed the same pattern across multiple jurisdictions. Email accounts belonging to police forces and government bodies in countries across Asia, Europe, South America, and Africa have been observed for sale on underground forums for as little as twenty dollars per account.
The implication is significant: any online service provider that has relied on the authenticity of a government email domain as a primary verification factor for law enforcement requests is now operating in a fundamentally changed threat environment. This article explains how Onion Mail and its parent company Onion Search Engine LLC approach this problem, what we have always done, what we have recently learned, and how we are evolving our processes going forward. We are publishing this because we believe transparency is the only legitimate response to a problem of this nature.
What a Service Like Onion Mail Receives, and the Legal Framework
Onion Search Engine LLC is a company registered in the State of New York, United States. As such, it is subject to United States law, including the Electronic Communications Privacy Act (ECPA), the Stored Communications Act, and applicable provisions on cooperation with law enforcement authorities through subpoenas, court orders, and search warrants. Like every online service provider that operates legally, Onion Mail receives data requests from law enforcement agencies in various jurisdictions and responds within the framework of applicable law. This is not exceptional; it is the baseline obligation of any legitimate technology company.
The relevant question is not whether such requests are received, but how they are verified, what information can actually be provided, and what protections exist for users against both unlawful surveillance and impersonation-based abuse. The remainder of this article addresses these three points in detail.
The Architecture of Onion Mail: How Users Control Their Own Privacy
Onion Mail is designed around a fundamental principle: the user, not the provider, should determine the level of anonymity and protection applied to their communications. The service is built so that this is not a marketing claim but a technical reality, verifiable at any moment by the user themselves.
Network access options
Users can access Onion Mail through standard HTTPS connections, through a VPN of their choice, or natively through the Tor network. Onion Mail operates a dedicated .onion address, which means the service is reachable directly from within Tor without any exit node traversal. When a user connects through Tor or through the .onion address, the connection does not produce an originating IP address that can be associated with the user’s real network identity.
Message encryption
Onion Mail integrates PGP encryption natively into the user interface. When users exchange messages using PGP, the content of those messages is end-to-end encrypted; the provider does not hold the decryption keys and cannot read the message bodies. This is not a proprietary cryptographic implementation but an integration of the open, audited, and widely deployed OpenPGP standard.
Account recovery without phone numbers
Onion Mail does not require a phone number for account creation or recovery. Account recovery is handled through a Tox ID, leveraging the open-source Tox decentralized messaging protocol. This means the service does not hold a phone number that could be subpoenaed, leaked, or used as a correlation identifier.
The user-facing security widget
Every Onion Mail user sees, in their profile, a real-time indicator of the security state of their session and account. The widget shows whether the connection is currently routed through Tor or a VPN, whether received messages are encrypted with PGP, and whether the overall configuration achieves the level of protection the user expects. The user does not need to trust the provider’s claims about privacy; the widget communicates the technical reality of each session.
The security events panel
Every user can access https://onionmail.org/account/security/events and view the connection IP addresses recorded for their own account. If a user has been accessing the service through Tor, no usable IP addresses appear in that log, because there are none to record. This is verifiable by every user, on their own account, at any time.
The philosophy behind this architecture is what is sometimes called a trustless approach: the user is not asked to take the provider’s word for it. The user is asked to verify, through indicators built into the product and through reliance on open-source third-party tools (Tor, OpenPGP, Tox), that the protections are operating as described.
What Onion Mail Can and Cannot Provide in Response to a Legal Request
A consequence of the architecture described above is that the information available to the provider, and therefore the information that could potentially be produced in response to a lawful request, depends entirely on the choices the user has made.
When a user accesses Onion Mail exclusively through the Tor network and uses PGP encryption for their correspondence, the provider does not hold meaningful identifying IP information and does not hold the content of messages in readable form. There is no decision to be made about whether to “disclose” this information, because it does not exist in a usable state within our systems.
When a user accesses the service through a VPN and uses PGP, the provider records the IP address of the VPN exit point, not the user’s real IP, and the message content remains encrypted.
When a user accesses the service through a standard connection without PGP encryption, the provider records the originating IP address and stores message content in the standard form required to operate an email service.
In every case, what we can produce is what is technically present in our systems. The architecture is intentionally designed so that the user, not the provider, determines this baseline.
This is the meaning of our position that privacy and anonymity are foundational values: they are built into the technical structure of the service, not promised as a policy that could be reversed.
Onion Search Engine LLC and the Law Enforcement Platform
It is important to be clear about a structural point, because we have seen this confused in public discussion. Onion Mail is an email service. Onion Search Engine LLC is the United States company that owns and operates Onion Mail, as well as other services, including a platform that was designed to allow verified law enforcement agencies to submit data requests in a structured, auditable manner.
This platform was conceived to address a real problem: law enforcement agencies frequently submit data requests by email, in inconsistent formats, with varying degrees of verifiability. A purpose-built portal allows requests to be standardized, logged, and responded to with greater procedural clarity than ad-hoc email correspondence. Similar platforms exist for major providers across the industry.
Access to this platform is not open to the public. It is restricted to verified governmental entities. Until recently, the verification of those entities relied substantially on the authenticity of government email domains used during the registration and request process. This brings us to the central issue this article addresses.
The Current Problem: Compromised Government Email Channels
The model of verifying law enforcement requesters through the authenticity of their government email domain rested on an implicit assumption: that government email accounts are reasonably well protected and that a message arriving from a legitimate .gov, .gov.xx, police.xx, or equivalent domain can be treated as originating from a legitimate officer of that agency.
This assumption has been substantially eroded by the documented phenomenon of large-scale credential compromise affecting law enforcement and government email systems across multiple jurisdictions. As reported by the FBI in the November 2024 notification cited above, by KrebsOnSecurity, and by other reputable sources, compromised government email credentials are now a commodity on criminal markets. The vector of attack is not the technical infrastructure of providers like Onion Mail; it is the security posture of the institutional email accounts themselves, which are vulnerable to phishing, credential reuse, infostealer infections, and insider compromise.
We have also received direct communications, including from hostile sources, indicating awareness within criminal circles that this attack vector is being actively exploited. These communications, combined with publicly documented incidents affecting multiple service providers across the industry, lead to a single conclusion: the government email domain, considered in isolation, can no longer be treated as sufficient evidence of legitimate law enforcement origin.
An Incident on Our Law Enforcement Platform: What Happened and How We Responded
In keeping with our commitment to transparency, we will address an incident that occurred on our law enforcement platform.
A threat actor obtained access to the platform by registering with credentials originating from a compromised government email channel. Because the registration arrived through what appeared to be a legitimate institutional source — a verified government email domain — the request passed our then-standard verification process. This is consistent with the pattern documented by the FBI: when the upstream institutional channel itself is compromised, downstream verification based on that channel will produce a false positive.
The incident did not involve any compromise of Onion Mail’s or Onion Search Engine LLC’s technical infrastructure. Our systems were not breached. The attack succeeded against the verification process, not against the systems.
Our internal monitoring identified anomalies in the activity of this account. Access was suspended, the account was revoked, and our verification procedures were strengthened to add controls beyond email domain verification alone. The platform itself has been taken offline while we restructure its access procedures to reflect the changed threat environment.
We are documenting this incident here because we believe it illustrates exactly the dynamic that this article describes, and because we believe service providers have a responsibility to be transparent when their processes encounter the limits of prevailing industry assumptions. The same continuous monitoring approach that identified anomalies on the law enforcement platform has also been applied on the Onion Mail side, where suspicious patterns in law enforcement correspondence have led us to revoke cooperation with specific channels when verification anomalies were detected.
How Onion Search Engine LLC Will Operate Going Forward
In light of the documented compromise of government email channels as a verification factor, our processes are evolving. We will continue to cooperate with legitimate law enforcement authorities through means required by applicable law. What is changing is how requesters are verified.
Verification will no longer rely on any single factor, including the apparent authenticity of a government email domain. Multi-channel verification, independent confirmation of officer identity through institutional contacts established through verified means, and procedural controls beyond document review will form part of our process going forward. We are not publishing operational details of these controls because doing so would assist precisely the threat actors this article describes.
This evolution does not represent a withdrawal from our legal obligations. Onion Search Engine LLC remains a United States company subject to United States law and will continue to respond to lawful process. What is changing is the standard of evidence we apply before we accept that a request originates from the agency it claims to represent.
For Law Enforcement: How to Reduce Exposure to Impersonation
We recognize that the institutions most affected by this category of abuse are the legitimate law enforcement agencies whose credentials are being stolen and impersonated. We offer the following observations, which are consistent with general security best practices:
Officer credentials used for institutional email should be protected by multi-factor authentication using hardware tokens or comparable mechanisms rather than SMS-based codes. Institutional email systems should monitor for anomalous access patterns, particularly authentication from unexpected geographic locations or through anonymizing networks. Outbound legal requests to service providers should, where possible, be transmitted through documented and verified channels rather than ad-hoc email, and provider responses should be expected through the same channels. Agencies that believe their credentials or those of a colleague may have been compromised should contact affected providers through verified institutional channels and consider notifying the FBI through IC3.
These are not new recommendations. They are the recommendations that the threat landscape has now made unavoidable.
Our Position
Onion Mail exists to protect the privacy and anonymity of its users. These values are not slogans; they are encoded in the technical architecture of the service. Users access through Tor or VPN, encrypt their messages with PGP, recover their accounts without phone numbers, and verify the state of their own protection through indicators built into the product. The provider, by design, holds less information about the user than the user has the option to share.
These values are fully compatible with operating as a legal company. Onion Search Engine LLC is a registered United States company that complies with the laws applicable to it. Privacy protection and legal compliance are not in tension when the service is designed correctly. We protect users from unlawful surveillance, abusive impersonation, and the compromise of institutional channels they have no power to control. We cooperate with legitimate authorities through verified means, within the framework of the law.
We are not, and have never been, a service designed to assist those seeking to evade legitimate legal oversight. We are also not a service that will treat fraudulent requests as legitimate simply because they arrive through channels that the industry has, until now, treated as authoritative.
The model of trust that the industry has used for law enforcement verification is changing because the threat environment has changed. This article is part of our response to that change: a public, documented, verifiable statement of what we do, what we have done, what we have learned, and how we will operate going forward.
For further information, our Privacy Policy and Terms of Service describe in detail the legal framework within which Onion Mail operates. Users wishing to verify the state of their own account security can do so at any time at https://onionmail.org/account/security/events.