When Your Security Vendor's Email Delivers the Attack: ThreatDown Notification Hijacked Mid-Transit

A security notification from a cybersecurity vendor should be the last place you expect a phishing attack to hide. That assumption is precisely what attackers exploited in this case.

In early May 2026, a VP at a small technology services firm received what appeared to be a routine "EFS Threat Detection Notification" from a well-known endpoint security vendor. The email looked legitimate: the sender address matched the vendor's domain, the layout replicated the vendor's actual notification template, and familiar action links like "View Detection" and "View Endpoint" were present throughout. What the recipient could not see was that the email had been modified somewhere in its relay chain before it arrived, and one of those action links now routed through attacker-controlled infrastructure.

How a Legitimate Notification Became a Delivery Vehicle

The email's original path was clean. Amazon SES sent the message on behalf of the vendor's domain, and at the first receiving hop the authentication results confirmed it: SPF passed, DKIM passed against the vendor's selector, and DMARC passed for the header From address. Nothing in the initial authentication picture raised concern.

The problem surfaced at the next relay hop. The message passed through an outbound security gateway (a Barracuda ESS appliance) before reaching the Microsoft 365 destination. At that point, the authentication picture changed completely. SPF softfailed against the relay IP (209[.]222[.]82[.]242), DKIM failed because the body hash did not verify, and DMARC issued a reject action. This pattern, clean auth at origin followed by authentication collapse at a downstream relay, is the forensic signature of body modification in transit.

The mechanism is well-documented: security gateways that perform link rewriting, URL scanning, or message transformation will modify the email body, invalidating any DKIM signature that covers it. Normally this happens to add protection. Here, the link rewrite inserted an attacker-controlled redirect rather than a security wrapper.

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

The Redirect Chain: Two Hops to Obfuscation

The injected link pointed to 2.whichbrisk[.]com. WHOIS records confirm the domain was registered on December 17, 2025, with privacy-shielded registration through GoDaddy and Cloudflare nameservers. A domain less than five months old carrying no registrant details has no legitimate business context as a security-vendor notification host.

That first hop served a single purpose: a 301 redirect to hxxps://html-load[.]com/. The redirect was immediate, providing no content of its own, functioning purely as a link-laundering intermediary. The final destination returned an HTTP 200 response but did not present obvious credential-harvesting forms at scan time, suggesting the page may serve different content based on browser fingerprint, user-agent, or geographic origin, a common technique for evading static sandbox analysis.

IRONSCALES Themis flagged the malicious link within the message and identified the VIP nature of the target recipient, allowing rapid mitigation. The message was reverted from the affected mailbox before the recipient acted on it. The Verizon DBIR 2026 notes that 16% of breaches involve phishing as initial access; this case shows that number includes attacks delivered through ostensibly trusted vendor channels, not only cold-outreach lures.

Why Recipient Behavior Alone Could Not Catch This

This attack is worth examining because standard end-user security training would have offered limited protection. The domain in the From header was the vendor's own domain. The email was a real notification format that the recipient might genuinely expect to receive. The malicious link's display text was 2.whichbrisk.com, which is at least visible rather than hidden behind clean anchor text, but display URLs are often ignored by users focused on the action the email is requesting.

Phishing defenses that rely on static link reputation checks also face a structural disadvantage here. The final destination (html-load[.]com) was registered well before the attack and would not necessarily appear on fresh blocklists. The redirecting domain (whichbrisk[.]com) was only five months old and therefore had limited threat-intelligence coverage. The MITRE ATT&CK framework classifies this as Spearphishing via Link (T1566.002) combined with masquerading under a trusted brand identity.

For organizations relying on a secure email gateway (SEG) as their primary filter, the IRONSCALES platform data shows SEGs miss an average of 67.5 phishing emails per 100 mailboxes per month. Redirect chains specifically exploit the fact that SEGs typically evaluate the URL at scan time, not at click time, and a 301 redirect to a staged page can bypass that window entirely. The Microsoft Digital Defense Report 2024 similarly notes that multi-hop redirect chains are a primary technique for evading gateway URL analysis.

Relay-Tampering IOC Registry

Treating Vendor Security Emails Like Any Other Untrusted Message

The practical lesson here is uncomfortable: security notifications from your own security vendors deserve the same link scrutiny as cold-outreach phishing attempts. An attacker who can position a modifying relay in the message path, or compromise a relay that handles vendor mail, can abuse the trust relationship between the vendor and its customers.

Security operations teams should configure advanced malware and URL attack protection that performs click-time URL evaluation, not only scan-time evaluation. For this attack specifically, DKIM body-hash failures on messages claiming to come from known security vendors should be treated as high-priority investigation triggers rather than routine authentication noise. The CISA phishing guidance recommends verifying the legitimacy of any action request by navigating directly to the sender's portal rather than following email links, advice that applies with equal force to security vendor notifications.

Organizations that augment their existing Microsoft 365 environment with layered behavioral analysis gain the ability to catch in-transit tampering signals that the native filtering stack does not surface. M365 augmentation solutions evaluate authentication timeline mismatches, per-hop reputation, and link-redirect depth as part of a unified behavioral analysis layer rather than relying on a single-hop verdict.

The IBM Cost of a Data Breach 2024 report (IBM) puts the average breach cost at $4.88 million. NIST defines phishing as a technique that uses deceptive communications to acquire sensitive information. When the delivery vehicle is a vendor your team already trusts, the social-engineering lift is effectively zero. That is the calculation attackers are making.