Borrowed Backends: Income-Scam Links on Shared API Gateway Trackers

Throughout spring 2026, a make-money-online email operator ran its click-tracking through AWS API Gateway endpoints owned by a legitimate email SaaS. The links looked like the operator's own serverless infrastructure: a valid Amazon TLS certificate, a random host under amazonaws[.]com, nothing to date-cohort or block. They were not. Every execute-api endpoint we mapped across a 90-day window turned out to be a shared multi-tenant SaaS link-tracker, form backend, or opt-in service, abused one tenant at a time. The scam content is a conventional income lure. The interesting part is the infrastructure, and specifically why the piece that looks most like attacker-owned infrastructure is the piece a defender must not block.

Key Takeaways

• A CTA that terminates on <id>.execute-api.<region>.amazonaws[.]com is almost never operator-owned; the ten-character host label is an AWS API Gateway REST API ID minted once per SaaS deployment and shared across every tenant of that platform.
• This operator split its mail across two independent rails: a sending rail (a Mailgun return-path, or AWS SES) and a tracking rail (a shared Pabbly link-tracker on API Gateway), so header analysis and link analysis each point at a different, individually innocuous vendor.
• The tenancy is provable from the message itself: the operator's mail carries the SaaS campaign-builder's own preview and asset URLs, and the SaaS vendor's own newsletters ride the identical host and path.
• Blocking the shared tracker host would break every legitimate co-tenant, so the endpoint is never a standalone indicator no matter how much scam traffic passes through it.
• The durable signal is the sender domain paired with the coined-product lure, not the host. Either rail can be re-provisioned without touching the other.

Background

Make-money-online offers, also sold as "done-for-you" (DFY) income or "activate your payouts" pitches, are business-opportunity scams. The lure promises a turnkey, mostly passive income system: a pre-built store, an "AI profit" engine, or an account with pending earnings the recipient only has to unlock. Monetization runs through an upsell funnel. A low-friction hook harvests engaged leads, then escalating charges follow for "training," "activation," or done-for-you storefronts, sometimes reaching tens of thousands of dollars, while the promised earnings rarely arrive. The FTC's 2024 Operation AI Comply sweep is the clearest public anchor, charging several done-for-you storefront and passive-income operations over deceptive earnings claims.

The infrastructure question is what drew our attention. AWS API Gateway is a managed service for publishing serverless HTTP endpoints. When a tenant deploys an API without a custom domain, AWS mints a default invoke URL shaped like https[:]//<api-id>.execute-api.<region>.amazonaws[.]com/<stage>/..., where <api-id> is a random ten-character identifier unique to that deployment, served under Amazon's own TLS chain. A link that ends there inherits a reputable trust chain and reveals almost nothing about who stood it up. That property is well known offensively: the open-source FireProx tool turns API Gateway into a rotating-egress HTTP proxy so red-team traffic hides under amazonaws[.]com. The same shape makes execute-api an attractive place for a scam CTA to terminate.

Most email platforms rewrite every CTA in a tenant's campaign so clicks route through the platform's own tracker before redirecting to the real destination, which is how they report opens, clicks, and unsubscribes. Pabbly, an email-marketing and automation SaaS, hosts that tracker on AWS API Gateway. A tenant's rewritten links therefore take the execute-api shape, with a track-click path and a track-unsubscribe path, while emails[.]pabbly[.]com serves the hosted "view in browser" preview and assets-emails[.]pabbly[.]com serves campaign images. Every tenant, legitimate marketer or scammer, gets the identical rewrite, so one API ID fronts many unrelated senders.

That multi-tenancy is why the tracker host cannot be flagged at the URL-reputation layer. execute-api endpoints belong to the same category as sendgrid[.]net, awstrack[.]me, and bit[.]ly: one host fronting thousands of unrelated legitimate customers. Blocking it breaks every co-tenant, so detection has to pivot to the decoded final destination, the sending domain, or tenant-scoped path artifacts, not the shared tracker itself. The sending rails in this campaign are separate again: AWS SES is Amazon's outbound relay, and Mailgun leaves a recognizable mg.<domain> return-path. Neither says anything about who rewrote the visible links.

Discovery and Infrastructure

The investigation started from a watchlist hypothesis that API Gateway endpoints might be operator-owned, network-invisible scam infrastructure. We enumerated every execute-api host in the email corpus over 90 days and found eight distinct endpoints. Only one carried real volume and stayed active: a us-west-2 host reached by a make-money-online mailer sending as support@jobinterviewsecret[.]com.

The hypothesis collapsed in a single pivot. Grouping senders on that host surfaced admin@pabbly[.]com, Pabbly's own product newsletters, riding the identical host and the identical track-click path at neutral, alongside the scam senders. The random ten-character host ID was not the scammer's. It was one Pabbly deployment serving all of Pabbly's tenants. Extending that check to the remaining seven endpoints produced the same picture across the board: each was a shared SaaS link-tracker, form backend, or opt-in confirmation service with at least one plainly legitimate co-tenant. Representative rows from the eight endpoints follow.

