Law enforcement email compromise sits in an awkward gap. It is not quite phishing, because the attacker is not imitating anyone. It is not quite insider abuse, because the account holder is a victim. It is the use of a legitimate credential to make an illegitimate demand, and it breaks the assumption that most data request programmes are built on: that an email from a police domain came from the police.
How law enforcement email compromise works
The attack has three stages, and only the last one touches the target company.
- Acquire the account. The attacker obtains credentials for a genuine law enforcement or government mailbox, typically through credential stuffing against reused passwords, a phishing campaign aimed at the agency, or credentials bought from an initial access broker. Small agencies are disproportionately targeted because they are less likely to enforce multi-factor authentication.
- Study the format. Real legal process has a house style. Attackers read genuine requests already in the mailbox and copy the letterhead, case number format, statutory citations, and signature blocks.
- Send the request. The fraudulent request goes out from the real account, usually framed as an emergency so that it is triaged quickly and reviewed lightly.
Because stage three uses authentic infrastructure, the request passes every technical control that inspects the sender rather than the person.
Why standard verification fails
Most intake processes verify the channel, not the human. They check that the sending domain belongs to a real agency, that SPF and DMARC pass, and sometimes that the domain appears on an allowlist. Every one of those checks confirms something that is genuinely true during a LEEC attack.
| Spoofed request | LEEC request | |
|---|---|---|
| Sending domain | Imitated or lookalike | Genuine agency domain |
| SPF / DKIM / DMARC | Typically fails | Passes |
| Domain allowlist check | Fails | Passes |
| Reply-to inspection | Often mismatched | Matches the real mailbox |
| What actually catches it | Email authentication | Out-of-band identity verification |
The practical consequence is that a company can do everything its runbook asks and still disclose subscriber data to a criminal.
What it means for a company receiving requests
Treat the mailbox as untrusted infrastructure. If your process can be satisfied by anyone holding the password to a police inbox, then the security of your users’ data is only as strong as the password policy of the smallest agency that has ever contacted you, and you have no visibility into that.
Three things move the needle:
- Verify the individual, not the domain. Confirm the named officer is serving, is attached to the agency named, and is authorised to make the request.
- Use an independently sourced callback number. Never a number supplied in the request itself, which the attacker controls.
- Keep emergency requests inside the process, not around it. Urgency is the pressure an attacker applies deliberately. A fast path is reasonable; an unverified path is not.
How to tell a real emergency request from a fraudulent one
There is no single tell, which is the point. Useful signals are behavioural rather than technical: a request for an account with no plausible connection to the agency’s jurisdiction, an officer who has never contacted you before combined with unusual urgency, resistance to a callback, or a scope that is broader than the stated emergency would justify. None of these are proof on their own. All of them are reasons to verify before disclosing.