The HR Email Where the Signature and the Reply Button Led to Different Companies

The signature said hr@lombard[.]finance. The mailto behind it pointed to fortunato@carpenterhomeloans[.]com. Two different companies, two different domains, embedded in the same email and presented as the same identity.

That mismatch is the kind of detail a recipient in the mortgage industry would never notice. The display text looks right. The From address looks plausible. The body is personalized with the target's first name. Everything about this email was built to survive a quick glance from someone who processes HR notifications as part of their workday.

What made it dangerous was not just the social engineering. It was the infrastructure underneath: a sending domain authenticated through Amazon SES, a displayed URL referencing a real NMLS license number on a subdomain that does not exist in DNS, and a redirect chain that routed the actual click through two legitimate security vendor URL-rewriting services before landing on a credential harvest page.

Two Identities in One Signature Block

The email arrived from sch.sisconthosting[.]com, a subdomain of a Peruvian-registered hosting domain created in 2020 via PublicDomainRegistry. Amazon SES handled delivery from the eu-west-1 region. SPF passed for the SES sending infrastructure. DKIM signatures validated for both sch.sisconthosting[.]com and amazonses.com. DMARC returned p=none, which means the sending domain published a policy but chose not to enforce it.

The signature block displayed hr@lombard[.]finance as the contact address. Visually, this positioned the sender as the HR department at a legitimate financial services company. But the mailto link wired behind that text pointed to fortunato@carpenterhomeloans[.]com, an entirely different organization.

This is Masquerading (T1036.005) applied to email identity rather than filesystem objects. The attacker matched a legitimate name and location (the HR function at a known finance brand) while hiding the real action destination. Recipients who hover over a signature link before clicking, if they hover at all, would see a domain that has nothing to do with the displayed address. Most recipients do not hover.

The Subdomain That Does Not Exist

The body contained a "Login and complete tasks" call-to-action with a displayed URL: hxxps://9168050941.lombard[.]finance/1445910/pos/app/9168050941/tasks/tasks-list. The numeric prefix 9168050941 is a real NMLS license number, the kind of identifier that anyone in the mortgage industry would recognize as a regulatory credential.

That subdomain does not resolve in DNS. There is no A record, no CNAME, nothing. It was never meant to be visited directly. Its purpose was purely visual: to display a URL that looked like an internal task management portal tied to a real regulatory license, lending the email a layer of authority that a generic phishing link could never achieve.

The FBI IC3 2024 Internet Crime Report documented over $2.9 billion in business email compromise and phishing losses. Financial services targets are disproportionately represented because attackers can reference real regulatory identifiers, account numbers, and compliance terminology that make lures immediately plausible.

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

Two Vendor Gateways, One Credential Harvest

The actual click did not go anywhere near lombard[.]finance. The link behind the CTA resolved to a redirect chain with three hops:

Hop 1: TitanHQ LinkLock (linklock[.]titanhq[.]com). TitanHQ is a legitimate email security URL protection service that rewrites links and scans destinations before users reach them. The attacker encoded the next hop inside TitanHQ analysis parameters.

Hop 2: Securence URL Shield (url-shield[.]securence[.]com). Securence provides another URL-rewriting layer, typically deployed by ISPs and managed service providers. The attacker chained the payload URL inside the Securence wrapper, adding a second legitimate security vendor domain to the path.

Hop 3: sch.sisconthosting[.]com/docs/index.html. The terminal destination. A login prompt with "Login and complete tasks" text, hosted on the same domain that sent the email. IP: 185[.]181[.]254[.]184. Self-hosted MX. The credential harvest page and the sending infrastructure were the same server.

A URL reputation check that stops at the first hop sees a TitanHQ domain. One that follows to the second hop sees Securence. Neither domain is malicious. The terminal destination, the one that actually asks for credentials, is two layers deep and invisible to scanners evaluating the outermost wrapper. This is the same structural problem documented in MITRE ATT&CK T1566.002 (Phishing: Spearphishing Link): the gap between what a scanner evaluates and what the user ultimately reaches.

The Behavioral Signals That Caught It

The email passed every authentication check. SPF, DKIM, DMARC. The URL passed through two security vendor scanners. The body was professionally formatted with a personalized greeting and a 1x1 tracking pixel for delivery confirmation.

IRONSCALES Adaptive AI flagged this email based on signals that exist outside the authentication and URL evaluation layers. The sender had never contacted this organization before. The identity fragmentation across the display name ("HR"), the signature address (lombard[.]finance), the hidden mailto (carpenterhomeloans[.]com), and the actual sending domain (sisconthosting[.]com) triggered pattern detection for multi-identity spoofing. And community intelligence from the IRONSCALES network had already surfaced campaigns using dual-vendor redirect chains through similar infrastructure.

Authentication tells you the email came from where it claimed. It does not tell you whether the signature and the reply button lead to the same place.

Indicators of Compromise

What Makes Display-Versus-Action Mismatches Hard to Catch

Most email security tools evaluate the From header, the authentication chain, and the URLs in the body. They do not compare the text displayed in a signature block against the mailto link wired behind it. That comparison requires rendering the email as a user would see it and evaluating whether the visual identity and the functional identity match.

Three practices address this specific pattern:

Treat signature mailto mismatches as a high-confidence indicator. When the displayed email address and the underlying link point to different organizations, the email is misrepresenting its origin. Build detection logic that compares rendered text against action URIs in signature blocks.

Do not trust displayed URLs that reference regulatory identifiers. NMLS numbers, EIN numbers, and license references in URLs create false authority. If the domain hosting those identifiers does not resolve or was registered recently, the regulatory reference is decoration, not authentication.

Resolve redirect chains to their terminal destination. Two security vendor wrappers in a chain are not two layers of protection. They are two layers of obfuscation when the terminal URL was never scanned independently. Evaluate the final hop, not the intermediaries.

The gap between what this email displayed and what it actually did was the entire attack. The signature said one company. The mailto said another. The URL showed a subdomain that does not exist. And the click went through two security vendors before reaching the harvest page. Every layer was designed to survive exactly one check and not a second.