Three Security Vendors, One Credential Harvest: How Attackers Turned Protection Into Cover

Most phishing redirect chains try to hide behind one trusted intermediary. This one used three.

A credential harvesting campaign we recently intercepted threaded its malicious payload through three separate security vendor URL protection services, each one functioning as a trusted relay hop. The redirect chain ran from an ESVALabs URL sandbox to Inky email security to TitanHQ LinkLock, before finally landing on a credential capture page hosted on a compromised medical systems domain. Every link scanner that evaluated the chain saw a legitimate security vendor domain and returned a clean verdict. The final destination, where the actual theft happens, was buried three layers deep.

What makes this attack particularly effective is the combination: a triple-layer vendor redirect chain, a fabricated nonprofit reply thread grafted below the CTA for contextual credibility, and full DKIM/DMARC authentication via Amazon SES from a compromised OB/GYN practice domain. Each component alone is a known technique. Stacked together, they created an attack that passed every static check thrown at it.

Delivery Infrastructure and the Authentication Paradox

The email originated from info@gardenobgyn[.]com, a legitimate medical practice domain. The attacker sent it through Amazon SES, which meant SPF validated against amazonses[.]com, and DKIM signatures verified for both gardenobgyn[.]com and amazonses[.]com. DMARC passed cleanly. The Microsoft Digital Defense Report 2024 documented this exact pattern: attackers compromising legitimate domains to inherit their authentication posture, turning email security protocols into accomplices.

The sender display name was a garbled string of repeated characters ("eDocxeDocx6369815oekr..."), a deliberate obfuscation that looks like automated noise to casual inspection but would be flagged immediately by anyone scrutinizing the headers. The email targeted a specific individual at a European organization, arriving as a first-time external sender with a high risk score.

The Triple Vendor Redirect Chain

The primary call-to-action, a blue "COMPLETE NOW" button styled after DocuSign review notifications, initiated the redirect chain:

Hop 1: hxxps://urlsand[.]esvalabs[.]com/?e=2b89e387&f=y&... (ESVALabs URL sandbox service)

Hop 2: hxxps://shared[.]outlook[.]inky[.]com/link?domain=linklock[.]titanhq[.]com&t=... (Inky email security, encoding the next hop)

Hop 3: hxxps://linklock[.]titanhq[.]com/analyse?data=... (TitanHQ LinkLock URL protection)

Final destination: hxxps://secure[.]medisystemvzla[.]com/ (credential harvest landing page on a compromised Venezuelan medical systems domain)

This architecture is strategic, not accidental. Each hop traverses a domain owned by a legitimate email security or URL protection vendor. Traditional URL scanners evaluating the first hop see esvalabs[.]com and return a clean verdict. Scanners following one redirect deep see inky[.]com or titanhq[.]com, both known security companies, and again score it clean. According to the Verizon DBIR 2024, credential harvesting remains the primary objective in 44% of phishing attacks, and redirect chains are a growing evasion mechanism. Only full-depth chain resolution, walking all the way to medisystemvzla[.]com, reveals the attack.

The email also embedded an inline visible URL pointing to fb[.]com, a text-link mismatch that created an additional layer of misdirection. The visible Facebook domain served as a decoy anchor, making the email body appear to reference a known social platform while the actual CTA resolved elsewhere entirely.

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

Thread Grafting: Manufacturing Context From Thin Air

Below the CTA, the email contained an extensive fabricated reply chain involving a nonprofit organization called Questscope. The grafted thread included project-specific financial details, named individuals with organizational titles, bank information requests, contact tables with phone numbers, and references to grant disbursement schedules. The conversation spanned multiple dates and included CC lists with credible-looking email addresses.

This is thread grafting operating at a high level of detail. The fabricated context served two purposes: it made the email appear to be part of an active, legitimate business conversation, and it buried the malicious CTA under layers of seemingly authentic correspondence. The technique maps to MITRE ATT&CK T1566.002 (Phishing: Spearphishing Link) with a social engineering overlay that exploits the tendency of busy recipients to focus on the top-level action rather than scrutinizing the entire message body.

The FBI IC3 2024 Report documented $2.9 billion in BEC losses, with thread grafting and conversation hijacking identified as increasingly common techniques in sophisticated campaigns.

Why Static Scanners Failed (and What Caught It)

Here is the central problem with this attack from a defensive perspective: every individual component looks legitimate in isolation. The sender domain passes authentication. The redirect chain traverses known security vendor domains. The email attachment (a DocuSign-branded PNG, clean by binary analysis) contains no executable payload. Standard URL scanners returned clean or partial verdicts across the board.

IRONSCALES Adaptive AI flagged the attack through behavioral pattern analysis rather than URL reputation alone. The detection correlated multiple anomalies: a first-time external sender with a garbled display name, a CTA link encoding multiple redirect hops through unrelated security vendor domains, a visible link pointing to fb[.]com while the actual target resolved to a Venezuelan medical domain, and a grafted reply thread with no prior communication history with the recipient. The community intelligence layer added confidence through correlation with similar incidents reported across other organizations.

The incident was automatically resolved as phishing. Four affected mailboxes were quarantined within 39 minutes of delivery.

IOC Table

What This Means for Your Defenses

This attack exposes a specific blind spot: security vendor trust inheritance. When your URL scanner evaluates a link and sees inky[.]com or titanhq[.]com in the chain, it naturally assigns a higher trust score. Attackers know this. They are deliberately routing through these services to inherit that trust.

Three defensive adjustments matter here:

1. Full-depth redirect chain resolution. Your email security needs to walk redirect chains to the terminal destination, not just evaluate the first hop. If your SEG stops at hop one, you are effectively blind to the payload.

1. Behavioral sender analysis beyond authentication. DKIM/DMARC passing is necessary but insufficient. First-time sender status, display name entropy (garbled character strings), and domain-context mismatch (a medical practice sending document review requests to a security company) all matter more than SPF results.

1. Link-text mismatch detection. When visible anchor text points to fb[.]com but the underlying href resolves to an unrelated domain, that discrepancy alone warrants elevated scrutiny. According to NIST, deceptive link presentation remains a core phishing indicator that static scanners often miss when the visible domain itself is reputable.

The attackers behind this campaign did not invent new techniques. They combined existing ones (authenticated sending, multi-hop redirects, thread grafting, link-text decoys) into a stack that defeated every point solution in the delivery path. That layering strategy is becoming the norm, not the exception.