The Phishing Simulation Platform That Powered a Real Attack

The phishing kit images were hosted on caniphish.s3.ap-southeast-2.amazonaws.com. CanIPhish is a commercial phishing simulation platform, the kind security teams pay for to test their own employees. In this attack, a real threat actor borrowed that infrastructure to power a credential harvesting campaign targeting a regional healthcare organization.

The email promised a salary adjustment document. The landing page impersonated an Adobe PDF viewer. And the assets making that page look convincing came straight from a vendor whose entire business is simulating attacks. The line between simulation and live fire just disappeared.

A Fabricated HR Tenant, a Real Delivery Service

The email arrived from jp@hrsyncdashboard[.]onmicrosoft[.]com, a Microsoft 365 tenant name designed to look like an internal HR synchronization tool. The display name reinforced the pretext: "Excel_Generated Notifications_Salary_Adjustment." The subject line referenced a specific healthcare employer by name, adding institutional context that a generic lure would lack.

Behind the scenes, the attacker used SendGrid (account ID 60904143) as the delivery platform. The Return-Path pointed to a SendGrid bounce address encoded with the target recipient's email, a standard pattern for transactional sends that also happens to pass SPF checks at the first relay hop. According to the Verizon 2024 Data Breach Investigations Report, phishing remains the top initial access vector in confirmed breaches, and abuse of legitimate email infrastructure like SendGrid is a key reason these campaigns scale so effectively.

The email body was minimal and precise. A green checkmark icon preceded the message: "You've been granted access to read 'Salary adjustment for [organization] employees.'" Below that, a card displayed the recipient's full name and job title (Lead Senior Accounts Payable Analyst) with a date stamp. Two buttons offered "Open in Teams" and "Open in Browser." Both pointed to SendGrid click-tracking URLs that redirected to the phishing page.

This level of personalization matters. The attacker knew the target's name, title, and employer, hallmarks of spear phishing (MITRE ATT&CK T1566.002) rather than spray-and-pray distribution.

The Redirect Chain That Obscured the Destination

Every clickable element in the email routed through u60904143[.]ct[.]sendgrid[.]net, SendGrid's click-tracking subdomain. This is a legitimate service feature, but in this context it served as a cloaking layer. URL scanners evaluating the email at delivery time saw a SendGrid domain, not the final destination.

The redirect resolved to salaryadjustmentreadviaadobe[.]carrd[.]co, a one-page site built on Carrd's free hosting platform. Carrd pages inherit the platform's domain reputation, and because Carrd is widely used for legitimate purposes (portfolios, landing pages, link-in-bio sites), it rarely triggers domain-based blocklists.

The landing page itself was simple but effective. The heading read "Salary Adjustment for employees," followed by a prompt to "Click below to read document on your organization Adobe PDF reader online." A black "Continue" button led to the credential harvesting form. Below that, a QR code offered a secondary path for mobile devices, a dual-vector technique documented in CISA's phishing guidance as an increasingly common evasion method.

When Your Security Vendor's Infrastructure Becomes the Phishing Kit

Here is where this campaign gets genuinely uncomfortable for the industry. The images rendering on that Carrd phishing page were served from caniphish[.]s3[.]ap-southeast-2[.]amazonaws[.]com. CanIPhish is an Australian commercial phishing simulation platform. Organizations use it to run authorized phishing tests against their own employees.

The attacker either gained access to the S3 bucket through misconfigured permissions or simply referenced publicly accessible assets. Either way, the result is the same: phishing kit visual components hosted on infrastructure that many security teams have explicitly whitelisted. If your email security policy trusts CanIPhish domains because you use them for simulation, those same trust rules now benefit the attacker.

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

This is a concrete example of what the Microsoft Digital Defense Report 2024 describes as the weaponization of trusted cloud services. Attackers are not building infrastructure from scratch. They are compositing attacks from legitimate platforms: Microsoft 365 tenants for sender domains, SendGrid for delivery, Carrd for hosting, and now simulation vendor buckets for assets.

Authentication Passed at One Hop and Failed at the Next

The relay analysis tells a story of fractured trust. At the first hop (esa2[.]hc3244-53[.]iphmx[.]com), SPF passed for the SendGrid envelope-from address, and DKIM verified for sendgrid[.]net. The email looked authenticated.

By the time it reached Microsoft 365's inbound protection (BN1PEPF00006003), the picture had changed. SPF returned a softfail for the intermediate relay IP (139[.]138[.]59[.]32), and DKIM failed for sendgrid[.]net. DMARC returned none because the From domain (hrsyncdashboard[.]onmicrosoft[.]com) had no DMARC policy published. This is consistent with MITRE ATT&CK T1078.004 (Cloud Accounts): the attacker created a throwaway tenant specifically because onmicrosoft[.]com subdomains do not carry organizational DMARC policies.

The FBI IC3 2024 Internet Crime Report documented $2.9 billion in BEC losses, with the majority of successful campaigns exploiting exactly this kind of authentication gap between relay hops.

Despite link scanners returning "Clean" verdicts on two of the four URLs, IRONSCALES Adaptive AI identified the threat through behavioral signals: first-time sender to the organization, a fabricated tenant name with no historical sending pattern, and VIP recipient targeting. Across the IRONSCALES community intelligence network, similar SendGrid-to-Carrd redirect chains had already been flagged by analysts at other organizations, accelerating classification before URL reputation databases caught up.

Stop Whitelisting Simulation Vendors by Domain

This attack demands a specific operational response beyond standard phishing hygiene.

Audit your simulation vendor whitelists. If you whitelist phishing simulation platforms by domain or S3 bucket hostname, you are extending trust to any attacker who references those same assets. Scope allow-lists to the specific campaigns and timeframes you authorize, not to blanket domain exceptions.

Treat mixed authentication results as a signal, not noise. When SPF passes at one relay hop and fails at the next, that inconsistency should elevate the message's risk score. Static pass/fail authentication checks at a single evaluation point miss these gaps.

Monitor for fabricated onmicrosoft.com tenants. Attackers create throwaway M365 tenants to inherit Microsoft infrastructure credibility. Any inbound email from an onmicrosoft[.]com sender that your organization has never corresponded with should trigger heightened scrutiny, especially when paired with third-party delivery services like SendGrid.

Assume URL scanners will miss Carrd and similar platforms. User-generated hosting services (Carrd, Webflow, Notion, Google Sites) benefit from domain reputation they did not earn. Layer URL protection with behavioral sender analysis to catch campaigns where every individual link checks out but the message context does not.

Indicators of Compromise