The email looked like every Google Docs share notification you've ever received. "G o o g l e" across the top (spaced out, the way Google renders it in legitimate notifications), a message that someone had added you as an editor, and a big blue "Open to Edit" button. The subject line added urgency: "Deadline notice: [Company]-Agreement-3/10/2026."
There was just one problem.
The link behind that button didn't go to Google. It went through Kajabi's email marketing platform, carrying the recipient's email address base64-encoded in the URL fragment. And the sending domain? A UK healthcare organization whose DMARC policy was set to REJECT, meaning this phishing email actually had stricter authentication than most legitimate corporate mail.
This attack stacked three layers of legitimacy that, combined, made it nearly invisible to traditional email security:
Layer 1: A compromised legitimate domain. The email came from irene@angelichealthcare[.]co[.]uk, a real UK healthcare domain. SPF passed. DMARC passed with a p=REJECT policy. The sending infrastructure (sxb1plsmtpa01-15.prod.sxb1.secureserver[.]net) was authorized by the domain's DNS records. Whether the account was compromised or the domain's mail service was abused, the result was the same: the email looked authenticated and legitimate.
Layer 2: Google brand impersonation. The display name was "Workspace ShareDrive SharedPDF," mimicking Google's ecosystem. The body replicated Google Docs' visual language, complete with the spaced-out "G o o g l e" text that legitimate share notifications use. For most recipients, the visual match would be instant and convincing.
Layer 3: Marketing platform redirect. The "Open to Edit" CTA pointed to email.y.kajabimail[.]net, Kajabi's legitimate email marketing infrastructure. URL scanners that check link destinations see a known, trusted marketing platform. What they don't always see is the redirect chain that follows.
Here's the detail that elevates this from a standard phishing campaign to a targeted credential harvest. The URL fragment appended to the Kajabi redirect contained a base64-encoded string:
`` #YmVuQHBlcmlvbi5jb20= ``
Decoded, that's the recipient's email address. When the target clicks "Open to Edit," the credential harvesting page at the end of the redirect chain receives their email pre-filled. The fake login page already knows who they are, making the experience feel seamless and reducing the cognitive friction that might make someone pause.
This technique is increasingly common in targeted phishing, it serves a dual purpose...it personalizes the harvesting page and it allows the attacker to track which specific recipients clicked. The base64 encoding is trivial to decode, but it's sufficient to bypass simple URL pattern matching that doesn't inspect fragments.
Despite the sophisticated delivery mechanism, the phishing kit itself was sloppy. And that's useful for threat analysts, because the mistakes reveal how the kit was assembled:
kjdbkjcbk2.* subdomains appeared as decoy links (pointing to highlandereng[.]com, rodomech[.]com, isnetworld[.]com), suggesting a templating system that injects semi-legitimate links to reduce suspicionThese artifacts tell a story: the attacker assembled the email from reusable phishing kit components, swapping in Google branding and recipient-specific details while leaving behind traces of previous campaigns. According to Verizon's 2024 DBIR, credential harvesting remains the primary objective in over 30% of phishing attacks, and kits like this one lower the barrier for executing targeted campaigns at scale.
See Your Risk: Calculate how many threats your SEG is missing
| Type | Indicator | Context |
|---|---|---|
| Domain | angelichealthcare[.]co[.]uk |
Sending domain (likely compromised) |
irene@angelichealthcare[.]co[.]uk |
Sender address | |
| URL | email.y.kajabimail[.]net/c/eJxsk... |
Kajabi redirect (primary CTA) |
| Domain | crailulea[.]quest |
Final redirect destination (credential harvest) |
| IP | 92[.]204[.]81[.]244 |
Sending relay IP (secureserver.net) |
| IP | 81[.]199[.]26[.]24 |
Authenticated submission source |
| Fragment | #YmVuQHBlcmlvbi5jb20= |
Base64-encoded recipient email |
A traditional SEG evaluating this message would see:
Every signal that a gateway relies on said "safe."
The phishing indicators lived in places that static analysis doesn't typically reach: the base64 fragment, the redirect chain behavior, the mismatch between sending domain and visual brand.
IRONSCALES Themis identified this as credential theft through link-level analysis that followed the redirect chain beyond the initial Kajabi hop, combined with community intelligence from similar incidents reported across the IRONSCALES network. The platform's Adaptive AI recognized the behavioral pattern: legitimate domain sending Google-branded content with a marketing platform redirect, a combination that has appeared in multiple campaigns across the customer base.
Inspect beyond the first hop. URL scanners that evaluate only the initial link domain will miss redirect chains through marketing platforms. Effective detection requires following the full redirect path to the final destination.
Watch for brand-to-domain mismatches. When a Google-branded email arrives from a healthcare domain through a marketing platform, those three identities should never coexist. Behavioral analysis that correlates visual brand, sending domain, and link infrastructure catches what authentication cannot.
Decode URL fragments. Base64-encoded strings in URL fragments are a strong signal for targeted credential harvesting. Security teams should add fragment inspection to their link analysis workflows.
Report and share. When one security team identifies a campaign, community-driven platforms like IRONSCALES propagate that intelligence across thousands of organizations in real time. The attacker's infrastructure was flagged within the IRONSCALES community, turning a single detection into collective protection.