A Law Firm Notice From a No-Code App: No Sender to Block

The sender field on this phishing email was perfect, because it was real. From, Reply-To, Return-Path and the DKIM signing domain all belonged to a no-code app platform, and the attacker owned none of them.

The target was a hotel and resort operator's reservations desk mailbox. The message arrived as a "Legal Notice Regarding the Misuse of Protected Content" on what looked like the letterhead of a major international law firm, complete with a Chicago office address and a case reference. A Meta-style case card named the hotel's own property and listed a mailbox, a discovery date and four demanded actions. A 7-day deadline closed it out.

Every authentication check passed: SPF, DKIM, DMARC and Microsoft's composite authentication. Microsoft trusted the message.

A sender you cannot block

Most email defense assumes attackers need infrastructure. They register a domain, spoof a brand or hijack a mailbox, and each of those leaves something to block.

This one left nothing. A customer-built app on a no-code platform authored the whole message, and the platform's notification mailer delivered it. The envelope sender was the platform's bounce domain. The visible sender was the platform's shared "noreply" address. Allow-listing by sender would pass it, and block-listing by sender would also stop every legitimate app notification that platform sends to your users.

That is the real shift in this technique (MITRE T1566.002 for the phishing link, T1036.005 for the masquerade). The attacker rents the sending identity instead of building one. The author of the app was not established, and nothing here shows the platform or its owner acted maliciously. The feature was abused, not the vendor.

The 2026 Verizon DBIR puts phishing at 16% of initial access and the human element in 62% of breaches. Those numbers describe what happens when the message lands in front of a person. Here, the message landed because nothing about the sender was wrong.

The tell was content against channel

If the sender cannot be judged, the message has to be.

Read the body as a reader would. The letterhead was a US firm, with a Chicago address. The sign-off was "Barrister & Solicitor", a professional title used in Commonwealth jurisdictions, not in a US firm's litigation group. The legal references were American: Title 17, the DMCA and the Lanham Act, next to the Berne Convention. And beneath all of it sat a footer that read "Sent from AppSheet".

A law firm does not send a litigation notice from a no-code app notification. The channel contradicts the content. A model that scores sender reputation will miss that. A model that reads what the message claims to be, and compares it with how the message traveled, will not.

The firm's address and contact details were real public listings. The attacker copied authentic detail to borrow credibility. The firm itself was only impersonated, with no sign of compromise or involvement.

Twenty incidents, zero safe

The second tell is memory.

Sender history for this tenant shows the same platform address delivered 20 incidents since May 2025. Five were resolved as malicious by a human analyst, 14 were resolved automatically as phishing, and one came from a scanback. Zero were ever marked safe.

The costumes rotated. Intellectual property violation. Trademark. Terms-of-service account disablement. A "Damaged Delivery" notice, three times. A request to remove infringing posts. A resort reservation reference. The display name changed with each message. Ten of the 20 arrived in the final 17 days of the window, so the cadence is accelerating.

One sender address, one tenant, six months, no benign mail. A static allow-list sees a trusted platform. A per-tenant history sees a channel that has never carried a legitimate message to that organization.

Platform-hosted lures are not new. Microsoft's Digital Defense Report 2024 documents attackers abusing trusted cloud services, and the FBI IC3 2024 report shows phishing and spoofing leading complaint volume. What this case adds is a platform where even the sender is rented.

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

A secure email gateway (SEG) built on reputation and authentication verdicts is exactly the control this lure was designed to walk past.

What was and was not established

The record supports the mechanics and not the destination.

The only attacker artifact in the body was a single button, "Review supporting evidence & media files", pointing at a link-sharing short URL. The platform's link list also associates that link with a recently registered, privacy-protected domain. The scanner's screenshot of the short link showed a generic page, so no payload was observed. This analysis does not claim what the landing page hosts or collects. The link-list association is probable but unproven as the destination.

The message was quarantined, and a human analyst resolved the incident as malicious.

Defending a channel you cannot distrust

Three controls matter more than any sender rule.

First, compare claimed identity with delivery channel. Letterhead, jurisdiction and sign-off should agree with the footer and the route. When they disagree, treat the message as hostile regardless of authentication. CISA's phishing guidance and the NIST definition of phishing both center on deception about who is asking.

Second, key on history at the tenant level. A platform address that has produced 20 incidents and no safe mail for one organization deserves a different verdict than the same address does for an organization that actually uses the app.

Third, stop treating a pass on SPF, DKIM and DMARC as a trust signal. It confirms the platform sent the message. It says nothing about who wrote it. IRONSCALES platform data, drawn from 36,000+ security professionals across 18,000+ organizations, is built to flag content that does not fit its channel. Read more on authority and brand impersonation defense and the phishing glossary entry.