Endpoint (defanged)	Region	Tenant type	Path shape	Reputation
8yuhacbyj5[.]execute-api[.]us-west-2[.]amazonaws[.]com	us-west-2	Pabbly link-tracker (scam and legitimate Pabbly co-tenants)	/tc, /tu	no malicious classification
xtnzefcqrb[.]execute-api[.]us-east-1[.]amazonaws[.]com	us-east-1	SaaS verification backend (second tenant)	/pr	none; apex hosting-protected
Additional us-east-1 endpoints	us-east-1	Book-club retailer, slots app, national-government newsletter	/pr, /st, /prod	none; hosting-protected
n1nebh5zn3[.]execute-api[.]eu-west-1[.]amazonaws[.]com	eu-west-1	Cashback-app double opt-in	/de, /prod	none
amazonaws[.]com and regional service apex	n/a	AWS service root	n/a	hosting infrastructure, never flag

The reputation baseline reinforced the point. Thousands of distinct execute-api hosts appear in reputation data, and none carry a malicious classification. These serverless endpoints behave exactly like ESP tracking domains: shared infrastructure, never a standalone indicator.

How It Works

The primary operator sends from jobinterviewsecret[.]com, an aged domain re-activated for the mailer. Delivery runs through Mailgun, visible in the mg.jobinterviewsecret[.]com return-path. The campaign is composed in Pabbly's builder, which rewrites the body CTA and the unsubscribe link to the shared execute-api tracker. The lure asserts prior consent: the recipient supposedly already signed up and only has to activate a pending "payouts" or "eChecks" account. A click follows the track-click path, Pabbly logs it, and the redirect lands on the offer funnel.

The second tenant, sending as support@famesupport[.]com, uses a verification-code pretext and a different shared endpoint in us-east-1, reached by a track-parameter path rather than Pabbly's two-character verbs. Same tenant-abuse pattern, unrelated operator, different SaaS backend. A third, tangential actor sending as anthony@tigerinternetsolutions[.]co[.]uk runs aggressive make-money affiliate promotions through AWS SES directly, with no execute-api layer at all.

Sample Lures

Primary income lure (jobinterviewsecret[.]com), recipient data redacted, indicators defanged:

From: "Team JIS" <support@jobinterviewsecret[.]com>
Subject: your new automated epayouts mechanism
Return-Path: bounce+[tracking-token]@mg.jobinterviewsecret[.]com
List-Unsubscribe: <hxxps://8yuhacbyj5[.]execute-api[.]us-west-2[.]amazonaws[.]com/tu/[token]>

Hey,

We see that you had already completed verifying your email and confirming
interest in the new Automated ePayouts Mechanism.

It is very much a "plug 'n play" approach whereby you are putting your cup
into an already flowing stream of results/epayouts without having to learn
all the complicated stuff from scratch yourself:

    New Automated ePayouts-Account Can Be Activated

Afterwards, a congrats will be in order. Just follow the simple instructions
and you will get going with this in no time at all.

Please watch the step-by-step instructions and activate:
    hxxps://8yuhacbyj5[.]execute-api[.]us-west-2[.]amazonaws[.]com/tc/[token]

Best wishes,
Team JIS
Job Interview Secret, 60 Tottenham Court Road, London, W1T 2EW, UK
This email was sent to [recipient email] | Unsubscribe | View in Browser

Second tenant, verification-code pretext (famesupport[.]com), on a different shared backend:

From: "Famesupport Customer Service" <support@famesupport[.]com>
Subject: Verification Code ([service])
CTA: hxxps://xtnzefcqrb[.]execute-api[.]us-east-1[.]amazonaws[.]com/pr/[token]

Technical Analysis

The Two-Rail Architecture

The operator decouples sending from tracking. The sending rail is per-operator and burnable: jobinterviewsecret relays through Mailgun, famesupport through AWS SES, tigerinternetsolutions through AWS SES in eu-west-1. The tracking rail is shared SaaS that the operator does not own. This split is the campaign's defining feature. A header-based sender analysis sees an ESP relay; a link-based destination analysis sees a shared API Gateway tracker; each vendor, examined alone, is innocuous. The abuse is only visible when sender and content are correlated.

Sender (defanged)	Sending rail	Return-path or SPF anchor	Tracking rail	Path verbs
support@jobinterviewsecret[.]com	Mailgun	mg.jobinterviewsecret[.]com; SPF via dnssmarthost[.]net	8yuhacbyj5[.]execute-api[.]us-west-2[.]amazonaws[.]com (Pabbly)	/tc, /tu
support@famesupport[.]com	AWS SES	amazonses[.]com / return.famesupport[.]com	xtnzefcqrb[.]execute-api[.]us-east-1[.]amazonaws[.]com	/pr
anthony@tigerinternetsolutions[.]co[.]uk	AWS SES (eu-west-1)	SPF via spf.stackmail[.]com	none (direct offer links)	n/a

The return-path and SPF anchors above are shared sending and DNS providers, abused the same way as the tracker. None is operator-owned.

