A Shared Redirect Hub Behind Voicemail Account-Takeover Phishing

Between December 2025 and April 2026, one reused Mailchimp campaign became a shared redirect hub for at least seven unrelated scam operations. The lures that drew our attention were fake voicemail notifications, but the same click-tracking campaign ID also carried McAfee, Fidelity Life, TruGreen, and GLP-1 pretexts. Every voicemail message was sent from a genuinely hijacked business mailbox, rode that victim's own email-service integration, and pointed at a link that resolved, hop by hop, only to trusted platform domains. The operator's owned infrastructure amounted to a couple of throwaway domains. Everything else belonged to legitimate services it had learned to borrow.

Key Takeaways

• One reused Mailchimp click-tracking campaign ID fronted at least seven unrelated scam operations across about three and a half months, a shared-hub pattern that reads as Phishing-as-a-Service plumbing rather than one bespoke campaign.
• The voicemail lures went out from hijacked business mailboxes through those victims' own SendGrid integrations, so the mail passed SPF and DKIM and failed only on DMARC alignment.
• The click path chained through other compromised businesses' Mailchimp list-manage pages before reaching a disposable landing domain or a hijacked ActiveCampaign page, so every visible hop resolved to a reputable platform.
• The operator's own footprint was small: a pair of freshly registered, privacy-protected throwaway domains against a backbone of aged, high-reputation infrastructure it did not own.
• The clearest proof of full-mailbox compromise was structural. A fabricated voicemail notice sat prepended above the victim's real, intact mail thread.

Background

Most phishing that impersonates a real company spoofs it: the operator forges a From: header from infrastructure it does not control, and at least one of SPF or DKIM fails. This operation did the opposite. It sent from mailboxes it had taken over, using each victim's already-authenticated email pipeline, so the messages were genuinely signed and genuinely authorized.

That distinction matters because of how the three email-authentication standards fit together. SPF checks whether the sending IP is allowed to send for the return-path domain. DKIM checks a cryptographic signature bound to a signing domain. Both can legitimately pass for mail that travels a real account's real infrastructure. DMARC adds a third requirement on top: alignment, meaning the domain that passed SPF or DKIM has to match the domain a human sees in the From: header. When an attacker injects through a hijacked business integration, the platform's authentication passes cleanly while the visible sender identity, or the brand impersonated in the body, points somewhere else. The result is a message that passes SPF and DKIM yet fails DMARC alignment. Authentication-only trust waves it through; alignment-aware checks do not.

Several legitimate services show up in the narrative below because the operator abused them, not because they did anything wrong. A short primer on each:

• Mailchimp click-tracking and campaign redirect links (the click.mailchimp[.]com/track/click/... shape) rewrite every link in a send so it first passes through a shared Mailchimp redirector that counts the click, then forwards to the real destination. An attacker abuses this because the outbound link shows a reputable, TLS-valid Mailchimp domain while the true target hides behind the redirect, and because reusing one campaign object lets the operator swap that target server-side without touching the sent email.
• Mailchimp list-manage pages live on list-manage[.]com, the shared domain Mailchimp uses to host list content and the click redirector for all of its senders. When a customer's account is compromised, its hosted pages become intermediate redirect hops, so a click can traverse several unrelated but legitimate businesses' trusted pages before it lands anywhere suspicious.
• SendGrid, part of Twilio, is a high-volume email API that businesses send through using pre-authorized domains with valid SPF and DKIM. A hijacked SendGrid account lets an attacker send through the victim's authenticated integration, so the mail carries correct headers and passes authentication for a real domain. This is an abuse path, not a spoof.
• ActiveCampaign hosts customer landing and form pages on its own ac-page[.]com domain. A compromised ActiveCampaign account gives an attacker a credential-harvest page on a trusted, HTTPS-valid platform, at no cost and with no domain to register.

The voicemail pretext itself is old and well-documented. A "new voicemail message" or "unified messaging" notice exploits the sense that the mail came from the recipient's own phone system, and the "listen" or "view message" button usually leads to a credential page dressed as Microsoft 365 or Google Workspace. Public write-ups from GreatHorn, Hoxhunt, and university security teams have tracked this pretext class for years. What makes the case worth a closer look is the machinery underneath it.

