Borrowed Authentication: A Fake-Store Dropship Email Network

A single authenticated email account, spread across four AWS regions, carried post-purchase mail for more than a hundred fake storefronts. Each store had its own throwaway name, its own recently registered domain, and its own storefront on a legitimate commerce platform, yet all of them sent through one shared email tenant. That shared account is what tied the network together. The mail looked ordinary: order confirmations, shipment-status updates, arrival notices. It also passed every authentication check a receiver runs, because it was genuinely sent through a real platform's infrastructure. The scam sat underneath the normal-looking commerce. Payment was taken for goods that were cheap, counterfeit, or never shipped, and each confirmation email sustained the illusion of a real purchase.

Key Takeaways

• One durable correlator, an eight-character sending-account identifier embedded in the click-tracking host, ties the whole network together across four AWS regions and every store brand.
• The scam mail passes SPF, DKIM, and DMARC because it is genuinely sent through a legitimate commerce platform's authenticated sending account. Authentication is not a legitimacy signal here.
• The operator region-hops. When one regional tracking host was flagged, delivery shifted to sibling regions within a day while the account identifier stayed constant.
• Store domains fall into two registration cohorts: an aged 2023-2024 stash and a rolling 2025 monthly provisioning cadence, concentrated on a handful of cheap, privacy-friendly registrars.
• The store identity lives in the sender display name and sending domain, not the email address. The shared platform address carries both scam and legitimate merchant mail, so any response has to key on the merchant, not the platform.

Background

Fake-store fraud is a volume business. Operators stand up polished storefronts with product listings, logos, reviews, and a working checkout, take payment, and then ship counterfeits, cheap substitutes, or nothing at all. Some also harvest card and identity data at checkout. In franchise-style networks a core team runs the servers, payment processing, and templates while decentralized operators spin up individual shops. Malwarebytes documented one such network in March 2026 spanning more than 20,000 fake shops, and reported a sharp year-over-year rise in fake e-shop scams. The network described here is smaller and more focused, but it shares the model: many disposable shopfronts, one shared backend.

The backend in this case is a legitimate storefront platform. SHOPLINE is a Singapore-headquartered commerce platform founded in 2013, comparable in model to Shopify or BigCommerce, with hundreds of thousands of merchants across Asia-Pacific and beyond. Merchants get storefronts on myshopline[.]com subdomains and use the platform's shared backend, including its email delivery, to send post-purchase transactional mail. The abuse here is at the merchant-tenant layer. Fraudulent sellers sign up as merchants like any legitimate shop, and nothing about the platform itself is compromised or impersonated. This is the same "anyone can open a shop" dynamic that has been documented for other large commerce platforms, where un-vetted merchant accounts are used to sell counterfeits and take payment without shipping.

That merchant mail is delivered through Amazon Simple Email Service, AWS's high-volume transactional email API. When mail is sent through SES, AWS signs it with the tenant's DKIM keys and sends it from Amazon IP space, so it inherits Amazon's warmed, high-reputation infrastructure and passes SPF, DKIM, and DMARC by design. SES also rewrites links through its open and click tracking host, awstrack[.]me. That tracking hostname is region-specific and embeds a durable per-account identifier, which turns out to be the single most useful fingerprint in the whole network. Sending genuinely-authenticated mail through a trusted platform is exactly the technique behind recent reporting on SES-laundered phishing: the mail arrives from real Amazon infrastructure and passes every authentication check, because the reputation it carries is real. The variant here is narrower and less-reported, a fake-store network using a legitimate platform's own shared SES tenant to send transactional mail at the merchant tier.

The store domains themselves come from cheap, privacy-friendly registrars. Alibaba Cloud (HiChina), Xin Net, Cloud Yuqu, and Chengdu West Dimension are large, low-cost registrars that support bulk registration and readily offer WHOIS privacy. Fake-store operators favor them for cheap unit pricing at scale, fast spin-up of disposable domains, and weak identity linkage, which makes clusters hard to attribute and easy to churn. A second group of domains sits on NameSilo and Namecheap behind privacy services.

Post-purchase email is load-bearing for this kind of scam. "Order confirmed," "shipment status updated," "order arrived," and "refund initiated" messages manufacture the appearance of a real, fulfilled purchase. They suppress buyer suspicion during the dispute window and delay chargebacks. A smaller coin-dealer cluster in this network leans on "Merchant initiates refund" and "Order refunded" subjects, which fit a payment-reversal and dispute-management angle rather than a shipping one.

Discovery and Infrastructure

