One Kit, Two Industries: Inside a Fake Shop Platform

We started with six domains and a simple question: are these the same thing?

They didn’t look like it. Three were selling boots, three were selling sleepwear, and one rendered in German. One had prices two orders of magnitude too high. Two didn’t carry a brand name in the hostname at all.

Sixteen characters answered the question. A follow-up query then turned six domains into thousands of scan records on a single hosting provider, and turned what looked like two brand-impersonation incidents into something considerably more interesting.

A note on the screenshots below: they are redacted. We are not naming the impersonated retailers or publishing live hostnames while this cluster is still active.

The sixteen characters

Every one of the six storefronts served its social-preview image route with the same query parameter appended:

/opengraph-image.jpg?443c03a007878a5d

/twitter-image.jpg?443c03a007878a5d

That value is generated at compile time by the web framework the sites are built on, derived from the built metadata route. Two teams building two storefronts independently do not arrive at the same value, not on different brands, not in different languages, and not on different registration dates.

This is the whole finding, and it’s worth being clear about why it matters more than the visual similarity.

Visual similarity is the weakest evidence in brand-protection work. Every fake storefront looks like a real storefront. That’s the point of it. When a classification gets disputed, “these two sites look alike” collapses immediately, because commercial templates are everywhere and half the internet is running the same three ecommerce themes. A shared build artifact doesn’t collapse. It is a property of the compiled output, not of the design.

Everything else was corroboration

Once the fingerprint gave us the cluster, the supporting indicators fell out quickly. Two of them carry real evidentiary weight. The rest are texture, individually weak, and collectively they describe an assembly line.

The mirroring tool left a defect in every asset.

Static files are served from a path that embeds the hostname redundantly inside itself:

That isn’t a design decision. It’s a bug in whatever tool scraped the legitimate retailer and rebuilt its catalog, and it shows up on every storefront in the cluster. Because it lives in the build rather than the branding, it survives everything the operator is likely to change.

One storefront prices sleepwear at $29,700.

Prices render roughly a hundred times too high, with minor-unit values formatted as major units.

A shared design can be explained. A shared bug cannot. The same codebase renders correctly on the other five assets, which isolates the fault to a per-asset configuration error, exactly what you’d expect from a platform where the operator fills in a config file and hits deploy.

The smaller tells all point the same way. Hero and product images retain the filenames used by the real retailers, including internal identifiers and dimension strings, and nobody reproduces assets manually while preserving a filename like hp-hero-ritz-desktop-2560x1005-de85576d-2a03-4941-8559-54ebc06f1a99.jpg. Discounts are applied as a single multiplier across an entire catalog rather than selectively, at two different rates across the cluster, one per sub-vertical, which makes the discount rate a configuration value. And the social proof comes from a very small pool: exactly three five-star reviews on every storefront, single-letter avatar initials, and the same handful of reviewer first names recurring across storefronts selling completely different products.

The brand is a variable

Here is where this stopped being a brand-impersonation case and started being something else.

Two unrelated retailers. Different countries of origin, different product categories, different currencies, different locales, and different catalog structures. One build.

Which means the impersonated brand isn’t a property of this threat. It’s a parameter. Onboarding a new victim brand appears to require scraping their catalog and changing a configuration file, with no development work anywhere in that loop.

That reframes the defensive problem. If you’re protecting a brand and you build detection around your brand’s keywords, you’re detecting one row in someone else’s configuration table. The operator’s cost to add the next brand is close to zero. Your cost to detect it, if your logic is brand-shaped, is the same as it was for the first one.

Why consumer retail

Fake storefronts don’t target this sector by accident. The category has a specific combination of properties that lowers cost and detection risk at the same time:

• Deep discounting is normal here. Sixty to seventy percent off is an ordinary seasonal event in apparel. The same discount on electronics would trip a shopper’s instincts immediately.
• The product photography is free and excellent. Direct-to-consumer retailers publish extensive professional catalog imagery on open web properties. That is precisely what a scraping-driven kit needs, sitting behind no access barrier at all.
• The losses fall below the complaint threshold. A hundred-dollar order that never arrives frequently doesn’t become a chargeback, let alone a police report.
• Fulfillment expectations create a detection gap. Apparel is expected to take one to three weeks. By the time a victim realizes nothing is coming, the storefront may already be gone.
• Shoppers know the brand but not the channel. People recognize these labels without knowing the official domain or the authorized reseller list, which is exactly the gap a plausible lookalike fills.

Then we ran the pattern back

We took the path defect, the doubled /images/<hostname>/images/ structure, and queried it against a public scanning platform.

Roughly forty-nine hundred scan records.

An important caveat, and we’d rather state it than bury it: those are scan submissions, not unique hostnames. The same domain scanned repeatedly counts repeatedly, and the true number of distinct assets will be materially lower. We’re working through deduplication now. But even discounting heavily, this is an order of magnitude beyond the six domains we were handed.

Two things stood out in the returned sample.

The hosting is concentrated. Every result we inspected resolved to a single autonomous system, AS199242 (Malakmadze Web LLC, GE), across multiple disjoint IP ranges, with GeoIP attribution split between Georgia and the United States. Scattered addresses under one constant AS is the signature of a single hosting relationship, not of distributed or compromised infrastructure.

The targeting is much broader than we thought. The hostnames in the sample point at retailers in alcohol and beverage, outdoor equipment, natural and organic goods, and general apparel, alongside the footwear and sleepwear we started with. Several are constructed in German, which confirms locale is a deliberate targeting decision rather than an accident of translation.

So the vertical profile above was correct in shape and far too narrow in scope.

What we don’t know yet

One question stays open, and we would rather mark it than fill it with an assumption. We have not exercised the checkout flow, so we cannot yet confirm whether victim card data is harvested directly by operator-controlled infrastructure or passed to a legitimate processor.

That single unknown is the difference between a high-severity non-delivery operation, where the harm is a lost order, and a critical-severity card-harvesting one, where every shopper who reached the payment step has handed over a full card record that outlives the storefront. It also changes who needs to be notified, and how fast.

The bigger picture

This cluster represents the same structural shift in fake-shop fraud that phishing-as-a-service brought to credential theft. One actor building one fake store for one brand is no longer the shape of the threat. What we are looking at is a productized platform where the victim brand is a configuration value and the marginal cost of the next impersonation is close to zero. We have documented adjacent versions of this before, including storefronts that hide behind geo-IP and ad-campaign gating to stay invisible to conventional scanning.

Three questions are worth answering this week. Can your monitoring match on an artifact that has nothing to do with your brand name? Once you find a pattern, can you search historical scan data to size the cluster behind it? And can your enforcement path absorb several hundred hostnames instead of a handful?

Bolster AI monitors the external attack surface for exactly this class of activity: lookalike storefronts deployed at scale across hosting providers, scraped brand catalogs rebuilt on disposable infrastructure, and the shared build artifacts that link them into a single operation. Detection that keys on the kit rather than the keyword is what scales against a platform whose operator can onboard your brand with a config change, and enforcement has to move at the same speed.

The relevant question is not whether you have been impersonated. It is whether your detection would recognize it as part of something larger.

Appendix: what to hunt on

If you are hunting this, the durability of your selector matters more than its precision. The build fingerprint and the malformed asset path are both properties of the compiled output, which means they survive hostname rotation entirely. The operator can burn and re-register domains all day without changing either one.

filename.keyword:*443c03a007878a5d*

filename.keyword:*\/images\/*\/images\/branding\/*

Indicators