Discovery and Infrastructure

The pivot that opened the operation was a single click-tracking campaign ID. Following it, rather than any one sender or domain, surfaced a set of otherwise-unrelated scams that all funneled through the same Mailchimp redirect object. The voicemail lures were one theme among several sharing that hub.

The operation separates sending, redirection, and landing across three distinct trust layers, so no single hop exposes attacker-owned infrastructure:

• Delivery rode compromised-account SendGrid. Each lure was sent from a hijacked business mailbox through that victim's own Twilio SendGrid integration, with a return-path on sendgrid[.]net. Each compromised business carried its own distinct SendGrid account, not one shared sending identity, which is a burn-and-rotate delivery pool built from other people's infrastructure.
• Redirection ran through one reused Mailchimp campaign. The click-through links resolved into a single click-tracking campaign, ID 30010842, on click.mailchimp[.]com. That one ID is the cross-operation hub.
• Landing pages took one of two shapes: a dedicated throwaway domain (fr1bel[.]com), or a hijacked page on another business's ActiveCampaign account (*.ac-page[.]com).

Between the hub and the landing sat a further obfuscation layer: clicks bounced through *.list-manage[.]com subdomains belonging to other legitimate Mailchimp tenants, additional compromised third-party accounts used purely as hops. The list-manage[.]com apex is shared Intuit infrastructure and is never itself an indicator.

Mapping the hub across its lifetime shows how varied the traffic was for a single shared redirect object:

Date	Pretext / impersonated brand	Landing shape
2025-12-31	McAfee impersonation	compromised third-party Mailchimp hop
2026-01-29	Fidelity Life impersonation	compromised third-party Mailchimp hop
2026-02-04	unattributed cluster	compromised third-party Mailchimp hop
2026-02-27	voicemail lure	dedicated disposable domain fr1bel[.]com
2026-03-03	voicemail lure	SendGrid click-tracker (unresolved)
2026-03-27	GLP-1 / Ozempic scam	us18.admin.mailchimp[.]com
2026-04-14	voicemail lure	compromised third-party ActiveCampaign page
2026-04-15	TruGreen impersonation	compromised third-party Mailchimp hop

Five named pretext families and one unattributed cluster, all sharing one click-tracking campaign ID over about three and a half months.

How It Works

A representative voicemail send ran the full three-layer chain. The operator, already inside a small business's mailbox, composed a fake voicemail notification and sent it through that business's SendGrid integration. The message passed SPF and DKIM for the real sending domain and failed only DMARC alignment. Its single call-to-action pointed at the Mailchimp hub, which counted the click and forwarded it through a second, unrelated business's compromised list-manage page, and from there to the final landing: on the earliest voicemail send, the throwaway domain fr1bel[.]com; on a later one, a hijacked ActiveCampaign page.

A sanitized header for that pattern:

From: "Voicemail Service" <[compromised business account]>
Subject: New mailbox from "[fabricated caller]"
Return-Path: <bounces@sendgrid[.]net>
Authentication-Results: spf=pass dkim=pass dmarc=fail
CTA: http[:]//click.mailchimp[.]com/track/click/30010842/...

The lure body never contained a raw malicious URL. The only visible link was a trusted Mailchimp tracking address, and the disposable landing domain existed only inside the redirect chain, never as a standalone URL a reputation system would have crawled on its own.

Sample Lures

The voicemail theme shipped in four structurally distinct templates, each a fake unified-messaging notice grafted above the victim's real mail. Three representative variants, with all recipient data removed and all indicators defanged:

Variant A, a generic voicemail-system notice with a spoofed Google headquarters address in the footer:

From: "Voicemail" <[compromised business account]>
Subject: Fwd: 03-57UC Voice Message
Body:
  You Have a New V-Message
  Duration: 00:29
  [ View Message ]
  1600 Amphitheatre Pkwy, Mountain View, CA 94043, USA
  You're receiving this because voicemail alerts are enabled for your account.