The network surfaced through its post-purchase mail: thousands of order and shipment notifications from store brands nobody recognized, each on a recently registered domain, each authenticating cleanly. Pulling on the click-tracking host is what turned a pile of unrelated-looking stores into one network. Every message routed its links through an awstrack[.]me tracking host whose subdomain carried the same eight-character sending-account identifier, regardless of which store sent the mail or which AWS region delivered it.

That identifier is the anchor. Store brands rotate, sending domains churn, and the AWS region label changes, but the account identifier stays constant. Grouping on it alone pulls the whole network together and separates it from the platform's legitimate merchant traffic.

Indicator	Role	Notes
awstrack[.]me	Abused platform	AWS SES open/click tracking; shared infrastructure, never a standalone indicator
nqxmlfhn.r.ap-southeast-1.awstrack[.]me	Tracking host	Operator-correlated SES tracking host, one of four regional siblings
myshopline[.]com	Abused platform	Legitimate storefront platform; merchant subdomains host the stores
adhple[.]com	Sending domain	Self-branded store ("U.S. Western Collector"), registered 2025
kwvaaw[.]shop	Sending domain	Coin-dealer cluster ("Coin World online shop")
valarey[.]com	Sending domain	Self-branded store, privacy-registered 2025

Two kinds of stores share the account. Some send from a no-reply address on the platform's own shared sending domains, carrying the store identity entirely in the display name. Others run their own recently registered domains and send service@, support@, or contact@ mail through the same shared account. Both kinds route their links through the same tracking identifier, and both point recipients back to a storefront on a myshopline[.]com subdomain or a standalone throwaway domain.

How It Works

A fraudulent seller registers a merchant account on the legitimate storefront platform, stands up a store on a myshopline[.]com subdomain, and in many cases also registers a matching throwaway domain through a cheap registrar. When a victim places and pays for an order, the store sends a sequence of transactional emails through the platform's shared sending account: an order confirmation, then a shipment-status update, then an arrival notice. Each message carries the store's display-name brand, passes SPF, DKIM, and DMARC because it is really sent through the platform's authenticated infrastructure, and routes its click links through an awstrack[.]me tracking host back to the storefront.

Nothing in the sequence looks alarming. The victim has already paid, the mail matches the purchase, and the authentication is genuine. The goods are counterfeit or never arrive, and the steady confirmation mail keeps the buyer waiting past the point where a fast dispute would succeed. The coin-dealer cluster adds a refund-themed twist, sending "refund initiated" mail that reads as a helpful gesture while managing the victim toward accepting a reversal or a partial resolution rather than a chargeback.

Sample Lures

All samples are defanged, and every recipient identifier has been replaced with a neutral placeholder. Attacker-controlled content only.

Order-confirmation pretext, self-branded store on its own 2025 domain:

From: "U.S. Western Collector" <service@adhple[.]com>
Return-Path: <bounce@spx.adhple[.]com>
Subject: U.S. Western Collector order confirmed

