Property Tax Notice, Wrong Sender: How a Throwaway Domain Impersonated a County Government

The email arrived with a display name of "County of Santa Clara" and a subject line about a property tax payment deadline of December 10, 2025. The body read like every other official county notice: real phone number, real physical address, real email contact for the tax assessor's office, and a link to the actual county payment portal at payments.sccgov.org.

If a recipient checked the links, they resolved to the legitimate county website. If they called the phone number, it would ring the actual tax office. If they looked up the address, it matched the county's published location.

The sending domain was telleronline[.]net. It had no affiliation with Santa Clara County.

The Anatomy of a Clean Impersonation

The From header displayed "County of Santa Clara" as the sender name, but the envelope address was noreply@telleronline[.]net. This is the classic email spoofing displacement technique: use a display name the recipient recognizes and trusts, while the actual sending domain is something entirely different.

telleronline[.]net was registered in 2020 through Amazon Registrar with privacy-protected WHOIS. There is no publicly verifiable connection between the domain and any county government. The domain has no corporate website, no social presence, and no business registration that ties it to public sector services.

The real county domain, sccgov[.]org, tells a very different story. It has a long-standing registration, with nameservers (ns01.santaclaracounty[.]gov and ns02.santaclaracounty[.]gov) owned and operated by the county itself. The contrast between an established, government-owned nameserver infrastructure and a privacy-shielded commercial registrar registration is stark.

What the attacker did well was to avoid the most common mistakes in email spoofing attacks. There were no lookalike domains in the links. There were no typosquatted URLs. Every clickable element in the body resolved to the real county infrastructure. The attacker understood that the payment link itself was not the fraud vector: the fraud was the conversation that would follow if a confused or pressured recipient replied, called a spoofed number, or was directed to a fraudulent payment page in a follow-on message.

Why Legitimate Links Do Not Mean a Legitimate Email

The presence of real county links created a specific detection gap. URL-scanning tools, sandbox detonation systems, and link-rewriting gateways would analyze the URLs in this message and return clean results. payments.sccgov.org/propertytax is a legitimate government payment portal. It is not a phishing page. It does not serve malware. Any system that assigns trust based on link destination would rate this email as safe.

This is a documented technique shift. Attackers who understand how Secure Email Gateways evaluate content have moved away from hosting phishing infrastructure on attacker-controlled domains. Instead, they embed real content, real links, and real contact details, counting on the recipient to either be deceived into compliance or to follow up through an attacker-controlled channel introduced in a second stage of the campaign.

The Verizon 2024 Data Breach Investigations Report documented social engineering as the leading technique in financially motivated breaches. Property tax impersonation targets a predictable window: tax payment deadlines create urgency, and the consequences of missing a government deadline feel serious enough to override normal skepticism.

See Your Risk: Calculate how many threats your SEG is missing

The Detection Surface Was One Mismatch

The entire case for flagging this email rested on a single observable fact: the display name claimed to be a county government and the sending domain had no relationship to that government.

This is the detection surface that authentication-only systems cannot see. DMARC, SPF, and DKIM do not verify display names. They verify whether the sending infrastructure is authorized for the sending domain. telleronline[.]net could have had a perfectly configured DMARC policy, valid SPF records, and a passing DKIM signature, and none of that would tell a receiving system that "County of Santa Clara" is a lie.

Behavioral and identity-layer analysis closes this gap. Matching display names against known impersonation targets (government entities, financial institutions, healthcare organizations) is a signal category that operates independently of authentication results. When a display name matches a known public entity but the sending domain has no verifiable connection to that entity, the mismatch is the alert.

Themis, the IRONSCALES platform AI, flagged this message on that basis. No link was malicious. No attachment was present. No urgency language was unusual for a tax notice. The flag was the identity mismatch: a display name claiming government authority, a sender with no credentials to that claim.

Why This Pattern Scales

The operational cost of this attack was low. The attacker did not need to build a phishing page. They did not need to register a lookalike domain. They copied a legitimate government notice, swapped the sending address, and waited. The same template could be reused against any county's tax season with trivial modifications.

That scalability is what makes display-name government impersonation a persistent threat category. The technical barrier is near zero. The template quality is as high as the government's own communications. And the detection surface is invisible to anyone whose security stack stops at authentication and link scanning.

Indicators of Compromise

MITRE ATT&CK Mapping