Variant B, a fabricated "G-Tone Priority" brand leaning on secure-transmission language and a masked caller ID:

From: "G-Tone Priority" <[compromised business account]>
Subject: G-Tone Secure: New Voicemail
Body:
  SECURE AUDIO TRANSMISSION
  New Voicemail Received
  Recipient: [recipient]
  Caller: +1 ••• ••• ••[redacted]   [timestamp]
  [ Access Secure Message ]
  Caller identity partially masked for privacy - Authorized access required

Variant C, a plain PBX-mailbox notification with a fabricated caller name and number in the display field:

From: "[fabricated caller] AP" <[fabricated number]>
Subject: New mailbox 108 from "[fabricated caller] AP" <[fabricated number]>
Body:
  Account ID: [account id]
  You have a new msg in mailbox 108 [recipient]
  [ Press/Click to Access Voicemail ]

The through-line across every variant is the same: mailbox chrome (a duration stamp, a masked caller ID, secure-access language) wrapped around a single opaque, platform-tracked button.

Technical Analysis

The Three-Layer Trust-Laundering Chain

The operation's defining property is that no single hop reveals attacker-owned infrastructure. Delivery borrows the victim's ESP integration. Redirection borrows Mailchimp's click-tracker. The intermediate hops borrow still other victims' hosted pages. Only the final landing is ever operator-owned, and even that is sometimes a hijacked ActiveCampaign page rather than a registered domain. A defender inspecting any one layer sees a reputable service. The malice is visible only when the layers are assembled end to end.

Registration Cohorts and a Telling Absence

The domains split into three cohorts with sharply different registration profiles, and the split is itself a classifier.

Domain / platform	Registrar	Created	Role
foxmail[.]com	MarkMonitor	1997	abused platform (freemail)
mcsv[.]net	MarkMonitor	2005	abused platform (Mailchimp)
list-manage[.]com	MarkMonitor	2006	abused platform (Mailchimp, hosting)
sendgrid[.]net	MarkMonitor	2009	abused platform (Twilio delivery, hosting)
mcdlv[.]net	MarkMonitor	2011	abused platform (Mailchimp)
ac-page[.]com	MarkMonitor	2020	abused platform (ActiveCampaign)
googoojapan[.]com	Namecheap	2025-11-17	operator-disposable
hostdawn[.]mom	Spaceship	2026-01-09	operator-disposable
fr1bel[.]com	(absent)	(absent)	operator-disposable landing, never crawled

The abused platforms are aged, MarkMonitor-registered, and carry real corporate WHOIS organizations (Twilio, Intuit, ActiveCampaign). The operator's own domains are the opposite: freshly minted on cheap, privacy-friendly registrars, registered weeks before first abuse, and stripped of any WHOIS organization. That inversion is the heuristic. An aged domain with a real business WHOIS org is a compromised victim; a fresh registration behind privacy protection, abused almost immediately, is operator-owned. The label googoojapan[.]com looks business-suggestive, but it sits in the operator bucket precisely because it inverts the victim profile: registered November 2025 behind privacy, abused within weeks.

The most interesting entry is the one with no data at all. fr1bel[.]com never appears in reputation data, because it was never crawled or resolved as a standalone URL. It existed only inside the Mailchimp redirect chain. A landing domain reachable only through a trusted-platform redirect, and never observed independently, is not a gap in coverage. It is a designed reputation-evasion property.

The Shared Hub as Cross-Cluster Pivot

The single strongest correlation signal here is not a domain or a sender. It is the reused Mailchimp campaign ID 30010842. Sending addresses rotated freely across the operation: different hijacked mailboxes, different pretexts, freshly registered operator domains coming and going. The hub stayed constant. A rotating sender pool anchored to one invariant redirect object is the classic shape of shared tooling, where many nominally separate campaigns run off one piece of central plumbing. Reusing a single click-tracking campaign gives the operator trusted-domain laundering on every outbound link, one control point to repoint landing pages as they burn, and resilience that held across months and unrelated themes.

The Compromised-Account Fingerprint and Its Legitimate Twin