U.S. Western Collector
Order [order #]
Your order is confirmed
Hi [recipient name], ...
[link] http[:]//nqxmlfhn.r.ap-southeast-1.awstrack[.]me/L0/<url-encoded storefront>

Shipment-status pretext, order number folded into the subject line:

From: "Univetrsa" <support@univetrsa[.]com>
Return-Path: <bounce@spx.univetrsa[.]com>
Subject: Univetrsa[order #] shipment status updated

Univetrsa
Order [order #] - Shipment update
Hi [recipient name], ...
[link] http[:]//nqxmlfhn.r.ap-southeast-1.awstrack[.]me/L0/<url-encoded storefront>

Arrival-notice pretext, sent from a platform mail subdomain:

From: "Bdaeshop" <service@mail.bdaeshop[.]com>
Return-Path: <bounce@spn.mail.bdaeshop[.]com>
Subject: Order email - Arrived

Order [order #]
Order arrived
Your order arrived. ...
[link] http[:]//nqxmlfhn.r.ap-southeast-2.awstrack[.]me/l0/<url-encoded storefront>

Refund pretext from the coin-dealer cluster, returning through the raw SES bounce domain rather than a store domain:

From: "Coin World online shop" <service@kwvaaw[.]shop>
Return-Path: <bounce@ap-southeast-1.amazonses[.]com>
Subject: Merchant initiates refund

Coin World online shop
Order [order #]
Hi [recipient name], ...
[link] http[:]//nqxmlfhn.r.ap-southeast-1.awstrack[.]me/L0/<url-encoded storefront>

Technical Analysis

The Shared Account as the Durable Correlator

The one signal that survives everything else is the eight-character sending-account identifier in the tracking host. Store brands change with each shopfront, sending domains are registered and burned on a rolling basis, and the AWS region embedded in the tracking hostname rotates, but that account identifier is constant across the whole network. It is region-independent, so a single grouping on it captures the network regardless of which AWS region delivered a given message. Everything downstream, from the store domains to the storefront subdomains, hangs off that one anchor.

Region-Hopping Evasion

The tracking host exists in four regional forms, one each for ap-south-1, ap-southeast-1, ap-southeast-2, and ap-northeast-1. The operator treats the region as a disposable component. When the ap-south-1 tracking host was flagged, that region went quiet the next day while delivery continued from the two southeast-Asia siblings. The account identifier never changed. Addressing one regional host at a time simply pushes traffic to the others, so the four regions have to be treated as a single unit.

Sender Grammar: Display Name Over Address

The effective sender fingerprint is the display-name-plus-sending-domain pair, not the email address. Stores that send through the platform's shared address carry their entire identity in the display name, which means the same no-reply address delivers both scam mail and legitimate merchant mail. Stores on their own domains follow a consistent local-part convention (service@, support@, contact@, info@, cs@). The return path adds another tell: own-domain stores bounce through a short prefixed subdomain of the store domain (spx., spn., spm.), while some stores return straight through the raw amazonses[.]com bounce domain.

Registration Cohorts and Registrar Concentration

The store domains split into two clear registration cohorts. A small aged stash was registered in 2023 and 2024 and held before use. The bulk of the network was registered on a rolling monthly cadence through 2025, a provisioning rhythm that produces a fresh batch of store domains roughly every few weeks. One pair, adhple[.]com and swektsky[.]com, was registered on the same day, a same-batch signal that ties otherwise-unrelated store brands to one provisioning event.

Domain	Registrar	Created	Cohort
okhall[.]com	Alibaba Cloud (HiChina)	2023-10	Aged stash
univetrsa[.]com	NameSilo	2023-11	Aged stash
outdoor-mall[.]com	Chengdu West Dimension	2024-03	Aged stash
lush-farm[.]online	Alibaba Cloud (HiChina)	2024-11	Aged stash
bdaeshop[.]com	Chengdu West Dimension	2025-02	2025 cadence
adhple[.]com	Alibaba Cloud (HiChina)	2025-02-20	2025 cadence (same-day pair)
swektsky[.]com	Alibaba Cloud (HiChina)	2025-02-20	2025 cadence (same-day pair)
zephyrid[.]com	Namecheap	2025-03	2025 cadence
tuvilo[.]com	Xin Net	2025-05	2025 cadence
veraler[.]com	Alibaba Cloud (HiChina)	2025-06	2025 cadence
rushbuyus[.]com	Cloud Yuqu	2025-07	2025 cadence
valarey[.]com	NameSilo	2025-09	2025 cadence
choinlin[.]com	Xin Net	2025-10	2025 cadence
lumossky[.]com	NameSilo	2025-11	2025 cadence
morocenter[.]com	Alibaba Cloud (HiChina)	2025-11	2025 cadence

Registrar choice is concentrated. Four registrars carry most of the network:

Registrar	Role in the network
Alibaba Cloud (HiChina)	Largest share; aged stash and 2025 cadence both
Xin Net	Recurring 2025 registrations, WHOIS redacted
NameSilo	2025 registrations behind a privacy service
Cloud Yuqu / Chengdu West Dimension	Smaller shares; privacy-redacted

A separate sub-cohort of stores sits on .shop domains (kwvaaw[.]shop, hspmdk[.]shop, tpzrt[.]shop, kespark[.]shop, zgawjn[.]shop) with no resolvable WHOIS registrar at all, which lines up with the coin-dealer refund cluster and reads as a newer, distinct provisioning batch.

Detection Observations

The single strongest cross-network pivot is the shared sending-account identifier in the tracking host. It survives store-brand rotation, domain churn, and region hopping, and it separates the network from the legitimate merchant traffic on the same platform. Any one store looks small; grouped on the account identifier, the network is coherent.

At the individual-message level the mail is deliberately unremarkable. It resembles ordinary post-purchase commerce and authenticates cleanly, so content and authentication signals alone do not separate it from the legitimate merchant mail sharing the same infrastructure. The scam is visible at the ecosystem level, not per message. A useful combined signal is a freemail or burner reply-to on platform-authenticated transactional mail whose sending domain was registered within the last year. The return-path subdomain grammar and the coin-dealer refund-subject cluster are narrower keys on top of that.

Because legitimate merchants share the same sending account and the same platform apex, any blocking has to key on the store or merchant identity, the self-branded sending domain, or the operator-correlated tracking hosts. Acting on the shared platform address or the platform apex would land on real merchants.

MITRE Fight Fraud Framework Mapping

The campaign maps onto the MITRE Center for Threat-Informed Defense fraud framework (ctid.mitre.org/fraud). The framework's technique identifiers are not yet stably enumerable from public documentation, so the mapping below is given at the tactic level with technique descriptions rather than fabricated IDs.

Tactic	Technique (observed)
Resource Development	Bulk-register disposable store domains via cheap, privacy-friendly registrars
Resource Development	Enroll fraudulent merchant sub-tenants on a legitimate storefront platform and its shared sending account
Initial Access	Victim contact through authenticated, normal-looking post-purchase transactional email
Stealth	Pass SPF, DKIM, and DMARC via a genuine sending tenant; blend with legitimate platform mail
Stealth	Rotate delivery across four AWS regions when a regional tracking host is flagged
Execution	Take payment and issue fake order, shipment, and arrival notifications to sustain the illusion
Monetization	Convert the purchase into funds for undelivered or counterfeit goods; manage disputes with refund-themed mail

Indicators of Compromise

All indicators are defanged. Recipient and victim data has been removed. The lists below are a representative subset of the operator's verified infrastructure, not the full inventory.

Senders

Value	Role	Notes
service@adhple[.]com	Sender	"U.S. Western Collector" store
support@univetrsa[.]com	Sender	"Univetrsa" store
service@mail.bdaeshop[.]com	Sender	"Bdaeshop" store
service@kwvaaw[.]shop	Sender	Coin-dealer cluster
support@valarey[.]com	Sender	Self-branded store
service@tuvilo[.]com	Sender	Self-branded store
support@lumossky[.]com	Sender	Self-branded store
service@morocenter[.]com	Sender	Self-branded store
support@zephyrid[.]com	Sender	Self-branded store
service@mail.choinlin[.]com	Sender	Self-branded store
service@gotocomforts[.]com	Sender	Self-branded store
service@veraler[.]com	Sender	Self-branded store
service@mail.rushbuyus[.]com	Sender	Self-branded store
support@okhall[.]com	Sender	Self-branded store
service@vipukshop[.]com	Sender	Self-branded store
...		Representative subset; 100+ verified-malicious sender addresses

Domains

Value	Role	Notes
adhple[.]com	Store domain	Alibaba Cloud, reg 2025
univetrsa[.]com	Store domain	NameSilo, aged 2023
bdaeshop[.]com	Store domain	Chengdu West Dimension, reg 2025
kwvaaw[.]shop	Store domain	Coin-dealer cluster, no WHOIS
valarey[.]com	Store domain	NameSilo, reg 2025
tuvilo[.]com	Store domain	Xin Net, reg 2025
rushbuyus[.]com	Store domain	Cloud Yuqu, reg 2025
veraler[.]com	Store domain	Alibaba Cloud, reg 2025
lumossky[.]com	Store domain	NameSilo, reg 2025
morocenter[.]com	Store domain	Alibaba Cloud, reg 2025
zephyrid[.]com	Store domain	Namecheap, reg 2025
choinlin[.]com	Store domain	Xin Net, reg 2025
gotocomforts[.]com	Store domain	Alibaba Cloud, reg 2025
jinswhdre[.]com	Store domain	Cloud Yuqu, reg 2025
lush-farm[.]online	Store domain	Alibaba Cloud, aged 2024
...		Representative subset; 100+ verified-malicious store domains

Hosts

Value	Role	Notes
nqxmlfhn.r.ap-south-1.awstrack[.]me	Tracking host	Operator-correlated SES tracking host
nqxmlfhn.r.ap-southeast-1.awstrack[.]me	Tracking host	Operator-correlated SES tracking host
nqxmlfhn.r.ap-southeast-2.awstrack[.]me	Tracking host	Operator-correlated SES tracking host
nqxmlfhn.r.ap-northeast-1.awstrack[.]me	Tracking host	Operator-correlated SES tracking host

URLs

Value	Role	Notes
http[:]//nqxmlfhn.r.ap-southeast-1.awstrack[.]me/L0/<url-encoded storefront>	Redirect	Tracking redirect to a storefront
http[:]//nqxmlfhn.r.ap-southeast-2.awstrack[.]me/l0/<url-encoded storefront>	Redirect	Tracking redirect to a storefront

Conclusion

The account identifier is the operator's weak point and its convenience at the same time. Running the whole network through one shared sending tenant makes provisioning cheap and keeps every store authenticated, but it also collapses a hundred-plus shopfronts into a single fingerprint that survives every rotation the operator attempts. Region-hopping buys days, not immunity. Defenders watching this space should expect the store brands and domains to keep churning on a monthly cadence, and should anchor on the durable sending-account correlator and the merchant-level identity rather than the legitimate platform that carries the mail.