Funding Agreement, Forged Approval: How a Three-Layer Redirect Chain Targeted Finance Leadership

The subject line read "Please Approve: Funding Agreement Document." The sender, an obscure Italian domain routed through Amazon SES (Simple Email Service), addressed the recipient by first name, claimed the document came from the recipient's own organization's finance department, and presented a polished PDF-viewer interface with a single black button: View PDF.

Behind that button sat a three-layer redirect chain designed to survive every automated scanner between the attacker's infrastructure and the victim's browser.

The target: a VP of Finance. The pretext: an approval workflow that finance leaders process dozens of times a month. The intent: credential theft.

A Document Notification Built to Exploit Approval Fatigue

The email arrived at 23:58 UTC on a Thursday evening, timed to land when security teams are thin and approval queues feel urgent. The HTML rendered a convincing document-notification template: a blue app icon labeled "DOCUMENT," a banner reading "Notification of Signed Document," and body copy stating that a funding agreement had been shared by the target organization's finance team for approval.

The formatting was deliberate. The template mimicked SaaS document-sharing platforms that finance teams interact with daily: DocuSign, PandaDoc, Adobe Sign. The body text even addressed the recipient by first name, pulling from reconnaissance or scraped directory data. But several forensic anomalies surfaced on inspection: a stray token ("lior") orphaned in the body text, inconsistent spacing around the banner copy, and no sender display name, just the raw info@[redacted-domain][.]com address.

These are the fingerprints of a phishing kit, a templated HTML payload where variable substitution failed to clean up after itself. The Verizon 2025 Data Breach Investigations Report found that phishing appeared in 36% of breaches involving external actors, with document-approval pretexts ranking among the most effective social engineering lures against finance and executive targets.

Three Redirects, Three Trust Layers

The campaign's technical sophistication lived in its link architecture: a three-layer redirect chain that exploited trusted infrastructure at every hop.

Layer 1: Cisco Secure Web redirect. The primary CTA button wrapped the malicious destination inside a secure-web[.]cisco[.]com URL rewriter. Cisco's Secure Web gateway is a legitimate security tool that rewrites URLs for click-time scanning. Attackers exploited this by encoding their payload URL inside the Cisco redirect, leveraging Cisco's domain reputation to pass URL-reputation checks at the Secure Email Gateway (SEG) level.

Layer 2: Argentinian landing domain. The Cisco redirect resolved to hxxp://waterpowerinn[.]com[.]ar/12, a domain with no relationship to document signing, finance, or the purported sender. The use of a .com.ar ccTLD (country-code top-level domain) and bare HTTP (no TLS encryption) are hallmarks of compromised infrastructure repurposed as a redirect waypoint.

Layer 3: Display-URL spoofing. Below the CTA button, a fallback link displayed hxxps://[TargetOrg][.]haystack[.]so/post/[UUID], visually suggesting the document was hosted on a platform associated with the target organization. But the actual href pointed to hxxps://4creeks[.]haystack[.]so/post/[UUID], a completely different subdomain. This display/href mismatch is a textbook credential-harvesting technique documented under MITRE ATT&CK T1566.002 (Spearphishing Link) and T1036.005 (Masquerading: Match Legitimate Name or Location).

The redirect chain served a dual purpose: each hop added a layer of domain-reputation laundering, and the multi-step resolution made it harder for sandboxed URL scanners to follow the full chain to the terminal payload. CISA's guidance on evolving phishing techniques highlights redirect-chain abuse as a growing evasion method precisely because automated tools often evaluate only the first-hop URL.

Authentication Passed, But the Domain Didn't

The relay analysis revealed a textbook case of infrastructure-versus-identity mismatch.

• SPF: Pass, but only for the Amazon SES envelope domain (eu-west-1[.]amazonses[.]com), not the claimed From: header domain
• DKIM: Failed for the sender's domain; passed only for amazonses[.]com
• DMARC: Failed for the From: domain, but with action=none, meaning the message was delivered anyway
• CompAuth: Failed (reason=001): Microsoft's composite authentication flagged the mismatch but took no blocking action

The sending IP 54[.]240[.]3[.]30 geolocated to the United States and belongs to Amazon SES's EU-West-1 region. The sender domain, registered in 2020 with GDPR-masked WHOIS data, showed no public organizational identity. Amazon SES is a legitimate cloud email service used by thousands of businesses, but like any cloud infrastructure, it can be provisioned by attackers who obtain credentials or create trial accounts.

This pattern, SPF passing for the relay infrastructure while DKIM and DMARC fail for the claimed identity, is exactly the gap that authentication-only defenses leave open. As the FBI's 2024 Internet Crime Report documented, BEC and phishing schemes accounted for $2.7 billion in losses, with infrastructure abuse increasingly cited as a key enabler. IBM's 2024 Cost of a Data Breach Report found that phishing-initiated breaches carried an average cost of $4.88 million, and credential theft was the most common initial access vector.

How Behavioral AI Caught What Authentication Missed

Themis, the IRONSCALES agentic SOC analyst, classified this email as phishing with 90% confidence and quarantined it before the recipient engaged. The detection relied on three converging behavioral signals:

1. Link-mismatch detection. The display text showed one haystack.so subdomain while the href pointed to another, a deception pattern that static URL scanners evaluating only the href would miss, but behavioral analysis flags as deliberate obfuscation.
2. Community intelligence. The IRONSCALES community network had already cataloged similar funding-agreement pretexts using haystack.so infrastructure. Community-level pattern matching identified the campaign before any single IOC was blocklisted.
3. Sender behavioral anomalies. Although the sender had previously emailed the organization, DKIM/DMARC failure combined with a VIP recipient in the finance department triggered elevated risk scoring. The sender's domain, privacy-masked with no verifiable organizational identity, compounded the risk assessment.

The affected mailbox was quarantined within seconds of delivery. No recipient interaction with the redirect chain was recorded.

For security teams facing document-approval phishing campaigns, four actions matter now:

1. Enforce DMARC rejection policies. A p=none DMARC policy is a monitoring tool, not a defense. Move to p=quarantine or p=reject to prevent delivery of messages that fail domain authentication.
2. Treat display/href mismatches as high-confidence indicators. Any email where the visible link text doesn't match the underlying URL should be automatically escalated. This is not a gray area.
3. Audit SES and cloud email configurations. If your organization uses Amazon SES, review authorized sending identities and monitor for unauthorized domain configurations. Attackers increasingly provision cloud email services as disposable relay infrastructure.
4. Layer behavioral AI over authentication. Email authentication protocols verify sender infrastructure. They cannot evaluate whether a funding agreement is real, whether a redirect chain is malicious, or whether the recipient is being socially engineered. That requires AI that understands intent, not just identity.

Indicators of Compromise