When a Hospital's Name Becomes the Phishing Bait

A forwarded invoice thread arrived in the inbox of a security-operations analyst at a managed security services provider. It looked like the tail end of an ordinary vendor conversation: a request for quote, two past-due amounts, and a hard payment deadline at the end of the month. One link sat in the body, and it displayed as SHARED RFQ#42810_View Documents.pdf, the kind of thing an accounts-payable team clicks a hundred times a week.

The link was not a PDF, and it did not point where it appeared to. It resolved to an unrelated domain registered in 2017 with privacy-masked WHOIS, hosted on a server whose reverse DNS resolved to a hosting provider in Bogota, Colombia. What made the lure clever was the shape of the URL itself.

The Trick Is in the Path, Not the Domain

Most people are trained, loosely, to look for a lookalike domain. They scan for the misspelled brand, the extra hyphen, the odd top-level domain. This attacker skipped that entirely and worked one layer down, in the path.

The destination read as hxxps://linaforeroactriz[.]com/[regional-hospital]/index[.]html, where the bracketed segment was the exact name of a real regional hospital referenced in the invoice thread. The host, linaforeroactriz[.]com, has no connection to that hospital or to any healthcare organization. It is throwaway infrastructure. But a reader who half-glances at the link sees the hospital's name and reads the whole string as legitimate, because the familiar word is right there in front of them.

That is the entire technique. Put the trusted name after the first single slash, where the eye expects context rather than identity, and let the reader's pattern-matching do the rest. The server that actually answers the request is the domain that sits before that slash, and it is attacker-controlled. This is masquerading by placement, and it is why link inspection has to parse structure rather than search for a string.

The Hospital DKIM That Passed, Then Broke

The authentication trail on this message tells a two-act story, and both acts matter.

At an early hop, the message carried valid authentication for the hospital's own domain. Sender Policy Framework (SPF) passed, DKIM passed, and DMARC passed under a policy of p=none. In other words, the thread genuinely originated in, or was crafted to inherit, the hospital's mail identity, and it looked clean coming out of the gate.

Then it traveled. The message was forwarded and relayed through multiple legitimate security gateways, including Mimecast and Sophos, with Sender Rewriting Scheme envelope rewriting along the way. Somewhere in that chain the body was modified or re-injected, and the downstream result was decisive: DKIM failed on a body-hash mismatch across two signing domains, DMARC failed because SPF no longer aligned, compauth logged as none, and the ARC chain itself was marked cv=fail, a reject verdict on the forwarded evidence.

This is the practical bind that forwarded-thread lures create. The early-hop pass is what a casual header review or a trusting analyst latches onto. The late-hop failure is the truth, and it only surfaces if the receiving system evaluates the full relay chain rather than the friendliest signature in it. A forwarded invoice that once passed the sender's DKIM is not the same thing as a message you can trust now.

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

Mapping to MITRE ATT&CK

The tradecraft maps cleanly to a handful of techniques in the MITRE ATT&CK framework:

• T1566 Phishing and T1566.002 Spearphishing Link cover the delivery: a socially engineered invoice thread whose payload is a single link.
• T1204.001 User Execution: Malicious Link covers the required human action, a click on a link disguised as a document.
• T1036.005 Masquerading: Match Legitimate Name or Location covers the brand-in-path stuffing, the hospital's real name dropped into the URL path to borrow legitimacy the host never earned.

Indicators of Compromise

Detection and What to Watch For

Signature and reputation checks were never going to catch this cleanly. The domain was aged, the hosting was generic, and the message rode legitimate gateway infrastructure. Detection has to read intent. The signals that matter are a link whose host and displayed context do not agree, a trusted name appearing in a URL path rather than a domain, a forwarded invoice thread with a hard payment deadline, and an authentication chain that passes early and fails late.

This is where IRONSCALES adds a layer static gateways miss. Themis, the Adaptive AI analyst on the IRONSCALES platform, evaluates the relationship between the claimed identity, the actual host behind a link, and the full relay history the way a trained analyst would, flagging the deception even when a friendly early-hop signature says everything is fine. That link-structure analysis is core to advanced malware and URL attack protection, which parses where a link truly resolves rather than trusting how it displays.

The economics explain why invoice fraud keeps arriving. The 2024 Verizon Data Breach Investigations Report puts the human element in 68 percent of breaches and names pretexting, largely business email compromise, as the top social-engineering incident type, with a median BEC transaction near 50,000 dollars. The Microsoft Digital Defense Report 2024 documents the same drift toward abusing trusted services and infrastructure rather than breaking them. The FBI's 2023 Internet Crime Report likewise ranks business-identity and vendor-invoice fraud among the costliest categories reported, which is precisely the lever this thread pulled.

The Takeaway

Attackers no longer need a convincing domain when a convincing path will do. The name a reader trusts can sit one slash away from the server that actually answers, and most eyes never make the distinction. The defense is a habit and a control working together: teach people to read the host and not the path, and back that habit with detection that inspects link structure and the whole authentication chain instead of the single signature that happens to pass. See where invoice fraud and impersonation hide in your own mail flow before the next forwarded thread arrives, and treat every borrowed name as a claim to verify. CISA's guidance on recognizing and stopping phishing early is a solid reference for building that reflex across a team: https://www.cisa.gov/resources-tools/resources/phishing-guidance-stopping-attack-cycle-phase-one