A Real Squarespace Invite Carried a Fake Norton Bill

An employee at a logistics and transportation company was invited to help build a website. The invitation was real. It came from Squarespace, from the no-reply address Squarespace actually uses, and it left Squarespace's own SendGrid infrastructure. SPF passed, DKIM passed, DMARC passed under a published reject policy, composite authentication returned a perfect score, and the ARC chain validated. Every domain-level control a defender can point at agreed the mail was authentic, and every one of them was correct.

Inside it, where the inviting party is invited to add a friendly note, was a Norton auto-renewal notice demanding $269.99 and a phone call.

Invitation Injection Turns a Collaboration Feature Into a Mailer

The attacker did not spoof Squarespace. The attacker signed up for it. A throwaway site was created at the auto-generated subdomain vanilla-lobster-xh6r[.]squarespace[.]com, an invitee address was typed into the contributor field, and the lure was typed into the optional personal-message box that Squarespace faithfully renders into the notification body.

From there the platform did what it is built to do. It composed a transactional email, signed it, and pushed it out through its own sender. There is no attacker sending domain in this message, because the attacker never needed one. The delivery channel was a paying customer feature, which is the same pattern behind the invite and file-share notifications that MITRE ATT&CK tracks as acquiring web services for operations. The one field the attacker fully controlled was free text, and free text was enough.

The injected copy was standard antivirus refund-scam furniture: an order reference of UHQE925, a subscription charge, a warning that the amount would post automatically, and a support number to stop it. No credential page. The two links in the message pointed at the genuine acceptInvite endpoints on the attacker's Squarespace site, which is to say they pointed at Squarespace. The payload was the telephone number, and the goal was a live conversation about a refund.

Authentication Confirmed the Sender and Nothing Else

This is the part worth sitting with, because the authentication result here is not a false positive. It is a true statement about the wrong question. Alignment as defined in RFC 7489 establishes that a domain owner authorized a message. Squarespace authorized it. The signature over the Squarespace header domain was valid, and a second valid signature from an unrelated Microsoft 365 tenant appeared on the relay leg, adding cryptographic weight to a message whose fraudulent content no signature had any opinion about.

The practical consequence is that reputation-based filtering is working against itself. Blocking the sending domain means blocking every real Squarespace notification. Blocking the destination URLs means blocking squarespace[.]com. There is no indicator here with a useful blast radius, which is exactly why abusing transactional mail from a well-regarded platform is worth the effort. The 2024 Verizon Data Breach Investigations Report still finds a human element in 68 percent of breaches, and this message was engineered to leave the human as the only control in the path.

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

The Mail Merge Leaked the Kit

The most interesting artifact in the message is one the attacker never intended to send. The raw To header read View_INSERT51@ablert23[.]shop, which is not the recipient's address and never was. It is a template variable that failed to resolve, still carrying the placeholder domain from the kit it was copied out of.

Worth being precise about how a message addressed to a variable name reaches a real inbox, because it looks like a contradiction. The header To field is cosmetic and routes nothing. Delivery is decided by the SMTP envelope recipient, and Squarespace derives both from the same invitee field, so the two cannot simply be typed apart. The coherent reading is that the attacker's tooling never substituted the target's address into the invite form at all. Squarespace was asked to invite the placeholder, so it composed and signed a notification for the placeholder, exactly as designed. The header chain then shows a further hop before delivery, which is what that second relay-leg signature is doing in an otherwise pure platform send, and the Squarespace signature survived it intact.

So the mail landed cryptographically flawless in a mailbox that appears nowhere in its own To line, and the recipient was handed a direct view of the phishing kit behind it.

The Reply-To told a similar story with less subtlety. It had been redirected to lizamatthew78909@outlook[.]com, a consumer freemail account with no relationship to the brand in the body, the brand in the header, or the recipient.

A Deadline That Had Already Passed on Arrival

The urgency mechanic broke itself. The injected copy instructed the recipient to cancel before a specific stated deadline, after which the charge would become non-refundable. That stated deadline was the same day the message was sent, as the message's own delivery timestamp records. By the strictest reading of its own text, the window to act before that date had already elapsed by the time the mail landed in the inbox.

Then the body offered two different support numbers, one in the opening line and a second further down, both presented as the same billing helpline. Nobody writes one letter with two switchboards. That is a splice, two templates merged into one body by an operator working faster than they were reading, and the same carelessness that left the merge field unresolved.

Three self-inflicted errors in one message, all in the copy, none in the infrastructure. The infrastructure was never the weak point, because it was not the attacker's.

A Reporter Caught What the Model Held at Moderate

Themis, the IRONSCALES Adaptive AI analyst, scored this at 64 percent and fired no label. That is an honest reflection of a hard case. Cleanly authenticated transactional mail from a legitimate platform, with links resolving to that platform and no attacker domain anywhere, sits exactly where model confidence sags.

What moved it was a member of the IRONSCALES community, who reported the message and put it in front of resolution history from similar incidents. That history rated it phishing with high confidence, and the mail was quarantined. Reported-attack workflows are why the human element of the platform belongs inside the detection stack rather than beside it. A person recognized a billing scare inside a website invitation, which is a judgement about incongruity rather than about infrastructure.

What To Take From This Case

Treat the invite, share, and collaborate notifications of legitimate SaaS platforms as a delivery channel and inspect their free-text fields, because the sender reputation you are trusting belongs to the platform and not to whoever typed the message. Then teach one absolute rule about unsolicited billing mail, which is that a printed phone number never gets dialled, no matter which brand is on the letterhead or how convincingly the envelope checks out. Callback fraud, which defenders shorthand as vishing, only pays when someone picks up the phone. CISA phishing guidance makes the same point about authenticated mail: a clean header is not a content review.

Indicators of Compromise

MITRE ATT&CK Mapping

See You Next Time

The cleanest authentication result in this case belonged to the attacker, because the platform really did send the mail. What gave it away was a merge field that never filled in, a deadline that expired before delivery, and one letter with two phone numbers. Check back tomorrow.