Meta Partner-Request Phishing With No Attacker Domain

In May 2026, analysts tracked a phishing operation that hides its lure inside genuine Meta partner-request emails, with no attacker-owned domain anywhere. The operator registers no lookalike domain and spoofs no header. It never sends a message from its own infrastructure at all. Instead it registers a Facebook business, sets that business's name to the phishing payload, and asks Meta to deliver the lure on its behalf. The notification that lands in the target's inbox is a real Business Manager partner-sharing request from noreply@business.facebook[.]com, authenticated end to end, carrying an attacker-chosen Messenger handle in the requester name. The result is a lure that passes every check built to answer "is this really from Meta?" because the honest answer is yes.

Key Takeaways

• The actionable lure is a Messenger deep-link string (m[.]me/<handle>) placed in the partner-requester business-name field, so it renders as plain body text and never enters the parsed-URL pipeline.
• Delivery rides Meta's own servers. The mail passes SPF, DKIM, and DMARC because Meta genuinely sent it, which neutralizes sender-reputation and authentication controls by design.
• No operator-owned domain exists. The only durable attacker atoms are attacker-registered Messenger usernames and one Google Sites landing path, all hosted on legitimate platforms.
• The Messenger handles follow a stable naming grammar (businesspartnerplatform*, Partnerprogram*, Businesscollaborationplatform*) alongside disposable 15-digit numeric-uid handles.
• The same handle grammar has been observed carried through a second authenticated notification channel, a GoDaddy-hosted site's contact-form alerts, which shows this is a repeatable authentic-infrastructure technique, not a one-off.

Background

Meta Business Manager lets one business invite another to co-manage its assets through a partner-sharing request. Once a partner is approved, that partner can be granted access to Pages, ad accounts, the tracking pixel, product catalogs, and, in some cases, a line of credit. Approving the wrong partner does not leak a single password. It hands an outsider standing access to a company's advertising apparatus and its payment rails. That is what makes the partner-request flow an attractive target: the payoff is persistent asset control, not a one-time credential grab.

The technique on display here belongs to a broader shift toward authentic-infrastructure abuse. Email authentication proves that a message was sent by the domain it claims to come from. It says nothing about whether the content is trustworthy. When an attacker persuades a trusted platform to generate and send a notification, SPF, DKIM, and DMARC all validate correctly, and controls built on sender identity wave the message through. The malicious content lives in an attacker-controlled field that the platform faithfully renders. Security teams have watched the same pattern play out through Google Cloud automation notices, Google Calendar invites, and Google Forms receipts. Meta's partner-request notification is the same idea applied to a system whose end state is business-asset access.

The lure endpoints sit on two Meta-owned services and one Google service. m[.]me is Meta's official Messenger deep-link shortener: any Facebook or Messenger page can claim a username, and m[.]me/<username> resolves straight into a chat with it, so an attacker-registered page name becomes a working, Meta-hosted contact link with no attacker domain involved. Google Sites (sites.google[.]com/view/...) offers free, one-click-published pages served inside Google's trust chain, which the operator uses for a browser-based "verify your page" lander it can stand up and abandon cheaply.

Discovery and Infrastructure

The campaign surfaced while re-running a sweep across Meta-owned sending domains. The sender noreply@business.facebook[.]com had appeared in the hundreds, and every message authenticated cleanly, which ruled out the header-spoofing premise that first put this sender on a watchlist. Reading the bodies showed why the traffic looked benign to link-based tooling: the requester business name contained a Messenger handle and approval language, while the only parseable links were the genuine Meta footer and CDN assets.

Mapping the infrastructure meant enumerating those in-body handles rather than domains, because there are no domains to map. The operator's atoms are Messenger usernames and one Google Sites path.

Indicator	Role	Notes
noreply@business.facebook[.]com	Delivery channel	Genuine Meta partner-request sender, full auth pass, never attacker-owned
m[.]me/<handle>	Lure endpoint	Attacker-registered Messenger usernames in the requester business name
sites.google[.]com/view/verifypagemeta	Landing page	Attacker-created Google Sites verification lander (secondary variant)
static.xx.fbcdn[.]net, business.facebook[.]com	Decoy assets	Real Meta imagery and footer links embedded to raise perceived legitimacy

How It Works