The header fingerprint of a hijacked-account send is SPF=pass, DKIM=pass, DMARC=fail, with a return-path on the sending ESP. The trouble is that a completely legitimate message carries the identical triplet: cloud-PBX voicemail-to-email forwarding from RingCentral, 8x8, Vonage, Zoom Phone, and Dialpad all forward from the customer's own domain through an ESP, producing the same authentication result and the same voicemail subject line. We confirmed one such legitimate forward during this work that matched the fingerprint exactly.

Authentication alone cannot separate the two. The discriminator is content provenance:

• A true compromise prepends a fabricated voicemail template above a real, intact mail thread. Genuine multi-party business correspondence sits untouched below the lure. That underlying real thread is proof of full-mailbox access and is the operation's actual signature.
• A legitimate cloud-PBX forward is a self-consistent vendor template end to end: real caller ID, official first-party vendor links, and, where present, a genuine "sign in with Microsoft" SSO link rather than a credential harvester. There is no foreign scam block grafted on top of unrelated real mail.

Detection Observations

The behavioral signals that separate this traffic from legitimate mail, framed as observations a defender can key on:

• The authentication triplet of SPF pass, DKIM pass, and DMARC alignment failure, paired with a voicemail or unified-messaging subject and an ESP return-path, is a starting filter rather than a verdict. On its own it also matches legitimate cloud-PBX forwarding, so it narrows the field without confirming anything.
• The confirming signal is structural, not header-based: a fabricated notification block sitting above an unrelated, intact mail thread inside the same message. That mismatch does not occur in a genuine vendor voicemail forward.
• The single reused click-tracking campaign ID is the strongest cross-cluster pivot. A tracked-link redirector that forwards many unrelated pretexts over months is worth treating as shared infrastructure, independent of any one sender's reputation.
• Trusted-platform redirect layering degrades link-reputation signals by design. When the only visible URL is a reputable ESP tracker and the true destination is reachable only through it, the destination's absence from public reputation data is itself notable.

Indicators of Compromise

All indicators below are defanged, and cover only confirmed operator-owned infrastructure. The abused platforms (Mailchimp, SendGrid, ActiveCampaign) and every compromised business account are deliberately omitted: they are legitimate third parties and victims, not operator infrastructure, and publishing them would misattribute them.

Senders

Value	Role	Notes
airport.guitar2q@sapples.hostdawn[.]mom	Sender	Operator-disposable domain; TruGreen-impersonation spoke on the shared hub

Domains and Hosts

Value	Role	Notes
fr1bel[.]com	Landing	Dedicated disposable voicemail-lure landing; reachable only inside the redirect chain, never crawled independently
sapples.hostdawn[.]mom	Sender / landing	On operator-disposable hostdawn[.]mom, registered 2026-01-09 behind WHOIS privacy

MITRE Fight Fraud Framework Mapping

Mapped against the MITRE Fight Fraud Framework (F3), the current published fraud matrix. F3 uses ATT&CK-derived tactic and technique IDs (TA####, T####) alongside fraud-specific IDs (F####).

Tactic	Technique	ID
Resource Development	Compromise Accounts: Email Accounts	T1586.002
Resource Development	Compromise Accounts: Corporate Accounts	T1586.004
Resource Development	Acquire Infrastructure: Domains	T1583.001
Resource Development	Create Fake Materials: Fake Website	F1020.002
Initial Access	Phishing	T1660
Initial Access	Impersonate Official	F1032

The trusted-platform redirect layering has no exact F3 technique. It fits the Stealth tactic as a blend-with-trusted-infrastructure behavior, so we describe it as such rather than cite an ID that does not exist.

Conclusion

The operation went quiet in mid-April, and the reused campaign ID fell silent for about four weeks after its last observed send. Quiet is not the same as gone. The one net-new voicemail send in that window routed its click through a different compromised Mailchimp tenant rather than the original hub, which reads less like a shutdown than a migration of the redirect layer onto fresh borrowed infrastructure. Defenders watching for this operator should track the indirection pattern, a reused ESP click-tracking object fronting many unrelated pretexts, rather than any single domain, because the domains were always the most disposable part of the machine.