Reading an execute-api Endpoint

The ten-character host label is the AWS API Gateway REST API ID, minted per deployment. Two artifacts tell a link-tracker apart from a raw serverless backend. Pabbly uses two-character verb paths: /tc for track-click on body CTAs and /tu for track-unsubscribe in the List-Unsubscribe header. The other abused endpoints expose raw API Gateway stage names instead, such as /prod, /stag, /dev, /de, and /st. A verb path signals a purpose-built tracking product; a stage name signals a generic serverless deployment. Both are shared, and neither is a blockable indicator on its own. The endpoints also spread across regions by function: us-west-2 for the Pabbly tracker, us-east-1 for the verification backend and several unrelated tenants, eu-west-1 for a cashback opt-in service.

The Tenancy Proof

Three independent signals confirm the operator is a tenant, not the owner. First, Pabbly's own newsletters ride the same host and the same /tc path at neutral, so the deployment predates and outlives any one sender. Second, the operator's mail body carries emails[.]pabbly[.]com/app/email-preview/<id> and assets-emails[.]pabbly[.]com URLs, which means the message was authored inside Pabbly's campaign builder rather than merely pointed at its tracker. Third, the reputation baseline shows thousands of execute-api hosts with zero malicious classifications. The verdict has to live on the sender, because the host is load-bearing for many legitimate customers.

Registration and Naming

There is no fresh-registration tell here. All three sender domains are aged and wrapped in a reputable ESP, with relaxed DMARC that permits the ESP relay to pass authentication.

Domain (defanged)	Registrar	WHOIS created	DMARC policy	Notes
jobinterviewsecret[.]com	GoDaddy	2006	p=none	Aged shell re-activated for the mailer; Mailgun-sent
famesupport[.]com	Tucows	2006	p=quarantine	Second execute-api tenant; operator-controlled sending domain
tigerinternetsolutions[.]co[.]uk	GoDaddy (Nominet)	2013	p=none	Affiliate-spam tail; SES-direct, no tracker

The naming is not brand impersonation. The operator coins its own product vocabulary and recombines it: eProfits-App, eChecks, ePayouts, DFY Dashboard, DIGI-STORE, Mobile ATM-Machine, Commission-Box, AI method. Subjects follow a fixed grammar of a manufactured-approval or activation imperative, a month stamp, and often a single trailing emoji, for example "Activate Your June eChecks Method" or "AI eProfits-App is now Approved." The body asserts prior consent to blunt the recipient's suspicion, and the CAN-SPAM footer uses a generic London virtual-office address.

Detection Observations

The signal that separates this traffic from the legitimate Pabbly mail sharing the same host is never the host. It is the sender domain, the coined-product lure, and the manufactured-consent body, taken together. The two-rail split is what makes single-vendor analysis fail: the sending relay and the tracking tracker are both shared services with real customers, so a defender keying on either in isolation sees nothing actionable.

Several combinations are strong behavioral tells. An aged sender domain with a relaxed DMARC policy, relaying through one ESP while its visible links route through a different SaaS tracker, is unusual for a genuine marketer, who typically sends and tracks on the same platform. Composed-in-Pabbly artifacts, the preview and asset URLs, co-occurring with an income-approval subject and an invented product name is another. The path shape is a weaker discriminator that still has value: a verb path marks a link-tracker tenant, a raw stage name marks a generic serverless backend, and knowing which is which tells a defender where the redirect resolves without treating the shared host as guilty. Recognition happens at the sender and content layer. The shared serverless endpoint is deliberately left alone.

Indicators of Compromise

The indicators below are a representative, defanged subset. The execute-api endpoints in this campaign are deliberately excluded: they are shared multi-tenant SaaS infrastructure with legitimate co-tenants, and listing them as indicators would invite blocking that breaks unrelated customers. The actionable indicators are the operator's own sending identities.

Senders

Value	Role	Notes
support@jobinterviewsecret[.]com	Sender	Primary DFY-income mailer; Mailgun send, Pabbly tracking
support@famesupport[.]com	Sender	Verification-code pretext on a second shared backend
anthony@tigerinternetsolutions[.]co[.]uk	Sender	Affiliate-spam tail; SES-direct, no tracker

Domains

Value	Role	Notes
jobinterviewsecret[.]com	Sender domain	Aged shell re-activated for the income mailer
famesupport[.]com	Sender domain	Second execute-api tenant
tigerinternetsolutions[.]co[.]uk	Sender domain	Aggressive make-money affiliate spam

Conclusion

The operator built almost nothing that a defender can block. It rents its sending relay, rents its click-tracker from an unrelated email SaaS, and hides behind a valid Amazon certificate on a host it does not own. The rational response is to key on what the operator actually controls: the aged sender domain, the coined-product vocabulary, and the split between sending and tracking rails. Tenant churn is the expected next move, so when one sender domain burns, watch for the same lure on a fresh aged shell and, separately, for a genuinely single-tenant serverless endpoint with no legitimate co-tenant, which would finally be worth blocking.