The contact chain runs entirely through legitimate systems. The operator registers a Facebook business and names it with the payload, a Messenger handle plus a line such as "Your Business Is Approved for Partnership" and a 24-hour verification deadline. It then issues a real partner-sharing request from that business to the target's Business Manager. Meta generates the notification and sends it from noreply@business.facebook[.]com. The target receives an authentic email whose requester name is the lure. A recipient who opens the Messenger handle lands in a chat where the operator runs a social-engineering script to obtain partner approval or credentials, at which point it can attach itself to the victim's Pages, pixel, ad account, and line of credit. A minority variant swaps the Messenger hand-off for a Google Sites lander that collects credentials through a hosted "verify" page.

Sample Lures

All samples below are from the genuine Meta sender. Recipient identifiers and per-recipient tracking tokens have been removed; every domain and URL is defanged. The attacker-controlled content is the requester business name embedded in the body.

Numeric-uid handle variant:

From: "Facebook" <noreply@business.facebook[.]com>
Subject: You've received a Business Manager partner request
Reply-To: <noreply@facebookmail[.]com>

Hi,

    Your Business Is Approved for Partnership m[.]me/105976071283825  Other links is
    not part of or affiliated with Meta. Only approve requests and invitations from
    people and businesses that you know and trust. Meta will never ask for passwords,
    payment information or personal details in an email. You've received a partner
    request. Partners are other businesses that you work with on Facebook. [...]
    Go to Meta Business Suite to view the request [...] Respond to a line of credit
    request (if applicable). View request

Thanks,
The Facebook team

This message was sent to [recipient email] at your request.
Meta Platforms, Inc., 1 Meta Way, Menlo Park, CA 94025

Vanity-handle variant:

From: "Meta for Business" <noreply@business.facebook[.]com>
Subject: You've received a Business Manager partner request

    Meta Partner Support m[.]me/businesspartnerplatformprogram
    Eligible for Meta verification. Verify using the link above within the next 24 hours.

Google Sites lander variant:

From: "Facebook" <noreply@business.facebook[.]com>
Subject: You've received a Business Manager partner request

    Facebook Get Started  hxxps://sites.google[.]com/view/verifypagemeta

Technical Analysis

The Lure Lives in a Field, Not a Link

The defining feature of this campaign is placement. The Messenger handle sits in the requester business-name field of a genuine notification, so Meta renders it as ordinary text in the message body. A parser that extracts links finds only business.facebook[.]com, static.xx.fbcdn[.]net, and the Meta email-open pixel, all legitimate. The actionable atom, the string a victim is meant to act on, never appears as a hyperlink and never reaches URL reputation. The operator gets a Meta-hosted contact endpoint while presenting nothing for link-based defenses to grade.

Handle Naming Grammar

The Messenger usernames are not random. They cluster into a small set of families whose vocabulary mirrors the partner-sharing pretext, alongside disposable numeric handles that appear as one-off rotations.

Family	Members (defanged)	Shape
businesspartnerplatform*	businesspartnerplatformprogram, businesspartnerplatformprogramm	Vanity, double-final-letter mutation
Partnerprogram*	Partnerprogramss, Partnerprogramonourplatform, partnerprogramplatformmm, partnerplatformprogramagency	Vanity, token permutation of partner / program / platform / agency
Businesscollaborationplatform*	Businesscollaborationplatforms	Vanity
numeric-uid	100639312371009, 102813689127945, 105976071283825, 109234301486279, 328893341199486	15-digit Messenger page IDs, burn-and-rotate

The double-final-letter mutations (...programm, ...ss, ...mm) are the fingerprint of registering fresh usernames after earlier ones are claimed or reported. The vanity families and the numeric-uid handles co-occur across the window rather than one superseding the other, which is consistent with the vanity pages carrying the bulk of the traffic while numeric handles are throwaway rotations.

Subject and Pretext Rotation

The requester name carries the lure, but the subject line steers the emotional register. Beyond the dominant partner-request subject, the operator drives the same "contact support / verify" action through ad-restriction and call-reminder framing, all from the same genuine sender.

Intent	Subject line
Partner-request (primary)	You've received a Business Manager partner request
Ad-restriction	Your Facebook Account has been restricted from advertising
Ad-restriction	Review parameters blocked by Meta
Call-reminder	Confirmed: Your upcoming call with a Meta Technical Pro
Call-reminder	Reminder: Your call with Meta is tomorrow

Partner-request subjects offer opportunity ("you are approved"), ad-restriction subjects manufacture fear ("your account is restricted"), and call-reminder subjects manufacture familiarity ("your scheduled call"). Each funnels the target toward the same off-platform conversation.

No Registration Cohort, By Design

A conventional phishing writeup would anchor here on WHOIS registrars and creation-date cohorts. This operation has none. There is no apex to sinkhole, no registrar to pivot on, and no domain age to correlate. The only registrable resources are Facebook business accounts and Messenger usernames, both provisioned inside Meta and both cheap to replace. Removing the domain from the kill chain is the entire point: it strips defenders of the pivot they lean on most.

A Repeatable Technique Across Platforms

The Messenger-handle lure grammar is not bound to Meta's notification system. The same partner-program handle families have been observed arriving through a second authenticated channel, the contact-form alert system of a GoDaddy-hosted business site, where the operator submitted the lure through a website contact form and let GoDaddy's genuine notification pipeline carry it onward. Two unrelated SaaS notification systems delivering the same handle grammar is the signal that matters: the operator treats authenticated third-party notifications as an interchangeable delivery layer, and any platform that emails user-supplied text on a customer's behalf is a candidate carrier.

Detection Observations

The signal that separates this traffic from legitimate Meta mail is not in the envelope, because the envelope is genuine. It is in the body. A real partner-sharing request does not put a Messenger deep-link handle and a 24-hour verification deadline into the requester business name. Defenders can key on that combination: a Business Manager partner-request notification whose requester name contains an m[.]me/ handle, or approval and verification language paired with a countdown, is anomalous regardless of how cleanly the message authenticates.

Link-based tooling is structurally blind to this campaign because the lure is never a link. Content inspection has to read the requester-name field itself, and the handle naming grammar (the businesspartnerplatform* and Partnerprogram* families, the double-final-letter mutations) is a durable string signal that survives the operator rotating individual usernames. The strongest cross-campaign pivot is the handle grammar carried across delivery vectors: the same families appearing in both Meta and non-Meta authenticated notifications tie the activity together where no shared domain exists to do so.

Indicators of Compromise

All indicators are defanged. No operator-owned domain exists for this campaign; the apex platforms below (m[.]me, sites.google[.]com) are legitimate and are never themselves indicators. The actionable atoms are the attacker-registered Messenger usernames.

Messenger Handles (Lure Endpoints)

Value	Role	Notes
m[.]me/businesspartnerplatformprogram	Lure endpoint	Vanity handle in partner-business name
m[.]me/businesspartnerplatformprogramm	Lure endpoint	Double-final-letter mutation
m[.]me/Partnerprogramss	Lure endpoint	Vanity handle in partner-business name
m[.]me/Businesscollaborationplatforms	Lure endpoint	Vanity handle in partner-business name
m[.]me/100639312371009	Lure endpoint	Numeric-uid Messenger page ID
m[.]me/102813689127945	Lure endpoint	Numeric-uid Messenger page ID
m[.]me/105976071283825	Lure endpoint	Numeric-uid Messenger page ID
m[.]me/109234301486279	Lure endpoint	Numeric-uid Messenger page ID
m[.]me/328893341199486	Lure endpoint	Numeric-uid Messenger page ID

The list above is the verified, shareable subset. Additional Messenger usernames in the same Partnerprogram* family, along with the operator's Google Sites landing path (sites.google[.]com/view/verifypagemeta), were also observed and are covered in the analysis above.

MITRE Fight Fraud Framework Mapping

Mapping aligns to the MITRE Fight Fraud Framework (F3) (the Fight Fraud Framework). Technique IDs in that matrix were not machine-verifiable at time of writing, so the mapping is given by tactic and technique name.

Tactic	Observed behavior	Campaign Behavior
Initial Access	Phishing message via authenticated third-party notification	Lure delivered from genuine business.facebook[.]com partner-request mail
Initial Access	Brand impersonation	Facebook business named to pose as "Meta Partner Support" / "Meta Platforms"
Execution	Urgency and authority framing	Approval language, ad-restriction warnings, and 24-hour verification deadlines
Monetization	Account and asset takeover	Partner approval or credential capture grants Pages, pixel, and ad-account access
Monetization	Ad-account and line-of-credit abuse	Approved partner drains ad spend and exploits the Business Manager line of credit

Conclusion

This operator has removed the two artifacts defenders rely on most, the attacker domain and the malicious link, and replaced them with a trusted platform's own delivery and a string of text. The partner-request notification is only the current carrier. The handle grammar already travels across more than one authenticated notification system, so the durable defensive asset is behavior recognition, not a domain blocklist: a legitimate business notification whose user-supplied fields carry a contact handle and a deadline. Any platform that forwards customer-supplied text on a customer's behalf should expect to be enlisted as a delivery layer next.